diff options
| author | Danilo Krummrich <dakr@kernel.org> | 2026-05-28 20:04:24 +0200 |
|---|---|---|
| committer | Danilo Krummrich <dakr@kernel.org> | 2026-05-28 21:48:11 +0200 |
| commit | e2b773fb7b0735aa159491189651d64ab942e229 (patch) | |
| tree | d72e72d3e6a371cf79df3184ec1881f10f35eb71 /Documentation | |
| parent | 2cf1840b0fa7637b6731fd554529f8d57ea34c04 (diff) | |
| parent | bed29492d413349e5b13f21936655064cdb63c91 (diff) | |
| download | linux-next-history-e2b773fb7b0735aa159491189651d64ab942e229.tar.gz | |
Merge remote-tracking branch 'drm/drm-next' into drm-rust-next
Backmerge to pull in commit 838d852da850 ("rust: allow
`clippy::collapsible_match` globally"), in order to get rid of spurious
warnings messing with developer tooling.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Diffstat (limited to 'Documentation')
97 files changed, 1759 insertions, 320 deletions
diff --git a/Documentation/.renames.txt b/Documentation/.renames.txt index 43d44753ab93b..aa7e5aa4a81b3 100644 --- a/Documentation/.renames.txt +++ b/Documentation/.renames.txt @@ -786,6 +786,7 @@ networking/altera_tse networking/device_drivers/ethernet/altera/altera_tse networking/bpf_flow_dissector bpf/prog_flow_dissector networking/cxacru networking/device_drivers/atm/cxacru networking/defza networking/device_drivers/fddi/defza +networking/device_drivers/3com/3c509 networking/device_drivers/ethernet/3com/3c509 networking/device_drivers/3com/vortex networking/device_drivers/ethernet/3com/vortex networking/device_drivers/amazon/ena networking/device_drivers/ethernet/amazon/ena networking/device_drivers/aquantia/atlantic networking/device_drivers/ethernet/aquantia/atlantic diff --git a/Documentation/ABI/obsolete/sysfs-driver-ivpu b/Documentation/ABI/obsolete/sysfs-driver-ivpu new file mode 100644 index 0000000000000..b906e71497293 --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-ivpu @@ -0,0 +1,30 @@ +What: /sys/bus/pci/drivers/intel_vpu/.../sched_mode +Date: October 2024 +KernelVersion: 6.12 +Contact: dri-devel@lists.freedesktop.org +Description: Current NPU scheduling mode. Returns one of the following strings: + - "HW" - Hardware Scheduler mode + - "OS" - Operating System Scheduler mode + Read-only. + Deprecated since the "OS" scheduling mode is not usable + and will be removed from future versions of the driver. + Will be removed in 2027 + +What: /sys/bus/pci/drivers/intel_vpu/.../npu_max_frequency_mhz +Date: April 2025 +KernelVersion: 6.15 +Contact: dri-devel@lists.freedesktop.org +Description: Legacy alias for /sys/bus/pci/drivers/intel_vpu/.../freq/hw_max_freq. + Shows maximum frequency in MHz of the NPU's data processing unit. + Read-only. + Will be removed in 2027 + +What: /sys/bus/pci/drivers/intel_vpu/.../npu_current_frequency_mhz +Date: April 2025 +KernelVersion: 6.15 +Contact: dri-devel@lists.freedesktop.org +Description: Legacy alias for /sys/bus/pci/drivers/intel_vpu/.../freq/current_freq. + Shows current frequency in MHz of the NPU's data processing unit. + The value is read only when the device is active; otherwise it returns 0. + Read-only. + Will be removed in 2027 diff --git a/Documentation/ABI/obsolete/sysfs-selinux-user b/Documentation/ABI/removed/sysfs-selinux-user index 8ab7557f283fe..8ab7557f283fe 100644 --- a/Documentation/ABI/obsolete/sysfs-selinux-user +++ b/Documentation/ABI/removed/sysfs-selinux-user diff --git a/Documentation/ABI/testing/sysfs-driver-ivpu b/Documentation/ABI/testing/sysfs-driver-ivpu new file mode 100644 index 0000000000000..91685774edfcc --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-ivpu @@ -0,0 +1,65 @@ +What: /sys/bus/pci/drivers/intel_vpu/.../npu_busy_time_us +Date: May 2024 +KernelVersion: 6.11 +Contact: dri-devel@lists.freedesktop.org +Description: Time in microseconds that the device spent executing jobs. The time is + counted when and only when there are jobs submitted to firmware. This time + can be used to measure the utilization of NPU, either by calculating the + difference between two timepoints or monitoring utilization percentage by + reading periodically. Recommended read period is 1 second to avoid impact + on job submission performance. Read-only. + +What: /sys/bus/pci/drivers/intel_vpu/.../npu_memory_utilization +Date: Jan 2025 +KernelVersion: 6.15 +Contact: dri-devel@lists.freedesktop.org +Description: Current NPU memory utilization in bytes. Reports the total size of all + resident buffer objects allocated for NPU use. Read-only. + +What: /sys/bus/pci/drivers/intel_vpu/.../freq/hw_min_freq +Date: April 2026 +KernelVersion: 7.2 +Contact: dri-devel@lists.freedesktop.org +Description: Minimum frequency in MHz supported by the NPU hardware. This is a + hardware capability and cannot be changed. Read-only. + +What: /sys/bus/pci/drivers/intel_vpu/.../freq/hw_efficient_freq +Date: April 2026 +KernelVersion: 7.2 +Contact: dri-devel@lists.freedesktop.org +Description: Most efficient operating frequency in MHz for the NPU. This represents + the frequency at which the NPU operates most efficiently in terms of power + and performance. Read-only. + +What: /sys/bus/pci/drivers/intel_vpu/.../freq/hw_max_freq +Date: April 2026 +KernelVersion: 7.2 +Contact: dri-devel@lists.freedesktop.org +Description: Maximum frequency in MHz supported by the NPU hardware. This is a + hardware capability and cannot be changed. Read-only. + +What: /sys/bus/pci/drivers/intel_vpu/.../freq/current_freq +Date: April 2026 +KernelVersion: 7.2 +Contact: dri-devel@lists.freedesktop.org +Description: Current operating frequency in MHz of the NPU. The value is valid only + when the device is active; returns 0 when idle. The actual frequency may + be lower than the requested range due to power or thermal constraints. + Read-only. + +What: /sys/bus/pci/drivers/intel_vpu/.../freq/set_min_freq +Date: April 2026 +KernelVersion: 7.2 +Contact: dri-devel@lists.freedesktop.org +Description: Configured minimum operating frequency in MHz (50XX devices and newer). + Values written are clamped to hardware limits (hw_min_freq to hw_max_freq). + If set_min_freq exceeds set_max_freq, the driver clamps set_min_freq to + set_max_freq when selecting the operating frequency. Read-write. + +What: /sys/bus/pci/drivers/intel_vpu/.../freq/set_max_freq +Date: April 2026 +KernelVersion: 7.2 +Contact: dri-devel@lists.freedesktop.org +Description: Configured maximum operating frequency in MHz (50XX devices and newer). + Values written are clamped to hardware limits (hw_min_freq to hw_max_freq). + Read-write. diff --git a/Documentation/accel/amdxdna/amdnpu.rst b/Documentation/accel/amdxdna/amdnpu.rst index 42e54904f9a87..064973bf48939 100644 --- a/Documentation/accel/amdxdna/amdnpu.rst +++ b/Documentation/accel/amdxdna/amdnpu.rst @@ -270,6 +270,31 @@ MERT can report various kinds of telemetry information like the following: * Deep Sleep counter * etc. +.. _amdxdna-usage-stats: + +Amdxdna DRM client usage stats implementation +============================================= + +The amdxdna driver implements the DRM client usage stats specification as +documented in :ref:`drm-client-usage-stats`. + +Example of the output showing the implemented key value pairs: + +:: + + pos: 0 + flags: 0100002 + mnt_id: 29 + ino: 939 + drm-driver: amdxdna_accel_driver + drm-client-id: 3219 + drm-pdev: 0000:c5:00.1 + amdxdna_accel_driver-heap-alloc: 60 KiB + amdxdna_accel_driver-internal-alloc: 67588 KiB + amdxdna_accel_driver-external-alloc: 0 + drm-total-memory: 67632 KiB + drm-shared-memory: 0 + References ========== diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst index 9f8e27355cba5..7c7cd457cf695 100644 --- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst +++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst @@ -47,21 +47,19 @@ Please note that implementation details can be changed. Called when swp_entry's refcnt goes down to 0. A charge against swap disappears. -3. charge-commit-cancel +3. charge-commit ======================= Memcg pages are charged in two steps: - mem_cgroup_try_charge() - - mem_cgroup_commit_charge() or mem_cgroup_cancel_charge() + - commit_charge() At try_charge(), there are no flags to say "this page is charged". at this point, usage += PAGE_SIZE. At commit(), the page is associated with the memcg. - At cancel(), simply usage -= PAGE_SIZE. - Under below explanation, we assume CONFIG_SWAP=y. 4. Anonymous diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 8ad0b27813175..6efd0095ed995 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -220,7 +220,7 @@ cgroup v2 currently supports the following mount options. memory_hugetlb_accounting Count HugeTLB memory usage towards the cgroup's overall memory usage for the memory controller (for the purpose of - statistics reporting and memory protetion). This is a new + statistics reporting and memory protection). This is a new behavior that could regress existing setups, so it must be explicitly opted in with this mount option. diff --git a/Documentation/admin-guide/laptops/uniwill-laptop.rst b/Documentation/admin-guide/laptops/uniwill-laptop.rst index 561334865feb7..1f3ca84c7d88b 100644 --- a/Documentation/admin-guide/laptops/uniwill-laptop.rst +++ b/Documentation/admin-guide/laptops/uniwill-laptop.rst @@ -43,6 +43,11 @@ Support for changing the platform performance mode is currently not implemented. Battery Charging Control ------------------------ +.. warning:: Some devices do not properly implement the charging threshold interface. Forcing + the driver to enable access to said interface on such devices might damage the + battery [1]_. Because of this the driver will not enable said feature even when + using the ``force`` module parameter. + The ``uniwill-laptop`` driver supports controlling the battery charge limit. This happens over the standard ``charge_control_end_threshold`` power supply sysfs attribute. All values between 1 and 100 percent are supported. @@ -70,3 +75,8 @@ The ``uniwill-laptop`` driver allows to set the configurable TGP for devices wit allow it. See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details. + +References +========== + +.. [1] https://www.reddit.com/r/XMG_gg/comments/ld9yyf/battery_limit_hidden_function_discovered_on/ diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst index f8e7050fc7623..a95e2ebce0057 100644 --- a/Documentation/admin-guide/pm/amd-pstate.rst +++ b/Documentation/admin-guide/pm/amd-pstate.rst @@ -358,9 +358,9 @@ Dynamic energy performance profile The amd-pstate driver supports dynamically selecting the energy performance profile based on whether the machine is running on AC or DC power. -Whether this behavior is enabled by default depends on the kernel -config option `CONFIG_X86_AMD_PSTATE_DYNAMIC_EPP`. This behavior can also be overridden -at runtime by the sysfs file ``/sys/devices/system/cpu/cpufreq/policyX/dynamic_epp``. +Whether this behavior is enabled by default depends on the kernel command line option +``amd_dynamic_epp`` is set. This behavior can also be overridden +at runtime by the sysfs file ``/sys/devices/system/cpu/amd_pstate/dynamic_epp``. When set to enabled, the driver will select a different energy performance profile when the machine is running on battery or AC power. The driver will @@ -485,9 +485,8 @@ kernel parameter ``amd_prefcore=disable``. ``amd_dynamic_epp`` When AMD pstate is in auto mode, dynamic EPP will control whether the kernel -autonomously changes the EPP mode. The default is configured by -``CONFIG_X86_AMD_PSTATE_DYNAMIC_EPP`` but can be explicitly enabled with -``amd_dynamic_epp=enable`` or disabled with ``amd_dynamic_epp=disable``. +autonomously changes the EPP mode. The default is disabled. It can be enabled +with the kernel parameter ``amd_dynamic_epp=enable``. User Space Interface in ``sysfs`` - General =========================================== diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index fde967b0c2e0e..25fe5d88fea6c 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -355,11 +355,12 @@ HyperThreading (HT) in the context of Intel processors, is enabled on at least one core, ``intel_pstate`` assigns performance-based priorities to CPUs. Namely, the priority of a given CPU reflects its highest HWP performance level which causes the CPU scheduler to generally prefer more performant CPUs, so the less -performant CPUs are used when the other ones are fully loaded. However, SMT -siblings (that is, logical CPUs sharing one physical core) are treated in a -special way such that if one of them is in use, the effective priority of the -other ones is lowered below the priorities of the CPUs located in the other -physical cores. +performant CPUs are used when the other ones are fully loaded. SMT siblings +(that is, logical CPUs sharing one physical core) are given the same priority. +The scheduler can pull tasks from lower-priority cores and place them on any +sibling. Since the scheduler spreads tasks among physical cores, tasks will be +placed on the SMT siblings of physical cores only after all physical cores are +busy. This approach maximizes performance in the majority of cases, but unfortunately it also leads to excessive energy usage in some important scenarios, like video diff --git a/Documentation/arch/riscv/cmodx.rst b/Documentation/arch/riscv/cmodx.rst index 40ba53bed5dff..cbfa812a11b45 100644 --- a/Documentation/arch/riscv/cmodx.rst +++ b/Documentation/arch/riscv/cmodx.rst @@ -21,13 +21,13 @@ call at each patchable function entry, and patches it dynamically at runtime to enable or disable the redirection. In the case of RISC-V, 2 instructions, AUIPC + JALR, are required to compose a function call. However, it is impossible to patch 2 instructions and expect that a concurrent read-side executes them -without a race condition. This series makes atmoic code patching possible in +without a race condition. This series makes atomic code patching possible in RISC-V ftrace. Kernel preemption makes things even worse as it allows the old state to persist across the patching process with stop_machine(). In order to get rid of stop_machine() and run dynamic ftrace with full kernel preemption, we partially initialize each patchable function entry at boot-time, -setting the first instruction to AUIPC, and the second to NOP. Now, atmoic +setting the first instruction to AUIPC, and the second to NOP. Now, atomic patching is possible because the kernel only has to update one instruction. According to Ziccif, as long as an instruction is naturally aligned, the ISA guarantee an atomic update. @@ -36,8 +36,8 @@ By fixing down the first instruction, AUIPC, the range of the ftrace trampoline is limited to +-2K from the predetermined target, ftrace_caller, due to the lack of immediate encoding space in RISC-V. To address the issue, we introduce CALL_OPS, where an 8B naturally align metadata is added in front of each -pacthable function. The metadata is resolved at the first trampoline, then the -execution can be derect to another custom trampoline. +patchable function. The metadata is resolved at the first trampoline, then the +execution can be directed to another custom trampoline. CMODX in the User Space ----------------------- diff --git a/Documentation/arch/riscv/zicfilp.rst b/Documentation/arch/riscv/zicfilp.rst index ab7d8e62ddaff..12b35969d17ad 100644 --- a/Documentation/arch/riscv/zicfilp.rst +++ b/Documentation/arch/riscv/zicfilp.rst @@ -78,7 +78,7 @@ the program. Per-task indirect branch tracking state can be monitored and controlled via the :c:macro:`PR_GET_CFI` and :c:macro:`PR_SET_CFI` -``prctl()` arguments (respectively), by supplying +``prctl()`` arguments (respectively), by supplying :c:macro:`PR_CFI_BRANCH_LANDING_PADS` as the second argument. These are architecture-agnostic, and will return -EINVAL if the underlying functionality is not supported. diff --git a/Documentation/crypto/krb5.rst b/Documentation/crypto/krb5.rst index beffa0133446d..f62e07ac68114 100644 --- a/Documentation/crypto/krb5.rst +++ b/Documentation/crypto/krb5.rst @@ -158,13 +158,22 @@ returned. When a message has been received, the location and size of the data with the message can be determined by calling:: - void crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5, - enum krb5_crypto_mode mode, - size_t *_offset, size_t *_len); + int crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5, + enum krb5_crypto_mode mode, + size_t *_offset, size_t *_len); The caller provides the offset and length of the message to the function, which then alters those values to indicate the region containing the data (plus any -padding). It is up to the caller to determine how much padding there is. +padding). It is up to the caller to determine how much padding there is. The +function returns an error if the length is too small or if the mode is +unsupported. An additional function:: + + int crypto_krb5_check_data_len(const struct krb5_enctype *krb5, + enum krb5_crypto_mode mode, + size_t len, size_t min_content); + +is provided to just do a basic check that the decrypted/verified message would +have a sufficient minimum payload. Preparation Functions --------------------- diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml index 9a6e9b25d14a9..7cfe92a8bcd72 100644 --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml @@ -36,18 +36,56 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Primary MIPI DSI port-1 for MIPI input or LVDS port-1 for LVDS input or DPI input. + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + required: + - data-lanes + port@1: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Additional MIPI port-2 for MIPI input or LVDS port-2 for LVDS input. Used in combination with primary port-1 to drive higher resolution displays + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + required: + - data-lanes + port@2: $ref: /schemas/graph.yaml#/properties/port description: @@ -99,6 +137,7 @@ examples: reg = <0>; endpoint { + data-lanes = <1 2 3 4>; remote-endpoint = <&dsi0_out>; }; }; diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 7586d681bcc6b..0363201f0e619 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -34,6 +34,7 @@ properties: - items: - enum: - doestek,dtc34lm85am # For the Doestek DTC34LM85AM Flat Panel Display (FPD) Transmitter + - idt,v103 # For the Triple 10-BIT LVDS Transmitter - onnn,fin3385 # OnSemi FIN3385 - ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer - ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml index e6808419f6254..7636c24906ba0 100644 --- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml +++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml @@ -30,6 +30,7 @@ properties: - algoltek,ag6311 - asl-tek,cs5263 - dumb-vga-dac + - mstar,tsumu88adt3-lf-1 - parade,ps185hdm - radxa,ra620 - realtek,rtd2171 diff --git a/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml b/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml index 3820dd7e11af1..4d34a92192bf0 100644 --- a/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml @@ -10,11 +10,14 @@ maintainers: - Joseph Guo <qijian.guo@nxp.com> description: - Waveshare bridge board is part of Waveshare panel which converts DSI to DPI. + Waveshare bridge board is part of Waveshare panel which converts DSI to DPI + or LVDS. properties: compatible: - const: waveshare,dsi2dpi + enum: + - waveshare,dsi2dpi + - waveshare,dsi2lvds reg: maxItems: 1 @@ -53,7 +56,7 @@ properties: port@1: $ref: /schemas/graph.yaml#/properties/port description: - Video port for MIPI DPI output panel. + Video port for MIPI DPI or LVDS output to the panel. required: - port@0 diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 8239adb7f7d3e..094a6383bb779 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -219,6 +219,7 @@ allOf: - required: - "#sound-dai-cells" else: + $ref: /schemas/sound/dai-common.yaml# properties: aux-bus: false required: @@ -243,7 +244,7 @@ allOf: clocks: minItems: 5 maxItems: 5 - clocks-names: + clock-names: minItems: 5 maxItems: 5 @@ -264,7 +265,7 @@ allOf: clocks: minItems: 5 maxItems: 6 - clocks-names: + clock-names: minItems: 5 maxItems: 6 @@ -277,7 +278,6 @@ allOf: - qcom,sc8180x-dp - qcom,sdm845-dp - qcom,sm8350-dp - - qcom,sm8650-dp then: properties: reg: @@ -286,6 +286,24 @@ allOf: clocks: minItems: 6 maxItems: 6 + clock-names: + minItems: 6 + maxItems: 6 + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8650-dp + then: + properties: + reg: + minItems: 5 + maxItems: 9 + clocks: + minItems: 6 + maxItems: 6 clocks-names: minItems: 6 maxItems: 6 @@ -306,7 +324,7 @@ allOf: clocks: minItems: 6 maxItems: 8 - clocks-names: + clock-names: minItems: 6 maxItems: 8 @@ -326,7 +344,7 @@ allOf: clocks: minItems: 5 maxItems: 6 - clocks-names: + clock-names: minItems: 5 maxItems: 6 diff --git a/Documentation/devicetree/bindings/display/msm/qcom,eliza-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,eliza-mdss.yaml index 47938d13d1ca8..bd4ba91a171f6 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,eliza-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,eliza-mdss.yaml @@ -119,7 +119,7 @@ examples: mdss_mdp: display-controller@ae01000 { compatible = "qcom,eliza-dpu"; reg = <0x0ae01000 0x93000>, - <0x0aeb0000 0x2008>; + <0x0aeb0000 0x3000>; reg-names = "mdp", "vbif"; @@ -304,7 +304,7 @@ examples: mdss_dsi0_phy: phy@ae95000 { compatible = "qcom,eliza-dsi-phy-4nm", "qcom,sm8650-dsi-phy-4nm"; reg = <0x0ae95000 0x200>, - <0x0ae95200 0x280>, + <0x0ae95200 0x300>, <0x0ae95500 0x400>; reg-names = "dsi_phy", "dsi_phy_lane", @@ -388,7 +388,7 @@ examples: mdss_dsi1_phy: phy@ae97000 { compatible = "qcom,eliza-dsi-phy-4nm", "qcom,sm8650-dsi-phy-4nm"; reg = <0x0ae97000 0x200>, - <0x0ae97200 0x280>, + <0x0ae97200 0x300>, <0x0ae97500 0x400>; reg-names = "dsi_phy", "dsi_phy_lane", @@ -407,11 +407,15 @@ examples: displayport-controller@af54000 { compatible = "qcom,eliza-dp", "qcom,sm8650-dp"; - reg = <0xaf54000 0x104>, - <0xaf54200 0xc0>, - <0xaf55000 0x770>, - <0xaf56000 0x9c>, - <0xaf57000 0x9c>; + reg = <0x0af54000 0x200>, + <0x0af54200 0x200>, + <0x0af55000 0xc00>, + <0x0af56000 0x400>, + <0x0af57000 0x400>, + <0x0af58000 0x400>, + <0x0af59000 0x400>, + <0x0af5a000 0x600>, + <0x0af5b000 0x600>; interrupts-extended = <&mdss 12>; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml index dccac525d202c..134321b508978 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml @@ -70,7 +70,7 @@ examples: display-controller@ae01000 { compatible = "qcom,sm8650-dpu"; reg = <0x0ae01000 0x8f000>, - <0x0aeb0000 0x2008>; + <0x0aeb0000 0x3000>; reg-names = "mdp", "vbif"; clocks = <&gcc_axi_clk>, diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml index a1c53e1910330..0f7f79527748e 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml @@ -112,7 +112,7 @@ examples: display-controller@ae01000 { compatible = "qcom,sm8650-dpu"; reg = <0x0ae01000 0x8f000>, - <0x0aeb0000 0x2008>; + <0x0aeb0000 0x3000>; reg-names = "mdp", "vbif"; clocks = <&gcc_axi_clk>, diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml index a38c2261ef1ac..46dc0d28da29a 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml @@ -117,7 +117,7 @@ examples: display-controller@ae01000 { compatible = "qcom,sm8750-dpu"; reg = <0x0ae01000 0x93000>, - <0x0aeb0000 0x2008>; + <0x0aeb0000 0x3000>; reg-names = "mdp", "vbif"; @@ -389,11 +389,15 @@ examples: displayport-controller@af54000 { compatible = "qcom,sm8750-dp", "qcom,sm8650-dp"; - reg = <0xaf54000 0x104>, - <0xaf54200 0xc0>, - <0xaf55000 0x770>, - <0xaf56000 0x9c>, - <0xaf57000 0x9c>; + reg = <0x0af54000 0x200>, + <0x0af54200 0x200>, + <0x0af55000 0xc00>, + <0x0af56000 0x400>, + <0x0af57000 0x400>, + <0x0af58000 0x400>, + <0x0af59000 0x400>, + <0x0af5a000 0x600>, + <0x0af5b000 0x600>; interrupts-extended = <&mdss 12>; diff --git a/Documentation/devicetree/bindings/display/panel/chipwealth,ch13726a.yaml b/Documentation/devicetree/bindings/display/panel/chipwealth,ch13726a.yaml new file mode 100644 index 0000000000000..c8d7b61037e62 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/chipwealth,ch13726a.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/chipwealth,ch13726a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Chip Wealth Technology CH13726A AMOLED driver + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +description: + Chip Wealth Technology CH13726A is a single-chip solution + for AMOLED connected using a MIPI-DSI video interface. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - const: ayntec,thor-panel-bottom + - const: chipwealth,ch13726a + + reg: + maxItems: 1 + description: DSI virtual channel + + vdd-supply: true + vddio-supply: true + vdd1v2-supply: true + avdd-supply: true + + port: true + reset-gpios: true + rotation: true + +required: + - compatible + - reg + - vdd-supply + - vddio-supply + - vdd1v2-supply + - avdd-supply + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "ayntec,thor-panel-bottom", "chipwealth,ch13726a"; + reg = <0>; + vdd1v2-supply = <&vreg_l11b_1p2>; + vddio-supply = <&vdd_disp_1v8>; + vdd-supply = <&vreg_l13b_3p0>; + avdd-supply = <&vdd_disp2_2v8>; + reset-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml b/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml new file mode 100644 index 0000000000000..db6775f4d75ca --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/focaltech,ota7290b.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Focaltech OTA7290B DSI panels + +maintainers: + - Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: waveshare,8.8-dsi-touch-a + + reg: + maxItems: 1 + + vdd-supply: + description: supply regulator for VDD, usually 3.3V + + vdda-supply: + description: supply regulator for VDDA, 7-10V + + vcc-supply: + description: supply regulator for VCCIO, usually 1.5V + + reset-gpios: true + backlight: true + rotation: true + port: true + +required: + - compatible + - reg + - vdd-supply + - vcc-supply + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "waveshare,8.8-dsi-touch-a"; + reg = <0>; + vdd-supply = <&vdd>; + vcc-supply = <&vccio>; + reset-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; + backlight = <&backlight>; + + port { + endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; + }; + }; + +... + diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml index 66404b425af35..7667428bf9a88 100644 --- a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml @@ -30,6 +30,8 @@ properties: - starry,2082109qfh040022-50e # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel - starry,himax83102-j02 + # Waveshare 12.3-DSI-TOUCH-A panel + - waveshare,12.3-dsi-touch-a - const: himax,hx83102 reg: diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml index 84e840e0224f2..83c343b028355 100644 --- a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml +++ b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml @@ -23,6 +23,8 @@ properties: - hannstar,hsd060bhw4 - microchip,ac40t08a-mipi-panel - powkiddy,x55-panel + - waveshare,5.0-dsi-touch-a + - waveshare,5.5-dsi-touch-a - const: himax,hx8394 - items: - enum: diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml index d979701a00a8a..42e35986fbf60 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml @@ -24,6 +24,7 @@ properties: - raspberrypi,dsi-7inch - startek,kd050hdfia020 - tdo,tl050hdv35 + - waveshare,7.0-dsi-touch-a - wanchanglong,w552946aaa - wanchanglong,w552946aba - const: ilitek,ili9881c @@ -34,6 +35,7 @@ properties: backlight: true port: true power-supply: true + iovcc-supply: true reset-gpios: true rotation: true diff --git a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml index e39efb44ed42c..4eae802de9fd5 100644 --- a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml +++ b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml @@ -24,6 +24,12 @@ properties: - radxa,display-10hd-ad001 - radxa,display-8hd-ad002 - taiguanck,xti05101-01a + - waveshare,3.4-dsi-touch-c + - waveshare,4.0-dsi-touch-c + - waveshare,8.0-dsi-touch-a + - waveshare,9.0-dsi-touch-b + - waveshare,10.1-dsi-touch-a + - waveshare,10.1-dsi-touch-b - const: jadard,jd9365da-h3 reg: diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt35532.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt35532.yaml new file mode 100644 index 0000000000000..ff6fdad7febfa --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35532.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/novatek,nt35532.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Novatek NT35532-based DSI display panels + +maintainers: + - Cristian Cozzolino <cristian_ci@protonmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + - flipkart,rimob-panel-nt35532-cs + - const: novatek,nt35532 + + reg: + maxItems: 1 + + backlight: true + reset-gpios: true + + avdd-supply: + description: positive boost supply regulator + + avee-supply: + description: negative boost supply regulator + + vci-supply: + description: regulator that supplies the analog voltage + + vddam-supply: + description: power supply for MIPI interface + + vddi-supply: + description: regulator that supplies the I/O voltage + + port: true + +required: + - compatible + - reg + - reset-gpios + - vddi-supply + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "flipkart,rimob-panel-nt35532-cs", "novatek,nt35532"; + reg = <0>; + + backlight = <&pmi8950_wled>; + reset-gpios = <&tlmm 61 GPIO_ACTIVE_LOW>; + avdd-supply = <&lab>; + avee-supply = <&ibb>; + vci-supply = <&pm8953_l17>; + vddi-supply = <&pm8953_l6>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index cc8d795df732c..6d4133b91e7cc 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -63,6 +63,8 @@ properties: - samsung,s6e3fa7-ams559nk06 # Shangai Top Display Optoelectronics 7" TL070WSH30 1024x600 TFT LCD panel - tdo,tl070wsh30 + # Team Source Display Technology 7" TST070WSBE-196C 1024x600 TFT LCD panel + - team-source-display,tst070wsbe-196c reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 3e41ed0ef5d51..44ec7388d8512 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -97,6 +97,8 @@ properties: - dataimage,fg1001l0dsswmg01 # DataImage, Inc. 7" WVGA (800x480) TFT LCD panel with 24-bit parallel interface. - dataimage,scf0700c48ggu18 + # Displaytech DT050BTFT-PTS 5.0" 800x480 TFT LCD Panel + - displaytech,dt050btft-pts # DLC Display Co. DLC1010GIG 10.1" WXGA TFT LCD Panel - dlc,dlc1010gig # Emerging Display Technology Corp. 3.5" QVGA TFT LCD panel @@ -304,6 +306,8 @@ properties: - shelly,sca07010-bfn-lnn # Starry KR070PE2T 7" WVGA TFT LCD panel - starry,kr070pe2t + # Startek KD070HDFLD092 7" WSVGA TFT LCD panel + - startek,kd070hdfld092 # Startek KD070WVFPA043-C069A 7" TFT LCD panel - startek,kd070wvfpa # Team Source Display Technology TST043015CMHX 4.3" WQVGA TFT LCD panel @@ -341,10 +345,38 @@ properties: - vivax,tpc9150-panel # VXT 800x480 color TFT LCD panel - vxt,vl050-8048nt-c01 + # Waveshare 10.1" WXGA (1280x800) LCD panel + - waveshare,10.1inch-c-panel + # Waveshare 11.9" (320x1480) LCD panel + - waveshare,11.9inch-panel # Waveshare 13.3" FHD (1920x1080) LCD panel - waveshare,13.3inch-panel + # Waveshare 2.8" VGA (480x640) LCD panel + - waveshare,2.8inch-panel + # Waveshare 3.4" (800x800) LCD panel + - waveshare,3.4inch-c-panel + # Waveshare 4.0" WVGA (480x800) LCD panel + - waveshare,4.0inch-panel + # Waveshare 4.0" (720x720) LCD panel + - waveshare,4.0inch-c-panel + # Waveshare 5.0" WSVGA (1024x600) LCD panel + - waveshare,5.0inch-c-panel + # Waveshare 5.0" HD 720p (720x1280) LCD panel + - waveshare,5.0inch-d-panel + # Waveshare 6.25" (720x1560) LCD panel + - waveshare,6.25inch-panel # Waveshare 7.0" WSVGA (1024x600) LCD panel - waveshare,7.0inch-c-panel + # Waveshare 7.0" WXGA (1280x800) LCD panel + - waveshare,7.0inch-e-panel + # Waveshare 7.0" HD 720p (720x1280) LCD panel + - waveshare,7.0inch-h-panel + # Waveshare 7.9" (400x1280) LCD panel + - waveshare,7.9inch-panel + # Waveshare 8.0" WXGA (1280x800) LCD panel + - waveshare,8.0inch-c-panel + # Waveshare 8.8" (480x1920) LCD panel + - waveshare,8.8inch-panel # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel - winstar,wf35ltiacd # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index db49b8ff8c748..9db9f84ad964b 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -26,6 +26,7 @@ properties: - realtek,rtd1619-mali - renesas,r9a07g044-mali - renesas,r9a07g054-mali + - renesas,r9a08g046-mali - renesas,r9a09g047-mali - renesas,r9a09g056-mali - renesas,r9a09g057-mali @@ -150,6 +151,7 @@ allOf: enum: - renesas,r9a07g044-mali - renesas,r9a07g054-mali + - renesas,r9a08g046-mali - renesas,r9a09g047-mali - renesas,r9a09g056-mali - renesas,r9a09g057-mali diff --git a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml index c4cc8af182807..7b59b60b62e5b 100644 --- a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml @@ -16,10 +16,15 @@ allOf: properties: compatible: - enum: - - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs - - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs - - amlogic,meson-axg-i2c # AXG and compatible SoCs + oneOf: + - items: + - enum: + - amlogic,t7-i2c + - const: amlogic,meson-axg-i2c + - enum: + - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs + - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs + - amlogic,meson-axg-i2c # AXG and compatible SoCs reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml index 500a965bdb7a8..9e59200ad37b6 100644 --- a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml @@ -22,7 +22,9 @@ properties: compatible: oneOf: - items: - - const: apple,t6020-i2c + - enum: + - apple,t6020-i2c + - apple,t8122-i2c - const: apple,t8103-i2c - items: - enum: diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml index 7c4d6170491db..f5c584cf2146d 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml @@ -24,6 +24,7 @@ properties: compatible: items: - enum: + - qcom,eliza-ipcc - qcom,glymur-ipcc - qcom,kaanapali-ipcc - qcom,milos-ipcc diff --git a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml index 91e8cd1db67b8..b66ae6300fafa 100644 --- a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml +++ b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml @@ -73,6 +73,15 @@ properties: HSP CSR is to control and get status of different high-speed peripherals (such as Ethernet, USB, SATA, etc.) via register, which can tune board-level's parameters of PHY, etc. + + Additional background information about the High-Speed Subsystem + and the HSP CSR block is available in Chapter 10 ("High-Speed Interface") + of the EIC7700X SoC Technical Reference Manual, Part 4 + (EIC7700X_SoC_Technical_Reference_Manual_Part4.pdf). The manual is + publicly available at + https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual/releases + + This reference is provided for background information only. $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: @@ -82,6 +91,8 @@ properties: - description: Offset of AXI clock controller Low-Power request register - description: Offset of register controlling TX/RX clock delay + - description: Optional offset of register controlling TXD delay + - description: Optional offset of register controlling RXD delay required: - compatible @@ -116,7 +127,7 @@ examples: reset-names = "stmmaceth"; rx-internal-delay-ps = <200>; tx-internal-delay-ps = <200>; - eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118>; + eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118 0x114 0x11c>; snps,axi-config = <&stmmac_axi_setup>; snps,aal; snps,fixed-burst; diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml index ed698c9ff42b0..becc7a11f8dc1 100644 --- a/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml @@ -18,7 +18,9 @@ properties: description: Phandles of rt5650 and rt5514 codecs items: - description: phandle of rt5650 codec + maxItems: 1 - description: phandle of rt5514 codec + maxItems: 1 mediatek,platform: $ref: /schemas/types.yaml#/definitions/phandle diff --git a/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml b/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml index 1d10cfbad86c7..504df31a4f90d 100644 --- a/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml @@ -21,6 +21,9 @@ properties: - fsl,ls2080a-qspi - spacemit,k1-qspi - items: + - const: spacemit,k3-qspi + - const: spacemit,k1-qspi + - items: - enum: - fsl,ls1043a-qspi - const: fsl,ls1021a-qspi diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 28784d66ae7ba..11c55b5df0e4c 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -437,6 +437,8 @@ patternProperties: description: Diodes, Inc. "^dioo,.*": description: Dioo Microcircuit Co., Ltd + "^displaytech,.*": + description: Displaytech Ltd. "^djn,.*": description: Shenzhen DJN Optronics Technology Co., Ltd "^dlc,.*": diff --git a/Documentation/filesystems/isofs.rst b/Documentation/filesystems/isofs.rst index 08fd469091d4b..2a30999b024f3 100644 --- a/Documentation/filesystems/isofs.rst +++ b/Documentation/filesystems/isofs.rst @@ -57,7 +57,7 @@ Mount options unique to the isofs filesystem. Recommended documents about ISO 9660 standard are located at: - http://www.y-adagio.com/ -- ftp://ftp.ecma.ch/ecma-st/Ecma-119.pdf +- https://ecma-international.org/wp-content/uploads/ECMA-119_2nd_edition_december_1987.pdf Quoting from the PDF "This 2nd Edition of Standard ECMA-119 is technically identical with ISO 9660.", so it is a valid and gratis substitute of the diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst b/Documentation/gpu/amdgpu/amdgpu-glossary.rst index 033167025fcca..d553dd599c966 100644 --- a/Documentation/gpu/amdgpu/amdgpu-glossary.rst +++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst @@ -233,8 +233,15 @@ we have a dedicated glossary for Display Core at TC Texture Cache + TCC + Texture Cache per Channel - L2 cache attached to the memory channels. + May be used when shader cores are accessing memory. + Despite "Texture" in the name, this is used by any kind of memory access. + TCCs may be mapped to TCPs, depending on the architecture. + TCP (AMDGPU) - Texture Cache per Pipe. Even though the name "Texture" is part of this + Texture Cache per Pipe - L1 cache attached to each CU. + Even though the name "Texture" is part of this acronym, the TCP represents the path to memory shaders; i.e., it is not related to texture. The name is a leftover from older designs where shader stages had different cache designs; it refers to the L1 cache in older diff --git a/Documentation/gpu/amdgpu/index.rst b/Documentation/gpu/amdgpu/index.rst index 8732084186a48..b2ab182236efb 100644 --- a/Documentation/gpu/amdgpu/index.rst +++ b/Documentation/gpu/amdgpu/index.rst @@ -23,3 +23,4 @@ Next (GCN), Radeon DNA (RDNA), and Compute DNA (CDNA) architectures. debugfs process-isolation amdgpu-glossary + ptl diff --git a/Documentation/gpu/amdgpu/ptl.rst b/Documentation/gpu/amdgpu/ptl.rst new file mode 100644 index 0000000000000..c7f16dea79546 --- /dev/null +++ b/Documentation/gpu/amdgpu/ptl.rst @@ -0,0 +1,94 @@ +======================================= +Peak Tops Limiter (PTL) sysfs Interface +======================================= + +Overview +-------- +The Peak Tops Limiter (PTL) sysfs interface enables users to control and +configure the PTL feature for each GPU individually. All PTL-related +sysfs files are located under `/sys/class/drm/cardX/device/ptl/`, where +`X` is the GPU index. Through these files, users can enable or disable +PTL, set preferred data formats, and query supported formats for each GPU. + +PTL sysfs files +---------------- +The following files are available under `/sys/class/drm/cardX/device/ptl/`: + +- `ptl_enable` +- `ptl_format` +- `ptl_supported_formats` + +PTL Enable/Disable +------------------ +File: `ptl_enable` +Type: Read/Write (rw) + +Read: Returns the current PTL status as a string: `enabled` if PTL +is active, or `disabled` if inactive. + +Write: + +- Write `1` or `enabled` to enable PTL +- Write `0` or `disabled` to disable PTL + +Examples:: + + # Query PTL status + cat /sys/class/drm/card1/device/ptl/ptl_enable + # Output: enabled + + # Enable PTL + sudo bash -c "echo 1 > /sys/class/drm/card1/device/ptl/ptl_enable" + + # Disable PTL + sudo bash -c "echo 0 > /sys/class/drm/card1/device/ptl/ptl_enable" + +PTL Format (Preferred Data Formats) +----------------------------------- +File: `ptl_format` +Type: Read/Write (rw) + +Read: Returns the two preferred formats, e.g. `I8,F32`. + +Write: Accepts two formats separated by a comma, e.g. `I8,F32`. + +- Both formats must be supported and different. +- If an invalid format is provided (not supported, or both formats are the + same), the driver will return "write error: Invalid argument". + +Examples:: + + # Query PTL formats + cat /sys/class/drm/card1/device/ptl/ptl_format + # Output: I8,F32 + + # Set PTL formats + sudo bash -c "echo I8,F32 > /sys/class/drm/card1/device/ptl/ptl_format" + +Supported Formats +----------------- +File: `ptl_supported_formats` +Type: Read-only (r) + +Read: Returns a comma-separated list of supported formats, e.g. +`I8,F16,BF16,F32,F64`. + +Example:: + + # Check supported formats + cat /sys/class/drm/card1/device/ptl/ptl_supported_formats + # Output: I8,F16,BF16,F32,F64 + +Behavioral Notes +---------------- +- PTL formats can only be set when PTL is enabled. +- If PTL is disabled, `ptl_format` returns `N/A`. +- Only two formats can be set at a time, and they must be from the supported set and different.. +- All commands support per-GPU targeting. +- Root permission is required to enable/disable PTL or change formats. +- If the hardware does not support PTL, the PTL sysfs directory will not + be created. + +Implementation +-------------- +The PTL sysfs nodes are implemented in `drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c`. diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst index 1f15a8ca12651..627fc68c7a21a 100644 --- a/Documentation/gpu/driver-uapi.rst +++ b/Documentation/gpu/driver-uapi.rst @@ -2,6 +2,8 @@ DRM Driver uAPI =============== +.. contents:: + drm/i915 uAPI ============= diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index 2e13e0ad7e88b..20d2c454aa1d9 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -8,6 +8,7 @@ GPU Driver Documentation amdgpu/index i915 imagination/index + intel-display/index mcde meson nouveau diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 94f93fd3b8a0a..a3ce25a36f1d7 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -18,6 +18,8 @@ event handling, memory management, output management, framebuffer management, command submission & fencing, suspend/resume support, and DMA services. +.. contents:: + Driver Initialization ===================== diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index b4a9e5ae81f6e..80453dda33b84 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -33,6 +33,8 @@ There are a few areas these helpers can grouped into: pipeline: Planes, handling rectangles for visibility checking and scissoring, flip queues and assorted bits. +.. contents:: + Modeset Helper Reference for Common Vtables =========================================== diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 2292e65f044c3..fa69a5450f967 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -1,3 +1,6 @@ + +.. _drm-kms: + ========================= Kernel Mode Setting (KMS) ========================= @@ -15,6 +18,8 @@ be setup by initializing the following fields. - struct drm_mode_config_funcs \*funcs; Mode setting functions. +.. contents:: + Overview ======== @@ -206,11 +211,11 @@ Atomic Mode Setting style=dashed label="Free-standing state" - "drm_atomic_state" -> "duplicated drm_plane_state A" - "drm_atomic_state" -> "duplicated drm_plane_state B" - "drm_atomic_state" -> "duplicated drm_crtc_state" - "drm_atomic_state" -> "duplicated drm_connector_state" - "drm_atomic_state" -> "duplicated driver private state" + "drm_atomic_commit" -> "duplicated drm_plane_state A" + "drm_atomic_commit" -> "duplicated drm_plane_state B" + "drm_atomic_commit" -> "duplicated drm_crtc_state" + "drm_atomic_commit" -> "duplicated drm_connector_state" + "drm_atomic_commit" -> "duplicated driver private state" } subgraph cluster_current { @@ -230,7 +235,7 @@ Atomic Mode Setting "driver private object" -> "driver private state" } - "drm_atomic_state" -> "drm_device" [label="atomic_commit"] + "drm_atomic_commit" -> "drm_device" [label="atomic_commit"] "duplicated drm_plane_state A" -> "drm_device"[style=invis] } @@ -265,7 +270,7 @@ Taken all together there's two consequences for the atomic design: drm_private_state<drm_private_state>`. - An atomic update is assembled and validated as an entirely free-standing pile - of structures within the :c:type:`drm_atomic_state <drm_atomic_state>` + of structures within the :c:type:`drm_atomic_commit <drm_atomic_commit>` container. Driver private state structures are also tracked in the same structure; see the next chapter. Only when a state is committed is it applied to the driver and modeset objects. This way rolling back an update boils down diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 32fb506db05b5..2dea94f77d52d 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -25,6 +25,8 @@ share it. GEM has simpler initialization and execution requirements than TTM, but has no video RAM management capabilities and is thus limited to UMA devices. +.. contents:: + The Translation Table Manager (TTM) =================================== diff --git a/Documentation/gpu/drm-ras.rst b/Documentation/gpu/drm-ras.rst index 70b246a78fc8a..83c21853b74b6 100644 --- a/Documentation/gpu/drm-ras.rst +++ b/Documentation/gpu/drm-ras.rst @@ -24,6 +24,8 @@ Key Goals: nodes for different IP blocks, sub-blocks, or other logical subdivisions as applicable. +.. contents:: + Nodes ===== @@ -52,6 +54,8 @@ User space tools can: as a parameter. * Query specific error counter values with the ``get-error-counter`` command, using both ``node-id`` and ``error-id`` as parameters. +* Clear specific error counters with the ``clear-error-counter`` command, using both + ``node-id`` and ``error-id`` as parameters. YAML-based Interface -------------------- @@ -101,3 +105,9 @@ Example: Query an error counter for a given node sudo ynl --family drm_ras --do get-error-counter --json '{"node-id":0, "error-id":1}' {'error-id': 1, 'error-name': 'error_name1', 'error-value': 0} +Example: Clear an error counter for a given node + +.. code-block:: bash + + sudo ynl --family drm_ras --do clear-error-counter --json '{"node-id":0, "error-id":1}' + None diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 579e87cb9ff75..2c2f939322fb9 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -16,6 +16,8 @@ management, and output management. Cover generic ioctls and sysfs layout here. We only need high-level info, since man pages should cover the rest. +.. contents:: + libdrm Device Lookup ==================== @@ -118,6 +120,10 @@ is already rather painful for the DRM subsystem, with multiple different uAPIs for the same thing co-existing. If we add a few more complete mistakes into the mix every year it would be entirely unmanageable. +The DRM subsystem has however no concern with independent closed-source +userspace implementations. To officialize that position, the DRM uAPI headers +are covered by the MIT license. + .. _drm_render_node: Render nodes @@ -761,4 +767,4 @@ Stable uAPI events From ``drivers/gpu/drm/scheduler/gpu_scheduler_trace.h`` .. kernel-doc:: drivers/gpu/drm/scheduler/gpu_scheduler_trace.h - :doc: uAPI trace events
\ No newline at end of file + :doc: uAPI trace events diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index 63d6b2abe5adf..70b7cfcc194f7 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -16,6 +16,8 @@ output is split between common and driver specific parts. Having said that, wherever possible effort should still be made to standardise as much as possible. +.. contents:: + File format specification ========================= @@ -215,3 +217,4 @@ Driver specific implementations * :ref:`panfrost-usage-stats` * :ref:`panthor-usage-stats` * :ref:`xe-usage-stats` +* :ref:`amdxdna-usage-stats` diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index eba09c3ddce42..0c9d687585331 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -1,3 +1,6 @@ + +.. _drm/i915: + =========================== drm/i915 Intel GFX Driver =========================== @@ -7,6 +10,9 @@ models) integrated GFX chipsets with both Intel display and rendering blocks. This excludes a set of SoC platforms with an SGX rendering unit, those have basic support through the gma500 drm driver. +The display, or :ref:`drm-kms`, support for drm/i915 is provided by +:ref:`drm/intel-display`, and shared with :ref:`drm/xe <drm/xe>`. + Core Driver Infrastructure ========================== @@ -64,200 +70,6 @@ Workarounds .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c :doc: Hardware workarounds -Display Hardware Handling -========================= - -This section covers everything related to the display hardware including -the mode setting infrastructure, plane, sprite and cursor handling and -display, output probing and related topics. - -Mode Setting Infrastructure ---------------------------- - -The i915 driver is thus far the only DRM driver which doesn't use the -common DRM helper code to implement mode setting sequences. Thus it has -its own tailor-made infrastructure for executing a display configuration -change. - -Frontbuffer Tracking --------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c - :doc: frontbuffer tracking - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.h - :internal: - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c - :internal: - -Display FIFO Underrun Reporting -------------------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c - :doc: fifo underrun handling - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c - :internal: - -Plane Configuration -------------------- - -This section covers plane configuration and composition with the primary -plane, sprites, cursors and overlays. This includes the infrastructure -to do atomic vsync'ed updates of all this state and also tightly coupled -topics like watermark setup and computation, framebuffer compression and -panel self refresh. - -Atomic Plane Helpers --------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c - :doc: atomic plane helpers - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c - :internal: - -Asynchronous Page Flip ----------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c - :doc: asynchronous flip implementation - -Output Probing --------------- - -This section covers output probing and related infrastructure like the -hotplug interrupt storm detection and mitigation code. Note that the -i915 driver still uses most of the common DRM helper code for output -probing, so those sections fully apply. - -Hotplug -------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c - :doc: Hotplug - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c - :internal: - -High Definition Audio ---------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c - :doc: High Definition Audio over HDMI and Display Port - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c - :internal: - -.. kernel-doc:: include/drm/intel/i915_component.h - :internal: - -Intel HDMI LPE Audio Support ----------------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c - :doc: LPE Audio integration for HDMI or DP playback - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c - :internal: - -Panel Self Refresh PSR (PSR/SRD) --------------------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c - :doc: Panel Self Refresh (PSR/SRD) - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c - :internal: - -Frame Buffer Compression (FBC) ------------------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c - :doc: Frame Buffer Compression (FBC) - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c - :internal: - -Display Refresh Rate Switching (DRRS) -------------------------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c - :doc: Display Refresh Rate Switching (DRRS) - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c - :internal: - -DPIO ----- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c - :doc: DPIO - -DMC Firmware Support --------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c - :doc: DMC Firmware Support - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c - :internal: - -DMC Flip Queue --------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_flipq.c - :doc: DMC Flip Queue - -DMC wakelock support --------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c - :doc: DMC wakelock support - -Video BIOS Table (VBT) ----------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c - :doc: Video BIOS Table (VBT) - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c - :internal: - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_vbt_defs.h - :internal: - -Display clocks --------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c - :doc: CDCLK / RAWCLK - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c - :internal: - -Display PLLs ------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c - :doc: Display PLLs - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c - :internal: - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.h - :internal: - -Display State Buffer --------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c - :doc: DSB - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c - :internal: - GT Programming ============== @@ -568,7 +380,7 @@ The HuC FW layout is the same as the GuC one, see `GuC Firmware Layout`_ DMC --- -See `DMC Firmware Support`_ +See :ref:`drm/intel-display/dmc`. Tracing ======= diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 5d708a106b3fa..65bf3b26e4f4c 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -3,6 +3,7 @@ GPU Driver Developer's Guide ============================ .. toctree:: + :maxdepth: 2 introduction drm-internals diff --git a/Documentation/gpu/intel-display/async-flip.rst b/Documentation/gpu/intel-display/async-flip.rst new file mode 100644 index 0000000000000..40f93e885bb78 --- /dev/null +++ b/Documentation/gpu/intel-display/async-flip.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Asynchronous Page Flip +====================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c + :doc: asynchronous flip implementation diff --git a/Documentation/gpu/intel-display/atomic.rst b/Documentation/gpu/intel-display/atomic.rst new file mode 100644 index 0000000000000..43a473181e7a1 --- /dev/null +++ b/Documentation/gpu/intel-display/atomic.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Atomic Modeset Support +====================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic.c + :doc: atomic modeset support + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic.c + :internal: diff --git a/Documentation/gpu/intel-display/audio.rst b/Documentation/gpu/intel-display/audio.rst new file mode 100644 index 0000000000000..eef95df75f8d2 --- /dev/null +++ b/Documentation/gpu/intel-display/audio.rst @@ -0,0 +1,23 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +High Definition Audio +===================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c + :doc: High Definition Audio over HDMI and Display Port + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c + :internal: + +.. kernel-doc:: include/drm/intel/i915_component.h + :internal: + +Intel HDMI LPE Audio Support +============================ + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c + :doc: LPE Audio integration for HDMI or DP playback + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c + :internal: diff --git a/Documentation/gpu/intel-display/casf.rst b/Documentation/gpu/intel-display/casf.rst new file mode 100644 index 0000000000000..406778ccd94ca --- /dev/null +++ b/Documentation/gpu/intel-display/casf.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Content Adaptive Sharpness Filter (CASF) +======================================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_casf.c + :doc: Content Adaptive Sharpness Filter (CASF) diff --git a/Documentation/gpu/intel-display/cdclk.rst b/Documentation/gpu/intel-display/cdclk.rst new file mode 100644 index 0000000000000..a66d623b0ec9b --- /dev/null +++ b/Documentation/gpu/intel-display/cdclk.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Display clocks +============== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c + :doc: CDCLK / RAWCLK + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c + :internal: diff --git a/Documentation/gpu/intel-display/cmtg.rst b/Documentation/gpu/intel-display/cmtg.rst new file mode 100644 index 0000000000000..04edd0bd165d2 --- /dev/null +++ b/Documentation/gpu/intel-display/cmtg.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Common Primary Timing Generator (CMTG) +====================================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cmtg.c + :doc: Common Primary Timing Generator (CMTG) diff --git a/Documentation/gpu/intel-display/dmc.rst b/Documentation/gpu/intel-display/dmc.rst new file mode 100644 index 0000000000000..4368da4c70489 --- /dev/null +++ b/Documentation/gpu/intel-display/dmc.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +.. _drm/intel-display/dmc: + +DMC Firmware Support +==================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c + :doc: DMC Firmware Support + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c + :internal: + + +DMC Flip Queue +============== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_flipq.c + :doc: DMC Flip Queue + +DMC wakelock support +==================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c + :doc: DMC wakelock support diff --git a/Documentation/gpu/intel-display/dpio.rst b/Documentation/gpu/intel-display/dpio.rst new file mode 100644 index 0000000000000..84d92ac162f85 --- /dev/null +++ b/Documentation/gpu/intel-display/dpio.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +DPIO +==== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c + :doc: DPIO diff --git a/Documentation/gpu/intel-display/dpll.rst b/Documentation/gpu/intel-display/dpll.rst new file mode 100644 index 0000000000000..c750352e0ae50 --- /dev/null +++ b/Documentation/gpu/intel-display/dpll.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Display PLLs +============ + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c + :doc: Display PLLs + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c + :internal: + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.h + :internal: diff --git a/Documentation/gpu/intel-display/drrs.rst b/Documentation/gpu/intel-display/drrs.rst new file mode 100644 index 0000000000000..a5aaba63d6b95 --- /dev/null +++ b/Documentation/gpu/intel-display/drrs.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Display Refresh Rate Switching (DRRS) +===================================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c + :doc: Display Refresh Rate Switching (DRRS) + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c + :internal: diff --git a/Documentation/gpu/intel-display/dsb.rst b/Documentation/gpu/intel-display/dsb.rst new file mode 100644 index 0000000000000..857aca59995ad --- /dev/null +++ b/Documentation/gpu/intel-display/dsb.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Display State Buffer +==================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c + :doc: DSB + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c + :internal: diff --git a/Documentation/gpu/intel-display/fbc.rst b/Documentation/gpu/intel-display/fbc.rst new file mode 100644 index 0000000000000..de9e19021f507 --- /dev/null +++ b/Documentation/gpu/intel-display/fbc.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Frame Buffer Compression (FBC) +============================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c + :doc: Frame Buffer Compression (FBC) + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c + :internal: diff --git a/Documentation/gpu/intel-display/fifo-underrun.rst b/Documentation/gpu/intel-display/fifo-underrun.rst new file mode 100644 index 0000000000000..5d8f019215069 --- /dev/null +++ b/Documentation/gpu/intel-display/fifo-underrun.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Display FIFO Underrun Reporting +=============================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c + :doc: fifo underrun handling + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c + :internal: diff --git a/Documentation/gpu/intel-display/frontbuffer.rst b/Documentation/gpu/intel-display/frontbuffer.rst new file mode 100644 index 0000000000000..7ae38e0827bf1 --- /dev/null +++ b/Documentation/gpu/intel-display/frontbuffer.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Frontbuffer Tracking +==================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c + :doc: frontbuffer tracking + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c + :internal: diff --git a/Documentation/gpu/intel-display/hotplug.rst b/Documentation/gpu/intel-display/hotplug.rst new file mode 100644 index 0000000000000..f33bc0087c278 --- /dev/null +++ b/Documentation/gpu/intel-display/hotplug.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Hotplug +======= + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c + :doc: Hotplug + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c + :internal: diff --git a/Documentation/gpu/intel-display/index.rst b/Documentation/gpu/intel-display/index.rst new file mode 100644 index 0000000000000..01c3d1e576b71 --- /dev/null +++ b/Documentation/gpu/intel-display/index.rst @@ -0,0 +1,44 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +.. _drm/intel-display: + +==================== +Intel Display Driver +==================== + +The Intel display driver provides the display, or :ref:`drm-kms`, support for +both the :ref:`drm/xe <drm/xe>` and :ref:`drm/i915 <drm/i915>` Intel GPU +drivers. + +The source code currently resides under ``drivers/gpu/drm/i915/display`` due to +historical reasons, and it's compiled separately into both drm/xe and drm/i915 +kernel modules. + +The drm/xe and drm/i915 drivers are the "core" or "parent" drivers for display, +as they initialize and own the drm device, and pass that on to the display +driver. The display driver isn't an independent driver in that sense. + +.. toctree:: + :maxdepth: 1 + :caption: Detailed display topics + + async-flip + atomic + audio + casf + cdclk + cmtg + dmc + dpio + dpll + drrs + dsb + fbc + fifo-underrun + frontbuffer + hotplug + plane + psr + snps-phy + vbt diff --git a/Documentation/gpu/intel-display/plane.rst b/Documentation/gpu/intel-display/plane.rst new file mode 100644 index 0000000000000..59932a82051b5 --- /dev/null +++ b/Documentation/gpu/intel-display/plane.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Atomic Plane Helpers +==================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c + :doc: atomic plane helpers + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c + :internal: diff --git a/Documentation/gpu/intel-display/psr.rst b/Documentation/gpu/intel-display/psr.rst new file mode 100644 index 0000000000000..63e56abcdd564 --- /dev/null +++ b/Documentation/gpu/intel-display/psr.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Panel Self Refresh PSR (PSR/SRD) +================================ + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c + :doc: Panel Self Refresh (PSR/SRD) + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c + :internal: diff --git a/Documentation/gpu/intel-display/snps-phy.rst b/Documentation/gpu/intel-display/snps-phy.rst new file mode 100644 index 0000000000000..c9e333fa7f62e --- /dev/null +++ b/Documentation/gpu/intel-display/snps-phy.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Synopsis PHY support +==================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_snps_phy.c + :doc: Synopsis PHY support diff --git a/Documentation/gpu/intel-display/vbt.rst b/Documentation/gpu/intel-display/vbt.rst new file mode 100644 index 0000000000000..be69f7fd7b396 --- /dev/null +++ b/Documentation/gpu/intel-display/vbt.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Video BIOS Table (VBT) +====================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c + :doc: Video BIOS Table (VBT) + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c + :internal: + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_vbt_defs.h + :internal: diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index d8f519693fc2c..64074ac22d9b7 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -16,6 +16,8 @@ found in current kernels. [Insert diagram of typical DRM stack here] +.. contents:: + Style Guidelines ================ diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst index eaea40eb725b7..9c07459406590 100644 --- a/Documentation/gpu/komeda-kms.rst +++ b/Documentation/gpu/komeda-kms.rst @@ -367,7 +367,7 @@ So, one KMS-Obj represents a sub-pipeline of komeda resources. So, for komeda, we treat KMS crtc/plane/connector as users of pipeline and component, and at any one time a pipeline/component only can be used by one user. And pipeline/component will be treated as private object of DRM-KMS; the -state will be managed by drm_atomic_state as well. +state will be managed by drm_atomic_commit as well. How to map plane to Layer(input) pipeline ----------------------------------------- @@ -416,8 +416,8 @@ Add :c:type:`drm_private_obj` to :c:type:`komeda_component`, :c:type:`komeda_pip ... } -Tracking component_state/pipeline_state by drm_atomic_state ------------------------------------------------------------ +Tracking component_state/pipeline_state by drm_atomic_commit +------------------------------------------------------------ Add :c:type:`drm_private_state` and user to :c:type:`komeda_component_state`, :c:type:`komeda_pipeline_state` @@ -454,7 +454,7 @@ similar, usually including the following steps: put the data flow into next stage. Setup 2: check user_state with component features and capabilities to see if requirements can be met; if not, return fail. - Setup 3: get component_state from drm_atomic_state, and try set to set + Setup 3: get component_state from drm_atomic_commit, and try set to set user to component; fail if component has been assigned to another user already. Setup 3: configure the component_state, like set its input component, diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index ef19b0ba2a3ea..26a7ebe6fb445 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -18,23 +18,9 @@ host such documentation: .. toctree:: - gpusvm.rst - -.. toctree:: - - i915_gem_lmem.rst - -.. toctree:: - - i915_scheduler.rst - -.. toctree:: - - i915_small_bar.rst - -.. toctree:: - - i915_vm_bind.rst - -.. toctree:: - color_pipeline.rst
\ No newline at end of file + gpusvm + i915_gem_lmem + i915_scheduler + i915_small_bar + i915_vm_bind + color_pipeline diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index bc9f14c8a2ec2..cdddf8db35f53 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -152,29 +152,6 @@ Contact: Simona Vetter, respective driver maintainers Level: Advanced -Rename drm_atomic_state ------------------------ - -The KMS framework uses two slightly different definitions for the ``state`` -concept. For a given object (plane, CRTC, encoder, etc., so -``drm_$OBJECT_state``), the state is the entire state of that object. However, -at the device level, ``drm_atomic_state`` refers to a state update for a -limited number of objects. - -The state isn't the entire device state, but only the full state of some -objects in that device. This is confusing to newcomers, and -``drm_atomic_state`` should be renamed to something clearer like -``drm_atomic_commit``. - -In addition to renaming the structure itself, it would also imply renaming some -related functions (``drm_atomic_state_alloc``, ``drm_atomic_state_get``, -``drm_atomic_state_put``, ``drm_atomic_state_init``, -``__drm_atomic_state_free``, etc.). - -Contact: Maxime Ripard <mripard@kernel.org> - -Level: Advanced - Fallout from atomic KMS ----------------------- diff --git a/Documentation/gpu/xe/index.rst b/Documentation/gpu/xe/index.rst index bc432c95d1a35..665c0e93601c5 100644 --- a/Documentation/gpu/xe/index.rst +++ b/Documentation/gpu/xe/index.rst @@ -1,5 +1,7 @@ .. SPDX-License-Identifier: (GPL-2.0+ OR MIT) +.. _drm/xe: + ======================= drm/xe Intel GFX Driver ======================= @@ -8,6 +10,9 @@ The drm/xe driver supports some future GFX cards with rendering, display, compute and media. Support for currently available platforms like TGL, ADL, DG2, etc is provided to prototype the driver. +The display, or :ref:`drm-kms`, support for drm/xe is provided by +:ref:`drm/intel-display`, and shared with :ref:`drm/i915 <drm/i915>`. + .. toctree:: :titlesonly: @@ -29,3 +34,4 @@ DG2, etc is provided to prototype the driver. xe_device xe-drm-usage-stats.rst xe_configfs + xe_gt_stats diff --git a/Documentation/gpu/xe/xe_gt_stats.rst b/Documentation/gpu/xe/xe_gt_stats.rst new file mode 100644 index 0000000000000..5ff806abaddb8 --- /dev/null +++ b/Documentation/gpu/xe/xe_gt_stats.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +================ +Xe GT Statistics +================ + +.. kernel-doc:: drivers/gpu/drm/xe/xe_gt_stats.c + :doc: Xe GT Statistics + +.. kernel-doc:: drivers/gpu/drm/xe/xe_gt_stats_types.h + :internal: diff --git a/Documentation/hwmon/sy7636a-hwmon.rst b/Documentation/hwmon/sy7636a-hwmon.rst index 0143ce0e5db76..03d866aba6e81 100644 --- a/Documentation/hwmon/sy7636a-hwmon.rst +++ b/Documentation/hwmon/sy7636a-hwmon.rst @@ -22,5 +22,5 @@ The following sensors are supported sysfs-Interface --------------- -temp0_input +temp1_input - Temperature of external NTC (milli-degree C) diff --git a/Documentation/hwmon/yogafan.rst b/Documentation/hwmon/yogafan.rst index c553a381f772e..68761947a1a83 100644 --- a/Documentation/hwmon/yogafan.rst +++ b/Documentation/hwmon/yogafan.rst @@ -135,4 +135,4 @@ References 4. **Lenovo IdeaPad Laptop Driver:** Reference for DMI-based hardware feature gating in Lenovo laptops. - https://github.com/torvalds/linux/blob/master/drivers/platform/x86/ideapad-laptop.c + https://github.com/torvalds/linux/blob/master/drivers/platform/x86/lenovo/ideapad-laptop.c diff --git a/Documentation/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml index 57f59fe23e3f8..4ea31e8fc4d19 100644 --- a/Documentation/netlink/genetlink-c.yaml +++ b/Documentation/netlink/genetlink-c.yaml @@ -69,6 +69,15 @@ properties: header: description: For C-compatible languages, header which already defines this value. type: string + scope: + description: | + Visibility of this definition. "uapi" (default) renders into + the uAPI header, "kernel" renders into the kernel-side + generated header, "user" renders into the user-side + generated header. When combined with `header:`, the + definition is not rendered, and the named header is + included only by code matching the scope. + enum: [ uapi, kernel, user ] type: enum: [ const, enum, flags ] doc: diff --git a/Documentation/netlink/genetlink-legacy.yaml b/Documentation/netlink/genetlink-legacy.yaml index 66fb8653a3442..f9c44747729ae 100644 --- a/Documentation/netlink/genetlink-legacy.yaml +++ b/Documentation/netlink/genetlink-legacy.yaml @@ -83,6 +83,15 @@ properties: header: description: For C-compatible languages, header which already defines this value. type: string + scope: + description: | + Visibility of this definition. "uapi" (default) renders into + the uAPI header, "kernel" renders into the kernel-side + generated header, "user" renders into the user-side + generated header. When combined with `header:`, the + definition is not rendered, and the named header is + included only by code matching the scope. + enum: [ uapi, kernel, user ] type: enum: [ const, enum, flags, struct ] # Trim doc: diff --git a/Documentation/netlink/genetlink.yaml b/Documentation/netlink/genetlink.yaml index a1194d5d93fc3..d3f3f3399ddf8 100644 --- a/Documentation/netlink/genetlink.yaml +++ b/Documentation/netlink/genetlink.yaml @@ -55,6 +55,15 @@ properties: header: description: For C-compatible languages, header which already defines this value. type: string + scope: + description: | + Visibility of this definition. "uapi" (default) renders into + the uAPI header, "kernel" renders into the kernel-side + generated header, "user" renders into the user-side + generated header. When combined with `header:`, the + definition is not rendered, and the named header is + included only by code matching the scope. + enum: [ uapi, kernel, user ] type: enum: [ const, enum, flags ] doc: diff --git a/Documentation/netlink/netlink-raw.yaml b/Documentation/netlink/netlink-raw.yaml index dd98dda55bd0f..4c436b59a34be 100644 --- a/Documentation/netlink/netlink-raw.yaml +++ b/Documentation/netlink/netlink-raw.yaml @@ -87,6 +87,15 @@ properties: header: description: For C-compatible languages, header which already defines this value. type: string + scope: + description: | + Visibility of this definition. "uapi" (default) renders into + the uAPI header, "kernel" renders into the kernel-side + generated header, "user" renders into the user-side + generated header. When combined with `header:`, the + definition is not rendered, and the named header is + included only by code matching the scope. + enum: [ uapi, kernel, user ] type: enum: [ const, enum, flags, struct ] # Trim doc: diff --git a/Documentation/netlink/specs/drm_ras.yaml b/Documentation/netlink/specs/drm_ras.yaml index 79af25dac3c57..e113056f8c016 100644 --- a/Documentation/netlink/specs/drm_ras.yaml +++ b/Documentation/netlink/specs/drm_ras.yaml @@ -99,7 +99,7 @@ operations: flags: [admin-perm] do: request: - attributes: + attributes: &id-attrs - node-id - error-id reply: @@ -113,3 +113,14 @@ operations: - node-id reply: attributes: *errorinfo + - + name: clear-error-counter + doc: >- + Clear error counter for a given node. + The request includes the error-id and node-id of the + counter to be cleared. + attribute-set: error-counter-attrs + flags: [admin-perm] + do: + request: + attributes: *id-attrs diff --git a/Documentation/netlink/specs/net_shaper.yaml b/Documentation/netlink/specs/net_shaper.yaml index 3f2ad772b64b1..de01f922040a5 100644 --- a/Documentation/netlink/specs/net_shaper.yaml +++ b/Documentation/netlink/specs/net_shaper.yaml @@ -34,6 +34,11 @@ doc: | definitions: - + type: const + name: max-handle-id + value: 0x3fffffe + scope: kernel + - type: enum name: scope doc: Defines the shaper @id interpretation. @@ -140,6 +145,8 @@ attribute-sets: - name: id type: u32 + checks: + max: max-handle-id doc: | Numeric identifier of a shaper. The id semantic depends on the scope. For @queue scope it's the queue id and for @node diff --git a/Documentation/netlink/specs/psp.yaml b/Documentation/netlink/specs/psp.yaml index 100c36cda8e5d..bfcd6e4ecb850 100644 --- a/Documentation/netlink/specs/psp.yaml +++ b/Documentation/netlink/specs/psp.yaml @@ -188,6 +188,7 @@ operations: name: dev-set doc: Set the configuration of a PSP device. attribute-set: dev + flags: [admin-perm] do: request: attributes: @@ -207,6 +208,7 @@ operations: name: key-rotate doc: Rotate the device key. attribute-set: dev + flags: [admin-perm] do: request: attributes: diff --git a/Documentation/networking/device_drivers/ethernet/3com/3c509.rst b/Documentation/networking/device_drivers/ethernet/3com/3c509.rst new file mode 100644 index 0000000000000..a8c5e5e6841d4 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/3com/3c509.rst @@ -0,0 +1,249 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================================= +Linux and the 3Com EtherLink III Series Ethercards (driver v1.18c and higher) +============================================================================= + +This file contains the instructions and caveats for v1.18c and higher versions +of the 3c509 driver. You should not use the driver without reading this file. + +release 1.0 + +28 February 2002 + +Current maintainer (corrections to): + Maciej W. Rozycki <macro@orcam.me.uk> + +Introduction +============ + +The following are notes and information on using the 3Com EtherLink III series +ethercards in Linux. These cards are commonly known by the most widely-used +card's 3Com model number, 3c509. They are all 10mb/s ISA-bus cards and shouldn't +be (but sometimes are) confused with the similarly-numbered PCI-bus "3c905" +(aka "Vortex" or "Boomerang") series. Kernel support for the 3c509 family is +provided by the module 3c509.c, which has code to support all of the following +models: + + - 3c509 (original ISA card) + - 3c509B (later revision of the ISA card; supports full-duplex) + - 3c589 (PCMCIA) + - 3c589B (later revision of the 3c589; supports full-duplex) + - 3c579 (EISA) + +Large portions of this documentation were heavily borrowed from the guide +written the original author of the 3c509 driver, Donald Becker. The master +copy of that document, which contains notes on older versions of the driver, +currently resides on Scyld web server: http://www.scyld.com/. + + +Special Driver Features +======================= + +Overriding card settings + +The driver allows boot- or load-time overriding of the card's detected IOADDR, +IRQ, and transceiver settings, although this capability shouldn't generally be +needed except to enable full-duplex mode (see below). An example of the syntax +for LILO parameters for doing this:: + + ether=10,0x310,3,0x3c509,eth0 + +This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and +transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts +with other card types when overriding the I/O address. When the driver is +loaded as a module, only the IRQ may be overridden. For example, +setting two cards to IRQ10 and IRQ11 is done by using the irq module +option:: + + options 3c509 irq=10,11 + + +Full-duplex mode +================ + +The v1.18c driver added support for the 3c509B's full-duplex capabilities. +In order to enable and successfully use full-duplex mode, three conditions +must be met: + +(a) You must have a Etherlink III card model whose hardware supports full- +duplex operations. Currently, the only members of the 3c509 family that are +positively known to support full-duplex are the 3c509B (ISA bus) and 3c589B +(PCMCIA) cards. Cards without the "B" model designation do *not* support +full-duplex mode; these include the original 3c509 (no "B"), the original +3c589, the 3c529 (MCA bus), and the 3c579 (EISA bus). + +(b) You must be using your card's 10baseT transceiver (i.e., the RJ-45 +connector), not its AUI (thick-net) or 10base2 (thin-net/coax) interfaces. +AUI and 10base2 network cabling is physically incapable of full-duplex +operation. + +(c) Most importantly, your 3c509B must be connected to a link partner that is +itself full-duplex capable. This is almost certainly one of two things: a full- +duplex-capable Ethernet switch (*not* a hub), or a full-duplex-capable NIC on +another system that's connected directly to the 3c509B via a crossover cable. + +Full-duplex mode can be enabled using 'ethtool'. + +.. warning:: + + Extremely important caution concerning full-duplex mode + + Understand that the 3c509B's hardware's full-duplex support is much more + limited than that provide by more modern network interface cards. Although + at the physical layer of the network it fully supports full-duplex operation, + the card was designed before the current Ethernet auto-negotiation (N-way) + spec was written. This means that the 3c509B family ***cannot and will not + auto-negotiate a full-duplex connection with its link partner under any + circumstances, no matter how it is initialized***. If the full-duplex mode + of the 3c509B is enabled, its link partner will very likely need to be + independently _forced_ into full-duplex mode as well; otherwise various nasty + failures will occur - at the very least, you'll see massive numbers of packet + collisions. This is one of very rare circumstances where disabling auto- + negotiation and forcing the duplex mode of a network interface card or switch + would ever be necessary or desirable. + + +Available Transceiver Types +=========================== + +For versions of the driver v1.18c and above, the available transceiver types are: + +== ========================================================================= +0 transceiver type from EEPROM config (normally 10baseT); force half-duplex +1 AUI (thick-net / DB15 connector) +2 (undefined) +3 10base2 (thin-net == coax / BNC connector) +4 10baseT (RJ-45 connector); force half-duplex mode +8 transceiver type and duplex mode taken from card's EEPROM config settings +12 10baseT (RJ-45 connector); force full-duplex mode +== ========================================================================= + +Prior to driver version 1.18c, only transceiver codes 0-4 were supported. Note +that the new transceiver codes 8 and 12 are the *only* ones that will enable +full-duplex mode, no matter what the card's detected EEPROM settings might be. +This insured that merely upgrading the driver from an earlier version would +never automatically enable full-duplex mode in an existing installation; +it must always be explicitly enabled via one of these code in order to be +activated. + +The transceiver type can be changed using 'ethtool'. + + +Interpretation of error messages and common problems +---------------------------------------------------- + +Error Messages +^^^^^^^^^^^^^^ + +eth0: Infinite loop in interrupt, status 2011. +These are "mostly harmless" message indicating that the driver had too much +work during that interrupt cycle. With a status of 0x2011 you are receiving +packets faster than they can be removed from the card. This should be rare +or impossible in normal operation. Possible causes of this error report are: + + - a "green" mode enabled that slows the processor down when there is no + keyboard activity. + + - some other device or device driver hogging the bus or disabling interrupts. + Check /proc/interrupts for excessive interrupt counts. The timer tick + interrupt should always be incrementing faster than the others. + +No received packets +^^^^^^^^^^^^^^^^^^^ + +If a 3c509, 3c562 or 3c589 can successfully transmit packets, but never +receives packets (as reported by /proc/net/dev or 'ifconfig') you likely +have an interrupt line problem. Check /proc/interrupts to verify that the +card is actually generating interrupts. If the interrupt count is not +increasing you likely have a physical conflict with two devices trying to +use the same ISA IRQ line. The common conflict is with a sound card on IRQ10 +or IRQ5, and the easiest solution is to move the 3c509 to a different +interrupt line. If the device is receiving packets but 'ping' doesn't work, +you have a routing problem. + +Tx Carrier Errors Reported in /proc/net/dev +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + +If an EtherLink III appears to transmit packets, but the "Tx carrier errors" +field in /proc/net/dev increments as quickly as the Tx packet count, you +likely have an unterminated network or the incorrect media transceiver selected. + +3c509B card is not detected on machines with an ISA PnP BIOS. +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +While the updated driver works with most PnP BIOS programs, it does not work +with all. This can be fixed by disabling PnP support using the 3Com-supplied +setup program. + +3c509 card is not detected on overclocked machines +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Increase the delay time in id_read_eeprom() from the current value, 500, +to an absurdly high value, such as 5000. + + +Decoding Status and Error Messages +---------------------------------- + + +The bits in the main status register are: + +===== ====================================== +value description +===== ====================================== +0x01 Interrupt latch +0x02 Tx overrun, or Rx underrun +0x04 Tx complete +0x08 Tx FIFO room available +0x10 A complete Rx packet has arrived +0x20 A Rx packet has started to arrive +0x40 The driver has requested an interrupt +0x80 Statistics counter nearly full +===== ====================================== + +The bits in the transmit (Tx) status word are: + +===== ============================================ +value description +===== ============================================ +0x02 Out-of-window collision. +0x04 Status stack overflow (normally impossible). +0x08 16 collisions. +0x10 Tx underrun (not enough PCI bus bandwidth). +0x20 Tx jabber. +0x40 Tx interrupt requested. +0x80 Status is valid (this should always be set). +===== ============================================ + + +When a transmit error occurs the driver produces a status message such as:: + + eth0: Transmit error, Tx status register 82 + +The two values typically seen here are: + +0x82 +^^^^ + +Out of window collision. This typically occurs when some other Ethernet +host is incorrectly set to full duplex on a half duplex network. + +0x88 +^^^^ + +16 collisions. This typically occurs when the network is exceptionally busy +or when another host doesn't correctly back off after a collision. If this +error is mixed with 0x82 errors it is the result of a host incorrectly set +to full duplex (see above). + +Both of these errors are the result of network problems that should be +corrected. They do not represent driver malfunction. + + +Revision history (this file) +============================ + +28Feb02 v1.0 DR New; major portions based on Becker original 3c509 docs + diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst index 64621c21fd786..1d25be493ae9d 100644 --- a/Documentation/networking/device_drivers/ethernet/index.rst +++ b/Documentation/networking/device_drivers/ethernet/index.rst @@ -10,6 +10,7 @@ Contents: .. toctree:: :maxdepth: 2 + 3com/3c509 3com/vortex amazon/ena altera/altera_tse diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index dbd6ea16aca70..aa7c959a52b87 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -86,6 +86,7 @@ regressions and security problems. debugging/index handling-regressions security-bugs + threat-model cve embargoed-hardware-issues diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst index 27b028e858610..3c51ddde31dd9 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -66,6 +66,42 @@ In addition, the following information are highly desirable: the issue appear. It is useful to share them, as they can be helpful to keep end users protected during the time it takes them to apply the fix. +What qualifies as a security bug +-------------------------------- + +It is important that most bugs are handled publicly so as to involve the widest +possible audience and find the best solution. By nature, bugs that are handled +in closed discussions between a small set of participants are less likely to +produce the best possible fix (e.g., risk of missing valid use cases, limited +testing abilities). + +It turns out that the majority of the bugs reported via the security team are +just regular bugs that have been improperly qualified as security bugs due to +a lack of awareness of the Linux kernel's threat model, as described in +Documentation/process/threat-model.rst, and ought to have been sent through +the normal channels described in Documentation/admin-guide/reporting-issues.rst +instead. + +The security list exists for urgent bugs that grant an attacker a capability +they are not supposed to have on a correctly configured production system, and +can be easily exploited, representing an imminent threat to many users. Before +reporting, consider whether the issue actually crosses a trust boundary on such +a system. + +**If you resorted to AI assistance to identify a bug, you must treat it as +public**. While you may have valid reasons to believe it is not, the security +team's experience shows that bugs discovered this way systematically surface +simultaneously across multiple researchers, often on the same day. In this +case, do not publicly share a reproducer, as this could cause unintended harm; +just mention that one is available and maintainers might ask for it privately +if they need it. + +If you are unsure whether an issue qualifies, err on the side of reporting +privately: the security team would rather triage a borderline report than miss +a real vulnerability. Reporting ordinary bugs to the security list, however, +does not make them move faster and consumes triage capacity that other reports +need. + Identifying contacts -------------------- @@ -74,7 +110,7 @@ affected subsystem's maintainers and Cc: the Linux kernel security team. Do not send it to a public list at this stage, unless you have good reasons to consider the issue as being public or trivial to discover (e.g. result of a widely available automated vulnerability scanning tool that can be repeated by -anyone). +anyone, or use of AI-based tools). If you're sending a report for issues affecting multiple parts in the kernel, even if they're fairly similar issues, please send individual messages (think @@ -131,6 +167,64 @@ the Linux kernel security team only. Your message will be triaged, and you will receive instructions about whom to contact, if needed. Your message may equally be forwarded as-is to the relevant maintainers. +Responsible use of AI to find bugs +---------------------------------- + +A significant fraction of bug reports submitted to the security team are +actually the result of code reviews assisted by AI tools. While this can be an +efficient means to find bugs in rarely explored areas, it causes an overload on +maintainers, who are sometimes forced to ignore such reports due to their poor +quality or accuracy. As such, reporters must be particularly cautious about a +number of points which tend to make these reports needlessly difficult to +handle: + + * **Length**: AI-generated reports tend to be excessively long, containing + multiple sections and excessive detail. This makes it difficult to spot + important information such as affected files, versions, and impact. Please + ensure that a clear summary of the problem and all critical details are + presented first. Do not require triage engineers to scan multiple pages of + text. Configure your tools to produce concise, human-style reports. + + * **Formatting**: Most AI-generated reports are littered with Markdown tags. + These decorations complicate the search for important information and do + not survive the quoting processes involved in forwarding or replying. + Please **always convert your report to plain text** without any formatting + decorations before sending it. + + * **Impact Evaluation**: Many AI-generated reports lack an understanding + of the kernel's threat model (see Documentation/process/threat-model.rst) + and go to great lengths inventing theoretical consequences. This adds + noise and complicates triage. Please stick to verifiable facts (e.g., + "this bug permits any user to gain CAP_NET_ADMIN") without enumerating + speculative implications. Have your tool read this documentation as + part of the evaluation process. + + * **Reproducer**: AI-based tools are often capable of generating reproducers. + Please always ensure your tool provides one and **test it thoroughly**. If + the reproducer does not work, or if the tool cannot produce one, the + validity of the report should be seriously questioned. Note that since the + report will be posted to a public list, the reproducer should only be + shared upon maintainers' request. + + * **Propose a Fix**: Many AI tools are actually better at writing code than + evaluating it. Please ask your tool to propose a fix and **test it** before + reporting the problem. If the fix cannot be tested because it relies on + rare hardware or almost extinct network protocols, the issue is likely not + a security bug. In any case, if a fix is proposed, it must adhere to + Documentation/process/submitting-patches.rst and include a 'Fixes:' tag + designating the commit that introduced the bug. + +Failure to consider these points exposes your report to the risk of being +ignored. + +Use common sense when evaluating the report. If the affected file has not been +touched for more than one year and is maintained by a single individual, it is +likely that usage has declined and exposed users are virtually non-existent +(e.g., drivers for very old hardware, obsolete filesystems). In such cases, +there is no need to consume a maintainer's time with an unimportant report. If +the issue is clearly trivial and publicly discoverable, you should report it +directly to the public mailing lists. + Sending the report ------------------ @@ -148,7 +242,15 @@ run additional tests. Reports where the reporter does not respond promptly or cannot effectively discuss their findings may be abandoned if the communication does not quickly improve. -The report must be sent to maintainers, with the security team in ``Cc:``. +The report must be sent to maintainers. If there are two or fewer +recipients in your message, you must also always Cc: the Linux kernel +security team who will ensure the message is delivered to the proper +people, and will be able to assist small maintainer teams with processes +they may not be familiar with. For larger teams, Cc: the Linux kernel +security team for your first few reports or when seeking specific help, +such as when resending a message which got no response within a week. +Once you have become comfortable with the process for a few reports, it is +no longer necessary to Cc: the security list when sending to large teams. The Linux kernel security team can be contacted by email at <security@kernel.org>. This is a private list of security officers who will help verify the bug report and assist developers working on a fix. diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst new file mode 100644 index 0000000000000..f177b8d3c1caf --- /dev/null +++ b/Documentation/process/threat-model.rst @@ -0,0 +1,235 @@ +The Linux Kernel threat model +============================= + +There are a lot of assumptions regarding what the kernel does and does not +protect against. These assumptions tend to cause confusion for bug reports +(:doc:`security-related ones <security-bugs>` vs :doc:`non-security ones +<../admin-guide/reporting-issues>`), and can complicate security enforcement +when the responsibilities for some boundaries is not clear between the kernel, +distros, administrators and users. + +This document tries to clarify the responsibilities of the kernel in this +domain. + +The kernel's responsibilities +----------------------------- + +The kernel abstracts access to local hardware resources and to remote systems +in a way that allows multiple local users to get a fair share of the available +resources granted to them, and, when the underlying hardware permits, to assign +a level of confidentiality to their communications and to the data they are +processing or storing. + +The kernel assumes that the underlying hardware behaves according to its +specifications. This includes the integrity of the CPU's instruction set, the +transparency of the branch prediction unit and the cache units, the consistency +of the Memory Management Unit (MMU), the isolation of DMA-capable peripherals +(e.g., via IOMMU), state transitions in controllers, ranges of values read from +registers, the respect of documented hardware limitations, etc. + +When hardware fails to maintain its specified isolation (e.g., CPU bugs, +side-channels, hardware response to unexpected inputs), the kernel will usually +attempt to implement reasonable mitigations. These are best-effort measures +intended to reduce the attack surface or elevate the cost of an attack within +the limits of the hardware's facilities; they do not constitute a +kernel-provided safety guarantee. + +Users always perform their activities under the authority of an administrator +who is able to grant or deny various types of permissions that may affect how +users benefit from available resources, or the level of confidentiality of +their activities. Administrators may also delegate all or part of their own +permissions to some users, particularly via capabilities but not only. All this +is performed via configuration (sysctl, file-system permissions etc). + +The Linux Kernel applies a certain collection of default settings that match +its threat model. Distros have their own threat model and will come with their +own configuration presets, that the administrator may have to adjust to better +suit their expectations (relax or restrict). + +By default, the Linux Kernel guarantees the following protections when running +on common processors featuring privilege levels and memory management units: + +* **User-based isolation**: an unprivileged user may restrict access to their + own data from other unprivileged users running on the same system. This + includes: + + * stored data, via file system permissions + * in-memory data (pages are not accessible by default to other users) + * process activity (ptrace is not permitted to other users) + * inter-process communication (other users may not observe data exchanged via + UNIX domain sockets or other IPC mechanisms). + * network communications within the same or with other systems + +* **Capability-based protection**: + + * users not having elevated capabilities (including but not limited to + CAP_SYS_ADMIN) may not alter the + kernel's configuration, memory nor state, change other users' view of the + file system layout, grant any user capabilities they do not have, nor + affect the system's availability (shutdown, reboot, panic, hang, or making + the system unresponsive via unbounded resource exhaustion). + * users not having the ``CAP_NET_ADMIN`` capability may not alter the network + configuration, intercept nor spoof network communications from other users + nor systems. + * users not having ``CAP_SYS_PTRACE`` may not observe other users' processes + activities. + +When ``CONFIG_USER_NS`` is set, the kernel also permits unprivileged users to +create their own user namespace in which they have all capabilities, but with a +number of restrictions (they may not perform actions that have impacts on the +initial user namespace, such as changing time, loading modules or mounting +block devices). Please refer to ``user_namespaces(7)`` for more details, the +possibilities of user namespaces are not covered in this document. + +The kernel also offers a lot of troubleshooting and debugging facilities, which +can constitute attack vectors when placed in wrong hands. While some of them +are designed to be accessible to regular local users with a low risk (e.g. +kernel logs via ``/proc/kmsg``), some would expose enough information to +represent a risk in most places and the decision to expose them is under the +administrator's responsibility (perf events, traces), and others are not +designed to be accessed by non-privileged users (e.g. debugfs). Access to these +facilities by a user who has been explicitly granted permission by an +administrator does not constitute a security breach. + +Bugs that permit to violate the principles above constitute security breaches. +However, bugs that permit one violation only once another one was already +achieved are only weaknesses. The kernel applies a number of self-protection +measures whose purpose is to avoid crossing a security boundary when certain +classes of bugs are found, but a failure of these extra protections do not +constitute a vulnerability alone. + +What does not constitute a security bug +--------------------------------------- + +In the Linux kernel's threat model, the following classes of problems are +**NOT** considered as Linux Kernel security bugs. However, when it is believed +that the kernel could do better, they should be reported, so that they can be +reviewed and fixed where reasonably possible, but they will be handled as any +regular bug: + +* **Configuration**: + + * outdated kernels and particularly end-of-life branches are out of the scope + of the kernel's threat model: administrators are responsible for keeping + their system up to date. For a bug to qualify as a security bug, it must be + demonstrated that it affects actively maintained versions. + + * build-level: changes to the kernel configuration that are explicitly + documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or + targeted at developers only. + + * OS-level: changes to command line parameters, sysctls, filesystem + permissions, user capabilities, exposure of privileged interfaces, that + explicitly increase exposure by either offering non-default access to + unprivileged users, or reduce the kernel's ability to enforce some + protections or mitigations. Example: write access to procfs or debugfs. + + * issues triggered only when using features intended for development or + debugging (e.g., LOCKDEP, KASAN, FAULT_INJECTION): these features are known + to introduce overhead and potential instability and are not intended for + production use. + + * issues affecting drivers exposed under CONFIG_STAGING, as well as features + marked EXPERIMENTAL in the configuration. + + * loading of explicitly insecure/broken/staging modules, and generally any + using any subsystem marked as experimental or not intended for production + use. + + * running out-of-tree modules or unofficial kernel forks; these should be + reported to the relevant vendor. + +* **Excess of initial privileges**: + + * actions performed by a user already possessing the privileges required to + perform that action or modify that state (e.g. ``CAP_SYS_ADMIN``, + ``CAP_NET_ADMIN``, ``CAP_SYS_RAWIO``, ``CAP_SYS_MODULE`` with no further + boundary being crossed). + + * actions performed in user namespace that do not bypass the restrictions + imposed to the initial user (e.g. ptrace usage, signal delivery, resource + usage, access to FS/device/sysctl/memory, network binding, system/network + configuration etc). + + * anything performed by the root user in the initial namespace (e.g. kernel + oops when writing to a privileged device). + +* **Out of production use**: + + This covers theoretical/probabilistic attacks that rely on laboratory + conditions with zero system noise, or those requiring an unrealistic number + of attempts (e.g., billions of trials) that would be detected by standard + system monitoring long before success, such as: + + * prediction of random numbers that only works in a totally silent + environment (such as IP ID, TCP ports or sequence numbers that can only be + guessed in a lab). + + * activity observation and information leaks based on probabilistic + approaches that are prone to measurement noise and not realistically + reproducible on a production system. + + * issues that can only be triggered by heavy attacks (e.g. brute force) whose + impact on the system makes it unlikely or impossible to remain undetected + before they succeed (e.g. consuming all memory before succeeding). + + * problems seen only under development simulators, emulators, or combinations + that do not exist on real systems at the time of reporting (issues + involving tens of millions of threads, tens of thousands of CPUs, + unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds. + + * issues whose reproduction requires hardware modification or emulation, + including fake USB devices that pretend to be another one. + + * as well as issues that can be triggered at a cost that is orders of + magnitude higher than the expected benefits (e.g. fully functional keyboard + emulator only to retrieve 7 uninitialized bytes in a structure, or + brute-force method involving millions of connection attempts to guess a + port number). + +* **Hardening failures**: + + * ability to bypass some of the kernel's hardening measures with no + demonstrable exploit path (e.g. ASLR bypass, events timing or probing with + no demonstrable consequence). These are just weaknesses, not + vulnerabilities. + + * missing argument checks and failure to report certain errors with no + immediate consequence. + +* **Random information leaks**: + + This concerns information leaks of small data parts that happen to be there + and that cannot be chosen by the attacker, or face access restrictions: + + * structure padding reported by syscalls or other interfaces. + + * identifiers, partial data, non-terminated strings reported in error + messages. + + * Leaks of kernel memory addresses/pointers do not constitute an immediately + exploitable vector and are not security bugs, though they must be reported + and fixed. + +* **Crafted file system images**: + + * bugs triggered by mounting a corrupted or maliciously crafted file system + image are generally not security bugs, as the kernel assumes the underlying + storage media is under the administrator's control, unless the filesystem + driver is specifically documented as being hardened against untrusted media. + + * issues that are resolved, mitigated, or detected by running a filesystem + consistency check (fsck) on the image prior to mounting. + +* **Physical access**: + + Issues that require physical access to the machine, hardware modification, or + the use of specialized hardware (e.g., logic analyzers, DMA-attack tools over + PCI-E/Thunderbolt) are out of scope unless the system is explicitly + configured with technologies meant to defend against such attacks + (e.g. IOMMU). + +* **Functional and performance regressions**: + + Any issue that can be mitigated by setting proper permissions and limits + doesn't qualify as a security bug. diff --git a/Documentation/sound/codecs/cs35l56.rst b/Documentation/sound/codecs/cs35l56.rst index d5363b08f5152..b3f8c1c238518 100644 --- a/Documentation/sound/codecs/cs35l56.rst +++ b/Documentation/sound/codecs/cs35l56.rst @@ -40,7 +40,7 @@ There are two drivers in the kernel *For systems using SoundWire*: sound/soc/codecs/cs35l56.c and associated files -*For systems using HDA*: sound/pci/hda/cs35l56_hda.c +*For systems using HDA*: sound/hda/codecs/side-codecs/cs35l56_hda.c Firmware ======== diff --git a/Documentation/userspace-api/rseq.rst b/Documentation/userspace-api/rseq.rst index 3cd27a3c7c7e5..8549a6c61531c 100644 --- a/Documentation/userspace-api/rseq.rst +++ b/Documentation/userspace-api/rseq.rst @@ -24,6 +24,97 @@ Quick access to CPU number, node ID Allows to implement per CPU data efficiently. Documentation is in code and selftests. :( +Optimized RSEQ V2 +----------------- + +On architectures which utilize the generic entry code and generic TIF bits +the kernel supports runtime optimizations for RSEQ, which also enable +enhanced features like scheduler time slice extensions. + +To enable them a task has to register the RSEQ region with at least the +length advertised by getauxval(AT_RSEQ_FEATURE_SIZE). + +If existing binaries register with RSEQ_ORIG_SIZE (32 bytes), the kernel +keeps the legacy low performance mode enabled to fulfil the expectations +of existing users regarding the original RSEQ implementation behaviour. + +The following table documents the ABI and behavioral guarantees of the +legacy and the optimized V2 mode. + +.. list-table:: RSEQ modes + :header-rows: 1 + + * - Nr + - What + + - Legacy + - Optimized V2 + + * - 1 + - The cpu_id_start, cpu_id, node_id and mm_cid fields (User mode read + only) + .. Legacy + - Updated by the kernel unconditionally after each context switch and + before signal delivery + .. Optimized V2 + - Updated by the kernel if and only if they change, i.e. if the task + is migrated or mm_cid changes + + * - 2 + - The rseq_cs critical section field + .. Legacy + - Evaluated and handled unconditionally after each context switch and + before signal delivery + .. Optimized V2 + - Evaluated and handled conditionally only when user space was + interrupted and was scheduled out or before delivering a signal in + the interrupted context. + + * - 3 + - Read only fields + .. Legacy + - No strict enforcement except in debug mode + .. Optimized V2 + - Strict enforcement + + * - 4 + - membarrier(...RSEQ) + .. Legacy + - All running threads of the process are interrupted and the ID fields + are rewritten and eventually active critical sections are aborted + before they return to user space. All threads which are scheduled + out whether voluntary or not are covered by #1/#2 above. + .. Optimized V2 + - All running threads of the process are interrupted and eventually + active critical sections are aborted before these threads return to + user space. The ID fields are only updated if changed as a + consequence of the interrupt. All threads which are scheduled out + whether voluntary or not are covered by #1/#2 above. + + * - 5 + - Time slice extensions + .. Legacy + - Not supported + .. Optimized V2 + - Supported + +The legacy mode is obviously less performant as it does unconditional +updates and critical section checks even if not strictly required by the +ABI contract. That can't be changed anymore as some users depend on that +observed behavior, which in turn enables them to violate the ABI and +overwrite the cpu_id_start field for their own purposes. This is obviously +discouraged as it renders RSEQ incompatible with the intended usage and +breaks the expectation of other libraries in the same application. + +The ABI compliant optimized v2 mode, which respects the read only fields, +does not require unconditional updates and therefore is way more +performant. The kernel validates the read only fields for compliance. If +user space modifies them, the process is killed. Compliant usage allows +multiple libraries in the same application to benefit from the RSEQ +functionality without disturbing each other. The ABI compliant optimized v2 +mode also enables extended RSEQ features like time slice extensions. + + Scheduler time slice extensions ------------------------------- @@ -37,7 +128,8 @@ The prerequisites for this functionality are: * Enabled at boot time (default is enabled) - * A rseq userspace pointer has been registered for the thread + * A rseq userspace pointer has been registered for the thread in + optimized V2 mode The thread has to enable the functionality via prctl(2):: diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst index b2395dd4769de..bd04a908a8dbd 100644 --- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst @@ -656,8 +656,8 @@ References See [white-paper]_, [api-spec]_, [amd-apm]_, [kvm-forum]_, and [snp-fw-abi]_ for more info. -.. [white-paper] https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf -.. [api-spec] https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf -.. [amd-apm] https://support.amd.com/TechDocs/24593.pdf (section 15.34) +.. [white-paper] https://docs.amd.com/v/u/en-US/memory-encryption-white-paper +.. [api-spec] https://docs.amd.com/v/u/en-US/55766_PUB_3.24_SEV_API +.. [amd-apm] https://docs.amd.com/v/u/en-US/24593_3.44_APM_Vol2 (section 15.34) .. [kvm-forum] https://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf -.. [snp-fw-abi] https://www.amd.com/system/files/TechDocs/56860.pdf +.. [snp-fw-abi] https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf |