mirrors/linux
2
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-08-23 06:05:48 -04:00
Code Issues Packages Projects Releases Wiki Activity

Merge drm/drm-next into drm-xe-next

Browse Source 
Backmerging to bring in a build error fix to drm-xe-next.

Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
This commit is contained in:
Thomas Hellström
2026-06-04 16:19:59 +02:00
parent b7fb55cc33 527b3f2a48
commit b226489de4
2327 changed files with 160607 additions and 22893 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
.mailmap
View File

@@ -584,6 +584,8 @@ Mayuresh Janorkar <mayur@ti.com>
Md Sadre Alam <quic_mdalam@quicinc.com> <mdalam@codeaurora.org>
Miaoqing Pan <quic_miaoqing@quicinc.com> <miaoqing@codeaurora.org>
Michael Buesch <m@bues.ch>
Michal Grzeschik <mgr@kernel.org> <m.grzeschik@pengutronix.de>
Michal Grzeschik <mgr@kernel.org> <mgr@pengutronix.de>
Michael Riesch <michael.riesch@collabora.com> <michael.riesch@wolfvision.net>
Michal Simek <michal.simek@amd.com> <michal.simek@xilinx.com>
Michel Dänzer <michel@tungstengraphics.com>
@@ -682,6 +684,7 @@ Peter A Jonsson <pj@ludd.ltu.se>
Peter Hilber <peter.hilber@oss.qualcomm.com> <quic_philber@quicinc.com>
Peter Oruba <peter.oruba@amd.com>
Peter Oruba <peter@oruba.de>
Peter Rosin <peda@lysator.liu.se> <peda@axentia.se>
Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> <pierre-louis.bossart@linux.intel.com>
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
Pratyush Yadav <pratyush@kernel.org> <ptyadav@amazon.de>
@@ -856,6 +859,7 @@ Tobias Klauser <tklauser@distanz.ch> <klto@zhaw.ch>
Tobias Klauser <tklauser@distanz.ch> <tklauser@nuerscht.ch>
Tobias Klauser <tklauser@distanz.ch> <tklauser@xenon.tklauser.home>
Todor Tomov <todor.too@gmail.com> <todor.tomov@linaro.org>
Tomasz Jeznach <tomasz.jeznach@linux.dev> <tjeznach@rivosinc.com>
Tony Luck <tony.luck@intel.com>
Trilok Soni <quic_tsoni@quicinc.com> <tsoni@codeaurora.org>
TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>

1
Documentation/.renames.txt
View File

@@ -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

0
Documentation/ABI/obsolete/sysfs-selinux-user → Documentation/ABI/removed/sysfs-selinux-user
View File

6
Documentation/admin-guide/cgroup-v1/memcg_test.rst
View File

@@ -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

10
Documentation/admin-guide/laptops/uniwill-laptop.rst
View File

@@ -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/

11
Documentation/admin-guide/pm/amd-pstate.rst
View File

@@ -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
===========================================

11
Documentation/admin-guide/pm/intel_pstate.rst
View File

@@ -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

8
Documentation/arch/riscv/cmodx.rst
View File

@@ -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
-----------------------

2
Documentation/arch/riscv/zicfilp.rst
View File

@@ -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.

17
Documentation/crypto/krb5.rst
View File

@@ -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
---------------------

43
Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
View File

@@ -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>;
};
};

28
Documentation/devicetree/bindings/display/msm/dp-controller.yaml
View File

@@ -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

2
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
View File

@@ -16,6 +16,7 @@ properties:
- enum:
- qcom,apq8064-dsi-ctrl
- qcom,kaanapali-dsi-ctrl
- qcom,milos-dsi-ctrl
- qcom,msm8226-dsi-ctrl
- qcom,msm8916-dsi-ctrl
- qcom,msm8953-dsi-ctrl
@@ -339,6 +340,7 @@ allOf:
compatible:
contains:
enum:
- qcom,milos-dsi-ctrl
- qcom,msm8998-dsi-ctrl
- qcom,sa8775p-dsi-ctrl
- qcom,sar2130p-dsi-ctrl

30
Documentation/devicetree/bindings/display/msm/gmu.yaml
View File

@@ -300,6 +300,36 @@ allOf:
required:
- qcom,qmp
- if:
properties:
compatible:
contains:
const: qcom,adreno-gmu-810.0
then:
properties:
reg:
items:
- description: Core GMU registers
reg-names:
items:
- const: gmu
clocks:
items:
- description: GPU AHB clock
- description: GMU clock
- description: GPU CX clock
- description: GPU AXI clock
- description: GPU MEMNOC clock
- description: GMU HUB clock
clock-names:
items:
- const: ahb
- const: gmu
- const: cxo
- const: axi
- const: memnoc
- const: hub
- if:
properties:
compatible:

19
Documentation/devicetree/bindings/display/msm/gpu.yaml
View File

@@ -411,6 +411,23 @@ allOf:
- clocks
- clock-names
- if:
properties:
compatible:
contains:
enum:
- qcom,adreno-44010000
- qcom,adreno-44070001
then:
properties:
reg:
minItems: 2
maxItems: 2
reg-names:
minItems: 2
maxItems: 2
- if:
properties:
compatible:
@@ -434,6 +451,8 @@ allOf:
- qcom,adreno-43050a01
- qcom,adreno-43050c01
- qcom,adreno-43051401
- qcom,adreno-44010000
- qcom,adreno-44070001
then: # Starting with A6xx, the clocks are usually defined in the GMU node
properties:

20
Documentation/devicetree/bindings/display/msm/qcom,eliza-mdss.yaml
View File

@@ -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>;

286
Documentation/devicetree/bindings/display/msm/qcom,milos-mdss.yaml Normal file
View File

@@ -0,0 +1,286 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,milos-mdss.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Milos Display MDSS
maintainers:
- Luca Weiss <luca.weiss@fairphone.com>
description:
Milos MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
DPU display controller, DSI and DP interfaces etc.
$ref: /schemas/display/msm/mdss-common.yaml#
properties:
compatible:
const: qcom,milos-mdss
clocks:
items:
- description: Display AHB
- description: Display hf AXI
- description: Display core
iommus:
maxItems: 1
interconnects:
items:
- description: Interconnect path from mdp0 port to the data bus
- description: Interconnect path from CPU to the reg bus
interconnect-names:
items:
- const: mdp0-mem
- const: cpu-cfg
patternProperties:
"^display-controller@[0-9a-f]+$":
type: object
additionalProperties: true
properties:
compatible:
const: qcom,milos-dpu
"^displayport-controller@[0-9a-f]+$":
type: object
additionalProperties: true
properties:
compatible:
const: qcom,milos-dp
"^dsi@[0-9a-f]+$":
type: object
additionalProperties: true
properties:
compatible:
contains:
const: qcom,milos-dsi-ctrl
"^phy@[0-9a-f]+$":
type: object
additionalProperties: true
properties:
compatible:
const: qcom,milos-dsi-phy-4nm
required:
- compatible
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,dsi-phy-28nm.h>
#include <dt-bindings/clock/qcom,milos-dispcc.h>
#include <dt-bindings/clock/qcom,milos-gcc.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/interconnect/qcom,icc.h>
#include <dt-bindings/interconnect/qcom,milos-rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/qcom,rpmhpd.h>
display-subsystem@ae00000 {
compatible = "qcom,milos-mdss";
reg = <0x0ae00000 0x1000>;
reg-names = "mdss";
interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH 0>;
clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
<&gcc GCC_DISP_HF_AXI_CLK>,
<&dispcc DISP_CC_MDSS_MDP_CLK>;
resets = <&dispcc DISP_CC_MDSS_CORE_BCR>;
interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_ALWAYS
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
<&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&cnoc_main SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
interconnect-names = "mdp0-mem",
"cpu-cfg";
power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>;
iommus = <&apps_smmu 0x1c00 0x2>;
interrupt-controller;
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
display-controller@ae01000 {
compatible = "qcom,milos-dpu";
reg = <0x0ae01000 0x8f000>,
<0x0aeb0000 0x3000>;
reg-names = "mdp",
"vbif";
interrupts-extended = <&mdss 0>;
clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
<&dispcc DISP_CC_MDSS_AHB_CLK>,
<&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
<&dispcc DISP_CC_MDSS_MDP_CLK>,
<&dispcc DISP_CC_MDSS_VSYNC_CLK>;
clock-names = "nrt_bus",
"iface",
"lut",
"core",
"vsync";
assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
assigned-clock-rates = <19200000>;
operating-points-v2 = <&mdp_opp_table>;
power-domains = <&rpmhpd RPMHPD_CX>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dpu_intf1_out: endpoint {
remote-endpoint = <&mdss_dsi0_in>;
};
};
};
mdp_opp_table: opp-table {
compatible = "operating-points-v2";
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
required-opps = <&rpmhpd_opp_low_svs>;
};
opp-342000000 {
opp-hz = /bits/ 64 <342000000>;
required-opps = <&rpmhpd_opp_svs>;
};
opp-402000000 {
opp-hz = /bits/ 64 <402000000>;
required-opps = <&rpmhpd_opp_svs_l1>;
};
opp-535000000 {
opp-hz = /bits/ 64 <535000000>;
required-opps = <&rpmhpd_opp_nom>;
};
opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
required-opps = <&rpmhpd_opp_nom_l1>;
};
opp-630000000 {
opp-hz = /bits/ 64 <630000000>;
required-opps = <&rpmhpd_opp_turbo>;
};
};
};
dsi@ae94000 {
compatible = "qcom,milos-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae94000 0x1000>;
reg-names = "dsi_ctrl";
interrupts-extended = <&mdss 4>;
clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
<&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
<&dispcc DISP_CC_MDSS_PCLK0_CLK>,
<&dispcc DISP_CC_MDSS_ESC0_CLK>,
<&dispcc DISP_CC_MDSS_AHB_CLK>,
<&gcc GCC_DISP_HF_AXI_CLK>;
clock-names = "byte",
"byte_intf",
"pixel",
"core",
"iface",
"bus";
assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
<&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
assigned-clock-parents = <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>,
<&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>;
operating-points-v2 = <&mdss_dsi_opp_table>;
power-domains = <&rpmhpd RPMHPD_CX>;
phys = <&mdss_dsi0_phy>;
phy-names = "dsi";
#address-cells = <1>;
#size-cells = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
mdss_dsi0_in: endpoint {
remote-endpoint = <&dpu_intf1_out>;
};
};
port@1 {
reg = <1>;
mdss_dsi0_out: endpoint {
};
};
};
mdss_dsi_opp_table: opp-table {
compatible = "operating-points-v2";
opp-187500000 {
opp-hz = /bits/ 64 <187500000>;
required-opps = <&rpmhpd_opp_low_svs>;
};
opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
required-opps = <&rpmhpd_opp_svs>;
};
opp-358000000 {
opp-hz = /bits/ 64 <358000000>;
required-opps = <&rpmhpd_opp_svs_l1>;
};
};
};
mdss_dsi0_phy: phy@ae95000 {
compatible = "qcom,milos-dsi-phy-4nm";
reg = <0x0ae95000 0x200>,
<0x0ae95200 0x300>,
<0x0ae95500 0x400>;
reg-names = "dsi_phy",
"dsi_phy_lane",
"dsi_pll";
clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
<&rpmhcc RPMH_CXO_CLK>;
clock-names = "iface",
"ref";
#clock-cells = <1>;
#phy-cells = <0>;
};
};
...

3
Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml
View File

@@ -18,6 +18,7 @@ properties:
- qcom,eliza-dpu
- qcom,glymur-dpu
- qcom,kaanapali-dpu
- qcom,milos-dpu
- qcom,sa8775p-dpu
- qcom,sm8650-dpu
- qcom,sm8750-dpu
@@ -70,7 +71,7 @@ examples:
display-controller@ae01000 {
compatible = "qcom,sm8650-dpu";
reg = <0x0ae01000 0x8f000>,
<0x0aeb0000 0x2008>;
<0x0aeb0000 0x3000>;
reg-names = "mdp", "vbif";
clocks = <&gcc_axi_clk>,

2
Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml
View File

@@ -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>,

16
Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml
View File

@@ -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>;

4
Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
View File

@@ -58,6 +58,10 @@ properties:
- hydis,hv070wx2-1e0
# Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
- jenson,bl-jt60050-01a
# Riverdi RVT101HVLNWC00 10.1" WXGA (1280x800) TFT LCD LVDS panel
- riverdi,rvt101hvlnwc00
# Riverdi RVT70HSLNWCA0 7.0" WSVGA (1024x600) TFT LCD LVDS panel
- riverdi,rvt70hslnwca0
# Samsung LTN070NL01 7.0" WSVGA (1024x600) TFT LCD LVDS panel
- samsung,ltn070nl01
# Samsung LTN101AL03 10.1" WXGA (800x1280) TFT LCD LVDS panel

4
Documentation/devicetree/bindings/display/panel/panel-simple.yaml
View File

@@ -31,6 +31,8 @@ properties:
# Ampire AM-1280800N3TZQW-T00H 10.1" WQVGA TFT LCD panel
- ampire,am-1280800n3tzqw-t00h
# Ampire AM-1280800W8TZQW-T00H 10.1" WXGA TFT LCD panel
- ampire,am-1280800w8tzqw-t00h
# Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
- ampire,am-480272h3tmqw-t01h
# Ampire AM-800480L1TMQW-T00H 5" WVGA TFT LCD panel
@@ -234,6 +236,8 @@ properties:
- nec,nl12880bc20-05
# NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
- nec,nl4827hc19-05b
# NEC LCD Technologies,Ltd. VGA TFT LCD panel
- nec,nl6448bc33-70c
# Netron-DY E231732 7.0" WSVGA TFT LCD panel
- netron-dy,e231732
# Newhaven Display International 480 x 272 TFT LCD panel

21
Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
View File

@@ -21,6 +21,7 @@ properties:
- renesas,r9a07g043u-du # RZ/G2UL
- renesas,r9a07g044-du # RZ/G2{L,LC}
- renesas,r9a09g057-du # RZ/V2H(P)
- renesas,r9a09g077-du # RZ/T2H
- items:
- enum:
- renesas,r9a07g054-du # RZ/V2L
@@ -28,6 +29,9 @@ properties:
- items:
- const: renesas,r9a09g056-du # RZ/V2N
- const: renesas,r9a09g057-du # RZ/V2H(P) fallback
- items:
- const: renesas,r9a09g087-du # RZ/N2H
- const: renesas,r9a09g077-du # RZ/T2H fallback
reg:
maxItems: 1
@@ -83,7 +87,6 @@ required:
- interrupts
- clocks
- clock-names
- resets
- power-domains
- ports
- renesas,vsps
@@ -95,13 +98,16 @@ allOf:
properties:
compatible:
contains:
const: renesas,r9a07g043u-du
enum:
- renesas,r9a07g043u-du
- renesas,r9a09g077-du
then:
properties:
ports:
properties:
port@0:
description: DPI
port@1: false
required:
- port@0
@@ -137,6 +143,17 @@ allOf:
required:
- port@0
- if:
properties:
compatible:
contains:
const: renesas,r9a09g077-du
then:
properties:
resets: false
else:
required:
- resets
examples:
# RZ/G2L DU

13
Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
View File

@@ -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

4
Documentation/devicetree/bindings/i2c/apple,i2c.yaml
View File

@@ -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:

13
Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
View File

@@ -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;

1
Documentation/devicetree/bindings/phy/qcom,dsi-phy-7nm.yaml
View File

@@ -20,6 +20,7 @@ properties:
- qcom,dsi-phy-7nm
- qcom,dsi-phy-7nm-8150
- qcom,kaanapali-dsi-phy-3nm
- qcom,milos-dsi-phy-4nm
- qcom,sa8775p-dsi-phy-5nm
- qcom,sar2130p-dsi-phy-5nm
- qcom,sc7280-dsi-phy-7nm

2
Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml
View File

@@ -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

3
Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml
View File

@@ -20,6 +20,9 @@ properties:
- fsl,ls1021a-qspi
- fsl,ls2080a-qspi
- spacemit,k1-qspi
- items:
- const: spacemit,k3-qspi
- const: spacemit,k1-qspi
- items:
- enum:
- fsl,ls1043a-qspi

1
Documentation/gpu/amdgpu/index.rst
View File

@@ -23,3 +23,4 @@ Next (GCN), Radeon DNA (RDNA), and Compute DNA (CDNA) architectures.
debugfs
process-isolation
amdgpu-glossary
ptl

94
Documentation/gpu/amdgpu/ptl.rst Normal file
View File

@@ -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`.

2
Documentation/gpu/driver-uapi.rst
View File

@@ -2,6 +2,8 @@
DRM Driver uAPI
===============
.. contents::
drm/i915 uAPI
=============

1
Documentation/gpu/drivers.rst
View File

@@ -8,6 +8,7 @@ GPU Driver Documentation
amdgpu/index
i915
imagination/index
intel-display/index
mcde
meson
nouveau

2
Documentation/gpu/drm-internals.rst
View File

@@ -18,6 +18,8 @@ event handling, memory management, output management, framebuffer
management, command submission & fencing, suspend/resume support, and
DMA services.
.. contents::
Driver Initialization
=====================

2
Documentation/gpu/drm-kms-helpers.rst
View File

@@ -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
===========================================

5
Documentation/gpu/drm-kms.rst
View File

@@ -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
========

2
Documentation/gpu/drm-mm.rst
View File

@@ -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)
===================================

2
Documentation/gpu/drm-ras.rst
View File

@@ -24,6 +24,8 @@ Key Goals:
nodes for different IP blocks, sub-blocks, or other logical subdivisions
as applicable.
.. contents::
Nodes
=====

4
Documentation/gpu/drm-uapi.rst
View File

@@ -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
====================
@@ -765,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
:doc: uAPI trace events

2
Documentation/gpu/drm-usage-stats.rst
View File

@@ -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
=========================

202
Documentation/gpu/i915.rst
View File

@@ -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
=======

1
Documentation/gpu/index.rst
View File

@@ -3,6 +3,7 @@ GPU Driver Developer's Guide
============================
.. toctree::
:maxdepth: 2
introduction
drm-internals

8
Documentation/gpu/intel-display/async-flip.rst Normal file
View File

@@ -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

11
Documentation/gpu/intel-display/atomic.rst Normal file
View File

@@ -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:

23
Documentation/gpu/intel-display/audio.rst Normal file
View File

@@ -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:

8
Documentation/gpu/intel-display/casf.rst Normal file
View File

@@ -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)

11
Documentation/gpu/intel-display/cdclk.rst Normal file
View File

@@ -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:

8
Documentation/gpu/intel-display/cmtg.rst Normal file
View File

@@ -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)

26
Documentation/gpu/intel-display/dmc.rst Normal file
View File

@@ -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

8
Documentation/gpu/intel-display/dpio.rst Normal file
View File

@@ -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

14
Documentation/gpu/intel-display/dpll.rst Normal file
View File

@@ -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:

11
Documentation/gpu/intel-display/drrs.rst Normal file
View File

@@ -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:

11
Documentation/gpu/intel-display/dsb.rst Normal file
View File

@@ -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:

11
Documentation/gpu/intel-display/fbc.rst Normal file
View File

@@ -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:

11
Documentation/gpu/intel-display/fifo-underrun.rst Normal file
View File

@@ -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:

14
Documentation/gpu/intel-display/frontbuffer.rst Normal file
View File

@@ -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:

11
Documentation/gpu/intel-display/hotplug.rst Normal file
View File

@@ -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:

44
Documentation/gpu/intel-display/index.rst Normal file
View File

@@ -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

11
Documentation/gpu/intel-display/plane.rst Normal file
View File

@@ -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:

11
Documentation/gpu/intel-display/psr.rst Normal file
View File

@@ -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:

8
Documentation/gpu/intel-display/snps-phy.rst Normal file
View File

@@ -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

14
Documentation/gpu/intel-display/vbt.rst Normal file
View File

@@ -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:

2
Documentation/gpu/introduction.rst
View File

@@ -16,6 +16,8 @@ found in current kernels.
[Insert diagram of typical DRM stack here]
.. contents::
Style Guidelines
================

26
Documentation/gpu/rfc/index.rst
View File

@@ -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
gpusvm
i915_gem_lmem
i915_scheduler
i915_small_bar
i915_vm_bind
color_pipeline

5
Documentation/gpu/xe/index.rst
View File

@@ -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:

2
Documentation/hwmon/sy7636a-hwmon.rst
View File

@@ -22,5 +22,5 @@ The following sensors are supported
sysfs-Interface
---------------
temp0_input
temp1_input
- Temperature of external NTC (milli-degree C)

2
Documentation/hwmon/yogafan.rst
View File

@@ -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

9
Documentation/netlink/genetlink-c.yaml
View File

@@ -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:

9
Documentation/netlink/genetlink-legacy.yaml
View File

@@ -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:

9
Documentation/netlink/genetlink.yaml
View File

@@ -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:

9
Documentation/netlink/netlink-raw.yaml
View File

@@ -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:

7
Documentation/netlink/specs/net_shaper.yaml
View File

@@ -33,6 +33,11 @@ doc: |
@cap-get operation.
definitions:
-
type: const
name: max-handle-id
value: 0x3fffffe
scope: kernel
-
type: enum
name: scope
@@ -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

249
Documentation/networking/device_drivers/ethernet/3com/3c509.rst Normal file
View File

@@ -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

1
Documentation/networking/device_drivers/ethernet/index.rst
View File

@@ -10,6 +10,7 @@ Contents:
.. toctree::
:maxdepth: 2
3com/3c509
3com/vortex
amazon/ena
altera/altera_tse

1
Documentation/process/index.rst
View File

@@ -86,6 +86,7 @@ regressions and security problems.
debugging/index
handling-regressions
security-bugs
threat-model
cve
embargoed-hardware-issues

106
Documentation/process/security-bugs.rst
View File

@@ -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.

235
Documentation/process/threat-model.rst Normal file
View File

@@ -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.

2
Documentation/sound/codecs/cs35l56.rst
View File

@@ -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
========

94
Documentation/userspace-api/rseq.rst
View File

@@ -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)::

8
Documentation/virt/kvm/x86/amd-memory-encryption.rst
View File

@@ -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

91
MAINTAINERS
View File

@@ -68,6 +68,12 @@ Maintainers List
first. When adding to this list, please keep the entries in
alphabetical order.
3C509 NETWORK DRIVER
M: "Maciej W. Rozycki" <macro@orcam.me.uk>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/3com/3c509.c
3C59X NETWORK DRIVER
M: Steffen Klassert <klassert@kernel.org>
L: netdev@vger.kernel.org
@@ -2015,7 +2021,7 @@ F: Documentation/hwmon/aquacomputer_d5next.rst
F: drivers/hwmon/aquacomputer_d5next.c
AQUANTIA ETHERNET DRIVER (atlantic)
M: Igor Russkikh <irusskikh@marvell.com>
M: Sukhdeep Singh <sukhdeeps@marvell.com>
L: netdev@vger.kernel.org
S: Maintained
W: https://www.marvell.com/
@@ -2024,7 +2030,7 @@ F: Documentation/networking/device_drivers/ethernet/aquantia/atlantic.rst
F: drivers/net/ethernet/aquantia/atlantic/
AQUANTIA ETHERNET DRIVER PTP SUBSYSTEM
M: Egor Pomozov <epomozov@marvell.com>
M: Sukhdeep Singh <sukhdeeps@marvell.com>
L: netdev@vger.kernel.org
S: Maintained
W: http://www.aquantia.com
@@ -2058,7 +2064,7 @@ F: Documentation/devicetree/bindings/display/snps,arcpgu.txt
F: drivers/gpu/drm/tiny/arcpgu.c
ARCNET NETWORK LAYER
M: Michael Grzeschik <m.grzeschik@pengutronix.de>
M: Michael Grzeschik <mgr@kernel.org>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/arcnet/
@@ -3361,7 +3367,9 @@ F: drivers/irqchip/irq-rda-intc.c
F: drivers/tty/serial/rda-uart.c
ARM/REALTEK ARCHITECTURE
M: Andreas Färber <afaerber@suse.de>
M: James Tai <james.tai@realtek.com>
M: Yu-Chun Lin <eleanor.lin@realtek.com>
R: Andreas Färber <afaerber@suse.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-realtek-soc@lists.infradead.org (moderated for non-subscribers)
S: Maintained
@@ -3369,6 +3377,7 @@ F: Documentation/devicetree/bindings/arm/realtek.yaml
F: arch/arm/boot/dts/realtek/
F: arch/arm/mach-realtek/
F: arch/arm64/boot/dts/realtek/
F: drivers/pinctrl/realtek/
ARM/RISC-V/RENESAS ARCHITECTURE
M: Geert Uytterhoeven <geert+renesas@glider.be>
@@ -4181,8 +4190,8 @@ F: include/uapi/linux/sonet.h
F: net/atm/
ATMEL MACB ETHERNET DRIVER
M: Nicolas Ferre <nicolas.ferre@microchip.com>
M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
M: Théo Lebrun <theo.lebrun@bootlin.com>
R: Conor Dooley <conor.dooley@microchip.com>
S: Maintained
F: drivers/net/ethernet/cadence/
@@ -4299,18 +4308,16 @@ F: Documentation/devicetree/bindings/leds/backlight/awinic,aw99706.yaml
F: drivers/video/backlight/aw99706.c
AXENTIA ARM DEVICES
M: Peter Rosin <peda@axentia.se>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
S: Orphan
F: arch/arm/boot/dts/microchip/at91-linea.dtsi
F: arch/arm/boot/dts/microchip/at91-natte.dtsi
F: arch/arm/boot/dts/microchip/at91-nattis-2-natte-2.dts
F: arch/arm/boot/dts/microchip/at91-tse850-3.dts
AXENTIA ASOC DRIVERS
M: Peter Rosin <peda@axentia.se>
L: linux-sound@vger.kernel.org
S: Maintained
S: Orphan
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
@@ -6358,6 +6365,7 @@ F: include/uapi/linux/comedi.h
COMMON CLK FRAMEWORK
M: Michael Turquette <mturquette@baylibre.com>
M: Stephen Boyd <sboyd@kernel.org>
R: Brian Masney <bmasney@redhat.com>
L: linux-clk@vger.kernel.org
S: Maintained
Q: http://patchwork.kernel.org/project/linux-clk/list/
@@ -7077,6 +7085,12 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/debugobjec
F: include/linux/debugobjects.h
F: lib/debugobjects.c
DEC LANCE NETWORK DRIVER
M: "Maciej W. Rozycki" <macro@orcam.me.uk>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/amd/declance.c
DECSTATION PLATFORM SUPPORT
M: "Maciej W. Rozycki" <macro@orcam.me.uk>
L: linux-mips@vger.kernel.org
@@ -8201,10 +8215,9 @@ F: include/uapi/drm/nouveau_drm.h
CORE DRIVER FOR NVIDIA GPUS [RUST]
M: Danilo Krummrich <dakr@kernel.org>
M: Alexandre Courbot <acourbot@nvidia.com>
L: nouveau@lists.freedesktop.org
L: nova-gpu@lists.linux.dev
S: Supported
W: https://rust-for-linux.com/nova-gpu-driver
Q: https://patchwork.freedesktop.org/project/nouveau/
B: https://gitlab.freedesktop.org/drm/nova/-/issues
C: irc://irc.oftc.net/nouveau
T: git https://gitlab.freedesktop.org/drm/rust/kernel.git drm-rust-next
@@ -8213,10 +8226,9 @@ F: drivers/gpu/nova-core/
DRM DRIVER FOR NVIDIA GPUS [RUST]
M: Danilo Krummrich <dakr@kernel.org>
L: nouveau@lists.freedesktop.org
L: nova-gpu@lists.linux.dev
S: Supported
W: https://rust-for-linux.com/nova-gpu-driver
Q: https://patchwork.freedesktop.org/project/nouveau/
B: https://gitlab.freedesktop.org/drm/nova/-/issues
C: irc://irc.oftc.net/nouveau
T: git https://gitlab.freedesktop.org/drm/rust/kernel.git drm-rust-next
@@ -12055,7 +12067,7 @@ F: Documentation/i2c/busses/i2c-nvidia-gpu.rst
F: drivers/i2c/busses/i2c-nvidia-gpu.c
I2C MUXES
M: Peter Rosin <peda@axentia.se>
M: Peter Rosin <peda@lysator.liu.se>
L: linux-i2c@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-arb*
@@ -12456,7 +12468,7 @@ F: drivers/iio/industrialio-backend.c
F: include/linux/iio/backend.h
IIO DIGITAL POTENTIOMETER DAC
M: Peter Rosin <peda@axentia.se>
M: Peter Rosin <peda@lysator.liu.se>
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/ABI/testing/sysfs-bus-iio-dac-dpot-dac
@@ -12464,7 +12476,7 @@ F: Documentation/devicetree/bindings/iio/dac/dpot-dac.yaml
F: drivers/iio/dac/dpot-dac.c
IIO ENVELOPE DETECTOR
M: Peter Rosin <peda@axentia.se>
M: Peter Rosin <peda@lysator.liu.se>
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
@@ -12480,7 +12492,7 @@ F: include/linux/iio/iio-gts-helper.h
F: drivers/iio/test/iio-test-gts.c
IIO MULTIPLEXER
M: Peter Rosin <peda@axentia.se>
M: Peter Rosin <peda@lysator.liu.se>
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml
@@ -12511,7 +12523,7 @@ F: include/linux/iio/
F: tools/iio/
IIO UNIT CONVERTER
M: Peter Rosin <peda@axentia.se>
M: Peter Rosin <peda@lysator.liu.se>
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
@@ -12788,7 +12800,6 @@ M: Cezary Rojewski <cezary.rojewski@intel.com>
M: Liam Girdwood <liam.r.girdwood@linux.intel.com>
M: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
M: Bard Liao <yung-chuan.liao@linux.intel.com>
M: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
M: Kai Vehmanen <kai.vehmanen@linux.intel.com>
R: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
L: linux-sound@vger.kernel.org
@@ -13869,6 +13880,7 @@ M: Pratyush Yadav <pratyush@kernel.org>
R: Dave Young <ruirui.yang@linux.dev>
L: kexec@lists.infradead.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git
F: Documentation/admin-guide/kdump/
F: fs/proc/vmcore.c
F: include/linux/crash_core.h
@@ -14061,6 +14073,7 @@ KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
M: Marc Zyngier <maz@kernel.org>
M: Oliver Upton <oupton@kernel.org>
R: Joey Gouly <joey.gouly@arm.com>
R: Steffen Eiden <seiden@linux.ibm.com>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
R: Zenghui Yu <yuzenghui@huawei.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -14185,6 +14198,7 @@ M: Pasha Tatashin <pasha.tatashin@soleen.com>
M: Pratyush Yadav <pratyush@kernel.org>
L: kexec@lists.infradead.org
W: http://kernel.org/pub/linux/utils/kernel/kexec/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git
F: include/linux/kexec.h
F: include/uapi/linux/kexec.h
F: kernel/kexec*
@@ -14901,6 +14915,7 @@ LIVE UPDATE
M: Pasha Tatashin <pasha.tatashin@soleen.com>
M: Mike Rapoport <rppt@kernel.org>
M: Pratyush Yadav <pratyush@kernel.org>
L: kexec@lists.infradead.org
L: linux-kernel@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git
@@ -15727,7 +15742,7 @@ F: Documentation/devicetree/bindings/media/i2c/maxim,max96717.yaml
F: drivers/media/i2c/max96717.c
MAX9860 MONO AUDIO VOICE CODEC DRIVER
M: Peter Rosin <peda@axentia.se>
M: Peter Rosin <peda@lysator.liu.se>
L: linux-sound@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/sound/max9860.txt
@@ -15942,7 +15957,7 @@ F: Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
F: drivers/net/can/spi/mcp251xfd/
MCP4018 AND MCP4531 MICROCHIP DIGITAL POTENTIOMETER DRIVERS
M: Peter Rosin <peda@axentia.se>
M: Peter Rosin <peda@lysator.liu.se>
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/ABI/testing/sysfs-bus-iio-potentiometer-mcp4531
@@ -18247,7 +18262,7 @@ F: include/linux/mmc/
F: include/uapi/linux/mmc/
MULTIPLEXER SUBSYSTEM
M: Peter Rosin <peda@axentia.se>
M: Peter Rosin <peda@lysator.liu.se>
S: Odd Fixes
F: Documentation/ABI/testing/sysfs-class-mux*
F: Documentation/devicetree/bindings/mux/
@@ -18631,6 +18646,7 @@ F: tools/testing/selftests/net/
X: Documentation/networking/mac80211-injection.rst
X: Documentation/networking/mac80211_hwsim/
X: Documentation/networking/regulatory.rst
X: include/net/bluetooth/
X: include/net/cfg80211.h
X: include/net/ieee80211_radiotap.h
X: include/net/iw_handler.h
@@ -18940,7 +18956,8 @@ F: drivers/hid/hid-nintendo*
NIOS2 ARCHITECTURE
M: Dinh Nguyen <dinguyen@kernel.org>
S: Maintained
M: Simon Schuster <schuster.simon@siemens-energy.com>
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git
F: arch/nios2/
@@ -19356,7 +19373,7 @@ F: include/dt-bindings/display/tda998x.h
K: "nxp,tda998x"
NXP TFA9879 DRIVER
M: Peter Rosin <peda@axentia.se>
M: Peter Rosin <peda@lysator.liu.se>
L: linux-sound@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/sound/trivial-codec.yaml
@@ -19454,7 +19471,6 @@ F: include/misc/ocxl*
F: include/uapi/misc/ocxl.h
OMAP AUDIO SUPPORT
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
M: Jarkko Nikula <jarkko.nikula@bitmer.com>
L: linux-sound@vger.kernel.org
L: linux-omap@vger.kernel.org
@@ -20357,13 +20373,14 @@ F: Documentation/devicetree/bindings/pci/marvell,armada8k-pcie.yaml
F: drivers/pci/controller/dwc/pcie-armada8k.c
PCI DRIVER FOR CADENCE PCIE IP
R: Aksh Garg <a-garg7@ti.com>
L: linux-pci@vger.kernel.org
S: Orphan
F: Documentation/devicetree/bindings/pci/cdns,*
F: drivers/pci/controller/cadence/*cadence*
F: drivers/pci/controller/cadence/
PCI DRIVER FOR CIX Sky1
M: Hans Zhang <hans.zhang@cixtech.com>
M: Hans Zhang <18255117159@163.com>
L: linux-pci@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/pci/cix,sky1-pcie-*.yaml
@@ -20475,7 +20492,7 @@ F: drivers/pci/controller/plda/pcie-plda-host.c
F: drivers/pci/controller/plda/pcie-plda.h
PCI DRIVER FOR RENESAS R-CAR
M: Marek Vasut <marek.vasut+renesas@gmail.com>
M: Marek Vasut <marek.vasut+renesas@mailbox.org>
M: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
L: linux-pci@vger.kernel.org
L: linux-renesas-soc@vger.kernel.org
@@ -20735,15 +20752,13 @@ F: Documentation/devicetree/bindings/pci/intel,keembay-pcie*
F: drivers/pci/controller/dwc/pcie-keembay.c
PCIE DRIVER FOR INTEL LGM GW SOC
M: Chuanhua Lei <lchuanhua@maxlinear.com>
L: linux-pci@vger.kernel.org
S: Maintained
S: Orphan
F: Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
F: drivers/pci/controller/dwc/pcie-intel-gw.c
PCIE DRIVER FOR MEDIATEK
M: Ryder Lee <ryder.lee@mediatek.com>
M: Jianjun Wang <jianjun.wang@mediatek.com>
L: linux-pci@vger.kernel.org
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Supported
@@ -22949,7 +22964,7 @@ N: riscv
K: riscv
RISC-V IOMMU
M: Tomasz Jeznach <tjeznach@rivosinc.com>
M: Tomasz Jeznach <tomasz.jeznach@linux.dev>
L: iommu@lists.linux.dev
L: linux-riscv@lists.infradead.org
S: Maintained
@@ -24659,6 +24674,7 @@ S: Maintained
F: fs/smb/client/smbdirect.*
F: fs/smb/smbdirect/
F: fs/smb/server/transport_rdma.*
F: include/linux/smbdirect.h
SMC91x ETHERNET DRIVER
M: Nicolas Pitre <nico@fluxnic.net>
@@ -25062,7 +25078,6 @@ SOUND - SOUND OPEN FIRMWARE (SOF) DRIVERS
M: Liam Girdwood <lgirdwood@gmail.com>
M: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
M: Bard Liao <yung-chuan.liao@linux.intel.com>
M: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
M: Daniel Baluta <daniel.baluta@nxp.com>
R: Kai Vehmanen <kai.vehmanen@linux.intel.com>
R: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
@@ -26355,7 +26370,7 @@ F: arch/xtensa/
F: drivers/irqchip/irq-xtensa-*
TEXAS INSTRUMENTS ASoC DRIVERS
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
M: Sen Wang <sen@ti.com>
L: linux-sound@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml
@@ -26857,12 +26872,6 @@ S: Maintained
F: Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
F: drivers/iio/adc/ti-tsc2046.c
TI TWL4030 SERIES SOC CODEC DRIVER
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
L: linux-sound@vger.kernel.org
S: Maintained
F: sound/soc/codecs/twl4030*
TI VPE/CAL DRIVERS
M: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
L: linux-media@vger.kernel.org

4
Makefile
View File

@@ -2,7 +2,7 @@
VERSION = 7
PATCHLEVEL = 1
SUBLEVEL = 0
EXTRAVERSION = -rc2
EXTRAVERSION = -rc5
NAME = Baby Opossum Posse
# *DOCUMENTATION*
@@ -486,6 +486,8 @@ export rust_common_flags := --edition=2021 \
-Wclippy::as_ptr_cast_mut \
-Wclippy::as_underscore \
-Wclippy::cast_lossless \
-Aclippy::collapsible_if \
-Aclippy::collapsible_match \
-Wclippy::ignored_unit_patterns \
-Aclippy::incompatible_msrv \
-Wclippy::mut_mut \

1
arch/alpha/include/asm/Kbuild
View File

@@ -5,4 +5,5 @@ generic-y += agp.h
generic-y += asm-offsets.h
generic-y += kvm_para.h
generic-y += mcs_spinlock.h
generic-y += ring_buffer.h
generic-y += text-patching.h

1
arch/arc/include/asm/Kbuild
View File

@@ -5,5 +5,6 @@ generic-y += extable.h
generic-y += kvm_para.h
generic-y += mcs_spinlock.h
generic-y += parport.h
generic-y += ring_buffer.h
generic-y += user.h
generic-y += text-patching.h

3
arch/arm/boot/dts/renesas/r7s72100-genmai.dts
View File

@@ -34,9 +34,6 @@ flash@18000000 {
clocks = <&mstp9_clks R7S72100_CLK_SPIBSC0>;
power-domains = <&cpg_clocks>;
#address-cells = <1>;
#size-cells = <1>;
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;

2
arch/arm/boot/dts/renesas/r7s72100-rskrza1.dts
View File

@@ -36,8 +36,6 @@ flash@18000000 {
power-domains = <&cpg_clocks>;
bank-width = <4>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
partitions {
compatible = "fixed-partitions";

2
arch/arm/boot/dts/renesas/r7s72100.dtsi
View File

@@ -37,7 +37,7 @@ b_clk: b {
clock-div = <3>;
};
bsc: bus {
bsc: bus@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;

2
arch/arm/boot/dts/renesas/r8a7778.dtsi
View File

@@ -40,7 +40,7 @@ aliases {
spi2 = &hspi2;
};
lbsc: bus {
lbsc: bus@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;

2
arch/arm/boot/dts/renesas/r8a7779.dtsi
View File

@@ -704,7 +704,7 @@ R8A7779_CLK_MMC1 R8A7779_CLK_MMC0
};
};
lbsc: bus {
lbsc: bus@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;

2
arch/arm/boot/dts/renesas/r8a7792.dtsi
View File

@@ -86,7 +86,7 @@ extal_clk: extal {
bootph-all;
};
lbsc: bus {
lbsc: bus@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;

1
arch/arm/include/asm/Kbuild
View File

@@ -3,6 +3,7 @@ generic-y += early_ioremap.h
generic-y += extable.h
generic-y += flat.h
generic-y += parport.h
generic-y += ring_buffer.h
generated-y += mach-types.h
generated-y += unistd-nr.h

13
arch/arm/mach-versatile/integrator_cp.c
View File

@@ -86,14 +86,6 @@ static u64 notrace intcp_read_sched_clock(void)
return val;
}
static void __init intcp_init_early(void)
{
cm_map = syscon_regmap_lookup_by_compatible("arm,core-module-integrator");
if (IS_ERR(cm_map))
return;
sched_clock_register(intcp_read_sched_clock, 32, 24000000);
}
static void __init intcp_init_irq_of(void)
{
cm_init();
@@ -119,6 +111,10 @@ static void __init intcp_init_of(void)
{
struct device_node *cpcon;
cm_map = syscon_regmap_lookup_by_compatible("arm,core-module-integrator");
if (!IS_ERR(cm_map))
sched_clock_register(intcp_read_sched_clock, 32, 24000000);
cpcon = of_find_matching_node(NULL, intcp_syscon_match);
if (!cpcon)
return;
@@ -138,7 +134,6 @@ static const char * intcp_dt_board_compat[] = {
DT_MACHINE_START(INTEGRATOR_CP_DT, "ARM Integrator/CP (Device Tree)")
.reserve = integrator_reserve,
.map_io = intcp_map_io,
.init_early = intcp_init_early,
.init_irq = intcp_init_irq_of,
.init_machine = intcp_init_of,
.dt_compat = intcp_dt_board_compat,

5
arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso
View File

@@ -27,7 +27,12 @@ &lvds1 {
status = "okay";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@1 {
reg = <1>;
lvds1_out: endpoint {
remote-endpoint = <&panel_in>;
};

8
arch/arm64/boot/dts/renesas/r8a78000.dtsi
View File

@@ -699,7 +699,7 @@ scif0: serial@c0700000 {
"renesas,rcar-gen5-scif", "renesas,scif";
reg = <0 0xc0700000 0 0x40>;
interrupts = <GIC_ESPI 10 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&dummy_clk_sgasyncd16>, <&dummy_clk_sgasyncd16>, <&scif_clk>;
clocks = <&dummy_clk_sgasyncd16>, <&dummy_clk_sgasyncd4>, <&scif_clk>;
clock-names = "fck", "brg_int", "scif_clk";
status = "disabled";
};
@@ -709,7 +709,7 @@ scif1: serial@c0704000 {
"renesas,rcar-gen5-scif", "renesas,scif";
reg = <0 0xc0704000 0 0x40>;
interrupts = <GIC_ESPI 11 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&dummy_clk_sgasyncd16>, <&dummy_clk_sgasyncd16>, <&scif_clk>;
clocks = <&dummy_clk_sgasyncd16>, <&dummy_clk_sgasyncd4>, <&scif_clk>;
clock-names = "fck", "brg_int", "scif_clk";
status = "disabled";
};
@@ -719,7 +719,7 @@ scif3: serial@c0708000 {
"renesas,rcar-gen5-scif", "renesas,scif";
reg = <0 0xc0708000 0 0x40>;
interrupts = <GIC_ESPI 12 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&dummy_clk_sgasyncd16>, <&dummy_clk_sgasyncd16>, <&scif_clk>;
clocks = <&dummy_clk_sgasyncd16>, <&dummy_clk_sgasyncd4>, <&scif_clk>;
clock-names = "fck", "brg_int", "scif_clk";
status = "disabled";
};
@@ -729,7 +729,7 @@ scif4: serial@c070c000 {
"renesas,rcar-gen5-scif", "renesas,scif";
reg = <0 0xc070c000 0 0x40>;
interrupts = <GIC_ESPI 13 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&dummy_clk_sgasyncd16>, <&dummy_clk_sgasyncd16>, <&scif_clk>;
clocks = <&dummy_clk_sgasyncd16>, <&dummy_clk_sgasyncd4>, <&scif_clk>;
clock-names = "fck", "brg_int", "scif_clk";
status = "disabled";
};

1
arch/arm64/boot/dts/renesas/r9a09g056.dtsi
View File

@@ -1327,6 +1327,7 @@ usb20phyrst: usb20phy-reset@15830000 {
resets = <&cpg 0xaf>;
power-domains = <&cpg>;
#reset-cells = <0>;
#mux-state-cells = <1>;
status = "disabled";
};

2
arch/arm64/boot/dts/renesas/r9a09g057.dtsi
View File

@@ -1345,6 +1345,7 @@ usb20phyrst: usb20phy-reset@15830000 {
resets = <&cpg 0xaf>;
power-domains = <&cpg>;
#reset-cells = <0>;
#mux-state-cells = <1>;
status = "disabled";
};
@@ -1355,6 +1356,7 @@ usb21phyrst: usb21phy-reset@15840000 {
resets = <&cpg 0xaf>;
power-domains = <&cpg>;
#reset-cells = <0>;
#mux-state-cells = <1>;
status = "disabled";
};

5
arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
View File

@@ -46,7 +46,12 @@ &csi2 {
status = "okay";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
csi2_in: endpoint {
clock-lanes = <0>;
data-lanes = <1 2>;

5
arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
View File

@@ -26,7 +26,12 @@ &du {
status = "okay";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
du_out_rgb: endpoint {
remote-endpoint = <&adv7513_in>;
};

5
arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso
View File

@@ -27,7 +27,12 @@ &lvds0 {
status = "okay";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@1 {
reg = <1>;
lvds0_out: endpoint {
remote-endpoint = <&panel_in>;
};

3
arch/arm64/configs/defconfig
View File

@@ -1411,6 +1411,9 @@ CONFIG_RZ_DMAC=y
CONFIG_TI_K3_UDMA=y
CONFIG_TI_K3_UDMA_GLUE_LAYER=y
CONFIG_STM32_DMA3=m
CONFIG_DMABUF_HEAPS=y
CONFIG_DMABUF_HEAPS_SYSTEM=m
CONFIG_DMABUF_HEAPS_CMA=m
CONFIG_VFIO=y
CONFIG_VFIO_PCI=y
CONFIG_VIRTIO_PCI=y

Some files were not shown because too many files have changed in this diff Show More