diff options
Diffstat (limited to 'Documentation')
866 files changed, 26355 insertions, 7601 deletions
diff --git a/Documentation/ABI/README b/Documentation/ABI/README index 8bac9cb09a6d..ef0e6d11e919 100644 --- a/Documentation/ABI/README +++ b/Documentation/ABI/README @@ -1,4 +1,5 @@ -This directory attempts to document the ABI between the Linux kernel and +This part of the documentation inside Documentation/ABI directory +attempts to document the ABI between the Linux kernel and userspace, and the relative stability of these interfaces. Due to the everchanging nature of Linux, and the differing maturity levels, these interfaces should be used by userspace programs in different ways. diff --git a/Documentation/ABI/removed/sysfs-class-rfkill b/Documentation/ABI/removed/sysfs-class-rfkill index f25174eafd55..20cb688af173 100644 --- a/Documentation/ABI/removed/sysfs-class-rfkill +++ b/Documentation/ABI/removed/sysfs-class-rfkill @@ -4,7 +4,7 @@ For details to this subsystem look at Documentation/driver-api/rfkill.rst. What: /sys/class/rfkill/rfkill[0-9]+/claim Date: 09-Jul-2007 -KernelVersion v2.6.22 +KernelVersion: v2.6.22 Contact: linux-wireless@vger.kernel.org Description: This file was deprecated because there no longer was a way to claim just control over a single rfkill instance. diff --git a/Documentation/ABI/stable/sysfs-class-bluetooth b/Documentation/ABI/stable/sysfs-class-bluetooth new file mode 100644 index 000000000000..36be02471174 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-class-bluetooth @@ -0,0 +1,9 @@ +What: /sys/class/bluetooth/hci<index>/reset +Date: 14-Jan-2025 +KernelVersion: 6.13 +Contact: linux-bluetooth@vger.kernel.org +Description: This write-only attribute allows users to trigger the vendor reset + method on the Bluetooth device when arbitrary data is written. + The reset may or may not be done through the device transport + (e.g., UART/USB), and can also be done through an out-of-band + approach such as GPIO. diff --git a/Documentation/ABI/stable/sysfs-class-rfkill b/Documentation/ABI/stable/sysfs-class-rfkill index 037979f7dc4b..67b605e3dd16 100644 --- a/Documentation/ABI/stable/sysfs-class-rfkill +++ b/Documentation/ABI/stable/sysfs-class-rfkill @@ -16,7 +16,7 @@ Description: The rfkill class subsystem folder. What: /sys/class/rfkill/rfkill[0-9]+/name Date: 09-Jul-2007 -KernelVersion v2.6.22 +KernelVersion: v2.6.22 Contact: linux-wireless@vger.kernel.org Description: Name assigned by driver to this key (interface or driver name). Values: arbitrary string. @@ -24,7 +24,7 @@ Values: arbitrary string. What: /sys/class/rfkill/rfkill[0-9]+/type Date: 09-Jul-2007 -KernelVersion v2.6.22 +KernelVersion: v2.6.22 Contact: linux-wireless@vger.kernel.org Description: Driver type string ("wlan", "bluetooth", etc). Values: See include/linux/rfkill.h. @@ -32,7 +32,7 @@ Values: See include/linux/rfkill.h. What: /sys/class/rfkill/rfkill[0-9]+/persistent Date: 09-Jul-2007 -KernelVersion v2.6.22 +KernelVersion: v2.6.22 Contact: linux-wireless@vger.kernel.org Description: Whether the soft blocked state is initialised from non-volatile storage at startup. @@ -44,7 +44,7 @@ Values: A numeric value: What: /sys/class/rfkill/rfkill[0-9]+/state Date: 09-Jul-2007 -KernelVersion v2.6.22 +KernelVersion: v2.6.22 Contact: linux-wireless@vger.kernel.org Description: Current state of the transmitter. This file was scheduled to be removed in 2014, but due to its @@ -67,7 +67,7 @@ Values: A numeric value. What: /sys/class/rfkill/rfkill[0-9]+/hard Date: 12-March-2010 -KernelVersion v2.6.34 +KernelVersion: v2.6.34 Contact: linux-wireless@vger.kernel.org Description: Current hardblock state. This file is read only. Values: A numeric value. @@ -81,7 +81,7 @@ Values: A numeric value. What: /sys/class/rfkill/rfkill[0-9]+/soft Date: 12-March-2010 -KernelVersion v2.6.34 +KernelVersion: v2.6.34 Contact: linux-wireless@vger.kernel.org Description: Current softblock state. This file is read and write. Values: A numeric value. diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu index 902392d7eddf..cf78bd99f6c8 100644 --- a/Documentation/ABI/stable/sysfs-devices-system-cpu +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu @@ -24,12 +24,6 @@ Description: Default value for the Data Stream Control Register (DSCR) on If set by a process it will be inherited by child processes. Values: 64 bit unsigned integer (bit field) -What: /sys/devices/system/cpu/cpuX/topology/physical_package_id -Description: physical package id of cpuX. Typically corresponds to a physical - socket number, but the actual value is architecture and platform - dependent. -Values: integer - What: /sys/devices/system/cpu/cpuX/topology/die_id Description: the CPU die ID of cpuX. Typically it is the hardware platform's identifier (rather than the kernel's). The actual value is @@ -86,10 +80,6 @@ What: /sys/devices/system/cpu/cpuX/topology/die_cpus Description: internal kernel map of CPUs within the same die. Values: hexadecimal bitmask. -What: /sys/devices/system/cpu/cpuX/topology/ppin -Description: per-socket protected processor inventory number -Values: hexadecimal. - What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list Description: human-readable list of CPUs within the same die. The format is like 0-3, 8-11, 14,17. diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index f2ec42949a54..4a355e6747ae 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -246,14 +246,14 @@ Description: Controls whether PRS disable is turned on for the workqueue. capability. What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy -Date May 25, 2021 +Date: May 25, 2021 KernelVersion: 5.14.0 Contact: dmaengine@vger.kernel.org Description: Show the current number of entries in this WQ if WQ Occupancy Support bit WQ capabilities is 1. What: /sys/bus/dsa/devices/wq<m>.<n>/enqcmds_retries -Date Oct 29, 2021 +Date: Oct 29, 2021 KernelVersion: 5.17.0 Contact: dmaengine@vger.kernel.org Description: Indicate the number of retires for an enqcmds submission on a sharedwq. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-midi2 b/Documentation/ABI/testing/configfs-usb-gadget-midi2 index 0eac3aaba137..d76a52e2ca7f 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-midi2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-midi2 @@ -47,7 +47,7 @@ Description: midi1_first_group The first UMP Group number for MIDI 1.0 (0-15) midi1_num_groups The number of groups for MIDI 1.0 (0-16) ui_hint 0: unknown, 1: receiver, 2: sender, 3: both - midi_ci_verison Supported MIDI-CI version number (8 bit) + midi_ci_version Supported MIDI-CI version number (8 bit) is_midi1 Legacy MIDI 1.0 device (0, 1 or 2) sysex8_streams Max number of SysEx8 streams (8 bit) active Active FB flag (0 or 1) diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti b/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti index bf2869c413e7..a97b70f588da 100644 --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti @@ -1,241 +1,241 @@ What: /sys/bus/coresight/devices/<cti-name>/enable Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Enable/Disable the CTI hardware. What: /sys/bus/coresight/devices/<cti-name>/powered Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Indicate if the CTI hardware is powered. What: /sys/bus/coresight/devices/<cti-name>/ctmid Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Display the associated CTM ID What: /sys/bus/coresight/devices/<cti-name>/nr_trigger_cons Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Number of devices connected to triggers on this CTI What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/name Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Name of connected device <N> What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_signals Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Input trigger signals from connected device <N> What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_types Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Functional types for the input trigger signals from connected device <N> What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_signals Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Output trigger signals to connected device <N> What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_types Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Functional types for the output trigger signals to connected device <N> What: /sys/bus/coresight/devices/<cti-name>/regs/inout_sel Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Select the index for inen and outen registers. What: /sys/bus/coresight/devices/<cti-name>/regs/inen Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Read or write the CTIINEN register selected by inout_sel. What: /sys/bus/coresight/devices/<cti-name>/regs/outen Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Read or write the CTIOUTEN register selected by inout_sel. What: /sys/bus/coresight/devices/<cti-name>/regs/gate Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Read or write CTIGATE register. What: /sys/bus/coresight/devices/<cti-name>/regs/asicctl Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Read or write ASICCTL register. What: /sys/bus/coresight/devices/<cti-name>/regs/intack Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Write the INTACK register. What: /sys/bus/coresight/devices/<cti-name>/regs/appset Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Set CTIAPPSET register to activate channel. Read back to determine current value of register. What: /sys/bus/coresight/devices/<cti-name>/regs/appclear Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Write APPCLEAR register to deactivate channel. What: /sys/bus/coresight/devices/<cti-name>/regs/apppulse Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Write APPPULSE to pulse a channel active for one clock cycle. What: /sys/bus/coresight/devices/<cti-name>/regs/chinstatus Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Read current status of channel inputs. What: /sys/bus/coresight/devices/<cti-name>/regs/choutstatus Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) read current status of channel outputs. What: /sys/bus/coresight/devices/<cti-name>/regs/triginstatus Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) read current status of input trigger signals What: /sys/bus/coresight/devices/<cti-name>/regs/trigoutstatus Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) read current status of output trigger signals. What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_attach Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Attach a CTI input trigger to a CTM channel. What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_detach Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Detach a CTI input trigger from a CTM channel. What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_attach Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Attach a CTI output trigger to a CTM channel. What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_detach Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Detach a CTI output trigger from a CTM channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_enable Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Enable CTIGATE for single channel (Write) or list enabled channels through the gate (R). What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_disable Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Disable CTIGATE for single channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_set Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Activate a single channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_clear Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Deactivate a single channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_pulse Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Pulse a single channel - activate for a single clock cycle. What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_filtered Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) List of output triggers filtered across all connections. What: /sys/bus/coresight/devices/<cti-name>/channels/trig_filter_enable Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Enable or disable trigger output signal filtering. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_inuse Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) show channels with at least one attached trigger signal. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_free Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) show channels with no attached trigger signals. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_sel Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Write channel number to select a channel to view, read to see selected channel number. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_in Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Read to see input triggers connected to selected view channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_out Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Read to see output triggers connected to selected view channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_reset Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Clear all channel / trigger programming. diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source b/Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source new file mode 100644 index 000000000000..0830661ef656 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source @@ -0,0 +1,15 @@ +What: /sys/bus/coresight/devices/dummy_source<N>/enable_source +Date: Dec 2024 +KernelVersion: 6.14 +Contact: Mao Jinlong <quic_jinlmao@quicinc.com> +Description: (RW) Enable/disable tracing of dummy source. A sink should be activated + before enabling the source. The path of coresight components linking + the source to the sink is configured and managed automatically by the + coresight framework. + +What: /sys/bus/coresight/devices/dummy_source<N>/traceid +Date: Dec 2024 +KernelVersion: 6.14 +Contact: Mao Jinlong <quic_jinlmao@quicinc.com> +Description: (R) Show the trace ID that will appear in the trace stream + coming from this trace entity. diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm index bf710ea6e0ef..53cb454b60d0 100644 --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm @@ -1,6 +1,6 @@ What: /sys/bus/coresight/devices/<tpdm-name>/integration_test Date: January 2023 -KernelVersion 6.2 +KernelVersion: 6.2 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Run integration test for tpdm. Integration test @@ -14,7 +14,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/reset_dataset Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Reset the dataset of the tpdm. @@ -24,7 +24,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_type Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the trigger type of the DSB for tpdm. @@ -35,7 +35,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_ts Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the trigger timestamp of the DSB for tpdm. @@ -46,7 +46,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_mode Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the programming mode of the DSB for tpdm. @@ -60,7 +60,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_idx Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the index number of the edge detection for the DSB @@ -69,7 +69,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_val Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: Write a data to control the edge detection corresponding to @@ -85,7 +85,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_mask Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: Write a data to mask the edge detection corresponding to the index @@ -97,21 +97,21 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/edcr[0:15] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: Read a set of the edge control value of the DSB in TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/edcmr[0:7] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: Read a set of the edge control mask of the DSB in TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_patt/xpr[0:7] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the value of the trigger pattern for the DSB @@ -119,7 +119,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_patt/xpmr[0:7] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the mask of the trigger pattern for the DSB @@ -127,21 +127,21 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpr[0:7] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the value of the pattern for the DSB subunit TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpmr[0:7] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the mask of the pattern for the DSB subunit TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/enable_ts Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Set the pattern timestamp of DSB tpdm. Read @@ -153,7 +153,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/set_type Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Set the pattern type of DSB tpdm. Read @@ -165,7 +165,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_msr/msr[0:31] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the MSR(mux select register) for the DSB subunit @@ -173,7 +173,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/cmb_mode Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Set the data collection mode of CMB tpdm. Continuous change creates CMB data set elements on every CMBCLK edge. @@ -187,7 +187,7 @@ Description: (Write) Set the data collection mode of CMB tpdm. Continuous What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_patt/xpr[0:1] Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the value of the trigger pattern for the CMB @@ -195,7 +195,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_patt/xpmr[0:1] Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the mask of the trigger pattern for the CMB @@ -203,21 +203,21 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpr[0:1] Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the value of the pattern for the CMB subunit TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpmr[0:1] Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the mask of the pattern for the CMB subunit TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Set the pattern timestamp of CMB tpdm. Read @@ -229,7 +229,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the trigger timestamp of the CMB for tpdm. @@ -240,7 +240,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Read or write the status of timestamp upon all interface. @@ -252,7 +252,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/cmb_msr/msr[0:31] Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the MSR(mux select register) for the CMB subunit diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices b/Documentation/ABI/testing/sysfs-bus-event_source-devices new file mode 100644 index 000000000000..79b268319df1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices @@ -0,0 +1,24 @@ +What: /sys/bus/event_source/devices/<pmu> +Date: 2014/02/24 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: Performance Monitoring Unit (<pmu>) + + Each <pmu> directory, for a PMU device, is a name + optionally followed by an underscore and then either a + decimal or hexadecimal number. For example, cpu is a + PMU name without a suffix as is intel_bts, + uncore_imc_0 is a PMU name with a 0 numeric suffix, + ddr_pmu_87e1b0000000 is a PMU name with a hex + suffix. The hex suffix must be more than two + characters long to avoid ambiguity with PMUs like the + S390 cpum_cf. + + Tools can treat PMUs with the same name that differ by + suffix as instances of the same PMU for the sake of, + for example, opening an event. For example, the PMUs + uncore_imc_free_running_0 and + uncore_imc_free_running_1 have an event data_read; + opening the data_read event on a PMU specified as + uncore_imc_free_running should be treated as opening + the data_read event on PMU uncore_imc_free_running_0 + and PMU uncore_imc_free_running_1. diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events index e7efeab2ee83..0fe1b9487202 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events @@ -37,11 +37,13 @@ Description: Per-pmu performance monitoring events specific to the running syste performance monitoring event supported by the <pmu>. The name of the file is the name of the event. - As performance monitoring event names are case - insensitive in the perf tool, the perf tool only looks - for lower or upper case event names in sysfs to avoid + As performance monitoring event names are case insensitive + in the perf tool, the perf tool only looks for all lower + case or all upper case event names in sysfs to avoid scanning the directory. It is therefore required the - name of the event here is either lower or upper case. + name of the event here is either completely lower or upper + case, with no mixed-case characters. Numbers, '.', '_', and + '-' are also allowed. File contents: diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index f83bd6829285..25d366d452a5 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -168,18 +168,6 @@ Description: is required is a consistent labeling. Units after application of scale and offset are millivolts. -What: /sys/bus/iio/devices/iio:deviceX/in_currentY_raw -What: /sys/bus/iio/devices/iio:deviceX/in_currentY_supply_raw -KernelVersion: 3.17 -Contact: linux-iio@vger.kernel.org -Description: - Raw (unscaled no bias removal etc.) current measurement from - channel Y. In special cases where the channel does not - correspond to externally available input one of the named - versions may be used. The number must always be specified and - unique to allow association with event codes. Units after - application of scale and offset are milliamps. - What: /sys/bus/iio/devices/iio:deviceX/in_powerY_raw KernelVersion: 4.5 Contact: linux-iio@vger.kernel.org @@ -227,7 +215,7 @@ Description: same scaling as _raw. What: /sys/bus/iio/devices/iio:deviceX/in_temp_raw -What: /sys/bus/iio/devices/iio:deviceX/in_tempX_raw +What: /sys/bus/iio/devices/iio:deviceX/in_tempY_raw What: /sys/bus/iio/devices/iio:deviceX/in_temp_x_raw What: /sys/bus/iio/devices/iio:deviceX/in_temp_y_raw What: /sys/bus/iio/devices/iio:deviceX/in_temp_ambient_raw @@ -416,11 +404,11 @@ Contact: linux-iio@vger.kernel.org Description: Scaled humidity measurement in milli percent. -What: /sys/bus/iio/devices/iio:deviceX/in_X_mean_raw +What: /sys/bus/iio/devices/iio:deviceX/in_Y_mean_raw KernelVersion: 3.5 Contact: linux-iio@vger.kernel.org Description: - Averaged raw measurement from channel X. The number of values + Averaged raw measurement from channel Y. The number of values used for averaging is device specific. The converting rules for normal raw values also applies to the averaged raw values. @@ -448,7 +436,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_offset What: /sys/bus/iio/devices/iio:deviceX/in_magn_offset What: /sys/bus/iio/devices/iio:deviceX/in_rot_offset What: /sys/bus/iio/devices/iio:deviceX/in_angl_offset -What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceX_offset +What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_offset KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -508,6 +496,9 @@ What: /sys/bus/iio/devices/iio:deviceX/in_angl_scale What: /sys/bus/iio/devices/iio:deviceX/in_intensity_x_scale What: /sys/bus/iio/devices/iio:deviceX/in_intensity_y_scale What: /sys/bus/iio/devices/iio:deviceX/in_intensity_z_scale +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_red_scale +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_green_scale +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_scale What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_scale KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org @@ -660,10 +651,10 @@ What: /sys/.../iio:deviceX/in_magn_scale_available What: /sys/.../iio:deviceX/in_illuminance_scale_available What: /sys/.../iio:deviceX/in_intensity_scale_available What: /sys/.../iio:deviceX/in_proximity_scale_available -What: /sys/.../iio:deviceX/in_voltageX_scale_available +What: /sys/.../iio:deviceX/in_voltageY_scale_available What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available -What: /sys/.../iio:deviceX/out_voltageX_scale_available -What: /sys/.../iio:deviceX/out_altvoltageX_scale_available +What: /sys/.../iio:deviceX/out_voltageY_scale_available +What: /sys/.../iio:deviceX/out_altvoltageY_scale_available What: /sys/.../iio:deviceX/in_capacitance_scale_available What: /sys/.../iio:deviceX/in_pressure_scale_available What: /sys/.../iio:deviceX/in_pressureY_scale_available @@ -681,6 +672,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_intensity_red_hardwaregain What: /sys/bus/iio/devices/iio:deviceX/in_intensity_green_hardwaregain What: /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_hardwaregain What: /sys/bus/iio/devices/iio:deviceX/in_intensity_clear_hardwaregain +What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_hardwaregain KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -1562,7 +1554,7 @@ Description: This attribute is used to read the amount of quadrature error present in the device at a given time. -What: /sys/.../iio:deviceX/in_accelX_power_mode +What: /sys/.../iio:deviceX/in_accelY_power_mode KernelVersion: 3.11 Contact: linux-iio@vger.kernel.org Description: @@ -1633,6 +1625,10 @@ What: /sys/.../iio:deviceX/in_intensityY_uv_raw What: /sys/.../iio:deviceX/in_intensityY_uva_raw What: /sys/.../iio:deviceX/in_intensityY_uvb_raw What: /sys/.../iio:deviceX/in_intensityY_duv_raw +What: /sys/.../iio:deviceX/in_intensity_red_raw +What: /sys/.../iio:deviceX/in_intensity_green_raw +What: /sys/.../iio:deviceX/in_intensity_blue_raw +What: /sys/.../iio:deviceX/in_intensity_clear_raw KernelVersion: 3.4 Contact: linux-iio@vger.kernel.org Description: @@ -1691,16 +1687,19 @@ Description: Raw value of rotation from true/magnetic north measured with or without compensation from tilt sensors. -What: /sys/bus/iio/devices/iio:deviceX/in_currentX_raw -What: /sys/bus/iio/devices/iio:deviceX/in_currentX_i_raw -What: /sys/bus/iio/devices/iio:deviceX/in_currentX_q_raw -KernelVersion: 3.18 +What: /sys/bus/iio/devices/iio:deviceX/in_currentY_raw +What: /sys/bus/iio/devices/iio:deviceX/in_currentY_supply_raw +What: /sys/bus/iio/devices/iio:deviceX/in_currentY_i_raw +What: /sys/bus/iio/devices/iio:deviceX/in_currentY_q_raw +KernelVersion: 3.17 Contact: linux-iio@vger.kernel.org Description: - Raw current measurement from channel X. Units are in milliamps + Raw current measurement from channel Y. Units are in milliamps after application of scale and offset. If no offset or scale is present, output should be considered as processed with the - unit in milliamps. + unit in milliamps. In special cases where the channel does not + correspond to externally available input one of the named + versions may be used. Channels with 'i' and 'q' modifiers always exist in pairs and both channels refer to the same signal. The 'i' channel contains the in-phase @@ -1864,9 +1863,9 @@ Description: hardware fifo watermark level. What: /sys/bus/iio/devices/iio:deviceX/in_temp_calibemissivity -What: /sys/bus/iio/devices/iio:deviceX/in_tempX_calibemissivity +What: /sys/bus/iio/devices/iio:deviceX/in_tempY_calibemissivity What: /sys/bus/iio/devices/iio:deviceX/in_temp_object_calibemissivity -What: /sys/bus/iio/devices/iio:deviceX/in_tempX_object_calibemissivity +What: /sys/bus/iio/devices/iio:deviceX/in_tempY_object_calibemissivity KernelVersion: 4.1 Contact: linux-iio@vger.kernel.org Description: @@ -1887,17 +1886,17 @@ Description: is considered as one sample for <type>[_name]_sampling_frequency. What: /sys/bus/iio/devices/iio:deviceX/in_concentration_raw -What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw +What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_raw What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_raw -What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_co2_raw +What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_co2_raw What: /sys/bus/iio/devices/iio:deviceX/in_concentration_ethanol_raw -What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_ethanol_raw +What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_ethanol_raw What: /sys/bus/iio/devices/iio:deviceX/in_concentration_h2_raw -What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_h2_raw +What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_h2_raw What: /sys/bus/iio/devices/iio:deviceX/in_concentration_o2_raw -What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_o2_raw +What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_o2_raw What: /sys/bus/iio/devices/iio:deviceX/in_concentration_voc_raw -What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw +What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_voc_raw KernelVersion: 4.3 Contact: linux-iio@vger.kernel.org Description: @@ -1905,9 +1904,9 @@ Description: after application of scale and offset are percents. What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw -What: /sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw +What: /sys/bus/iio/devices/iio:deviceX/in_resistanceY_raw What: /sys/bus/iio/devices/iio:deviceX/out_resistance_raw -What: /sys/bus/iio/devices/iio:deviceX/out_resistanceX_raw +What: /sys/bus/iio/devices/iio:deviceX/out_resistanceY_raw KernelVersion: 4.3 Contact: linux-iio@vger.kernel.org Description: @@ -2096,7 +2095,7 @@ Description: One of the following thermocouple types: B, E, J, K, N, R, S, T. What: /sys/bus/iio/devices/iio:deviceX/in_temp_object_calibambient -What: /sys/bus/iio/devices/iio:deviceX/in_tempX_object_calibambient +What: /sys/bus/iio/devices/iio:deviceX/in_tempY_object_calibambient KernelVersion: 5.10 Contact: linux-iio@vger.kernel.org Description: @@ -2172,9 +2171,9 @@ Description: - a range specified as "[min step max]" -What: /sys/bus/iio/devices/iio:deviceX/in_voltageX_sampling_frequency +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_sampling_frequency What: /sys/bus/iio/devices/iio:deviceX/in_powerY_sampling_frequency -What: /sys/bus/iio/devices/iio:deviceX/in_currentZ_sampling_frequency +What: /sys/bus/iio/devices/iio:deviceX/in_currentY_sampling_frequency KernelVersion: 5.20 Contact: linux-iio@vger.kernel.org Description: diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad-sigma-delta b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad-sigma-delta new file mode 100644 index 000000000000..a5a8a579f4f3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad-sigma-delta @@ -0,0 +1,23 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_sys_calibration +KernelVersion: 5.5 +Contact: linux-iio@vger.kernel.org +Description: + This attribute, if available, initiates the system calibration procedure. This is done on a + single channel at a time. Write '1' to start the calibration. + +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_sys_calibration_mode_available +KernelVersion: 5.5 +Contact: linux-iio@vger.kernel.org +Description: + This attribute, if available, returns a list with the possible calibration modes. + There are two available options: + "zero_scale" - calibrate to zero scale + "full_scale" - calibrate to full scale + +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_sys_calibration_mode +KernelVersion: 5.5 +Contact: linux-iio@vger.kernel.org +Description: + This attribute, if available, sets up the calibration mode used in the system calibration + procedure. Reading returns the current calibration mode. + Writing sets the system calibration mode. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 index f8315202c8f0..28be1cabf112 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 @@ -19,33 +19,9 @@ Description: the bridge can be disconnected (when it is not being used using the bridge_switch_en attribute. -What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration -KernelVersion: -Contact: linux-iio@vger.kernel.org -Description: - Initiates the system calibration procedure. This is done on a - single channel at a time. Write '1' to start the calibration. - What: /sys/bus/iio/devices/iio:deviceX/in_voltage2-voltage2_shorted_raw KernelVersion: Contact: linux-iio@vger.kernel.org Description: Measure voltage from AIN2 pin connected to AIN(+) and AIN(-) shorted. - -What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration_mode_available -KernelVersion: -Contact: linux-iio@vger.kernel.org -Description: - Reading returns a list with the possible calibration modes. - There are two available options: - "zero_scale" - calibrate to zero scale - "full_scale" - calibrate to full scale - -What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration_mode -KernelVersion: -Contact: linux-iio@vger.kernel.org -Description: - Sets up the calibration mode used in the system calibration - procedure. Reading returns the current calibration mode. - Writing sets the system calibration mode. diff --git a/Documentation/ABI/testing/sysfs-class-chromeos b/Documentation/ABI/testing/sysfs-class-chromeos index 74ece942722e..7fa5be6cc774 100644 --- a/Documentation/ABI/testing/sysfs-class-chromeos +++ b/Documentation/ABI/testing/sysfs-class-chromeos @@ -31,3 +31,23 @@ Date: August 2015 KernelVersion: 4.2 Description: Show the information about the EC software and hardware. + +What: /sys/class/chromeos/cros_ec/usbpdmuxinfo +Date: February 2025 +Description: + Show PD mux status for each typec port with following flags: + - "USB": USB connected + - "DP": DP connected + - "POLARITY": CC line Polarity inverted + - "HPD_IRQ": Hot Plug Detect interrupt is asserted + - "HPD_LVL": Hot Plug Detect level is asserted + - "SAFE": DP is in safe mode + - "TBT": TBT enabled + - "USB4": USB4 enabled + +What: /sys/class/chromeos/cros_ec/ap_mode_entry +Date: February 2025 +Description: + Show if the AP mode entry EC feature is supported. + It indicates whether the EC waits for direction from the AP + to enter Type-C altmodes or USB4 mode. diff --git a/Documentation/ABI/testing/sysfs-class-platform-profile b/Documentation/ABI/testing/sysfs-class-platform-profile new file mode 100644 index 000000000000..dc72adfb830a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-platform-profile @@ -0,0 +1,48 @@ +What: /sys/class/platform-profile/platform-profile-X/name +Date: March 2025 +KernelVersion: 6.14 +Description: Name of the class device given by the driver. + + RO + +What: /sys/class/platform-profile/platform-profile-X/choices +Date: March 2025 +KernelVersion: 6.14 +Description: This file contains a space-separated list of profiles supported + for this device. + + Drivers must use the following standard profile-names: + + ==================== ======================================== + low-power Low power consumption + cool Cooler operation + quiet Quieter operation + balanced Balance between low power consumption + and performance + balanced-performance Balance between performance and low + power consumption with a slight bias + towards performance + performance High performance operation + custom Driver defined custom profile + ==================== ======================================== + + RO + +What: /sys/class/platform-profile/platform-profile-X/profile +Date: March 2025 +KernelVersion: 6.14 +Description: Reading this file gives the current selected profile for this + device. Writing this file with one of the strings from + platform_profile_choices changes the profile to the new value. + + This file can be monitored for changes by polling for POLLPRI, + POLLPRI will be signaled on any changes, independent of those + changes coming from a userspace write; or coming from another + source such as e.g. a hotkey triggered profile change handled + either directly by the embedded-controller or fully handled + inside the kernel. + + This file may also emit the string 'custom' to indicate + that the driver is using a driver defined custom profile. + + RW diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index 45180b62d426..2a5c1a09a28f 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -407,10 +407,30 @@ Description: Access: Read, Write + Reading this returns the current active value, e.g. 'Standard'. + Check charge_types to get the values supported by the battery. + Valid values: "Unknown", "N/A", "Trickle", "Fast", "Standard", "Adaptive", "Custom", "Long Life", "Bypass" +What: /sys/class/power_supply/<supply_name>/charge_types +Date: December 2024 +Contact: linux-pm@vger.kernel.org +Description: + Identical to charge_type but reading returns a list of supported + charge-types with the currently active type surrounded by square + brackets, e.g.: "Fast [Standard] Long_Life". + + power_supply class devices may support both charge_type and + charge_types for backward compatibility. In this case both will + always have the same active value and the active value can be + changed by writing either property. + + Note charge-types which contain a space such as "Long Life" will + have the space replaced by a '_' resulting in e.g. "Long_Life". + When writing charge-types both variants are accepted. + What: /sys/class/power_supply/<supply_name>/charge_term_current Date: July 2014 Contact: linux-pm@vger.kernel.org @@ -433,7 +453,7 @@ Description: Valid values: "Unknown", "Good", "Overheat", "Dead", - "Over voltage", "Unspecified failure", "Cold", + "Over voltage", "Under voltage", "Unspecified failure", "Cold", "Watchdog timer expire", "Safety timer expire", "Over current", "Calibration required", "Warm", "Cool", "Hot", "No battery" @@ -793,3 +813,12 @@ Description: Access: Read Valid values: 1-31 + +What: /sys/class/power_supply/<supply_name>/extensions/<extension_name> +Date: March 2025 +Contact: linux-pm@vger.kernel.org +Description: + Reports the extensions registered to the power supply. + Each entry is a link to the device which registered the extension. + + Access: Read diff --git a/Documentation/ABI/testing/sysfs-class-power-max1720x b/Documentation/ABI/testing/sysfs-class-power-max1720x new file mode 100644 index 000000000000..7d895bfda9ce --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-power-max1720x @@ -0,0 +1,32 @@ +What: /sys/class/power_supply/max1720x/temp_ain1 +Date: January 2025 +KernelVersion: 6.14 +Contact: Dimitri Fedrau <dimitri.fedrau@liebherr.com> +Description: + Reports the current temperature reading from AIN1 thermistor. + + Access: Read + + Valid values: Represented in 1/10 Degrees Celsius + +What: /sys/class/power_supply/max1720x/temp_ain2 +Date: January 2025 +KernelVersion: 6.14 +Contact: Dimitri Fedrau <dimitri.fedrau@liebherr.com> +Description: + Reports the current temperature reading from AIN2 thermistor. + + Access: Read + + Valid values: Represented in 1/10 Degrees Celsius + +What: /sys/class/power_supply/max1720x/temp_int +Date: January 2025 +KernelVersion: 6.14 +Contact: Dimitri Fedrau <dimitri.fedrau@liebherr.com> +Description: + Reports the current temperature reading from internal die. + + Access: Read + + Valid values: Represented in 1/10 Degrees Celsius diff --git a/Documentation/ABI/testing/sysfs-driver-amd-sfh b/Documentation/ABI/testing/sysfs-driver-amd-sfh new file mode 100644 index 000000000000..c053126a83bb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-amd-sfh @@ -0,0 +1,13 @@ +What: /sys/bus/pci/drivers/pcie_mp2_amd/*/hpd +Date: April 2025 +Contact: mario.limonciello@amd.com +Description: + Human presence detection (HPD) enable/disable. + When HPD is enabled, the device will be able to detect the + presence of a human and will send an interrupt that can be + used to wake the system from a low power state. + When HPD is disabled, the device will not be able to detect + the presence of a human. + + Access: Read/Write + Valid values: enabled/disabled diff --git a/Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd b/Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd new file mode 100644 index 000000000000..2a19584d091e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd @@ -0,0 +1,13 @@ +What: /sys/bus/hid/drivers/hid-appletb-kbd/<dev>/mode +Date: September, 2023 +KernelVersion: 6.5 +Contact: linux-input@vger.kernel.org +Description: + The set of keys displayed on the Touch Bar. + Valid values are: + == ================= + 0 Escape key only + 1 Function keys + 2 Media/brightness keys + 3 None + == ================= diff --git a/Documentation/ABI/testing/sysfs-edac-ecs b/Documentation/ABI/testing/sysfs-edac-ecs new file mode 100644 index 000000000000..87c885c4eb1a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-edac-ecs @@ -0,0 +1,74 @@ +What: /sys/bus/edac/devices/<dev-name>/ecs_fruX +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + The sysfs EDAC bus devices /<dev-name>/ecs_fruX subdirectory + pertains to the memory media ECS (Error Check Scrub) control + feature, where <dev-name> directory corresponds to a device + registered with the EDAC device driver for the ECS feature. + /ecs_fruX belongs to the media FRUs (Field Replaceable Unit) + under the memory device. + + The sysfs ECS attr nodes are only present if the parent + driver has implemented the corresponding attr callback + function and provided the necessary operations to the EDAC + device driver during registration. + +What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/log_entry_type +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The log entry type of how the DDR5 ECS log is reported. + + - 0 - per DRAM. + + - 1 - per memory media FRU. + + - All other values are reserved. + +What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/mode +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The mode of how the DDR5 ECS counts the errors. + Error count is tracked based on two different modes + selected by DDR5 ECS Control Feature - Codeword mode and + Row Count mode. If the ECS is under Codeword mode, then + the error count increments each time a codeword with check + bit errors is detected. If the ECS is under Row Count mode, + then the error counter increments each time a row with + check bit errors is detected. + + - 0 - ECS counts rows in the memory media that have ECC errors. + + - 1 - ECS counts codewords with errors, specifically, it counts + the number of ECC-detected errors in the memory media. + + - All other values are reserved. + +What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/reset +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (WO) ECS reset ECC counter. + + - 1 - reset ECC counter to the default value. + + - All other values are reserved. + +What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/threshold +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) DDR5 ECS threshold count per gigabits of memory cells. + The ECS error count is subject to the ECS Threshold count + per Gbit, which masks error counts less than the Threshold. + + Supported values are 256, 1024 and 4096. + + All other values are reserved. diff --git a/Documentation/ABI/testing/sysfs-edac-memory-repair b/Documentation/ABI/testing/sysfs-edac-memory-repair new file mode 100644 index 000000000000..0434a3b23ff3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-edac-memory-repair @@ -0,0 +1,206 @@ +What: /sys/bus/edac/devices/<dev-name>/mem_repairX +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + The sysfs EDAC bus devices /<dev-name>/mem_repairX subdirectory + pertains to the memory media repair features control, such as + PPR (Post Package Repair), memory sparing etc, where <dev-name> + directory corresponds to a device registered with the EDAC + device driver for the memory repair features. + + Post Package Repair is a maintenance operation requests the memory + device to perform a repair operation on its media. It is a memory + self-healing feature that fixes a failing memory location by + replacing it with a spare row in a DRAM device. For example, a + CXL memory device with DRAM components that support PPR features may + implement PPR maintenance operations. DRAM components may support + two types of PPR functions: hard PPR, for a permanent row repair, and + soft PPR, for a temporary row repair. Soft PPR may be much faster + than hard PPR, but the repair is lost with a power cycle. + + The sysfs attributes nodes for a repair feature are only + present if the parent driver has implemented the corresponding + attr callback function and provided the necessary operations + to the EDAC device driver during registration. + + In some states of system configuration (e.g. before address + decoders have been configured), memory devices (e.g. CXL) + may not have an active mapping in the main host address + physical address map. As such, the memory to repair must be + identified by a device specific physical addressing scheme + using a device physical address(DPA). The DPA and other control + attributes to use will be presented in related error records. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/repair_type +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RO) Memory repair type. For eg. post package repair, + memory sparing etc. Valid values are: + + - ppr - Post package repair. + + - cacheline-sparing + + - row-sparing + + - bank-sparing + + - rank-sparing + + - All other values are reserved. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/persist_mode +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) Get/Set the current persist repair mode set for a + repair function. Persist repair modes supported in the + device, based on a memory repair function, either is temporary, + which is lost with a power cycle or permanent. Valid values are: + + - 0 - Soft memory repair (temporary repair). + + - 1 - Hard memory repair (permanent repair). + + - All other values are reserved. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/repair_safe_when_in_use +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RO) True if memory media is accessible and data is retained + during the memory repair operation. + The data may not be retained and memory requests may not be + correctly processed during a repair operation. In such case + repair operation can not be executed at runtime. The memory + must be taken offline. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/hpa +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) Host Physical Address (HPA) of the memory to repair. + The HPA to use will be provided in related error records. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/dpa +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) Device Physical Address (DPA) of the memory to repair. + The specific DPA to use will be provided in related error + records. + + In some states of system configuration (e.g. before address + decoders have been configured), memory devices (e.g. CXL) + may not have an active mapping in the main host address + physical address map. As such, the memory to repair must be + identified by a device specific physical addressing scheme + using a DPA. The device physical address(DPA) to use will be + presented in related error records. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/nibble_mask +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) Read/Write Nibble mask of the memory to repair. + Nibble mask identifies one or more nibbles in error on the + memory bus that produced the error event. Nibble Mask bit 0 + shall be set if nibble 0 on the memory bus produced the + event, etc. For example, CXL PPR and sparing, a nibble mask + bit set to 1 indicates the request to perform repair + operation in the specific device. All nibble mask bits set + to 1 indicates the request to perform the operation in all + devices. Eg. for CXL memory repair, the specific value of + nibble mask to use will be provided in related error records. + For more details, See nibble mask field in CXL spec ver 3.1, + section 8.2.9.7.1.2 Table 8-103 soft PPR and section + 8.2.9.7.1.3 Table 8-104 hard PPR, section 8.2.9.7.1.4 + Table 8-105 memory sparing. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/min_hpa +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/max_hpa +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/min_dpa +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/max_dpa +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The supported range of memory address that is to be + repaired. The memory device may give the supported range of + attributes to use and it will depend on the memory device + and the portion of memory to repair. + The userspace may receive the specific value of attributes + to use for a repair operation from the memory device via + related error records and trace events, for eg. CXL DRAM + and CXL general media error records in CXL memory devices. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/bank_group +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/bank +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/rank +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/row +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/column +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/channel +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/sub_channel +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The control attributes for the memory to be repaired. + The specific value of attributes to use depends on the + portion of memory to repair and will be reported to the host + in related error records and be available to userspace + in trace events, such as CXL DRAM and CXL general media + error records of CXL memory devices. + + When readng back these attributes, it returns the current + value of memory requested to be repaired. + + bank_group - The bank group of the memory to repair. + + bank - The bank number of the memory to repair. + + rank - The rank of the memory to repair. Rank is defined as a + set of memory devices on a channel that together execute a + transaction. + + row - The row number of the memory to repair. + + column - The column number of the memory to repair. + + channel - The channel of the memory to repair. Channel is + defined as an interface that can be independently accessed + for a transaction. + + sub_channel - The subchannel of the memory to repair. + + The requirement to set these attributes varies based on the + repair function. The attributes in sysfs are not present + unless required for a repair function. + + For example, CXL spec ver 3.1, Section 8.2.9.7.1.2 Table 8-103 + soft PPR and Section 8.2.9.7.1.3 Table 8-104 hard PPR operations, + these attributes are not required to set. CXL spec ver 3.1, + Section 8.2.9.7.1.4 Table 8-105 memory sparing, these attributes + are required to set based on memory sparing granularity. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/repair +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (WO) Issue the memory repair operation for the specified + memory repair attributes. The operation may fail if resources + are insufficient based on the requirements of the memory + device and repair function. + + - 1 - Issue the repair operation. + + - All other values are reserved. diff --git a/Documentation/ABI/testing/sysfs-edac-scrub b/Documentation/ABI/testing/sysfs-edac-scrub new file mode 100644 index 000000000000..c43be90deab4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-edac-scrub @@ -0,0 +1,69 @@ +What: /sys/bus/edac/devices/<dev-name>/scrubX +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + The sysfs EDAC bus devices /<dev-name>/scrubX subdirectory + belongs to an instance of memory scrub control feature, + where <dev-name> directory corresponds to a device/memory + region registered with the EDAC device driver for the + scrub control feature. + + The sysfs scrub attr nodes are only present if the parent + driver has implemented the corresponding attr callback + function and provided the necessary operations to the EDAC + device driver during registration. + +What: /sys/bus/edac/devices/<dev-name>/scrubX/addr +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The base address of the memory region to be scrubbed + for on-demand scrubbing. Setting address starts scrubbing. + The size must be set before that. + + The readback addr value is non-zero if the requested + on-demand scrubbing is in progress, zero otherwise. + +What: /sys/bus/edac/devices/<dev-name>/scrubX/size +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The size of the memory region to be scrubbed + (on-demand scrubbing). + +What: /sys/bus/edac/devices/<dev-name>/scrubX/enable_background +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) Start/Stop background (patrol) scrubbing if supported. + +What: /sys/bus/edac/devices/<dev-name>/scrubX/min_cycle_duration +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RO) Supported minimum scrub cycle duration in seconds + by the memory scrubber. + +What: /sys/bus/edac/devices/<dev-name>/scrubX/max_cycle_duration +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RO) Supported maximum scrub cycle duration in seconds + by the memory scrubber. + +What: /sys/bus/edac/devices/<dev-name>/scrubX/current_cycle_duration +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The current scrub cycle duration in seconds and must be + within the supported range by the memory scrubber. + + Scrub has an overhead when running and that may want to be + reduced by taking longer to do it. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 3e1630c70d8a..e44bb614964b 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -347,7 +347,7 @@ Description: Used to control configure extension list: - [c] means add/del cold file extension What: /sys/fs/f2fs/<disk>/unusable -Date April 2019 +Date: April 2019 Contact: "Daniel Rosenberg" <drosen@google.com> Description: If checkpoint=disable, it displays the number of blocks that are unusable. @@ -355,7 +355,7 @@ Description: If checkpoint=disable, it displays the number of blocks that would be unusable if checkpoint=disable were to be set. What: /sys/fs/f2fs/<disk>/encoding -Date July 2019 +Date: July 2019 Contact: "Daniel Rosenberg" <drosen@google.com> Description: Displays name and version of the encoding set for the filesystem. If no encoding is set, displays (none) diff --git a/Documentation/ABI/testing/sysfs-kernel-livepatch b/Documentation/ABI/testing/sysfs-kernel-livepatch index 3735d868013d..3c3f36b32b57 100644 --- a/Documentation/ABI/testing/sysfs-kernel-livepatch +++ b/Documentation/ABI/testing/sysfs-kernel-livepatch @@ -55,6 +55,15 @@ Description: An attribute which indicates whether the patch supports atomic-replace. +What: /sys/kernel/livepatch/<patch>/stack_order +Date: Jan 2025 +KernelVersion: 6.14.0 +Description: + This attribute specifies the sequence in which live patch modules + are applied to the system. If multiple live patches modify the same + function, the implementation with the biggest 'stack_order' number + is used, unless a transition is currently in progress. + What: /sys/kernel/livepatch/<patch>/<object> Date: Nov 2014 KernelVersion: 3.19.0 diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon index f1b90cf1249b..b057eddefbfc 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-damon +++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon @@ -355,10 +355,15 @@ Description: If 'target' is written to the 'type' file, writing to or What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/matching Date: Dec 2022 Contact: SeongJae Park <sj@kernel.org> -Description: Writing 'Y' or 'N' to this file sets whether to filter out - pages that do or do not match to the 'type' and 'memcg_path', - respectively. Filter out means the action of the scheme will - not be applied to. +Description: Writing 'Y' or 'N' to this file sets whether the filter is for + the memory of the 'type', or all except the 'type'. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/allow +Date: Jan 2025 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing 'Y' or 'N' to this file sets whether to allow or reject + applying the scheme's action to the memory that satisfies the + 'type' and the 'matching' of the directory. What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/nr_tried Date: Mar 2022 @@ -384,6 +389,12 @@ Contact: SeongJae Park <sj@kernel.org> Description: Reading this file returns the total size of regions that the action of the scheme has successfully applied in bytes. +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/sz_ops_filter_passed +Date: Dec 2024 +Contact: SeongJae Park <sj@kernel.org> +Description: Reading this file returns the total size of memory that passed + DAMON operations layer-handled filters of the scheme in bytes. + What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/qt_exceeds Date: Mar 2022 Contact: SeongJae Park <sj@kernel.org> @@ -424,3 +435,10 @@ Contact: SeongJae Park <sj@kernel.org> Description: Reading this file returns the 'age' of a memory region that corresponding DAMON-based Operation Scheme's action has tried to be applied. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/sz_filter_passed +Date: Dec 2024 +Contact: SeongJae Park <sj@kernel.org> +Description: Reading this file returns the size of the memory in the region + that passed DAMON operations layer-handled filters of the + scheme in bytes. diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl index 65ed3865da62..09f783fa0a53 100644 --- a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl +++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl @@ -150,3 +150,13 @@ Description: The "mfg_lock" sysfs attribute is write-only. A successful write to this attribute will latch the board-level attributes into EEPROM, making them read-only. + +What: /sys/bus/platform/devices/MLNXBF04:00/rtc_battery +Date: June 2025 +KernelVersion: 6.15 +Contact: "Xiangrong Li <xiangrongl@nvidia.com>" +Description: + The "rtc_battery" sysfs attribute is read-only. + A successful read from this attribute returns the status of + the board's RTC battery. The RTC battery status register is + also cleared upon successful read operation. diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-pmc b/Documentation/ABI/testing/sysfs-platform-mellanox-pmc new file mode 100644 index 000000000000..29b3f9c58e00 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-mellanox-pmc @@ -0,0 +1,64 @@ +HID Driver Description +MLNXBFD0 mlxbf-pmc Performance counters (BlueField-1) +MLNXBFD1 mlxbf-pmc Performance counters (BlueField-2) +MLNXBFD2 mlxbf-pmc Performance counters (BlueField-3) + +What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/event_list +Date: Dec 2020 +KernelVersion: 5.10 +Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>" +Description: + List of events supported by the counters in the specific block. + It is used to extract the event number or ID associated with + each event. + +What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/event<N> +Date: Dec 2020 +KernelVersion: 5.10 +Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>" +Description: + Event monitored by corresponding counter. This is used to + program or read back the event that should be or is currently + being monitored by counter<N>. + +What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/counter<N> +Date: Dec 2020 +KernelVersion: 5.10 +Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>" +Description: + Counter value of the event being monitored. This is used to + read the counter value of the event which was programmed using + event<N>. This is also used to clear or reset the counter value + by writing 0 to the counter sysfs. + +What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/enable +Date: Dec 2020 +KernelVersion: 5.10 +Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>" +Description: + Start or stop counters. This is used to start the counters + for monitoring the programmed events and also to stop the + counters after the desired duration. Writing value 1 will + start all the counters in the block, and writing 0 will + stop all the counters together. + +What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/<reg> +Date: Dec 2020 +KernelVersion: 5.10 +Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>" +Description: + Value of register. This is used to read or reset the registers + where various performance statistics are counted for each block. + Writing 0 to the sysfs will clear the counter, writing any other + value is not allowed. + +What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/count_clock +Date: Mar 2025 +KernelVersion: 6.14 +Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>" +Description: + Use a counter for counting cycles. This is used to repurpose/dedicate + any of the counters in the block to counting cycles. Each counter is + represented by a bit (bit 0 for counter0, bit1 for counter1 and so on) + and setting the corresponding bit will reserve that specific counter + for counting cycles and override the event<N> setting. diff --git a/Documentation/ABI/testing/sysfs-platform_profile b/Documentation/ABI/testing/sysfs-platform_profile index baf1d125f9f8..125324ab53a9 100644 --- a/Documentation/ABI/testing/sysfs-platform_profile +++ b/Documentation/ABI/testing/sysfs-platform_profile @@ -33,3 +33,8 @@ Description: Reading this file gives the current selected profile for this source such as e.g. a hotkey triggered profile change handled either directly by the embedded-controller or fully handled inside the kernel. + + This file may also emit the string 'custom' to indicate + that multiple platform profiles drivers are in use but + have different values. This string can not be written to + this interface and is solely for informational purposes. diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index a3942b1036e2..2192478e83cf 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -131,7 +131,7 @@ Description: CAUTION: Using it will cause your machine's real-time (CMOS) clock to be set to a random invalid time after a resume. -What; /sys/power/pm_trace_dev_match +What: /sys/power/pm_trace_dev_match Date: October 2010 Contact: James Hogan <jhogan@kernel.org> Description: diff --git a/Documentation/ABI/testing/sysfs-pps-gen b/Documentation/ABI/testing/sysfs-pps-gen new file mode 100644 index 000000000000..2519207b88fd --- /dev/null +++ b/Documentation/ABI/testing/sysfs-pps-gen @@ -0,0 +1,43 @@ +What: /sys/class/pps-gen/ +Date: February 2025 +KernelVersion: 6.13 +Contact: Rodolfo Giometti <giometti@enneenne.com> +Description: + The /sys/class/pps-gen/ directory contains files and + directories that provide a unified interface to the PPS + generators. + +What: /sys/class/pps-gen/pps-genX/ +Date: February 2025 +KernelVersion: 6.13 +Contact: Rodolfo Giometti <giometti@enneenne.com> +Description: + The /sys/class/pps-gen/pps-genX/ directory is related to X-th + PPS generator in the system. Each directory contain files to + manage and control its PPS generator. + +What: /sys/class/pps-gen/pps-genX/enable +Date: February 2025 +KernelVersion: 6.13 +Contact: Rodolfo Giometti <giometti@enneenne.com> +Description: + This write-only file enables or disables generation of the + PPS signal. + +What: /sys/class/pps-gen/pps-genX/system +Date: February 2025 +KernelVersion: 6.13 +Contact: Rodolfo Giometti <giometti@enneenne.com> +Description: + This read-only file returns "1" if the generator takes the + timing from the system clock, while it returns "0" if not + (i.e. from a peripheral device clock). + +What: /sys/class/pps-gen/pps-genX/time +Date: February 2025 +KernelVersion: 6.13 +Contact: Rodolfo Giometti <giometti@enneenne.com> +Description: + This read-only file contains the current time stored into the + generator clock as two integers representing the current time + seconds and nanoseconds. diff --git a/Documentation/Makefile b/Documentation/Makefile index fa71602ec961..63094646df28 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -12,7 +12,7 @@ endif # Check for broken ABI files ifeq ($(CONFIG_WARN_ABI_ERRORS),y) -$(shell $(srctree)/scripts/get_abi.pl validate --dir $(srctree)/Documentation/ABI) +$(shell $(srctree)/scripts/get_abi.py --dir $(srctree)/Documentation/ABI validate) endif # You can set these variables from the command line. @@ -104,7 +104,7 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4) YNL_INDEX:=$(srctree)/Documentation/networking/netlink_spec/index.rst YNL_RST_DIR:=$(srctree)/Documentation/networking/netlink_spec YNL_YAML_DIR:=$(srctree)/Documentation/netlink/specs -YNL_TOOL:=$(srctree)/tools/net/ynl/ynl-gen-rst.py +YNL_TOOL:=$(srctree)/tools/net/ynl/pyynl/ynl_gen_rst.py YNL_RST_FILES_TMP := $(patsubst %.yaml,%.rst,$(wildcard $(YNL_YAML_DIR)/*.yaml)) YNL_RST_FILES := $(patsubst $(YNL_YAML_DIR)%,$(YNL_RST_DIR)%, $(YNL_RST_FILES_TMP)) diff --git a/Documentation/PCI/endpoint/pci-test-howto.rst b/Documentation/PCI/endpoint/pci-test-howto.rst index 909f770a07d6..aafc17ef3fd3 100644 --- a/Documentation/PCI/endpoint/pci-test-howto.rst +++ b/Documentation/PCI/endpoint/pci-test-howto.rst @@ -81,8 +81,8 @@ device, the following commands can be used:: # echo 0x104c > functions/pci_epf_test/func1/vendorid # echo 0xb500 > functions/pci_epf_test/func1/deviceid - # echo 16 > functions/pci_epf_test/func1/msi_interrupts - # echo 8 > functions/pci_epf_test/func1/msix_interrupts + # echo 32 > functions/pci_epf_test/func1/msi_interrupts + # echo 2048 > functions/pci_epf_test/func1/msix_interrupts Binding pci-epf-test Device to EP Controller @@ -123,113 +123,83 @@ above:: Using Endpoint Test function Device ----------------------------------- -pcitest.sh added in tools/pci/ can be used to run all the default PCI endpoint -tests. To compile this tool the following commands should be used:: +Kselftest added in tools/testing/selftests/pci_endpoint can be used to run all +the default PCI endpoint tests. To build the Kselftest for PCI endpoint +subsystem, the following commands should be used:: # cd <kernel-dir> - # make -C tools/pci + # make -C tools/testing/selftests/pci_endpoint or if you desire to compile and install in your system:: # cd <kernel-dir> - # make -C tools/pci install + # make -C tools/testing/selftests/pci_endpoint INSTALL_PATH=/usr/bin install -The tool and script will be located in <rootfs>/usr/bin/ +The test will be located in <rootfs>/usr/bin/ - -pcitest.sh Output -~~~~~~~~~~~~~~~~~ +Kselftest Output +~~~~~~~~~~~~~~~~ :: - # pcitest.sh - BAR tests - - BAR0: OKAY - BAR1: OKAY - BAR2: OKAY - BAR3: OKAY - BAR4: NOT OKAY - BAR5: NOT OKAY - - Interrupt tests - - SET IRQ TYPE TO LEGACY: OKAY - LEGACY IRQ: NOT OKAY - SET IRQ TYPE TO MSI: OKAY - MSI1: OKAY - MSI2: OKAY - MSI3: OKAY - MSI4: OKAY - MSI5: OKAY - MSI6: OKAY - MSI7: OKAY - MSI8: OKAY - MSI9: OKAY - MSI10: OKAY - MSI11: OKAY - MSI12: OKAY - MSI13: OKAY - MSI14: OKAY - MSI15: OKAY - MSI16: OKAY - MSI17: NOT OKAY - MSI18: NOT OKAY - MSI19: NOT OKAY - MSI20: NOT OKAY - MSI21: NOT OKAY - MSI22: NOT OKAY - MSI23: NOT OKAY - MSI24: NOT OKAY - MSI25: NOT OKAY - MSI26: NOT OKAY - MSI27: NOT OKAY - MSI28: NOT OKAY - MSI29: NOT OKAY - MSI30: NOT OKAY - MSI31: NOT OKAY - MSI32: NOT OKAY - SET IRQ TYPE TO MSI-X: OKAY - MSI-X1: OKAY - MSI-X2: OKAY - MSI-X3: OKAY - MSI-X4: OKAY - MSI-X5: OKAY - MSI-X6: OKAY - MSI-X7: OKAY - MSI-X8: OKAY - MSI-X9: NOT OKAY - MSI-X10: NOT OKAY - MSI-X11: NOT OKAY - MSI-X12: NOT OKAY - MSI-X13: NOT OKAY - MSI-X14: NOT OKAY - MSI-X15: NOT OKAY - MSI-X16: NOT OKAY - [...] - MSI-X2047: NOT OKAY - MSI-X2048: NOT OKAY - - Read Tests - - SET IRQ TYPE TO MSI: OKAY - READ ( 1 bytes): OKAY - READ ( 1024 bytes): OKAY - READ ( 1025 bytes): OKAY - READ (1024000 bytes): OKAY - READ (1024001 bytes): OKAY - - Write Tests - - WRITE ( 1 bytes): OKAY - WRITE ( 1024 bytes): OKAY - WRITE ( 1025 bytes): OKAY - WRITE (1024000 bytes): OKAY - WRITE (1024001 bytes): OKAY - - Copy Tests - - COPY ( 1 bytes): OKAY - COPY ( 1024 bytes): OKAY - COPY ( 1025 bytes): OKAY - COPY (1024000 bytes): OKAY - COPY (1024001 bytes): OKAY + # pci_endpoint_test + TAP version 13 + 1..16 + # Starting 16 tests from 9 test cases. + # RUN pci_ep_bar.BAR0.BAR_TEST ... + # OK pci_ep_bar.BAR0.BAR_TEST + ok 1 pci_ep_bar.BAR0.BAR_TEST + # RUN pci_ep_bar.BAR1.BAR_TEST ... + # OK pci_ep_bar.BAR1.BAR_TEST + ok 2 pci_ep_bar.BAR1.BAR_TEST + # RUN pci_ep_bar.BAR2.BAR_TEST ... + # OK pci_ep_bar.BAR2.BAR_TEST + ok 3 pci_ep_bar.BAR2.BAR_TEST + # RUN pci_ep_bar.BAR3.BAR_TEST ... + # OK pci_ep_bar.BAR3.BAR_TEST + ok 4 pci_ep_bar.BAR3.BAR_TEST + # RUN pci_ep_bar.BAR4.BAR_TEST ... + # OK pci_ep_bar.BAR4.BAR_TEST + ok 5 pci_ep_bar.BAR4.BAR_TEST + # RUN pci_ep_bar.BAR5.BAR_TEST ... + # OK pci_ep_bar.BAR5.BAR_TEST + ok 6 pci_ep_bar.BAR5.BAR_TEST + # RUN pci_ep_basic.CONSECUTIVE_BAR_TEST ... + # OK pci_ep_basic.CONSECUTIVE_BAR_TEST + ok 7 pci_ep_basic.CONSECUTIVE_BAR_TEST + # RUN pci_ep_basic.LEGACY_IRQ_TEST ... + # OK pci_ep_basic.LEGACY_IRQ_TEST + ok 8 pci_ep_basic.LEGACY_IRQ_TEST + # RUN pci_ep_basic.MSI_TEST ... + # OK pci_ep_basic.MSI_TEST + ok 9 pci_ep_basic.MSI_TEST + # RUN pci_ep_basic.MSIX_TEST ... + # OK pci_ep_basic.MSIX_TEST + ok 10 pci_ep_basic.MSIX_TEST + # RUN pci_ep_data_transfer.memcpy.READ_TEST ... + # OK pci_ep_data_transfer.memcpy.READ_TEST + ok 11 pci_ep_data_transfer.memcpy.READ_TEST + # RUN pci_ep_data_transfer.memcpy.WRITE_TEST ... + # OK pci_ep_data_transfer.memcpy.WRITE_TEST + ok 12 pci_ep_data_transfer.memcpy.WRITE_TEST + # RUN pci_ep_data_transfer.memcpy.COPY_TEST ... + # OK pci_ep_data_transfer.memcpy.COPY_TEST + ok 13 pci_ep_data_transfer.memcpy.COPY_TEST + # RUN pci_ep_data_transfer.dma.READ_TEST ... + # OK pci_ep_data_transfer.dma.READ_TEST + ok 14 pci_ep_data_transfer.dma.READ_TEST + # RUN pci_ep_data_transfer.dma.WRITE_TEST ... + # OK pci_ep_data_transfer.dma.WRITE_TEST + ok 15 pci_ep_data_transfer.dma.WRITE_TEST + # RUN pci_ep_data_transfer.dma.COPY_TEST ... + # OK pci_ep_data_transfer.dma.COPY_TEST + ok 16 pci_ep_data_transfer.dma.COPY_TEST + # PASSED: 16 / 16 tests passed. + # Totals: pass:16 fail:0 xfail:0 xpass:0 skip:0 error:0 + + +Testcase 16 (pci_ep_data_transfer.dma.COPY_TEST) will fail for most of the DMA +capable endpoint controllers due to the absence of the MEMCPY over DMA. For such +controllers, it is advisable to skip this testcase using this +command:: + + # pci_endpoint_test -f pci_ep_bar -f pci_ep_basic -v memcpy -T COPY_TEST -v dma diff --git a/Documentation/RCU/rcubarrier.rst b/Documentation/RCU/rcubarrier.rst index 6da7f66da2a8..12a7b059654f 100644 --- a/Documentation/RCU/rcubarrier.rst +++ b/Documentation/RCU/rcubarrier.rst @@ -329,10 +329,7 @@ Answer: was first added back in 2005. This is because on_each_cpu() disables preemption, which acted as an RCU read-side critical section, thus preventing CPU 0's grace period from completing - until on_each_cpu() had dealt with all of the CPUs. However, - with the advent of preemptible RCU, rcu_barrier() no longer - waited on nonpreemptible regions of code in preemptible kernels, - that being the job of the new rcu_barrier_sched() function. + until on_each_cpu() had dealt with all of the CPUs. However, with the RCU flavor consolidation around v4.20, this possibility was once again ruled out, because the consolidated diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst index 30080ff6f406..d1ccd6039a8c 100644 --- a/Documentation/RCU/stallwarn.rst +++ b/Documentation/RCU/stallwarn.rst @@ -96,6 +96,13 @@ warnings: the ``rcu_.*timer wakeup didn't happen for`` console-log message, which will include additional debugging information. +- A timer issue causes time to appear to jump forward, so that RCU + believes that the RCU CPU stall-warning timeout has been exceeded + when in fact much less time has passed. This could be due to + timer hardware bugs, timer driver bugs, or even corruption of + the "jiffies" global variable. These sorts of timer hardware + and driver bugs are not uncommon when testing new hardware. + - A low-level kernel issue that either fails to invoke one of the variants of rcu_eqs_enter(true), rcu_eqs_exit(true), ct_idle_enter(), ct_idle_exit(), ct_irq_enter(), or ct_irq_exit() on the one diff --git a/Documentation/accel/amdxdna/amdnpu.rst b/Documentation/accel/amdxdna/amdnpu.rst new file mode 100644 index 000000000000..fbe0a7585345 --- /dev/null +++ b/Documentation/accel/amdxdna/amdnpu.rst @@ -0,0 +1,281 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +.. include:: <isonum.txt> + +========= + AMD NPU +========= + +:Copyright: |copy| 2024 Advanced Micro Devices, Inc. +:Author: Sonal Santan <sonal.santan@amd.com> + +Overview +======== + +AMD NPU (Neural Processing Unit) is a multi-user AI inference accelerator +integrated into AMD client APU. NPU enables efficient execution of Machine +Learning applications like CNN, LLM, etc. NPU is based on +`AMD XDNA Architecture`_. NPU is managed by **amdxdna** driver. + + +Hardware Description +==================== + +AMD NPU consists of the following hardware components: + +AMD XDNA Array +-------------- + +AMD XDNA Array comprises of 2D array of compute and memory tiles built with +`AMD AI Engine Technology`_. Each column has 4 rows of compute tiles and 1 +row of memory tile. Each compute tile contains a VLIW processor with its own +dedicated program and data memory. The memory tile acts as L2 memory. The 2D +array can be partitioned at a column boundary creating a spatially isolated +partition which can be bound to a workload context. + +Each column also has dedicated DMA engines to move data between host DDR and +memory tile. + +AMD Phoenix and AMD Hawk Point client NPU have a 4x5 topology, i.e., 4 rows of +compute tiles arranged into 5 columns. AMD Strix Point client APU have 4x8 +topology, i.e., 4 rows of compute tiles arranged into 8 columns. + +Shared L2 Memory +---------------- + +The single row of memory tiles create a pool of software managed on chip L2 +memory. DMA engines are used to move data between host DDR and memory tiles. +AMD Phoenix and AMD Hawk Point NPUs have a total of 2560 KB of L2 memory. +AMD Strix Point NPU has a total of 4096 KB of L2 memory. + +Microcontroller +--------------- + +A microcontroller runs NPU Firmware which is responsible for command processing, +XDNA Array partition setup, XDNA Array configuration, workload context +management and workload orchestration. + +NPU Firmware uses a dedicated instance of an isolated non-privileged context +called ERT to service each workload context. ERT is also used to execute user +provided ``ctrlcode`` associated with the workload context. + +NPU Firmware uses a single isolated privileged context called MERT to service +management commands from the amdxdna driver. + +Mailboxes +--------- + +The microcontroller and amdxdna driver use a privileged channel for management +tasks like setting up of contexts, telemetry, query, error handling, setting up +user channel, etc. As mentioned before, privileged channel requests are +serviced by MERT. The privileged channel is bound to a single mailbox. + +The microcontroller and amdxdna driver use a dedicated user channel per +workload context. The user channel is primarily used for submitting work to +the NPU. As mentioned before, a user channel requests are serviced by an +instance of ERT. Each user channel is bound to its own dedicated mailbox. + +PCIe EP +------- + +NPU is visible to the x86 host CPU as a PCIe device with multiple BARs and some +MSI-X interrupt vectors. NPU uses a dedicated high bandwidth SoC level fabric +for reading or writing into host memory. Each instance of ERT gets its own +dedicated MSI-X interrupt. MERT gets a single instance of MSI-X interrupt. + +The number of PCIe BARs varies depending on the specific device. Based on their +functions, PCIe BARs can generally be categorized into the following types. + +* PSP BAR: Expose the AMD PSP (Platform Security Processor) function +* SMU BAR: Expose the AMD SMU (System Management Unit) function +* SRAM BAR: Expose ring buffers for the mailbox +* Mailbox BAR: Expose the mailbox control registers (head, tail and ISR + registers etc.) +* Public Register BAR: Expose public registers + +On specific devices, the above-mentioned BAR type might be combined into a +single physical PCIe BAR. Or a module might require two physical PCIe BARs to +be fully functional. For example, + +* On AMD Phoenix device, PSP, SMU, Public Register BARs are on PCIe BAR index 0. +* On AMD Strix Point device, Mailbox and Public Register BARs are on PCIe BAR + index 0. The PSP has some registers in PCIe BAR index 0 (Public Register BAR) + and PCIe BAR index 4 (PSP BAR). + +Process Isolation Hardware +-------------------------- + +As explained before, XDNA Array can be dynamically divided into isolated +spatial partitions, each of which may have one or more columns. The spatial +partition is setup by programming the column isolation registers by the +microcontroller. Each spatial partition is associated with a PASID which is +also programmed by the microcontroller. Hence multiple spatial partitions in +the NPU can make concurrent host access protected by PASID. + +The NPU FW itself uses microcontroller MMU enforced isolated contexts for +servicing user and privileged channel requests. + + +Mixed Spatial and Temporal Scheduling +===================================== + +AMD XDNA architecture supports mixed spatial and temporal (time sharing) +scheduling of 2D array. This means that spatial partitions may be setup and +torn down dynamically to accommodate various workloads. A *spatial* partition +may be *exclusively* bound to one workload context while another partition may +be *temporarily* bound to more than one workload contexts. The microcontroller +updates the PASID for a temporarily shared partition to match the context that +has been bound to the partition at any moment. + +Resource Solver +--------------- + +The Resource Solver component of the amdxdna driver manages the allocation +of 2D array among various workloads. Every workload describes the number +of columns required to run the NPU binary in its metadata. The Resource Solver +component uses hints passed by the workload and its own heuristics to +decide 2D array (re)partition strategy and mapping of workloads for spatial and +temporal sharing of columns. The FW enforces the context-to-column(s) resource +binding decisions made by the Resource Solver. + +AMD Phoenix and AMD Hawk Point client NPU can support 6 concurrent workload +contexts. AMD Strix Point can support 16 concurrent workload contexts. + + +Application Binaries +==================== + +A NPU application workload is comprised of two separate binaries which are +generated by the NPU compiler. + +1. AMD XDNA Array overlay, which is used to configure a NPU spatial partition. + The overlay contains instructions for setting up the stream switch + configuration and ELF for the compute tiles. The overlay is loaded on the + spatial partition bound to the workload by the associated ERT instance. + Refer to the + `Versal Adaptive SoC AIE-ML Architecture Manual (AM020)`_ for more details. + +2. ``ctrlcode``, used for orchestrating the overlay loaded on the spatial + partition. ``ctrlcode`` is executed by the ERT running in protected mode on + the microcontroller in the context of the workload. ``ctrlcode`` is made up + of a sequence of opcodes named ``XAie_TxnOpcode``. Refer to the + `AI Engine Run Time`_ for more details. + + +Special Host Buffers +==================== + +Per-context Instruction Buffer +------------------------------ + +Every workload context uses a host resident 64 MB buffer which is memory +mapped into the ERT instance created to service the workload. The ``ctrlcode`` +used by the workload is copied into this special memory. This buffer is +protected by PASID like all other input/output buffers used by that workload. +Instruction buffer is also mapped into the user space of the workload. + +Global Privileged Buffer +------------------------ + +In addition, the driver also allocates a single buffer for maintenance tasks +like recording errors from MERT. This global buffer uses the global IOMMU +domain and is only accessible by MERT. + + +High-level Use Flow +=================== + +Here are the steps to run a workload on AMD NPU: + +1. Compile the workload into an overlay and a ``ctrlcode`` binary. +2. Userspace opens a context in the driver and provides the overlay. +3. The driver checks with the Resource Solver for provisioning a set of columns + for the workload. +4. The driver then asks MERT to create a context on the device with the desired + columns. +5. MERT then creates an instance of ERT. MERT also maps the Instruction Buffer + into ERT memory. +6. The userspace then copies the ``ctrlcode`` to the Instruction Buffer. +7. Userspace then creates a command buffer with pointers to input, output, and + instruction buffer; it then submits command buffer with the driver and goes + to sleep waiting for completion. +8. The driver sends the command over the Mailbox to ERT. +9. ERT *executes* the ``ctrlcode`` in the instruction buffer. +10. Execution of the ``ctrlcode`` kicks off DMAs to and from the host DDR while + AMD XDNA Array is running. +11. When ERT reaches end of ``ctrlcode``, it raises an MSI-X to send completion + signal to the driver which then wakes up the waiting workload. + + +Boot Flow +========= + +amdxdna driver uses PSP to securely load signed NPU FW and kick off the boot +of the NPU microcontroller. amdxdna driver then waits for the alive signal in +a special location on BAR 0. The NPU is switched off during SoC suspend and +turned on after resume where the NPU FW is reloaded, and the handshake is +performed again. + + +Userspace components +==================== + +Compiler +-------- + +Peano is an LLVM based open-source compiler for AMD XDNA Array compute tile +available at: +https://github.com/Xilinx/llvm-aie + +The open-source IREE compiler supports graph compilation of ML models for AMD +NPU and uses Peano underneath. It is available at: +https://github.com/nod-ai/iree-amd-aie + +Usermode Driver (UMD) +--------------------- + +The open-source XRT runtime stack interfaces with amdxdna kernel driver. XRT +can be found at: +https://github.com/Xilinx/XRT + +The open-source XRT shim for NPU is can be found at: +https://github.com/amd/xdna-driver + + +DMA Operation +============= + +DMA operation instructions are encoded in the ``ctrlcode`` as +``XAIE_IO_BLOCKWRITE`` opcode. When ERT executes ``XAIE_IO_BLOCKWRITE``, DMA +operations between host DDR and L2 memory are effected. + + +Error Handling +============== + +When MERT detects an error in AMD XDNA Array, it pauses execution for that +workload context and sends an asynchronous message to the driver over the +privileged channel. The driver then sends a buffer pointer to MERT to capture +the register states for the partition bound to faulting workload context. The +driver then decodes the error by reading the contents of the buffer pointer. + + +Telemetry +========= + +MERT can report various kinds of telemetry information like the following: + +* L1 interrupt counter +* DMA counter +* Deep Sleep counter +* etc. + + +References +========== + +- `AMD XDNA Architecture <https://www.amd.com/en/technologies/xdna.html>`_ +- `AMD AI Engine Technology <https://www.xilinx.com/products/technology/ai-engine.html>`_ +- `Peano <https://github.com/Xilinx/llvm-aie>`_ +- `Versal Adaptive SoC AIE-ML Architecture Manual (AM020) <https://docs.amd.com/r/en-US/am020-versal-aie-ml>`_ +- `AI Engine Run Time <https://github.com/Xilinx/aie-rt/tree/release/main_aig>`_ diff --git a/Documentation/accel/amdxdna/index.rst b/Documentation/accel/amdxdna/index.rst new file mode 100644 index 000000000000..38c16939f1fc --- /dev/null +++ b/Documentation/accel/amdxdna/index.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +===================================== + accel/amdxdna NPU driver +===================================== + +The accel/amdxdna driver supports the AMD NPU (Neural Processing Unit). + +.. toctree:: + + amdnpu diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst index e94a0160b6a0..bc85f26533d8 100644 --- a/Documentation/accel/index.rst +++ b/Documentation/accel/index.rst @@ -8,6 +8,7 @@ Compute Accelerators :maxdepth: 1 introduction + amdxdna/index qaic/index .. only:: subproject and html diff --git a/Documentation/accounting/delay-accounting.rst b/Documentation/accounting/delay-accounting.rst index f61c01fc376e..210c194d4a7b 100644 --- a/Documentation/accounting/delay-accounting.rst +++ b/Documentation/accounting/delay-accounting.rst @@ -100,29 +100,29 @@ Get delays, since system boot, for pid 10:: # ./getdelays -d -p 10 (output similar to next case) -Get sum of delays, since system boot, for all pids with tgid 5:: +Get sum and peak of delays, since system boot, for all pids with tgid 242:: - # ./getdelays -d -t 5 + bash-4.4# ./getdelays -d -t 242 print delayacct stats ON - TGID 5 - - - CPU count real total virtual total delay total delay average - 8 7000000 6872122 3382277 0.423ms - IO count delay total delay average - 0 0 0.000ms - SWAP count delay total delay average - 0 0 0.000ms - RECLAIM count delay total delay average - 0 0 0.000ms - THRASHING count delay total delay average - 0 0 0.000ms - COMPACT count delay total delay average - 0 0 0.000ms - WPCOPY count delay total delay average - 0 0 0.000ms - IRQ count delay total delay average - 0 0 0.000ms + TGID 242 + + + CPU count real total virtual total delay total delay average delay max delay min + 39 156000000 156576579 2111069 0.054ms 0.212296ms 0.031307ms + IO count delay total delay average delay max delay min + 0 0 0.000ms 0.000000ms 0.000000ms + SWAP count delay total delay average delay max delay min + 0 0 0.000ms 0.000000ms 0.000000ms + RECLAIM count delay total delay average delay max delay min + 0 0 0.000ms 0.000000ms 0.000000ms + THRASHING count delay total delay average delay max delay min + 0 0 0.000ms 0.000000ms 0.000000ms + COMPACT count delay total delay average delay max delay min + 0 0 0.000ms 0.000000ms 0.000000ms + WPCOPY count delay total delay average delay max delay min + 156 11215873 0.072ms 0.207403ms 0.033913ms + IRQ count delay total delay average delay max delay min + 0 0 0.000ms 0.000000ms 0.000000ms Get IO accounting for pid 1, it works only with -p:: diff --git a/Documentation/accounting/taskstats-struct.rst b/Documentation/accounting/taskstats-struct.rst index ca90fd489c9a..acca51c34157 100644 --- a/Documentation/accounting/taskstats-struct.rst +++ b/Documentation/accounting/taskstats-struct.rst @@ -47,7 +47,7 @@ should not change the relative position of each field within the struct. 1) Common and basic accounting fields:: /* The version number of this struct. This field is always set to - * TAKSTATS_VERSION, which is defined in <linux/taskstats.h>. + * TASKSTATS_VERSION, which is defined in <linux/taskstats.h>. * Each time the struct is changed, the value should be incremented. */ __u16 version; diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst index f2bebff6a733..70b02f30013a 100644 --- a/Documentation/admin-guide/README.rst +++ b/Documentation/admin-guide/README.rst @@ -165,7 +165,7 @@ Configuring the kernel "make xconfig" Qt based configuration tool. - "make gconfig" GTK+ based configuration tool. + "make gconfig" GTK based configuration tool. "make oldconfig" Default all questions based on the contents of your existing ./.config file and asking about @@ -176,7 +176,7 @@ Configuring the kernel values without prompting. "make defconfig" Create a ./.config file by using the default - symbol values from either arch/$ARCH/defconfig + symbol values from either arch/$ARCH/configs/defconfig or arch/$ARCH/configs/${PLATFORM}_defconfig, depending on the architecture. @@ -356,5 +356,5 @@ instructions at 'Documentation/admin-guide/reporting-issues.rst'. Hints on understanding kernel bug reports are in 'Documentation/admin-guide/bug-hunting.rst'. More on debugging the kernel -with gdb is in 'Documentation/dev-tools/gdb-kernel-debugging.rst' and -'Documentation/dev-tools/kgdb.rst'. +with gdb is in 'Documentation/process/debugging/gdb-kernel-debugging.rst' and +'Documentation/process/debugging/kgdb.rst'. diff --git a/Documentation/admin-guide/abi-obsolete-files.rst b/Documentation/admin-guide/abi-obsolete-files.rst new file mode 100644 index 000000000000..3061a916b4b5 --- /dev/null +++ b/Documentation/admin-guide/abi-obsolete-files.rst @@ -0,0 +1,7 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Obsolete ABI Files +================== + +.. kernel-abi:: obsolete + :no-symbols: diff --git a/Documentation/admin-guide/abi-obsolete.rst b/Documentation/admin-guide/abi-obsolete.rst index 594e697aa1b2..640f3903e847 100644 --- a/Documentation/admin-guide/abi-obsolete.rst +++ b/Documentation/admin-guide/abi-obsolete.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + ABI obsolete symbols ==================== @@ -7,5 +9,5 @@ marked to be removed at some later point in time. The description of the interface will document the reason why it is obsolete and when it can be expected to be removed. -.. kernel-abi:: ABI/obsolete - :rst: +.. kernel-abi:: obsolete + :no-files: diff --git a/Documentation/admin-guide/abi-removed-files.rst b/Documentation/admin-guide/abi-removed-files.rst new file mode 100644 index 000000000000..f1bdfadd2ec4 --- /dev/null +++ b/Documentation/admin-guide/abi-removed-files.rst @@ -0,0 +1,7 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Removed ABI Files +================= + +.. kernel-abi:: removed + :no-symbols: diff --git a/Documentation/admin-guide/abi-removed.rst b/Documentation/admin-guide/abi-removed.rst index f9e000c81828..88832d3eacd6 100644 --- a/Documentation/admin-guide/abi-removed.rst +++ b/Documentation/admin-guide/abi-removed.rst @@ -1,5 +1,7 @@ +.. SPDX-License-Identifier: GPL-2.0 + ABI removed symbols =================== -.. kernel-abi:: ABI/removed - :rst: +.. kernel-abi:: removed + :no-files: diff --git a/Documentation/admin-guide/abi-stable-files.rst b/Documentation/admin-guide/abi-stable-files.rst new file mode 100644 index 000000000000..f867738fc178 --- /dev/null +++ b/Documentation/admin-guide/abi-stable-files.rst @@ -0,0 +1,7 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Stable ABI Files +================ + +.. kernel-abi:: stable + :no-symbols: diff --git a/Documentation/admin-guide/abi-stable.rst b/Documentation/admin-guide/abi-stable.rst index fc3361d847b1..528c68401f4b 100644 --- a/Documentation/admin-guide/abi-stable.rst +++ b/Documentation/admin-guide/abi-stable.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + ABI stable symbols ================== @@ -10,5 +12,5 @@ for at least 2 years. Most interfaces (like syscalls) are expected to never change and always be available. -.. kernel-abi:: ABI/stable - :rst: +.. kernel-abi:: stable + :no-files: diff --git a/Documentation/admin-guide/abi-testing-files.rst b/Documentation/admin-guide/abi-testing-files.rst new file mode 100644 index 000000000000..1da868e42fdb --- /dev/null +++ b/Documentation/admin-guide/abi-testing-files.rst @@ -0,0 +1,7 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Testing ABI Files +================= + +.. kernel-abi:: testing + :no-symbols: diff --git a/Documentation/admin-guide/abi-testing.rst b/Documentation/admin-guide/abi-testing.rst index 19767926b344..6153ebd38e2d 100644 --- a/Documentation/admin-guide/abi-testing.rst +++ b/Documentation/admin-guide/abi-testing.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + ABI testing symbols =================== @@ -16,5 +18,5 @@ Programs that use these interfaces are strongly encouraged to add their name to the description of these interfaces, so that the kernel developers can easily notify them if any changes occur. -.. kernel-abi:: ABI/testing - :rst: +.. kernel-abi:: testing + :no-files: diff --git a/Documentation/admin-guide/abi.rst b/Documentation/admin-guide/abi.rst index bcab3ef2597c..c6039359e585 100644 --- a/Documentation/admin-guide/abi.rst +++ b/Documentation/admin-guide/abi.rst @@ -1,7 +1,14 @@ +.. SPDX-License-Identifier: GPL-2.0 + ===================== Linux ABI description ===================== +.. kernel-abi:: README + +ABI symbols +----------- + .. toctree:: :maxdepth: 2 @@ -9,3 +16,14 @@ Linux ABI description abi-testing abi-obsolete abi-removed + +ABI files +--------- + +.. toctree:: + :maxdepth: 2 + + abi-stable-files + abi-testing-files + abi-obsolete-files + abi-removed-files diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst index 714a5171bfc0..1576fb93f06c 100644 --- a/Documentation/admin-guide/blockdev/zram.rst +++ b/Documentation/admin-guide/blockdev/zram.rst @@ -121,14 +121,14 @@ compression algorithm to use external pre-trained dictionary, pass full path to the `dict` along with other parameters:: #pass path to pre-trained zstd dictionary - echo "algo=zstd dict=/etc/dictioary" > /sys/block/zram0/algorithm_params + echo "algo=zstd dict=/etc/dictionary" > /sys/block/zram0/algorithm_params #same, but using algorithm priority - echo "priority=1 dict=/etc/dictioary" > \ + echo "priority=1 dict=/etc/dictionary" > \ /sys/block/zram0/algorithm_params #pass path to pre-trained zstd dictionary and compression level - echo "algo=zstd level=8 dict=/etc/dictioary" > \ + echo "algo=zstd level=8 dict=/etc/dictionary" > \ /sys/block/zram0/algorithm_params Parameters are algorithm specific: not all algorithms support pre-trained diff --git a/Documentation/admin-guide/braille-console.rst b/Documentation/admin-guide/braille-console.rst index 18e79337dcfd..153472e93cae 100644 --- a/Documentation/admin-guide/braille-console.rst +++ b/Documentation/admin-guide/braille-console.rst @@ -21,8 +21,8 @@ override the baud rate to 115200, etc. By default, the braille device will just show the last kernel message (console mode). To review previous messages, press the Insert key to switch to the VT review mode. In review mode, the arrow keys permit to browse in the VT content, -:kbd:`PAGE-UP`/:kbd:`PAGE-DOWN` keys go at the top/bottom of the screen, and -the :kbd:`HOME` key goes back +`PAGE-UP`/`PAGE-DOWN` keys go at the top/bottom of the screen, and +the `HOME` key goes back to the cursor, hence providing very basic screen reviewing facility. Sound feedback can be obtained by adding the ``braille_console.sound=1`` kernel diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst index 1d0f8ceb3075..ce6f4e8ca487 100644 --- a/Documentation/admin-guide/bug-hunting.rst +++ b/Documentation/admin-guide/bug-hunting.rst @@ -368,12 +368,3 @@ processed by ``klogd``:: Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128] Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3 ---------------------------------------------------------------------------- - -:: - - Dr. G.W. Wettstein Oncology Research Div. Computing Facility - Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com - 820 4th St. N. - Fargo, ND 58122 - Phone: 701-234-7556 diff --git a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst index 582d3427de3f..a964aff373b1 100644 --- a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst +++ b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst @@ -125,3 +125,7 @@ to unfreeze all tasks in the container:: This is the basic mechanism which should do the right thing for user space task in a simple scenario. + +This freezer implementation is affected by shortcomings (see commit +76f969e8948d8 ("cgroup: cgroup v2 freezer")) and cgroup v2 freezer is +recommended. diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 286d16fc22eb..02b8206a3594 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -90,6 +90,7 @@ Brief summary of control files. used. memory.swappiness set/show swappiness parameter of vmscan (See sysctl's vm.swappiness) + Per memcg knob does not exist in cgroup v2. memory.move_charge_at_immigrate This knob is deprecated. memory.oom_control set/show oom controls. This knob is deprecated and shouldn't be diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 315ede811c9d..f293a13b42ed 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -64,13 +64,14 @@ v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgrou 5-6. Device 5-7. RDMA 5-7-1. RDMA Interface Files - 5-8. HugeTLB - 5.8-1. HugeTLB Interface Files - 5-9. Misc - 5.9-1 Miscellaneous cgroup Interface Files - 5.9-2 Migration and Ownership - 5-10. Others - 5-10-1. perf_event + 5-8. DMEM + 5-9. HugeTLB + 5.9-1. HugeTLB Interface Files + 5-10. Misc + 5.10-1 Miscellaneous cgroup Interface Files + 5.10-2 Migration and Ownership + 5-11. Others + 5-11-1. perf_event 5-N. Non-normative information 5-N-1. CPU controller root cgroup process behaviour 5-N-2. IO controller root cgroup process behaviour @@ -1075,15 +1076,20 @@ cpufreq governor about the minimum desired frequency which should always be provided by a CPU, as well as the maximum desired frequency, which should not be exceeded by a CPU. -WARNING: cgroup2 doesn't yet support control of realtime processes. For -a kernel built with the CONFIG_RT_GROUP_SCHED option enabled for group -scheduling of realtime processes, the cpu controller can only be enabled -when all RT processes are in the root cgroup. This limitation does -not apply if CONFIG_RT_GROUP_SCHED is disabled. Be aware that system -management software may already have placed RT processes into nonroot -cgroups during the system boot process, and these processes may need -to be moved to the root cgroup before the cpu controller can be enabled -with a CONFIG_RT_GROUP_SCHED enabled kernel. +WARNING: cgroup2 cpu controller doesn't yet fully support the control of +realtime processes. For a kernel built with the CONFIG_RT_GROUP_SCHED option +enabled for group scheduling of realtime processes, the cpu controller can only +be enabled when all RT processes are in the root cgroup. Be aware that system +management software may already have placed RT processes into non-root cgroups +during the system boot process, and these processes may need to be moved to the +root cgroup before the cpu controller can be enabled with a +CONFIG_RT_GROUP_SCHED enabled kernel. + +With CONFIG_RT_GROUP_SCHED disabled, this limitation does not apply and some of +the interface files either affect realtime processes or account for them. See +the following section for details. Only the cpu controller is affected by +CONFIG_RT_GROUP_SCHED. Other controllers can be used for the resource control of +realtime processes irrespective of CONFIG_RT_GROUP_SCHED. CPU Interface Files @@ -2626,6 +2632,49 @@ RDMA Interface Files mlx4_0 hca_handle=1 hca_object=20 ocrdma1 hca_handle=1 hca_object=23 +DMEM +---- + +The "dmem" controller regulates the distribution and accounting of +device memory regions. Because each memory region may have its own page size, +which does not have to be equal to the system page size, the units are always bytes. + +DMEM Interface Files +~~~~~~~~~~~~~~~~~~~~ + + dmem.max, dmem.min, dmem.low + A readwrite nested-keyed file that exists for all the cgroups + except root that describes current configured resource limit + for a region. + + An example for xe follows:: + + drm/0000:03:00.0/vram0 1073741824 + drm/0000:03:00.0/stolen max + + The semantics are the same as for the memory cgroup controller, and are + calculated in the same way. + + dmem.capacity + A read-only file that describes maximum region capacity. + It only exists on the root cgroup. Not all memory can be + allocated by cgroups, as the kernel reserves some for + internal use. + + An example for xe follows:: + + drm/0000:03:00.0/vram0 8514437120 + drm/0000:03:00.0/stolen 67108864 + + dmem.current + A read-only file that describes current resource usage. + It exists for all the cgroup except root. + + An example for xe follows:: + + drm/0000:03:00.0/vram0 12550144 + drm/0000:03:00.0/stolen 8650752 + HugeTLB ------- diff --git a/Documentation/admin-guide/gpio/gpio-sim.rst b/Documentation/admin-guide/gpio/gpio-sim.rst index 1cc5567a4bbe..35d49ccd49e0 100644 --- a/Documentation/admin-guide/gpio/gpio-sim.rst +++ b/Documentation/admin-guide/gpio/gpio-sim.rst @@ -71,7 +71,7 @@ specific lines. The name of those subdirectories must take the form of: ``'line<offset>'`` (e.g. ``'line0'``, ``'line20'``, etc.) as the name will be used by the module to assign the config to the specific line at given offset. -Once the confiuration is complete, the ``'live'`` attribute must be set to 1 in +Once the configuration is complete, the ``'live'`` attribute must be set to 1 in order to instantiate the chip. It can be set back to 0 to destroy the simulated chip. The module will synchronously wait for the new simulated device to be successfully probed and if this doesn't happen, writing to ``'live'`` will diff --git a/Documentation/admin-guide/gpio/gpio-virtuser.rst b/Documentation/admin-guide/gpio/gpio-virtuser.rst index 2aca70db9f3b..7e7c0df51640 100644 --- a/Documentation/admin-guide/gpio/gpio-virtuser.rst +++ b/Documentation/admin-guide/gpio/gpio-virtuser.rst @@ -92,7 +92,7 @@ struct. The first two take string values as arguments: Activating GPIO consumers ------------------------- -Once the confiuration is complete, the ``'live'`` attribute must be set to 1 in +Once the configuration is complete, the ``'live'`` attribute must be set to 1 in order to instantiate the consumer. It can be set back to 0 to destroy the virtual device. The module will synchronously wait for the new simulated device to be successfully probed and if this doesn't happen, writing to ``'live'`` will diff --git a/Documentation/admin-guide/highuid.rst b/Documentation/admin-guide/highuid.rst deleted file mode 100644 index 6ee70465c0ea..000000000000 --- a/Documentation/admin-guide/highuid.rst +++ /dev/null @@ -1,80 +0,0 @@ -=================================================== -Notes on the change from 16-bit UIDs to 32-bit UIDs -=================================================== - -:Author: Chris Wing <wingc@umich.edu> -:Last updated: January 11, 2000 - -- kernel code MUST take into account __kernel_uid_t and __kernel_uid32_t - when communicating between user and kernel space in an ioctl or data - structure. - -- kernel code should use uid_t and gid_t in kernel-private structures and - code. - -What's left to be done for 32-bit UIDs on all Linux architectures: - -- Disk quotas have an interesting limitation that is not related to the - maximum UID/GID. They are limited by the maximum file size on the - underlying filesystem, because quota records are written at offsets - corresponding to the UID in question. - Further investigation is needed to see if the quota system can cope - properly with huge UIDs. If it can deal with 64-bit file offsets on all - architectures, this should not be a problem. - -- Decide whether or not to keep backwards compatibility with the system - accounting file, or if we should break it as the comments suggest - (currently, the old 16-bit UID and GID are still written to disk, and - part of the former pad space is used to store separate 32-bit UID and - GID) - -- Need to validate that OS emulation calls the 16-bit UID - compatibility syscalls, if the OS being emulated used 16-bit UIDs, or - uses the 32-bit UID system calls properly otherwise. - - This affects at least: - - - iBCS on Intel - - - sparc32 emulation on sparc64 - (need to support whatever new 32-bit UID system calls are added to - sparc32) - -- Validate that all filesystems behave properly. - - At present, 32-bit UIDs _should_ work for: - - - ext2 - - ufs - - isofs - - nfs - - coda - - udf - - Ioctl() fixups have been made for: - - - ncpfs - - smbfs - - Filesystems with simple fixups to prevent 16-bit UID wraparound: - - - minix - - sysv - - qnx4 - - Other filesystems have not been checked yet. - -- The ncpfs and smpfs filesystems cannot presently use 32-bit UIDs in - all ioctl()s. Some new ioctl()s have been added with 32-bit UIDs, but - more are needed. (as well as new user<->kernel data structures) - -- The ELF core dump format only supports 16-bit UIDs on arm, i386, m68k, - sh, and sparc32. Fixing this is probably not that important, but would - require adding a new ELF section. - -- The ioctl()s used to control the in-kernel NFS server only support - 16-bit UIDs on arm, i386, m68k, sh, and sparc32. - -- make sure that the UID mapping feature of AX25 networking works properly - (it should be safe because it's always used a 32-bit integer to - communicate between user and kernel) diff --git a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst index 0585d02b9a6c..ad15417d39f9 100644 --- a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst +++ b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst @@ -29,14 +29,6 @@ Below is the list of affected Intel processors [#f1]_: RAPTORLAKE_S 06_BFH =================== ============ -As an exception to this table, Intel Xeon E family parts ALDERLAKE(06_97H) and -RAPTORLAKE(06_B7H) codenamed Catlow are not affected. They are reported as -vulnerable in Linux because they share the same family/model with an affected -part. Unlike their affected counterparts, they do not enumerate RFDS_CLEAR or -CPUID.HYBRID. This information could be used to distinguish between the -affected and unaffected parts, but it is deemed not worth adding complexity as -the reporting is fixed automatically when these parts enumerate RFDS_NO. - Mitigation ========== Intel released a microcode update that enables software to clear sensitive diff --git a/Documentation/admin-guide/hw-vuln/srso.rst b/Documentation/admin-guide/hw-vuln/srso.rst index 2ad1c05b8c88..66af95251a3d 100644 --- a/Documentation/admin-guide/hw-vuln/srso.rst +++ b/Documentation/admin-guide/hw-vuln/srso.rst @@ -104,7 +104,20 @@ The possible values in this file are: (spec_rstack_overflow=ibpb-vmexit) + * 'Mitigation: Reduced Speculation': + This mitigation gets automatically enabled when the above one "IBPB on + VMEXIT" has been selected and the CPU supports the BpSpecReduce bit. + + It gets automatically enabled on machines which have the + SRSO_USER_KERNEL_NO=1 CPUID bit. In that case, the code logic is to switch + to the above =ibpb-vmexit mitigation because the user/kernel boundary is + not affected anymore and thus "safe RET" is not needed. + + After enabling the IBPB on VMEXIT mitigation option, the BpSpecReduce bit + is detected (functionality present on all such machines) and that + practically overrides IBPB on VMEXIT as it has a lot less performance + impact and takes care of the guest->host attack vector too. In order to exploit vulnerability, an attacker needs to: diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index e85b1adf5908..259d79fbeb94 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -7,6 +7,9 @@ added to the kernel over time. There is, as yet, little overall order or organization here — this material was not written to be a single, coherent document! With luck things will improve quickly over time. +General guides to kernel administration +--------------------------------------- + This initial section contains overall information, including the README file describing the kernel as a whole, documentation on kernel parameters, etc. @@ -15,19 +18,44 @@ etc. :maxdepth: 1 README - kernel-parameters devices - sysctl/index - abi features -This section describes CPU vulnerabilities and their mitigations. +A big part of the kernel's administrative interface is the /proc and sysfs +virtual filesystems; these documents describe how to interact with tem + +.. toctree:: + :maxdepth: 1 + + sysfs-rules + sysctl/index + cputopology + abi + +Security-related documentation: .. toctree:: :maxdepth: 1 hw-vuln/index + LSM/index + perf-security + +Booting the kernel +------------------ + +.. toctree:: + :maxdepth: 1 + + bootconfig + kernel-parameters + efi-stub + initrd + + +Tracking down and identifying problems +-------------------------------------- Here is a set of documents aimed at users who are trying to track down problems and bugs in particular. @@ -48,94 +76,119 @@ problems and bugs in particular. kdump/index perf/index pstore-blk + clearing-warn-once + kernel-per-CPU-kthreads + lockup-watchdogs + RAS/index + sysrq -This is the beginning of a section with information of interest to -application developers. Documents covering various aspects of the kernel -ABI will be found here. + +Core-kernel subsystems +---------------------- + +These documents describe core-kernel administration interfaces that are +likely to be of interest on almost any system. .. toctree:: :maxdepth: 1 - sysfs-rules + cgroup-v2 + cgroup-v1/index + cpu-load + mm/index + module-signing + namespaces/index + numastat + pm/index + syscall-user-dispatch -This is the beginning of a section with information of interest to -application developers and system integrators doing analysis of the -Linux kernel for safety critical applications. Documents supporting -analysis of kernel interactions with applications, and key kernel -subsystems expectations will be found here. +Support for non-native binary formats. Note that some of these +documents are ... old ... .. toctree:: :maxdepth: 1 - workload-tracing + binfmt-misc + java + mono -The rest of this manual consists of various unordered guides on how to -configure specific aspects of kernel behavior to your liking. + +Block-layer and filesystem administration +----------------------------------------- .. toctree:: :maxdepth: 1 - acpi/index - aoe/index - auxdisplay/index bcache binderfs - binfmt-misc blockdev/index - bootconfig - braille-console - btmrvl - cgroup-v1/index - cgroup-v2 cifs/index - clearing-warn-once - cpu-load - cputopology - dell_rbu device-mapper/index - edid - efi-stub ext4 filesystem-monitoring nfs/index - gpio/index - highuid - hw_random - initrd iostats - java jfs - kernel-per-CPU-kthreads + md + ufs + xfs + +Device-specific guides +---------------------- + +How to configure your hardware within your Linux system. + +.. toctree:: + :maxdepth: 1 + + acpi/index + aoe/index + auxdisplay/index + braille-console + btmrvl + dell_rbu + edid + gpio/index + hw_random laptops/index lcd-panel-cgram - ldm - lockup-watchdogs - LSM/index - md media/index - mm/index - module-signing - mono - namespaces/index - numastat + nvme-multipath parport - perf-security - pm/index pnp rapidio - RAS/index rtc serial-console svga - syscall-user-dispatch - sysrq thermal/index thunderbolt - ufs - unicode vga-softcursor video-output - xfs + +Workload analysis +----------------- + +This is the beginning of a section with information of interest to +application developers and system integrators doing analysis of the +Linux kernel for safety critical applications. Documents supporting +analysis of kernel interactions with applications, and key kernel +subsystems expectations will be found here. + +.. toctree:: + :maxdepth: 1 + + workload-tracing + +Everything else +--------------- + +A few hard-to-categorize and generally obsolete documents. + +.. toctree:: + :maxdepth: 1 + + ldm + unicode .. only:: subproject and html diff --git a/Documentation/admin-guide/iostats.rst b/Documentation/admin-guide/iostats.rst index 609a3201fd4e..9453196ade51 100644 --- a/Documentation/admin-guide/iostats.rst +++ b/Documentation/admin-guide/iostats.rst @@ -2,62 +2,39 @@ I/O statistics fields ===================== -Since 2.4.20 (and some versions before, with patches), and 2.5.45, -more extensive disk statistics have been introduced to help measure disk -activity. Tools such as ``sar`` and ``iostat`` typically interpret these and do -the work for you, but in case you are interested in creating your own -tools, the fields are explained here. - -In 2.4 now, the information is found as additional fields in -``/proc/partitions``. In 2.6 and upper, the same information is found in two -places: one is in the file ``/proc/diskstats``, and the other is within -the sysfs file system, which must be mounted in order to obtain -the information. Throughout this document we'll assume that sysfs -is mounted on ``/sys``, although of course it may be mounted anywhere. -Both ``/proc/diskstats`` and sysfs use the same source for the information -and so should not differ. - -Here are examples of these different formats:: - - 2.4: - 3 0 39082680 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160 - 3 1 9221278 hda1 35486 0 35496 38030 0 0 0 0 0 38030 38030 - - 2.6+ sysfs: - 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160 - 35486 38030 38030 38030 - - 2.6+ diskstats: - 3 0 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160 - 3 1 hda1 35486 38030 38030 38030 - - 4.18+ diskstats: - 3 0 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160 0 0 0 0 - -On 2.4 you might execute ``grep 'hda ' /proc/partitions``. On 2.6+, you have -a choice of ``cat /sys/block/hda/stat`` or ``grep 'hda ' /proc/diskstats``. - -The advantage of one over the other is that the sysfs choice works well -if you are watching a known, small set of disks. ``/proc/diskstats`` may -be a better choice if you are watching a large number of disks because -you'll avoid the overhead of 50, 100, or 500 or more opens/closes with -each snapshot of your disk statistics. - -In 2.4, the statistics fields are those after the device name. In -the above example, the first field of statistics would be 446216. -By contrast, in 2.6+ if you look at ``/sys/block/hda/stat``, you'll -find just the 15 fields, beginning with 446216. If you look at -``/proc/diskstats``, the 15 fields will be preceded by the major and -minor device numbers, and device name. Each of these formats provides -15 fields of statistics, each meaning exactly the same things. -All fields except field 9 are cumulative since boot. Field 9 should -go to zero as I/Os complete; all others only increase (unless they -overflow and wrap). Wrapping might eventually occur on a very busy -or long-lived system; so applications should be prepared to deal with -it. Regarding wrapping, the types of the fields are either unsigned -int (32 bit) or unsigned long (32-bit or 64-bit, depending on your -machine) as noted per-field below. Unless your observations are very -spread in time, these fields should not wrap twice before you notice it. +The kernel exposes disk statistics via ``/proc/diskstats`` and +``/sys/block/<device>/stat``. These stats are usually accessed via tools +such as ``sar`` and ``iostat``. + +Here are examples using a disk with two partitions:: + + /proc/diskstats: + 259 0 nvme0n1 255999 814 12369153 47919 996852 81 36123024 425995 0 301795 580470 0 0 0 0 60602 106555 + 259 1 nvme0n1p1 492 813 17572 96 848 81 108288 210 0 76 307 0 0 0 0 0 0 + 259 2 nvme0n1p2 255401 1 12343477 47799 996004 0 36014736 425784 0 344336 473584 0 0 0 0 0 0 + + /sys/block/nvme0n1/stat: + 255999 814 12369153 47919 996858 81 36123056 426009 0 301809 580491 0 0 0 0 60605 106562 + + /sys/block/nvme0n1/nvme0n1p1/stat: + 492 813 17572 96 848 81 108288 210 0 76 307 0 0 0 0 0 0 + +Both files contain the same 17 statistics. ``/sys/block/<device>/stat`` +contains the fields for ``<device>``. In ``/proc/diskstats`` the fields +are prefixed with the major and minor device numbers and the device +name. In the example above, the first stat value for ``nvme0n1`` is +255999 in both files. + +The sysfs ``stat`` file is efficient for monitoring a small, known set +of disks. If you're tracking a large number of devices, +``/proc/diskstats`` is often the better choice since it avoids the +overhead of opening and closing multiple files for each snapshot. + +All fields are cumulative, monotonic counters, except for field 9, which +resets to zero as I/Os complete. The remaining fields reset at boot, on +device reattachment or reinitialization, or when the underlying counter +overflows. Applications reading these counters should detect and handle +resets when comparing stat snapshots. Each set of stats only applies to the indicated device; if you want system-wide stats you'll have to find all the devices and sum them all up. diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst index 5376890adbeb..1f7f14c6e184 100644 --- a/Documentation/admin-guide/kdump/kdump.rst +++ b/Documentation/admin-guide/kdump/kdump.rst @@ -180,10 +180,6 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64) 1) On i386, enable high memory support under "Processor type and features":: - CONFIG_HIGHMEM64G=y - - or:: - CONFIG_HIGHMEM4G 2) With CONFIG_SMP=y, usually nr_cpus=1 need specified on the kernel diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 59931f21c974..39d0e7ff0965 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -194,8 +194,6 @@ is applicable:: WDT Watchdog support is enabled. X86-32 X86-32, aka i386 architecture is enabled. X86-64 X86-64 architecture is enabled. - More X86-64 boot options can be found in - Documentation/arch/x86/x86_64/boot-options.rst. X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64) X86_UV SGI UV support is enabled. XEN Xen support is enabled @@ -213,7 +211,6 @@ Do not modify the syntax of boot loader parameters without extreme need or coordination with <Documentation/arch/x86/boot.rst>. There are also arch-specific kernel-parameters not documented here. -See for example <Documentation/arch/x86/x86_64/boot-options.rst>. Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3872bc6ec49d..f0f1b9e0ebcb 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -21,6 +21,10 @@ strictly ACPI specification compliant. rsdt -- prefer RSDT over (default) XSDT copy_dsdt -- copy DSDT to memory + nocmcff -- Disable firmware first mode for corrected + errors. This disables parsing the HEST CMC error + source to check if firmware has set the FF flag. This + may result in duplicate corrected error reports. nospcr -- disable console in ACPI SPCR table as default _serial_ console on ARM64 For ARM64, ONLY "acpi=off", "acpi=on", "acpi=force" or @@ -405,15 +409,13 @@ not play well with APC CPU idle - disable it if you have APC and your system crashes randomly. + apic [APIC,X86-64] Use IO-APIC. Default. + apic= [APIC,X86,EARLY] Advanced Programmable Interrupt Controller Change the output verbosity while booting Format: { quiet (default) | verbose | debug } Change the amount of debugging information output when initialising the APIC and IO-APIC components. - For X86-32, this can also be used to specify an APIC - driver name. - Format: apic=driver_name - Examples: apic=bigsmp apic_extnmi= [APIC,X86,EARLY] External NMI delivery setting Format: { bsp (default) | all | none } @@ -424,6 +426,10 @@ useful so that a dump capture kernel won't be shot down by NMI + apicpmtimer Do APIC timer calibration using the pmtimer. Implies + apicmaintimer. Useful when your PIT timer is totally + broken. + autoconf= [IPV6] See Documentation/networking/ipv6.rst. @@ -1726,6 +1732,8 @@ off: Disable GDS mitigation. + gbpages [X86] Use GB pages for kernel direct mappings. + gcov_persist= [GCOV] When non-zero (default), profiling data for kernel modules is saved and remains accessible via debugfs, even when the module is unloaded/reloaded. @@ -1773,7 +1781,9 @@ allocation boundaries as a proactive defense against bounds-checking flaws in the kernel's copy_to_user()/copy_from_user() interface. - on Perform hardened usercopy checks (default). + The default is determined by + CONFIG_HARDENED_USERCOPY_DEFAULT_ON. + on Perform hardened usercopy checks. off Disable hardened usercopy checks. hardlockup_all_cpu_backtrace= @@ -2008,12 +2018,21 @@ idle= [X86,EARLY] Format: idle=poll, idle=halt, idle=nomwait - Poll forces a polling idle loop that can slightly - improve the performance of waking up a idle CPU, but - will use a lot of power and make the system run hot. - Not recommended. + + idle=poll: Don't do power saving in the idle loop + using HLT, but poll for rescheduling event. This will + make the CPUs eat a lot more power, but may be useful + to get slightly better performance in multiprocessor + benchmarks. It also makes some profiling using + performance counters more accurate. Please note that + on systems with MONITOR/MWAIT support (like Intel + EM64T CPUs) this option has no performance advantage + over the normal idle loop. It may also interact badly + with hyperthreading. + idle=halt: Halt is forced to be used for CPU idle. In such case C2/C3 won't be used again. + idle=nomwait: Disable mwait for CPU C-states idxd.sva= [HW] @@ -2295,6 +2314,9 @@ per_cpu_perf_limits Allow per-logical-CPU P-State performance control limits using cpufreq sysfs interface + no_cas + Do not enable capacity-aware scheduling (CAS) on + hybrid systems intremap= [X86-64,Intel-IOMMU,EARLY] on enable Interrupt Remapping (default) @@ -2311,20 +2333,73 @@ relaxed iommu= [X86,EARLY] + off + Don't initialize and use any kind of IOMMU. + force + Force the use of the hardware IOMMU even when + it is not actually needed (e.g. because < 3 GB + memory). + noforce + Don't force hardware IOMMU usage when it is not + needed. (default). + biomerge panic nopanic merge nomerge + soft - pt [X86] - nopt [X86] - nobypass [PPC/POWERNV] + Use software bounce buffering (SWIOTLB) (default for + Intel machines). This can be used to prevent the usage + of an available hardware IOMMU. + + [X86] + pt + [X86] + nopt + [PPC/POWERNV] + nobypass Disable IOMMU bypass, using IOMMU for PCI devices. + [X86] + AMD Gart HW IOMMU-specific options: + + <size> + Set the size of the remapping area in bytes. + + allowed + Overwrite iommu off workarounds for specific chipsets + + fullflush + Flush IOMMU on each allocation (default). + + nofullflush + Don't use IOMMU fullflush. + + memaper[=<order>] + Allocate an own aperture over RAM with size + 32MB<<order. (default: order=1, i.e. 64MB) + + merge + Do scatter-gather (SG) merging. Implies "force" + (experimental). + + nomerge + Don't do scatter-gather (SG) merging. + + noaperture + Ask the IOMMU not to touch the aperture for AGP. + + noagp + Don't initialize the AGP driver and use full aperture. + + panic + Always panic when IOMMU overflows. + iommu.forcedac= [ARM64,X86,EARLY] Control IOVA allocation for PCI devices. Format: { "0" | "1" } 0 - Try to allocate a 32-bit DMA address first, before @@ -2432,7 +2507,9 @@ specified in the flag list (default: domain): nohz - Disable the tick when a single task runs. + Disable the tick when a single task runs as well as + disabling other kernel noises like having RCU callbacks + offloaded. This is equivalent to the nohz_full parameter. A residual 1Hz tick is offloaded to workqueues, which you need to affine to housekeeping through the global @@ -2695,7 +2772,7 @@ VMs, i.e. on the 0=>1 and 1=>0 transitions of the number of VMs. - Enabling virtualization at module lode avoids potential + Enabling virtualization at module load avoids potential latency for creation of the 0=>1 VM, as KVM serializes virtualization enabling across all online CPUs. The "cost" of enabling virtualization when KVM is loaded, @@ -2748,17 +2825,21 @@ nvhe: Standard nVHE-based mode, without support for protected guests. - protected: nVHE-based mode with support for guests whose - state is kept private from the host. + protected: Mode with support for guests whose state is + kept private from the host, using VHE or + nVHE depending on HW support. nested: VHE-based mode with support for nested - virtualization. Requires at least ARMv8.3 - hardware. + virtualization. Requires at least ARMv8.4 + hardware (with FEAT_NV2). Defaults to VHE/nVHE based on hardware support. Setting mode to "protected" will disable kexec and hibernation - for the host. "nested" is experimental and should be - used with extreme caution. + for the host. To force nVHE on VHE hardware, add + "arm64_sw.hvhe=0 id_aa64mmfr1.vh=0" to the + command-line. + "nested" is experimental and should be used with + extreme caution. kvm-arm.vgic_v3_group0_trap= [KVM,ARM,EARLY] Trap guest accesses to GICv3 group-0 @@ -3259,9 +3340,77 @@ devices can be requested on-demand with the /dev/loop-control interface. - mce [X86-32] Machine Check Exception + mce= [X86-{32,64}] + + Please see Documentation/arch/x86/x86_64/machinecheck.rst for sysfs runtime tunables. + + off + disable machine check + + no_cmci + disable CMCI(Corrected Machine Check Interrupt) that + Intel processor supports. Usually this disablement is + not recommended, but it might be handy if your + hardware is misbehaving. + + Note that you'll get more problems without CMCI than + with due to the shared banks, i.e. you might get + duplicated error logs. + + dont_log_ce + don't make logs for corrected errors. All events + reported as corrected are silently cleared by OS. This + option will be useful if you have no interest in any + of corrected errors. + + ignore_ce + disable features for corrected errors, e.g. + polling timer and CMCI. All events reported as + corrected are not cleared by OS and remained in its + error banks. + + Usually this disablement is not recommended, however + if there is an agent checking/clearing corrected + errors (e.g. BIOS or hardware monitoring + applications), conflicting with OS's error handling, + and you cannot deactivate the agent, then this option + will be a help. + + no_lmce + do not opt-in to Local MCE delivery. Use legacy method + to broadcast MCEs. + + bootlog + enable logging of machine checks left over from + booting. Disabled by default on AMD Fam10h and older + because some BIOS leave bogus ones. + + If your BIOS doesn't do that it's a good idea to + enable though to make sure you log even machine check + events that result in a reboot. On Intel systems it is + enabled by default. + + nobootlog + disable boot machine check logging. + + monarchtimeout (number) + sets the time in us to wait for other CPUs on machine + checks. 0 to disable. + + bios_cmci_threshold + don't overwrite the bios-set CMCI threshold. This boot + option prevents Linux from overwriting the CMCI + threshold set by the bios. Without this option, Linux + always sets the CMCI threshold to 1. Enabling this may + make memory predictive failure analysis less effective + if the bios sets thresholds for memory errors since we + will not see details for all errors. + + recovery + force-enable recoverable machine check code paths + + Everything else is in sysfs now. - mce=option [X86-64] See Documentation/arch/x86/x86_64/boot-options.rst md= [HW] RAID subsystems devices and level See Documentation/admin-guide/md.rst. @@ -3351,8 +3500,8 @@ [KNL] Set the initial state for the memory hotplug onlining policy. If not specified, the default value is set according to the - CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE kernel config - option. + CONFIG_MHP_DEFAULT_ONLINE_TYPE kernel config + options. See Documentation/admin-guide/mm/memory-hotplug.rst. memmap=exactmap [KNL,X86,EARLY] Enable setting of an exact @@ -3887,6 +4036,8 @@ noapic [SMP,APIC,EARLY] Tells the kernel to not make use of any IOAPICs that may be present in the system. + noapictimer [APIC,X86] Don't set up the APIC timer + noautogroup Disable scheduler automatic task group creation. nocache [ARM,EARLY] @@ -3934,6 +4085,8 @@ register save and restore. The kernel will only save legacy floating-point registers on task switch. + nogbpages [X86] Do not use GB pages for kernel direct mappings. + no_hash_pointers [KNL,EARLY] Force pointers printed to the console or buffers to be @@ -3960,6 +4113,8 @@ the impact of the sleep instructions. This is also useful when using JTAG debugger. + nohpet [X86] Don't use the HPET timer. + nohugeiomap [KNL,X86,PPC,ARM64,EARLY] Disable kernel huge I/O mappings. nohugevmalloc [KNL,X86,PPC,ARM64,EARLY] Disable kernel huge vmalloc mappings. @@ -4111,8 +4266,10 @@ nosync [HW,M68K] Disables sync negotiation for all devices. - no_timer_check [X86,APIC] Disables the code which tests for - broken timer IRQ sources. + no_timer_check [X86,APIC] Disables the code which tests for broken + timer IRQ sources, i.e., the IO-APIC timer. This can + work around problems with incorrect timer + initialization on some boards. no_uaccess_flush [PPC,EARLY] Don't flush the L1-D cache after accessing user data. @@ -4192,6 +4349,11 @@ If given as an integer followed by 'U', it will divide each physical node into N emulated nodes. + numa=noacpi [X86] Don't parse the SRAT table for NUMA setup + + numa=nohmat [X86] Don't parse the HMAT table for NUMA setup, or + soft-reserved memory partitioning. + numa_balancing= [KNL,ARM64,PPC,RISCV,S390,X86] Enable or disable automatic NUMA balancing. Allowed values are enable and disable @@ -4673,7 +4835,7 @@ '1' – force enabled 'x' – unchanged For example, - pci=config_acs=10x + pci=config_acs=10x@pci:0:0 would configure all devices that support ACS to enable P2P Request Redirect, disable Translation Blocking, and leave Source @@ -5367,7 +5529,42 @@ rcutorture.gp_cond= [KNL] Use conditional/asynchronous update-side - primitives, if available. + normal-grace-period primitives, if available. + + rcutorture.gp_cond_exp= [KNL] + Use conditional/asynchronous update-side + expedited-grace-period primitives, if available. + + rcutorture.gp_cond_full= [KNL] + Use conditional/asynchronous update-side + normal-grace-period primitives that also take + concurrent expedited grace periods into account, + if available. + + rcutorture.gp_cond_exp_full= [KNL] + Use conditional/asynchronous update-side + expedited-grace-period primitives that also take + concurrent normal grace periods into account, + if available. + + rcutorture.gp_cond_wi= [KNL] + Nominal wait interval for normal conditional + grace periods (specified by rcutorture's + gp_cond and gp_cond_full module parameters), + in microseconds. The actual wait interval will + be randomly selected to nanosecond granularity up + to this wait interval. Defaults to 16 jiffies, + for example, 16,000 microseconds on a system + with HZ=1000. + + rcutorture.gp_cond_wi_exp= [KNL] + Nominal wait interval for expedited conditional + grace periods (specified by rcutorture's + gp_cond_exp and gp_cond_exp_full module + parameters), in microseconds. The actual wait + interval will be randomly selected to nanosecond + granularity up to this wait interval. Defaults to + 128 microseconds. rcutorture.gp_exp= [KNL] Use expedited update-side primitives, if available. @@ -5376,6 +5573,43 @@ Use normal (non-expedited) asynchronous update-side primitives, if available. + rcutorture.gp_poll= [KNL] + Use polled update-side normal-grace-period + primitives, if available. + + rcutorture.gp_poll_exp= [KNL] + Use polled update-side expedited-grace-period + primitives, if available. + + rcutorture.gp_poll_full= [KNL] + Use polled update-side normal-grace-period + primitives that also take concurrent expedited + grace periods into account, if available. + + rcutorture.gp_poll_exp_full= [KNL] + Use polled update-side expedited-grace-period + primitives that also take concurrent normal + grace periods into account, if available. + + rcutorture.gp_poll_wi= [KNL] + Nominal wait interval for normal conditional + grace periods (specified by rcutorture's + gp_poll and gp_poll_full module parameters), + in microseconds. The actual wait interval will + be randomly selected to nanosecond granularity up + to this wait interval. Defaults to 16 jiffies, + for example, 16,000 microseconds on a system + with HZ=1000. + + rcutorture.gp_poll_wi_exp= [KNL] + Nominal wait interval for expedited conditional + grace periods (specified by rcutorture's + gp_poll_exp and gp_poll_exp_full module + parameters), in microseconds. The actual wait + interval will be randomly selected to nanosecond + granularity up to this wait interval. Defaults to + 128 microseconds. + rcutorture.gp_sync= [KNL] Use normal (non-expedited) synchronous update-side primitives, if available. If all @@ -5429,6 +5663,22 @@ Set time (jiffies) between CPU-hotplug operations, or zero to disable CPU-hotplug testing. + rcutorture.preempt_duration= [KNL] + Set duration (in milliseconds) of preemptions + by a high-priority FIFO real-time task. Set to + zero (the default) to disable. The CPUs to + preempt are selected randomly from the set that + are online at a given point in time. Races with + CPUs going offline are ignored, with that attempt + at preemption skipped. + + rcutorture.preempt_interval= [KNL] + Set interval (in milliseconds, defaulting to one + second) between preemptions by a high-priority + FIFO real-time task. This delay is mediated + by an hrtimer and is further fuzzed to avoid + inadvertent synchronizations. + rcutorture.read_exit_burst= [KNL] The number of times in a given read-then-exit episode that a set of read-then-exit kthreads @@ -5509,6 +5759,11 @@ rcutorture.test_boost_duration= [KNL] Duration (s) of each individual boost test. + rcutorture.test_boost_holdoff= [KNL] + Holdoff time (s) from start of test to the start + of RCU priority-boost testing. Defaults to zero, + that is, no holdoff. + rcutorture.test_boost_interval= [KNL] Interval (s) between each boost test. @@ -5715,6 +5970,55 @@ reboot_cpu is s[mp]#### with #### being the processor to be used for rebooting. + acpi + Use the ACPI RESET_REG in the FADT. If ACPI is not + configured or the ACPI reset does not work, the reboot + path attempts the reset using the keyboard controller. + + bios + Use the CPU reboot vector for warm reset + + cold + Set the cold reboot flag + + default + There are some built-in platform specific "quirks" + - you may see: "reboot: <name> series board detected. + Selecting <type> for reboots." In the case where you + think the quirk is in error (e.g. you have newer BIOS, + or newer board) using this option will ignore the + built-in quirk table, and use the generic default + reboot actions. + + efi + Use efi reset_system runtime service. If EFI is not + configured or the EFI reset does not work, the reboot + path attempts the reset using the keyboard controller. + + force + Don't stop other CPUs on reboot. This can make reboot + more reliable in some cases. + + kbd + Use the keyboard controller. cold reset (default) + + pci + Use a write to the PCI config space register 0xcf9 to + trigger reboot. + + triple + Force a triple fault (init) + + warm + Don't set the cold reboot flag + + Using warm reset will be much faster especially on big + memory systems because the BIOS will not go through + the memory check. Disadvantage is that not all + hardware will be completely reinitialized on reboot so + there may be boot problems on some systems. + + refscale.holdoff= [KNL] Set test-start holdoff period. The purpose of this parameter is to delay the start of the @@ -5784,7 +6088,7 @@ is assumed to be I/O ports; otherwise it is memory. reserve_mem= [RAM] - Format: nn[KNG]:<align>:<label> + Format: nn[KMG]:<align>:<label> Reserve physical memory and label it with a name that other subsystems can use to access it. This is typically used for systems that do not wipe the RAM, and this command @@ -6106,7 +6410,16 @@ serialnumber [BUGS=X86-32] - sev=option[,option...] [X86-64] See Documentation/arch/x86/x86_64/boot-options.rst + sev=option[,option...] [X86-64] + + debug + Enable debug messages. + + nosnp + Do not enable SEV-SNP (applies to host/hypervisor + only). Setting 'nosnp' avoids the RMP check overhead + in memory accesses when users do not want to run + SEV-SNP guests. shapers= [NET] Maximal number of shapers. @@ -6275,6 +6588,8 @@ Selecting 'on' will also enable the mitigation against user space to user space task attacks. + Selecting specific mitigation does not force enable + user mitigations. Selecting 'off' will disable both the kernel and the user space protections. @@ -6858,6 +7173,14 @@ comma-separated list of trace events to enable. See also Documentation/trace/events.rst + To enable modules, use :mod: keyword: + + trace_event=:mod:<module> + + The value before :mod: will only enable specific events + that are part of the module. See the above mentioned + document for more information. + trace_instance=[instance-info] [FTRACE] Create a ring buffer instance early in boot up. This will be listed in: @@ -6992,6 +7315,13 @@ See Documentation/admin-guide/mm/transhuge.rst for more details. + transparent_hugepage_tmpfs= [KNL] + Format: [always|within_size|advise|never] + Can be used to control the default hugepage allocation policy + for the tmpfs mount. + See Documentation/admin-guide/mm/transhuge.rst + for more details. + trusted.source= [KEYS] Format: <string> This parameter identifies the trust source as a backend @@ -7350,13 +7680,6 @@ 16 - SIGBUS faults Example: user_debug=31 - userpte= - [X86,EARLY] Flags controlling user PTE allocations. - - nohigh = do not allocate PTE pages in - HIGHMEM regardless of setting - of CONFIG_HIGHPTE. - vdso= [X86,SH,SPARC] On X86_32, this is an alias for vdso32=. Otherwise: @@ -7474,7 +7797,7 @@ vt.cur_default= [VT] Default cursor shape. Format: 0xCCBBAA, where AA, BB, and CC are the same as the parameters of the <Esc>[?A;B;Cc escape sequence; - see VGA-softcursor.txt. Default: 2 = underline. + see vga-softcursor.rst. Default: 2 = underline. vt.default_blu= [VT] Format: <blue0>,<blue1>,<blue2>,...,<blue15> diff --git a/Documentation/admin-guide/laptops/index.rst b/Documentation/admin-guide/laptops/index.rst index cd9a1c2695fd..e71c8984c23e 100644 --- a/Documentation/admin-guide/laptops/index.rst +++ b/Documentation/admin-guide/laptops/index.rst @@ -11,6 +11,7 @@ Laptop Drivers disk-shock-protection laptop-mode lg-laptop + samsung-galaxybook sony-laptop sonypi thinkpad-acpi diff --git a/Documentation/admin-guide/laptops/samsung-galaxybook.rst b/Documentation/admin-guide/laptops/samsung-galaxybook.rst new file mode 100644 index 000000000000..752b8f1a4a74 --- /dev/null +++ b/Documentation/admin-guide/laptops/samsung-galaxybook.rst @@ -0,0 +1,174 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +========================== +Samsung Galaxy Book Driver +========================== + +Joshua Grisham <josh@joshuagrisham.com> + +This is a Linux x86 platform driver for Samsung Galaxy Book series notebook +devices which utilizes Samsung's ``SCAI`` ACPI device in order to control +extra features and receive various notifications. + +Supported devices +================= + +Any device with one of the supported ACPI device IDs should be supported. This +covers most of the "Samsung Galaxy Book" series notebooks that are currently +available as of this writing, and could include other Samsung notebook devices +as well. + +Status +====== + +The following features are currently supported: + +- :ref:`Keyboard backlight <keyboard-backlight>` control +- :ref:`Performance mode <performance-mode>` control implemented using the + platform profile interface +- :ref:`Battery charge control end threshold + <battery-charge-control-end-threshold>` (stop charging battery at given + percentage value) implemented as a battery hook +- :ref:`Firmware Attributes <firmware-attributes>` to allow control of various + device settings +- :ref:`Handling of Fn hotkeys <keyboard-hotkey-actions>` for various actions +- :ref:`Handling of ACPI notifications and hotkeys + <acpi-notifications-and-hotkey-actions>` + +Because different models of these devices can vary in their features, there is +logic built within the driver which attempts to test each implemented feature +for a valid response before enabling its support (registering additional devices +or extensions, adding sysfs attributes, etc). Therefore, it can be important to +note that not all features may be supported for your particular device. + +The following features might be possible to implement but will require +additional investigation and are therefore not supported at this time: + +- "Dolby Atmos" mode for the speakers +- "Outdoor Mode" for increasing screen brightness on models with ``SAM0427`` +- "Silent Mode" on models with ``SAM0427`` + +.. _keyboard-backlight: + +Keyboard backlight +================== + +A new LED class named ``samsung-galaxybook::kbd_backlight`` is created which +will then expose the device using the standard sysfs-based LED interface at +``/sys/class/leds/samsung-galaxybook::kbd_backlight``. Brightness can be +controlled by writing the desired value to the ``brightness`` sysfs attribute or +with any other desired userspace utility. + +.. note:: + Most of these devices have an ambient light sensor which also turns + off the keyboard backlight under well-lit conditions. This behavior does not + seem possible to control at this time, but can be good to be aware of. + +.. _performance-mode: + +Performance mode +================ + +This driver implements the +Documentation/userspace-api/sysfs-platform_profile.rst interface for working +with the "performance mode" function of the Samsung ACPI device. + +Mapping of each Samsung "performance mode" to its respective platform profile is +performed dynamically by the driver, as not all models support all of the same +performance modes. Your device might have one or more of the following mappings: + +- "Silent" maps to ``low-power`` +- "Quiet" maps to ``quiet`` +- "Optimized" maps to ``balanced`` +- "High performance" maps to ``performance`` + +The result of the mapping can be printed in the kernel log when the module is +loaded. Supported profiles can also be retrieved from +``/sys/firmware/acpi/platform_profile_choices``, while +``/sys/firmware/acpi/platform_profile`` can be used to read or write the +currently selected profile. + +The ``balanced`` platform profile will be set during module load if no profile +has been previously set. + +.. _battery-charge-control-end-threshold: + +Battery charge control end threshold +==================================== + +This platform driver will add the ability to set the battery's charge control +end threshold, but does not have the ability to set a start threshold. + +This feature is typically called "Battery Saver" by the various Samsung +applications in Windows, but in Linux we have implemented the standardized +"charge control threshold" sysfs interface on the battery device to allow for +controlling this functionality from the userspace. + +The sysfs attribute +``/sys/class/power_supply/BAT1/charge_control_end_threshold`` can be used to +read or set the desired charge end threshold. + +If you wish to maintain interoperability with the Samsung Settings application +in Windows, then you should set the value to 100 to represent "off", or enable +the feature using only one of the following values: 50, 60, 70, 80, or 90. +Otherwise, the driver will accept any value between 1 and 100 as the percentage +that you wish the battery to stop charging at. + +.. note:: + Some devices have been observed as automatically "turning off" the charge + control end threshold if an input value of less than 30 is given. + +.. _firmware-attributes: + +Firmware Attributes +=================== + +The following enumeration-typed firmware attributes are set up by this driver +and should be accessible under +``/sys/class/firmware-attributes/samsung-galaxybook/attributes/`` if your device +supports them: + +- ``power_on_lid_open`` (device should power on when the lid is opened) +- ``usb_charging`` (USB ports can deliver power to connected devices even when + the device is powered off or in a low sleep state) +- ``block_recording`` (blocks access to camera and microphone) + +All of these attributes are simple boolean-like enumeration values which use 0 +to represent "off" and 1 to represent "on". Use the ``current_value`` attribute +to get or change the setting on the device. + +Note that when ``block_recording`` is updated, the input device "Samsung Galaxy +Book Lens Cover" will receive a ``SW_CAMERA_LENS_COVER`` switch event which +reflects the current state. + +.. _keyboard-hotkey-actions: + +Keyboard hotkey actions (i8042 filter) +====================================== + +The i8042 filter will swallow the keyboard events for the Fn+F9 hotkey (Multi- +level keyboard backlight toggle) and Fn+F10 hotkey (Block recording toggle) +and instead execute their actions within the driver itself. + +Fn+F9 will cycle through the brightness levels of the keyboard backlight. A +notification will be sent using ``led_classdev_notify_brightness_hw_changed`` +so that the userspace can be aware of the change. This mimics the behavior of +other existing devices where the brightness level is cycled internally by the +embedded controller and then reported via a notification. + +Fn+F10 will toggle the value of the "block recording" setting, which blocks +or allows usage of the built-in camera and microphone (and generates the same +Lens Cover switch event mentioned above). + +.. _acpi-notifications-and-hotkey-actions: + +ACPI notifications and hotkey actions +===================================== + +ACPI notifications will generate ACPI netlink events under the device class +``samsung-galaxybook`` and bus ID matching the Samsung ACPI device ID found on +your device. The events can be received using userspace tools such as +``acpi_listen`` and ``acpid``. + +The Fn+F11 Performance mode hotkey will be handled by the driver; each keypress +will cycle to the next available platform profile. diff --git a/Documentation/admin-guide/media/cec.rst b/Documentation/admin-guide/media/cec.rst index 92690e1f2183..b2e7a300494a 100644 --- a/Documentation/admin-guide/media/cec.rst +++ b/Documentation/admin-guide/media/cec.rst @@ -451,7 +451,7 @@ configure the CEC devices for HDMI Input and the HDMI Outputs manually. --------------------- A three character manufacturer name that is used in the EDID for the HDMI -Input. If not set, then userspace is reponsible for configuring an EDID. +Input. If not set, then userspace is responsible for configuring an EDID. If set, then the driver will update the EDID automatically based on the resolutions supported by the connected displays, and it will not be possible anymore to manually set the EDID for the HDMI Input. diff --git a/Documentation/admin-guide/media/ipu3.rst b/Documentation/admin-guide/media/ipu3.rst index 83b3cd03b35c..9c190942932e 100644 --- a/Documentation/admin-guide/media/ipu3.rst +++ b/Documentation/admin-guide/media/ipu3.rst @@ -98,7 +98,7 @@ frames in packed raw Bayer format to IPU3 CSI2 receiver. # and that ov5670 sensor is connected to i2c bus 10 with address 0x36 export SDEV=$(media-ctl -d $MDEV -e "ov5670 10-0036") - # Establish the link for the media devices using media-ctl [#f3]_ + # Establish the link for the media devices using media-ctl media-ctl -d $MDEV -l "ov5670:0 -> ipu3-csi2 0:0[1]" # Set the format for the media devices @@ -589,12 +589,8 @@ preserved. References ========== -.. [#f5] drivers/staging/media/ipu3/include/uapi/intel-ipu3.h - .. [#f1] https://github.com/intel/nvt .. [#f2] http://git.ideasonboard.org/yavta.git -.. [#f3] http://git.ideasonboard.org/?p=media-ctl.git;a=summary - .. [#f4] ImgU limitation requires an additional 16x16 for all input resolutions diff --git a/Documentation/admin-guide/media/mgb4.rst b/Documentation/admin-guide/media/mgb4.rst index b9da127c074d..f69d331e3cb1 100644 --- a/Documentation/admin-guide/media/mgb4.rst +++ b/Documentation/admin-guide/media/mgb4.rst @@ -22,7 +22,9 @@ Global (PCI card) parameters | 0 - No module present | 1 - FPDL3 - | 2 - GMSL + | 2 - GMSL (one serializer, two daisy chained deserializers) + | 3 - GMSL (one serializer, two deserializers) + | 4 - GMSL (two deserializers with two daisy chain outputs) **module_version** (R): Module version number. Zero in case of a missing module. diff --git a/Documentation/admin-guide/mm/damon/start.rst b/Documentation/admin-guide/mm/damon/start.rst index c4dddf6733cd..ede14b679d02 100644 --- a/Documentation/admin-guide/mm/damon/start.rst +++ b/Documentation/admin-guide/mm/damon/start.rst @@ -42,32 +42,45 @@ the execution. :: $ git clone https://github.com/sjp38/masim; cd masim; make $ sudo damo start "./masim ./configs/stairs.cfg --quiet" - $ sudo ./damo show - 0 addr [85.541 TiB , 85.541 TiB ) (57.707 MiB ) access 0 % age 10.400 s - 1 addr [85.541 TiB , 85.542 TiB ) (413.285 MiB) access 0 % age 11.400 s - 2 addr [127.649 TiB , 127.649 TiB) (57.500 MiB ) access 0 % age 1.600 s - 3 addr [127.649 TiB , 127.649 TiB) (32.500 MiB ) access 0 % age 500 ms - 4 addr [127.649 TiB , 127.649 TiB) (9.535 MiB ) access 100 % age 300 ms - 5 addr [127.649 TiB , 127.649 TiB) (8.000 KiB ) access 60 % age 0 ns - 6 addr [127.649 TiB , 127.649 TiB) (6.926 MiB ) access 0 % age 1 s - 7 addr [127.998 TiB , 127.998 TiB) (120.000 KiB) access 0 % age 11.100 s - 8 addr [127.998 TiB , 127.998 TiB) (8.000 KiB ) access 40 % age 100 ms - 9 addr [127.998 TiB , 127.998 TiB) (4.000 KiB ) access 0 % age 11 s - total size: 577.590 MiB - $ sudo ./damo stop + $ sudo damo report access + heatmap: 641111111000000000000000000000000000000000000000000000[...]33333333333333335557984444[...]7 + # min/max temperatures: -1,840,000,000, 370,010,000, column size: 3.925 MiB + 0 addr 86.182 TiB size 8.000 KiB access 0 % age 14.900 s + 1 addr 86.182 TiB size 8.000 KiB access 60 % age 0 ns + 2 addr 86.182 TiB size 3.422 MiB access 0 % age 4.100 s + 3 addr 86.182 TiB size 2.004 MiB access 95 % age 2.200 s + 4 addr 86.182 TiB size 29.688 MiB access 0 % age 14.100 s + 5 addr 86.182 TiB size 29.516 MiB access 0 % age 16.700 s + 6 addr 86.182 TiB size 29.633 MiB access 0 % age 17.900 s + 7 addr 86.182 TiB size 117.652 MiB access 0 % age 18.400 s + 8 addr 126.990 TiB size 62.332 MiB access 0 % age 9.500 s + 9 addr 126.990 TiB size 13.980 MiB access 0 % age 5.200 s + 10 addr 126.990 TiB size 9.539 MiB access 100 % age 3.700 s + 11 addr 126.990 TiB size 16.098 MiB access 0 % age 6.400 s + 12 addr 127.987 TiB size 132.000 KiB access 0 % age 2.900 s + total size: 314.008 MiB + $ sudo damo stop The first command of the above example downloads and builds an artificial memory access generator program called ``masim``. The second command asks DAMO -to execute the artificial generator process start via the given command and -make DAMON monitors the generator process. The third command retrieves the -current snapshot of the monitored access pattern of the process from DAMON and -shows the pattern in a human readable format. - -Each line of the output shows which virtual address range (``addr [XX, XX)``) -of the process is how frequently (``access XX %``) accessed for how long time -(``age XX``). For example, the fifth region of ~9 MiB size is being most -frequently accessed for last 300 milliseconds. Finally, the fourth command -stops DAMON. +to start the program via the given command and make DAMON monitors the newly +started process. The third command retrieves the current snapshot of the +monitored access pattern of the process from DAMON and shows the pattern in a +human readable format. + +The first line of the output shows the relative access temperature (hotness) of +the regions in a single row hetmap format. Each column on the heatmap +represents regions of same size on the monitored virtual address space. The +position of the colun on the row and the number on the column represents the +relative location and access temperature of the region. ``[...]`` means +unmapped huge regions on the virtual address spaces. The second line shows +additional information for better understanding the heatmap. + +Each line of the output from the third line shows which virtual address range +(``addr XX size XX``) of the process is how frequently (``access XX %``) +accessed for how long time (``age XX``). For example, the evelenth region of +~9.5 MiB size is being most frequently accessed for last 3.7 seconds. Finally, +the fourth command stops DAMON. Note that DAMON can monitor not only virtual address spaces but multiple types of address spaces including the physical address space. @@ -95,7 +108,7 @@ Visualizing Recorded Patterns You can visualize the pattern in a heatmap, showing which memory region (x-axis) got accessed when (y-axis) and how frequently (number).:: - $ sudo damo report heats --heatmap stdout + $ sudo damo report heatmap 22222222222222222222222222222222222222211111111111111111111111111111111111111100 44444444444444444444444444444444444444434444444444444444444444444444444444443200 44444444444444444444444444444444444444433444444444444444444444444444444444444200 @@ -160,6 +173,6 @@ Data Access Pattern Aware Memory Management Below command makes every memory region of size >=4K that has not accessed for >=60 seconds in your workload to be swapped out. :: - $ sudo damo schemes --damos_access_rate 0 0 --damos_sz_region 4K max \ - --damos_age 60s max --damos_action pageout \ - <pid of your workload> + $ sudo damo start --damos_access_rate 0 0 --damos_sz_region 4K max \ + --damos_age 60s max --damos_action pageout \ + <pid of your workload> diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index d9be9f7caa7d..47a44bd348ab 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -26,12 +26,6 @@ DAMON provides below interfaces for different users. writing kernel space DAMON application programs for you. You can even extend DAMON for various address spaces. For detail, please refer to the interface :doc:`document </mm/damon/api>`. -- *debugfs interface. (DEPRECATED!)* - :ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface - <sysfs_interface>`. This is deprecated, so users should move to the - :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot - move, please report your usecase to damon@lists.linux.dev and - linux-mm@kvack.org. .. _sysfs_interface: @@ -89,10 +83,10 @@ comma (","). │ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value │ │ │ │ │ │ │ :ref:`watermarks <sysfs_watermarks>`/metric,interval_us,high,mid,low │ │ │ │ │ │ │ :ref:`filters <sysfs_filters>`/nr_filters - │ │ │ │ │ │ │ │ 0/type,matching,memcg_id - │ │ │ │ │ │ │ :ref:`stats <sysfs_schemes_stats>`/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds + │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx + │ │ │ │ │ │ │ :ref:`stats <sysfs_schemes_stats>`/nr_tried,sz_tried,nr_applied,sz_applied,sz_ops_filter_passed,qt_exceeds │ │ │ │ │ │ │ :ref:`tried_regions <sysfs_schemes_tried_regions>`/total_bytes - │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age + │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age,sz_filter_passed │ │ │ │ │ │ │ │ ... │ │ │ │ │ │ ... │ │ │ │ ... @@ -412,59 +406,62 @@ number (``N``) to the file creates the number of child directories named ``0`` to ``N-1``. Each directory represents each filter. The filters are evaluated in the numeric order. -Each filter directory contains six files, namely ``type``, ``matcing``, -``memcg_path``, ``addr_start``, ``addr_end``, and ``target_idx``. To ``type`` -file, you can write one of five special keywords: ``anon`` for anonymous pages, -``memcg`` for specific memory cgroup, ``young`` for young pages, ``addr`` for -specific address range (an open-ended interval), or ``target`` for specific -DAMON monitoring target filtering. In case of the memory cgroup filtering, you -can specify the memory cgroup of the interest by writing the path of the memory -cgroup from the cgroups mount point to ``memcg_path`` file. In case of the -address range filtering, you can specify the start and end address of the range -to ``addr_start`` and ``addr_end`` files, respectively. For the DAMON -monitoring target filtering, you can specify the index of the target between -the list of the DAMON context's monitoring targets list to ``target_idx`` file. -You can write ``Y`` or ``N`` to ``matching`` file to filter out pages that does -or does not match to the type, respectively. Then, the scheme's action will -not be applied to the pages that specified to be filtered out. +Each filter directory contains seven files, namely ``type``, ``matching``, +``allow``, ``memcg_path``, ``addr_start``, ``addr_end``, and ``target_idx``. +To ``type`` file, you can write one of five special keywords: ``anon`` for +anonymous pages, ``memcg`` for specific memory cgroup, ``young`` for young +pages, ``addr`` for specific address range (an open-ended interval), or +``target`` for specific DAMON monitoring target filtering. Meaning of the +types are same to the description on the :ref:`design doc +<damon_design_damos_filters>`. + +In case of the memory cgroup filtering, you can specify the memory cgroup of +the interest by writing the path of the memory cgroup from the cgroups mount +point to ``memcg_path`` file. In case of the address range filtering, you can +specify the start and end address of the range to ``addr_start`` and +``addr_end`` files, respectively. For the DAMON monitoring target filtering, +you can specify the index of the target between the list of the DAMON context's +monitoring targets list to ``target_idx`` file. + +You can write ``Y`` or ``N`` to ``matching`` file to specify whether the filter +is for memory that matches the ``type``. You can write ``Y`` or ``N`` to +``allow`` file to specify if applying the action to the memory that satisfies +the ``type`` and ``matching`` should be allowed or not. For example, below restricts a DAMOS action to be applied to only non-anonymous pages of all memory cgroups except ``/having_care_already``.:: # echo 2 > nr_filters - # # filter out anonymous pages + # # disallow anonymous pages echo anon > 0/type echo Y > 0/matching + echo N > 0/allow # # further filter out all cgroups except one at '/having_care_already' echo memcg > 1/type echo /having_care_already > 1/memcg_path echo Y > 1/matching + echo N > 1/allow -Note that ``anon`` and ``memcg`` filters are currently supported only when -``paddr`` :ref:`implementation <sysfs_context>` is being used. - -Also, memory regions that are filtered out by ``addr`` or ``target`` filters -are not counted as the scheme has tried to those, while regions that filtered -out by other type filters are counted as the scheme has tried to. The -difference is applied to :ref:`stats <damos_stats>` and -:ref:`tried regions <sysfs_schemes_tried_regions>`. +Refer to the :ref:`DAMOS filters design documentation +<damon_design_damos_filters>` for more details including how multiple filters +of different ``allow`` works, when each of the filters are supported, and +differences on stats. .. _sysfs_schemes_stats: schemes/<N>/stats/ ------------------ -DAMON counts the total number and bytes of regions that each scheme is tried to -be applied, the two numbers for the regions that each scheme is successfully -applied, and the total number of the quota limit exceeds. This statistics can -be used for online analysis or tuning of the schemes. +DAMON counts statistics for each scheme. This statistics can be used for +online analysis or tuning of the schemes. Refer to :ref:`design doc +<damon_design_damos_stat>` for more details about the stats. The statistics can be retrieved by reading the files under ``stats`` directory -(``nr_tried``, ``sz_tried``, ``nr_applied``, ``sz_applied``, and -``qt_exceeds``), respectively. The files are not updated in real time, so you -should ask DAMON sysfs interface to update the content of the files for the -stats by writing a special keyword, ``update_schemes_stats`` to the relevant -``kdamonds/<N>/state`` file. +(``nr_tried``, ``sz_tried``, ``nr_applied``, ``sz_applied``, +``sz_ops_filter_passed``, and ``qt_exceeds``), respectively. The files are not +updated in real time, so you should ask DAMON sysfs interface to update the +content of the files for the stats by writing a special keyword, +``update_schemes_stats`` to the relevant ``kdamonds/<N>/state`` file. .. _sysfs_schemes_tried_regions: @@ -501,10 +498,10 @@ set the ``access pattern`` as their interested pattern that they want to query. tried_regions/<N>/ ------------------ -In each region directory, you will find four files (``start``, ``end``, -``nr_accesses``, and ``age``). Reading the files will show the start and end -addresses, ``nr_accesses``, and ``age`` of the region that corresponding -DAMON-based operation scheme ``action`` has tried to be applied. +In each region directory, you will find five files (``start``, ``end``, +``nr_accesses``, ``age``, and ``sz_filter_passed``). Reading the files will +show the properties of the region that corresponding DAMON-based operation +scheme ``action`` has tried to be applied. Example ~~~~~~~ @@ -600,306 +597,3 @@ fields are as usual. It shows the index of the DAMON context (``ctx_idx=X``) of the scheme in the list of the contexts of the context's kdamond, the index of the scheme (``scheme_idx=X``) in the list of the schemes of the context, in addition to the output of ``damon_aggregated`` tracepoint. - - -.. _debugfs_interface: - -debugfs Interface (DEPRECATED!) -=============================== - -.. note:: - - THIS IS DEPRECATED! - - DAMON debugfs interface is deprecated, so users should move to the - :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot - move, please report your usecase to damon@lists.linux.dev and - linux-mm@kvack.org. - -DAMON exports nine files, ``DEPRECATED``, ``attrs``, ``target_ids``, -``init_regions``, ``schemes``, ``monitor_on_DEPRECATED``, ``kdamond_pid``, -``mk_contexts`` and ``rm_contexts`` under its debugfs directory, -``<debugfs>/damon/``. - - -``DEPRECATED`` is a read-only file for the DAMON debugfs interface deprecation -notice. Reading it returns the deprecation notice, as below:: - - # cat DEPRECATED - DAMON debugfs interface is deprecated, so users should move to DAMON_SYSFS. If you cannot, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org. - - -Attributes ----------- - -Users can get and set the ``sampling interval``, ``aggregation interval``, -``update interval``, and min/max number of monitoring target regions by -reading from and writing to the ``attrs`` file. To know about the monitoring -attributes in detail, please refer to the :doc:`/mm/damon/design`. For -example, below commands set those values to 5 ms, 100 ms, 1,000 ms, 10 and -1000, and then check it again:: - - # cd <debugfs>/damon - # echo 5000 100000 1000000 10 1000 > attrs - # cat attrs - 5000 100000 1000000 10 1000 - - -Target IDs ----------- - -Some types of address spaces supports multiple monitoring target. For example, -the virtual memory address spaces monitoring can have multiple processes as the -monitoring targets. Users can set the targets by writing relevant id values of -the targets to, and get the ids of the current targets by reading from the -``target_ids`` file. In case of the virtual address spaces monitoring, the -values should be pids of the monitoring target processes. For example, below -commands set processes having pids 42 and 4242 as the monitoring targets and -check it again:: - - # cd <debugfs>/damon - # echo 42 4242 > target_ids - # cat target_ids - 42 4242 - -Users can also monitor the physical memory address space of the system by -writing a special keyword, "``paddr\n``" to the file. Because physical address -space monitoring doesn't support multiple targets, reading the file will show a -fake value, ``42``, as below:: - - # cd <debugfs>/damon - # echo paddr > target_ids - # cat target_ids - 42 - -Note that setting the target ids doesn't start the monitoring. - - -Initial Monitoring Target Regions ---------------------------------- - -In case of the virtual address space monitoring, DAMON automatically sets and -updates the monitoring target regions so that entire memory mappings of target -processes can be covered. However, users can want to limit the monitoring -region to specific address ranges, such as the heap, the stack, or specific -file-mapped area. Or, some users can know the initial access pattern of their -workloads and therefore want to set optimal initial regions for the 'adaptive -regions adjustment'. - -In contrast, DAMON do not automatically sets and updates the monitoring target -regions in case of physical memory monitoring. Therefore, users should set the -monitoring target regions by themselves. - -In such cases, users can explicitly set the initial monitoring target regions -as they want, by writing proper values to the ``init_regions`` file. The input -should be a sequence of three integers separated by white spaces that represent -one region in below form.:: - - <target idx> <start address> <end address> - -The ``target idx`` should be the index of the target in ``target_ids`` file, -starting from ``0``, and the regions should be passed in address order. For -example, below commands will set a couple of address ranges, ``1-100`` and -``100-200`` as the initial monitoring target region of pid 42, which is the -first one (index ``0``) in ``target_ids``, and another couple of address -ranges, ``20-40`` and ``50-100`` as that of pid 4242, which is the second one -(index ``1``) in ``target_ids``.:: - - # cd <debugfs>/damon - # cat target_ids - 42 4242 - # echo "0 1 100 \ - 0 100 200 \ - 1 20 40 \ - 1 50 100" > init_regions - -Note that this sets the initial monitoring target regions only. In case of -virtual memory monitoring, DAMON will automatically updates the boundary of the -regions after one ``update interval``. Therefore, users should set the -``update interval`` large enough in this case, if they don't want the -update. - - -Schemes -------- - -Users can get and set the DAMON-based operation :ref:`schemes -<damon_design_damos>` by reading from and writing to ``schemes`` debugfs file. -Reading the file also shows the statistics of each scheme. To the file, each -of the schemes should be represented in each line in below form:: - - <target access pattern> <action> <quota> <watermarks> - -You can disable schemes by simply writing an empty string to the file. - -Target Access Pattern -~~~~~~~~~~~~~~~~~~~~~ - -The target access :ref:`pattern <damon_design_damos_access_pattern>` of the -scheme. The ``<target access pattern>`` is constructed with three ranges in -below form:: - - min-size max-size min-acc max-acc min-age max-age - -Specifically, bytes for the size of regions (``min-size`` and ``max-size``), -number of monitored accesses per aggregate interval for access frequency -(``min-acc`` and ``max-acc``), number of aggregate intervals for the age of -regions (``min-age`` and ``max-age``) are specified. Note that the ranges are -closed interval. - -Action -~~~~~~ - -The ``<action>`` is a predefined integer for memory management :ref:`actions -<damon_design_damos_action>`. The mapping between the ``<action>`` values and -the memory management actions is as below. For the detailed meaning of the -action and DAMON operations set supporting each action, please refer to the -list on :ref:`design doc <damon_design_damos_action>`. - - - 0: ``willneed`` - - 1: ``cold`` - - 2: ``pageout`` - - 3: ``hugepage`` - - 4: ``nohugepage`` - - 5: ``stat`` - -Quota -~~~~~ - -Users can set the :ref:`quotas <damon_design_damos_quotas>` of the given scheme -via the ``<quota>`` in below form:: - - <ms> <sz> <reset interval> <priority weights> - -This makes DAMON to try to use only up to ``<ms>`` milliseconds for applying -the action to memory regions of the ``target access pattern`` within the -``<reset interval>`` milliseconds, and to apply the action to only up to -``<sz>`` bytes of memory regions within the ``<reset interval>``. Setting both -``<ms>`` and ``<sz>`` zero disables the quota limits. - -For the :ref:`prioritization <damon_design_damos_quotas_prioritization>`, users -can set the weights for the three properties in ``<priority weights>`` in below -form:: - - <size weight> <access frequency weight> <age weight> - -Watermarks -~~~~~~~~~~ - -Users can specify :ref:`watermarks <damon_design_damos_watermarks>` of the -given scheme via ``<watermarks>`` in below form:: - - <metric> <check interval> <high mark> <middle mark> <low mark> - -``<metric>`` is a predefined integer for the metric to be checked. The -supported numbers and their meanings are as below. - - - 0: Ignore the watermarks - - 1: System's free memory rate (per thousand) - -The value of the metric is checked every ``<check interval>`` microseconds. - -If the value is higher than ``<high mark>`` or lower than ``<low mark>``, the -scheme is deactivated. If the value is lower than ``<mid mark>``, the scheme -is activated. - -.. _damos_stats: - -Statistics -~~~~~~~~~~ - -It also counts the total number and bytes of regions that each scheme is tried -to be applied, the two numbers for the regions that each scheme is successfully -applied, and the total number of the quota limit exceeds. This statistics can -be used for online analysis or tuning of the schemes. - -The statistics can be shown by reading the ``schemes`` file. Reading the file -will show each scheme you entered in each line, and the five numbers for the -statistics will be added at the end of each line. - -Example -~~~~~~~ - -Below commands applies a scheme saying "If a memory region of size in [4KiB, -8KiB] is showing accesses per aggregate interval in [0, 5] for aggregate -interval in [10, 20], page out the region. For the paging out, use only up to -10ms per second, and also don't page out more than 1GiB per second. Under the -limitation, page out memory regions having longer age first. Also, check the -free memory rate of the system every 5 seconds, start the monitoring and paging -out when the free memory rate becomes lower than 50%, but stop it if the free -memory rate becomes larger than 60%, or lower than 30%".:: - - # cd <debugfs>/damon - # scheme="4096 8192 0 5 10 20 2" # target access pattern and action - # scheme+=" 10 $((1024*1024*1024)) 1000" # quotas - # scheme+=" 0 0 100" # prioritization weights - # scheme+=" 1 5000000 600 500 300" # watermarks - # echo "$scheme" > schemes - - -Turning On/Off --------------- - -Setting the files as described above doesn't incur effect unless you explicitly -start the monitoring. You can start, stop, and check the current status of the -monitoring by writing to and reading from the ``monitor_on_DEPRECATED`` file. -Writing ``on`` to the file starts the monitoring of the targets with the -attributes. Writing ``off`` to the file stops those. DAMON also stops if -every target process is terminated. Below example commands turn on, off, and -check the status of DAMON:: - - # cd <debugfs>/damon - # echo on > monitor_on_DEPRECATED - # echo off > monitor_on_DEPRECATED - # cat monitor_on_DEPRECATED - off - -Please note that you cannot write to the above-mentioned debugfs files while -the monitoring is turned on. If you write to the files while DAMON is running, -an error code such as ``-EBUSY`` will be returned. - - -Monitoring Thread PID ---------------------- - -DAMON does requested monitoring with a kernel thread called ``kdamond``. You -can get the pid of the thread by reading the ``kdamond_pid`` file. When the -monitoring is turned off, reading the file returns ``none``. :: - - # cd <debugfs>/damon - # cat monitor_on_DEPRECATED - off - # cat kdamond_pid - none - # echo on > monitor_on_DEPRECATED - # cat kdamond_pid - 18594 - - -Using Multiple Monitoring Threads ---------------------------------- - -One ``kdamond`` thread is created for each monitoring context. You can create -and remove monitoring contexts for multiple ``kdamond`` required use case using -the ``mk_contexts`` and ``rm_contexts`` files. - -Writing the name of the new context to the ``mk_contexts`` file creates a -directory of the name on the DAMON debugfs directory. The directory will have -DAMON debugfs files for the context. :: - - # cd <debugfs>/damon - # ls foo - # ls: cannot access 'foo': No such file or directory - # echo foo > mk_contexts - # ls foo - # attrs init_regions kdamond_pid schemes target_ids - -If the context is not needed anymore, you can remove it and the corresponding -directory by putting the name of the context to the ``rm_contexts`` file. :: - - # echo foo > rm_contexts - # ls foo - # ls: cannot access 'foo': No such file or directory - -Note that ``mk_contexts``, ``rm_contexts``, and ``monitor_on_DEPRECATED`` files -are in the root directory only. diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index cb2c080f400c..33c886f3d198 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -280,8 +280,8 @@ The following files are currently defined: blocks; configure auto-onlining. The default value depends on the - CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE kernel configuration - option. + CONFIG_MHP_DEFAULT_ONLINE_TYPE kernel configuration + options. See the ``state`` property of memory blocks for details. ``block_size_bytes`` read-only: the size in bytes of a memory block. diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index 8872203df088..dff8d5985f0f 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -332,6 +332,12 @@ allocation policy for the internal shmem mount by using the kernel parameter seven valid policies for shmem (``always``, ``within_size``, ``advise``, ``never``, ``deny``, and ``force``). +Similarly to ``transparent_hugepage_shmem``, you can control the default +hugepage allocation policy for the tmpfs mount by using the kernel parameter +``transparent_hugepage_tmpfs=<policy>``, where ``<policy>`` is one of the +four valid policies for tmpfs (``always``, ``within_size``, ``advise``, +``never``). The tmpfs mount default policy is ``never``. + In the same manner as ``thp_anon`` controls each supported anonymous THP size, ``thp_shmem`` controls each supported shmem THP size. ``thp_shmem`` has the same format as ``thp_anon``, but also supports the policy @@ -352,8 +358,21 @@ default to ``never``. Hugepages in tmpfs/shmem ======================== -You can control hugepage allocation policy in tmpfs with mount option -``huge=``. It can have following values: +Traditionally, tmpfs only supported a single huge page size ("PMD"). Today, +it also supports smaller sizes just like anonymous memory, often referred +to as "multi-size THP" (mTHP). Huge pages of any size are commonly +represented in the kernel as "large folios". + +While there is fine control over the huge page sizes to use for the internal +shmem mount (see below), ordinary tmpfs mounts will make use of all available +huge page sizes without any control over the exact sizes, behaving more like +other file systems. + +tmpfs mounts +------------ + +The THP allocation policy for tmpfs mounts can be adjusted using the mount +option: ``huge=``. It can have following values: always Attempt to allocate huge pages every time we need a new page; @@ -363,24 +382,24 @@ never within_size Only allocate huge page if it will be fully within i_size. - Also respect fadvise()/madvise() hints; + Also respect madvise() hints; advise - Only allocate huge pages if requested with fadvise()/madvise(); + Only allocate huge pages if requested with madvise(); + +Remember, that the kernel may use huge pages of all available sizes, and +that no fine control as for the internal tmpfs mount is available. -The default policy is ``never``. +The default policy in the past was ``never``, but it can now be adjusted +using the kernel parameter ``transparent_hugepage_tmpfs=<policy>``. ``mount -o remount,huge= /mountpoint`` works fine after mount: remounting ``huge=never`` will not attempt to break up huge pages at all, just stop more from being allocated. -There's also sysfs knob to control hugepage allocation policy for internal -shmem mount: /sys/kernel/mm/transparent_hugepage/shmem_enabled. The mount -is used for SysV SHM, memfds, shared anonymous mmaps (of /dev/zero or -MAP_ANONYMOUS), GPU drivers' DRM objects, Ashmem. - -In addition to policies listed above, shmem_enabled allows two further -values: +In addition to policies listed above, the sysfs knob +/sys/kernel/mm/transparent_hugepage/shmem_enabled will affect the +allocation policy of tmpfs mounts, when set to the following values: deny For use in emergencies, to force the huge option off from @@ -388,13 +407,24 @@ deny force Force the huge option on for all - very useful for testing; -Shmem can also use "multi-size THP" (mTHP) by adding a new sysfs knob to -control mTHP allocation: -'/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/shmem_enabled', -and its value for each mTHP is essentially consistent with the global -setting. An 'inherit' option is added to ensure compatibility with these -global settings. Conversely, the options 'force' and 'deny' are dropped, -which are rather testing artifacts from the old ages. +shmem / internal tmpfs +---------------------- +The mount internal tmpfs mount is used for SysV SHM, memfds, shared anonymous +mmaps (of /dev/zero or MAP_ANONYMOUS), GPU drivers' DRM objects, Ashmem. + +To control the THP allocation policy for this internal tmpfs mount, the +sysfs knob /sys/kernel/mm/transparent_hugepage/shmem_enabled and the knobs +per THP size in +'/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/shmem_enabled' +can be used. + +The global knob has the same semantics as the ``huge=`` mount options +for tmpfs mounts, except that the different huge page sizes can be controlled +individually, and will only use the setting of the global knob when the +per-size knob is set to 'inherit'. + +The options 'force' and 'deny' are dropped for the individual sizes, which +are rather testing artifacts from the old ages. always Attempt to allocate <size> huge pages every time we need a new page; @@ -408,10 +438,10 @@ never within_size Only allocate <size> huge page if it will be fully within i_size. - Also respect fadvise()/madvise() hints; + Also respect madvise() hints; advise - Only allocate <size> huge pages if requested with fadvise()/madvise(); + Only allocate <size> huge pages if requested with madvise(); Need of application restart =========================== @@ -561,6 +591,16 @@ swpin is incremented every time a huge page is swapped in from a non-zswap swap device in one piece. +swpin_fallback + is incremented if swapin fails to allocate or charge a huge page + and instead falls back to using huge pages with lower orders or + small pages. + +swpin_fallback_charge + is incremented if swapin fails to charge a huge page and instead + falls back to using huge pages with lower orders or small pages + even though the allocation was successful. + swpout is incremented every time a huge page is swapped out to a non-zswap swap device in one piece without splitting. diff --git a/Documentation/admin-guide/nvme-multipath.rst b/Documentation/admin-guide/nvme-multipath.rst new file mode 100644 index 000000000000..97ca1ccef459 --- /dev/null +++ b/Documentation/admin-guide/nvme-multipath.rst @@ -0,0 +1,72 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +Linux NVMe multipath +==================== + +This document describes NVMe multipath and its path selection policies supported +by the Linux NVMe host driver. + + +Introduction +============ + +The NVMe multipath feature in Linux integrates namespaces with the same +identifier into a single block device. Using multipath enhances the reliability +and stability of I/O access while improving bandwidth performance. When a user +sends I/O to this merged block device, the multipath mechanism selects one of +the underlying block devices (paths) according to the configured policy. +Different policies result in different path selections. + + +Policies +======== + +All policies follow the ANA (Asymmetric Namespace Access) mechanism, meaning +that when an optimized path is available, it will be chosen over a non-optimized +one. Current the NVMe multipath policies include numa(default), round-robin and +queue-depth. + +To set the desired policy (e.g., round-robin), use one of the following methods: + 1. echo -n "round-robin" > /sys/module/nvme_core/parameters/iopolicy + 2. or add the "nvme_core.iopolicy=round-robin" to cmdline. + + +NUMA +---- + +The NUMA policy selects the path closest to the NUMA node of the current CPU for +I/O distribution. This policy maintains the nearest paths to each NUMA node +based on network interface connections. + +When to use the NUMA policy: + 1. Multi-core Systems: Optimizes memory access in multi-core and + multi-processor systems, especially under NUMA architecture. + 2. High Affinity Workloads: Binds I/O processing to the CPU to reduce + communication and data transfer delays across nodes. + + +Round-Robin +----------- + +The round-robin policy distributes I/O requests evenly across all paths to +enhance throughput and resource utilization. Each I/O operation is sent to the +next path in sequence. + +When to use the round-robin policy: + 1. Balanced Workloads: Effective for balanced and predictable workloads with + similar I/O size and type. + 2. Homogeneous Path Performance: Utilizes all paths efficiently when + performance characteristics (e.g., latency, bandwidth) are similar. + + +Queue-Depth +----------- + +The queue-depth policy manages I/O requests based on the current queue depth +of each path, selecting the path with the least number of in-flight I/Os. + +When to use the queue-depth policy: + 1. High load with small I/Os: Effectively balances load across paths when + the load is high, and I/O operations consist of small, relatively + fixed-sized requests. diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst index a21369eba034..3950583f2b15 100644 --- a/Documentation/admin-guide/pm/cpufreq.rst +++ b/Documentation/admin-guide/pm/cpufreq.rst @@ -248,6 +248,20 @@ are the following: If that frequency cannot be determined, this attribute should not be present. +``cpuinfo_avg_freq`` + An average frequency (in KHz) of all CPUs belonging to a given policy, + derived from a hardware provided feedback and reported on a time frame + spanning at most few milliseconds. + + This is expected to be based on the frequency the hardware actually runs + at and, as such, might require specialised hardware support (such as AMU + extension on ARM). If one cannot be determined, this attribute should + not be present. + + Note, that failed attempt to retrieve current frequency for a given + CPU(s) will result in an appropriate error, i.e: EAGAIN for CPU that + remains idle (raised on ARM). + ``cpuinfo_max_freq`` Maximum possible operating frequency the CPUs belonging to this policy can run at (in kHz). @@ -293,7 +307,8 @@ are the following: Some architectures (e.g. ``x86``) may attempt to provide information more precisely reflecting the current CPU frequency through this attribute, but that still may not be the exact current CPU frequency as - seen by the hardware at the moment. + seen by the hardware at the moment. This behavior though, is only + available via c:macro:``CPUFREQ_ARCH_CUR_FREQ`` option. ``scaling_driver`` The scaling driver currently in use. diff --git a/Documentation/admin-guide/pm/cpuidle.rst b/Documentation/admin-guide/pm/cpuidle.rst index eb58d7a5affd..0c090b076224 100644 --- a/Documentation/admin-guide/pm/cpuidle.rst +++ b/Documentation/admin-guide/pm/cpuidle.rst @@ -275,20 +275,25 @@ values and, when predicting the idle duration next time, it computes the average and variance of them. If the variance is small (smaller than 400 square milliseconds) or it is small relative to the average (the average is greater that 6 times the standard deviation), the average is regarded as the "typical -interval" value. Otherwise, the longest of the saved observed idle duration +interval" value. Otherwise, either the longest or the shortest (depending on +which one is farther from the average) of the saved observed idle duration values is discarded and the computation is repeated for the remaining ones. + Again, if the variance of them is small (in the above sense), the average is taken as the "typical interval" value and so on, until either the "typical -interval" is determined or too many data points are disregarded, in which case -the "typical interval" is assumed to equal "infinity" (the maximum unsigned -integer value). - -If the "typical interval" computed this way is long enough, the governor obtains -the time until the closest timer event with the assumption that the scheduler -tick will be stopped. That time, referred to as the *sleep length* in what follows, -is the upper bound on the time before the next CPU wakeup. It is used to determine -the sleep length range, which in turn is needed to get the sleep length correction -factor. +interval" is determined or too many data points are disregarded. In the latter +case, if the size of the set of data points still under consideration is +sufficiently large, the next idle duration is not likely to be above the largest +idle duration value still in that set, so that value is taken as the predicted +next idle duration. Finally, if the set of data points still under +consideration is too small, no prediction is made. + +If the preliminary prediction of the next idle duration computed this way is +long enough, the governor obtains the time until the closest timer event with +the assumption that the scheduler tick will be stopped. That time, referred to +as the *sleep length* in what follows, is the upper bound on the time before the +next CPU wakeup. It is used to determine the sleep length range, which in turn +is needed to get the sleep length correction factor. The ``menu`` governor maintains an array containing several correction factor values that correspond to different sleep length ranges organized so that each @@ -302,7 +307,7 @@ to 1 the correction factor becomes (it must fall between 0 and 1 inclusive). The sleep length is multiplied by the correction factor for the range that it falls into to obtain an approximation of the predicted idle duration that is compared to the "typical interval" determined previously and the minimum of -the two is taken as the idle duration prediction. +the two is taken as the final idle duration prediction. If the "typical interval" value is small, which means that the CPU is likely to be woken up soon enough, the sleep length computation is skipped as it may diff --git a/Documentation/admin-guide/pm/intel_idle.rst b/Documentation/admin-guide/pm/intel_idle.rst index 39bd6ecce7de..5940528146eb 100644 --- a/Documentation/admin-guide/pm/intel_idle.rst +++ b/Documentation/admin-guide/pm/intel_idle.rst @@ -192,11 +192,19 @@ even if they have been enumerated (see :ref:`cpu-pm-qos` in Documentation/admin-guide/pm/cpuidle.rst). Setting ``max_cstate`` to 0 causes the ``intel_idle`` initialization to fail. -The ``no_acpi`` and ``use_acpi`` module parameters (recognized by ``intel_idle`` -if the kernel has been configured with ACPI support) can be set to make the -driver ignore the system's ACPI tables entirely or use them for all of the -recognized processor models, respectively (they both are unset by default and -``use_acpi`` has no effect if ``no_acpi`` is set). +The ``no_acpi``, ``use_acpi`` and ``no_native`` module parameters are +recognized by ``intel_idle`` if the kernel has been configured with ACPI +support. In the case that ACPI is not configured these flags have no impact +on functionality. + +``no_acpi`` - Do not use ACPI at all. Only native mode is available, no +ACPI mode. + +``use_acpi`` - No-op in ACPI mode, the driver will consult ACPI tables for +C-states on/off status in native mode. + +``no_native`` - Work only in ACPI mode, no native mode available (ignore +all custom tables). The value of the ``states_off`` module parameter (0 by default) represents a list of idle states to be disabled by default in the form of a bitmask. diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index bf13ad25a32f..78fc83ed2a7e 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -696,6 +696,9 @@ of them have to be prepended with the ``intel_pstate=`` prefix. Use per-logical-CPU P-State limits (see `Coordination of P-state Limits`_ for details). +``no_cas`` + Do not enable capacity-aware scheduling (CAS) which is enabled by + default on hybrid systems. Diagnostics and Tuning ====================== diff --git a/Documentation/admin-guide/pnp.rst b/Documentation/admin-guide/pnp.rst index 3eda08191d13..24d80e3eb309 100644 --- a/Documentation/admin-guide/pnp.rst +++ b/Documentation/admin-guide/pnp.rst @@ -129,9 +129,6 @@ pnp_put_protocol pnp_register_protocol use this to register a new PnP protocol -pnp_unregister_protocol - use this function to remove a PnP protocol from the Plug and Play Layer - pnp_register_driver adds a PnP driver to the Plug and Play Layer diff --git a/Documentation/admin-guide/quickly-build-trimmed-linux.rst b/Documentation/admin-guide/quickly-build-trimmed-linux.rst index f08149bc53f8..07cfd8863b46 100644 --- a/Documentation/admin-guide/quickly-build-trimmed-linux.rst +++ b/Documentation/admin-guide/quickly-build-trimmed-linux.rst @@ -733,7 +733,7 @@ can easily happen that your self-built kernel will lack modules for tasks you did not perform before utilizing this make target. That's because those tasks require kernel modules that are normally autoloaded when you perform that task for the first time; if you didn't perform that task at least once before using -localmodonfig, the latter will thus assume these modules are superfluous and +localmodconfig, the latter will thus assume these modules are superfluous and disable them. You can try to avoid this by performing typical tasks that often will autoload diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst index f5ec6c9312e1..08e89e031714 100644 --- a/Documentation/admin-guide/sysctl/fs.rst +++ b/Documentation/admin-guide/sysctl/fs.rst @@ -41,7 +41,7 @@ pre-allocation or re-sizing of any kernel data structures. dentry-negative ---------------------------- -Policy for negative dentries. Set to 1 to to always delete the dentry when a +Policy for negative dentries. Set to 1 to always delete the dentry when a file is removed, and 0 to disable it. By default, this behavior is disabled. dentry-state diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index b2b36d0c3094..dd49a89a62d3 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -212,6 +212,17 @@ pid>/``). This value defaults to 0. +core_sort_vma +============= + +The default coredump writes VMAs in address order. By setting +``core_sort_vma`` to 1, VMAs will be written from smallest size +to largest size. This is known to break at least elfutils, but +can be handy when dealing with very large (and truncated) +coredumps where the more useful debugging details are included +in the smaller VMAs. + + core_uses_pid ============= @@ -1544,6 +1555,13 @@ constant ``FUTEX_TID_MASK`` (0x3fffffff). If a value outside of this range is written to ``threads-max`` an ``EINVAL`` error occurs. +timer_migration +=============== + +When set to a non-zero value, attempt to migrate timers away from idle cpus to +allow them to remain in low power states longer. + +Default is set (1). traceoff_on_warning =================== diff --git a/Documentation/admin-guide/sysrq.rst b/Documentation/admin-guide/sysrq.rst index a85b3384d1e7..9c7aa817adc7 100644 --- a/Documentation/admin-guide/sysrq.rst +++ b/Documentation/admin-guide/sysrq.rst @@ -49,26 +49,26 @@ How do I use the magic SysRq key? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On x86 - You press the key combo :kbd:`ALT-SysRq-<command key>`. + You press the key combo `ALT-SysRq-<command key>`. .. note:: Some keyboards may not have a key labeled 'SysRq'. The 'SysRq' key is also known as the 'Print Screen' key. Also some keyboards cannot handle so many keys being pressed at the same time, so you might - have better luck with press :kbd:`Alt`, press :kbd:`SysRq`, - release :kbd:`SysRq`, press :kbd:`<command key>`, release everything. + have better luck with press `Alt`, press `SysRq`, + release `SysRq`, press `<command key>`, release everything. On SPARC - You press :kbd:`ALT-STOP-<command key>`, I believe. + You press `ALT-STOP-<command key>`, I believe. On the serial console (PC style standard serial ports only) You send a ``BREAK``, then within 5 seconds a command key. Sending ``BREAK`` twice is interpreted as a normal BREAK. On PowerPC - Press :kbd:`ALT - Print Screen` (or :kbd:`F13`) - :kbd:`<command key>`. - :kbd:`Print Screen` (or :kbd:`F13`) - :kbd:`<command key>` may suffice. + Press `ALT - Print Screen` (or `F13`) - `<command key>`. + `Print Screen` (or `F13`) - `<command key>` may suffice. On other If you know of the key combos for other architectures, please @@ -88,7 +88,7 @@ On all echo _reisub > /proc/sysrq-trigger -The :kbd:`<command key>` is case sensitive. +The `<command key>` is case sensitive. What are the 'command' keys? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -225,9 +225,9 @@ Sometimes SysRq seems to get 'stuck' after using it, what can I do? When this happens, try tapping shift, alt and control on both sides of the keyboard, and hitting an invalid sysrq sequence again. (i.e., something like -:kbd:`alt-sysrq-z`). +`alt-sysrq-z`). -Switching to another virtual console (:kbd:`ALT+Fn`) and then back again +Switching to another virtual console (`ALT+Fn`) and then back again should also help. I hit SysRq, but nothing seems to happen, what's wrong? @@ -290,7 +290,7 @@ exception the header line from the sysrq command is passed to all console consumers as if the current loglevel was maximum. If only the header is emitted it is almost certain that the kernel loglevel is too low. Should you require the output on the console channel then you will need -to temporarily up the console loglevel using :kbd:`alt-sysrq-8` or:: +to temporarily up the console loglevel using `alt-sysrq-8` or:: echo 8 > /proc/sysrq-trigger diff --git a/Documentation/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst index 2ed79f41a411..d0502691dfa1 100644 --- a/Documentation/admin-guide/thunderbolt.rst +++ b/Documentation/admin-guide/thunderbolt.rst @@ -28,7 +28,7 @@ should be a userspace tool that handles all the low-level details, keeps a database of the authorized devices and prompts users for new connections. More details about the sysfs interface for Thunderbolt devices can be -found in ``Documentation/ABI/testing/sysfs-bus-thunderbolt``. +found in Documentation/ABI/testing/sysfs-bus-thunderbolt. Those users who just want to connect any device without any sort of manual work can add following line to diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index 6281eae9e6bc..03c55151346c 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -1431,7 +1431,7 @@ can easily happen that your self-built kernels will lack modules for tasks you did not perform at least once before utilizing this make target. That happens when a task requires kernel modules which are only autoloaded when you execute it for the first time. So when you never performed that task since starting your -kernel the modules will not have been loaded -- and from localmodonfig's point +kernel the modules will not have been loaded -- and from localmodconfig's point of view look superfluous, which thus disables them to reduce the amount of code to be compiled. diff --git a/Documentation/admin-guide/workload-tracing.rst b/Documentation/admin-guide/workload-tracing.rst index b2e254ec8ee8..d6313890ee41 100644 --- a/Documentation/admin-guide/workload-tracing.rst +++ b/Documentation/admin-guide/workload-tracing.rst @@ -82,8 +82,8 @@ Install tools to build Linux kernel and tools in kernel repository. scripts/ver_linux is a good way to check if your system already has the necessary tools:: - sudo apt-get build-essentials flex bison yacc - sudo apt install libelf-dev systemtap-sdt-dev libaudit-dev libslang2-dev libperl-dev libdw-dev + sudo apt-get install build-essential flex bison yacc + sudo apt install libelf-dev systemtap-sdt-dev libslang2-dev libperl-dev libdw-dev cscope is a good tool to browse kernel sources. Let's install it now:: diff --git a/Documentation/arch/arm64/amu.rst b/Documentation/arch/arm64/amu.rst index 01f2de2b0450..ac1b3f0e211d 100644 --- a/Documentation/arch/arm64/amu.rst +++ b/Documentation/arch/arm64/amu.rst @@ -80,7 +80,7 @@ bypass the setting of AMUSERENR_EL0 to trap accesses from EL0 (userspace) to EL1 (kernel). Therefore, firmware should still ensure accesses to AMU registers are not trapped in EL2/EL3. -The fixed counters of AMUv1 are accessible though the following system +The fixed counters of AMUv1 are accessible through the following system register definitions: - SYS_AMEVCNTR0_CORE_EL0 diff --git a/Documentation/arch/arm64/asymmetric-32bit.rst b/Documentation/arch/arm64/asymmetric-32bit.rst index 64a0b505da7d..57b8d7476f71 100644 --- a/Documentation/arch/arm64/asymmetric-32bit.rst +++ b/Documentation/arch/arm64/asymmetric-32bit.rst @@ -55,7 +55,7 @@ sysfs The subset of CPUs capable of running 32-bit tasks is described in ``/sys/devices/system/cpu/aarch32_el0`` and is documented further in -``Documentation/ABI/testing/sysfs-devices-system-cpu``. +Documentation/ABI/testing/sysfs-devices-system-cpu. **Note:** CPUs are advertised by this file as they are detected and so late-onlining of 32-bit-capable CPUs can result in the file contents @@ -153,3 +153,11 @@ asymmetric system, a broken guest at EL1 could still attempt to execute mode will return to host userspace with an ``exit_reason`` of ``KVM_EXIT_FAIL_ENTRY`` and will remain non-runnable until successfully re-initialised by a subsequent ``KVM_ARM_VCPU_INIT`` operation. + +NOHZ FULL +--------- + +To avoid perturbing an adaptive-ticks CPU (specified using +``nohz_full=``) when a 32-bit task is forcefully migrated, these CPUs +are treated as 64-bit-only when support for asymmetric 32-bit systems +is enabled. diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst index cad6fdc96b98..dee7b6de864f 100644 --- a/Documentation/arch/arm64/booting.rst +++ b/Documentation/arch/arm64/booting.rst @@ -288,6 +288,12 @@ Before jumping into the kernel, the following conditions must be met: - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1. + For CPUs with the Fine Grained Traps 2 (FEAT_FGT2) extension present: + + - If EL3 is present and the kernel is entered at EL2: + + - SCR_EL3.FGTEn2 (bit 59) must be initialised to 0b1. + For CPUs with support for HCRX_EL2 (FEAT_HCX) present: - If EL3 is present and the kernel is entered at EL2: @@ -382,6 +388,22 @@ Before jumping into the kernel, the following conditions must be met: - SMCR_EL2.EZT0 (bit 30) must be initialised to 0b1. + For CPUs with the Performance Monitors Extension (FEAT_PMUv3p9): + + - If EL3 is present: + + - MDCR_EL3.EnPM2 (bit 7) must be initialised to 0b1. + + - If the kernel is entered at EL1 and EL2 is present: + + - HDFGRTR2_EL2.nPMICNTR_EL0 (bit 2) must be initialised to 0b1. + - HDFGRTR2_EL2.nPMICFILTR_EL0 (bit 3) must be initialised to 0b1. + - HDFGRTR2_EL2.nPMUACR_EL1 (bit 4) must be initialised to 0b1. + + - HDFGWTR2_EL2.nPMICNTR_EL0 (bit 2) must be initialised to 0b1. + - HDFGWTR2_EL2.nPMICFILTR_EL0 (bit 3) must be initialised to 0b1. + - HDFGWTR2_EL2.nPMUACR_EL1 (bit 4) must be initialised to 0b1. + For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS): - If the kernel is entered at EL1 and EL2 is present: diff --git a/Documentation/arch/arm64/gcs.rst b/Documentation/arch/arm64/gcs.rst index 1f65a3193e77..226c0b008456 100644 --- a/Documentation/arch/arm64/gcs.rst +++ b/Documentation/arch/arm64/gcs.rst @@ -37,7 +37,7 @@ intended to be exhaustive. shadow stacks rather than GCS. * Support for GCS is reported to userspace via HWCAP_GCS in the aux vector - AT_HWCAP2 entry. + AT_HWCAP entry. * GCS is enabled per thread. While there is support for disabling GCS at runtime this should be done with great care. diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst index b42fea07c5ce..f968c13b46a7 100644 --- a/Documentation/arch/arm64/silicon-errata.rst +++ b/Documentation/arch/arm64/silicon-errata.rst @@ -198,7 +198,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ -| ARM | MMU-500 | #841119,826419 | N/A | +| ARM | MMU-500 | #841119,826419 | ARM_SMMU_MMU_500_CPRE_ERRATA| +| | | #562869,1047329 | | +----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-600 | #1076982,1209401| N/A | +----------------+-----------------+-----------------+-----------------------------+ @@ -283,6 +284,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 | +----------------+-----------------+-----------------+-----------------------------+ +| Rockchip | RK3568 | #3568002 | ROCKCHIP_ERRATUM_3568002 | ++----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ | Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 | +----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/arch/powerpc/cxl.rst b/Documentation/arch/powerpc/cxl.rst index d2d77057610e..778adda740d2 100644 --- a/Documentation/arch/powerpc/cxl.rst +++ b/Documentation/arch/powerpc/cxl.rst @@ -18,6 +18,7 @@ Introduction both access system memory directly and with the same effective addresses. + **This driver is deprecated and will be removed in a future release.** Hardware overview ================= @@ -453,7 +454,7 @@ Sysfs Class A cxl sysfs class is added under /sys/class/cxl to facilitate enumeration and tuning of the accelerators. Its layout is - described in Documentation/ABI/testing/sysfs-class-cxl + described in Documentation/ABI/obsolete/sysfs-class-cxl Udev rules diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst index 955fbcd19ce9..f273ea15a8e8 100644 --- a/Documentation/arch/riscv/hwprobe.rst +++ b/Documentation/arch/riscv/hwprobe.rst @@ -293,3 +293,13 @@ The following keys are defined: * :c:macro:`RISCV_HWPROBE_MISALIGNED_VECTOR_UNSUPPORTED`: Misaligned vector accesses are not supported at all and will generate a misaligned address fault. + +* :c:macro:`RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0`: A bitmask containing the + thead vendor extensions that are compatible with the + :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: base system behavior. + + * T-HEAD + + * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XTHEADVECTOR`: The xtheadvector vendor + extension is supported in the T-Head ISA extensions spec starting from + commit a18c801634 ("Add T-Head VECTOR vendor extension. "). diff --git a/Documentation/arch/x86/amd-memory-encryption.rst b/Documentation/arch/x86/amd-memory-encryption.rst index 6df3264f23b9..bd840df708ea 100644 --- a/Documentation/arch/x86/amd-memory-encryption.rst +++ b/Documentation/arch/x86/amd-memory-encryption.rst @@ -130,8 +130,126 @@ SNP feature support. More details in AMD64 APM[1] Vol 2: 15.34.10 SEV_STATUS MSR +Reverse Map Table (RMP) +======================= + +The RMP is a structure in system memory that is used to ensure a one-to-one +mapping between system physical addresses and guest physical addresses. Each +page of memory that is potentially assignable to guests has one entry within +the RMP. + +The RMP table can be either contiguous in memory or a collection of segments +in memory. + +Contiguous RMP +-------------- + +Support for this form of the RMP is present when support for SEV-SNP is +present, which can be determined using the CPUID instruction:: + + 0x8000001f[eax]: + Bit[4] indicates support for SEV-SNP + +The location of the RMP is identified to the hardware through two MSRs:: + + 0xc0010132 (RMP_BASE): + System physical address of the first byte of the RMP + + 0xc0010133 (RMP_END): + System physical address of the last byte of the RMP + +Hardware requires that RMP_BASE and (RPM_END + 1) be 8KB aligned, but SEV +firmware increases the alignment requirement to require a 1MB alignment. + +The RMP consists of a 16KB region used for processor bookkeeping followed +by the RMP entries, which are 16 bytes in size. The size of the RMP +determines the range of physical memory that the hypervisor can assign to +SEV-SNP guests. The RMP covers the system physical address from:: + + 0 to ((RMP_END + 1 - RMP_BASE - 16KB) / 16B) x 4KB. + +The current Linux support relies on BIOS to allocate/reserve the memory for +the RMP and to set RMP_BASE and RMP_END appropriately. Linux uses the MSR +values to locate the RMP and determine the size of the RMP. The RMP must +cover all of system memory in order for Linux to enable SEV-SNP. + +Segmented RMP +------------- + +Segmented RMP support is a new way of representing the layout of an RMP. +Initial RMP support required the RMP table to be contiguous in memory. +RMP accesses from a NUMA node on which the RMP doesn't reside +can take longer than accesses from a NUMA node on which the RMP resides. +Segmented RMP support allows the RMP entries to be located on the same +node as the memory the RMP is covering, potentially reducing latency +associated with accessing an RMP entry associated with the memory. Each +RMP segment covers a specific range of system physical addresses. + +Support for this form of the RMP can be determined using the CPUID +instruction:: + + 0x8000001f[eax]: + Bit[23] indicates support for segmented RMP + +If supported, segmented RMP attributes can be found using the CPUID +instruction:: + + 0x80000025[eax]: + Bits[5:0] minimum supported RMP segment size + Bits[11:6] maximum supported RMP segment size + + 0x80000025[ebx]: + Bits[9:0] number of cacheable RMP segment definitions + Bit[10] indicates if the number of cacheable RMP segments + is a hard limit + +To enable a segmented RMP, a new MSR is available:: + + 0xc0010136 (RMP_CFG): + Bit[0] indicates if segmented RMP is enabled + Bits[13:8] contains the size of memory covered by an RMP + segment (expressed as a power of 2) + +The RMP segment size defined in the RMP_CFG MSR applies to all segments +of the RMP. Therefore each RMP segment covers a specific range of system +physical addresses. For example, if the RMP_CFG MSR value is 0x2401, then +the RMP segment coverage value is 0x24 => 36, meaning the size of memory +covered by an RMP segment is 64GB (1 << 36). So the first RMP segment +covers physical addresses from 0 to 0xF_FFFF_FFFF, the second RMP segment +covers physical addresses from 0x10_0000_0000 to 0x1F_FFFF_FFFF, etc. + +When a segmented RMP is enabled, RMP_BASE points to the RMP bookkeeping +area as it does today (16K in size). However, instead of RMP entries +beginning immediately after the bookkeeping area, there is a 4K RMP +segment table (RST). Each entry in the RST is 8-bytes in size and represents +an RMP segment:: + + Bits[19:0] mapped size (in GB) + The mapped size can be less than the defined segment size. + A value of zero, indicates that no RMP exists for the range + of system physical addresses associated with this segment. + Bits[51:20] segment physical address + This address is left shift 20-bits (or just masked when + read) to form the physical address of the segment (1MB + alignment). + +The RST can hold 512 segment entries but can be limited in size to the number +of cacheable RMP segments (CPUID 0x80000025_EBX[9:0]) if the number of cacheable +RMP segments is a hard limit (CPUID 0x80000025_EBX[10]). + +The current Linux support relies on BIOS to allocate/reserve the memory for +the segmented RMP (the bookkeeping area, RST, and all segments), build the RST +and to set RMP_BASE, RMP_END, and RMP_CFG appropriately. Linux uses the MSR +values to locate the RMP and determine the size and location of the RMP +segments. The RMP must cover all of system memory in order for Linux to enable +SEV-SNP. + +More details in the AMD64 APM Vol 2, section "15.36.3 Reverse Map Table", +docID: 24593. + Secure VM Service Module (SVSM) =============================== + SNP provides a feature called Virtual Machine Privilege Levels (VMPL) which defines four privilege levels at which guest software can run. The most privileged level is 0 and numerically higher numbers have lesser privileges. diff --git a/Documentation/arch/x86/boot.rst b/Documentation/arch/x86/boot.rst index ad2d8ddad27f..77e6163288db 100644 --- a/Documentation/arch/x86/boot.rst +++ b/Documentation/arch/x86/boot.rst @@ -77,7 +77,7 @@ Protocol 2.14 BURNT BY INCORRECT COMMIT Protocol 2.15 (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max. ============= ============================================================ - .. note:: +.. note:: The protocol version number should be changed only if the setup header is changed. There is no need to update the version number if boot_params or kernel_info are changed. Additionally, it is recommended to use @@ -95,27 +95,27 @@ Memory Layout The traditional memory map for the kernel loader, used for Image or zImage kernels, typically looks like:: - | | - 0A0000 +------------------------+ - | Reserved for BIOS | Do not use. Reserved for BIOS EBDA. - 09A000 +------------------------+ - | Command line | - | Stack/heap | For use by the kernel real-mode code. - 098000 +------------------------+ - | Kernel setup | The kernel real-mode code. - 090200 +------------------------+ - | Kernel boot sector | The kernel legacy boot sector. - 090000 +------------------------+ - | Protected-mode kernel | The bulk of the kernel image. - 010000 +------------------------+ - | Boot loader | <- Boot sector entry point 0000:7C00 - 001000 +------------------------+ - | Reserved for MBR/BIOS | - 000800 +------------------------+ - | Typically used by MBR | - 000600 +------------------------+ - | BIOS use only | - 000000 +------------------------+ + | | + 0A0000 +------------------------+ + | Reserved for BIOS | Do not use. Reserved for BIOS EBDA. + 09A000 +------------------------+ + | Command line | + | Stack/heap | For use by the kernel real-mode code. + 098000 +------------------------+ + | Kernel setup | The kernel real-mode code. + 090200 +------------------------+ + | Kernel boot sector | The kernel legacy boot sector. + 090000 +------------------------+ + | Protected-mode kernel | The bulk of the kernel image. + 010000 +------------------------+ + | Boot loader | <- Boot sector entry point 0000:7C00 + 001000 +------------------------+ + | Reserved for MBR/BIOS | + 000800 +------------------------+ + | Typically used by MBR | + 000600 +------------------------+ + | BIOS use only | + 000000 +------------------------+ When using bzImage, the protected-mode kernel was relocated to 0x100000 ("high memory"), and the kernel real-mode block (boot sector, @@ -142,28 +142,28 @@ above the 0x9A000 point; too many BIOSes will break above that point. For a modern bzImage kernel with boot protocol version >= 2.02, a memory layout like the following is suggested:: - ~ ~ - | Protected-mode kernel | - 100000 +------------------------+ - | I/O memory hole | - 0A0000 +------------------------+ - | Reserved for BIOS | Leave as much as possible unused - ~ ~ - | Command line | (Can also be below the X+10000 mark) - X+10000 +------------------------+ - | Stack/heap | For use by the kernel real-mode code. - X+08000 +------------------------+ - | Kernel setup | The kernel real-mode code. - | Kernel boot sector | The kernel legacy boot sector. - X +------------------------+ - | Boot loader | <- Boot sector entry point 0000:7C00 - 001000 +------------------------+ - | Reserved for MBR/BIOS | - 000800 +------------------------+ - | Typically used by MBR | - 000600 +------------------------+ - | BIOS use only | - 000000 +------------------------+ + ~ ~ + | Protected-mode kernel | + 100000 +------------------------+ + | I/O memory hole | + 0A0000 +------------------------+ + | Reserved for BIOS | Leave as much as possible unused + ~ ~ + | Command line | (Can also be below the X+10000 mark) + X+10000 +------------------------+ + | Stack/heap | For use by the kernel real-mode code. + X+08000 +------------------------+ + | Kernel setup | The kernel real-mode code. + | Kernel boot sector | The kernel legacy boot sector. + X +------------------------+ + | Boot loader | <- Boot sector entry point 0000:7C00 + 001000 +------------------------+ + | Reserved for MBR/BIOS | + 000800 +------------------------+ + | Typically used by MBR | + 000600 +------------------------+ + | BIOS use only | + 000000 +------------------------+ ... where the address X is as low as the design of the boot loader permits. @@ -229,22 +229,22 @@ Offset/Size Proto Name Meaning =========== ======== ===================== ============================================ .. note:: - (1) For backwards compatibility, if the setup_sects field contains 0, the - real value is 4. + (1) For backwards compatibility, if the setup_sects field contains 0, + the real value is 4. - (2) For boot protocol prior to 2.04, the upper two bytes of the syssize - field are unusable, which means the size of a bzImage kernel - cannot be determined. + (2) For boot protocol prior to 2.04, the upper two bytes of the syssize + field are unusable, which means the size of a bzImage kernel + cannot be determined. - (3) Ignored, but safe to set, for boot protocols 2.02-2.09. + (3) Ignored, but safe to set, for boot protocols 2.02-2.09. If the "HdrS" (0x53726448) magic number is not found at offset 0x202, the boot protocol version is "old". Loading an old kernel, the following parameters should be assumed:: - Image type = zImage - initrd not supported - Real-mode kernel must be located at 0x90000. + Image type = zImage + initrd not supported + Real-mode kernel must be located at 0x90000. Otherwise, the "version" field contains the protocol version, e.g. protocol version 2.01 will contain 0x0201 in this field. When @@ -265,7 +265,7 @@ All general purpose boot loaders should write the fields marked nonstandard address should fill in the fields marked (reloc); other boot loaders can ignore those fields. -The byte order of all fields is littleendian (this is x86, after all.) +The byte order of all fields is little endian (this is x86, after all.) ============ =========== Field name: setup_sects @@ -365,7 +365,7 @@ Offset/size: 0x206/2 Protocol: 2.00+ ============ ======= - Contains the boot protocol version, in (major << 8)+minor format, + Contains the boot protocol version, in (major << 8) + minor format, e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version 10.17. @@ -397,17 +397,17 @@ Protocol: 2.00+ If set to a nonzero value, contains a pointer to a NUL-terminated human-readable kernel version number string, less 0x200. This can be used to display the kernel version to the user. This value - should be less than (0x200*setup_sects). + should be less than (0x200 * setup_sects). For example, if this value is set to 0x1c00, the kernel version number string can be found at offset 0x1e00 in the kernel file. This is a valid value if and only if the "setup_sects" field contains the value 15 or higher, as:: - 0x1c00 < 15*0x200 (= 0x1e00) but - 0x1c00 >= 14*0x200 (= 0x1c00) + 0x1c00 < 15 * 0x200 (= 0x1e00) but + 0x1c00 >= 14 * 0x200 (= 0x1c00) - 0x1c00 >> 9 = 14, So the minimum value for setup_secs is 15. + 0x1c00 >> 9 = 14, So the minimum value for setup_secs is 15. ============ ================== Field name: type_of_loader @@ -427,9 +427,9 @@ Protocol: 2.00+ For example, for T = 0x15, V = 0x234, write:: - type_of_loader <- 0xE4 - ext_loader_type <- 0x05 - ext_loader_ver <- 0x23 + type_of_loader <- 0xE4 + ext_loader_type <- 0x05 + ext_loader_ver <- 0x23 Assigned boot loader ids (hexadecimal): @@ -686,7 +686,7 @@ Protocol: 2.10+ If a boot loader makes use of this field, it should update the kernel_alignment field with the alignment unit desired; typically:: - kernel_alignment = 1 << min_alignment + kernel_alignment = 1 << min_alignment; There may be a considerable performance cost with an excessively misaligned kernel. Therefore, a loader should typically try each @@ -754,7 +754,7 @@ Protocol: 2.07+ 0x00000000 The default x86/PC environment 0x00000001 lguest 0x00000002 Xen - 0x00000003 Moorestown MID + 0x00000003 Intel MID (Moorestown, CloverTrail, Merrifield, Moorefield) 0x00000004 CE4100 TV Platform ========== ============================== @@ -808,13 +808,13 @@ Protocol: 2.09+ parameters passing mechanism. The definition of struct setup_data is as follow:: - struct setup_data { - u64 next; - u32 type; - u32 len; - u8 data[0]; - }; - + struct setup_data { + __u64 next; + __u32 type; + __u32 len; + __u8 data[]; + } + Where, the next is a 64-bit physical pointer to the next node of linked list, the next field of the last node is 0; the type is used to identify the contents of data; the len is the length of data @@ -834,12 +834,12 @@ Protocol: 2.09+ Thus setup_indirect struct and SETUP_INDIRECT type were introduced in protocol 2.15:: - struct setup_indirect { - __u32 type; - __u32 reserved; /* Reserved, must be set to zero. */ - __u64 len; - __u64 addr; - }; + struct setup_indirect { + __u32 type; + __u32 reserved; /* Reserved, must be set to zero. */ + __u64 len; + __u64 addr; + }; The type member is a SETUP_INDIRECT | SETUP_* type. However, it cannot be SETUP_INDIRECT itself since making the setup_indirect a tree structure @@ -849,17 +849,17 @@ Protocol: 2.09+ Let's give an example how to point to SETUP_E820_EXT data using setup_indirect. In this case setup_data and setup_indirect will look like this:: - struct setup_data { - __u64 next = 0 or <addr_of_next_setup_data_struct>; - __u32 type = SETUP_INDIRECT; - __u32 len = sizeof(setup_indirect); - __u8 data[sizeof(setup_indirect)] = struct setup_indirect { - __u32 type = SETUP_INDIRECT | SETUP_E820_EXT; - __u32 reserved = 0; - __u64 len = <len_of_SETUP_E820_EXT_data>; - __u64 addr = <addr_of_SETUP_E820_EXT_data>; - } - } + struct setup_data { + .next = 0, /* or <addr_of_next_setup_data_struct> */ + .type = SETUP_INDIRECT, + .len = sizeof(setup_indirect), + .data[sizeof(setup_indirect)] = (struct setup_indirect) { + .type = SETUP_INDIRECT | SETUP_E820_EXT, + .reserved = 0, + .len = <len_of_SETUP_E820_EXT_data>, + .addr = <addr_of_SETUP_E820_EXT_data>, + }, + } .. note:: SETUP_INDIRECT | SETUP_NONE objects cannot be properly distinguished @@ -896,19 +896,19 @@ Offset/size: 0x260/4 The kernel runtime start address is determined by the following algorithm:: - if (relocatable_kernel) { - if (load_address < pref_address) - load_address = pref_address; - runtime_start = align_up(load_address, kernel_alignment); - } else { - runtime_start = pref_address; - } + if (relocatable_kernel) { + if (load_address < pref_address) + load_address = pref_address; + runtime_start = align_up(load_address, kernel_alignment); + } else { + runtime_start = pref_address; + } Hence the necessary memory window location and size can be estimated by a boot loader as:: - memory_window_start = runtime_start; - memory_window_size = init_size; + memory_window_start = runtime_start; + memory_window_size = init_size; ============ =============== Field name: handover_offset @@ -938,12 +938,12 @@ The kernel_info =============== The relationships between the headers are analogous to the various data -sections: +sections:: setup_header = .data boot_params/setup_data = .bss -What is missing from the above list? That's right: +What is missing from the above list? That's right:: kernel_info = .rodata @@ -975,22 +975,22 @@ after kernel_info_var_len_data label. Each chunk of variable size data has to be prefixed with header/magic and its size, e.g.:: kernel_info: - .ascii "LToP" /* Header, Linux top (structure). */ - .long kernel_info_var_len_data - kernel_info - .long kernel_info_end - kernel_info - .long 0x01234567 /* Some fixed size data for the bootloaders. */ + .ascii "LToP" /* Header, Linux top (structure). */ + .long kernel_info_var_len_data - kernel_info + .long kernel_info_end - kernel_info + .long 0x01234567 /* Some fixed size data for the bootloaders. */ kernel_info_var_len_data: - example_struct: /* Some variable size data for the bootloaders. */ - .ascii "0123" /* Header/Magic. */ - .long example_struct_end - example_struct - .ascii "Struct" - .long 0x89012345 + example_struct: /* Some variable size data for the bootloaders. */ + .ascii "0123" /* Header/Magic. */ + .long example_struct_end - example_struct + .ascii "Struct" + .long 0x89012345 example_struct_end: - example_strings: /* Some variable size data for the bootloaders. */ - .ascii "ABCD" /* Header/Magic. */ - .long example_strings_end - example_strings - .asciz "String_0" - .asciz "String_1" + example_strings: /* Some variable size data for the bootloaders. */ + .ascii "ABCD" /* Header/Magic. */ + .long example_strings_end - example_strings + .asciz "String_0" + .asciz "String_1" example_strings_end: kernel_info_end: @@ -1038,16 +1038,6 @@ Offset/size: 0x000c/4 This field contains maximal allowed type for setup_data and setup_indirect structs. -The Image Checksum -================== - -From boot protocol version 2.08 onwards the CRC-32 is calculated over -the entire file using the characteristic polynomial 0x04C11DB7 and an -initial remainder of 0xffffffff. The checksum is appended to the -file; therefore the CRC of the file up to the limit specified in the -syssize field of the header is always 0. - - The Kernel Command Line ======================= @@ -1139,67 +1129,63 @@ mode segment. Such a boot loader should enter the following fields in the header:: - unsigned long base_ptr; /* base address for real-mode segment */ - - if ( setup_sects == 0 ) { - setup_sects = 4; - } + unsigned long base_ptr; /* base address for real-mode segment */ - if ( protocol >= 0x0200 ) { - type_of_loader = <type code>; - if ( loading_initrd ) { - ramdisk_image = <initrd_address>; - ramdisk_size = <initrd_size>; - } + if (setup_sects == 0) + setup_sects = 4; - if ( protocol >= 0x0202 && loadflags & 0x01 ) - heap_end = 0xe000; - else - heap_end = 0x9800; + if (protocol >= 0x0200) { + type_of_loader = <type code>; + if (loading_initrd) { + ramdisk_image = <initrd_address>; + ramdisk_size = <initrd_size>; + } - if ( protocol >= 0x0201 ) { - heap_end_ptr = heap_end - 0x200; - loadflags |= 0x80; /* CAN_USE_HEAP */ - } + if (protocol >= 0x0202 && loadflags & 0x01) + heap_end = 0xe000; + else + heap_end = 0x9800; - if ( protocol >= 0x0202 ) { - cmd_line_ptr = base_ptr + heap_end; - strcpy(cmd_line_ptr, cmdline); - } else { - cmd_line_magic = 0xA33F; - cmd_line_offset = heap_end; - setup_move_size = heap_end + strlen(cmdline)+1; - strcpy(base_ptr+cmd_line_offset, cmdline); - } - } else { - /* Very old kernel */ + if (protocol >= 0x0201) { + heap_end_ptr = heap_end - 0x200; + loadflags |= 0x80; /* CAN_USE_HEAP */ + } - heap_end = 0x9800; + if (protocol >= 0x0202) { + cmd_line_ptr = base_ptr + heap_end; + strcpy(cmd_line_ptr, cmdline); + } else { + cmd_line_magic = 0xA33F; + cmd_line_offset = heap_end; + setup_move_size = heap_end + strlen(cmdline) + 1; + strcpy(base_ptr + cmd_line_offset, cmdline); + } + } else { + /* Very old kernel */ - cmd_line_magic = 0xA33F; - cmd_line_offset = heap_end; + heap_end = 0x9800; - /* A very old kernel MUST have its real-mode code - loaded at 0x90000 */ + cmd_line_magic = 0xA33F; + cmd_line_offset = heap_end; - if ( base_ptr != 0x90000 ) { - /* Copy the real-mode kernel */ - memcpy(0x90000, base_ptr, (setup_sects+1)*512); - base_ptr = 0x90000; /* Relocated */ - } + /* A very old kernel MUST have its real-mode code loaded at 0x90000 */ + if (base_ptr != 0x90000) { + /* Copy the real-mode kernel */ + memcpy(0x90000, base_ptr, (setup_sects + 1) * 512); + base_ptr = 0x90000; /* Relocated */ + } - strcpy(0x90000+cmd_line_offset, cmdline); + strcpy(0x90000 + cmd_line_offset, cmdline); - /* It is recommended to clear memory up to the 32K mark */ - memset(0x90000 + (setup_sects+1)*512, 0, - (64-(setup_sects+1))*512); - } + /* It is recommended to clear memory up to the 32K mark */ + memset(0x90000 + (setup_sects + 1) * 512, 0, (64 - (setup_sects + 1)) * 512); + } Loading The Rest of The Kernel ============================== -The 32-bit (non-real-mode) kernel starts at offset (setup_sects+1)*512 +The 32-bit (non-real-mode) kernel starts at offset (setup_sects + 1) * 512 in the kernel file (again, if setup_sects == 0 the real value is 4.) It should be loaded at address 0x10000 for Image/zImage kernels and 0x100000 for bzImage kernels. @@ -1207,13 +1193,14 @@ It should be loaded at address 0x10000 for Image/zImage kernels and The kernel is a bzImage kernel if the protocol >= 2.00 and the 0x01 bit (LOAD_HIGH) in the loadflags field is set:: - is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01); - load_address = is_bzImage ? 0x100000 : 0x10000; + is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01); + load_address = is_bzImage ? 0x100000 : 0x10000; -Note that Image/zImage kernels can be up to 512K in size, and thus use -the entire 0x10000-0x90000 range of memory. This means it is pretty -much a requirement for these kernels to load the real-mode part at -0x90000. bzImage kernels allow much more flexibility. +.. note:: + Image/zImage kernels can be up to 512K in size, and thus use the entire + 0x10000-0x90000 range of memory. This means it is pretty much a + requirement for these kernels to load the real-mode part at 0x90000. + bzImage kernels allow much more flexibility. Special Command Line Options ============================ @@ -1282,19 +1269,20 @@ es = ss. In our example from above, we would do:: - /* Note: in the case of the "old" kernel protocol, base_ptr must - be == 0x90000 at this point; see the previous sample code */ + /* + * Note: in the case of the "old" kernel protocol, base_ptr must + * be == 0x90000 at this point; see the previous sample code. + */ + seg = base_ptr >> 4; - seg = base_ptr >> 4; + cli(); /* Enter with interrupts disabled! */ - cli(); /* Enter with interrupts disabled! */ + /* Set up the real-mode kernel stack */ + _SS = seg; + _SP = heap_end; - /* Set up the real-mode kernel stack */ - _SS = seg; - _SP = heap_end; - - _DS = _ES = _FS = _GS = seg; - jmp_far(seg+0x20, 0); /* Run the kernel */ + _DS = _ES = _FS = _GS = seg; + jmp_far(seg + 0x20, 0); /* Run the kernel */ If your boot sector accesses a floppy drive, it is recommended to switch off the floppy motor before running the kernel, since the @@ -1349,7 +1337,7 @@ from offset 0x01f1 of kernel image on should be loaded into struct boot_params and examined. The end of setup header can be calculated as follow:: - 0x0202 + byte value at offset 0x0201 + 0x0202 + byte value at offset 0x0201 In addition to read/modify/write the setup header of the struct boot_params as that of 16-bit boot protocol, the boot loader should @@ -1385,7 +1373,7 @@ Then, the setup header at offset 0x01f1 of kernel image on should be loaded into struct boot_params and examined. The end of setup header can be calculated as follows:: - 0x0202 + byte value at offset 0x0201 + 0x0202 + byte value at offset 0x0201 In addition to read/modify/write the setup header of the struct boot_params as that of 16-bit boot protocol, the boot loader should @@ -1427,7 +1415,7 @@ execution context provided by the EFI firmware. The function prototype for the handover entry point looks like this:: - efi_stub_entry(void *handle, efi_system_table_t *table, struct boot_params *bp) + void efi_stub_entry(void *handle, efi_system_table_t *table, struct boot_params *bp); 'handle' is the EFI image handle passed to the boot loader by the EFI firmware, 'table' is the EFI system table - these are the first two @@ -1442,12 +1430,13 @@ The boot loader *must* fill out the following fields in bp:: All other fields should be zero. -NOTE: The EFI Handover Protocol is deprecated in favour of the ordinary PE/COFF - entry point, combined with the LINUX_EFI_INITRD_MEDIA_GUID based initrd - loading protocol (refer to [0] for an example of the bootloader side of - this), which removes the need for any knowledge on the part of the EFI - bootloader regarding the internal representation of boot_params or any - requirements/limitations regarding the placement of the command line - and ramdisk in memory, or the placement of the kernel image itself. +.. note:: + The EFI Handover Protocol is deprecated in favour of the ordinary PE/COFF + entry point, combined with the LINUX_EFI_INITRD_MEDIA_GUID based initrd + loading protocol (refer to [0] for an example of the bootloader side of + this), which removes the need for any knowledge on the part of the EFI + bootloader regarding the internal representation of boot_params or any + requirements/limitations regarding the placement of the command line + and ramdisk in memory, or the placement of the kernel image itself. [0] https://github.com/u-boot/u-boot/commit/ec80b4735a593961fe701cc3a5d717d4739b0fd0 diff --git a/Documentation/arch/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst index a824affd741d..6768fc1fad16 100644 --- a/Documentation/arch/x86/resctrl.rst +++ b/Documentation/arch/x86/resctrl.rst @@ -384,6 +384,16 @@ When monitoring is enabled all MON groups will also contain: Available only with debug option. The identifier used by hardware for the monitor group. On x86 this is the RMID. +When the "mba_MBps" mount option is used all CTRL_MON groups will also contain: + +"mba_MBps_event": + Reading this file shows which memory bandwidth event is used + as input to the software feedback loop that keeps memory bandwidth + below the value specified in the schemata file. Writing the + name of one of the supported memory bandwidth events found in + /sys/fs/resctrl/info/L3_MON/mon_features changes the input + event. + Resource allocation rules ------------------------- diff --git a/Documentation/arch/x86/sva.rst b/Documentation/arch/x86/sva.rst index 33cb05005982..6a759984d471 100644 --- a/Documentation/arch/x86/sva.rst +++ b/Documentation/arch/x86/sva.rst @@ -25,7 +25,7 @@ to cache translations for virtual addresses. The IOMMU driver uses the mmu_notifier() support to keep the device TLB cache and the CPU cache in sync. When an ATS lookup fails for a virtual address, the device should use the PRI in order to request the virtual address to be paged into the -CPU page tables. The device must use ATS again in order the fetch the +CPU page tables. The device must use ATS again in order to fetch the translation before use. Shared Hardware Workqueues @@ -216,7 +216,7 @@ submitting work and processing completions. Single Root I/O Virtualization (SR-IOV) focuses on providing independent hardware interfaces for virtualizing hardware. Hence, it's required to be -almost fully functional interface to software supporting the traditional +an almost fully functional interface to software supporting the traditional BARs, space for interrupts via MSI-X, its own register layout. Virtual Functions (VFs) are assisted by the Physical Function (PF) driver. diff --git a/Documentation/arch/x86/topology.rst b/Documentation/arch/x86/topology.rst index 7352ab89a55a..c12837e61bda 100644 --- a/Documentation/arch/x86/topology.rst +++ b/Documentation/arch/x86/topology.rst @@ -135,6 +135,10 @@ Thread-related topology information in the kernel: The ID of the core to which a thread belongs. It is also printed in /proc/cpuinfo "core_id." + - topology_logical_core_id(); + + The logical core ID to which a thread belongs. + System topology examples diff --git a/Documentation/arch/x86/usb-legacy-support.rst b/Documentation/arch/x86/usb-legacy-support.rst index e01c08b7c981..b17bf122270a 100644 --- a/Documentation/arch/x86/usb-legacy-support.rst +++ b/Documentation/arch/x86/usb-legacy-support.rst @@ -20,11 +20,7 @@ It has several drawbacks, though: features (wheel, extra buttons, touchpad mode) of the real PS/2 mouse may not be available. -2) If CONFIG_HIGHMEM64G is enabled, the PS/2 mouse emulation can cause - system crashes, because the SMM BIOS is not expecting to be in PAE mode. - The Intel E7505 is a typical machine where this happens. - -3) If AMD64 64-bit mode is enabled, again system crashes often happen, +2) If AMD64 64-bit mode is enabled, again system crashes often happen, because the SMM BIOS isn't expecting the CPU to be in 64-bit mode. The BIOS manufacturers only test with Windows, and Windows doesn't do 64-bit yet. @@ -38,11 +34,6 @@ Problem 1) compiled-in, too. Problem 2) - can currently only be solved by either disabling HIGHMEM64G - in the kernel config or USB Legacy support in the BIOS. A BIOS update - could help, but so far no such update exists. - -Problem 3) is usually fixed by a BIOS update. Check the board manufacturers web site. If an update is not available, disable USB Legacy support in the BIOS. If this alone doesn't help, try also adding diff --git a/Documentation/arch/x86/x86_64/boot-options.rst b/Documentation/arch/x86/x86_64/boot-options.rst deleted file mode 100644 index d69e3cfbdba5..000000000000 --- a/Documentation/arch/x86/x86_64/boot-options.rst +++ /dev/null @@ -1,312 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=========================== -AMD64 Specific Boot Options -=========================== - -There are many others (usually documented in driver documentation), but -only the AMD64 specific ones are listed here. - -Machine check -============= -Please see Documentation/arch/x86/x86_64/machinecheck.rst for sysfs runtime tunables. - - mce=off - Disable machine check - mce=no_cmci - Disable CMCI(Corrected Machine Check Interrupt) that - Intel processor supports. Usually this disablement is - not recommended, but it might be handy if your hardware - is misbehaving. - Note that you'll get more problems without CMCI than with - due to the shared banks, i.e. you might get duplicated - error logs. - mce=dont_log_ce - Don't make logs for corrected errors. All events reported - as corrected are silently cleared by OS. - This option will be useful if you have no interest in any - of corrected errors. - mce=ignore_ce - Disable features for corrected errors, e.g. polling timer - and CMCI. All events reported as corrected are not cleared - by OS and remained in its error banks. - Usually this disablement is not recommended, however if - there is an agent checking/clearing corrected errors - (e.g. BIOS or hardware monitoring applications), conflicting - with OS's error handling, and you cannot deactivate the agent, - then this option will be a help. - mce=no_lmce - Do not opt-in to Local MCE delivery. Use legacy method - to broadcast MCEs. - mce=bootlog - Enable logging of machine checks left over from booting. - Disabled by default on AMD Fam10h and older because some BIOS - leave bogus ones. - If your BIOS doesn't do that it's a good idea to enable though - to make sure you log even machine check events that result - in a reboot. On Intel systems it is enabled by default. - mce=nobootlog - Disable boot machine check logging. - mce=monarchtimeout (number) - monarchtimeout: - Sets the time in us to wait for other CPUs on machine checks. 0 - to disable. - mce=bios_cmci_threshold - Don't overwrite the bios-set CMCI threshold. This boot option - prevents Linux from overwriting the CMCI threshold set by the - bios. Without this option, Linux always sets the CMCI - threshold to 1. Enabling this may make memory predictive failure - analysis less effective if the bios sets thresholds for memory - errors since we will not see details for all errors. - mce=recovery - Force-enable recoverable machine check code paths - - nomce (for compatibility with i386) - same as mce=off - - Everything else is in sysfs now. - -APICs -===== - - apic - Use IO-APIC. Default - - noapic - Don't use the IO-APIC. - - disableapic - Don't use the local APIC - - nolapic - Don't use the local APIC (alias for i386 compatibility) - - pirq=... - See Documentation/arch/x86/i386/IO-APIC.rst - - noapictimer - Don't set up the APIC timer - - no_timer_check - Don't check the IO-APIC timer. This can work around - problems with incorrect timer initialization on some boards. - - apicpmtimer - Do APIC timer calibration using the pmtimer. Implies - apicmaintimer. Useful when your PIT timer is totally broken. - -Timing -====== - - notsc - Deprecated, use tsc=unstable instead. - - nohpet - Don't use the HPET timer. - -Idle loop -========= - - idle=poll - Don't do power saving in the idle loop using HLT, but poll for rescheduling - event. This will make the CPUs eat a lot more power, but may be useful - to get slightly better performance in multiprocessor benchmarks. It also - makes some profiling using performance counters more accurate. - Please note that on systems with MONITOR/MWAIT support (like Intel EM64T - CPUs) this option has no performance advantage over the normal idle loop. - It may also interact badly with hyperthreading. - -Rebooting -========= - - reboot=b[ios] | t[riple] | k[bd] | a[cpi] | e[fi] | p[ci] [, [w]arm | [c]old] - bios - Use the CPU reboot vector for warm reset - warm - Don't set the cold reboot flag - cold - Set the cold reboot flag - triple - Force a triple fault (init) - kbd - Use the keyboard controller. cold reset (default) - acpi - Use the ACPI RESET_REG in the FADT. If ACPI is not configured or - the ACPI reset does not work, the reboot path attempts the reset - using the keyboard controller. - efi - Use efi reset_system runtime service. If EFI is not configured or - the EFI reset does not work, the reboot path attempts the reset using - the keyboard controller. - pci - Use a write to the PCI config space register 0xcf9 to trigger reboot. - - Using warm reset will be much faster especially on big memory - systems because the BIOS will not go through the memory check. - Disadvantage is that not all hardware will be completely reinitialized - on reboot so there may be boot problems on some systems. - - reboot=force - Don't stop other CPUs on reboot. This can make reboot more reliable - in some cases. - - reboot=default - There are some built-in platform specific "quirks" - you may see: - "reboot: <name> series board detected. Selecting <type> for reboots." - In the case where you think the quirk is in error (e.g. you have - newer BIOS, or newer board) using this option will ignore the built-in - quirk table, and use the generic default reboot actions. - -NUMA -==== - - numa=off - Only set up a single NUMA node spanning all memory. - - numa=noacpi - Don't parse the SRAT table for NUMA setup - - numa=nohmat - Don't parse the HMAT table for NUMA setup, or soft-reserved memory - partitioning. - -ACPI -==== - - acpi=off - Don't enable ACPI - acpi=ht - Use ACPI boot table parsing, but don't enable ACPI interpreter - acpi=force - Force ACPI on (currently not needed) - acpi=strict - Disable out of spec ACPI workarounds. - acpi_sci={edge,level,high,low} - Set up ACPI SCI interrupt. - acpi=noirq - Don't route interrupts - acpi=nocmcff - Disable firmware first mode for corrected errors. This - disables parsing the HEST CMC error source to check if - firmware has set the FF flag. This may result in - duplicate corrected error reports. - -PCI -=== - - pci=off - Don't use PCI - pci=conf1 - Use conf1 access. - pci=conf2 - Use conf2 access. - pci=rom - Assign ROMs. - pci=assign-busses - Assign busses - pci=irqmask=MASK - Set PCI interrupt mask to MASK - pci=lastbus=NUMBER - Scan up to NUMBER busses, no matter what the mptable says. - pci=noacpi - Don't use ACPI to set up PCI interrupt routing. - -IOMMU (input/output memory management unit) -=========================================== -Multiple x86-64 PCI-DMA mapping implementations exist, for example: - - 1. <kernel/dma/direct.c>: use no hardware/software IOMMU at all - (e.g. because you have < 3 GB memory). - Kernel boot message: "PCI-DMA: Disabling IOMMU" - - 2. <arch/x86/kernel/amd_gart_64.c>: AMD GART based hardware IOMMU. - Kernel boot message: "PCI-DMA: using GART IOMMU" - - 3. <arch/x86_64/kernel/pci-swiotlb.c> : Software IOMMU implementation. Used - e.g. if there is no hardware IOMMU in the system and it is need because - you have >3GB memory or told the kernel to us it (iommu=soft)) - Kernel boot message: "PCI-DMA: Using software bounce buffering - for IO (SWIOTLB)" - -:: - - iommu=[<size>][,noagp][,off][,force][,noforce] - [,memaper[=<order>]][,merge][,fullflush][,nomerge] - [,noaperture] - -General iommu options: - - off - Don't initialize and use any kind of IOMMU. - noforce - Don't force hardware IOMMU usage when it is not needed. (default). - force - Force the use of the hardware IOMMU even when it is - not actually needed (e.g. because < 3 GB memory). - soft - Use software bounce buffering (SWIOTLB) (default for - Intel machines). This can be used to prevent the usage - of an available hardware IOMMU. - -iommu options only relevant to the AMD GART hardware IOMMU: - - <size> - Set the size of the remapping area in bytes. - allowed - Overwrite iommu off workarounds for specific chipsets. - fullflush - Flush IOMMU on each allocation (default). - nofullflush - Don't use IOMMU fullflush. - memaper[=<order>] - Allocate an own aperture over RAM with size 32MB<<order. - (default: order=1, i.e. 64MB) - merge - Do scatter-gather (SG) merging. Implies "force" (experimental). - nomerge - Don't do scatter-gather (SG) merging. - noaperture - Ask the IOMMU not to touch the aperture for AGP. - noagp - Don't initialize the AGP driver and use full aperture. - panic - Always panic when IOMMU overflows. - -iommu options only relevant to the software bounce buffering (SWIOTLB) IOMMU -implementation: - - swiotlb=<slots>[,force,noforce] - <slots> - Prereserve that many 2K slots for the software IO bounce buffering. - force - Force all IO through the software TLB. - noforce - Do not initialize the software TLB. - - -Miscellaneous -============= - - nogbpages - Do not use GB pages for kernel direct mappings. - gbpages - Use GB pages for kernel direct mappings. - - -AMD SEV (Secure Encrypted Virtualization) -========================================= -Options relating to AMD SEV, specified via the following format: - -:: - - sev=option1[,option2] - -The available options are: - - debug - Enable debug messages. - - nosnp - Do not enable SEV-SNP (applies to host/hypervisor only). Setting - 'nosnp' avoids the RMP check overhead in memory accesses when - users do not want to run SEV-SNP guests. diff --git a/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst b/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst index ba74617d4999..970ee94eb551 100644 --- a/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst +++ b/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst @@ -18,7 +18,7 @@ For more information on the features of cpusets, see Documentation/admin-guide/cgroup-v1/cpusets.rst. There are a number of different configurations you can use for your needs. For more information on the numa=fake command line option and its various ways of -configuring fake nodes, see Documentation/arch/x86/x86_64/boot-options.rst. +configuring fake nodes, see Documentation/admin-guide/kernel-parameters.txt For the purposes of this introduction, we'll assume a very primitive NUMA emulation setup of "numa=fake=4*512,". This will split our system memory into diff --git a/Documentation/arch/x86/x86_64/index.rst b/Documentation/arch/x86/x86_64/index.rst index ad15e9bd623f..a0261957a08a 100644 --- a/Documentation/arch/x86/x86_64/index.rst +++ b/Documentation/arch/x86/x86_64/index.rst @@ -7,7 +7,6 @@ x86_64 Support .. toctree:: :maxdepth: 2 - boot-options uefi mm 5level-paging diff --git a/Documentation/arch/x86/x86_64/uefi.rst b/Documentation/arch/x86/x86_64/uefi.rst index fbc30c9a071d..e84592dbd6c1 100644 --- a/Documentation/arch/x86/x86_64/uefi.rst +++ b/Documentation/arch/x86/x86_64/uefi.rst @@ -12,14 +12,20 @@ with EFI firmware and specifications are listed below. 1. UEFI specification: http://www.uefi.org -2. Booting Linux kernel on UEFI x86_64 platform requires bootloader - support. Elilo with x86_64 support can be used. +2. Booting Linux kernel on UEFI x86_64 platform can either be + done using the <Documentation/admin-guide/efi-stub.rst> or using a + separate bootloader. 3. x86_64 platform with EFI/UEFI firmware. Mechanics --------- +Refer to <Documentation/admin-guide/efi-stub.rst> to learn how to use the EFI stub. + +Below are general EFI setup guidelines on the x86_64 platform, +regardless of whether you use the EFI stub or a separate bootloader. + - Build the kernel with the following configuration:: CONFIG_FB_EFI=y @@ -31,16 +37,27 @@ Mechanics CONFIG_EFI=y CONFIG_EFIVAR_FS=y or m # optional -- Create a VFAT partition on the disk -- Copy the following to the VFAT partition: +- Create a VFAT partition on the disk with the EFI System flag + You can do this with fdisk with the following commands: + + 1. g - initialize a GPT partition table + 2. n - create a new partition + 3. t - change the partition type to "EFI System" (number 1) + 4. w - write and save the changes + + Afterwards, initialize the VFAT filesystem by running mkfs:: + + mkfs.fat /dev/<your-partition> + +- Copy the boot files to the VFAT partition: + If you use the EFI stub method, the kernel acts also as an EFI executable. + + You can just copy the bzImage to the EFI/boot/bootx64.efi path on the partition + so that it will automatically get booted, see the <Documentation/admin-guide/efi-stub.rst> page + for additional instructions regarding passage of kernel parameters and initramfs. - elilo bootloader with x86_64 support, elilo configuration file, - kernel image built in first step and corresponding - initrd. Instructions on building elilo and its dependencies - can be found in the elilo sourceforge project. + If you use a custom bootloader, refer to the relevant documentation for help on this part. -- Boot to EFI shell and invoke elilo choosing the kernel image built - in first step. - If some or all EFI runtime services don't work, you can try following kernel command line parameters to turn off some or all EFI runtime services. diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst index 51665a3e6a50..1e0e7358e14a 100644 --- a/Documentation/block/ublk.rst +++ b/Documentation/block/ublk.rst @@ -333,6 +333,4 @@ References .. [#userspace_readme] https://github.com/ming1/ubdsrv/blob/master/README -.. [#stefan] https://lore.kernel.org/linux-block/YoOr6jBfgVm8GvWg@stefanha-x1.localdomain/ - .. [#xiaoguang] https://lore.kernel.org/linux-block/YoOr6jBfgVm8GvWg@stefanha-x1.localdomain/ diff --git a/Documentation/conf.py b/Documentation/conf.py index 0c2205d536b3..3dad1f90b098 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -47,7 +47,7 @@ from load_config import loadConfig # -- General configuration ------------------------------------------------ # If your documentation needs a minimal Sphinx version, state it here. -needs_sphinx = '2.4.4' +needs_sphinx = '3.4.3' # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom diff --git a/Documentation/core-api/cgroup.rst b/Documentation/core-api/cgroup.rst new file mode 100644 index 000000000000..734ea21e1e17 --- /dev/null +++ b/Documentation/core-api/cgroup.rst @@ -0,0 +1,9 @@ +================== +Cgroup Kernel APIs +================== + +Device Memory Cgroup API (dmemcg) +================================= +.. kernel-doc:: kernel/cgroup/dmem.c + :export: + diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index 563b8fc0002f..e9789bd381d8 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -53,6 +53,7 @@ Library functionality that is used throughout the kernel. floating-point union_find min_heap + parser Low level entry and exit ======================== @@ -109,6 +110,7 @@ more memory-management documentation in Documentation/mm/index.rst. dma-isa-lpc swiotlb mm-api + cgroup genalloc pin_user_pages boot-time-mm diff --git a/Documentation/core-api/kref.rst b/Documentation/core-api/kref.rst index c61eea6f1bf2..8db9ff03d952 100644 --- a/Documentation/core-api/kref.rst +++ b/Documentation/core-api/kref.rst @@ -3,7 +3,7 @@ Adding reference counters (krefs) to kernel objects =================================================== :Author: Corey Minyard <minyard@acm.org> -:Author: Thomas Hellstrom <thellstrom@vmware.com> +:Author: Thomas Hellström <thomas.hellstrom@linux.intel.com> A lot of this was lifted from Greg Kroah-Hartman's 2004 OLS paper and presentation on krefs, which can be found at: @@ -321,3 +321,8 @@ rcu grace period after release_entry_rcu was called. That can be accomplished by using kfree_rcu(entry, rhead) as done above, or by calling synchronize_rcu() before using kfree, but note that synchronize_rcu() may sleep for a substantial amount of time. + +Functions and structures +======================== + +.. kernel-doc:: include/linux/kref.h diff --git a/Documentation/core-api/min_heap.rst b/Documentation/core-api/min_heap.rst index 0c636c8b7aa5..9f57766581df 100644 --- a/Documentation/core-api/min_heap.rst +++ b/Documentation/core-api/min_heap.rst @@ -4,6 +4,8 @@ Min Heap API ============ +:Author: Kuan-Wei Chiu <visitorckw@gmail.com> + Introduction ============ @@ -45,8 +47,8 @@ Example: #define MIN_HEAP_PREALLOCATED(_type, _name, _nr) struct _name { - int nr; /* Number of elements in the heap */ - int size; /* Maximum number of elements that can be held */ + size_t nr; /* Number of elements in the heap */ + size_t size; /* Maximum number of elements that can be held */ _type *data; /* Pointer to the heap data */ _type preallocated[_nr]; /* Static preallocated array */ } diff --git a/Documentation/core-api/packing.rst b/Documentation/core-api/packing.rst index 821691f23c54..0ce2078c8e13 100644 --- a/Documentation/core-api/packing.rst +++ b/Documentation/core-api/packing.rst @@ -227,11 +227,119 @@ Intended use Drivers that opt to use this API first need to identify which of the above 3 quirk combinations (for a total of 8) match what the hardware documentation -describes. Then they should wrap the packing() function, creating a new -xxx_packing() that calls it using the proper QUIRK_* one-hot bits set. +describes. + +There are 3 supported usage patterns, detailed below. + +packing() +^^^^^^^^^ + +This API function is deprecated. The packing() function returns an int-encoded error code, which protects the programmer against incorrect API use. The errors are not expected to occur -during runtime, therefore it is reasonable for xxx_packing() to return void -and simply swallow those errors. Optionally it can dump stack or print the -error description. +during runtime, therefore it is reasonable to wrap packing() into a custom +function which returns void and swallows those errors. Optionally it can +dump stack or print the error description. + +.. code-block:: c + + void my_packing(void *buf, u64 *val, int startbit, int endbit, + size_t len, enum packing_op op) + { + int err; + + /* Adjust quirks accordingly */ + err = packing(buf, val, startbit, endbit, len, op, QUIRK_LSW32_IS_FIRST); + if (likely(!err)) + return; + + if (err == -EINVAL) { + pr_err("Start bit (%d) expected to be larger than end (%d)\n", + startbit, endbit); + } else if (err == -ERANGE) { + if ((startbit - endbit + 1) > 64) + pr_err("Field %d-%d too large for 64 bits!\n", + startbit, endbit); + else + pr_err("Cannot store %llx inside bits %d-%d (would truncate)\n", + *val, startbit, endbit); + } + dump_stack(); + } + +pack() and unpack() +^^^^^^^^^^^^^^^^^^^ + +These are const-correct variants of packing(), and eliminate the last "enum +packing_op op" argument. + +Calling pack(...) is equivalent, and preferred, to calling packing(..., PACK). + +Calling unpack(...) is equivalent, and preferred, to calling packing(..., UNPACK). + +pack_fields() and unpack_fields() +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The library exposes optimized functions for the scenario where there are many +fields represented in a buffer, and it encourages consumer drivers to avoid +repetitive calls to pack() and unpack() for each field, but instead use +pack_fields() and unpack_fields(), which reduces the code footprint. + +These APIs use field definitions in arrays of ``struct packed_field_u8`` or +``struct packed_field_u16``, allowing consumer drivers to minimize the size +of these arrays according to their custom requirements. + +The pack_fields() and unpack_fields() API functions are actually macros which +automatically select the appropriate function at compile time, based on the +type of the fields array passed in. + +An additional benefit over pack() and unpack() is that sanity checks on the +field definitions are handled at compile time with ``BUILD_BUG_ON`` rather +than only when the offending code is executed. These functions return void and +wrapping them to handle unexpected errors is not necessary. + +It is recommended, but not required, that you wrap your packed buffer into a +structured type with a fixed size. This generally makes it easier for the +compiler to enforce that the correct size buffer is used. + +Here is an example of how to use the fields APIs: + +.. code-block:: c + + /* Ordering inside the unpacked structure is flexible and can be different + * from the packed buffer. Here, it is optimized to reduce padding. + */ + struct data { + u64 field3; + u32 field4; + u16 field1; + u8 field2; + }; + + #define SIZE 13 + + typdef struct __packed { u8 buf[SIZE]; } packed_buf_t; + + static const struct packed_field_u8 fields[] = { + PACKED_FIELD(100, 90, struct data, field1), + PACKED_FIELD(90, 87, struct data, field2), + PACKED_FIELD(86, 30, struct data, field3), + PACKED_FIELD(29, 0, struct data, field4), + }; + + void unpack_your_data(const packed_buf_t *buf, struct data *unpacked) + { + BUILD_BUG_ON(sizeof(*buf) != SIZE; + + unpack_fields(buf, sizeof(*buf), unpacked, fields, + QUIRK_LITTLE_ENDIAN); + } + + void pack_your_data(const struct data *unpacked, packed_buf_t *buf) + { + BUILD_BUG_ON(sizeof(*buf) != SIZE; + + pack_fields(buf, sizeof(*buf), unpacked, fields, + QUIRK_LITTLE_ENDIAN); + } diff --git a/Documentation/core-api/parser.rst b/Documentation/core-api/parser.rst new file mode 100644 index 000000000000..45750d04b895 --- /dev/null +++ b/Documentation/core-api/parser.rst @@ -0,0 +1,17 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +============== +Generic parser +============== + +Overview +======== + +The generic parser is a simple parser for parsing mount options, +filesystem options, driver options, subsystem options, etc. + +Parser API +========== + +.. kernel-doc:: lib/parser.c + :export: diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index ecccc0473da9..4bdc394e86af 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -661,7 +661,7 @@ Do *not* use it from C. Thanks ====== -If you add other %p extensions, please extend <lib/test_printf.c> with -one or more test cases, if at all feasible. +If you add other %p extensions, please extend <lib/tests/printf_kunit.c> +with one or more test cases, if at all feasible. Thank you for your cooperation and attention. diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst index 27a9cccc792c..06f766a6aab2 100644 --- a/Documentation/core-api/symbol-namespaces.rst +++ b/Documentation/core-api/symbol-namespaces.rst @@ -41,9 +41,9 @@ entries. In addition to the macros EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(), that allow exporting of kernel symbols to the kernel symbol table, variants of these are available to export symbols into a certain namespace: EXPORT_SYMBOL_NS() and -EXPORT_SYMBOL_NS_GPL(). They take one additional argument: the namespace. -Please note that due to macro expansion that argument needs to be a -preprocessor symbol. E.g. to export the symbol ``usb_stor_suspend`` into the +EXPORT_SYMBOL_NS_GPL(). They take one additional argument: the namespace as a +string constant. Note that this string must not contain whitespaces. +E.g. to export the symbol ``usb_stor_suspend`` into the namespace ``USB_STORAGE``, use:: EXPORT_SYMBOL_NS(usb_stor_suspend, "USB_STORAGE"); @@ -78,11 +78,10 @@ as this argument has preference over a default symbol namespace. A second option to define the default namespace is directly in the compilation unit as preprocessor statement. The above example would then read:: - #undef DEFAULT_SYMBOL_NAMESPACE #define DEFAULT_SYMBOL_NAMESPACE "USB_COMMON" -within the corresponding compilation unit before any EXPORT_SYMBOL macro is -used. +within the corresponding compilation unit before the #include for +<linux/export.h>. Typically it's placed before the first #include statement. 3. How to use Symbols exported in Namespaces ============================================ diff --git a/Documentation/core-api/this_cpu_ops.rst b/Documentation/core-api/this_cpu_ops.rst index 91acbcf30e9b..533ac5dd5750 100644 --- a/Documentation/core-api/this_cpu_ops.rst +++ b/Documentation/core-api/this_cpu_ops.rst @@ -138,12 +138,22 @@ get_cpu/put_cpu sequence requires. No processor number is available. Instead, the offset of the local per cpu area is simply added to the per cpu offset. -Note that this operation is usually used in a code segment when -preemption has been disabled. The pointer is then used to -access local per cpu data in a critical section. When preemption -is re-enabled this pointer is usually no longer useful since it may -no longer point to per cpu data of the current processor. - +Note that this operation can only be used in code segments where +smp_processor_id() may be used, for example, where preemption has been +disabled. The pointer is then used to access local per cpu data in a +critical section. When preemption is re-enabled this pointer is usually +no longer useful since it may no longer point to per cpu data of the +current processor. + +The special cases where it makes sense to obtain a per-CPU pointer in +preemptible code are addressed by raw_cpu_ptr(), but such use cases need +to handle cases where two different CPUs are accessing the same per cpu +variable, which might well be that of a third CPU. These use cases are +typically performance optimizations. For example, SRCU implements a pair +of counters as a pair of per-CPU variables, and rcu_read_lock_nmisafe() +uses raw_cpu_ptr() to get a pointer to some CPU's counter, and uses +atomic_inc_long() to handle migration between the raw_cpu_ptr() and +the atomic_inc_long(). Per cpu variables and offsets ----------------------------- diff --git a/Documentation/core-api/xarray.rst b/Documentation/core-api/xarray.rst index 77e0ece2b1d6..f6a3eef4fe7f 100644 --- a/Documentation/core-api/xarray.rst +++ b/Documentation/core-api/xarray.rst @@ -42,8 +42,8 @@ call xa_tag_pointer() to create an entry with a tag, xa_untag_pointer() to turn a tagged entry back into an untagged pointer and xa_pointer_tag() to retrieve the tag of an entry. Tagged pointers use the same bits that are used to distinguish value entries from normal pointers, so you must -decide whether they want to store value entries or tagged pointers in -any particular XArray. +decide whether you want to store value entries or tagged pointers in any +particular XArray. The XArray does not support storing IS_ERR() pointers as some conflict with value entries or internal entries. @@ -52,8 +52,9 @@ An unusual feature of the XArray is the ability to create entries which occupy a range of indices. Once stored to, looking up any index in the range will return the same entry as looking up any other index in the range. Storing to any index will store to all of them. Multi-index -entries can be explicitly split into smaller entries, or storing ``NULL`` -into any entry will cause the XArray to forget about the range. +entries can be explicitly split into smaller entries. Unsetting (using +xa_erase() or xa_store() with ``NULL``) any entry will cause the XArray +to forget about the range. Normal API ========== @@ -63,13 +64,14 @@ for statically allocated XArrays or xa_init() for dynamically allocated ones. A freshly-initialised XArray contains a ``NULL`` pointer at every index. -You can then set entries using xa_store() and get entries -using xa_load(). xa_store will overwrite any entry with the -new entry and return the previous entry stored at that index. You can -use xa_erase() instead of calling xa_store() with a -``NULL`` entry. There is no difference between an entry that has never -been stored to, one that has been erased and one that has most recently -had ``NULL`` stored to it. +You can then set entries using xa_store() and get entries using +xa_load(). xa_store() will overwrite any entry with the new entry and +return the previous entry stored at that index. You can unset entries +using xa_erase() or by setting the entry to ``NULL`` using xa_store(). +There is no difference between an entry that has never been stored to +and one that has been erased with xa_erase(); an entry that has most +recently had ``NULL`` stored to it is also equivalent except if the +XArray was initialized with ``XA_FLAGS_ALLOC``. You can conditionally replace an entry at an index by using xa_cmpxchg(). Like cmpxchg(), it will only succeed if diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst index 3c0ac08b2709..65c54b27a60b 100644 --- a/Documentation/dev-tools/index.rst +++ b/Documentation/dev-tools/index.rst @@ -10,6 +10,9 @@ whole; patches welcome! A brief overview of testing-specific tools can be found in Documentation/dev-tools/testing-overview.rst +Tools that are specific to debugging can be found in +Documentation/process/debugging/index.rst + .. toctree:: :caption: Table of contents :maxdepth: 2 @@ -27,8 +30,6 @@ Documentation/dev-tools/testing-overview.rst kmemleak kcsan kfence - gdb-kernel-debugging - kgdb kselftest kunit/index ktap diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index d81c42d1063e..8575178aa87f 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -203,7 +203,7 @@ they happen concurrently in different threads, and at least one of them is a least one is a write. For a more thorough discussion and definition, see `"Plain Accesses and Data Races" in the LKMM`_. -.. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt#n1922 +.. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt?id=8f6629c004b193d23612641c3607e785819e97ab#n2164 Relationship with the Linux-Kernel Memory Consistency Model (LKMM) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst index fdb1df86783a..18c2da67fae4 100644 --- a/Documentation/dev-tools/kselftest.rst +++ b/Documentation/dev-tools/kselftest.rst @@ -347,7 +347,7 @@ kselftest. We use kselftests for lib/ as an example. 1. Create the test module 2. Create the test script that will run (load/unload) the module - e.g. ``tools/testing/selftests/lib/printf.sh`` + e.g. ``tools/testing/selftests/lib/bitmap.sh`` 3. Add line to config file e.g. ``tools/testing/selftests/lib/config`` diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt deleted file mode 100644 index 82edbaaa3f85..000000000000 --- a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt +++ /dev/null @@ -1,25 +0,0 @@ -Altera SOCFPGA System Manager - -Required properties: -- compatible : "altr,sys-mgr" -- reg : Should contain 1 register ranges(address and length) -- cpu1-start-addr : CPU1 start address in hex. - -Example: - sysmgr@ffd08000 { - compatible = "altr,sys-mgr"; - reg = <0xffd08000 0x1000>; - cpu1-start-addr = <0xffd080c4>; - }; - -ARM64 - Stratix10 -Required properties: -- compatible : "altr,sys-mgr-s10" -- reg : Should contain 1 register range(address and length) - for system manager register. - -Example: - sysmgr@ffd12000 { - compatible = "altr,sys-mgr-s10"; - reg = <0xffd12000 0x228>; - }; diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml index 04a8c37b4aff..742dc4e25d3b 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml @@ -38,6 +38,12 @@ properties: enum: - arm,coresight-dummy-source + arm,static-trace-id: + description: If dummy source needs static id support, use this to set trace id. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 111 + out-ports: $ref: /schemas/graph.yaml#/properties/ports diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml index 1892a091ac35..a6f793ea03b6 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml @@ -45,7 +45,22 @@ properties: patternProperties: '^port@[01]$': description: Output connections to CoreSight Trace bus - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + + properties: + endpoint: + $ref: /schemas/graph.yaml#/$defs/endpoint-base + unevaluatedProperties: false + + properties: + filter-source: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to the coresight trace source device matching the + hard coded filtering for this port + + remote-endpoint: true required: - compatible @@ -72,6 +87,7 @@ examples: reg = <0>; replicator_out_port0: endpoint { remote-endpoint = <&etb_in_port>; + filter-source = <&tpdm_video>; }; }; @@ -79,6 +95,7 @@ examples: reg = <1>; replicator_out_port1: endpoint { remote-endpoint = <&tpiu_in_port>; + filter-source = <&tpdm_mdss>; }; }; }; diff --git a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml index f725e6940993..9c2c9ac9705a 100644 --- a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml +++ b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml @@ -23,7 +23,7 @@ description: | properties: $nodename: - pattern: "^ete([0-9a-f]+)$" + pattern: "^ete(-[0-9]+)?$" compatible: items: - const: arm,embedded-trace-extension @@ -55,13 +55,13 @@ examples: # An ETE node without legacy CoreSight connections - | - ete0 { + ete-0 { compatible = "arm,embedded-trace-extension"; cpu = <&cpu_0>; }; # An ETE node with legacy CoreSight connections - | - ete1 { + ete-1 { compatible = "arm,embedded-trace-extension"; cpu = <&cpu_1>; diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml index 2f92b8ab08fa..01333ac111fb 100644 --- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml @@ -74,6 +74,7 @@ properties: - description: AST2600 based boards items: - enum: + - ampere,mtjefferson-bmc - ampere,mtmitchell-bmc - aspeed,ast2600-evb - aspeed,ast2600-evb-a1 @@ -91,6 +92,7 @@ properties: - ibm,everest-bmc - ibm,fuji-bmc - ibm,rainier-bmc + - ibm,sbp1-bmc - ibm,system1-bmc - ibm,tacoma-bmc - inventec,starscream-bmc diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml index 7160ec80ac1b..0ec29366e6c2 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml @@ -180,6 +180,13 @@ properties: - const: atmel,sama5d4 - const: atmel,sama5 + - description: Microchip SAMA7D65 Curiosity Board + items: + - const: microchip,sama7d65-curiosity + - const: microchip,sama7d65 + - const: microchip,sama7d6 + - const: microchip,sama7 + - items: - const: microchip,sama7g5ek # SAMA7G5 Evaluation Kit - const: microchip,sama7g5 diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index 76e2b7978250..1a173e92bb13 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -13,6 +13,7 @@ PIT Timer required properties: PIT64B Timer required properties: - compatible: Should be "microchip,sam9x60-pit64b" or "microchip,sam9x7-pit64b", "microchip,sam9x60-pit64b" + "microchip,sama7d65-pit64b", "microchip,sam9x60-pit64b" - reg: Should contain registers location and length - interrupts: Should contain interrupt for PIT64B timer - clocks: Should contain the available clock sources for PIT64B timer. @@ -27,12 +28,13 @@ Its subnodes can be: - watchdog: compatible should be "atmel,at91rm9200-wdt" RAMC SDRAM/DDR Controller required properties: -- compatible: Should be "atmel,at91rm9200-sdramc", "syscon" - "atmel,at91sam9260-sdramc", - "atmel,at91sam9g45-ddramc", - "atmel,sama5d3-ddramc", - "microchip,sam9x60-ddramc", - "microchip,sama7g5-uddrc", +- compatible: Should be "atmel,at91rm9200-sdramc", "syscon" or + "atmel,at91sam9260-sdramc" or + "atmel,at91sam9g45-ddramc" or + "atmel,sama5d3-ddramc" or + "microchip,sam9x60-ddramc" or + "microchip,sama7g5-uddrc" or + "microchip,sama7d65-uddrc", "microchip,sama7g5-uddrc" or "microchip,sam9x7-ddramc", "atmel,sama5d3-ddramc". - reg: Should contain registers location and length diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml index 07892cbdd23c..354bb1420cdd 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml @@ -34,6 +34,7 @@ properties: - enum: - netgear,r8000p - tplink,archer-c2300-v1 + - zyxel,ex3510b - const: brcm,bcm4906 - const: brcm,bcm4908 - const: brcm,bcmbca @@ -115,6 +116,7 @@ properties: items: - enum: - brcm,bcm96846 + - genexis,xg6846b - const: brcm,bcm6846 - const: brcm,bcmbca diff --git a/Documentation/devicetree/bindings/arm/blaize.yaml b/Documentation/devicetree/bindings/arm/blaize.yaml new file mode 100644 index 000000000000..af39e2756407 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/blaize.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/blaize.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Blaize Platforms + +maintainers: + - James Cowgill <james.cowgill@blaize.com> + - Matt Redfearn <matt.redfearn@blaize.com> + - Neil Jones <neil.jones@blaize.com> + - Nikolaos Pasaloukos <nikolaos.pasaloukos@blaize.com> + +description: | + Blaize Platforms using SoCs designed by Blaize Inc. + + The products based on the BLZP1600 SoC: + + - BLZP1600-SoM: SoM (System on Module) + - BLZP1600-CB2: Development board CB2 based on BLZP1600-SoM + + BLZP1600 SoC integrates a dual core ARM Cortex A53 cluster + and a Blaize Graph Streaming Processor for AI and ML workloads, + plus a suite of connectivity and other peripherals. + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: Blaize BLZP1600 based boards + items: + - enum: + - blaize,blzp1600-cb2 + - const: blaize,blzp1600 + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 6e0dcf4307f1..0db2cbd7891f 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -1091,6 +1091,7 @@ properties: - dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC - emcraft,imx8mp-navqp # i.MX8MP Emcraft Systems NavQ+ Kit - fsl,imx8mp-evk # i.MX8MP EVK Board + - fsl,imx8mp-evk-revb4 # i.MX8MP EVK Rev B4 Board - gateworks,imx8mp-gw71xx-2x # i.MX8MP Gateworks Board - gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board - gateworks,imx8mp-gw73xx-2x # i.MX8MP Gateworks Board @@ -1106,6 +1107,15 @@ properties: - ysoft,imx8mp-iota2-lumpy # Y Soft i.MX8MP IOTA2 Lumpy Board - const: fsl,imx8mp + - description: ABB Boards with i.MX8M Plus Modules from ADLink + items: + - enum: + - abb,imx8mp-aristanetos3-adpismarc # i.MX8MP ABB SoM on PI SMARC Board + - abb,imx8mp-aristanetos3-helios # i.MX8MP ABB SoM on helios Board + - abb,imx8mp-aristanetos3-proton2s # i.MX8MP ABB SoM on proton2s Board + - const: abb,imx8mp-aristanetos3-som # i.MX8MP ABB SoM + - const: fsl,imx8mp + - description: Avnet (MSC Branded) Boards with SM2S i.MX8M Plus Modules items: - const: avnet,sm2s-imx8mp-14N0600E-ep1 # SM2S-IMX8PLUS-14N0600E on SM2-MB-EP1 Carrier Board @@ -1262,6 +1272,7 @@ properties: items: - enum: - fsl,imx8qm-mek # i.MX8QM MEK Board + - fsl,imx8qm-mek-revd # i.MX8QM MEK Rev D Board - toradex,apalis-imx8 # Apalis iMX8 Modules - toradex,apalis-imx8-v1.1 # Apalis iMX8 V1.1 Modules - const: fsl,imx8qm @@ -1290,6 +1301,7 @@ properties: - enum: - einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board - fsl,imx8qxp-mek # i.MX8QXP MEK Board + - fsl,imx8qxp-mek-wcpu # i.MX8QXP MEK WCPU Board - const: fsl,imx8qxp - description: i.MX8DXL based Boards diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 1d4bb50fcd8d..3ce34d68c213 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -239,6 +239,34 @@ properties: - enum: - mediatek,mt8183-pumpkin - const: mediatek,mt8183 + - description: Google Chinchou (Asus Chromebook CZ1104CM2A/CZ1204CM2A) + items: + - const: google,chinchou-sku0 + - const: google,chinchou-sku2 + - const: google,chinchou-sku4 + - const: google,chinchou-sku5 + - const: google,chinchou + - const: mediatek,mt8186 + - description: Google Chinchou (Asus Chromebook CZ1104FM2A/CZ1204FM2A/CZ1104CM2A/CZ1204CM2A) + items: + - const: google,chinchou-sku1 + - const: google,chinchou-sku3 + - const: google,chinchou-sku6 + - const: google,chinchou-sku7 + - const: google,chinchou-sku17 + - const: google,chinchou-sku20 + - const: google,chinchou-sku22 + - const: google,chinchou-sku23 + - const: google,chinchou + - const: mediatek,mt8186 + - description: Google Chinchou360 (Asus Chromebook CZ1104FM2A/CZ1204FM2A Flip) + items: + - const: google,chinchou-sku16 + - const: google,chinchou-sku18 + - const: google,chinchou-sku19 + - const: google,chinchou-sku21 + - const: google,chinchou + - const: mediatek,mt8186 - description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868)) items: - const: google,steelix-sku393219 @@ -263,6 +291,19 @@ properties: - const: google,steelix-sku196608 - const: google,steelix - const: mediatek,mt8186 + - description: Google Starmie (ASUS Chromebook Enterprise CM30 (CM3001)) + items: + - const: google,starmie-sku0 + - const: google,starmie-sku2 + - const: google,starmie-sku3 + - const: google,starmie + - const: mediatek,mt8186 + - description: Google Starmie (ASUS Chromebook Enterprise CM30 (CM3001)) + items: + - const: google,starmie-sku1 + - const: google,starmie-sku4 + - const: google,starmie + - const: mediatek,mt8186 - description: Google Steelix (Lenovo 300e Yoga Chromebook Gen 4) items: - enum: @@ -307,6 +348,19 @@ properties: - enum: - mediatek,mt8186-evb - const: mediatek,mt8186 + - description: Google Ciri (Lenovo Chromebook Duet (11", 9)) + items: + - enum: + - google,ciri-sku0 + - google,ciri-sku1 + - google,ciri-sku2 + - google,ciri-sku3 + - google,ciri-sku4 + - google,ciri-sku5 + - google,ciri-sku6 + - google,ciri-sku7 + - const: google,ciri + - const: mediatek,mt8188 - items: - enum: - mediatek,mt8188-evb @@ -316,12 +370,6 @@ properties: - const: google,hayato-rev1 - const: google,hayato - const: mediatek,mt8192 - - description: Google Hayato rev5 - items: - - const: google,hayato-rev5-sku2 - - const: google,hayato-sku2 - - const: google,hayato - - const: mediatek,mt8192 - description: Google Spherion (Acer Chromebook 514) items: - const: google,spherion-rev3 @@ -330,11 +378,6 @@ properties: - const: google,spherion-rev0 - const: google,spherion - const: mediatek,mt8192 - - description: Google Spherion rev4 (Acer Chromebook 514) - items: - - const: google,spherion-rev4 - - const: google,spherion - - const: mediatek,mt8192 - items: - enum: - mediatek,mt8192-evb diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml index d0751a572af3..a77d68dcad4e 100644 --- a/Documentation/devicetree/bindings/arm/qcom-soc.yaml +++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml @@ -23,7 +23,7 @@ description: | select: properties: compatible: - pattern: "^qcom,.*(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm|x1e)[0-9]+.*$" + pattern: "^qcom,.*(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sar|sc|sd[amx]|sm|x1[ep])[0-9]+.*$" required: - compatible @@ -31,7 +31,8 @@ properties: compatible: oneOf: # Preferred naming style for compatibles of SoC components: - - pattern: "^qcom,(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm|x1e)[0-9]+(pro)?-.*$" + - pattern: "^qcom,(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm|x1[ep])[0-9]+(pro)?-.*$" + - pattern: "^qcom,sar[0-9]+[a-z]?-.*$" - pattern: "^qcom,(sa|sc)8[0-9]+[a-z][a-z]?-.*$" # Legacy namings - variations of existing patterns/compatibles are OK, @@ -39,9 +40,9 @@ properties: - pattern: "^qcom,[ak]pss-wdt-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm)[0-9]+.*$" - pattern: "^qcom,gcc-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm)[0-9]+.*$" - pattern: "^qcom,mmcc-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm)[0-9]+.*$" - - pattern: "^qcom,pcie-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm|x1e)[0-9]+.*$" + - pattern: "^qcom,pcie-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm|x1[ep])[0-9]+.*$" - pattern: "^qcom,rpm-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm)[0-9]+.*$" - - pattern: "^qcom,scm-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm|x1e)[0-9]+.*$" + - pattern: "^qcom,scm-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm|x1[ep])[0-9]+.*$" - enum: - qcom,dsi-ctrl-6g-qcm2290 - qcom,gpucc-sdm630 diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 9679fed7259b..618a87693ac1 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -19,29 +19,42 @@ description: | apq8016 apq8026 + apq8064 apq8074 apq8084 + apq8094 apq8096 ipq4018 + ipq4019 ipq5018 ipq5332 + ipq5424 ipq6018 + ipq8064 ipq8074 ipq9574 mdm9615 msm8226 + msm8660 msm8916 + msm8917 + msm8926 + msm8929 msm8939 msm8953 msm8956 msm8960 msm8974 + msm8974pro msm8976 msm8992 msm8994 msm8996 + msm8996pro msm8998 qcs404 + qcs615 + qcs8300 qcs8550 qcm2290 qcm6490 @@ -53,6 +66,7 @@ description: | sa8155p sa8540p sa8775p + sar2130p sc7180 sc7280 sc8180x @@ -84,7 +98,10 @@ description: | sm8450 sm8550 sm8650 + sm8750 + x1e78100 x1e80100 + x1p42100 There are many devices in the list below that run the standard ChromeOS bootloader setup and use the open source depthcharge bootloader to boot the @@ -252,6 +269,11 @@ properties: - items: - enum: + - xiaomi,riva + - const: qcom,msm8917 + + - items: + - enum: - motorola,potter - xiaomi,daisy - xiaomi,mido @@ -354,6 +376,11 @@ properties: - items: - enum: + - qcom,ipq5424-rdp466 + - const: qcom,ipq5424 + + - items: + - enum: - mikrotik,rb3011 - qcom,ipq8064-ap148 - const: qcom,ipq8064 @@ -408,6 +435,12 @@ properties: - qcom,qru1000-idp - const: qcom,qru1000 + - description: Qualcomm AR2 Gen1 platform + items: + - enum: + - qcom,qar2130p + - const: qcom,sar2130p + - items: - enum: - acer,aspire1 @@ -822,8 +855,10 @@ properties: - items: - enum: + - huawei,gaokun3 - lenovo,thinkpad-x13s - microsoft,arcata + - microsoft,blackrock - qcom,sc8280xp-crd - qcom,sc8280xp-qrd - const: qcom,sc8280xp @@ -900,6 +935,16 @@ properties: - items: - enum: + - qcom,qcs8300-ride + - const: qcom,qcs8300 + + - items: + - enum: + - qcom,qcs615-ride + - const: qcom,qcs615 + + - items: + - enum: - qcom,sa8155p-adp - const: qcom,sa8155p @@ -1066,6 +1111,18 @@ properties: - items: - enum: + - qcom,sm8750-mtp + - qcom,sm8750-qrd + - const: qcom,sm8750 + + - items: + - enum: + - qcom,x1e001de-devkit + - const: qcom,x1e001de + - const: qcom,x1e80100 + + - items: + - enum: - lenovo,thinkpad-t14s - const: qcom,x1e78100 - const: qcom,x1e80100 @@ -1074,6 +1131,7 @@ properties: - enum: - asus,vivobook-s15 - dell,xps13-9345 + - hp,omnibook-x14 - lenovo,yoga-slim7x - microsoft,romulus13 - microsoft,romulus15 @@ -1081,6 +1139,11 @@ properties: - qcom,x1e80100-qcp - const: qcom,x1e80100 + - items: + - enum: + - qcom,x1p42100-crd + - const: qcom,x1p42100 + # Board compatibles go above qcom,msm-id: @@ -1158,6 +1221,7 @@ allOf: - qcom,apq8026 - qcom,apq8094 - qcom,apq8096 + - qcom,msm8917 - qcom,msm8939 - qcom,msm8953 - qcom,msm8956 diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 753199a12923..522a6f0450ea 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -81,6 +81,17 @@ properties: - const: azw,beelink-a1 - const: rockchip,rk3328 + - description: BigTreeTech CB2 Manta M4/8P + items: + - const: bigtreetech,cb2-manta + - const: bigtreetech,cb2 + - const: rockchip,rk3566 + + - description: BigTreeTech Pi 2 + items: + - const: bigtreetech,pi2 + - const: rockchip,rk3566 + - description: bq Curie 2 tablet items: - const: mundoreader,bq-curie2 @@ -167,6 +178,13 @@ properties: - const: engicam,px30-core - const: rockchip,px30 + - description: Firefly Core-3588J-based boards + items: + - enum: + - firefly,itx-3588j + - const: firefly,core-3588j + - const: rockchip,rk3588 + - description: Firefly Core-PX30-JD4 on MB-JD4-PX30 baseboard items: - const: firefly,px30-jd4-core-mb @@ -597,6 +615,11 @@ properties: - const: google,veyron - const: rockchip,rk3288 + - description: H96 Max V58 TV Box + items: + - const: haochuangyi,h96-max-v58 + - const: rockchip,rk3588 + - description: Haoyu MarsBoard RK3066 items: - const: haoyu,marsboard-rk3066 @@ -812,6 +835,12 @@ properties: - const: radxa,e20c - const: rockchip,rk3528 + - description: Radxa E52C + items: + - const: radxa,e52c + - const: rockchip,rk3582 + - const: rockchip,rk3588s + - description: Radxa Rock items: - const: radxa,rock @@ -1006,6 +1035,21 @@ properties: - const: rockchip,rk3399-sapphire-excavator - const: rockchip,rk3399 + - description: Rockchip RK3566 BOX Evaluation Demo board + items: + - const: rockchip,rk3566-box-demo + - const: rockchip,rk3566 + + - description: Rockchip RK3568 Evaluation board + items: + - const: rockchip,rk3568-evb1-v10 + - const: rockchip,rk3568 + + - description: Rockchip RK3576 Evaluation board + items: + - const: rockchip,rk3576-evb1-v10 + - const: rockchip,rk3576 + - description: Rockchip RK3588 Evaluation board items: - const: rockchip,rk3588-evb1-v10 @@ -1026,6 +1070,23 @@ properties: - const: rockchip,rk3588-toybrick-x0 - const: rockchip,rk3588 + - description: Sinovoip RK3308 Banana Pi P2 Pro + items: + - const: sinovoip,rk3308-bpi-p2pro + - const: rockchip,rk3308 + + - description: Sinovoip RK3568 Banana Pi R2 Pro + items: + - const: sinovoip,rk3568-bpi-r2pro + - const: rockchip,rk3568 + + - description: Sonoff iHost Smart Home Hub + items: + - const: itead,sonoff-ihost + - enum: + - rockchip,rv1126 + - rockchip,rv1109 + - description: Theobroma Systems PX30-uQ7 with Haikou baseboard items: - const: tsd,px30-ringneck-haikou @@ -1075,9 +1136,11 @@ properties: - const: xunlong,orangepi-3b - const: rockchip,rk3566 - - description: Xunlong Orange Pi 5 Plus + - description: Xunlong Orange Pi 5 Max/Plus items: - - const: xunlong,orangepi-5-plus + - enum: + - xunlong,orangepi-5-max + - xunlong,orangepi-5-plus - const: rockchip,rk3588 - description: Xunlong Orange Pi R1 Plus / LTS @@ -1099,33 +1162,6 @@ properties: - const: zkmagic,a95x-z2 - const: rockchip,rk3318 - - description: Rockchip RK3566 BOX Evaluation Demo board - items: - - const: rockchip,rk3566-box-demo - - const: rockchip,rk3566 - - - description: Rockchip RK3568 Evaluation board - items: - - const: rockchip,rk3568-evb1-v10 - - const: rockchip,rk3568 - - - description: Sinovoip RK3308 Banana Pi P2 Pro - items: - - const: sinovoip,rk3308-bpi-p2pro - - const: rockchip,rk3308 - - - description: Sinovoip RK3568 Banana Pi R2 Pro - items: - - const: sinovoip,rk3568-bpi-r2pro - - const: rockchip,rk3568 - - - description: Sonoff iHost Smart Home Hub - items: - - const: itead,sonoff-ihost - - enum: - - rockchip,rv1126 - - rockchip,rv1109 - additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml index 932f981265cc..52016a141227 100644 --- a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml @@ -53,11 +53,17 @@ properties: reg: maxItems: 1 + power-controller: + type: object + + reboot-mode: + type: object + required: - compatible - reg -additionalProperties: true +additionalProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml index b5ba5ffc36d6..fab29f95d8e6 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml @@ -240,6 +240,9 @@ properties: items: - enum: - samsung,c1s # Samsung Galaxy Note20 5G (SM-N981B) + - samsung,r8s # Samsung Galaxy S20 FE (SM-G780F) + - samsung,x1s # Samsung Galaxy S20 5G (SM-G981B) + - samsung,x1slte # Samsung Galaxy S20 (SM-G980F) - const: samsung,exynos990 - description: Exynos Auto v9 based boards diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 703d4b574398..b6c56d4ce6b9 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -91,6 +91,13 @@ properties: - const: dh,stm32mp153c-dhcor-som - const: st,stm32mp153 + - description: Octavo OSD32MP153 System-in-Package based boards + items: + - enum: + - lxa,stm32mp153c-tac-gen3 # Linux Automation TAC (Generation 3) + - const: oct,stm32mp153x-osd32 + - const: st,stm32mp153 + - items: - enum: - shiratech,stm32mp157a-iot-box # IoT Box diff --git a/Documentation/devicetree/bindings/cache/qcom,llcc.yaml b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml index 03b1941eaa33..e5effbb4a606 100644 --- a/Documentation/devicetree/bindings/cache/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml @@ -20,6 +20,7 @@ description: | properties: compatible: enum: + - qcom,ipq5424-llcc - qcom,qcs615-llcc - qcom,qcs8300-llcc - qcom,qdu1000-llcc @@ -42,11 +43,11 @@ properties: - qcom,x1e80100-llcc reg: - minItems: 2 + minItems: 1 maxItems: 10 reg-names: - minItems: 2 + minItems: 1 maxItems: 10 interrupts: @@ -71,6 +72,21 @@ allOf: compatible: contains: enum: + - qcom,ipq5424-llcc + then: + properties: + reg: + items: + - description: LLCC0 base register region + reg-names: + items: + - const: llcc0_base + + - if: + properties: + compatible: + contains: + enum: - qcom,sar1130p-llcc - qcom,sar2130p-llcc then: diff --git a/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml b/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml deleted file mode 100644 index c94ab8f9e0b8..000000000000 --- a/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml +++ /dev/null @@ -1,36 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/chrome/google,cros-kbd-led-backlight.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: ChromeOS keyboard backlight LED driver. - -maintainers: - - Tzung-Bi Shih <tzungbi@kernel.org> - -properties: - compatible: - const: google,cros-kbd-led-backlight - -required: - - compatible - -additionalProperties: false - -examples: - - | - spi { - #address-cells = <1>; - #size-cells = <0>; - - cros_ec: ec@0 { - compatible = "google,cros-ec-spi"; - reg = <0>; - interrupts = <15 0>; - - kbd-led-backlight { - compatible = "google,cros-kbd-led-backlight"; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml b/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml index c9eb60776b4d..885d47dd5724 100644 --- a/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml +++ b/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml @@ -43,6 +43,7 @@ properties: - atmel,sama5d4-pmc - microchip,sam9x60-pmc - microchip,sam9x7-pmc + - microchip,sama7d65-pmc - microchip,sama7g5-pmc - const: syscon @@ -90,6 +91,7 @@ allOf: enum: - microchip,sam9x60-pmc - microchip,sam9x7-pmc + - microchip,sama7d65-pmc - microchip,sama7g5-pmc then: properties: diff --git a/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml b/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml index c2283cd07f05..d4cf8ae2961e 100644 --- a/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml +++ b/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml @@ -20,6 +20,7 @@ properties: - items: - enum: - microchip,sam9x7-sckc + - microchip,sama7d65-sckc - microchip,sama7g5-sckc - const: microchip,sam9x60-sckc diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml index 0858fd635282..4cdff6161bf0 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml @@ -8,6 +8,7 @@ title: Qualcomm Graphics Clock & Reset Controller maintainers: - Taniya Das <quic_tdas@quicinc.com> + - Imran Shaik <quic_imrashai@quicinc.com> description: | Qualcomm graphics clock control module provides the clocks, resets and power @@ -23,10 +24,12 @@ description: | include/dt-bindings/clock/qcom,gpucc-sm8150.h include/dt-bindings/clock/qcom,gpucc-sm8250.h include/dt-bindings/clock/qcom,gpucc-sm8350.h + include/dt-bindings/clock/qcom,qcs8300-gpucc.h properties: compatible: enum: + - qcom,qcs8300-gpucc - qcom,sdm845-gpucc - qcom,sa8775p-gpucc - qcom,sc7180-gpucc diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml new file mode 100644 index 000000000000..f869b3739be8 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,ipq9574-cmn-pll.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm CMN PLL Clock Controller on IPQ SoC + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + - Luo Jie <quic_luoj@quicinc.com> + +description: + The CMN (or common) PLL clock controller expects a reference + input clock. This reference clock is from the on-board Wi-Fi. + The CMN PLL supplies a number of fixed rate output clocks to + the devices providing networking functions and to GCC. These + networking hardware include PPE (packet process engine), PCS + and the externally connected switch or PHY devices. The CMN + PLL block also outputs fixed rate clocks to GCC. The PLL's + primary function is to enable fixed rate output clocks for + networking hardware functions used with the IPQ SoC. + +properties: + compatible: + enum: + - qcom,ipq9574-cmn-pll + + reg: + maxItems: 1 + + clocks: + items: + - description: The reference clock. The supported clock rates include + 25000000, 31250000, 40000000, 48000000, 50000000 and 96000000 HZ. + - description: The AHB clock + - description: The SYS clock + description: + The reference clock is the source clock of CMN PLL, which is from the + Wi-Fi. The AHB and SYS clocks must be enabled to access CMN PLL + clock registers. + + clock-names: + items: + - const: ref + - const: ahb + - const: sys + + "#clock-cells": + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - "#clock-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,ipq-cmn-pll.h> + #include <dt-bindings/clock/qcom,ipq9574-gcc.h> + + cmn_pll: clock-controller@9b000 { + compatible = "qcom,ipq9574-cmn-pll"; + reg = <0x0009b000 0x800>; + clocks = <&cmn_pll_ref_clk>, + <&gcc GCC_CMN_12GPLL_AHB_CLK>, + <&gcc GCC_CMN_12GPLL_SYS_CLK>; + clock-names = "ref", "ahb", "sys"; + #clock-cells = <1>; + assigned-clocks = <&cmn_pll CMN_PLL_CLK>; + assigned-clock-rates-u64 = /bits/ 64 <12000000000>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml index aa35a40648ba..59ac288ca5f1 100644 --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml @@ -78,6 +78,7 @@ allOf: then: properties: clocks: + minItems: 8 items: - description: Board PXO source - description: PLL 3 clock @@ -87,8 +88,10 @@ allOf: - description: DSI phy instance 2 dsi clock - description: DSI phy instance 2 byte clock - description: HDMI phy PLL clock + - description: LVDS PLL clock clock-names: + minItems: 8 items: - const: pxo - const: pll3 @@ -98,6 +101,7 @@ allOf: - const: dsi2pll - const: dsi2pllbyte - const: hdmipll + - const: lvdspll - if: properties: diff --git a/Documentation/devicetree/bindings/clock/qcom,qcs615-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcs615-gcc.yaml new file mode 100644 index 000000000000..4a828e102d25 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,qcs615-gcc.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,qcs615-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on QCS615 + +maintainers: + - Taniya Das <quic_tdas@quicinc.com> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on QCS615. + + See also: include/dt-bindings/clock/qcom,qcs615-gcc.h + +properties: + compatible: + const: qcom,qcs615-gcc + + clocks: + items: + - description: Board XO source + - description: Board active XO source + - description: Sleep clock source + + clock-names: + items: + - const: bi_tcxo + - const: bi_tcxo_ao + - const: sleep_clk + +required: + - compatible + - clocks + - clock-names + - '#power-domain-cells' + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@100000 { + compatible = "qcom,qcs615-gcc"; + reg = <0x00100000 0x1f0000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&rpmhcc RPMH_CXO_CLK_A>, + <&sleep_clk>; + clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml index 02fcffe93f1a..be3835e2e043 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml @@ -33,6 +33,8 @@ properties: - qcom,rpmcc-msm8916 - qcom,rpmcc-msm8917 - qcom,rpmcc-msm8936 + - qcom,rpmcc-msm8937 + - qcom,rpmcc-msm8940 - qcom,rpmcc-msm8953 - qcom,rpmcc-msm8974 - qcom,rpmcc-msm8976 @@ -110,6 +112,8 @@ allOf: - qcom,rpmcc-msm8916 - qcom,rpmcc-msm8917 - qcom,rpmcc-msm8936 + - qcom,rpmcc-msm8937 + - qcom,rpmcc-msm8940 - qcom,rpmcc-msm8953 - qcom,rpmcc-msm8974 - qcom,rpmcc-msm8976 diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml index a561a306b947..dcb872b9cf3e 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml @@ -17,6 +17,7 @@ description: | properties: compatible: enum: + - qcom,qcs615-rpmh-clk - qcom,qdu1000-rpmh-clk - qcom,sa8775p-rpmh-clk - qcom,sar2130p-rpmh-clk @@ -37,6 +38,7 @@ properties: - qcom,sm8450-rpmh-clk - qcom,sm8550-rpmh-clk - qcom,sm8650-rpmh-clk + - qcom,sm8750-rpmh-clk - qcom,x1e80100-rpmh-clk clocks: diff --git a/Documentation/devicetree/bindings/clock/qcom,sa8775p-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sa8775p-camcc.yaml index 36a60d8f5ae3..81623f59d11d 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sa8775p-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sa8775p-camcc.yaml @@ -8,16 +8,20 @@ title: Qualcomm Camera Clock & Reset Controller on SA8775P maintainers: - Taniya Das <quic_tdas@quicinc.com> + - Imran Shaik <quic_imrashai@quicinc.com> description: | Qualcomm camera clock control module provides the clocks, resets and power domains on SA8775p. - See also: include/dt-bindings/clock/qcom,sa8775p-camcc.h + See also: + include/dt-bindings/clock/qcom,qcs8300-camcc.h + include/dt-bindings/clock/qcom,sa8775p-camcc.h properties: compatible: enum: + - qcom,qcs8300-camcc - qcom,sa8775p-camcc clocks: diff --git a/Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml index 928131bff4c1..07e5d811d816 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml @@ -18,6 +18,7 @@ description: | properties: compatible: enum: + - qcom,qcs8300-videocc - qcom,sa8775p-videocc clocks: diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml index deee5423d66e..488d63959424 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml @@ -18,12 +18,6 @@ description: | include/dt-bindings/clock/qcom,lpassaudiocc-sc7280.h properties: - clocks: true - - clock-names: true - - reg: true - compatible: enum: - qcom,sc7280-lpassaoncc @@ -31,12 +25,24 @@ properties: - qcom,sc7280-lpasscorecc - qcom,sc7280-lpasshm - power-domains: - maxItems: 1 + reg: + minItems: 1 + maxItems: 2 + + clocks: + minItems: 1 + maxItems: 3 + + clock-names: + minItems: 1 + maxItems: 3 '#clock-cells': const: 1 + power-domains: + maxItems: 1 + '#power-domain-cells': const: 1 @@ -57,8 +63,6 @@ required: - '#clock-cells' - '#power-domain-cells' -additionalProperties: false - allOf: - if: properties: @@ -125,6 +129,9 @@ allOf: reg: maxItems: 1 + +additionalProperties: false + examples: - | #include <dt-bindings/clock/qcom,rpmh.h> diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml index 810b852ae371..fa95c3a1ba3a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml @@ -20,7 +20,11 @@ allOf: properties: compatible: - const: qcom,sdm845-camcc + oneOf: + - items: + - const: qcom,sdm670-camcc + - const: qcom,sdm845-camcc + - const: qcom,sdm845-camcc clocks: items: diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml new file mode 100644 index 000000000000..8cbab3fbb660 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sm6115-lpasscc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm LPASS Core & Audio Clock Controller on SM6115 + +maintainers: + - Konrad Dybcio <konradybcio@kernel.org> + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + Qualcomm LPASS core and audio clock controllers provide audio-related resets + on SM6115 and its derivatives. + + See also:: + include/dt-bindings/clock/qcom,sm6115-lpasscc.h + +properties: + compatible: + enum: + - qcom,sm6115-lpassaudiocc + - qcom,sm6115-lpasscc + + reg: + maxItems: 1 + + '#reset-cells': + const: 1 + +required: + - compatible + - reg + - '#reset-cells' + +additionalProperties: false + +examples: + - | + lpass_audiocc: clock-controller@a6a9000 { + compatible = "qcom,sm6115-lpassaudiocc"; + reg = <0x0a6a9000 0x1000>; + #reset-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml index 0766f66c7dc4..b88b6c9b399a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml @@ -19,7 +19,6 @@ description: | include/dt-bindings/clock/qcom,sm8450-camcc.h include/dt-bindings/clock/qcom,sm8550-camcc.h include/dt-bindings/clock/qcom,sm8650-camcc.h - include/dt-bindings/clock/qcom,x1e80100-camcc.h properties: compatible: @@ -29,7 +28,6 @@ properties: - qcom,sm8475-camcc - qcom,sm8550-camcc - qcom,sm8650-camcc - - qcom,x1e80100-camcc clocks: items: diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml index 5c65f5ecf0f3..02968632fb3a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml @@ -32,6 +32,7 @@ properties: - qcom,sm8550-gpucc - qcom,sm8650-gpucc - qcom,x1e80100-gpucc + - qcom,x1p42100-gpucc clocks: items: diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml index c57d55a9293c..30e4b4631575 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml @@ -12,11 +12,12 @@ maintainers: description: | Qualcomm display clock control module provides the clocks, resets and power - domains on SM8550. + domains on SM8550, SM8650, SM8750 and few other platforms. See also: - include/dt-bindings/clock/qcom,sm8550-dispcc.h - include/dt-bindings/clock/qcom,sm8650-dispcc.h + - include/dt-bindings/clock/qcom,sm8750-dispcc.h - include/dt-bindings/clock/qcom,x1e80100-dispcc.h properties: @@ -25,6 +26,7 @@ properties: - qcom,sar2130p-dispcc - qcom,sm8550-dispcc - qcom,sm8650-dispcc + - qcom,sm8750-dispcc - qcom,x1e80100-dispcc clocks: diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml index 3b546deb514a..f3afbb25e868 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml @@ -16,6 +16,7 @@ description: | See also: - include/dt-bindings/clock/qcom,sm8550-tcsr.h - include/dt-bindings/clock/qcom,sm8650-tcsr.h + - include/dt-bindings/clock/qcom,sm8750-tcsr.h properties: compatible: @@ -24,6 +25,7 @@ properties: - qcom,sar2130p-tcsr - qcom,sm8550-tcsr - qcom,sm8650-tcsr + - qcom,sm8750-tcsr - qcom,x1e80100-tcsr - const: syscon diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8750-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8750-gcc.yaml new file mode 100644 index 000000000000..aab7039fd28d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm8750-gcc.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sm8750-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on SM8750 + +maintainers: + - Taniya Das <quic_tdas@quicinc.com> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on SM8750 + + See also: include/dt-bindings/clock/qcom,sm8750-gcc.h + +properties: + compatible: + const: qcom,sm8750-gcc + + clocks: + items: + - description: Board XO source + - description: Board Always On XO source + - description: Sleep clock source + - description: PCIE 0 Pipe clock source + - description: UFS Phy Rx symbol 0 clock source + - description: UFS Phy Rx symbol 1 clock source + - description: UFS Phy Tx symbol 0 clock source + - description: USB3 Phy wrapper pipe clock source + +required: + - compatible + - clocks + - '#power-domain-cells' + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@100000 { + compatible = "qcom,sm8750-gcc"; + reg = <0x00100000 0x001f4200>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&rpmhcc RPMH_CXO_CLK_A>, + <&sleep_clk>, + <&pcie0_phy>, + <&ufs_mem_phy 0>, + <&ufs_mem_phy 1>, + <&ufs_mem_phy 2>, + <&usb_1_qmpphy>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml new file mode 100644 index 000000000000..5bbbaa15a260 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,x1e80100-camcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Camera Clock & Reset Controller on x1e80100 + +maintainers: + - Bryan O'Donoghue <bryan.odonoghue@linaro.org> + +description: | + Qualcomm camera clock control module provides the clocks, resets and power + domains on x1e80100. + + See also: + include/dt-bindings/clock/qcom,x1e80100-camcc.h + +allOf: + - $ref: qcom,gcc.yaml# + +properties: + compatible: + enum: + - qcom,x1e80100-camcc + + reg: + maxItems: 1 + + clocks: + items: + - description: Camera AHB clock from GCC + - description: Board XO source + - description: Board active XO source + - description: Sleep clock source + + power-domains: + items: + - description: A phandle to the MXC power-domain + - description: A phandle to the MMCX power-domain + + required-opps: + maxItems: 1 + description: + A phandle to an OPP node describing MMCX performance points. + +required: + - compatible + - clocks + - power-domains + - required-opps + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,x1e80100-gcc.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/power/qcom,rpmhpd.h> + clock-controller@ade0000 { + compatible = "qcom,x1e80100-camcc"; + reg = <0xade0000 0x20000>; + clocks = <&gcc GCC_CAMERA_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>, + <&rpmhcc RPMH_CXO_CLK_A>, + <&sleep_clk>; + power-domains = <&rpmhpd RPMHPD_MXC>, + <&rpmhpd RPMHPD_MMCX>; + required-opps = <&rpmhpd_opp_low_svs>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,x1e80100-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,x1e80100-gcc.yaml index 5951a60ab081..28797d0c5d8d 100644 --- a/Documentation/devicetree/bindings/clock/qcom,x1e80100-gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,x1e80100-gcc.yaml @@ -17,7 +17,11 @@ description: | properties: compatible: - const: qcom,x1e80100-gcc + oneOf: + - items: + - const: qcom,x1p42100-gcc + - const: qcom,x1e80100-gcc + - const: qcom,x1e80100-gcc clocks: items: diff --git a/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml b/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml index 42b6f80613f3..162d38035188 100644 --- a/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml @@ -31,6 +31,7 @@ description: | properties: compatible: enum: + - renesas,5l35023 - renesas,5p35023 reg: diff --git a/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml index 926c503bed1f..c3fe76abd549 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml @@ -4,19 +4,22 @@ $id: http://devicetree.org/schemas/clock/renesas,rzv2h-cpg.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/V2H(P) Clock Pulse Generator (CPG) +title: Renesas RZ/{G3E,V2H(P)} Clock Pulse Generator (CPG) maintainers: - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> description: - On Renesas RZ/V2H(P) SoCs, the CPG (Clock Pulse Generator) handles generation - and control of clock signals for the IP modules, generation and control of resets, - and control over booting, low power consumption and power supply domains. + On Renesas RZ/{G3E,V2H(P)} SoCs, the CPG (Clock Pulse Generator) handles + generation and control of clock signals for the IP modules, generation and + control of resets, and control over booting, low power consumption and power + supply domains. properties: compatible: - const: renesas,r9a09g057-cpg + enum: + - renesas,r9a09g047-cpg # RZ/G3E + - renesas,r9a09g057-cpg # RZ/V2H reg: maxItems: 1 @@ -37,7 +40,7 @@ properties: description: | - For CPG core clocks, the two clock specifier cells must be "CPG_CORE" and a core clock reference, as defined in - <dt-bindings/clock/renesas,r9a09g057-cpg.h>, + <dt-bindings/clock/renesas,r9a09g0*-cpg.h>, - For module clocks, the two clock specifier cells must be "CPG_MOD" and a module number. The module number is calculated as the CLKON register offset index multiplied by 16, plus the actual bit in the register diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos990-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos990-clock.yaml new file mode 100644 index 000000000000..9e7944b5f13b --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos990-clock.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/samsung,exynos990-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos990 SoC clock controller + +maintainers: + - Igor Belwon <igor.belwon@mentallysanemainliners.org> + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzk@kernel.org> + +description: | + Exynos990 clock controller is comprised of several CMU units, generating + clocks for different domains. Those CMU units are modeled as separate device + tree nodes, and might depend on each other. The root clock in that root tree + is an external clock: OSCCLK (26 MHz). This external clock must be defined + as a fixed-rate clock in dts. + + CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and + dividers; all other clocks of function blocks (other CMUs) are usually + derived from CMU_TOP. + + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All clocks available for usage + in clock consumer nodes are defined as preprocessor macros in + 'include/dt-bindings/clock/samsung,exynos990.h' header. + +properties: + compatible: + enum: + - samsung,exynos990-cmu-hsi0 + - samsung,exynos990-cmu-top + + clocks: + minItems: 1 + maxItems: 5 + + clock-names: + minItems: 1 + maxItems: 5 + + "#clock-cells": + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - "#clock-cells" + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos990-cmu-hsi0 + + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: CMU_HSI0 BUS clock (from CMU_TOP) + - description: CMU_HSI0 USB31DRD clock (from CMU_TOP) + - description: CMU_HSI0 USBDP_DEBUG clock (from CMU_TOP) + - description: CMU_HSI0 DPGTC clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: bus + - const: usb31drd + - const: usbdp_debug + - const: dpgtc + + - if: + properties: + compatible: + contains: + const: samsung,exynos990-cmu-top + + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + + clock-names: + items: + - const: oscclk + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/samsung,exynos990.h> + + cmu_hsi0: clock-controller@10a00000 { + compatible = "samsung,exynos990-cmu-hsi0"; + reg = <0x10a00000 0x8000>; + #clock-cells = <1>; + + clocks = <&oscclk>, + <&cmu_top CLK_DOUT_CMU_HSI0_BUS>, + <&cmu_top CLK_DOUT_CMU_HSI0_USB31DRD>, + <&cmu_top CLK_DOUT_CMU_HSI0_USBDP_DEBUG>, + <&cmu_top CLK_DOUT_CMU_HSI0_DPGTC>; + clock-names = "oscclk", + "bus", + "usb31drd", + "usbdp_debug", + "dpgtc"; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt deleted file mode 100644 index cfa04b614d8a..000000000000 --- a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt +++ /dev/null @@ -1,138 +0,0 @@ -STMicroelectronics STM32 Reset and Clock Controller -=================================================== - -The RCC IP is both a reset and a clock controller. - -Please refer to clock-bindings.txt for common clock controller binding usage. -Please also refer to reset.txt for common reset controller binding usage. - -Required properties: -- compatible: Should be: - "st,stm32f42xx-rcc" - "st,stm32f469-rcc" - "st,stm32f746-rcc" - "st,stm32f769-rcc" - -- reg: should be register base and length as documented in the - datasheet -- #reset-cells: 1, see below -- #clock-cells: 2, device nodes should specify the clock in their "clocks" - property, containing a phandle to the clock device node, an index selecting - between gated clocks and other clocks and an index specifying the clock to - use. -- clocks: External oscillator clock phandle - - high speed external clock signal (HSE) - - external I2S clock (I2S_CKIN) - -Example: - - rcc: rcc@40023800 { - #reset-cells = <1>; - #clock-cells = <2> - compatible = "st,stm32f42xx-rcc", "st,stm32-rcc"; - reg = <0x40023800 0x400>; - clocks = <&clk_hse>, <&clk_i2s_ckin>; - }; - -Specifying gated clocks -======================= - -The primary index must be set to 0. - -The secondary index is the bit number within the RCC register bank, starting -from the first RCC clock enable register (RCC_AHB1ENR, address offset 0x30). - -It is calculated as: index = register_offset / 4 * 32 + bit_offset. -Where bit_offset is the bit offset within the register (LSB is 0, MSB is 31). - -To simplify the usage and to share bit definition with the reset and clock -drivers of the RCC IP, macros are available to generate the index in -human-readble format. - -For STM32F4 series, the macro are available here: - - include/dt-bindings/mfd/stm32f4-rcc.h - -Example: - - /* Gated clock, AHB1 bit 0 (GPIOA) */ - ... { - clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOA)> - }; - - /* Gated clock, AHB2 bit 4 (CRYP) */ - ... { - clocks = <&rcc 0 STM32F4_AHB2_CLOCK(CRYP)> - }; - -Specifying other clocks -======================= - -The primary index must be set to 1. - -The secondary index is bound with the following magic numbers: - - 0 SYSTICK - 1 FCLK - 2 CLK_LSI (low-power clock source) - 3 CLK_LSE (generated from a 32.768 kHz low-speed external - crystal or ceramic resonator) - 4 CLK_HSE_RTC (HSE division factor for RTC clock) - 5 CLK_RTC (real-time clock) - 6 PLL_VCO_I2S (vco frequency of I2S pll) - 7 PLL_VCO_SAI (vco frequency of SAI pll) - 8 CLK_LCD (LCD-TFT) - 9 CLK_I2S (I2S clocks) - 10 CLK_SAI1 (audio clocks) - 11 CLK_SAI2 - 12 CLK_I2SQ_PDIV (post divisor of pll i2s q divisor) - 13 CLK_SAIQ_PDIV (post divisor of pll sai q divisor) - - 14 CLK_HSI (Internal ocscillator clock) - 15 CLK_SYSCLK (System Clock) - 16 CLK_HDMI_CEC (HDMI-CEC clock) - 17 CLK_SPDIF (SPDIF-Rx clock) - 18 CLK_USART1 (U(s)arts clocks) - 19 CLK_USART2 - 20 CLK_USART3 - 21 CLK_UART4 - 22 CLK_UART5 - 23 CLK_USART6 - 24 CLK_UART7 - 25 CLK_UART8 - 26 CLK_I2C1 (I2S clocks) - 27 CLK_I2C2 - 28 CLK_I2C3 - 29 CLK_I2C4 - 30 CLK_LPTIMER (LPTimer1 clock) - 31 CLK_PLL_SRC - 32 CLK_DFSDM1 - 33 CLK_ADFSDM1 - 34 CLK_F769_DSI -) - -Example: - - /* Misc clock, FCLK */ - ... { - clocks = <&rcc 1 STM32F4_APB1_CLOCK(TIM2)> - }; - - -Specifying softreset control of devices -======================================= - -Device nodes should specify the reset channel required in their "resets" -property, containing a phandle to the reset device node and an index specifying -which channel to use. -The index is the bit number within the RCC registers bank, starting from RCC -base address. -It is calculated as: index = register_offset / 4 * 32 + bit_offset. -Where bit_offset is the bit offset within the register. -For example, for CRC reset: - crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140 - -example: - - timer2 { - resets = <&rcc STM32F4_APB1_RESET(TIM2)>; - }; diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32-rcc.yaml new file mode 100644 index 000000000000..f83a6120d65a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st,stm32-rcc.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/st,stm32-rcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STM32 Reset Clock Controller + +maintainers: + - Dario Binacchi <dario.binacchi@amarulasolutions.com> + +description: | + The RCC IP is both a reset and a clock controller. + The reset phandle argument is the bit number within the RCC registers bank, + starting from RCC base address. + +properties: + compatible: + oneOf: + - items: + - enum: + - st,stm32f42xx-rcc + - st,stm32f746-rcc + - st,stm32h743-rcc + - const: st,stm32-rcc + - items: + - enum: + - st,stm32f469-rcc + - const: st,stm32f42xx-rcc + - const: st,stm32-rcc + - items: + - enum: + - st,stm32f769-rcc + - const: st,stm32f746-rcc + - const: st,stm32-rcc + + reg: + maxItems: 1 + + '#reset-cells': + const: 1 + + '#clock-cells': + enum: [1, 2] + + clocks: + minItems: 2 + maxItems: 3 + + st,syscfg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to system configuration controller. It can be used to control the + power domain circuitry. + + st,ssc-modfreq-hz: + description: + The modulation frequency for main PLL (in Hz) + + st,ssc-moddepth-permyriad: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The modulation rate for main PLL (in permyriad, i.e. 0.01%) + minimum: 25 + maximum: 200 + + st,ssc-modmethod: + $ref: /schemas/types.yaml#/definitions/string + description: + The modulation techniques for main PLL. + items: + enum: + - center-spread + - down-spread + +required: + - compatible + - reg + - '#reset-cells' + - '#clock-cells' + - clocks + - st,syscfg + +allOf: + - if: + properties: + compatible: + contains: + const: st,stm32h743-rcc + then: + properties: + '#clock-cells': + const: 1 + description: | + The clock index for the specified type. + clocks: + items: + - description: high speed external (HSE) clock input + - description: low speed external (LSE) clock input + - description: Inter-IC sound (I2S) clock input + st,ssc-modfreq-hz: false + st,ssc-moddepth-permyriad: false + st,ssc-modmethod: false + + else: + properties: + '#clock-cells': + const: 2 + description: | + - The first cell is the clock type, possible values are 0 for + gated clocks and 1 otherwise. + - The second cell is the clock index for the specified type. + clocks: + items: + - description: high speed external (HSE) clock input + - description: Inter-IC sound (I2S) clock input + +additionalProperties: false + +examples: + # Reset and Clock Control Module node: + - | + clock-controller@40023800 { + compatible = "st,stm32f42xx-rcc", "st,stm32-rcc"; + reg = <0x40023800 0x400>; + #clock-cells = <2>; + #reset-cells = <1>; + clocks = <&clk_hse>, <&clk_i2s_ckin>; + st,syscfg = <&pwrcfg>; + st,ssc-modfreq-hz = <10000>; + st,ssc-moddepth-permyriad = <200>; + st,ssc-modmethod = "center-spread"; + }; + - | + clock-controller@58024400 { + compatible = "st,stm32h743-rcc", "st,stm32-rcc"; + reg = <0x58024400 0x400>; + #clock-cells = <1>; + #reset-cells = <1>; + clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s>; + st,syscfg = <&pwrcfg>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml index 9b3aaae546cb..e72f46e79b90 100644 --- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml +++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml @@ -21,7 +21,7 @@ description: | ================= All available clocks are defined as preprocessor macros in - dt-bindings/clock/stm32mp1-clks.h header and can be used in device + include/dt-bindings/clock/stm32mp1-clks.h header and can be used in device tree sources. Specifying softreset control of devices @@ -40,8 +40,8 @@ description: | = 0x180 / 4 * 32 + 0 = 3072 The list of valid indices for STM32MP1 is available in: - include/dt-bindings/reset-controller/stm32mp1-resets.h - include/dt-bindings/reset-controller/stm32mp13-resets.h + include/dt-bindings/reset/stm32mp1-resets.h + include/dt-bindings/reset/stm32mp13-resets.h This file implements defines like: #define LTDC_R 3072 diff --git a/Documentation/devicetree/bindings/clock/ti/composite.txt b/Documentation/devicetree/bindings/clock/ti/composite.txt deleted file mode 100644 index 238e6f7d74f8..000000000000 --- a/Documentation/devicetree/bindings/clock/ti/composite.txt +++ /dev/null @@ -1,55 +0,0 @@ -Binding for TI composite clock. - -This binding uses the common clock binding[1]. It assumes a -register-mapped composite clock with multiple different sub-types; - -a multiplexer clock with multiple input clock signals or parents, one -of which can be selected as output, this behaves exactly as [2] - -an adjustable clock rate divider, this behaves exactly as [3] - -a gating function which can be used to enable and disable the output -clock, this behaves exactly as [4] - -The binding must provide a list of the component clocks that shall be -merged to this clock. The component clocks shall be of one of the -"ti,*composite*-clock" types. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml -[3] Documentation/devicetree/bindings/clock/ti/ti,divider-clock.yaml -[4] Documentation/devicetree/bindings/clock/ti/gate.txt - -Required properties: -- compatible : shall be: "ti,composite-clock" -- clocks : link phandles of component clocks -- #clock-cells : from common clock binding; shall be set to 0. - -Optional properties: -- clock-output-names : from common clock binding. - -Examples: - -usb_l4_gate_ick: usb_l4_gate_ick { - #clock-cells = <0>; - compatible = "ti,composite-interface-clock"; - clocks = <&l4_ick>; - ti,bit-shift = <5>; - reg = <0x0a10>; -}; - -usb_l4_div_ick: usb_l4_div_ick { - #clock-cells = <0>; - compatible = "ti,composite-divider-clock"; - clocks = <&l4_ick>; - ti,bit-shift = <4>; - ti,max-div = <1>; - reg = <0x0a40>; - ti,index-starts-at-one; -}; - -usb_l4_ick: usb_l4_ick { - #clock-cells = <0>; - compatible = "ti,composite-clock"; - clocks = <&usb_l4_gate_ick>, <&usb_l4_div_ick>; -}; diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt deleted file mode 100644 index a8e0335b006a..000000000000 --- a/Documentation/devicetree/bindings/clock/ti/gate.txt +++ /dev/null @@ -1,105 +0,0 @@ -Binding for Texas Instruments gate clock. - -This binding uses the common clock binding[1]. This clock is -quite much similar to the basic gate-clock [2], however, -it supports a number of additional features. If no register -is provided for this clock, the code assumes that a clockdomain -will be controlled instead and the corresponding hw-ops for -that is used. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.yaml -[3] Documentation/devicetree/bindings/clock/ti/clockdomain.txt - -Required properties: -- compatible : shall be one of: - "ti,gate-clock" - basic gate clock - "ti,wait-gate-clock" - gate clock which waits until clock is active before - returning from clk_enable() - "ti,dss-gate-clock" - gate clock with DSS specific hardware handling - "ti,am35xx-gate-clock" - gate clock with AM35xx specific hardware handling - "ti,clkdm-gate-clock" - clockdomain gate clock, which derives its functional - clock directly from a clockdomain, see [3] how - to map clockdomains properly - "ti,hsdiv-gate-clock" - gate clock with OMAP36xx specific hardware handling, - required for a hardware errata - "ti,composite-gate-clock" - composite gate clock, to be part of composite - clock - "ti,composite-no-wait-gate-clock" - composite gate clock that does not wait - for clock to be active before returning - from clk_enable() -- #clock-cells : from common clock binding; shall be set to 0 -- clocks : link to phandle of parent clock -- reg : offset for register controlling adjustable gate, not needed for - ti,clkdm-gate-clock type - -Optional properties: -- clock-output-names : from common clock binding. -- ti,bit-shift : bit shift for programming the clock gate, invalid for - ti,clkdm-gate-clock type -- ti,set-bit-to-disable : inverts default gate programming. Setting the bit - gates the clock and clearing the bit ungates the clock. - -Examples: - mmchs2_fck: mmchs2_fck@48004a00 { - #clock-cells = <0>; - compatible = "ti,gate-clock"; - clocks = <&core_96m_fck>; - reg = <0x0a00>; - ti,bit-shift = <25>; - }; - - uart4_fck_am35xx: uart4_fck_am35xx { - #clock-cells = <0>; - compatible = "ti,wait-gate-clock"; - clocks = <&core_48m_fck>; - reg = <0x0a00>; - ti,bit-shift = <23>; - }; - - dss1_alwon_fck_3430es2: dss1_alwon_fck_3430es2@48004e00 { - #clock-cells = <0>; - compatible = "ti,dss-gate-clock"; - clocks = <&dpll4_m4x2_ck>; - reg = <0x0e00>; - ti,bit-shift = <0>; - }; - - emac_ick: emac_ick@4800259c { - #clock-cells = <0>; - compatible = "ti,am35xx-gate-clock"; - clocks = <&ipss_ick>; - reg = <0x059c>; - ti,bit-shift = <1>; - }; - - emu_src_ck: emu_src_ck { - #clock-cells = <0>; - compatible = "ti,clkdm-gate-clock"; - clocks = <&emu_src_mux_ck>; - }; - - dpll4_m2x2_ck: dpll4_m2x2_ck@48004d00 { - #clock-cells = <0>; - compatible = "ti,hsdiv-gate-clock"; - clocks = <&dpll4_m2x2_mul_ck>; - ti,bit-shift = <0x1b>; - reg = <0x0d00>; - ti,set-bit-to-disable; - }; - - vlynq_gate_fck: vlynq_gate_fck { - #clock-cells = <0>; - compatible = "ti,composite-gate-clock"; - clocks = <&core_ck>; - ti,bit-shift = <3>; - reg = <0x0200>; - }; - - sys_clkout2_src_gate: sys_clkout2_src_gate { - #clock-cells = <0>; - compatible = "ti,composite-no-wait-gate-clock"; - clocks = <&core_ck>; - ti,bit-shift = <15>; - reg = <0x0070>; - }; diff --git a/Documentation/devicetree/bindings/clock/ti/ti,composite-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,composite-clock.yaml new file mode 100644 index 000000000000..31a6794852c7 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/ti,composite-clock.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/ti/ti,composite-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments composite clock + +maintainers: + - Tero Kristo <kristo@kernel.org> + +description: | + *Deprecated design pattern: one node per clock* + + This binding assumes a register-mapped composite clock with multiple + different sub-types: + + a multiplexer clock with multiple input clock signals or parents, one + of which can be selected as output, this behaves exactly as [1]. + + an adjustable clock rate divider, this behaves exactly as [2]. + + a gating function which can be used to enable and disable the output + clock, this behaves exactly as [3]. + + The binding must provide a list of the component clocks that shall be + merged to this clock. The component clocks shall be of one of the + "ti,*composite*-clock" types. + + [1] Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml + [2] Documentation/devicetree/bindings/clock/ti/ti,divider-clock.yaml + [3] Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml + +properties: + compatible: + const: ti,composite-clock + + "#clock-cells": + const: 0 + + clocks: true + + clock-output-names: + maxItems: 1 + +required: + - compatible + - "#clock-cells" + - clocks + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <1>; + #size-cells = <0>; + + usb_l4_gate_ick: clock-controller@a10 { + #clock-cells = <0>; + compatible = "ti,composite-gate-clock"; + clocks = <&l4_ick>; + ti,bit-shift = <5>; + reg = <0x0a10>; + }; + + usb_l4_div_ick: clock-controller@a40 { + #clock-cells = <0>; + compatible = "ti,composite-divider-clock"; + clocks = <&l4_ick>; + ti,bit-shift = <4>; + ti,max-div = <1>; + reg = <0x0a40>; + ti,index-starts-at-one; + }; + }; + + clock-controller { + #clock-cells = <0>; + compatible = "ti,composite-clock"; + clocks = <&usb_l4_gate_ick>, <&usb_l4_div_ick>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml new file mode 100644 index 000000000000..eaa727ab0d7f --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml @@ -0,0 +1,125 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/ti/ti,gate-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments gate clock + +maintainers: + - Tero Kristo <kristo@kernel.org> + +description: | + *Deprecated design pattern: one node per clock* + + This clock is quite much similar to the basic gate-clock [1], however, + it supports a number of additional features. If no register + is provided for this clock, the code assumes that a clockdomain + will be controlled instead and the corresponding hw-ops for + that is used. + + [1] Documentation/devicetree/bindings/clock/gpio-gate-clock.yaml + [2] Documentation/devicetree/bindings/clock/ti/clockdomain.txt + +properties: + compatible: + enum: + - ti,gate-clock # basic gate clock + - ti,wait-gate-clock # gate clock which waits until clock is + # active before returning from clk_enable() + - ti,dss-gate-clock # gate clock with DSS specific hardware + # handling + - ti,am35xx-gate-clock # gate clock with AM35xx specific hardware + # handling + - ti,clkdm-gate-clock # clockdomain gate clock, which derives its + # functional clock directly from a + # clockdomain, see [2] how to map + # clockdomains properly + - ti,hsdiv-gate-clock # gate clock with OMAP36xx specific hardware + # handling, required for a hardware errata + - ti,composite-gate-clock # composite gate clock, to be part of + # composite clock + - ti,composite-no-wait-gate-clock # composite gate clock that does not + # wait for clock to be active before + # returning from clk_enable() + "#clock-cells": + const: 0 + + clocks: true + + clock-output-names: + maxItems: 1 + + reg: + maxItems: 1 + + ti,bit-shift: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Number of bits to shift the bit-mask + maximum: 31 + default: 0 + + ti,set-bit-to-disable: + type: boolean + description: + Inverts default gate programming. Setting the bit + gates the clock and clearing the bit ungates the clock. + + ti,set-rate-parent: + type: boolean + description: + clk_set_rate is propagated to parent clock, + +if: + properties: + compatible: + contains: + const: ti,clkdm-gate-clock +then: + properties: + reg: false + required: + - compatible + - "#clock-cells" + - clocks +else: + required: + - compatible + - "#clock-cells" + - clocks + - reg + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <1>; + #size-cells = <0>; + + clock-controller@a00 { + #clock-cells = <0>; + compatible = "ti,gate-clock"; + clocks = <&core_96m_fck>; + reg = <0x0a00>; + ti,bit-shift = <25>; + }; + + clock-controller@d00 { + compatible = "ti,hsdiv-gate-clock"; + reg = <0x0d00>; + #clock-cells = <0>; + clocks = <&dpll4_m2x2_mul_ck>; + ti,bit-shift = <0x1b>; + ti,set-bit-to-disable; + }; + }; + + - | + clock-controller { + #clock-cells = <0>; + compatible = "ti,clkdm-gate-clock"; + clocks = <&emu_src_mux_ck>; + }; + diff --git a/Documentation/devicetree/bindings/clock/xlnx,vcu.yaml b/Documentation/devicetree/bindings/clock/xlnx,vcu.yaml new file mode 100644 index 000000000000..19dc923e2ee9 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/xlnx,vcu.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/xlnx,vcu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# +title: LogicoreIP designed compatible with Xilinx ZYNQ family. + +maintainers: + - Rohit Visavalia <rohit.visavalia@amd.com> + +description: + LogicoreIP design to provide the isolation between processing system + and programmable logic. Also provides the list of register set to configure + the frequency. + +properties: + compatible: + items: + - enum: + - xlnx,vcu + - xlnx,vcu-logicoreip-1.0 + + reg: + maxItems: 1 + + clocks: + items: + - description: pll ref clocksource + - description: aclk + + clock-names: + items: + - const: pll_ref + - const: aclk + + reset-gpios: + maxItems: 1 + +required: + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + fpga { + #address-cells = <2>; + #size-cells = <2>; + xlnx_vcu: vcu@a0040000 { + compatible = "xlnx,vcu-logicoreip-1.0"; + reg = <0x0 0xa0040000 0x0 0x1000>; + reset-gpios = <&gpio 78 GPIO_ACTIVE_HIGH>; + clocks = <&si570_1>, <&clkc 71>; + clock-names = "pll_ref", "aclk"; + }; + }; diff --git a/Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml b/Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml new file mode 100644 index 000000000000..a16ae2762d16 --- /dev/null +++ b/Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/connector/gocontroll,moduline-module-slot.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GOcontroll Moduline Module slot + +maintainers: + - Maud Spierings <maudspierings@gocontroll.com> + +description: + The GOcontroll Moduline module slot represents a connector that fullfills the + Moduline slot specification, and can thus house any IO module that is also + built to this spec. + +properties: + compatible: + const: gocontroll,moduline-module-slot + + reg: + maxItems: 1 + + interrupts: + description: indicates readiness, high means busy. + maxItems: 1 + reset-gpios: + description: resets the module, active low. + maxItems: 1 + sync-gpios: + description: sync line between all module slots. + maxItems: 1 + + vdd-supply: + description: low power 3v3 supply generally for the microcontroller. + vddp-supply: + description: medium power 5v0 supply for on module low power peripherals. + vddhpp-supply: + description: high power 6v-8v supply for on module high power peripherals. + power-supply: + description: high power 6v-30v supply for high power module circuits. + + i2c-bus: + description: i2c bus shared between module slots and the SoC + $ref: /schemas/types.yaml#/definitions/phandle + + slot-number: + description: + The number of the module slot representing the location of on the pcb. + This enables access to the modules based on slot location. + $ref: /schemas/types.yaml#/definitions/uint32 + + spi-max-frequency: true + +required: + - compatible + - reg + - reset-gpios + - interrupts + - sync-gpios + - i2c-bus + - slot-number + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + connector@0 { + reg = <0>; + compatible = "gocontroll,moduline-module-slot"; + reset-gpios = <&gpio5 10 GPIO_ACTIVE_LOW>; + sync-gpios = <&gpio4 16 GPIO_ACTIVE_HIGH>; + interrupt-parent = <&gpio4>; + interrupts = <5 IRQ_TYPE_EDGE_FALLING>; + vdd-supply = <®_3v3_per>; + vddp-supply = <®_5v0>; + vddhpp-supply = <®_6v4>; + i2c-bus = <&i2c2>; + slot-number = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 67700440e23b..11e40d225b9f 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -293,6 +293,13 @@ properties: PD negotiation till BC1.2 detection completes. default: 0 + pd-revision: + description: Specifies the maximum USB PD revision and version supported by + the connector. This property is specified in the following order; + <revision_major, revision_minor, version_major, version_minor>. + $ref: /schemas/types.yaml#/definitions/uint8-array + maxItems: 4 + dependencies: sink-vdos-v1: [ sink-vdos ] sink-vdos: [ sink-vdos-v1 ] diff --git a/Documentation/devicetree/bindings/cpufreq/airoha,en7581-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/airoha,en7581-cpufreq.yaml new file mode 100644 index 000000000000..7d4510b3219c --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/airoha,en7581-cpufreq.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cpufreq/airoha,en7581-cpufreq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Airoha EN7581 CPUFreq + +maintainers: + - Christian Marangi <ansuelsmth@gmail.com> + +description: | + On newer Airoha SoC, CPU Frequency is scaled indirectly with SMC commands + to ATF. + + A virtual clock is exposed. This virtual clock is a get-only clock and + is used to expose the current global CPU clock. The frequency info comes + by the output of the SMC command that reports the clock in MHz. + + The SMC sets the CPU clock by providing an index, this is modelled as + performance states in a power domain. + + CPUs can't be individually scaled as the CPU frequency is shared across + all CPUs and is global. + +properties: + compatible: + const: airoha,en7581-cpufreq + + '#clock-cells': + const: 0 + + '#power-domain-cells': + const: 0 + + operating-points-v2: true + +required: + - compatible + - '#clock-cells' + - '#power-domain-cells' + - operating-points-v2 + +additionalProperties: false + +examples: + - | + performance-domain { + compatible = "airoha,en7581-cpufreq"; + + operating-points-v2 = <&cpu_smcc_opp_table>; + + #power-domain-cells = <0>; + #clock-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml index 76cb9726660e..896276b8c6bb 100644 --- a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml +++ b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml @@ -24,9 +24,17 @@ properties: - apple,t8112-cluster-cpufreq - const: apple,cluster-cpufreq - items: - - const: apple,t6000-cluster-cpufreq + - enum: + - apple,s8000-cluster-cpufreq + - apple,t8010-cluster-cpufreq + - apple,t8015-cluster-cpufreq + - apple,t6000-cluster-cpufreq - const: apple,t8103-cluster-cpufreq - const: apple,cluster-cpufreq + - items: + - const: apple,t7000-cluster-cpufreq + - const: apple,s5l8960x-cluster-cpufreq + - const: apple,s5l8960x-cluster-cpufreq reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml index e937eb7355e7..e0242bed3342 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -34,6 +34,7 @@ properties: - description: v2 of CPUFREQ HW (EPSS) items: - enum: + - qcom,qcs8300-cpufreq-epss - qcom,qdu1000-cpufreq-epss - qcom,sa8255p-cpufreq-epss - qcom,sa8775p-cpufreq-epss @@ -111,22 +112,20 @@ allOf: enum: - qcom,qcm2290-cpufreq-hw - qcom,sar2130p-cpufreq-epss + - qcom,sdx75-cpufreq-epss then: properties: reg: - minItems: 1 maxItems: 1 reg-names: - minItems: 1 maxItems: 1 interrupts: - minItems: 1 maxItems: 1 interrupt-names: - minItems: 1 + maxItems: 1 - if: properties: @@ -135,6 +134,7 @@ allOf: enum: - qcom,qdu1000-cpufreq-epss - qcom,sa8255p-cpufreq-epss + - qcom,sa8775p-cpufreq-epss - qcom,sc7180-cpufreq-hw - qcom,sc8180x-cpufreq-hw - qcom,sc8280xp-cpufreq-epss @@ -160,12 +160,14 @@ allOf: interrupt-names: minItems: 2 + maxItems: 2 - if: properties: compatible: contains: enum: + - qcom,qcs8300-cpufreq-epss - qcom,sc7280-cpufreq-epss - qcom,sm8250-cpufreq-epss - qcom,sm8350-cpufreq-epss @@ -187,6 +189,7 @@ allOf: interrupt-names: minItems: 3 + maxItems: 3 - if: properties: @@ -211,7 +214,31 @@ allOf: interrupt-names: minItems: 2 + maxItems: 2 + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8650-cpufreq-epss + then: + properties: + reg: + minItems: 4 + maxItems: 4 + + reg-names: + minItems: 4 + maxItems: 4 + + interrupts: + minItems: 4 + maxItems: 4 + + interrupt-names: + minItems: 4 + maxItems: 4 examples: - | diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml index 0304f074cf08..08fe6a707a37 100644 --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml @@ -13,12 +13,14 @@ properties: compatible: items: - enum: + - qcom,qcs8300-inline-crypto-engine - qcom,sa8775p-inline-crypto-engine - qcom,sc7180-inline-crypto-engine - qcom,sc7280-inline-crypto-engine - qcom,sm8450-inline-crypto-engine - qcom,sm8550-inline-crypto-engine - qcom,sm8650-inline-crypto-engine + - qcom,sm8750-inline-crypto-engine - const: qcom,inline-crypto-engine reg: diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml index 048b769a73c0..5e6f8b642545 100644 --- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml @@ -17,12 +17,17 @@ properties: - qcom,prng-ee # 8996 and later using EE - items: - enum: + - qcom,ipq5332-trng + - qcom,ipq5424-trng + - qcom,ipq9574-trng + - qcom,qcs8300-trng - qcom,sa8255p-trng - qcom,sa8775p-trng - qcom,sc7280-trng - qcom,sm8450-trng - qcom,sm8550-trng - qcom,sm8650-trng + - qcom,sm8750-trng - const: qcom,trng reg: diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml index c09be97434ac..3ed56d9d378e 100644 --- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml @@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm crypto engine driver maintainers: - - Bhupesh Sharma <bhupesh.sharma@linaro.org> + - Bjorn Andersson <andersson@kernel.org> + - Konrad Dybcio <konradybcio@kernel.org> description: This document defines the binding for the QCE crypto @@ -44,6 +45,7 @@ properties: - items: - enum: + - qcom,qcs8300-qce - qcom,sa8775p-qce - qcom,sc7280-qce - qcom,sm6350-qce @@ -52,6 +54,7 @@ properties: - qcom,sm8450-qce - qcom,sm8550-qce - qcom,sm8650-qce + - qcom,sm8750-qce - const: qcom,sm8150-qce - const: qcom,qce diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml index 84d68b8cfccc..416fe263ac92 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml @@ -148,10 +148,10 @@ examples: /* TMDS Output */ hdmi_tx_tmds_port: port@1 { - reg = <1>; + reg = <1>; - hdmi_tx_tmds_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; + hdmi_tx_tmds_out: endpoint { + remote-endpoint = <&hdmi_connector_in>; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml index 5b35adf34c7b..6d11f5955b51 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml @@ -14,6 +14,8 @@ properties: enum: - brcm,bcm2711-hdmi0 - brcm,bcm2711-hdmi1 + - brcm,bcm2712-hdmi0 + - brcm,bcm2712-hdmi1 reg: items: diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml index 2e8566f47e63..f91c9dce2a44 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml @@ -13,6 +13,7 @@ properties: compatible: enum: - brcm,bcm2711-hvs + - brcm,bcm2712-hvs - brcm,bcm2835-hvs reg: @@ -36,7 +37,9 @@ if: properties: compatible: contains: - const: brcm,bcm2711-hvs + enum: + - brcm,bcm2711-hvs + - brcm,bcm2712-hvs then: required: diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml index 4e1ba03f6477..6b5b1d3fbc0b 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml @@ -20,6 +20,9 @@ properties: - brcm,bcm2711-pixelvalve2 - brcm,bcm2711-pixelvalve3 - brcm,bcm2711-pixelvalve4 + - brcm,bcm2712-pixelvalve0 + - brcm,bcm2712-pixelvalve1 + - brcm,bcm2712-pixelvalve2 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml index bb186197e471..16f45afd2bad 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml @@ -11,7 +11,10 @@ maintainers: properties: compatible: - const: brcm,bcm2835-txp + enum: + - brcm,bcm2712-mop + - brcm,bcm2712-moplet + - brcm,bcm2835-txp reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml index 49a5e041aa49..2aa9d5d2afff 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - brcm,bcm2711-vc5 + - brcm,bcm2712-vc6 - brcm,bcm2835-vc4 - brcm,cygnus-vc4 diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml index 3791c9f4ebab..05442d437755 100644 --- a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml +++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml @@ -82,21 +82,21 @@ examples: power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>; reg-io-width = <1>; ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - - hdmi_tx_from_pvi: endpoint { - remote-endpoint = <&pvi_to_hdmi_tx>; - }; - }; - - port@1 { - reg = <1>; - hdmi_tx_out: endpoint { - remote-endpoint = <&hdmi0_con>; - }; - }; + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + + endpoint { + remote-endpoint = <&pvi_to_hdmi_tx>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&hdmi0_con>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml index d33026f85e19..c167795c63f6 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml @@ -19,6 +19,7 @@ properties: enum: - renesas,r8a779a0-dsi-csi2-tx # for V3U - renesas,r8a779g0-dsi-csi2-tx # for V4H + - renesas,r8a779h0-dsi-csi2-tx # for V4M reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml index 4ed7a799ba26..1acad99f3965 100644 --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -27,7 +27,9 @@ properties: - fsl,imx8mm-mipi-dsim - fsl,imx8mp-mipi-dsim - items: - - const: fsl,imx8mn-mipi-dsim + - enum: + - fsl,imx7d-mipi-dsim + - fsl,imx8mn-mipi-dsim - const: fsl,imx8mm-mipi-dsim reg: @@ -241,40 +243,40 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> dsi@13900000 { - compatible = "samsung,exynos5433-mipi-dsi"; - reg = <0x13900000 0xC0>; - interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>; - phys = <&mipi_phy 1>; - phy-names = "dsim"; - clocks = <&cmu_disp CLK_PCLK_DSIM0>, - <&cmu_disp CLK_PHYCLK_MIPIDPHY0_BITCLKDIV8>, - <&cmu_disp CLK_PHYCLK_MIPIDPHY0_RXCLKESC0>, - <&cmu_disp CLK_SCLK_RGB_VCLK_TO_DSIM0>, - <&cmu_disp CLK_SCLK_DSIM0>; - clock-names = "bus_clk", - "phyclk_mipidphy0_bitclkdiv8", - "phyclk_mipidphy0_rxclkesc0", - "sclk_rgb_vclk_to_dsim0", - "sclk_mipi"; - power-domains = <&pd_disp>; - vddcore-supply = <&ldo6_reg>; - vddio-supply = <&ldo7_reg>; - samsung,burst-clock-frequency = <512000000>; - samsung,esc-clock-frequency = <16000000>; - samsung,pll-clock-frequency = <24000000>; - pinctrl-names = "default"; - pinctrl-0 = <&te_irq>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - dsi_to_mic: endpoint { - remote-endpoint = <&mic_to_dsi>; - }; - }; - }; + compatible = "samsung,exynos5433-mipi-dsi"; + reg = <0x13900000 0xC0>; + interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>; + phys = <&mipi_phy 1>; + phy-names = "dsim"; + clocks = <&cmu_disp CLK_PCLK_DSIM0>, + <&cmu_disp CLK_PHYCLK_MIPIDPHY0_BITCLKDIV8>, + <&cmu_disp CLK_PHYCLK_MIPIDPHY0_RXCLKESC0>, + <&cmu_disp CLK_SCLK_RGB_VCLK_TO_DSIM0>, + <&cmu_disp CLK_SCLK_DSIM0>; + clock-names = "bus_clk", + "phyclk_mipidphy0_bitclkdiv8", + "phyclk_mipidphy0_rxclkesc0", + "sclk_rgb_vclk_to_dsim0", + "sclk_mipi"; + power-domains = <&pd_disp>; + vddcore-supply = <&ldo6_reg>; + vddio-supply = <&ldo7_reg>; + samsung,burst-clock-frequency = <512000000>; + samsung,esc-clock-frequency = <16000000>; + samsung,pll-clock-frequency = <24000000>; + pinctrl-names = "default"; + pinctrl-0 = <&te_irq>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + dsi_to_mic: endpoint { + remote-endpoint = <&mic_to_dsi>; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index 48a97bb3e2e0..bad6f5c81b06 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -80,12 +80,12 @@ properties: - const: 4 port@2: - $ref: /schemas/graph.yaml#/properties/port description: Video port for LVDS Channel-A output (panel or bridge). + $ref: '#/$defs/lvds-port' port@3: - $ref: /schemas/graph.yaml#/properties/port description: Video port for LVDS Channel-B output (panel or bridge). + $ref: '#/$defs/lvds-port' required: - port@0 @@ -96,6 +96,36 @@ required: - reg - ports +$defs: + lvds-port: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + ti,lvds-termination-ohms: + description: The value of near end differential termination in ohms. + enum: [100, 200] + default: 200 + + ti,lvds-vod-swing-clock-microvolt: + description: LVDS diferential output voltage <min max> for clock + lanes in microvolts. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + + ti,lvds-vod-swing-data-microvolt: + description: LVDS diferential output voltage <min max> for data + lanes in microvolts. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + allOf: - if: properties: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index 47ddba5c41af..5d2089dc596e 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -104,30 +104,30 @@ examples: #size-cells = <2>; aal@14015000 { - compatible = "mediatek,mt8173-disp-aal"; - reg = <0 0x14015000 0 0x1000>; - interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_AAL>; - mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - aal0_in: endpoint { - remote-endpoint = <&ccorr0_out>; - }; - }; - - port@1 { - reg = <1>; - aal0_out: endpoint { - remote-endpoint = <&gamma0_in>; - }; - }; - }; - }; + compatible = "mediatek,mt8173-disp-aal"; + reg = <0 0x14015000 0 0x1000>; + interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_AAL>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&ccorr0_out>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&gamma0_in>; + }; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index 9ea796a033b2..4f110635afb6 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt8173-disp-ovl - mediatek,mt8183-disp-ovl - mediatek,mt8192-disp-ovl + - mediatek,mt8195-disp-ovl - mediatek,mt8195-mdp3-ovl - items: - enum: @@ -38,14 +39,15 @@ properties: - const: mediatek,mt8173-disp-ovl - items: - enum: - - mediatek,mt8188-disp-ovl - - mediatek,mt8195-disp-ovl - - const: mediatek,mt8183-disp-ovl - - items: - - enum: - mediatek,mt8186-disp-ovl - mediatek,mt8365-disp-ovl - const: mediatek,mt8192-disp-ovl + - items: + - const: mediatek,mt8188-disp-ovl + - const: mediatek,mt8195-disp-ovl + - items: + - const: mediatek,mt8188-mdp3-ovl + - const: mediatek,mt8195-mdp3-ovl reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index a212f335d5ff..e00b88332f2f 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -8,6 +8,7 @@ title: MSM Display Port Controller maintainers: - Kuogee Hsieh <quic_khsieh@quicinc.com> + - Abhinav Kumar <quic_abhinavk@quicinc.com> description: | Device tree bindings for DisplayPort host controller for MSM targets diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index b0fd96b76ed1..ffbd1dc9470e 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -30,6 +30,7 @@ properties: - qcom,sdm845-dsi-ctrl - qcom,sm6115-dsi-ctrl - qcom,sm6125-dsi-ctrl + - qcom,sm6150-dsi-ctrl - qcom,sm6350-dsi-ctrl - qcom,sm6375-dsi-ctrl - qcom,sm7150-dsi-ctrl @@ -349,6 +350,7 @@ allOf: enum: - qcom,sc7180-dsi-ctrl - qcom,sc7280-dsi-ctrl + - qcom,sm6150-dsi-ctrl - qcom,sm7150-dsi-ctrl - qcom,sm8150-dsi-ctrl - qcom,sm8250-dsi-ctrl @@ -416,63 +418,63 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,dispcc-sdm845.h> - #include <dt-bindings/clock/qcom,gcc-sdm845.h> - #include <dt-bindings/power/qcom-rpmpd.h> - - dsi@ae94000 { - compatible = "qcom,sc7180-dsi-ctrl", "qcom,mdss-dsi-ctrl"; - reg = <0x0ae94000 0x400>; - reg-names = "dsi_ctrl"; - - #address-cells = <1>; - #size-cells = <0>; - - interrupt-parent = <&mdss>; - interrupts = <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>, - <&dispcc DISP_CC_MDSS_AXI_CLK>; - clock-names = "byte", - "byte_intf", - "pixel", - "core", - "iface", - "bus"; - - phys = <&dsi0_phy>; - phy-names = "dsi"; - - assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>; - assigned-clock-parents = <&dsi_phy 0>, <&dsi_phy 1>; - - power-domains = <&rpmhpd SC7180_CX>; - operating-points-v2 = <&dsi_opp_table>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - dsi0_in: endpoint { - remote-endpoint = <&dpu_intf1_out>; - }; - }; - - port@1 { - reg = <1>; - dsi0_out: endpoint { - remote-endpoint = <&sn65dsi86_in>; - data-lanes = <0 1 2 3>; - qcom,te-source = "mdp_vsync_e"; - }; - }; - }; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + dsi@ae94000 { + compatible = "qcom,sc7180-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x0ae94000 0x400>; + reg-names = "dsi_ctrl"; + + #address-cells = <1>; + #size-cells = <0>; + + interrupt-parent = <&mdss>; + interrupts = <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>, + <&dispcc DISP_CC_MDSS_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + phys = <&dsi0_phy>; + phy-names = "dsi"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>; + assigned-clock-parents = <&dsi_phy 0>, <&dsi_phy 1>; + + power-domains = <&rpmhpd SC7180_CX>; + operating-points-v2 = <&dsi_opp_table>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dpu_intf1_out>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&sn65dsi86_in>; + data-lanes = <0 1 2 3>; + qcom,te-source = "mdp_vsync_e"; + }; + }; + }; + }; ... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml index 69d13867b7cf..fc9abf090f0d 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml @@ -74,28 +74,28 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/qcom,dispcc-sdm845.h> - #include <dt-bindings/clock/qcom,rpmh.h> - - dsi-phy@ae94400 { - compatible = "qcom,dsi-phy-10nm"; - reg = <0x0ae94400 0x200>, - <0x0ae94600 0x280>, - <0x0ae94a00 0x1e0>; - reg-names = "dsi_phy", - "dsi_phy_lane", - "dsi_pll"; - - #clock-cells = <1>; - #phy-cells = <0>; - - vdds-supply = <&vdda_mipi_dsi0_pll>; - clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, - <&rpmhcc RPMH_CXO_CLK>; - clock-names = "iface", "ref"; - - qcom,phy-rescode-offset-top = /bits/ 8 <0 0 0 0 0>; - qcom,phy-rescode-offset-bot = /bits/ 8 <0 0 0 0 0>; - qcom,phy-drive-ldo-level = <400>; - }; + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + dsi-phy@ae94400 { + compatible = "qcom,dsi-phy-10nm"; + reg = <0x0ae94400 0x200>, + <0x0ae94600 0x280>, + <0x0ae94a00 0x1e0>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vdds-supply = <&vdda_mipi_dsi0_pll>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + + qcom,phy-rescode-offset-top = /bits/ 8 <0 0 0 0 0>; + qcom,phy-rescode-offset-bot = /bits/ 8 <0 0 0 0 0>; + qcom,phy-drive-ldo-level = <400>; + }; ... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml index 52bbe132e6da..206a9a4b3845 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml @@ -20,6 +20,7 @@ properties: - qcom,dsi-phy-14nm-660 - qcom,dsi-phy-14nm-8953 - qcom,sm6125-dsi-phy-14nm + - qcom,sm6150-dsi-phy-14nm reg: items: @@ -55,24 +56,24 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/qcom,dispcc-sdm845.h> - #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> - dsi-phy@ae94400 { - compatible = "qcom,dsi-phy-14nm"; - reg = <0x0ae94400 0x200>, - <0x0ae94600 0x280>, - <0x0ae94a00 0x1e0>; - reg-names = "dsi_phy", - "dsi_phy_lane", - "dsi_pll"; + dsi-phy@ae94400 { + compatible = "qcom,dsi-phy-14nm"; + reg = <0x0ae94400 0x200>, + <0x0ae94600 0x280>, + <0x0ae94a00 0x1e0>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; - #clock-cells = <1>; - #phy-cells = <0>; + #clock-cells = <1>; + #phy-cells = <0>; - vcca-supply = <&vcca_reg>; - clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, - <&rpmhcc RPMH_CXO_CLK>; - clock-names = "iface", "ref"; - }; + vcca-supply = <&vcca_reg>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; ... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml index 7e6687cb002b..93570052992a 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml @@ -45,26 +45,26 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/qcom,dispcc-sdm845.h> - #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> - dsi-phy@fd922a00 { - compatible = "qcom,dsi-phy-20nm"; - reg = <0xfd922a00 0xd4>, - <0xfd922b00 0x2b0>, - <0xfd922d80 0x7b>; - reg-names = "dsi_pll", - "dsi_phy", - "dsi_phy_regulator"; + dsi-phy@fd922a00 { + compatible = "qcom,dsi-phy-20nm"; + reg = <0xfd922a00 0xd4>, + <0xfd922b00 0x2b0>, + <0xfd922d80 0x7b>; + reg-names = "dsi_pll", + "dsi_phy", + "dsi_phy_regulator"; - #clock-cells = <1>; - #phy-cells = <0>; + #clock-cells = <1>; + #phy-cells = <0>; - vcca-supply = <&vcca_reg>; - vddio-supply = <&vddio_reg>; + vcca-supply = <&vcca_reg>; + vddio-supply = <&vddio_reg>; - clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, - <&rpmhcc RPMH_CXO_CLK>; - clock-names = "iface", "ref"; - }; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; ... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml index a55c2445d189..371befa9f9d2 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml @@ -51,25 +51,25 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/qcom,dispcc-sdm845.h> - #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> - dsi-phy@fd922a00 { - compatible = "qcom,dsi-phy-28nm-lp"; - reg = <0xfd922a00 0xd4>, - <0xfd922b00 0x2b0>, - <0xfd922d80 0x7b>; - reg-names = "dsi_pll", - "dsi_phy", - "dsi_phy_regulator"; + dsi-phy@fd922a00 { + compatible = "qcom,dsi-phy-28nm-lp"; + reg = <0xfd922a00 0xd4>, + <0xfd922b00 0x2b0>, + <0xfd922d80 0x7b>; + reg-names = "dsi_pll", + "dsi_phy", + "dsi_phy_regulator"; - #clock-cells = <1>; - #phy-cells = <0>; + #clock-cells = <1>; + #phy-cells = <0>; - vddio-supply = <&vddio_reg>; + vddio-supply = <&vddio_reg>; - clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, - <&rpmhcc RPMH_CXO_CLK>; - clock-names = "iface", "ref"; - }; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; ... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml index 7e764eac3ef3..321470435e65 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml @@ -54,23 +54,23 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/qcom,dispcc-sm8250.h> - #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,dispcc-sm8250.h> + #include <dt-bindings/clock/qcom,rpmh.h> - dsi-phy@ae94400 { - compatible = "qcom,dsi-phy-7nm"; - reg = <0x0ae94400 0x200>, - <0x0ae94600 0x280>, - <0x0ae94900 0x260>; - reg-names = "dsi_phy", - "dsi_phy_lane", - "dsi_pll"; + dsi-phy@ae94400 { + compatible = "qcom,dsi-phy-7nm"; + reg = <0x0ae94400 0x200>, + <0x0ae94600 0x280>, + <0x0ae94900 0x260>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; - #clock-cells = <1>; - #phy-cells = <0>; + #clock-cells = <1>; + #phy-cells = <0>; - vdds-supply = <&vreg_l5a_0p88>; - clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, - <&rpmhcc RPMH_CXO_CLK>; - clock-names = "iface", "ref"; - }; + vdds-supply = <&vreg_l5a_0p88>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml index 58f8a01f29c7..a90a8b3f1a9e 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml @@ -78,7 +78,6 @@ examples: "mdp1-mem", "cpu-cfg"; - resets = <&dispcc_core_bcr>; power-domains = <&dispcc_gdsc>; @@ -129,7 +128,7 @@ examples: port@0 { reg = <0>; dpu_intf0_out: endpoint { - remote-endpoint = <&mdss0_dp0_in>; + remote-endpoint = <&mdss0_dp0_in>; }; }; }; @@ -168,7 +167,8 @@ examples: reg = <0xaf54000 0x104>, <0xaf54200 0x0c0>, <0xaf55000 0x770>, - <0xaf56000 0x09c>; + <0xaf56000 0x09c>, + <0xaf57000 0x09c>; interrupt-parent = <&mdss0>; interrupts = <12>; @@ -208,8 +208,8 @@ examples: }; port@1 { - reg = <1>; - mdss0_dp_out: endpoint { }; + reg = <1>; + mdss0_dp_out: endpoint { }; }; }; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6150-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6150-dpu.yaml new file mode 100644 index 000000000000..b4f437172218 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6150-dpu.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,sm6150-dpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM6150 Display DPU + +maintainers: + - Abhinav Kumar <quic_abhinavk@quicinc.com> + - Dmitry Baryshkov <dmitry.baryshkov@linaro.org> + +$ref: /schemas/display/msm/dpu-common.yaml# + +properties: + compatible: + const: qcom,sm6150-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for vbif register set + + reg-names: + items: + - const: mdp + - const: vbif + + clocks: + items: + - description: Display ahb clock + - description: Display hf axi clock + - description: Display core clock + - description: Display vsync clock + + clock-names: + items: + - const: iface + - const: bus + - const: core + - const: vsync + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom,rpmhpd.h> + + display-controller@ae01000 { + compatible = "qcom,sm6150-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&dispcc_mdss_ahb_clk>, + <&gcc_disp_hf_axi_clk>, + <&dispcc_mdss_mdp_clk>, + <&dispcc_mdss_vsync_clk>; + clock-names = "iface", "bus", "core", "vsync"; + + assigned-clocks = <&dispcc_mdss_vsync_clk>; + assigned-clock-rates = <19200000>; + + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmhpd RPMHPD_CX>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf0_out: endpoint { + }; + }; + + port@1 { + reg = <1>; + dpu_intf1_out: endpoint { + remote-endpoint = <&mdss_dsi0_in>; + }; + }; + }; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-19200000 { + opp-hz = /bits/ 64 <19200000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-25600000 { + opp-hz = /bits/ 64 <25600000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-307200000 { + opp-hz = /bits/ 64 <307200000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6150-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6150-mdss.yaml new file mode 100644 index 000000000000..9ac24f99d3ad --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6150-mdss.yaml @@ -0,0 +1,245 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,sm6150-mdss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM6150 Display MDSS + +maintainers: + - Abhinav Kumar <quic_abhinavk@quicinc.com> + - Dmitry Baryshkov <dmitry.baryshkov@linaro.org> + +description: + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree + bindings of MDSS are mentioned for SM6150 target. + +$ref: /schemas/display/msm/mdss-common.yaml# + +properties: + compatible: + items: + - const: qcom,sm6150-mdss + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display hf axi clock + - description: Display core clock + + clock-names: + items: + - const: iface + - const: bus + - const: core + + iommus: + maxItems: 1 + + interconnects: + maxItems: 2 + + interconnect-names: + maxItems: 2 + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + const: qcom,sm6150-dpu + + "^dsi@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + items: + - const: qcom,sm6150-dsi-ctrl + - const: qcom,mdss-dsi-ctrl + + "^phy@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + const: qcom,sm6150-dsi-phy-14nm + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/interconnect/qcom,icc.h> + #include <dt-bindings/interconnect/qcom,qcs615-rpmh.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom,rpmhpd.h> + + display-subsystem@ae00000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,sm6150-mdss"; + reg = <0x0ae00000 0x1000>; + reg-names = "mdss"; + + interconnects = <&mmss_noc MASTER_MDP0 QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY + &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>; + interconnect-names = "mdp0-mem", "cpu-cfg"; + + power-domains = <&dispcc_mdss_gdsc>; + + clocks = <&dispcc_mdss_ahb_clk>, + <&gcc_disp_hf_axi_clk>, + <&dispcc_mdss_mdp_clk>; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + iommus = <&apps_smmu 0x800 0x0>; + + ranges; + + display-controller@ae01000 { + compatible = "qcom,sm6150-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&dispcc_mdss_ahb_clk>, + <&gcc_disp_hf_axi_clk>, + <&dispcc_mdss_mdp_clk>, + <&dispcc_mdss_vsync_clk>; + clock-names = "iface", "bus", "core", "vsync"; + + assigned-clocks = <&dispcc_mdss_vsync_clk>; + assigned-clock-rates = <19200000>; + + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmhpd RPMHPD_CX>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf0_out: endpoint { + }; + }; + + port@1 { + reg = <1>; + dpu_intf1_out: endpoint { + remote-endpoint = <&mdss_dsi0_in>; + }; + }; + }; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-19200000 { + opp-hz = /bits/ 64 <19200000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-25600000 { + opp-hz = /bits/ 64 <25600000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-307200000 { + opp-hz = /bits/ 64 <307200000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + }; + + dsi@ae94000 { + compatible = "qcom,sm6150-dsi-ctrl", + "qcom,mdss-dsi-ctrl"; + reg = <0x0ae94000 0x400>; + reg-names = "dsi_ctrl"; + + interrupt-parent = <&mdss>; + interrupts = <4>; + + clocks = <&dispcc_mdss_byte0_clk>, + <&dispcc_mdss_byte0_intf_clk>, + <&dispcc_mdss_pclk0_clk>, + <&dispcc_mdss_esc0_clk>, + <&dispcc_mdss_ahb_clk>, + <&gcc_disp_hf_axi_clk>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + assigned-clocks = <&dispcc_mdss_byte0_clk_src>, + <&dispcc_mdss_pclk0_clk_src>; + assigned-clock-parents = <&mdss_dsi0_phy 0>, + <&mdss_dsi0_phy 1>; + + operating-points-v2 = <&dsi0_opp_table>; + + phys = <&mdss_dsi0_phy>; + + #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 { + }; + }; + }; + + dsi0_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-164000000 { + opp-hz = /bits/ 64 <164000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + }; + }; + + mdss_dsi0_phy: phy@ae94400 { + compatible = "qcom,sm6150-dsi-phy-14nm"; + reg = <0x0ae94400 0x100>, + <0x0ae94500 0x300>, + <0x0ae94800 0x188>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + clocks = <&dispcc_mdss_ahb_clk>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml index 5af2d6930075..fcb5834f799a 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -42,6 +42,8 @@ properties: # Admatec 9904379 10.1" 1024x600 LVDS panel - admatec,9904379 - auo,b101ew05 + # AUO G084SN05 V9 8.4" 800x600 LVDS panel + - auo,g084sn05 # Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel - chunghwa,claa070wp03xg # EDT ETML0700Z9NDHA 7.0" WSVGA (1024x600) color TFT LCD LVDS panel diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 18b63f356bb4..e3ee3a332bb7 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -206,12 +206,16 @@ properties: - mitsubishi,aa070mc01-ca1 # Mitsubishi AA084XE01 8.4" XGA TFT LCD panel - mitsubishi,aa084xe01 + # Multi-Inno Technology Co.,Ltd MI0700A2T-30 7" 800x480 TFT Resistive Touch Module + - multi-inno,mi0700a2t-30 # Multi-Inno Technology Co.,Ltd MI0700S4T-6 7" 800x480 TFT Resistive Touch Module - multi-inno,mi0700s4t-6 # Multi-Inno Technology Co.,Ltd MI0800FT-9 8" 800x600 TFT Resistive Touch Module - multi-inno,mi0800ft-9 # Multi-Inno Technology Co.,Ltd MI1010AIT-1CP 10.1" 1280x800 LVDS IPS Cap Touch Mod. - multi-inno,mi1010ait-1cp + # Multi-Inno Technology Co.,Ltd MI1010Z1T-1CP11 10.1" 1024x600 TFT Resistive Touch Module + - multi-inno,mi1010z1t-1cp11 # NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel - nec,nl12880bc20-05 # NEC LCD Technologies,Ltd. WQVGA TFT LCD panel @@ -280,10 +284,14 @@ properties: - team-source-display,tst043015cmhx # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel - tianma,tm070jdhg30 + # Tianma Micro-electronics TM070JDHG34-00 7.0" WXGA (1280x800) LVDS TFT LCD panel + - tianma,tm070jdhg34-00 # Tianma Micro-electronics TM070JVHG33 7.0" WXGA TFT LCD panel - tianma,tm070jvhg33 # Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel - tianma,tm070rvhg71 + # Topland TIAN-G07017-01 7.0" WSVGA TFT-LCD panel with capacitive touch + - topland,tian-g07017-01 # Toshiba 8.9" WXGA (1280x768) TFT LCD panel - toshiba,lt089ac29000 # TPK U.S.A. LLC Fusion 7" 800 x 480 (WVGA) LCD panel with capacitive touch diff --git a/Documentation/devicetree/bindings/display/panel/powertip,hx8238a.yaml b/Documentation/devicetree/bindings/display/panel/powertip,hx8238a.yaml new file mode 100644 index 000000000000..b7d74faeb5d5 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/powertip,hx8238a.yaml @@ -0,0 +1,29 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/powertip,hx8238a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Powertip Electronic Technology Co. 320 x 240 LCD panel + +maintainers: + - Lukasz Majewski <lukma@denx.de> + +allOf: + - $ref: panel-dpi.yaml# + +properties: + compatible: + items: + - const: powertip,hx8238a + - {} # panel-dpi, but not listed here to avoid false select + + height-mm: true + panel-timing: true + port: true + power-supply: true + width-mm: true + +additionalProperties: false + +... diff --git a/Documentation/devicetree/bindings/display/panel/powertip,st7272.yaml b/Documentation/devicetree/bindings/display/panel/powertip,st7272.yaml new file mode 100644 index 000000000000..f3622800f13f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/powertip,st7272.yaml @@ -0,0 +1,29 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/powertip,st7272.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Powertip Electronic Technology Co. 320 x 240 LCD panel + +maintainers: + - Lukasz Majewski <lukma@denx.de> + +allOf: + - $ref: panel-dpi.yaml# + +properties: + compatible: + items: + - const: powertip,st7272 + - {} # panel-dpi, but not listed here to avoid false select + + height-mm: true + panel-timing: true + port: true + power-supply: true + width-mm: true + +additionalProperties: false + +... diff --git a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml index 032f783eefc4..684c2896d238 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml @@ -23,6 +23,8 @@ properties: - samsung,atna45af01 # Samsung 14.5" 3K (2944x1840 pixels) eDP AMOLED panel - samsung,atna45dc02 + # Samsung 15.6" 3K (2880x1620 pixels) eDP AMOLED panel + - samsung,atna56ac03 - const: samsung,atna33xc20 enable-gpios: true diff --git a/Documentation/devicetree/bindings/display/renesas,cmm.yaml b/Documentation/devicetree/bindings/display/renesas,cmm.yaml index 561efaaa5a91..fc4933c343cd 100644 --- a/Documentation/devicetree/bindings/display/renesas,cmm.yaml +++ b/Documentation/devicetree/bindings/display/renesas,cmm.yaml @@ -58,10 +58,10 @@ examples: #include <dt-bindings/power/r8a7796-sysc.h> cmm0: cmm@fea40000 { - compatible = "renesas,r8a7796-cmm", - "renesas,rcar-gen3-cmm"; - reg = <0xfea40000 0x1000>; - power-domains = <&sysc R8A7796_PD_ALWAYS_ON>; - clocks = <&cpg CPG_MOD 711>; - resets = <&cpg 711>; + compatible = "renesas,r8a7796-cmm", + "renesas,rcar-gen3-cmm"; + reg = <0xfea40000 0x1000>; + power-domains = <&sysc R8A7796_PD_ALWAYS_ON>; + clocks = <&cpg CPG_MOD 711>; + resets = <&cpg 711>; }; diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index c5b9e6812bce..3880b4c2ea9a 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -41,6 +41,7 @@ properties: - renesas,du-r8a77995 # for R-Car D3 compatible DU - renesas,du-r8a779a0 # for R-Car V3U compatible DU - renesas,du-r8a779g0 # for R-Car V4H compatible DU + - renesas,du-r8a779h0 # for R-Car V4M compatible DU reg: maxItems: 1 @@ -69,14 +70,12 @@ properties: $ref: /schemas/graph.yaml#/properties/port unevaluatedProperties: false - required: - - port@0 - - port@1 - unevaluatedProperties: false renesas,cmms: $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 4 items: maxItems: 1 description: @@ -85,6 +84,8 @@ properties: renesas,vsps: $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 4 items: items: - description: phandle to VSP instance that serves the DU channel @@ -489,9 +490,11 @@ allOf: renesas,cmms: minItems: 4 + maxItems: 4 renesas,vsps: minItems: 4 + maxItems: 4 required: - clock-names @@ -558,9 +561,11 @@ allOf: renesas,cmms: minItems: 3 + maxItems: 3 renesas,vsps: minItems: 3 + maxItems: 3 required: - clock-names @@ -627,9 +632,11 @@ allOf: renesas,cmms: minItems: 3 + maxItems: 3 renesas,vsps: minItems: 3 + maxItems: 3 required: - clock-names @@ -683,7 +690,7 @@ allOf: - port@1 renesas,vsps: - minItems: 1 + maxItems: 1 required: - clock-names @@ -746,9 +753,11 @@ allOf: renesas,cmms: minItems: 2 + maxItems: 2 renesas,vsps: minItems: 2 + maxItems: 2 required: - clock-names @@ -799,6 +808,54 @@ allOf: renesas,vsps: minItems: 2 + maxItems: 2 + + required: + - clock-names + - interrupts + - resets + - reset-names + - renesas,vsps + + - if: + properties: + compatible: + contains: + enum: + - renesas,du-r8a779h0 + then: + properties: + clocks: + items: + - description: Functional clock + + clock-names: + items: + - const: du.0 + + interrupts: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + items: + - const: du.0 + + ports: + properties: + port@0: + description: DSI 0 + port@1: false + port@2: false + port@3: false + + required: + - port@0 + + renesas,vsps: + maxItems: 1 required: - clock-names diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-mipi-dsi2.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-mipi-dsi2.yaml new file mode 100644 index 000000000000..53384e47b507 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-mipi-dsi2.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/rockchip/rockchip,rk3588-mipi-dsi2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip specific extensions to the Synopsys Designware MIPI DSI2 + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + enum: + - rockchip,rk3588-mipi-dsi2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: pclk + - const: sys + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + This SoC uses GRF regs to switch between vopl/vopb. + + phys: + maxItems: 1 + + phy-names: + const: dcphy + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + const: apb + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input node to receive pixel data. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: DSI output node to panel. + + required: + - port@0 + - port@1 + +required: + - compatible + - clocks + - clock-names + - rockchip,grf + - phys + - phy-names + - ports + - reg + +allOf: + - $ref: /schemas/display/dsi-controller.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/rockchip,rk3588-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/phy/phy.h> + #include <dt-bindings/power/rk3588-power.h> + #include <dt-bindings/reset/rockchip,rk3588-cru.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + dsi@fde20000 { + compatible = "rockchip,rk3588-mipi-dsi2"; + reg = <0x0 0xfde20000 0x0 0x10000>; + interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&cru PCLK_DSIHOST0>, <&cru CLK_DSIHOST0>; + clock-names = "pclk", "sys"; + resets = <&cru SRST_P_DSIHOST0>; + reset-names = "apb"; + power-domains = <&power RK3588_PD_VOP>; + phys = <&mipidcphy0 PHY_TYPE_DPHY>; + phy-names = "dcphy"; + rockchip,grf = <&vop_grf>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + dsi0_in: port@0 { + reg = <0>; + }; + + dsi0_out: port@1 { + reg = <1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index 55e3e490d0e6..31c4ffcb599c 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -23,7 +23,7 @@ properties: compatible: enum: - ti,am625-dss - - ti,am62a7,dss + - ti,am62a7-dss - ti,am65x-dss reg: diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml index 554f9d5809d4..6b754d4f260e 100644 --- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml @@ -100,12 +100,16 @@ properties: - description: Video layer, plane 1 (U/V or U) - description: Video layer, plane 2 (V) - description: Graphics layer + - description: Audio channel 0 + - description: Audio channel 1 dma-names: items: - const: vid0 - const: vid1 - const: vid2 - const: gfx0 + - const: aud0 + - const: aud1 phys: description: PHYs for the DP data lanes @@ -194,11 +198,13 @@ examples: power-domains = <&pd_dp>; resets = <&reset ZYNQMP_RESET_DP>; - dma-names = "vid0", "vid1", "vid2", "gfx0"; + dma-names = "vid0", "vid1", "vid2", "gfx0", "aud0", "aud1"; dmas = <&xlnx_dpdma 0>, <&xlnx_dpdma 1>, <&xlnx_dpdma 2>, - <&xlnx_dpdma 3>; + <&xlnx_dpdma 3>, + <&xlnx_dpdma 4>, + <&xlnx_dpdma 5>; phys = <&psgtr 1 PHY_TYPE_DP 0 3>, <&psgtr 0 PHY_TYPE_DP 1 3>; diff --git a/Documentation/devicetree/bindings/dma/adi,axi-dmac.txt b/Documentation/devicetree/bindings/dma/adi,axi-dmac.txt deleted file mode 100644 index cd17684aaab5..000000000000 --- a/Documentation/devicetree/bindings/dma/adi,axi-dmac.txt +++ /dev/null @@ -1,61 +0,0 @@ -Analog Devices AXI-DMAC DMA controller - -Required properties: - - compatible: Must be "adi,axi-dmac-1.00.a". - - reg: Specification for the controllers memory mapped register map. - - interrupts: Specification for the controllers interrupt. - - clocks: Phandle and specifier to the controllers AXI interface clock - - #dma-cells: Must be 1. - -Required sub-nodes: - - adi,channels: This sub-node must contain a sub-node for each DMA channel. For - the channel sub-nodes the following bindings apply. They must match the - configuration options of the peripheral as it was instantiated. - -Required properties for adi,channels sub-node: - - #size-cells: Must be 0 - - #address-cells: Must be 1 - -Required channel sub-node properties: - - reg: Which channel this node refers to. - - adi,source-bus-width, - adi,destination-bus-width: Width of the source or destination bus in bits. - - adi,source-bus-type, - adi,destination-bus-type: Type of the source or destination bus. Must be one - of the following: - 0 (AXI_DMAC_TYPE_AXI_MM): Memory mapped AXI interface - 1 (AXI_DMAC_TYPE_AXI_STREAM): Streaming AXI interface - 2 (AXI_DMAC_TYPE_AXI_FIFO): FIFO interface - -Deprecated optional channel properties: - - adi,length-width: Width of the DMA transfer length register. - - adi,cyclic: Must be set if the channel supports hardware cyclic DMA - transfers. - - adi,2d: Must be set if the channel supports hardware 2D DMA transfers. - -DMA clients connected to the AXI-DMAC DMA controller must use the format -described in the dma.txt file using a one-cell specifier. The value of the -specifier refers to the DMA channel index. - -Example: - -dma: dma@7c420000 { - compatible = "adi,axi-dmac-1.00.a"; - reg = <0x7c420000 0x10000>; - interrupts = <0 57 0>; - clocks = <&clkc 16>; - #dma-cells = <1>; - - adi,channels { - #size-cells = <0>; - #address-cells = <1>; - - dma-channel@0 { - reg = <0>; - adi,source-bus-width = <32>; - adi,source-bus-type = <ADI_AXI_DMAC_TYPE_MM_AXI>; - adi,destination-bus-width = <64>; - adi,destination-bus-type = <ADI_AXI_DMAC_TYPE_FIFO>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/dma/adi,axi-dmac.yaml b/Documentation/devicetree/bindings/dma/adi,axi-dmac.yaml new file mode 100644 index 000000000000..63b6fb0423c2 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/adi,axi-dmac.yaml @@ -0,0 +1,129 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/adi,axi-dmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AXI-DMAC DMA controller + +description: | + FPGA-based DMA controller designed for use with high-speed converter hardware. + + http://analogdevicesinc.github.io/hdl/library/axi_dmac/index.html + +maintainers: + - Nuno Sa <nuno.sa@analog.com> + +additionalProperties: false + +properties: + compatible: + const: adi,axi-dmac-1.00.a + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + "#dma-cells": + const: 1 + + adi,channels: + deprecated: true + type: object + description: + This sub-node must contain a sub-node for each DMA channel. This node is + only required for IP versions older than 4.3.a and should otherwise be + omitted. + additionalProperties: false + + properties: + "#size-cells": + const: 0 + "#address-cells": + const: 1 + + patternProperties: + "^dma-channel@[0-9a-f]+$": + type: object + description: + DMA channel properties based on HDL compile-time configuration. + additionalProperties: false + + properties: + reg: + maxItems: 1 + + adi,source-bus-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Width of the source bus in bits. + enum: [8, 16, 32, 64, 128] + + adi,destination-bus-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Width of the destination bus in bits. + enum: [8, 16, 32, 64, 128] + + adi,source-bus-type: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Type of the source bus. + + 0: Memory mapped AXI interface + 1: Streaming AXI interface + 2: FIFO interface + enum: [0, 1, 2] + + adi,destination-bus-type: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Type of the destination bus (see adi,source-bus-type). + enum: [0, 1, 2] + + adi,length-width: + deprecated: true + $ref: /schemas/types.yaml#/definitions/uint32 + description: Width of the DMA transfer length register. + + adi,cyclic: + deprecated: true + type: boolean + description: + Must be set if the channel supports hardware cyclic DMA transfers. + + adi,2d: + deprecated: true + type: boolean + description: + Must be set if the channel supports hardware 2D DMA transfers. + + required: + - reg + - adi,source-bus-width + - adi,destination-bus-width + - adi,source-bus-type + - adi,destination-bus-type + + required: + - "#size-cells" + - "#address-cells" + +required: + - compatible + - reg + - interrupts + - clocks + - "#dma-cells" + +examples: + - | + dma-controller@7c420000 { + compatible = "adi,axi-dmac-1.00.a"; + reg = <0x7c420000 0x10000>; + interrupts = <0 57 0>; + clocks = <&clkc 16>; + #dma-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml index 02d5bd035409..9b5180c0a7c4 100644 --- a/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml +++ b/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml @@ -22,7 +22,9 @@ properties: number. compatible: - const: allwinner,sun4i-a10-dma + enum: + - allwinner,sun4i-a10-dma + - allwinner,suniv-f1c100s-dma reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/dma/atmel,sama5d4-dma.yaml b/Documentation/devicetree/bindings/dma/atmel,sama5d4-dma.yaml new file mode 100644 index 000000000000..9ca1c5d1f00f --- /dev/null +++ b/Documentation/devicetree/bindings/dma/atmel,sama5d4-dma.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/atmel,sama5d4-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip AT91 Extensible Direct Memory Access Controller + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Charan Pedumuru <charan.pedumuru@microchip.com> + +description: + The DMA Controller (XDMAC) is a AHB-protocol central direct memory access + controller. It performs peripheral data transfer and memory move operations + over one or two bus ports through the unidirectional communication + channel. Each channel is fully programmable and provides both peripheral + or memory-to-memory transfers. The channel features are configurable at + implementation. + +allOf: + - $ref: dma-controller.yaml# + +properties: + compatible: + oneOf: + - enum: + - atmel,sama5d4-dma + - microchip,sama7g5-dma + - items: + - enum: + - microchip,sam9x60-dma + - microchip,sam9x7-dma + - const: atmel,sama5d4-dma + + "#dma-cells": + description: | + Represents the number of integer cells in the `dmas` property of client + devices. The single cell specifies the channel configuration register: + - bit 13: SIF (Source Interface Identifier) for memory interface. + - bit 14: DIF (Destination Interface Identifier) for peripheral interface. + - bit 30-24: PERID (Peripheral Identifier). + const: 1 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: dma_clk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - "#dma-cells" + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/dma/at91.h> + #include <dt-bindings/interrupt-controller/irq.h> + dma-controller@f0008000 { + compatible = "atmel,sama5d4-dma"; + reg = <0xf0008000 0x1000>; + interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>; + #dma-cells = <1>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 20>; + clock-names = "dma_clk"; + }; diff --git a/Documentation/devicetree/bindings/dma/atmel-xdma.txt b/Documentation/devicetree/bindings/dma/atmel-xdma.txt deleted file mode 100644 index 76d649b3a25d..000000000000 --- a/Documentation/devicetree/bindings/dma/atmel-xdma.txt +++ /dev/null @@ -1,54 +0,0 @@ -* Atmel Extensible Direct Memory Access Controller (XDMAC) - -* XDMA Controller -Required properties: -- compatible: Should be "atmel,sama5d4-dma", "microchip,sam9x60-dma" or - "microchip,sama7g5-dma" or - "microchip,sam9x7-dma", "atmel,sama5d4-dma". -- reg: Should contain DMA registers location and length. -- interrupts: Should contain DMA interrupt. -- #dma-cells: Must be <1>, used to represent the number of integer cells in -the dmas property of client devices. - - The 1st cell specifies the channel configuration register: - - bit 13: SIF, source interface identifier, used to get the memory - interface identifier, - - bit 14: DIF, destination interface identifier, used to get the peripheral - interface identifier, - - bit 30-24: PERID, peripheral identifier. - -Example: - -dma1: dma-controller@f0004000 { - compatible = "atmel,sama5d4-dma"; - reg = <0xf0004000 0x200>; - interrupts = <50 4 0>; - #dma-cells = <1>; -}; - - -* DMA clients -DMA clients connected to the Atmel XDMA controller must use the format -described in the dma.txt file, using a one-cell specifier for each channel. -The two cells in order are: -1. A phandle pointing to the DMA controller. -2. Channel configuration register. Configurable fields are: - - bit 13: SIF, source interface identifier, used to get the memory - interface identifier, - - bit 14: DIF, destination interface identifier, used to get the peripheral - interface identifier, - - bit 30-24: PERID, peripheral identifier. - -Example: - -i2c2: i2c@f8024000 { - compatible = "atmel,at91sam9x5-i2c"; - reg = <0xf8024000 0x4000>; - interrupts = <34 4 6>; - dmas = <&dma1 - (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) - | AT91_XDMAC_DT_PERID(6))>, - <&dma1 - (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) - | AT91_XDMAC_DT_PERID(7))>; - dma-names = "tx", "rx"; -}; diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml index d54140f18d34..4f925469533e 100644 --- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml +++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml @@ -26,9 +26,13 @@ properties: - fsl,imx93-edma3 - fsl,imx93-edma4 - fsl,imx95-edma5 + - nxp,s32g2-edma - items: - const: fsl,ls1028a-edma - const: fsl,vf610-edma + - items: + - const: nxp,s32g3-edma + - const: nxp,s32g2-edma reg: minItems: 1 @@ -221,6 +225,36 @@ allOf: properties: power-domains: false + - if: + properties: + compatible: + contains: + const: nxp,s32g2-edma + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: dmamux0 + - const: dmamux1 + interrupts: + minItems: 3 + maxItems: 3 + interrupt-names: + items: + - const: tx-0-15 + - const: tx-16-31 + - const: err + reg: + minItems: 3 + maxItems: 3 + "#dma-cells": + const: 2 + dma-channels: + const: 32 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml index 877147e95ecc..d3f8c269916c 100644 --- a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml @@ -13,9 +13,6 @@ description: | maintainers: - Jon Hunter <jonathanh@nvidia.com> -allOf: - - $ref: dma-controller.yaml# - properties: compatible: oneOf: @@ -29,7 +26,19 @@ properties: - const: nvidia,tegra186-adma reg: - maxItems: 1 + description: + The 'page' region describes the address space of the page + used for accessing the DMA channel registers. The 'global' + region describes the address space of the global DMA registers. + In the absence of the 'reg-names' property, there must be a + single entry that covers the address space of the global DMA + registers and the DMA channel registers. + minItems: 1 + maxItems: 2 + + reg-names: + minItems: 1 + maxItems: 2 interrupts: description: | @@ -63,6 +72,49 @@ required: - clocks - clock-names +allOf: + - $ref: dma-controller.yaml# + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra210-adma + then: + properties: + reg: + items: + - description: Full address space range of DMA registers. + + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra186-adma + then: + anyOf: + - properties: + reg: + items: + - description: Full address space range of DMA registers. + - properties: + reg: + items: + - description: Channel Page address space range of DMA registers. + reg-names: + items: + - const: page + - properties: + reg: + items: + - description: Channel Page address space range of DMA registers. + - description: Global Page address space range of DMA registers. + reg-names: + items: + - const: page + - const: global + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml index 4ad56a409b9c..7052468b15c8 100644 --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -25,7 +25,9 @@ properties: - items: - enum: - qcom,qcm2290-gpi-dma + - qcom,qcs8300-gpi-dma - qcom,qdu1000-gpi-dma + - qcom,sa8775p-gpi-dma - qcom,sar2130p-gpi-dma - qcom,sc7280-gpi-dma - qcom,sdx75-gpi-dma @@ -35,10 +37,12 @@ properties: - qcom,sm8450-gpi-dma - qcom,sm8550-gpi-dma - qcom,sm8650-gpi-dma + - qcom,sm8750-gpi-dma - qcom,x1e80100-gpi-dma - const: qcom,sm6350-gpi-dma - items: - enum: + - qcom,qcs615-gpi-dma - qcom,sdm670-gpi-dma - qcom,sm6125-gpi-dma - qcom,sm8150-gpi-dma diff --git a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dmamux.yaml index f26c914a3a9a..b7bca1a83769 100644 --- a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dmamux.yaml +++ b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dmamux.yaml @@ -15,6 +15,16 @@ allOf: properties: "#dma-cells": const: 3 + description: | + Each cell represents the following: + 1. The mux input number/line for the request + 2. Bitfield representing DMA channel configuration that is passed + to the real DMA controller + 3. Bitfield representing device dependent DMA features passed to + the real DMA controller + + For bitfield definitions of cells 2 and 3, see the associated + bindings doc for the actual DMA controller in st,stm32-dma.yaml. compatible: const: st,stm32h7-dmamux diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml index 27b8e1636560..b5bc842c5a0e 100644 --- a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml +++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml @@ -34,6 +34,7 @@ properties: - ti,am62a-dmss-bcdma-csirx - ti,am64-dmss-bcdma - ti,j721s2-dmss-bcdma-csi + - ti,j722s-dmss-bcdma-csi reg: minItems: 3 @@ -196,7 +197,9 @@ allOf: properties: compatible: contains: - const: ti,j721s2-dmss-bcdma-csi + enum: + - ti,j721s2-dmss-bcdma-csi + - ti,j722s-dmss-bcdma-csi then: properties: ti,sci-rm-range-bchan: false diff --git a/Documentation/devicetree/bindings/dts-coding-style.rst b/Documentation/devicetree/bindings/dts-coding-style.rst index 8a68331075a0..4772ded8a987 100644 --- a/Documentation/devicetree/bindings/dts-coding-style.rst +++ b/Documentation/devicetree/bindings/dts-coding-style.rst @@ -162,14 +162,17 @@ Example:: status = "okay"; } -Indentation ------------ +Indentation and wrapping +------------------------ -1. Use indentation according to Documentation/process/coding-style.rst. +1. Use indentation and wrap lines according to + Documentation/process/coding-style.rst. 2. Each entry in arrays with multiple cells, e.g. "reg" with two IO addresses, shall be enclosed in <>. -3. For arrays spanning across lines, it is preferred to align the continued - entries with opening < from the first line. +3. For arrays spanning across lines, it is preferred to split on item boundary + and align the continued entries with opening < from the first line. + Usually avoid splitting individual items unless they significantly exceed + line wrap limit. Example:: @@ -177,6 +180,9 @@ Example:: compatible = "qcom,sm8550-tsens", "qcom,tsens-v2"; reg = <0x0 0x0c271000 0x0 0x1000>, <0x0 0x0c222000 0x0 0x1000>; + /* Lines exceeding coding style line wrap limit: */ + interconnects = <&aggre1_noc MASTER_USB3_0 0 &mc_virt SLAVE_EBI1 0>, + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_USB3_0 0>; }; Organizing DTSI and DTS diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml index 590ba0ef5fa2..c9e4afbdc448 100644 --- a/Documentation/devicetree/bindings/eeprom/at24.yaml +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml @@ -134,10 +134,15 @@ properties: - const: atmel,24c64 - items: - enum: + - giantec,gt24p128f - renesas,r1ex24128 - samsung,s524ad0xd1 - const: atmel,24c128 - items: + - enum: + - puya,p24c256c + - const: atmel,24c256 + - items: - const: microchip,24aa025e48 - items: - const: microchip,24aa025e64 diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml index 2ee030000007..8cdaac8011ba 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml @@ -26,6 +26,7 @@ properties: - qcom,scm-ipq4019 - qcom,scm-ipq5018 - qcom,scm-ipq5332 + - qcom,scm-ipq5424 - qcom,scm-ipq6018 - qcom,scm-ipq806x - qcom,scm-ipq8074 @@ -42,6 +43,7 @@ properties: - qcom,scm-msm8996 - qcom,scm-msm8998 - qcom,scm-qcm2290 + - qcom,scm-qcs615 - qcom,scm-qcs8300 - qcom,scm-qdu1000 - qcom,scm-sa8255p diff --git a/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml b/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml new file mode 100644 index 000000000000..bbc183200400 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/thead,th1520-aon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: T-HEAD TH1520 AON (Always-On) Firmware + +description: | + The Always-On (AON) subsystem in the TH1520 SoC is responsible for managing + low-power states, system wakeup events, and power management tasks. It is + designed to operate independently in a dedicated power domain, allowing it to + remain functional even during the SoC's deep sleep states. + + At the heart of the AON subsystem is the E902, a low-power core that executes + firmware responsible for coordinating tasks such as power domain control, + clock management, and system wakeup signaling. Communication between the main + SoC and the AON subsystem is handled through a mailbox interface, which + enables message-based interactions with the AON firmware. + +maintainers: + - Michal Wilczynski <m.wilczynski@samsung.com> + +properties: + compatible: + const: thead,th1520-aon + + mboxes: + maxItems: 1 + + mbox-names: + items: + - const: aon + + "#power-domain-cells": + const: 1 + +required: + - compatible + - mboxes + - mbox-names + - "#power-domain-cells" + +additionalProperties: false + +examples: + - | + aon: aon { + compatible = "thead,th1520-aon"; + mboxes = <&mbox_910t 1>; + mbox-names = "aon"; + #power-domain-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml b/Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml index b9afd07a9d24..b16273e69dfe 100644 --- a/Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml @@ -46,6 +46,12 @@ properties: minimum: 12 maximum: 232 +patternProperties: + "-hog(-[0-9]+)?$": + type: object + required: + - gpio-hog + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml index f096f286da19..fbd69b4cecc7 100644 --- a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml @@ -64,6 +64,10 @@ properties: gpio-ranges: true + gpio-line-names: + minItems: 1 + maxItems: 128 + wakeup-source: type: boolean description: > diff --git a/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml b/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml index e8bc9f018edb..0e5c22929bde 100644 --- a/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml +++ b/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml @@ -6,6 +6,23 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Generic 8-bit shift register +description: | + NOTE: These chips nominally don't have a chip select pin. They do however + have a rising-edge triggered latch clock (or storage register clock) pin, + which behaves like an active-low chip select. + + After the bits are shifted into the shift register, CS# is driven high, which + the 74HC595 sees as a rising edge on the latch clock that results in a + transfer of the bits from the shift register to the storage register and thus + to the output pins. + _ _ _ _ + shift clock ____| |_| |_..._| |_| |_________ + + latch clock * trigger + ___ ________ + chip select# |___________________| + + maintainers: - Maxime Ripard <mripard@kernel.org> diff --git a/Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml index 84fd82291ee4..f1b60ab3f356 100644 --- a/Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml @@ -15,6 +15,7 @@ properties: - enum: - fsl,mpc5121-gpio - fsl,mpc5125-gpio + - fsl,mpc8314-gpio - fsl,mpc8349-gpio - fsl,mpc8572-gpio - fsl,mpc8610-gpio diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml b/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml index 33d4e4716516..7ed5f9c4dde9 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml @@ -72,6 +72,9 @@ properties: "#gpio-cells": const: 2 + gpio-ranges: + maxItems: 1 + marvell,pwm-offset: $ref: /schemas/types.yaml#/definitions/uint32 description: Offset in the register map for the pwm registers (in bytes) @@ -96,6 +99,13 @@ properties: - const: axi minItems: 1 +patternProperties: + "^(.+-hog(-[0-9]+)?)$": + type: object + + required: + - gpio-hog + required: - compatible - gpio-controller diff --git a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml index cabda2eab4a2..4fb32e9aec0a 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml @@ -28,6 +28,7 @@ properties: - items: - enum: - fsl,imx93-gpio + - fsl,imx94-gpio - fsl,imx95-gpio - const: fsl,imx8ulp-gpio diff --git a/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml index cf3b1b270aa8..b68159600e2b 100644 --- a/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml @@ -20,7 +20,10 @@ properties: - loongson,ls2k2000-gpio1 - loongson,ls2k2000-gpio2 - loongson,ls3a5000-gpio + - loongson,ls3a6000-gpio # Loongson-3A6000 node GPIO - loongson,ls7a-gpio + - loongson,ls7a2000-gpio1 # LS7A2000 chipset GPIO + - loongson,ls7a2000-gpio2 # LS7A2000 ACPI GPIO - items: - const: loongson,ls2k1000-gpio - const: loongson,ls2k-gpio diff --git a/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml index 3718103e966a..8bca574bb66d 100644 --- a/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml +++ b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml @@ -73,6 +73,43 @@ properties: wakeup-source: true + reset-gpios: + maxItems: 1 + description: + GPIO controlling the (reset active LOW) RESET# pin. + + The active polarity of the GPIO must translate to the low state of the + RESET# pin on the IC, i.e. if a GPIO is directly routed to the RESET# pin + without any inverter, GPIO_ACTIVE_LOW is expected. + + Performing a reset makes all lines initialized to their input (pulled-up) + state. + +allOf: + - if: + properties: + compatible: + not: + contains: + enum: + - nxp,pca9670 + - nxp,pca9671 + - nxp,pca9672 + - nxp,pca9673 + then: + properties: + reset-gpios: false + + # lines-initial-states XOR reset-gpios + # Performing a reset reinitializes all lines to a known state which + # may not match passed lines-initial-states + - if: + required: + - lines-initial-states + then: + properties: + reset-gpios: false + patternProperties: "^(.+-hog(-[0-9]+)?)$": type: object diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml index abd4aa335fbc..9318817ea135 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml @@ -33,6 +33,7 @@ properties: - rockchip,rk3188-mali - rockchip,rk3228-mali - samsung,exynos4210-mali + - st,stih410-mali - stericsson,db8500-mali - xlnx,zynqmp-mali - const: arm,mali-400 diff --git a/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml b/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml index ce7f8ce9da0a..236d8b52ef85 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/adi,ad741x.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml index 5b076d677395..ddb72857c846 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/adi,adm1275.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# @@ -24,6 +23,7 @@ properties: enum: - adi,adm1075 - adi,adm1272 + - adi,adm1273 - adi,adm1275 - adi,adm1276 - adi,adm1278 @@ -79,6 +79,7 @@ allOf: contains: enum: - adi,adm1272 + - adi,adm1273 then: properties: adi,volt-curr-sample-average: diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml index 011e5b65c79c..1ff44cb22ef4 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/adi,ltc2991.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml index 7f30cfc87350..4faebbb4c7ab 100644 --- a/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml +++ b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml @@ -23,6 +23,9 @@ properties: alarm-gpios: maxItems: 1 + fan-supply: + description: Power supply for fan + gpio-fan,speed-map: $ref: /schemas/types.yaml#/definitions/uint32-matrix minItems: 2 diff --git a/Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml b/Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml index 37e1dc9c7dd3..aa801ef1640b 100644 --- a/Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml +++ b/Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml @@ -12,6 +12,8 @@ maintainers: properties: compatible: enum: + - lltc,lt7170 + - lltc,lt7171 - lltc,ltc2972 - lltc,ltc2974 - lltc,ltc2975 @@ -30,6 +32,7 @@ properties: - lltc,ltc7880 - lltc,ltm2987 - lltc,ltm4664 + - lltc,ltm4673 - lltc,ltm4675 - lltc,ltm4676 - lltc,ltm4677 @@ -46,6 +49,7 @@ properties: description: | list of regulators provided by this controller. Valid names of regulators depend on number of supplies supported per device: + * lt7170, lt7171 : vout0 * ltc2972 vout0 - vout1 * ltc2974, ltc2975 : vout0 - vout3 * ltc2977, ltc2979, ltc2980, ltm2987 : vout0 - vout7 @@ -55,6 +59,7 @@ properties: * ltc7880 : vout0 - vout1 * ltc3883 : vout0 * ltm4664 : vout0 - vout1 + * ltm4673 : vout0 - vout3 * ltm4675, ltm4676, ltm4677, ltm4678 : vout0 - vout1 * ltm4680, ltm4686 : vout0 - vout1 * ltm4700 : vout0 - vout1 diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml b/Documentation/devicetree/bindings/hwmon/lm75.yaml index 29bd7460cc26..c38255243f57 100644 --- a/Documentation/devicetree/bindings/hwmon/lm75.yaml +++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml @@ -28,6 +28,7 @@ properties: - maxim,max31725 - maxim,max31726 - maxim,mcp980x + - nxp,p3t1755 - nxp,pct2075 - st,stds75 - st,stlm75 diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml index 93e86e3b4602..8af0d7458e62 100644 --- a/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml +++ b/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/maxim,max20730.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml index 4f5837a30773..139a95e00fe5 100644 --- a/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml +++ b/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/maxim,max6639.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml index 2c26104a5e16..24c7697fdc1a 100644 --- a/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml +++ b/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/maxim,max6650.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml new file mode 100644 index 000000000000..d3f06ebc19fa --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml @@ -0,0 +1,111 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/microchip,emc2305.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip EMC2305 SMBus compliant PWM fan controller + +maintainers: + - Michael Shych <michaelsh@nvidia.com> + +description: + Microchip EMC2301/2/3/5 pwm controller which supports up to five programmable + fan control circuits. + +properties: + compatible: + oneOf: + - enum: + - microchip,emc2305 + - items: + - enum: + - microchip,emc2303 + - microchip,emc2302 + - microchip,emc2301 + - const: microchip,emc2305 + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + '#pwm-cells': + const: 3 + description: | + Number of cells in a PWM specifier. + - cell 0: The PWM frequency + - cell 1: The PWM polarity: 0 or PWM_POLARITY_INVERTED + - cell 2: The PWM output config: + - 0 (Open-Drain) + - 1 (Push-Pull) + +patternProperties: + '^fan@[0-4]$': + $ref: fan-common.yaml# + unevaluatedProperties: false + properties: + reg: + description: + The fan number used to determine the associated PWM channel. + maxItems: 1 + + required: + - reg + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pwm/pwm.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + fan_controller: fan-controller@2f { + compatible = "microchip,emc2305"; + reg = <0x2f>; + #address-cells = <1>; + #size-cells = <0>; + #pwm-cells = <3>; + + fan@0 { + reg = <0x0>; + pwms = <&fan_controller 26000 PWM_POLARITY_INVERTED 1>; + #cooling-cells = <2>; + }; + + fan@1 { + reg = <0x1>; + pwms = <&fan_controller 26000 0 1>; + #cooling-cells = <2>; + }; + + fan@2 { + reg = <0x2>; + pwms = <&fan_controller 26000 0 1>; + #cooling-cells = <2>; + }; + + fan@3 { + reg = <0x3>; + pwms = <&fan_controller 26000 0 1>; + #cooling-cells = <2>; + }; + + fan@4 { + reg = <0x4>; + pwms = <&fan_controller 26000 0 1>; + #cooling-cells = <2>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml index 6e59c8fdef30..4feb76919404 100644 --- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml @@ -32,6 +32,9 @@ properties: - national,lm89 - national,lm90 - national,lm99 + - nuvoton,nct7716 + - nuvoton,nct7717 + - nuvoton,nct7718 - nxp,sa56004 - onnn,nct1008 - ti,tmp451 @@ -120,6 +123,8 @@ allOf: - dallas,max6659 - dallas,max6695 - dallas,max6696 + - nuvoton,nct7716 + - nuvoton,nct7717 then: patternProperties: "^channel@([0-2])$": @@ -155,6 +160,7 @@ allOf: - national,lm89 - national,lm90 - national,lm99 + - nuvoton,nct7718 - nxp,sa56004 - winbond,w83l771 then: diff --git a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml index 3d0146e20d3e..b8e500e6cd9f 100644 --- a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml +++ b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml @@ -76,7 +76,7 @@ properties: - const: murata,ncp03wf104 - const: murata,ncp15xh103 - const: samsung,1404-001221 - # Deprecated "ntp," compatible strings + # Deprecated "ntc," compatible strings - const: ntc,ncp15wb473 deprecated: true - const: ntc,ncp18wb473 diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml index e3db642878d4..244470282890 100644 --- a/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml +++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/nuvoton,nct6775.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml index c1e5dedc2f6a..625fcf5d3b54 100644 --- a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml +++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/nuvoton,nct7363.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml index cd8dcd797031..c16a33227e94 100644 --- a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml +++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/nuvoton,nct7802.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml index e8feee38c76c..f8bea1c0e94a 100644 --- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml @@ -28,6 +28,15 @@ properties: reg: maxItems: 1 + gpio-controller: true + + gpio-line-names: + minItems: 84 + maxItems: 84 + + '#gpio-cells': + const: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml b/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml index a32035409cee..78e3d97e2ae5 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,adc128d818.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml b/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml index 926be9a29044..fb80456120e1 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,ads7828.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml index 05a9cb36cd82..bc03781342c0 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,ina2xx.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# @@ -27,6 +26,7 @@ properties: - ti,ina226 - ti,ina230 - ti,ina231 + - ti,ina233 - ti,ina237 - ti,ina238 - ti,ina260 @@ -75,12 +75,41 @@ properties: the alert polarity to active-high. $ref: /schemas/types.yaml#/definitions/flag + ti,maximum-expected-current-microamp: + description: | + This value indicates the maximum current in microamps that you can + expect to measure with ina233 in your circuit. + + This value will be used to calculate the Current_LSB and current/power + coefficient for the pmbus and to calibrate the IC. + minimum: 32768 + maximum: 4294967295 + default: 32768000 + required: - compatible - reg allOf: - $ref: hwmon-common.yaml# + - if: + properties: + compatible: + contains: + enum: + - silergy,sy24655 + - ti,ina209 + - ti,ina219 + - ti,ina220 + - ti,ina226 + - ti,ina230 + - ti,ina231 + - ti,ina237 + - ti,ina238 + - ti,ina260 + then: + properties: + ti,maximum-expected-current-microamp: false unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml b/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml index f553235a7321..63d8cf467806 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,lm87.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml index 227858e76058..cba5b4a1b81f 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,tmp513.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml index f58248c29e22..ee7de53e1918 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,tps23861.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml b/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml index 31ce77a4b087..6971ecb314eb 100644 --- a/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml +++ b/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/winbond,w83781d.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml index cc8bba5537b9..70cc2ee9ee27 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml @@ -25,6 +25,7 @@ properties: - samsung,exynos5250-hsi2c # Exynos5250 and Exynos5420 - samsung,exynos5260-hsi2c # Exynos5260 - samsung,exynos7-hsi2c # Exynos7 + - samsung,exynos8895-hsi2c - samsung,exynosautov9-hsi2c - items: - enum: diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml index ef26ba6eda28..73144473b9b2 100644 --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml @@ -34,6 +34,7 @@ properties: - qcom,sm8450-cci - qcom,sm8550-cci - qcom,sm8650-cci + - qcom,x1e80100-cci - const: qcom,msm8996-cci # CCI v2 "#address-cells": @@ -224,6 +225,7 @@ allOf: enum: - qcom,sm8550-cci - qcom,sm8650-cci + - qcom,x1e80100-cci then: properties: clocks: diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml index 505a8ec92266..1b7fed232642 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -26,7 +26,9 @@ properties: - const: renesas,riic-rz # RZ/A or RZ/G2L - items: - - const: renesas,riic-r9a08g045 # RZ/G3S + - enum: + - renesas,riic-r9a08g045 # RZ/G3S + - renesas,riic-r9a09g047 # RZ/G3E - const: renesas,riic-r9a09g057 # RZ/V2H(P) - const: renesas,riic-r9a09g057 # RZ/V2H(P) @@ -89,6 +91,7 @@ if: - renesas,riic-r9a07g043 - renesas,riic-r9a07g044 - renesas,riic-r9a07g054 + - renesas,riic-r9a09g057 then: required: - resets diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml index 280ed479ef5a..84d949392012 100644 --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml @@ -37,10 +37,17 @@ properties: interrupts: maxItems: 1 + interrupt-names: + items: + - enum: [INT1, INT2] + +dependencies: + interrupts: [ interrupt-names ] + interrupt-names: [ interrupts ] + required: - compatible - reg - - interrupts allOf: - $ref: /schemas/spi/spi-peripheral-props.yaml# @@ -61,6 +68,7 @@ examples: reg = <0x2a>; interrupt-parent = <&gpio0>; interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "INT1"; }; }; - | @@ -79,5 +87,6 @@ examples: spi-cpha; interrupt-parent = <&gpio0>; interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "INT2"; }; }; diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml index 66ea894dbe55..f07c70e51c45 100644 --- a/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml +++ b/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml @@ -4,23 +4,26 @@ $id: http://devicetree.org/schemas/iio/accel/kionix,kx022a.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: ROHM/Kionix KX022A, KX132-1211 and KX132ACR-LBZ Accelerometers +title: ROHM/Kionix KX022A, KX132/134-1211 and KX132/134ACR-LBZ Accelerometers maintainers: - Matti Vaittinen <mazziesaccount@gmail.com> description: | KX022A, KX132ACR-LBZ and KX132-1211 are 3-axis accelerometers supporting - +/- 2G, 4G, 8G and 16G ranges, variable output data-rates and a - hardware-fifo buffering. These accelerometers can be accessed either - via I2C or SPI. + +/- 2G, 4G, 8G and 16G ranges. The KX134ACR-LBZ and KX134-1211 support + +/- 8G, 16G, 32G and 64G. All the sensors also have variable output + data-rates and a hardware-fifo buffering. These accelerometers can be + accessed either via I2C or SPI. properties: compatible: enum: - kionix,kx022a - kionix,kx132-1211 + - kionix,kx134-1211 - rohm,kx132acr-lbz + - rohm,kx134acr-lbz reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml b/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml index 783c7ddfcd90..c175f4c4cbdb 100644 --- a/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml +++ b/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml @@ -14,12 +14,20 @@ description: | SPI and I2C interface. https://www.nxp.com/docs/en/data-sheet/FXLS8962AF.pdf https://www.nxp.com/docs/en/data-sheet/FXLS8964AF.pdf + https://www.nxp.com/docs/en/data-sheet/FXLS8967AF.pdf + https://www.nxp.com/docs/en/data-sheet/FXLS8974CF.pdf properties: compatible: - enum: - - nxp,fxls8962af - - nxp,fxls8964af + oneOf: + - enum: + - nxp,fxls8962af + - nxp,fxls8964af + - items: + - enum: + - nxp,fxls8967af + - nxp,fxls8974cf + - const: nxp,fxls8962af reg: maxItems: 1 @@ -38,6 +46,11 @@ properties: drive-open-drain: type: boolean + wakeup-source: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable wake on accelerometer event + required: - compatible - reg @@ -61,6 +74,7 @@ examples: interrupt-parent = <&gpio0>; interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "INT1"; + wakeup-source; }; }; - | diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml index e413a9d8d2a2..96e01a97dd95 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml @@ -19,49 +19,82 @@ description: | https://www.analog.com/media/en/technical-documentation/data-sheets/ad4020-4021-4022.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/adaq4001.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/adaq4003.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7685.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7686.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7687.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7688.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7690.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7691.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7693.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7942.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7946.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7980.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7982.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7983.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7984.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7988-1_7988-5.pdf $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: oneOf: - - const: adi,ad4000 + - enum: + - adi,ad4000 + - adi,ad4001 + - adi,ad4002 + - adi,ad4003 + - adi,ad4020 + - adi,adaq4001 + - adi,adaq4003 + - adi,ad7687 + - adi,ad7691 + - adi,ad7942 + - adi,ad7946 + - adi,ad7983 - items: - enum: - adi,ad4004 - adi,ad4008 - const: adi,ad4000 - - - const: adi,ad4001 - items: - enum: - adi,ad4005 - const: adi,ad4001 - - - const: adi,ad4002 - items: - enum: - adi,ad4006 - adi,ad4010 - const: adi,ad4002 - - - const: adi,ad4003 - items: - enum: - adi,ad4007 - adi,ad4011 - const: adi,ad4003 - - - const: adi,ad4020 - items: - enum: - adi,ad4021 - adi,ad4022 - const: adi,ad4020 - - - const: adi,adaq4001 - - - const: adi,adaq4003 + - items: + - enum: + - adi,ad7685 + - adi,ad7686 + - adi,ad7980 + - adi,ad7988-1 + - adi,ad7988-5 + - const: adi,ad7983 + - items: + - enum: + - adi,ad7688 + - adi,ad7693 + - const: adi,ad7687 + - items: + - enum: + - adi,ad7690 + - adi,ad7982 + - adi,ad7984 + - const: adi,ad7691 reg: maxItems: 1 @@ -133,6 +166,22 @@ required: - ref-supply allOf: + # Single-channel PulSAR devices have SDI either tied to VIO, GND, or host CS. + - if: + properties: + compatible: + contains: + enum: + - adi,ad7687 + - adi,ad7691 + - adi,ad7942 + - adi,ad7946 + - adi,ad7983 + then: + properties: + adi,sdi-pin: + enum: [ high, low, cs ] + default: cs # The configuration register can only be accessed if SDI is connected to MOSI - if: required: diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml index 310f046e139f..7d2229dee444 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml @@ -134,8 +134,9 @@ patternProperties: description: Describes the common mode channel for single channels. 0xFF is REFGND and OxFE is COM. Macros are available for these values in - dt-bindings/iio/adi,ad4695.h. Values 1 to 15 correspond to INx inputs. - Only odd numbered INx inputs can be used as common mode channels. + dt-bindings/iio/adc/adi,ad4695.h. Values 1 to 15 correspond to INx + inputs. Only odd numbered INx inputs can be used as common mode + channels. enum: [1, 3, 5, 7, 9, 11, 13, 15, 0xFE, 0xFF] default: 0xFF @@ -209,7 +210,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> - #include <dt-bindings/iio/adi,ad4695.h> + #include <dt-bindings/iio/adc/adi,ad4695.h> spi { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml index 35ed04350e28..7146a654ae38 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml @@ -37,6 +37,17 @@ properties: description: IRQ line for the ADC maxItems: 1 + rdy-gpios: + description: + GPIO reading the R̅D̅Y̅ line. Having such a GPIO is technically optional but + highly recommended because DOUT/R̅D̅Y̅ toggles during SPI transfers (in its + DOUT aka MISO role) and so usually triggers a spurious interrupt. The + distinction between such a spurious event and a real one can only be done + by reading such a GPIO. (There is a register telling the same + information, but accessing that one needs a SPI transfer which then + triggers another interrupt event.) + maxItems: 1 + '#address-cells': const: 1 @@ -111,6 +122,7 @@ unevaluatedProperties: false examples: - | + #include <dt-bindings/gpio/gpio.h> spi { #address-cells = <1>; #size-cells = <0>; @@ -121,6 +133,7 @@ examples: spi-max-frequency = <5000000>; interrupts = <25 2>; interrupt-parent = <&gpio>; + rdy-gpios = <&gpio 25 GPIO_ACTIVE_LOW>; refin1-supply = <&adc_vref>; clocks = <&ad7124_mclk>; clock-names = "mclk"; diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml index ad15cf9bc2ff..21ee319d4675 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml @@ -135,6 +135,17 @@ properties: '#clock-cells': const: 0 + rdy-gpios: + description: + GPIO reading the R̅D̅Y̅ line. Having such a GPIO is technically optional but + highly recommended because DOUT/R̅D̅Y̅ toggles during SPI transfers (in its + DOUT aka MISO role) and so usually triggers a spurious interrupt. The + distinction between such a spurious event and a real one can only be done + by reading such a GPIO. (There is a register telling the same + information, but accessing that one needs a SPI transfer which then + triggers another interrupt event.) + maxItems: 1 + patternProperties: "^channel@[0-9a-f]$": type: object @@ -443,6 +454,7 @@ examples: interrupts = <25 IRQ_TYPE_EDGE_FALLING>; interrupt-names = "rdy"; interrupt-parent = <&gpio>; + rdy-gpios = <&gpio 25 GPIO_ACTIVE_LOW>; spi-max-frequency = <5000000>; gpio-controller; #gpio-cells = <2>; diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml index 66dd1c549bd3..0bd2c6906c83 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml @@ -106,6 +106,17 @@ properties: description: see Documentation/devicetree/bindings/iio/adc/adc.yaml type: boolean + rdy-gpios: + description: + GPIO reading the R̅D̅Y̅ line. Having such a GPIO is technically optional but + highly recommended because DOUT/R̅D̅Y̅ toggles during SPI transfers (in its + DOUT aka MISO role) and so usually triggers a spurious interrupt. The + distinction between such a spurious event and a real one can only be done + by reading such a GPIO. (There is a register telling the same + information, but accessing that one needs a SPI transfer which then + triggers another interrupt event.) + maxItems: 1 + patternProperties: "^channel@[0-9a-f]+$": type: object @@ -181,6 +192,7 @@ unevaluatedProperties: false examples: - | + #include <dt-bindings/gpio/gpio.h> spi { #address-cells = <1>; #size-cells = <0>; @@ -195,6 +207,7 @@ examples: clock-names = "mclk"; interrupts = <25 0x2>; interrupt-parent = <&gpio>; + rdy-gpios = <&gpio 25 GPIO_ACTIVE_LOW>; aincom-supply = <&aincom>; dvdd-supply = <&dvdd>; avdd-supply = <&avdd>; @@ -207,6 +220,7 @@ examples: }; }; - | + #include <dt-bindings/gpio/gpio.h> spi { #address-cells = <1>; #size-cells = <0>; @@ -224,6 +238,7 @@ examples: #clock-cells = <0>; interrupts = <25 0x2>; interrupt-parent = <&gpio>; + rdy-gpios = <&gpio 25 GPIO_ACTIVE_LOW>; aincom-supply = <&aincom>; dvdd-supply = <&dvdd>; avdd-supply = <&avdd>; diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml index ab5881d0d017..52d3f1ce3367 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml @@ -146,6 +146,7 @@ properties: maxItems: 2 pwm-names: + minItems: 1 items: - const: convst1 - const: convst2 diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml index be2616ff9af6..5c8df45bfab0 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml @@ -63,6 +63,17 @@ properties: marked GPIO_ACTIVE_LOW. maxItems: 1 + rdy-gpios: + description: + GPIO reading the R̅D̅Y̅ line. Having such a GPIO is technically optional but + highly recommended because DOUT/R̅D̅Y̅ toggles during SPI transfers (in its + DOUT aka MISO role) and so usually triggers a spurious interrupt. The + distinction between such a spurious event and a real one can only be done + by reading such a GPIO. (There is a register telling the same + information, but accessing that one needs a SPI transfer which then + triggers another interrupt event.) + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml index ba86c7b7d622..40341d541726 100644 --- a/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml @@ -17,12 +17,15 @@ description: | properties: compatible: - items: - - enum: - - renesas,r9a07g043-adc # RZ/G2UL and RZ/Five - - renesas,r9a07g044-adc # RZ/G2L - - renesas,r9a07g054-adc # RZ/V2L - - const: renesas,rzg2l-adc + oneOf: + - items: + - enum: + - renesas,r9a07g043-adc # RZ/G2UL and RZ/Five + - renesas,r9a07g044-adc # RZ/G2L + - renesas,r9a07g054-adc # RZ/V2L + - const: renesas,rzg2l-adc + - items: + - const: renesas,r9a08g045-adc # RZ/G3S reg: maxItems: 1 @@ -57,6 +60,9 @@ properties: '#size-cells': const: 0 + "#io-channel-cells": + const: 1 + required: - compatible - reg @@ -68,7 +74,7 @@ required: - reset-names patternProperties: - "^channel@[0-7]$": + "^channel@[0-8]$": $ref: adc.yaml type: object description: | @@ -78,6 +84,8 @@ patternProperties: reg: description: | The channel number. + minimum: 0 + maximum: 8 required: - reg @@ -92,18 +100,25 @@ allOf: const: renesas,r9a07g043-adc then: patternProperties: - "^channel@[2-7]$": false + "^channel@[2-8]$": false "^channel@[0-1]$": properties: reg: - minimum: 0 maximum: 1 - else: + + - if: + properties: + compatible: + contains: + enum: + - renesas,r9a07g044-adc + - renesas,r9a07g054-adc + then: patternProperties: + "^channel@[8]$": false "^channel@[0-7]$": properties: reg: - minimum: 0 maximum: 7 additionalProperties: false diff --git a/Documentation/devicetree/bindings/iio/chemical/bosch,bme680.yaml b/Documentation/devicetree/bindings/iio/chemical/bosch,bme680.yaml new file mode 100644 index 000000000000..fe98ec44f081 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/chemical/bosch,bme680.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/chemical/bosch,bme680.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bosch BME680 Gas sensor + +maintainers: + - Vasileios Amoiridis <vassilisamir@gmail.com> + +description: > + BME680 is a gas sensor which combines relative humidity, barometric pressure, + ambient temperature and gas (VOC - Volatile Organic Compounds) measurements. + + https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme680-ds001.pdf + +properties: + compatible: + const: bosch,bme680 + + reg: + maxItems: 1 + + vdd-supply: true + vddio-supply: true + +required: + - compatible + - reg + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + co2-sensor@77 { + compatible = "bosch,bme680"; + reg = <0x77>; + vddio-supply = <&vddio>; + vdd-supply = <&vdd>; + }; + }; + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + co2-sensor@0 { + compatible = "bosch,bme680"; + reg = <0>; + spi-max-frequency = <500000>; + vddio-supply = <&vddio>; + vdd-supply = <&vdd>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml index 79cb4b78a88a..2bd89e0aa46b 100644 --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml @@ -91,7 +91,7 @@ examples: vrefn-supply = <&dac_vrefn>; reset-gpios = <&gpio_bd 16 GPIO_ACTIVE_LOW>; clear-gpios = <&gpio_bd 17 GPIO_ACTIVE_LOW>; - ldac-gpios = <&gpio_bd 18 GPIO_ACTIVE_HIGH>; + ldac-gpios = <&gpio_bd 18 GPIO_ACTIVE_LOW>; }; }; ... diff --git a/Documentation/devicetree/bindings/iio/dac/rohm,bd79703.yaml b/Documentation/devicetree/bindings/iio/dac/rohm,bd79703.yaml new file mode 100644 index 000000000000..941a49c93943 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/rohm,bd79703.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2024 ROHM Semiconductor. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/rohm,bd79703.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BD79703 DAC device driver + +maintainers: + - Matti Vaittinen <mazziesaccount@gmail.com> + +description: | + The ROHM BD79703 is a 6 channel, 8-bit DAC. + Datasheet can be found here: + https://fscdn.rohm.com/en/products/databook/datasheet/ic/data_converter/dac/bd79702fv-lb_bd79703fv-lb-e.pdf + +properties: + compatible: + const: rohm,bd79703 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 30000000 + + vfs-supply: + description: + The regulator to use as a full scale voltage. The voltage should be between 2.7V .. VCC + + vcc-supply: + description: + The regulator supplying the operating voltage. Should be between 2.7V ... 5.5V + +required: + - compatible + - reg + - spi-max-frequency + - vfs-supply + - vcc-supply + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "rohm,bd79703"; + reg = <0>; + spi-max-frequency = <30000000>; + vcc-supply = <&vcc>; + vfs-supply = <&vref>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml index e3eec38897bf..7a1a74fec281 100644 --- a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml +++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml @@ -11,24 +11,30 @@ maintainers: properties: compatible: - enum: - - adi,adis16375 - - adi,adis16480 - - adi,adis16485 - - adi,adis16488 - - adi,adis16490 - - adi,adis16495-1 - - adi,adis16495-2 - - adi,adis16495-3 - - adi,adis16497-1 - - adi,adis16497-2 - - adi,adis16497-3 - - adi,adis16545-1 - - adi,adis16545-2 - - adi,adis16545-3 - - adi,adis16547-1 - - adi,adis16547-2 - - adi,adis16547-3 + oneOf: + - enum: + - adi,adis16375 + - adi,adis16480 + - adi,adis16485 + - adi,adis16486 + - adi,adis16488 + - adi,adis16489 + - adi,adis16490 + - adi,adis16495-1 + - adi,adis16495-2 + - adi,adis16495-3 + - adi,adis16497-1 + - adi,adis16497-2 + - adi,adis16497-3 + - adi,adis16545-1 + - adi,adis16545-2 + - adi,adis16545-3 + - adi,adis16547-1 + - adi,adis16547-2 + - adi,adis16547-3 + - items: + - const: adi,adis16487 + - const: adi,adis16485 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml index 3b0a2d8b2e91..2cf8a0c7eb4c 100644 --- a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml +++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml @@ -37,6 +37,7 @@ properties: to "INT2" if INT2 pin should be used instead drive-open-drain: + type: boolean description: | set if the specified interrupt pin should be configured as open drain. If not set, defaults to push-pull. diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi270.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi270.yaml index 7b0cde1c9b0a..860a6c1fea3c 100644 --- a/Documentation/devicetree/bindings/iio/imu/bosch,bmi270.yaml +++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi270.yaml @@ -41,6 +41,7 @@ properties: - INT2 drive-open-drain: + type: boolean description: set if the specified interrupt pins should be configured as open drain. If not set, defaults to push-pull. diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi323.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi323.yaml index 64ef26e19669..7bf8294a8f2e 100644 --- a/Documentation/devicetree/bindings/iio/imu/bosch,bmi323.yaml +++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi323.yaml @@ -38,6 +38,7 @@ properties: - INT2 drive-open-drain: + type: boolean description: set if the specified interrupt pin should be configured as open drain. If not set, defaults to push-pull. diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml index f91954870a44..0bce71529e34 100644 --- a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml +++ b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml @@ -16,6 +16,7 @@ properties: compatible: oneOf: - enum: + - invensense,iam20380 - invensense,iam20680 - invensense,icm20608 - invensense,icm20609 diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bu27008.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bu27008.yaml deleted file mode 100644 index 4f66fd47b016..000000000000 --- a/Documentation/devicetree/bindings/iio/light/rohm,bu27008.yaml +++ /dev/null @@ -1,49 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/iio/light/rohm,bu27008.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: ROHM BU27008 color sensor - -maintainers: - - Matti Vaittinen <mazziesaccount@gmail.com> - -description: - The ROHM BU27008 is a sensor with 5 photodiodes (red, green, blue, clear - and IR) with four configurable channels. Red and green being always - available and two out of the rest three (blue, clear, IR) can be - selected to be simultaneously measured. Typical application is adjusting - LCD backlight of TVs, mobile phones and tablet PCs. - -properties: - compatible: - const: rohm,bu27008 - - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - - vdd-supply: true - -required: - - compatible - - reg - -additionalProperties: false - -examples: - - | - i2c { - #address-cells = <1>; - #size-cells = <0>; - - light-sensor@38 { - compatible = "rohm,bu27008"; - reg = <0x38>; - }; - }; - -... diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bu27010.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bu27010.yaml deleted file mode 100644 index bed42d5d0d94..000000000000 --- a/Documentation/devicetree/bindings/iio/light/rohm,bu27010.yaml +++ /dev/null @@ -1,50 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/iio/light/rohm,bu27010.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: ROHM BU27010 color sensor - -maintainers: - - Matti Vaittinen <mazziesaccount@gmail.com> - -description: | - The ROHM BU27010 is a sensor with 6 photodiodes (red, green, blue, clear, - IR and flickering detection) with five configurable channels. Red, green - and flickering detection being always available and two out of the rest - three (blue, clear, IR) can be selected to be simultaneously measured. - Typical application is adjusting LCD/OLED backlight of TVs, mobile phones - and tablet PCs. - -properties: - compatible: - const: rohm,bu27010 - - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - - vdd-supply: true - -required: - - compatible - - reg - - vdd-supply - -additionalProperties: false - -examples: - - | - i2c { - #address-cells = <1>; - #size-cells = <0>; - - light-sensor@38 { - compatible = "rohm,bu27010"; - reg = <0x38>; - vdd-supply = <&vdd>; - }; - }; diff --git a/Documentation/devicetree/bindings/iio/light/ti,opt4060.yaml b/Documentation/devicetree/bindings/iio/light/ti,opt4060.yaml new file mode 100644 index 000000000000..568fb2a9b7a3 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/ti,opt4060.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/ti,opt4060.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments OPT4060 RGBW Color Sensor + +maintainers: + - Per-Daniel Olsson <perdaniel.olsson@axis.com> + +description: + Texas Instrument RGBW high resolution color sensor over I2C. + https://www.ti.com/lit/gpn/opt4060 + +properties: + compatible: + enum: + - ti,opt4060 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vdd-supply: true + +required: + - compatible + - reg + - vdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + light-sensor@44 { + compatible = "ti,opt4060"; + reg = <0x44>; + vdd-supply = <&vdd_reg>; + interrupt-parent = <&gpio5>; + interrupts = <13 IRQ_TYPE_EDGE_FALLING>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml index cb201cecfa1a..706b7e24f182 100644 --- a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml +++ b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml @@ -55,12 +55,16 @@ properties: If not set, defaults to push-pull configuration. type: boolean + spi-max-frequency: + maximum: 10000000 + required: - compatible - vddd-supply - vdda-supply allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# - if: properties: compatible: @@ -73,6 +77,16 @@ allOf: then: properties: interrupts: false + - if: + properties: + compatible: + contains: + enum: + - bosch,bmp085 + - bosch,bmp180 + then: + properties: + spi-max-frequency: false additionalProperties: false @@ -93,3 +107,18 @@ examples: vdda-supply = <&bar>; }; }; + - | + # include <dt-bindings/gpio/gpio.h> + # include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + pressure@0 { + compatible = "bosch,bmp280"; + reg = <0>; + spi-max-frequency = <10000000>; + reset-gpios = <&gpio0 26 GPIO_ACTIVE_LOW>; + vddd-supply = <&foo>; + vdda-supply = <&bar>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml b/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml index 47aac8794b68..517a4ac1bea3 100644 --- a/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml +++ b/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml @@ -26,6 +26,9 @@ properties: - items: - enum: - mediatek,mt6873-keypad + - mediatek,mt8183-keypad + - mediatek,mt8365-keypad + - mediatek,mt8516-keypad - const: mediatek,mt6779-keypad reg: diff --git a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml index 60f09caa0e4c..b95435bd6a9b 100644 --- a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml +++ b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml @@ -25,6 +25,7 @@ properties: compatible: enum: - mediatek,mt6323-keys + - mediatek,mt6328-keys - mediatek,mt6331-keys - mediatek,mt6357-keys - mediatek,mt6358-keys diff --git a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml index e24cbd960993..bd8ede3a4ad8 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml @@ -19,6 +19,7 @@ properties: - imagis,ist3038 - imagis,ist3038b - imagis,ist3038c + - imagis,ist3038h reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml index 251410aabf38..83bcf0575cd3 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml @@ -26,6 +26,7 @@ properties: - items: - enum: - qcom,qcm2290-cpu-bwmon + - qcom,qcs615-cpu-bwmon - qcom,qcs8300-cpu-bwmon - qcom,sa8775p-cpu-bwmon - qcom,sc7180-cpu-bwmon @@ -37,10 +38,12 @@ properties: - qcom,sm8250-cpu-bwmon - qcom,sm8550-cpu-bwmon - qcom,sm8650-cpu-bwmon + - qcom,sm8750-cpu-bwmon - qcom,x1e80100-cpu-bwmon - const: qcom,sdm845-bwmon # BWMON v4, unified register space - items: - enum: + - qcom,qcs615-llcc-bwmon - qcom,qcs8300-llcc-bwmon - qcom,sa8775p-llcc-bwmon - qcom,sc7180-llcc-bwmon diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index 21dae0b92819..4ac0863205b3 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -33,6 +33,7 @@ properties: - qcom,sm6375-cpucp-l3 - qcom,sm8250-epss-l3 - qcom,sm8350-epss-l3 + - qcom,sm8650-epss-l3 - const: qcom,epss-l3 reg: diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sm8750-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sm8750-rpmh.yaml new file mode 100644 index 000000000000..a816acc301e1 --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/qcom,sm8750-rpmh.yaml @@ -0,0 +1,136 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interconnect/qcom,sm8750-rpmh.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm RPMh Network-On-Chip Interconnect on SM8750 + +maintainers: + - Abel Vesa <abel.vesa@linaro.org> + - Neil Armstrong <neil.armstrong@linaro.org> + +description: | + RPMh interconnect providers support system bandwidth requirements through + RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is + able to communicate with the BCM through the Resource State Coordinator (RSC) + associated with each execution environment. Provider nodes must point to at + least one RPMh device child node pertaining to their RSC and each provider + can map to multiple RPMh resources. + + See also:: include/dt-bindings/interconnect/qcom,sm8750-rpmh.h + +properties: + compatible: + enum: + - qcom,sm8750-aggre1-noc + - qcom,sm8750-aggre2-noc + - qcom,sm8750-clk-virt + - qcom,sm8750-cnoc-main + - qcom,sm8750-config-noc + - qcom,sm8750-gem-noc + - qcom,sm8750-lpass-ag-noc + - qcom,sm8750-lpass-lpiaon-noc + - qcom,sm8750-lpass-lpicx-noc + - qcom,sm8750-mc-virt + - qcom,sm8750-mmss-noc + - qcom,sm8750-nsp-noc + - qcom,sm8750-pcie-anoc + - qcom,sm8750-system-noc + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + +required: + - compatible + +allOf: + - $ref: qcom,rpmh-common.yaml# + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8750-clk-virt + - qcom,sm8750-mc-virt + then: + properties: + reg: false + else: + required: + - reg + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8750-pcie-anoc + then: + properties: + clocks: + items: + - description: aggre-NOC PCIe AXI clock + - description: cfg-NOC PCIe a-NOC AHB clock + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8750-aggre1-noc + then: + properties: + clocks: + items: + - description: aggre UFS PHY AXI clock + - description: aggre USB3 PRIM AXI clock + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8750-aggre2-noc + then: + properties: + clocks: + items: + - description: RPMH CC IPA clock + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8750-aggre1-noc + - qcom,sm8750-aggre2-noc + - qcom,sm8750-pcie-anoc + then: + required: + - clocks + else: + properties: + clocks: false + +unevaluatedProperties: false + +examples: + - | + clk_virt: interconnect-0 { + compatible = "qcom,sm8750-clk-virt"; + #interconnect-cells = <2>; + qcom,bcm-voters = <&apps_bcm_voter>; + }; + + aggre1_noc: interconnect@16e0000 { + compatible = "qcom,sm8750-aggre1-noc"; + reg = <0x016e0000 0x16400>; + #interconnect-cells = <2>; + clocks = <&gcc_phy_axi_clk>, <&gcc_prim_axi_clk>; + qcom,bcm-voters = <&apps_bcm_voter>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml index f49b43f45f3d..06e3621a8c06 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml @@ -26,6 +26,7 @@ properties: deprecated: true - const: allwinner,sun7i-a20-sc-nmi - const: allwinner,sun9i-a80-nmi + - const: allwinner,sun55i-a523-nmi - items: - enum: - allwinner,sun8i-v3s-nmi diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml index a2846e493497..7173c4b5a228 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml @@ -110,8 +110,8 @@ properties: interrupts: description: Interrupt source of the parent interrupt controller on - secondary GICs, or VGIC maintenance interrupt on primary GIC (see - below). + secondary GICs, or VGIC maintenance interrupt on primary GIC (see "GICv2 + with virtualization extensions" paragraph in the "reg" property). maxItems: 1 cpu-offset: diff --git a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.yaml b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.yaml index 73e8b9a39bd7..86516cd44b9d 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.yaml @@ -52,11 +52,11 @@ additionalProperties: false examples: - | interrupt-controller@1e6c0080 { - compatible = "aspeed,ast2400-vic"; - reg = <0x1e6c0080 0x80>; - interrupt-controller; - #interrupt-cells = <1>; - valid-sources = <0xffffffff 0x0007ffff>; + compatible = "aspeed,ast2400-vic"; + reg = <0x1e6c0080 0x80>; + interrupt-controller; + #interrupt-cells = <1>; + valid-sources = <0xffffffff 0x0007ffff>; }; ... diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml index 786f2426399b..0fcbe304cd05 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml @@ -130,23 +130,23 @@ required: examples: - | irq0_intc: interrupt-controller@f0406800 { - compatible = "brcm,bcm7120-l2-intc"; - interrupt-parent = <&intc>; - #interrupt-cells = <1>; - reg = <0xf0406800 0x8>; - interrupt-controller; - interrupts = <0x0 0x42 0x0>, <0x0 0x40 0x0>; - brcm,int-map-mask = <0xeb8>, <0x140>; - brcm,int-fwd-mask = <0x7>; + compatible = "brcm,bcm7120-l2-intc"; + interrupt-parent = <&intc>; + #interrupt-cells = <1>; + reg = <0xf0406800 0x8>; + interrupt-controller; + interrupts = <0x0 0x42 0x0>, <0x0 0x40 0x0>; + brcm,int-map-mask = <0xeb8>, <0x140>; + brcm,int-fwd-mask = <0x7>; }; - | irq1_intc: interrupt-controller@10000020 { - compatible = "brcm,bcm3380-l2-intc"; - reg = <0x10000024 0x4>, <0x1000002c 0x4>, - <0x10000020 0x4>, <0x10000028 0x4>; - interrupt-controller; - #interrupt-cells = <1>; - interrupt-parent = <&cpu_intc>; - interrupts = <2>; + compatible = "brcm,bcm3380-l2-intc"; + reg = <0x10000024 0x4>, <0x1000002c 0x4>, + <0x10000020 0x4>, <0x10000028 0x4>; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&cpu_intc>; + interrupts = <2>; }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/microchip,lan966x-oic.yaml b/Documentation/devicetree/bindings/interrupt-controller/microchip,lan966x-oic.yaml index b2adc7174177..dca16e202da9 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/microchip,lan966x-oic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/microchip,lan966x-oic.yaml @@ -14,9 +14,8 @@ allOf: description: | The Microchip LAN966x outband interrupt controller (OIC) maps the internal - interrupt sources of the LAN966x device to an external interrupt. - When the LAN966x device is used as a PCI device, the external interrupt is - routed to the PCI interrupt. + interrupt sources of the LAN966x device to a PCI interrupt when the LAN966x + device is used as a PCI device. properties: compatible: diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml index a54da66a89e7..f06b40f88778 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml @@ -26,6 +26,8 @@ properties: compatible: items: - enum: + - qcom,qcs615-pdc + - qcom,qcs8300-pdc - qcom,qdu1000-pdc - qcom,sa8255p-pdc - qcom,sa8775p-pdc @@ -47,6 +49,7 @@ properties: - qcom,sm8450-pdc - qcom,sm8550-pdc - qcom,sm8650-pdc + - qcom,sm8750-pdc - qcom,x1e80100-pdc - const: qcom,pdc diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzv2h-icu.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzv2h-icu.yaml index d7ef4f1323a7..3f99c8645767 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzv2h-icu.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzv2h-icu.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/interrupt-controller/renesas,rzv2h-icu.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/V2H(P) Interrupt Control Unit +title: Renesas RZ/{G3E,V2H(P)} Interrupt Control Unit maintainers: - Fabrizio Castro <fabrizio.castro.jz@renesas.com> @@ -20,7 +20,9 @@ description: properties: compatible: - const: renesas,r9a09g057-icu # RZ/V2H(P) + enum: + - renesas,r9a09g047-icu # RZ/G3E + - renesas,r9a09g057-icu # RZ/V2H(P) '#interrupt-cells': description: The first cell is the SPI number of the NMI or the diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml index 190a6499c932..bef00521d5da 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml @@ -91,6 +91,14 @@ properties: Firmware must configure interrupt delegation registers based on interrupt delegation list. + riscv,hart-indexes: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 16384 + description: + A list of hart indexes that APLIC should use to address each hart + that is mentioned in the "interrupts-extended" + dependencies: riscv,delegation: [ "riscv,children" ] diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml index 84976f17a4a1..c23b5c09fdb9 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml @@ -142,7 +142,7 @@ examples: <&cpu2_intc 11>, <&cpu3_intc 11>, <&cpu4_intc 11>; - reg = <0x28000000 0x4000>; + reg = <0x24000000 0x4000>; interrupt-controller; #interrupt-cells = <0>; msi-controller; diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml index 7e1451f9786a..3dfe425909d1 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml @@ -59,6 +59,7 @@ properties: - enum: - canaan,k210-plic - sifive,fu540-c000-plic + - spacemit,k1-plic - starfive,jh7100-plic - starfive,jh7110-plic - const: sifive,plic-1.0.0 diff --git a/Documentation/devicetree/bindings/interrupt-controller/sophgo,sg2042-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/sophgo,sg2042-msi.yaml new file mode 100644 index 000000000000..e1ffd55fa7bf --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/sophgo,sg2042-msi.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/sophgo,sg2042-msi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sophgo SG2042 MSI Controller + +maintainers: + - Chen Wang <unicorn_wang@outlook.com> + +description: + This interrupt controller is in Sophgo SG2042 for transforming interrupts from + PCIe MSI to PLIC interrupts. + +allOf: + - $ref: /schemas/interrupt-controller/msi-controller.yaml# + +properties: + compatible: + const: sophgo,sg2042-msi + + reg: + items: + - description: clear register + - description: msi doorbell address + + reg-names: + items: + - const: clr + - const: doorbell + + msi-controller: true + + msi-ranges: + maxItems: 1 + + "#msi-cells": + const: 0 + +required: + - compatible + - reg + - reg-names + - msi-controller + - msi-ranges + - "#msi-cells" + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + msi-controller@30000000 { + compatible = "sophgo,sg2042-msi"; + reg = <0x30000000 0x4>, <0x30000008 0x4>; + reg-names = "clr", "doorbell"; + msi-controller; + #msi-cells = <0>; + msi-ranges = <&plic 64 IRQ_TYPE_LEVEL_HIGH 32>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu.txt index 422d6908f8b2..422d6908f8b2 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu.txt diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index c1e11bc6b7a0..032fdc27127b 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -61,6 +61,7 @@ properties: - qcom,sm8450-smmu-500 - qcom,sm8550-smmu-500 - qcom,sm8650-smmu-500 + - qcom,sm8750-smmu-500 - qcom,x1e80100-smmu-500 - const: qcom,smmu-500 - const: arm,mmu-500 @@ -88,6 +89,7 @@ properties: items: - enum: - qcom,qcm2290-smmu-500 + - qcom,qcs615-smmu-500 - qcom,sa8255p-smmu-500 - qcom,sa8775p-smmu-500 - qcom,sar2130p-smmu-500 @@ -102,6 +104,7 @@ properties: - qcom,sm8450-smmu-500 - qcom,sm8550-smmu-500 - qcom,sm8650-smmu-500 + - qcom,sm8750-smmu-500 - qcom,x1e80100-smmu-500 - const: qcom,adreno-smmu - const: qcom,smmu-500 @@ -122,6 +125,7 @@ properties: - qcom,msm8996-smmu-v2 - qcom,sc7180-smmu-v2 - qcom,sdm630-smmu-v2 + - qcom,sdm670-smmu-v2 - qcom,sdm845-smmu-v2 - qcom,sm6350-smmu-v2 - qcom,sm7150-smmu-v2 @@ -474,6 +478,7 @@ allOf: items: - enum: - qcom,qcm2290-smmu-500 + - qcom,qcs615-smmu-500 - qcom,sm6115-smmu-500 - qcom,sm6125-smmu-500 - const: qcom,adreno-smmu @@ -550,6 +555,23 @@ allOf: - description: GPU SNoC bus clock - description: GPU AHB clock + - if: + properties: + compatible: + items: + - const: qcom,sm8750-smmu-500 + - const: qcom,adreno-smmu + - const: qcom,smmu-500 + - const: arm,mmu-500 + then: + properties: + clock-names: + items: + - const: hlos + clocks: + items: + - description: HLOS vote clock + # Disallow clocks for all other platforms with specific compatibles - if: properties: @@ -559,7 +581,6 @@ allOf: - cavium,smmu-v2 - marvell,ap806-smmu-500 - nvidia,smmu-500 - - qcom,qcs615-smmu-500 - qcom,qcs8300-smmu-500 - qcom,qdu1000-smmu-500 - qcom,sa8255p-smmu-500 diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml index f8cebc9e8cd9..5ae9a628261f 100644 --- a/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml @@ -21,6 +21,7 @@ properties: - items: - enum: - qcom,msm8916-iommu + - qcom,msm8917-iommu - qcom,msm8953-iommu - const: qcom,msm-iommu-v1 - items: diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml index 621dde0e45d8..6ce41d11ff5e 100644 --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml @@ -25,6 +25,7 @@ properties: - rockchip,rk3568-iommu - items: - enum: + - rockchip,rk3576-iommu - rockchip,rk3588-iommu - const: rockchip,rk3568-iommu diff --git a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml index 34ef5215c150..f52f6304c79e 100644 --- a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml +++ b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml @@ -23,6 +23,12 @@ properties: description: I2C slave address of the microcontroller. maxItems: 1 + interrupts: + description: + Specifier for the global LED brightness changed by front button press + interrupt. + maxItems: 1 + "#address-cells": const: 1 @@ -56,6 +62,7 @@ additionalProperties: false examples: - | + #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/leds/common.h> i2c { @@ -65,6 +72,7 @@ examples: led-controller@2b { compatible = "cznic,turris-omnia-leds"; reg = <0x2b>; + interrupts-extended = <&mcu 11 IRQ_TYPE_NONE>; #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml index e850a8894758..bb40bb9e036e 100644 --- a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml +++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml @@ -27,7 +27,7 @@ properties: description: | For multicolor LED support this property should be defined as either LED_COLOR_ID_RGB or LED_COLOR_ID_MULTI which can be found in - include/linux/leds/common.h. + include/dt-bindings/leds/common.h. enum: [ 8, 9 ] required: diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt deleted file mode 100644 index 8bb25749a3da..000000000000 --- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt +++ /dev/null @@ -1,50 +0,0 @@ -* Texas Instruments - lp8860 4-Channel LED Driver - -The LP8860-Q1 is an high-efficiency LED -driver with boost controller. It has 4 high-precision -current sinks that can be controlled by a PWM input -signal, a SPI/I2C master, or both. - -Required properties: - - compatible : - "ti,lp8860" - - reg : I2C slave address - - #address-cells : 1 - - #size-cells : 0 - -Optional properties: - - enable-gpios : gpio pin to enable (active high)/disable the device. - - vled-supply : LED supply - -Required child properties: - - reg : 0 - -Optional child properties: - - function : see Documentation/devicetree/bindings/leds/common.txt - - color : see Documentation/devicetree/bindings/leds/common.txt - - label : see Documentation/devicetree/bindings/leds/common.txt (deprecated) - - linux,default-trigger : - see Documentation/devicetree/bindings/leds/common.txt - -Example: - -#include <dt-bindings/leds/common.h> - -led-controller@2d { - compatible = "ti,lp8860"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x2d>; - enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; - vled-supply = <&vbatt>; - - led@0 { - reg = <0>; - function = LED_FUNCTION_BACKLIGHT; - color = <LED_COLOR_ID_WHITE>; - linux,default-trigger = "backlight"; - }; -} - -For more product information please see the link below: -https://www.ti.com/product/lp8860-q1 diff --git a/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml b/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml index 1ba607685f5f..bcf0ad4ea57e 100644 --- a/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml +++ b/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml @@ -23,6 +23,7 @@ properties: items: - enum: - qcom,pm6150l-flash-led + - qcom,pm660l-flash-led - qcom,pm8150c-flash-led - qcom,pm8150l-flash-led - qcom,pm8350c-flash-led diff --git a/Documentation/devicetree/bindings/leds/st,led1202.yaml b/Documentation/devicetree/bindings/leds/st,led1202.yaml new file mode 100644 index 000000000000..f1e5e4efaa3a --- /dev/null +++ b/Documentation/devicetree/bindings/leds/st,led1202.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/st,led1202.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ST LED1202 LED controllers + +maintainers: + - Vicentiu Galanopulo <vicentiu.galanopulo@remote-tech.co.uk> + +description: | + The LED1202 is a 12-channel low quiescent current LED controller + programmable via I2C; The output current can be adjusted separately + for each channel by 8-bit analog and 12-bit digital dimming control. + Datasheet available at + https://www.st.com/en/power-management/led1202.html + +properties: + compatible: + const: st,led1202 + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^led@[0-9a-f]$": + type: object + $ref: common.yaml# + unevaluatedProperties: false + + properties: + reg: + minimum: 0 + maximum: 11 + + required: + - reg + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@58 { + compatible = "st,led1202"; + reg = <0x58>; + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0x0>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_RED>; + function-enumerator = <1>; + }; + + led@1 { + reg = <0x1>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_GREEN>; + function-enumerator = <2>; + }; + + led@2 { + reg = <0x2>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_BLUE>; + function-enumerator = <3>; + }; + + led@3 { + reg = <0x3>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_RED>; + function-enumerator = <4>; + }; + + led@4 { + reg = <0x4>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_GREEN>; + function-enumerator = <5>; + }; + + led@5 { + reg = <0x5>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_BLUE>; + function-enumerator = <6>; + }; + + led@6 { + reg = <0x6>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_RED>; + function-enumerator = <7>; + }; + + led@7 { + reg = <0x7>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_GREEN>; + function-enumerator = <8>; + }; + + led@8 { + reg = <0x8>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_BLUE>; + function-enumerator = <9>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/leds/ti,lp8860.yaml b/Documentation/devicetree/bindings/leds/ti,lp8860.yaml new file mode 100644 index 000000000000..0ee357b02661 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/ti,lp8860.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/ti,lp8860.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments - lp8860 4-Channel LED Driver + +maintainers: + - Andrew Davis <afd@ti.com> + +description: | + The LP8860-Q1 is an high-efficiency LED driver with boost controller. + It has 4 high-precision current sinks that can be controlled by a PWM input + signal, a SPI/I2C master, or both. + + For more product information please see the link below: + https://www.ti.com/product/lp8860-q1 + +properties: + compatible: + const: ti,lp8860 + + reg: + maxItems: 1 + description: I2C slave address + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + enable-gpios: + maxItems: 1 + description: GPIO pin to enable (active high) / disable the device + + vled-supply: + description: LED supply + +patternProperties: + "^led(@[0-3])?$": + type: object + $ref: common.yaml# + unevaluatedProperties: false + + properties: + reg: + description: + Index of the LED. + maxItems: 1 + + function: true + color: true + label: true + linux,default-trigger: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@2d { + compatible = "ti,lp8860"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x2d>; + enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; + vled-supply = <&vbatt>; + + led@0 { + reg = <0>; + function = LED_FUNCTION_BACKLIGHT; + color = <LED_COLOR_ID_WHITE>; + linux,default-trigger = "backlight"; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml b/Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml new file mode 100644 index 000000000000..e249db4c1fbc --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2024 Linaro Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/google,gs101-mbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos Mailbox Controller + +maintainers: + - Tudor Ambarus <tudor.ambarus@linaro.org> + +description: + The Samsung Exynos mailbox controller, used on Google GS101 SoC, has 16 flag + bits for hardware interrupt generation and a shared register for passing + mailbox messages. When the controller is used by the ACPM interface + the shared register is ignored and the mailbox controller acts as a doorbell. + The controller just raises the interrupt to the firmware after the + ACPM interface has written the message to SRAM. + +properties: + compatible: + const: google,gs101-mbox + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: pclk + + interrupts: + description: IRQ line for the RX mailbox. + maxItems: 1 + + '#mbox-cells': + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - '#mbox-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/google,gs101.h> + + soc { + #address-cells = <1>; + #size-cells = <1>; + + ap2apm_mailbox: mailbox@17610000 { + compatible = "google,gs101-mbox"; + reg = <0x17610000 0x1000>; + clocks = <&cmu_apm CLK_GOUT_APM_MAILBOX_APM_AP_PCLK>; + clock-names = "pclk"; + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH 0>; + #mbox-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml b/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml new file mode 100644 index 000000000000..8ed67ea7c883 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml @@ -0,0 +1,123 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/microchip,sbi-ipc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Inter-processor communication (IPC) mailbox controller + +maintainers: + - Valentina Fernandez <valentina.fernandezalanis@microchip.com> + +description: + The Microchip Inter-processor Communication (IPC) facilitates + message passing between processors using an interrupt signaling + mechanism. + +properties: + compatible: + oneOf: + - description: + Intended for use by software running in supervisor privileged + mode (s-mode). This SBI interface is compatible with the Mi-V + Inter-hart Communication (IHC) IP. + const: microchip,sbi-ipc + + - description: + Intended for use by the SBI implementation in machine mode + (m-mode), this compatible string is for the MIV_IHC Soft-IP. + const: microchip,miv-ihc-rtl-v2 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 5 + + interrupt-names: + minItems: 1 + maxItems: 5 + items: + enum: + - hart-0 + - hart-1 + - hart-2 + - hart-3 + - hart-4 + - hart-5 + + "#mbox-cells": + description: > + For "microchip,sbi-ipc", the cell represents the global "logical" + channel IDs. The meaning of channel IDs are platform firmware dependent. + + For "microchip,miv-ihc-rtl-v2", the cell represents the physical + channel and does not vary based on the platform firmware. + const: 1 + + microchip,ihc-chan-disabled-mask: + description: > + Represents the enable/disable state of the bi-directional IHC + channels within the MIV-IHC IP configuration. + + A bit set to '1' indicates that the corresponding channel is disabled, + and any read or write operations to that channel will return zero. + + A bit set to '0' indicates that the corresponding channel is enabled + and will be accessible through its dedicated address range registers. + + The actual enable/disable state of each channel is determined by the + IP block’s configuration. + $ref: /schemas/types.yaml#/definitions/uint16 + maximum: 0x7fff + default: 0 + +required: + - compatible + - interrupts + - interrupt-names + - "#mbox-cells" + +allOf: + - if: + properties: + compatible: + contains: + const: microchip,sbi-ipc + then: + properties: + reg: + not: {} + description: + The 'microchip,sbi-ipc' operates in a programming model + that does not require memory-mapped I/O (MMIO) registers + since it uses SBI ecalls provided by the m-mode/firmware + SBI implementation to access hardware registers. + microchip,ihc-chan-disabled-mask: false + else: + required: + - reg + - microchip,ihc-chan-disabled-mask + +additionalProperties: false + +examples: + - | + mailbox { + compatible = "microchip,sbi-ipc"; + interrupt-parent = <&plic>; + interrupts = <180>, <179>, <178>; + interrupt-names = "hart-1", "hart-2", "hart-3"; + #mbox-cells = <1>; + }; + - | + mailbox@50000000 { + compatible = "microchip,miv-ihc-rtl-v2"; + microchip,ihc-chan-disabled-mask = /bits/ 16 <0>; + reg = <0x50000000 0x1c000>; + interrupt-parent = <&plic>; + interrupts = <180>, <179>, <178>; + interrupt-names = "hart-1", "hart-2", "hart-3"; + #mbox-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 9d2dfd85b207..78f68dacd028 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -20,6 +20,7 @@ properties: - enum: - qcom,ipq5018-apcs-apps-global - qcom,ipq5332-apcs-apps-global + - qcom,ipq5424-apcs-apps-global - qcom,ipq8074-apcs-apps-global - qcom,ipq9574-apcs-apps-global - const: qcom,ipq6018-apcs-apps-global @@ -44,6 +45,7 @@ properties: - const: qcom,msm8994-apcs-kpss-global - items: - enum: + - qcom,qcs615-apss-shared - qcom,sc7180-apss-shared - qcom,sc8180x-apss-shared - qcom,sm8150-apss-shared diff --git a/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml index a4f06bbdfe49..8ba5177ac631 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/allwinner,sun50i-h6-vpu-g2.yaml# diff --git a/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml index 377acce93423..6da8a6aded23 100644 --- a/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/amlogic,meson-ir-tx.yaml# diff --git a/Documentation/devicetree/bindings/media/amphion,vpu.yaml b/Documentation/devicetree/bindings/media/amphion,vpu.yaml index 9801de3ed84e..5a920d9e78c7 100644 --- a/Documentation/devicetree/bindings/media/amphion,vpu.yaml +++ b/Documentation/devicetree/bindings/media/amphion,vpu.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/amphion,vpu.yaml# diff --git a/Documentation/devicetree/bindings/media/aspeed,video-engine.yaml b/Documentation/devicetree/bindings/media/aspeed,video-engine.yaml new file mode 100644 index 000000000000..682bba20778c --- /dev/null +++ b/Documentation/devicetree/bindings/media/aspeed,video-engine.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/aspeed,video-engine.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED Video Engine + +maintainers: + - Eddie James <eajames@linux.ibm.com> + +description: + The Video Engine (VE) embedded in the ASPEED SOCs can be configured to + capture and compress video data from digital or analog sources. + +properties: + compatible: + enum: + - aspeed,ast2400-video-engine + - aspeed,ast2500-video-engine + - aspeed,ast2600-video-engine + + reg: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: vclk + - const: eclk + + resets: + maxItems: 1 + + interrupts: + maxItems: 1 + + memory-region: + maxItems: 1 + description: | + Phandle to the reserved memory nodes to be associated with the + VE. VE will acquires memory space for 3 purposes: + 1. JPEG header + 2. Compressed result + 3. Temporary transformed image data + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/ast2600-clock.h> + + video@1e700000 { + compatible = "aspeed,ast2600-video-engine"; + reg = <0x1e700000 0x1000>; + clocks = <&syscon ASPEED_CLK_GATE_VCLK>, + <&syscon ASPEED_CLK_GATE_ECLK>; + clock-names = "vclk", "eclk"; + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/media/aspeed-video.txt b/Documentation/devicetree/bindings/media/aspeed-video.txt deleted file mode 100644 index d2ca32512272..000000000000 --- a/Documentation/devicetree/bindings/media/aspeed-video.txt +++ /dev/null @@ -1,33 +0,0 @@ -* Device tree bindings for Aspeed Video Engine - -The Video Engine (VE) embedded in the Aspeed AST2400/2500/2600 SOCs can -capture and compress video data from digital or analog sources. - -Required properties: - - compatible: "aspeed,ast2400-video-engine" or - "aspeed,ast2500-video-engine" or - "aspeed,ast2600-video-engine" - - reg: contains the offset and length of the VE memory region - - clocks: clock specifiers for the syscon clocks associated with - the VE (ordering must match the clock-names property) - - clock-names: "vclk" and "eclk" - - resets: reset specifier for the syscon reset associated with - the VE - - interrupts: the interrupt associated with the VE on this platform - -Optional properties: - - memory-region: - phandle to a memory region to allocate from, as defined in - Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt - -Example: - -video-engine@1e700000 { - compatible = "aspeed,ast2500-video-engine"; - reg = <0x1e700000 0x20000>; - clocks = <&syscon ASPEED_CLK_GATE_VCLK>, <&syscon ASPEED_CLK_GATE_ECLK>; - clock-names = "vclk", "eclk"; - resets = <&syscon ASPEED_RESET_VIDEO>; - interrupts = <7>; - memory-region = <&video_engine_memory>; -}; diff --git a/Documentation/devicetree/bindings/media/fsl,imx6ull-pxp.yaml b/Documentation/devicetree/bindings/media/fsl,imx6ull-pxp.yaml index 84a5e894ace4..3f47744459aa 100644 --- a/Documentation/devicetree/bindings/media/fsl,imx6ull-pxp.yaml +++ b/Documentation/devicetree/bindings/media/fsl,imx6ull-pxp.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/fsl,imx6ull-pxp.yaml# diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml index 4371a0ef2761..9ee1483775f6 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml @@ -49,6 +49,10 @@ properties: Indicates that the output is a BT.656-4 compatible stream. type: boolean + interrupts: + items: + - description: The GPIO connected to the INTRQ pin. + port: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml index bf05ca48601a..fa69bd21c8da 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml @@ -33,6 +33,8 @@ properties: - sony,imx290lqr # Colour - sony,imx290llr # Monochrome - sony,imx327lqr # Colour + - sony,imx462lqr # Colour + - sony,imx462llr # Monochrome - const: sony,imx290 deprecated: true diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml index b68141264c0e..4d40e75b4e1e 100644 --- a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml +++ b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml @@ -71,7 +71,7 @@ properties: description: Any lane can be inverted or not. minItems: 1 - maxItems: 2 + maxItems: 3 required: - data-lanes diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml index b401c67e3ba0..d726d141a434 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/mediatek,vcodec-decoder.yaml# diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml index b45743d0a9ec..110e8f5f1f9e 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/mediatek,vcodec-encoder.yaml# diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml index a500a585c692..bf8082d87ac0 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml @@ -1,56 +1,73 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek Video Decode Accelerator With Multi Hardware +title: MediaTek Video Decode Accelerator With Multi Hardware maintainers: - Yunfei Dong <yunfei.dong@mediatek.com> description: | - Mediatek Video Decode is the video decode hardware present in Mediatek - SoCs which supports high resolution decoding functionalities. Required - parent and child device node. - - About the Decoder Hardware Block Diagram, please check below: - - +------------------------------------------------+-------------------------------------+ - | | | - | input -> lat soc HW -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output | - | || || | || | - +------------||-------------||-------------------+---------------------||--------------+ - || lat || | core workqueue <parent> - -------------||-------------||-------------------|---------------------||--------------- - ||<------------||----------------HW index---------------->|| <child> - \/ \/ \/ - +-------------------------------------------------------------+ - | enable/disable | - | clk power irq iommu | - | (lat/lat soc/core0/core1) | - +-------------------------------------------------------------+ - - As above, there are parent and child devices, child mean each hardware. The child device - controls the information of each hardware independent which include clk/power/irq. - - There are two workqueues in parent device: lat workqueue and core workqueue. They are used - to lat and core hardware decoder. Lat workqueue need to get input bitstream and lat buffer, - then enable lat to decode, writing the result to lat buffer, dislabe hardware when lat decode - done. Core workqueue need to get lat buffer and output buffer, then enable core to decode, - writing the result to output buffer, disable hardware when core decode done. These two - hardwares will decode each frame cyclically. - - For the smi common may not the same for each hardware, can't combine all hardware in one node, - or leading to iommu fault when access dram data. - - Lat soc is a hardware which is related with some larb(local arbiter) ports. For mt8195 - platform, there are some ports like RDMA, UFO in lat soc larb, need to enable its power and - clock when lat start to work, don't have interrupt. - - mt8195: lat soc HW + lat HW + core HW - mt8192: lat HW + core HW + MediaTek Video Decode Accelerator is the video decoding hardware present in + MediaTek SoCs that supports high-resolution decoding functionalities. + It consists of parent and child nodes. + + The decoder hardware block diagram is shown below: + + +------------------------------------------------+------------------------------+ + | | | + | input -> LAT-SoC HW -> LAT HW -> LAT buffer --|--> Core HW -> output buffer | + | || || | || | + +--------------||-----------||-------------------+-------||---------------------+ + LAT Workqueue | Core Workqueue <parent> + ---------------||-----------||-------------------|-------||---------------------- + ||<----------||---------HW index--------->|| <child> + \/ \/ \/ + +-------------------------------------------------------------+ + | enable/disable | + | clk power irq iommu | + | (lat/lat-soc/core0/core1) | + +-------------------------------------------------------------+ + + The child nodes represent the individual hardware blocks within the decoding + pipeline, such as LAT-SoC, LAT and Core. + Each child node is responsible for managing the dedicated resources of the + hardware, such as clocks, power domains, interrupts and IOMMUs. + + The parent node is a central point of control for the child nodes. + It identifies the specific video decoding pipeline architecture used by the + SoC, manages the shared resources like workqueues and platform data, and + handles V4L2 API calls on behalf of the underlying hardware. + + The parent utilizes two workqueues to manage the decoding process. + 1. LAT Workqueue, for LAT-SoC and LAT decoder: + Its workers take input bitstream and LAT buffer, enable the hardware for + decoding tasks, write the result to LAT buffer, and disable the hardware + after the LAT decoding is done. + 2. Core Workqueue, for Core decoder: + Its workers take LAT buffer and output buffer, enable the hardware for + decoding tasks, write the result to output buffer, and disable the hardware + after the Core decoding is done. + + These hardware decode each frame cyclically. + + The hardware might be associated with different SMI-common devices. + To prevent IOMMU faults during DRAM access in such cases, each hardware with + the unique SMI-common device must be placed under a separate parent node in + the device tree. + + LAT-SoC refers to another hardware block that connected to additional LARB + (local arbiter) ports, such as RDMA and UFO. + It requires independent power and clock control to work with LAT decoder, and + it doesn't have a dedicated interrupt. + + The used video decoding pipeline architecture across various Mediatek SoC: + MT8195: LAT-SoC + LAT + Core + MT8192: LAT + Core + MT8188: LAT + Core + MT8186: Core properties: compatible: diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml index cfabf360f278..a4aacd3eb189 100644 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml @@ -44,7 +44,8 @@ properties: maxItems: 1 iommus: - maxItems: 2 + minItems: 2 + maxItems: 32 description: | Points to the respective IOMMU block with master port as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml index 83c020a673d6..5b15f8977f67 100644 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml @@ -39,7 +39,7 @@ properties: iommus: minItems: 2 - maxItems: 4 + maxItems: 32 description: | Points to the respective IOMMU block with master port as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. diff --git a/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml index 59b805ca47c5..ede086d55add 100644 --- a/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml +++ b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/microchip,sama5d4-vdec.yaml# @@ -36,12 +35,12 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/at91.h> - #include <dt-bindings/interrupt-controller/irq.h> - - vdec0: vdec@300000 { - compatible = "microchip,sama5d4-vdec"; - reg = <0x00300000 0x100000>; - interrupts = <19 IRQ_TYPE_LEVEL_HIGH 4>; - clocks = <&pmc PMC_TYPE_PERIPHERAL 19>; - }; + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/interrupt-controller/irq.h> + + vdec@300000 { + compatible = "microchip,sama5d4-vdec"; + reg = <0x00300000 0x100000>; + interrupts = <19 IRQ_TYPE_LEVEL_HIGH 4>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 19>; + }; diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml index 4d5348d456a1..f43b91984f01 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml @@ -21,6 +21,7 @@ properties: enum: - fsl,imx8mn-isi - fsl,imx8mp-isi + - fsl,imx8ulp-isi - fsl,imx93-isi reg: @@ -75,6 +76,7 @@ allOf: contains: enum: - fsl,imx8mn-isi + - fsl,imx8ulp-isi - fsl,imx93-isi then: properties: diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml index 3d58f02b0c5d..19528262810a 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml# @@ -44,26 +43,26 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/imx8mq-clock.h> - #include <dt-bindings/power/imx8mq-power.h> - #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx8mq-clock.h> + #include <dt-bindings/power/imx8mq-power.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> - vpu_g1: video-codec@38300000 { - compatible = "nxp,imx8mq-vpu-g1"; - reg = <0x38300000 0x10000>; - interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>; - power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G1>; - }; + video-codec@38300000 { + compatible = "nxp,imx8mq-vpu-g1"; + reg = <0x38300000 0x10000>; + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>; + power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G1>; + }; - | - #include <dt-bindings/clock/imx8mq-clock.h> - #include <dt-bindings/power/imx8mq-power.h> - #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx8mq-clock.h> + #include <dt-bindings/power/imx8mq-power.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> - vpu_g2: video-codec@38300000 { - compatible = "nxp,imx8mq-vpu-g2"; - reg = <0x38310000 0x10000>; - interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clk IMX8MQ_CLK_VPU_G2_ROOT>; - power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G2>; - }; + video-codec@38300000 { + compatible = "nxp,imx8mq-vpu-g2"; + reg = <0x38310000 0x10000>; + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_VPU_G2_ROOT>; + power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G2>; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml index 9cc0a968a401..3469a43f00d4 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/qcom,msm8916-camss.yaml# diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml index 9410f13ca97c..da140c2e3d3f 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml @@ -45,6 +45,7 @@ properties: required: - compatible + deprecated: true additionalProperties: false video-encoder: @@ -57,13 +58,12 @@ properties: required: - compatible + deprecated: true additionalProperties: false required: - compatible - iommus - - video-decoder - - video-encoder unevaluatedProperties: false @@ -83,12 +83,4 @@ examples: power-domains = <&gcc VENUS_GDSC>; iommus = <&apps_iommu 5>; memory-region = <&venus_mem>; - - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; }; diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml index 5cb0e337ea6e..644646de338a 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/qcom,msm8996-camss.yaml# diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml index 5cec1d077cda..83c4a5d95f02 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml @@ -70,6 +70,7 @@ properties: required: - compatible + deprecated: true additionalProperties: false video-encoder: @@ -82,14 +83,13 @@ properties: required: - compatible + deprecated: true additionalProperties: false required: - compatible - power-domain-names - iommus - - video-decoder - - video-encoder unevaluatedProperties: false @@ -114,12 +114,4 @@ examples: "vcodec0_core", "vcodec0_bus"; iommus = <&apps_smmu 0x0c00 0x60>; memory-region = <&venus_mem>; - - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; }; diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml new file mode 100644 index 000000000000..ee35e3bc97ff --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml @@ -0,0 +1,425 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,sc7280-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SC7280 CAMSS ISP + +maintainers: + - Azam Sadiq Pasha Kapatrala Syed <akapatra@quicinc.com> + - Hariram Purushothaman <hariramp@quicinc.com> + +description: + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. + +properties: + compatible: + const: qcom,sc7280-camss + + reg: + maxItems: 15 + + reg-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid_lite0 + - const: csid_lite1 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: vfe0 + - const: vfe1 + - const: vfe2 + - const: vfe_lite0 + - const: vfe_lite1 + + clocks: + maxItems: 33 + + clock-names: + items: + - const: camnoc_axi + - const: cpas_ahb + - const: csiphy0 + - const: csiphy0_timer + - const: csiphy1 + - const: csiphy1_timer + - const: csiphy2 + - const: csiphy2_timer + - const: csiphy3 + - const: csiphy3_timer + - const: csiphy4 + - const: csiphy4_timer + - const: gcc_axi_hf + - const: gcc_axi_sf + - const: icp_ahb + - const: vfe0 + - const: vfe0_axi + - const: vfe0_cphy_rx + - const: vfe0_csid + - const: vfe1 + - const: vfe1_axi + - const: vfe1_cphy_rx + - const: vfe1_csid + - const: vfe2 + - const: vfe2_axi + - const: vfe2_cphy_rx + - const: vfe2_csid + - const: vfe_lite0 + - const: vfe_lite0_cphy_rx + - const: vfe_lite0_csid + - const: vfe_lite1 + - const: vfe_lite1_cphy_rx + - const: vfe_lite1_csid + + interrupts: + maxItems: 15 + + interrupt-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid_lite0 + - const: csid_lite1 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: vfe0 + - const: vfe1 + - const: vfe2 + - const: vfe_lite0 + - const: vfe_lite1 + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: ahb + - const: hf_0 + + iommus: + maxItems: 1 + + power-domains: + items: + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller. + - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller. + + power-domain-names: + items: + - const: ife0 + - const: ife1 + - const: ife2 + - const: top + + vdda-phy-supply: + description: + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: + description: + Phandle to 1.8V regulator supply to PHY refclk pll block. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + description: + CSI input ports. + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSIPHY 0. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSIPHY 1. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - data-lanes + + port@2: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSIPHY 2. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - data-lanes + + port@3: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSIPHY 3. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - data-lanes + + port@4: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSIPHY 4. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - data-lanes + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - interrupts + - interrupt-names + - interconnects + - interconnect-names + - iommus + - power-domains + - power-domain-names + - vdda-phy-supply + - vdda-pll-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,camcc-sc7280.h> + #include <dt-bindings/clock/qcom,gcc-sc7280.h> + #include <dt-bindings/interconnect/qcom,sc7280.h> + #include <dt-bindings/interconnect/qcom,icc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + isp@acb3000 { + compatible = "qcom,sc7280-camss"; + + reg = <0x0 0x0acb3000 0x0 0x1000>, + <0x0 0x0acba000 0x0 0x1000>, + <0x0 0x0acc1000 0x0 0x1000>, + <0x0 0x0acc8000 0x0 0x1000>, + <0x0 0x0accf000 0x0 0x1000>, + <0x0 0x0ace0000 0x0 0x2000>, + <0x0 0x0ace2000 0x0 0x2000>, + <0x0 0x0ace4000 0x0 0x2000>, + <0x0 0x0ace6000 0x0 0x2000>, + <0x0 0x0ace8000 0x0 0x2000>, + <0x0 0x0acaf000 0x0 0x4000>, + <0x0 0x0acb6000 0x0 0x4000>, + <0x0 0x0acbd000 0x0 0x4000>, + <0x0 0x0acc4000 0x0 0x4000>, + <0x0 0x0accb000 0x0 0x4000>; + reg-names = "csid0", + "csid1", + "csid2", + "csid_lite0", + "csid_lite1", + "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "vfe0", + "vfe1", + "vfe2", + "vfe_lite0", + "vfe_lite1"; + + clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>, + <&camcc CAM_CC_CPAS_AHB_CLK>, + <&camcc CAM_CC_CSIPHY0_CLK>, + <&camcc CAM_CC_CSI0PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY1_CLK>, + <&camcc CAM_CC_CSI1PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY2_CLK>, + <&camcc CAM_CC_CSI2PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY3_CLK>, + <&camcc CAM_CC_CSI3PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY4_CLK>, + <&camcc CAM_CC_CSI4PHYTIMER_CLK>, + <&gcc GCC_CAMERA_HF_AXI_CLK>, + <&gcc GCC_CAMERA_SF_AXI_CLK>, + <&camcc CAM_CC_ICP_AHB_CLK>, + <&camcc CAM_CC_IFE_0_CLK>, + <&camcc CAM_CC_IFE_0_AXI_CLK>, + <&camcc CAM_CC_IFE_0_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_0_CSID_CLK>, + <&camcc CAM_CC_IFE_1_CLK>, + <&camcc CAM_CC_IFE_1_AXI_CLK>, + <&camcc CAM_CC_IFE_1_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_1_CSID_CLK>, + <&camcc CAM_CC_IFE_2_CLK>, + <&camcc CAM_CC_IFE_2_AXI_CLK>, + <&camcc CAM_CC_IFE_2_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_2_CSID_CLK>, + <&camcc CAM_CC_IFE_LITE_0_CLK>, + <&camcc CAM_CC_IFE_LITE_0_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_LITE_0_CSID_CLK>, + <&camcc CAM_CC_IFE_LITE_1_CLK>, + <&camcc CAM_CC_IFE_LITE_1_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_LITE_1_CSID_CLK>; + clock-names = "camnoc_axi", + "cpas_ahb", + "csiphy0", + "csiphy0_timer", + "csiphy1", + "csiphy1_timer", + "csiphy2", + "csiphy2_timer", + "csiphy3", + "csiphy3_timer", + "csiphy4", + "csiphy4_timer", + "gcc_axi_hf", + "gcc_axi_sf", + "icp_ahb", + "vfe0", + "vfe0_axi", + "vfe0_cphy_rx", + "vfe0_csid", + "vfe1", + "vfe1_axi", + "vfe1_cphy_rx", + "vfe1_csid", + "vfe2", + "vfe2_axi", + "vfe2_cphy_rx", + "vfe2_csid", + "vfe_lite0", + "vfe_lite0_cphy_rx", + "vfe_lite0_csid", + "vfe_lite1", + "vfe_lite1_cphy_rx", + "vfe_lite1_csid"; + + interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 640 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 641 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "csid0", + "csid1", + "csid2", + "csid_lite0", + "csid_lite1", + "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "vfe0", + "vfe1", + "vfe2", + "vfe_lite0", + "vfe_lite1"; + + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY + &cnoc2 SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>, + <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>; + interconnect-names = "ahb", + "hf_0"; + + iommus = <&apps_smmu 0x800 0x4e0>; + + power-domains = <&camcc CAM_CC_IFE_0_GDSC>, + <&camcc CAM_CC_IFE_1_GDSC>, + <&camcc CAM_CC_IFE_2_GDSC>, + <&camcc CAM_CC_TITAN_TOP_GDSC>; + power-domain-names = "ife0", + "ife1", + "ife2", + "top"; + + vdda-phy-supply = <&vreg_l10c_0p88>; + vdda-pll-supply = <&vreg_l6b_1p2>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml index 10c334e6b3dc..413c5b4ee650 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml @@ -68,6 +68,7 @@ properties: required: - compatible + deprecated: true additionalProperties: false video-encoder: @@ -80,14 +81,13 @@ properties: required: - compatible + deprecated: true additionalProperties: false required: - compatible - power-domain-names - iommus - - video-decoder - - video-encoder unevaluatedProperties: false @@ -125,14 +125,6 @@ examples: memory-region = <&video_mem>; - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; - video-firmware { iommus = <&apps_smmu 0x21a2 0x0>; }; diff --git a/Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml index c0bc31709873..9936f0132417 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml @@ -328,26 +328,26 @@ examples: vdda-phy-supply = <&vreg_l6d>; vdda-pll-supply = <&vreg_l4d>; - interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 640 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 641 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 758 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 759 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 760 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 761 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 762 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 764 IRQ_TYPE_LEVEL_HIGH>; + interrupts = <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 640 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 641 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 758 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 759 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 760 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 761 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 762 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 764 IRQ_TYPE_EDGE_RISING>; interrupt-names = "csid1_lite", "vfe_lite1", diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml index 584106e275f6..68d8670557f5 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/qcom,sdm660-camss.yaml# diff --git a/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml new file mode 100644 index 000000000000..35c40fe22376 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml @@ -0,0 +1,318 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,sdm670-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SDM670 Camera Subsystem (CAMSS) + +maintainers: + - Richard Acayan <mailingradian@gmail.com> + +description: + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. + +properties: + compatible: + const: qcom,sdm670-camss + + reg: + maxItems: 9 + + reg-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: vfe0 + - const: vfe1 + - const: vfe_lite + + interrupts: + maxItems: 9 + + interrupt-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: vfe0 + - const: vfe1 + - const: vfe_lite + + clocks: + maxItems: 22 + + clock-names: + items: + - const: camnoc_axi + - const: cpas_ahb + - const: csi0 + - const: csi1 + - const: csi2 + - const: csiphy0 + - const: csiphy0_timer + - const: csiphy1 + - const: csiphy1_timer + - const: csiphy2 + - const: csiphy2_timer + - const: gcc_camera_ahb + - const: gcc_camera_axi + - const: soc_ahb + - const: vfe0 + - const: vfe0_axi + - const: vfe0_cphy_rx + - const: vfe1 + - const: vfe1_axi + - const: vfe1_cphy_rx + - const: vfe_lite + - const: vfe_lite_cphy_rx + + iommus: + maxItems: 4 + + power-domains: + items: + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. + - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller. + + power-domain-names: + items: + - const: ife0 + - const: ife1 + - const: top + + vdda-phy-supply: + description: + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: + description: + Phandle to 1.8V regulator supply to PHY refclk pll block. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + description: + CSI input ports. + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data from CSIPHY0. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data from CSIPHY1. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@2: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data from CSIPHY2. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - clocks + - clock-names + - iommus + - power-domains + - power-domain-names + - vdda-phy-supply + - vdda-pll-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,camcc-sdm845.h> + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + isp@acb3000 { + compatible = "qcom,sdm670-camss"; + + reg = <0 0x0acb3000 0 0x1000>, + <0 0x0acba000 0 0x1000>, + <0 0x0acc8000 0 0x1000>, + <0 0x0ac65000 0 0x1000>, + <0 0x0ac66000 0 0x1000>, + <0 0x0ac67000 0 0x1000>, + <0 0x0acaf000 0 0x4000>, + <0 0x0acb6000 0 0x4000>, + <0 0x0acc4000 0 0x4000>; + reg-names = "csid0", + "csid1", + "csid2", + "csiphy0", + "csiphy1", + "csiphy2", + "vfe0", + "vfe1", + "vfe_lite"; + + interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "csid0", + "csid1", + "csid2", + "csiphy0", + "csiphy1", + "csiphy2", + "vfe0", + "vfe1", + "vfe_lite"; + + clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>, + <&camcc CAM_CC_CPAS_AHB_CLK>, + <&camcc CAM_CC_IFE_0_CSID_CLK>, + <&camcc CAM_CC_IFE_1_CSID_CLK>, + <&camcc CAM_CC_IFE_LITE_CSID_CLK>, + <&camcc CAM_CC_CSIPHY0_CLK>, + <&camcc CAM_CC_CSI0PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY1_CLK>, + <&camcc CAM_CC_CSI1PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY2_CLK>, + <&camcc CAM_CC_CSI2PHYTIMER_CLK>, + <&gcc GCC_CAMERA_AHB_CLK>, + <&gcc GCC_CAMERA_AXI_CLK>, + <&camcc CAM_CC_SOC_AHB_CLK>, + <&camcc CAM_CC_IFE_0_CLK>, + <&camcc CAM_CC_IFE_0_AXI_CLK>, + <&camcc CAM_CC_IFE_0_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_1_CLK>, + <&camcc CAM_CC_IFE_1_AXI_CLK>, + <&camcc CAM_CC_IFE_1_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_LITE_CLK>, + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>; + clock-names = "camnoc_axi", + "cpas_ahb", + "csi0", + "csi1", + "csi2", + "csiphy0", + "csiphy0_timer", + "csiphy1", + "csiphy1_timer", + "csiphy2", + "csiphy2_timer", + "gcc_camera_ahb", + "gcc_camera_axi", + "soc_ahb", + "vfe0", + "vfe0_axi", + "vfe0_cphy_rx", + "vfe1", + "vfe1_axi", + "vfe1_cphy_rx", + "vfe_lite", + "vfe_lite_cphy_rx"; + + iommus = <&apps_smmu 0x808 0x0>, + <&apps_smmu 0x810 0x8>, + <&apps_smmu 0xc08 0x0>, + <&apps_smmu 0xc10 0x8>; + + power-domains = <&camcc IFE_0_GDSC>, + <&camcc IFE_1_GDSC>, + <&camcc TITAN_TOP_GDSC>; + power-domain-names = "ife0", + "ife1", + "top"; + + vdda-phy-supply = <&vreg_l1a_1p225>; + vdda-pll-supply = <&vreg_l8a_1p8>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + csiphy_ep0: endpoint { + clock-lanes = <7>; + data-lanes = <0 1 2 3>; + remote-endpoint = <&front_sensor_ep>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml index ec4380a0a03f..289494f561e5 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/qcom,sdm845-camss.yaml# @@ -296,16 +295,16 @@ examples: "vfe_lite_cphy_rx", "vfe_lite_src"; - interrupts = <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>; + interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>; interrupt-names = "csid0", "csid1", diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml index 6228fd2b3246..c839cb1ebc09 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml @@ -70,6 +70,7 @@ properties: required: - compatible + deprecated: true additionalProperties: false video-core1: @@ -82,14 +83,13 @@ properties: required: - compatible + deprecated: true additionalProperties: false required: - compatible - power-domain-names - iommus - - video-core0 - - video-core1 unevaluatedProperties: false @@ -119,12 +119,4 @@ examples: iommus = <&apps_smmu 0x10a0 0x8>, <&apps_smmu 0x10b0 0x0>; memory-region = <&venus_mem>; - - video-core0 { - compatible = "venus-decoder"; - }; - - video-core1 { - compatible = "venus-encoder"; - }; }; diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml index fa5073c0fd1e..a372d991e652 100644 --- a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/qcom,sm8250-camss.yaml# @@ -329,20 +328,20 @@ examples: vdda-phy-supply = <&vreg_l5a_0p88>; vdda-pll-supply = <&vreg_l9a_1p2>; - interrupts = <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>; + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 86 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>; interrupt-names = "csiphy0", "csiphy1", "csiphy2", diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml index f66033ae8b59..da54493220c9 100644 --- a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml @@ -73,6 +73,7 @@ properties: required: - compatible + deprecated: true additionalProperties: false video-encoder: @@ -85,6 +86,7 @@ properties: required: - compatible + deprecated: true additionalProperties: false required: @@ -95,8 +97,6 @@ required: - iommus - resets - reset-names - - video-decoder - - video-encoder unevaluatedProperties: false @@ -132,12 +132,4 @@ examples: resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>, <&videocc VIDEO_CC_MVS0C_CLK_ARES>; reset-names = "bus", "core"; - - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; }; diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml new file mode 100644 index 000000000000..cd34f14916b4 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml @@ -0,0 +1,597 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,sm8550-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM8550 Camera Subsystem (CAMSS) + +maintainers: + - Depeng Shao <quic_depengs@quicinc.com> + +description: + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. + +properties: + compatible: + const: qcom,sm8550-camss + + reg: + maxItems: 19 + + reg-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid_lite0 + - const: csid_lite1 + - const: csid_wrapper + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: csiphy5 + - const: csiphy6 + - const: csiphy7 + - const: vfe0 + - const: vfe1 + - const: vfe2 + - const: vfe_lite0 + - const: vfe_lite1 + + clocks: + maxItems: 36 + + clock-names: + items: + - const: camnoc_axi + - const: cpas_ahb + - const: cpas_fast_ahb_clk + - const: cpas_ife_lite + - const: cpas_vfe0 + - const: cpas_vfe1 + - const: cpas_vfe2 + - const: csid + - const: csiphy0 + - const: csiphy0_timer + - const: csiphy1 + - const: csiphy1_timer + - const: csiphy2 + - const: csiphy2_timer + - const: csiphy3 + - const: csiphy3_timer + - const: csiphy4 + - const: csiphy4_timer + - const: csiphy5 + - const: csiphy5_timer + - const: csiphy6 + - const: csiphy6_timer + - const: csiphy7 + - const: csiphy7_timer + - const: csiphy_rx + - const: gcc_axi_hf + - const: vfe0 + - const: vfe0_fast_ahb + - const: vfe1 + - const: vfe1_fast_ahb + - const: vfe2 + - const: vfe2_fast_ahb + - const: vfe_lite + - const: vfe_lite_ahb + - const: vfe_lite_cphy_rx + - const: vfe_lite_csid + + interrupts: + maxItems: 18 + + interrupt-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid_lite0 + - const: csid_lite1 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: csiphy5 + - const: csiphy6 + - const: csiphy7 + - const: vfe0 + - const: vfe1 + - const: vfe2 + - const: vfe_lite0 + - const: vfe_lite1 + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: ahb + - const: hf_0_mnoc + + iommus: + maxItems: 1 + + power-domains: + items: + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller. + - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller. + + power-domain-names: + items: + - const: ife0 + - const: ife1 + - const: ife2 + - const: top + + vdda-phy-supply: + description: + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: + description: + Phandle to 1.2V regulator supply to PHY refclk pll block. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + description: + CSI input ports. + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI0. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI1. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@2: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI2. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@3: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI3. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@4: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI4. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@5: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI5. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@6: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI6. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@7: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI7. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - interrupts + - interrupt-names + - interconnects + - interconnect-names + - iommus + - power-domains + - power-domain-names + - vdda-phy-supply + - vdda-pll-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,sm8550-camcc.h> + #include <dt-bindings/clock/qcom,sm8550-gcc.h> + #include <dt-bindings/interconnect/qcom,icc.h> + #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + isp@acb7000 { + compatible = "qcom,sm8550-camss"; + + reg = <0 0x0acb7000 0 0xd00>, + <0 0x0acb9000 0 0xd00>, + <0 0x0acbb000 0 0xd00>, + <0 0x0acca000 0 0xa00>, + <0 0x0acce000 0 0xa00>, + <0 0x0acb6000 0 0x1000>, + <0 0x0ace4000 0 0x2000>, + <0 0x0ace6000 0 0x2000>, + <0 0x0ace8000 0 0x2000>, + <0 0x0acea000 0 0x2000>, + <0 0x0acec000 0 0x2000>, + <0 0x0acee000 0 0x2000>, + <0 0x0acf0000 0 0x2000>, + <0 0x0acf2000 0 0x2000>, + <0 0x0ac62000 0 0xf000>, + <0 0x0ac71000 0 0xf000>, + <0 0x0ac80000 0 0xf000>, + <0 0x0accb000 0 0x1800>, + <0 0x0accf000 0 0x1800>; + reg-names = "csid0", + "csid1", + "csid2", + "csid_lite0", + "csid_lite1", + "csid_wrapper", + "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "csiphy5", + "csiphy6", + "csiphy7", + "vfe0", + "vfe1", + "vfe2", + "vfe_lite0", + "vfe_lite1"; + + clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>, + <&camcc CAM_CC_CPAS_AHB_CLK>, + <&camcc CAM_CC_CPAS_FAST_AHB_CLK>, + <&camcc CAM_CC_CPAS_IFE_LITE_CLK>, + <&camcc CAM_CC_CPAS_IFE_0_CLK>, + <&camcc CAM_CC_CPAS_IFE_1_CLK>, + <&camcc CAM_CC_CPAS_IFE_2_CLK>, + <&camcc CAM_CC_CSID_CLK>, + <&camcc CAM_CC_CSIPHY0_CLK>, + <&camcc CAM_CC_CSI0PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY1_CLK>, + <&camcc CAM_CC_CSI1PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY2_CLK>, + <&camcc CAM_CC_CSI2PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY3_CLK>, + <&camcc CAM_CC_CSI3PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY4_CLK>, + <&camcc CAM_CC_CSI4PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY5_CLK>, + <&camcc CAM_CC_CSI5PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY6_CLK>, + <&camcc CAM_CC_CSI6PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY7_CLK>, + <&camcc CAM_CC_CSI7PHYTIMER_CLK>, + <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>, + <&gcc GCC_CAMERA_HF_AXI_CLK>, + <&camcc CAM_CC_IFE_0_CLK>, + <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>, + <&camcc CAM_CC_IFE_1_CLK>, + <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>, + <&camcc CAM_CC_IFE_2_CLK>, + <&camcc CAM_CC_IFE_2_FAST_AHB_CLK>, + <&camcc CAM_CC_IFE_LITE_CLK>, + <&camcc CAM_CC_IFE_LITE_AHB_CLK>, + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_LITE_CSID_CLK>; + clock-names = "camnoc_axi", + "cpas_ahb", + "cpas_fast_ahb_clk", + "cpas_ife_lite", + "cpas_vfe0", + "cpas_vfe1", + "cpas_vfe2", + "csid", + "csiphy0", + "csiphy0_timer", + "csiphy1", + "csiphy1_timer", + "csiphy2", + "csiphy2_timer", + "csiphy3", + "csiphy3_timer", + "csiphy4", + "csiphy4_timer", + "csiphy5", + "csiphy5_timer", + "csiphy6", + "csiphy6_timer", + "csiphy7", + "csiphy7_timer", + "csiphy_rx", + "gcc_axi_hf", + "vfe0", + "vfe0_fast_ahb", + "vfe1", + "vfe1_fast_ahb", + "vfe2", + "vfe2_fast_ahb", + "vfe_lite", + "vfe_lite_ahb", + "vfe_lite_cphy_rx", + "vfe_lite_csid"; + + interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 278 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 277 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 602 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 604 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 688 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "csid0", + "csid1", + "csid2", + "csid_lite0", + "csid_lite1", + "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "csiphy5", + "csiphy6", + "csiphy7", + "vfe0", + "vfe1", + "vfe2", + "vfe_lite0", + "vfe_lite1"; + + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY + &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>, + <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>; + interconnect-names = "ahb", + "hf_0_mnoc"; + + iommus = <&apps_smmu 0x800 0x20>; + + power-domains = <&camcc CAM_CC_IFE_0_GDSC>, + <&camcc CAM_CC_IFE_1_GDSC>, + <&camcc CAM_CC_IFE_2_GDSC>, + <&camcc CAM_CC_TITAN_TOP_GDSC>; + power-domain-names = "ife0", + "ife1", + "ife2", + "top"; + + vdda-phy-supply = <&vreg_l1e_0p88>; + vdda-pll-supply = <&vreg_l3e_1p2>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + csiphy_ep0: endpoint@0 { + reg = <0>; + clock-lanes = <7>; + data-lanes = <0 1>; + remote-endpoint = <&sensor_ep>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml new file mode 100644 index 000000000000..e424ea84c211 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,sm8550-iris.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm iris video encode and decode accelerators + +maintainers: + - Vikash Garodia <quic_vgarodia@quicinc.com> + - Dikshita Agarwal <quic_dikshita@quicinc.com> + +description: + The iris video processing unit is a video encode and decode accelerator + present on Qualcomm platforms. + +allOf: + - $ref: qcom,venus-common.yaml# + +properties: + compatible: + const: qcom,sm8550-iris + + power-domains: + maxItems: 4 + + power-domain-names: + items: + - const: venus + - const: vcodec0 + - const: mxc + - const: mmcx + + clocks: + maxItems: 3 + + clock-names: + items: + - const: iface + - const: core + - const: vcodec0_core + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: cpu-cfg + - const: video-mem + + resets: + maxItems: 1 + + reset-names: + items: + - const: bus + + iommus: + maxItems: 2 + + dma-coherent: true + + operating-points-v2: true + + opp-table: + type: object + +required: + - compatible + - power-domain-names + - interconnects + - interconnect-names + - resets + - reset-names + - iommus + - dma-coherent + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,sm8550-gcc.h> + #include <dt-bindings/clock/qcom,sm8450-videocc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interconnect/qcom,icc.h> + #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h> + #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> + + video-codec@aa00000 { + compatible = "qcom,sm8550-iris"; + reg = <0x0aa00000 0xf0000>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + + power-domains = <&videocc VIDEO_CC_MVS0C_GDSC>, + <&videocc VIDEO_CC_MVS0_GDSC>, + <&rpmhpd RPMHPD_MXC>, + <&rpmhpd RPMHPD_MMCX>; + power-domain-names = "venus", "vcodec0", "mxc", "mmcx"; + + clocks = <&gcc GCC_VIDEO_AXI0_CLK>, + <&videocc VIDEO_CC_MVS0C_CLK>, + <&videocc VIDEO_CC_MVS0_CLK>; + clock-names = "iface", "core", "vcodec0_core"; + + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS + &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ALWAYS>, + <&mmss_noc MASTER_VIDEO QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>; + interconnect-names = "cpu-cfg", "video-mem"; + + memory-region = <&video_mem>; + + resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>; + reset-names = "bus"; + + iommus = <&apps_smmu 0x1940 0x0000>, + <&apps_smmu 0x1947 0x0000>; + dma-coherent; + + operating-points-v2 = <&iris_opp_table>; + + iris_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-240000000 { + opp-hz = /bits/ 64 <240000000>; + required-opps = <&rpmhpd_opp_svs>, + <&rpmhpd_opp_low_svs>; + }; + + opp-338000000 { + opp-hz = /bits/ 64 <338000000>; + required-opps = <&rpmhpd_opp_svs>, + <&rpmhpd_opp_svs>; + }; + + opp-366000000 { + opp-hz = /bits/ 64 <366000000>; + required-opps = <&rpmhpd_opp_svs_l1>, + <&rpmhpd_opp_svs_l1>; + }; + + opp-444000000 { + opp-hz = /bits/ 64 <444000000>; + required-opps = <&rpmhpd_opp_turbo>, + <&rpmhpd_opp_turbo>; + }; + + opp-533333334 { + opp-hz = /bits/ 64 <533333334>; + required-opps = <&rpmhpd_opp_turbo_l1>, + <&rpmhpd_opp_turbo_l1>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml index 947ad699cc5e..d246f5d38427 100644 --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/rockchip,rk3568-vepu.yaml# diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index 719aeb2dc593..8c2501634080 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -1,5 +1,4 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- $id: http://devicetree.org/schemas/media/rockchip-vpu.yaml# @@ -92,18 +91,18 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/rk3288-cru.h> - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/power/rk3288-power.h> - - vpu: video-codec@ff9a0000 { - compatible = "rockchip,rk3288-vpu"; - reg = <0xff9a0000 0x800>; - interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "vepu", "vdpu"; - clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>; - clock-names = "aclk", "hclk"; - power-domains = <&power RK3288_PD_VIDEO>; - iommus = <&vpu_mmu>; - }; + #include <dt-bindings/clock/rk3288-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/rk3288-power.h> + + video-codec@ff9a0000 { + compatible = "rockchip,rk3288-vpu"; + reg = <0xff9a0000 0x800>; + interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "vepu", "vdpu"; + clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>; + clock-names = "aclk", "hclk"; + power-domains = <&power RK3288_PD_VIDEO>; + iommus = <&vpu_mmu>; + }; diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml new file mode 100644 index 000000000000..510e94e9ca3a --- /dev/null +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Device Tree bindings for Synopsys DesignWare HDMI RX Controller + +--- +$id: http://devicetree.org/schemas/media/snps,dw-hdmi-rx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare HDMI RX Controller + +maintainers: + - Shreeya Patel <shreeya.patel@collabora.com> + +description: + Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs + allowing devices to receive and decode high-resolution video streams + from external sources like media players, cameras, laptops, etc. + +properties: + compatible: + items: + - const: rockchip,rk3588-hdmirx-ctrler + - const: snps,dw-hdmi-rx + + reg: + maxItems: 1 + + interrupts: + maxItems: 3 + + interrupt-names: + items: + - const: cec + - const: hdmi + - const: dma + + clocks: + maxItems: 7 + + clock-names: + items: + - const: aclk + - const: audio + - const: cr_para + - const: pclk + - const: ref + - const: hclk_s_hdmirx + - const: hclk_vo1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 4 + + reset-names: + items: + - const: axi + - const: apb + - const: ref + - const: biu + + memory-region: + maxItems: 1 + + hpd-gpios: + description: GPIO specifier for HPD. + maxItems: 1 + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the syscon node for the general register file + containing HDMIRX PHY status bits. + + rockchip,vo1-grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the syscon node for the Video Output GRF register + to enable EDID transfer through SDAIN and SCLIN. + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - resets + - pinctrl-0 + - hpd-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rockchip,rk3588-cru.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/power/rk3588-power.h> + #include <dt-bindings/reset/rockchip,rk3588-cru.h> + hdmi_receiver: hdmi-receiver@fdee0000 { + compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx"; + reg = <0xfdee0000 0x6000>; + interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>, + <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH 0>, + <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>; + interrupt-names = "cec", "hdmi", "dma"; + clocks = <&cru ACLK_HDMIRX>, + <&cru CLK_HDMIRX_AUD>, + <&cru CLK_CR_PARA>, + <&cru PCLK_HDMIRX>, + <&cru CLK_HDMIRX_REF>, + <&cru PCLK_S_HDMIRX>, + <&cru HCLK_VO1>; + clock-names = "aclk", + "audio", + "cr_para", + "pclk", + "ref", + "hclk_s_hdmirx", + "hclk_vo1"; + power-domains = <&power RK3588_PD_VO1>; + resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>, + <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>; + reset-names = "axi", "apb", "ref", "biu"; + memory-region = <&hdmi_receiver_cma>; + pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>; + pinctrl-names = "default"; + hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>; + }; diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmipp.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmipp.yaml index 87731f3ce7bd..7b03a77adbce 100644 --- a/Documentation/devicetree/bindings/media/st,stm32-dcmipp.yaml +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmipp.yaml @@ -12,7 +12,9 @@ maintainers: properties: compatible: - const: st,stm32mp13-dcmipp + enum: + - st,stm32mp13-dcmipp + - st,stm32mp25-dcmipp reg: maxItems: 1 @@ -21,11 +23,24 @@ properties: maxItems: 1 clocks: - maxItems: 1 + items: + - description: bus clock + - description: csi clock + minItems: 1 + + clock-names: + items: + - const: kclk + - const: mclk + minItems: 1 resets: maxItems: 1 + access-controllers: + minItems: 1 + maxItems: 2 + port: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false @@ -39,7 +54,7 @@ properties: properties: bus-type: - enum: [5, 6] + enum: [4, 5, 6] default: 5 bus-width: @@ -50,9 +65,6 @@ properties: hsync-active: true vsync-active: true - required: - - pclk-sample - required: - compatible - reg @@ -61,6 +73,35 @@ required: - resets - port +allOf: + - if: + properties: + compatible: + contains: + enum: + - st,stm32mp13-dcmipp + then: + properties: + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + + port: + properties: + endpoint: + properties: + bus-type: + enum: [5, 6] + else: + properties: + clocks: + minItems: 2 + + clock-names: + minItems: 2 + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-csi.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-csi.yaml new file mode 100644 index 000000000000..e9fa3cfea5d2 --- /dev/null +++ b/Documentation/devicetree/bindings/media/st,stm32mp25-csi.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/st,stm32mp25-csi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STM32 CSI controller + +description: + The STM32 CSI controller, coupled with a D-PHY allows connecting a CSI-2 + based camera to the DCMIPP camera pipeline. + +maintainers: + - Alain Volmat <alain.volmat@foss.st.com> + +properties: + compatible: + enum: + - st,stm32mp25-csi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 3 + + clock-names: + items: + - const: pclk + - const: txesc + - const: csi2phy + + resets: + maxItems: 1 + + vdd-supply: + description: Digital core power supply (0.91V) + + vdda18-supply: + description: System analog power supply (1.8V) + + access-controllers: + minItems: 1 + maxItems: 2 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port node + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + items: + - const: 1 + - const: 2 + + required: + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Output port node + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/st,stm32mp25-rcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/media/video-interfaces.h> + #include <dt-bindings/reset/st,stm32mp25-rcc.h> + csi@48020000 { + compatible = "st,stm32mp25-csi"; + reg = <0x48020000 0x2000>; + interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>; + resets = <&rcc CSI_R>; + clocks = <&rcc CK_KER_CSI>, <&rcc CK_KER_CSITXESC>, <&rcc CK_KER_CSIPHY>; + clock-names = "pclk", "txesc", "csi2phy"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&imx335_ep>; + data-lanes = <1 2>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&dcmipp_0>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml b/Documentation/devicetree/bindings/media/video-interfaces.yaml index 26e3e7d7c67b..038e85b45bef 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.yaml +++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml @@ -210,6 +210,27 @@ properties: lane-polarities property is omitted, the value must be interpreted as 0 (normal). This property is valid for serial busses only. + line-orders: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + items: + enum: + - 0 # ABC + - 1 # ACB + - 2 # BAC + - 3 # BCA + - 4 # CAB + - 5 # CBA + description: + An array of line orders of the CSI-2 C-PHY data lanes. The order of the + lanes are the same as in data-lanes property. Valid values are 0-5 as + defined in the MIPI Discovery and Configuration (DisCo) Specification for + Imaging. The length of the array must be the same length as the + data-lanes property. If the line-orders property is omitted, the value + shall be interpreted as 0 (ABC). This property is valid for CSI-2 C-PHY + busses only. + strobe: $ref: /schemas/types.yaml#/definitions/uint32 enum: [ 0, 1 ] diff --git a/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml index 0c511ab906bf..8b937f90a1fb 100644 --- a/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml @@ -52,10 +52,3 @@ examples: #qca,ddr-wb-channel-cells = <1>; }; - - interrupt-controller { - // ... - qca,ddr-wb-channel-interrupts = <2>, <3>, <4>, <5>; - qca,ddr-wb-channels = <&ddr_ctrl 3>, <&ddr_ctrl 2>, - <&ddr_ctrl 0>, <&ddr_ctrl 1>; - }; diff --git a/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml new file mode 100644 index 000000000000..f805545aa62a --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/atmel,at91sam9260-gpbr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip AT91 General Purpose Backup Registers + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + +description: + The system controller embeds 256 bits of General Purpose Backup + registers organized as 8 32-bit registers. + +properties: + compatible: + oneOf: + - items: + - enum: + - atmel,at91sam9260-gpbr + - const: syscon + - items: + - enum: + - microchip,sam9x60-gpbr + - microchip,sam9x7-gpbr + - const: atmel,at91sam9260-gpbr + - const: syscon + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + syscon@fffffd50 { + compatible = "atmel,at91sam9260-gpbr", "syscon"; + reg = <0xfffffd50 0x10>; + }; diff --git a/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-matrix.yaml b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-matrix.yaml new file mode 100644 index 000000000000..447b3a3edbfc --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-matrix.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/atmel,at91sam9260-matrix.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip AT91 Bus Matrix + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + +description: + The Bus Matrix (MATRIX) implements a multi-layer AHB, based on the + AHB-Lite protocol, that enables parallel access paths between multiple + masters and slaves in a system, thus increasing the overall bandwidth. + +properties: + compatible: + oneOf: + - items: + - enum: + - atmel,at91sam9260-matrix + - atmel,at91sam9261-matrix + - atmel,at91sam9263-matrix + - atmel,at91sam9rl-matrix + - atmel,at91sam9g45-matrix + - atmel,at91sam9n12-matrix + - atmel,at91sam9x5-matrix + - atmel,sama5d3-matrix + - const: syscon + - items: + - enum: + - microchip,sam9x60-matrix + - microchip,sam9x7-matrix + - const: atmel,at91sam9x5-matrix + - const: syscon + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + syscon@ffffec00 { + compatible = "atmel,sama5d3-matrix", "syscon"; + reg = <0xffffec00 0x200>; + }; diff --git a/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt b/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt deleted file mode 100644 index 3c989d1760a2..000000000000 --- a/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt +++ /dev/null @@ -1,18 +0,0 @@ -* Device tree bindings for Atmel GPBR (General Purpose Backup Registers) - -The GPBR are a set of battery-backed registers. - -Required properties: -- compatible: Should be one of the following: - "atmel,at91sam9260-gpbr", "syscon" - "microchip,sam9x60-gpbr", "syscon" - "microchip,sam9x7-gpbr", "microchip,sam9x60-gpbr", "syscon" -- reg: contains offset/length value of the GPBR memory - region. - -Example: - -gpbr: gpbr@fffffd50 { - compatible = "atmel,at91sam9260-gpbr", "syscon"; - reg = <0xfffffd50 0x10>; -}; diff --git a/Documentation/devicetree/bindings/mfd/atmel-matrix.txt b/Documentation/devicetree/bindings/mfd/atmel-matrix.txt deleted file mode 100644 index 6e5f83614e83..000000000000 --- a/Documentation/devicetree/bindings/mfd/atmel-matrix.txt +++ /dev/null @@ -1,26 +0,0 @@ -* Device tree bindings for Atmel Bus Matrix - -The Bus Matrix registers are used to configure Atmel SoCs internal bus -behavior (master/slave priorities, undefined burst length type, ...) - -Required properties: -- compatible: Should be one of the following - "atmel,at91sam9260-matrix", "syscon" - "atmel,at91sam9261-matrix", "syscon" - "atmel,at91sam9263-matrix", "syscon" - "atmel,at91sam9rl-matrix", "syscon" - "atmel,at91sam9g45-matrix", "syscon" - "atmel,at91sam9n12-matrix", "syscon" - "atmel,at91sam9x5-matrix", "syscon" - "atmel,sama5d3-matrix", "syscon" - "microchip,sam9x60-matrix", "syscon" - "microchip,sam9x7-matrix", "atmel,at91sam9x5-matrix", "syscon" -- reg: Contains offset/length value of the Bus Matrix - memory region. - -Example: - -matrix: matrix@ffffec00 { - compatible = "atmel,sama5d3-matrix", "syscon"; - reg = <0xffffec00 0x200>; -}; diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index aac8819bd00b..50f457090066 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -108,9 +108,6 @@ properties: pwm: $ref: /schemas/pwm/google,cros-ec-pwm.yaml# - kbd-led-backlight: - $ref: /schemas/chrome/google,cros-kbd-led-backlight.yaml# - keyboard-controller: $ref: /schemas/input/google,cros-ec-keyb.yaml# diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml index 86451f151a6a..6a89b479d10f 100644 --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml @@ -36,6 +36,7 @@ properties: - enum: - mediatek,mt6323 - mediatek,mt6331 # "mediatek,mt6331" for PMIC MT6331 and MT6332. + - mediatek,mt6328 - mediatek,mt6358 - mediatek,mt6359 - mediatek,mt6397 @@ -88,6 +89,7 @@ properties: oneOf: - enum: - mediatek,mt6323-regulator + - mediatek,mt6328-regulator - mediatek,mt6358-regulator - mediatek,mt6359-regulator - mediatek,mt6397-regulator diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt index 190230216de8..f00827c9b67f 100644 --- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt +++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt @@ -31,6 +31,10 @@ node must be named "audio-codec". Required properties for the audio-codec subnode: - #sound-dai-cells = <1>; +- interrupts : should contain jack detection interrupts, with headset + detect interrupt matching "hs" and microphone bias 2 + detect interrupt matching "mb2" in interrupt-names. +- interrupt-names : Contains "hs", "mb2" The audio-codec provides two DAIs. The first one is connected to the Stereo HiFi DAC and the second one is connected to the Voice DAC. @@ -52,6 +56,8 @@ Example: audio-codec { #sound-dai-cells = <1>; + interrupts-extended = <&cpcap 9 0>, <&cpcap 10 0>; + interrupt-names = "hs", "mb2"; /* HiFi */ port@0 { diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml index 79add913e35c..a503b67f2dbe 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml @@ -42,6 +42,7 @@ properties: - qcom,tcsr-apq8064 - qcom,tcsr-apq8084 - qcom,tcsr-ipq5332 + - qcom,tcsr-ipq5424 - qcom,tcsr-ipq6018 - qcom,tcsr-ipq8064 - qcom,tcsr-ipq8074 diff --git a/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml b/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml new file mode 100644 index 000000000000..877078ac172f --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/qnap,ts433-mcu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: QNAP NAS on-board Microcontroller + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +description: + QNAP embeds a microcontroller on their NAS devices adding system feature + as PWM Fan control, additional LEDs, power button status and more. + +properties: + compatible: + enum: + - qnap,ts433-mcu + +patternProperties: + "^fan-[0-9]+$": + $ref: /schemas/hwmon/fan-common.yaml# + unevaluatedProperties: false + +required: + - compatible + +additionalProperties: false + +examples: + - | + uart { + mcu { + compatible = "qnap,ts433-mcu"; + + fan-0 { + #cooling-cells = <2>; + cooling-levels = <0 64 89 128 166 204 221 238>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml index bb81307dc11b..4fc78efaa550 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml @@ -50,15 +50,15 @@ properties: minimum: 0 maximum: 1 - rohm,charger-sense-resistor-ohms: - minimum: 10000000 - maximum: 50000000 + rohm,charger-sense-resistor-micro-ohms: + minimum: 10000 + maximum: 50000 description: | - BD71827 and BD71828 have SAR ADC for measuring charging currents. - External sense resistor (RSENSE in data sheet) should be used. If - something other but 30MOhm resistor is used the resistance value - should be given here in Ohms. - default: 30000000 + BD71815 has SAR ADC for measuring charging currents. External sense + resistor (RSENSE in data sheet) should be used. If something other + but a 30 mOhm resistor is used the resistance value should be given + here in micro Ohms. + default: 30000 regulators: $ref: /schemas/regulator/rohm,bd71815-regulator.yaml @@ -67,7 +67,7 @@ properties: gpio-reserved-ranges: description: | - Usage of BD71828 GPIO pins can be changed via OTP. This property can be + Usage of BD71815 GPIO pins can be changed via OTP. This property can be used to mark the pins which should not be configured for GPIO. Please see the ../gpio/gpio.txt for more information. @@ -113,7 +113,7 @@ examples: gpio-controller; #gpio-cells = <2>; - rohm,charger-sense-resistor-ohms = <10000000>; + rohm,charger-sense-resistor-micro-ohms = <10000>; regulators { buck1: buck1 { diff --git a/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml b/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml index 8beec7e8e4c6..b023e1ef8d3c 100644 --- a/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml +++ b/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml @@ -67,15 +67,7 @@ patternProperties: "^efuse@[0-9a-f]+$": type: object - additionalProperties: true - properties: - compatible: - enum: - - sprd,sc2720-efuse - - sprd,sc2721-efuse - - sprd,sc2723-efuse - - sprd,sc2730-efuse - - sprd,sc2731-efuse + $ref: /schemas/nvmem/sprd,sc2731-efuse.yaml# "^fuel-gauge@[0-9a-f]+$": type: object @@ -199,7 +191,7 @@ examples: }; }; - adc@480 { + pmic_adc: adc@480 { compatible = "sprd,sc2731-adc"; reg = <0x480>; interrupt-parent = <&sc2731_pmic>; diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index b414de4fa779..4d67ff26d445 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -27,7 +27,7 @@ select: compatible: contains: enum: - - al,alpine-sysfabric-servic + - al,alpine-sysfabric-service - allwinner,sun8i-a83t-system-controller - allwinner,sun8i-h3-system-controller - allwinner,sun8i-v3s-system-controller @@ -103,6 +103,7 @@ select: - rockchip,rk3288-qos - rockchip,rk3368-qos - rockchip,rk3399-qos + - rockchip,rk3562-qos - rockchip,rk3568-qos - rockchip,rk3576-qos - rockchip,rk3588-qos @@ -201,6 +202,7 @@ properties: - rockchip,rk3288-qos - rockchip,rk3368-qos - rockchip,rk3399-qos + - rockchip,rk3562-qos - rockchip,rk3568-qos - rockchip,rk3576-qos - rockchip,rk3588-qos @@ -213,6 +215,7 @@ properties: - ti,am625-dss-oldi-io-ctrl - ti,am62p-cpsw-mac-efuse - ti,am654-dss-oldi-io-ctrl + - ti,j784s4-acspcie-proxy-ctrl - ti,j784s4-pcie-ctrl - ti,keystone-pllctrl - const: syscon diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt deleted file mode 100644 index f9fb412642fe..000000000000 --- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt +++ /dev/null @@ -1,50 +0,0 @@ -* Atmel SSC driver. - -Required properties: -- compatible: "atmel,at91rm9200-ssc" or "atmel,at91sam9g45-ssc" - - atmel,at91rm9200-ssc: support pdc transfer - - atmel,at91sam9g45-ssc: support dma transfer -- reg: Should contain SSC registers location and length -- interrupts: Should contain SSC interrupt -- clock-names: tuple listing input clock names. - Required elements: "pclk" -- clocks: phandles to input clocks. - - -Required properties for devices compatible with "atmel,at91sam9g45-ssc": -- dmas: DMA specifier, consisting of a phandle to DMA controller node, - the memory interface and SSC DMA channel ID (for tx and rx). - See Documentation/devicetree/bindings/dma/atmel-dma.txt for details. -- dma-names: Must be "tx", "rx". - -Optional properties: - - atmel,clk-from-rk-pin: bool property. - - When SSC works in slave mode, according to the hardware design, the - clock can get from TK pin, and also can get from RK pin. So, add - this parameter to choose where the clock from. - - By default the clock is from TK pin, if the clock from RK pin, this - property is needed. - - #sound-dai-cells: Should contain <0>. - - This property makes the SSC into an automatically registered DAI. - -Examples: -- PDC transfer: -ssc0: ssc@fffbc000 { - compatible = "atmel,at91rm9200-ssc"; - reg = <0xfffbc000 0x4000>; - interrupts = <14 4 5>; - clocks = <&ssc0_clk>; - clock-names = "pclk"; -}; - -- DMA transfer: -ssc0: ssc@f0010000 { - compatible = "atmel,at91sam9g45-ssc"; - reg = <0xf0010000 0x4000>; - interrupts = <28 4 5>; - dmas = <&dma0 1 13>, - <&dma0 1 14>; - dma-names = "tx", "rx"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>; -}; diff --git a/Documentation/devicetree/bindings/misc/lwn,bk4-spi.yaml b/Documentation/devicetree/bindings/misc/lwn,bk4-spi.yaml new file mode 100644 index 000000000000..73fbf672e22a --- /dev/null +++ b/Documentation/devicetree/bindings/misc/lwn,bk4-spi.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/lwn,bk4-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Liebherr's BK4 external SPI controller + +maintainers: + - Lukasz Majewski <lukma@denx.de> + +description: | + Liebherr's BK4 external SPI controller is a device which handles data + acquisition from compatible industrial peripherals. + The SPI is used for data and management purposes in both master and + slave modes. + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + const: lwn,bk4-spi + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 30000000 + + fsl,spi-cs-sck-delay: true + + fsl,spi-sck-cs-delay: true + +required: + - compatible + - spi-max-frequency + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + spidev@0 { + compatible = "lwn,bk4-spi"; + reg = <0>; + spi-max-frequency = <30000000>; + fsl,spi-cs-sck-delay = <200>; + fsl,spi-sck-cs-delay = <400>; + }; + }; diff --git a/Documentation/devicetree/bindings/misc/lwn-bk4.txt b/Documentation/devicetree/bindings/misc/lwn-bk4.txt deleted file mode 100644 index d6a8c188c087..000000000000 --- a/Documentation/devicetree/bindings/misc/lwn-bk4.txt +++ /dev/null @@ -1,26 +0,0 @@ -* Liebherr's BK4 controller external SPI - -A device which handles data acquisition from compatible industrial -peripherals. -The SPI is used for data and management purposes in both master and -slave modes. - -Required properties: - -- compatible : Should be "lwn,bk4" - -Required SPI properties: - -- reg : Should be address of the device chip select within - the controller. - -- spi-max-frequency : Maximum SPI clocking speed of device in Hz, should be - 30MHz at most for the Liebherr's BK4 external bus. - -Example: - -spidev0: spi@0 { - compatible = "lwn,bk4"; - spi-max-frequency = <30000000>; - reg = <0>; -}; diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml index 0ccd632d5620..9f3b1edacaa0 100644 --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml @@ -30,38 +30,34 @@ properties: - const: allwinner,sun50i-a100-emmc - const: allwinner,sun50i-a100-mmc - items: - - const: allwinner,sun8i-a83t-mmc + - enum: + - allwinner,sun8i-a83t-mmc + - allwinner,suniv-f1c100s-mmc - const: allwinner,sun7i-a20-mmc - items: - - const: allwinner,sun8i-r40-emmc + - enum: + - allwinner,sun8i-r40-emmc + - allwinner,sun50i-h5-emmc + - allwinner,sun50i-h6-emmc - const: allwinner,sun50i-a64-emmc - items: - - const: allwinner,sun8i-r40-mmc + - enum: + - allwinner,sun8i-r40-mmc + - allwinner,sun50i-h5-mmc + - allwinner,sun50i-h6-mmc - const: allwinner,sun50i-a64-mmc - items: - - const: allwinner,sun50i-h5-emmc - - const: allwinner,sun50i-a64-emmc - - items: - - const: allwinner,sun50i-h5-mmc - - const: allwinner,sun50i-a64-mmc - - items: - - const: allwinner,sun50i-h6-emmc - - const: allwinner,sun50i-a64-emmc - - items: - - const: allwinner,sun50i-h6-mmc - - const: allwinner,sun50i-a64-mmc - - items: - - const: allwinner,sun20i-d1-emmc - - const: allwinner,sun50i-a100-emmc - - items: - - const: allwinner,sun50i-h616-emmc + - enum: + - allwinner,sun20i-d1-emmc + - allwinner,sun50i-h616-emmc + - allwinner,sun55i-a523-emmc - const: allwinner,sun50i-a100-emmc - items: - const: allwinner,sun50i-h616-mmc - const: allwinner,sun50i-a100-mmc - items: - - const: allwinner,suniv-f1c100s-mmc - - const: allwinner,sun7i-a20-mmc + - const: allwinner,sun55i-a523-mmc + - const: allwinner,sun20i-d1-mmc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.txt b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.txt deleted file mode 100644 index 8765c605e6bc..000000000000 --- a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.txt +++ /dev/null @@ -1,54 +0,0 @@ -* Amlogic Meson6, Meson8 and Meson8b SDIO/MMC controller - -The highspeed MMC host controller on Amlogic SoCs provides an interface -for MMC, SD, SDIO and SDHC types of memory cards. - -Supported maximum speeds are the ones of the eMMC standard 4.41 as well -as the speed of SD standard 2.0. - -The hardware provides an internal "mux" which allows up to three slots -to be controlled. Only one slot can be accessed at a time. - -Required properties: - - compatible : must be one of - - "amlogic,meson8-sdio" - - "amlogic,meson8b-sdio" - along with the generic "amlogic,meson-mx-sdio" - - reg : mmc controller base registers - - interrupts : mmc controller interrupt - - #address-cells : must be 1 - - size-cells : must be 0 - - clocks : phandle to clock providers - - clock-names : must contain "core" and "clkin" - -Required child nodes: -A node for each slot provided by the MMC controller is required. -NOTE: due to a driver limitation currently only one slot (= child node) - is supported! - -Required properties on each child node (= slot): - - compatible : must be "mmc-slot" (see mmc.txt within this directory) - - reg : the slot (or "port") ID - -Optional properties on each child node (= slot): - - bus-width : must be 1 or 4 (8-bit bus is not supported) - - for cd and all other additional generic mmc parameters - please refer to mmc.txt within this directory - -Examples: - mmc@c1108c20 { - compatible = "amlogic,meson8-sdio", "amlogic,meson-mx-sdio"; - reg = <0xc1108c20 0x20>; - interrupts = <0 28 1>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&clkc CLKID_SDIO>, <&clkc CLKID_CLK81>; - clock-names = "core", "clkin"; - - slot@1 { - compatible = "mmc-slot"; - reg = <1>; - - bus-width = <4>; - }; - }; diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.yaml new file mode 100644 index 000000000000..0d4d9ca6a8d9 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/amlogic,meson-mx-sdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson6, Meson8 and Meson8b SDIO/MMC controller + +description: | + The highspeed MMC host controller on Amlogic SoCs provides an interface + for MMC, SD, SDIO and SDHC types of memory cards. + + Supported maximum speeds are the ones of the eMMC standard 4.41 as well + as the speed of SD standard 2.0. + + The hardware provides an internal "mux" which allows up to three slots + to be controlled. Only one slot can be accessed at a time. + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +properties: + compatible: + items: + - enum: + - amlogic,meson8-sdio + - amlogic,meson8b-sdio + - const: amlogic,meson-mx-sdio + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: core + - const: clkin + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "slot@[0-2]$": + $ref: mmc-slot.yaml# + description: + A node for each slot provided by the MMC controller + + properties: + reg: + enum: [0, 1, 2] + + bus-width: + enum: [1, 4] + + required: + - compatible + + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + mmc@c1108c20 { + compatible = "amlogic,meson8-sdio", "amlogic,meson-mx-sdio"; + reg = <0xc1108c20 0x20>; + interrupts = <GIC_SPI 28 IRQ_TYPE_EDGE_RISING>; + clocks = <&clk_core>, <&clk_in>; + clock-names = "core", "clkin"; + #address-cells = <1>; + #size-cells = <0>; + + slot@1 { + compatible = "mmc-slot"; + reg = <1>; + bus-width = <4>; + }; + }; diff --git a/Documentation/devicetree/bindings/mmc/atmel,hsmci.yaml b/Documentation/devicetree/bindings/mmc/atmel,hsmci.yaml new file mode 100644 index 000000000000..151b414b9d27 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/atmel,hsmci.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/atmel,hsmci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel High-Speed MultiMedia Card Interface (HSMCI) + +description: + The Atmel HSMCI controller provides an interface for MMC, SD, and SDIO memory + cards. + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Aubin Constans <aubin.constans@microchip.com> + +allOf: + - $ref: mmc-controller.yaml + +properties: + compatible: + const: atmel,hsmci + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + const: rxtx + + clocks: + maxItems: 1 + + clock-names: + const: mci_clk + + "#address-cells": + const: 1 + description: Used for slot IDs. + + "#size-cells": + const: 0 + +patternProperties: + "slot@[0-2]$": + $ref: mmc-slot.yaml + description: A slot node representing an MMC, SD, or SDIO slot. + + properties: + reg: + enum: [0, 1] + + required: + - reg + - bus-width + + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - "#address-cells" + - "#size-cells" + +anyOf: + - required: + - slot@0 + - required: + - slot@1 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/at91.h> + mmc@f0008000 { + compatible = "atmel,hsmci"; + reg = <0xf0008000 0x600>; + interrupts = <12 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mci0_clk>; + clock-names = "mci_clk"; + #address-cells = <1>; + #size-cells = <0>; + + slot@0 { + reg = <0>; + bus-width = <4>; + cd-gpios = <&pioD 15 0>; + cd-inverted; + }; + + slot@1 { + reg = <1>; + bus-width = <4>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mmc/atmel,sama5d2-sdhci.yaml b/Documentation/devicetree/bindings/mmc/atmel,sama5d2-sdhci.yaml index 8c8ade88e8fe..ba75623b7778 100644 --- a/Documentation/devicetree/bindings/mmc/atmel,sama5d2-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/atmel,sama5d2-sdhci.yaml @@ -22,6 +22,7 @@ properties: - items: - enum: - microchip,sam9x7-sdhci + - microchip,sama7d65-sdhci - microchip,sama7g5-sdhci - const: microchip,sam9x60-sdhci diff --git a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt deleted file mode 100644 index 07ad02075a93..000000000000 --- a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt +++ /dev/null @@ -1,73 +0,0 @@ -* Atmel High Speed MultiMedia Card Interface - -This controller on atmel products provides an interface for MMC, SD and SDIO -types of memory cards. - -This file documents differences between the core properties described -by mmc.txt and the properties used by the atmel-mci driver. - -1) MCI node - -Required properties: -- compatible: should be "atmel,hsmci" -- #address-cells: should be one. The cell is the slot id. -- #size-cells: should be zero. -- at least one slot node -- clock-names: tuple listing input clock names. - Required elements: "mci_clk" -- clocks: phandles to input clocks. - -The node contains child nodes for each slot that the platform uses - -Example MCI node: - -mmc0: mmc@f0008000 { - compatible = "atmel,hsmci"; - reg = <0xf0008000 0x600>; - interrupts = <12 4>; - #address-cells = <1>; - #size-cells = <0>; - clock-names = "mci_clk"; - clocks = <&mci0_clk>; - - [ child node definitions...] -}; - -2) slot nodes - -Required properties: -- reg: should contain the slot id. -- bus-width: number of data lines connected to the controller - -Optional properties: -- cd-gpios: specify GPIOs for card detection -- cd-inverted: invert the value of external card detect gpio line -- wp-gpios: specify GPIOs for write protection - -Example slot node: - -slot@0 { - reg = <0>; - bus-width = <4>; - cd-gpios = <&pioD 15 0> - cd-inverted; -}; - -Example full MCI node: -mmc0: mmc@f0008000 { - compatible = "atmel,hsmci"; - reg = <0xf0008000 0x600>; - interrupts = <12 4>; - #address-cells = <1>; - #size-cells = <0>; - slot@0 { - reg = <0>; - bus-width = <4>; - cd-gpios = <&pioD 15 0> - cd-inverted; - }; - slot@1 { - reg = <1>; - bus-width = <4>; - }; -}; diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index b9b999570529..b98a84f93277 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -57,6 +57,7 @@ properties: - fsl,imx8mp-usdhc - fsl,imx8ulp-usdhc - fsl,imx93-usdhc + - fsl,imx94-usdhc - fsl,imx95-usdhc - const: fsl,imx8mm-usdhc - items: diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml index cfe6237716f4..3f48d8292d5b 100644 --- a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml @@ -38,15 +38,9 @@ properties: reg: minItems: 1 - maxItems: 2 - description: | - For "marvell,armada-3700-sdhci", two register areas. The first one - for Xenon IP register. The second one for the Armada 3700 SoC PHY PAD - Voltage Control register. Please follow the examples with compatible - "marvell,armada-3700-sdhci" in below. - Please also check property marvell,pad-type in below. - - For other compatible strings, one register area for Xenon IP. + items: + - description: Xenon IP registers + - description: Armada 3700 SoC PHY PAD Voltage Control register clocks: minItems: 1 @@ -61,6 +55,17 @@ properties: interrupts: maxItems: 1 + marvell,pad-type: + $ref: /schemas/types.yaml#/definitions/string + enum: + - sd + - fixed-1-8v + description: + Type of Armada 3700 SoC PHY PAD Voltage Controller register. If "sd" is + selected, SoC PHY PAD is set as 3.3V at the beginning and is switched to + 1.8V when later in higher speed mode. If "fixed-1-8v" is selected, SoC PHY + PAD is fixed 1.8V, such as for eMMC. + marvell,xenon-sdhc-id: $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 @@ -147,27 +152,18 @@ allOf: then: properties: reg: - items: - - description: Xenon IP registers - - description: Armada 3700 SoC PHY PAD Voltage Control register - - marvell,pad-type: - $ref: /schemas/types.yaml#/definitions/string - enum: - - sd - - fixed-1-8v - description: | - Type of Armada 3700 SoC PHY PAD Voltage Controller register. - If "sd" is selected, SoC PHY PAD is set as 3.3V at the beginning - and is switched to 1.8V when later in higher speed mode. - If "fixed-1-8v" is selected, SoC PHY PAD is fixed 1.8V, such as for - eMMC. - Please follow the examples with compatible - "marvell,armada-3700-sdhci" in below. + minItems: 2 required: - marvell,pad-type + else: + properties: + reg: + maxItems: 1 + + marvell,pad-type: false + - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml new file mode 100644 index 000000000000..9a7235439759 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml @@ -0,0 +1,357 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-controller-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MMC Controller & Slots Common Properties + +maintainers: + - Ulf Hansson <ulf.hansson@linaro.org> + +description: + These properties are common to multiple MMC host controllers and the + possible slots or ports for multi-slot controllers. + +properties: + "#address-cells": + const: 1 + description: + The cell is the SDIO function number if a function subnode is used. + + "#size-cells": + const: 0 + + # Card Detection. + # If none of these properties are supplied, the host native card + # detect will be used. Only one of them should be provided. + + broken-cd: + $ref: /schemas/types.yaml#/definitions/flag + description: + There is no card detection available; polling must be used. + + cd-gpios: + maxItems: 1 + description: + The card detection will be done using the GPIO provided. + + non-removable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Non-removable slot (like eMMC); assume always present. + + # *NOTE* on CD and WP polarity. To use common for all SD/MMC host + # controllers line polarity properties, we have to fix the meaning + # of the "normal" and "inverted" line levels. We choose to follow + # the SDHCI standard, which specifies both those lines as "active + # low." Therefore, using the "cd-inverted" property means, that the + # CD line is active high, i.e. it is high, when a card is + # inserted. Similar logic applies to the "wp-inverted" property. + # + # CD and WP lines can be implemented on the hardware in one of two + # ways: as GPIOs, specified in cd-gpios and wp-gpios properties, or + # as dedicated pins. Polarity of dedicated pins can be specified, + # using *-inverted properties. GPIO polarity can also be specified + # using the GPIO_ACTIVE_LOW flag. This creates an ambiguity in the + # latter case. We choose to use the XOR logic for GPIO CD and WP + # lines. This means, the two properties are "superimposed," for + # example leaving the GPIO_ACTIVE_LOW flag clear and specifying the + # respective *-inverted property property results in a + # double-inversion and actually means the "normal" line polarity is + # in effect. + wp-inverted: + $ref: /schemas/types.yaml#/definitions/flag + description: + The Write Protect line polarity is inverted. + + cd-inverted: + $ref: /schemas/types.yaml#/definitions/flag + description: + The CD line polarity is inverted. + + # Other properties + + bus-width: + description: + Number of data lines. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 4, 8] + default: 1 + + max-frequency: + description: | + Maximum operating frequency of the bus: + - for eMMC, the maximum supported frequency is 200MHz, + - for SD/SDIO cards the SDR104 mode has a max supported + frequency of 208MHz, + - some mmc host controllers do support a max frequency upto + 384MHz. + So, lets keep the maximum supported value here. + + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 400000 + maximum: 384000000 + + disable-wp: + $ref: /schemas/types.yaml#/definitions/flag + description: + When set, no physical write-protect line is present. This + property should only be specified when the controller has a + dedicated write-protect detection logic. If a GPIO is always used + for the write-protect detection logic, it is sufficient to not + specify the wp-gpios property in the absence of a write-protect + line. Not used in combination with eMMC or SDIO. + + wp-gpios: + maxItems: 1 + description: + GPIO to use for the write-protect detection. + + cd-debounce-delay-ms: + description: + Set delay time before detecting card after card insert + interrupt. + + no-1-8-v: + $ref: /schemas/types.yaml#/definitions/flag + description: + When specified, denotes that 1.8V card voltage is not supported + on this system, even if the controller claims it. + + cap-sd-highspeed: + $ref: /schemas/types.yaml#/definitions/flag + description: + SD high-speed timing is supported. + + cap-mmc-highspeed: + $ref: /schemas/types.yaml#/definitions/flag + description: + MMC high-speed timing is supported. + + sd-uhs-sdr12: + $ref: /schemas/types.yaml#/definitions/flag + description: + SD UHS SDR12 speed is supported. + + sd-uhs-sdr25: + $ref: /schemas/types.yaml#/definitions/flag + description: + SD UHS SDR25 speed is supported. + + sd-uhs-sdr50: + $ref: /schemas/types.yaml#/definitions/flag + description: + SD UHS SDR50 speed is supported. + + sd-uhs-sdr104: + $ref: /schemas/types.yaml#/definitions/flag + description: + SD UHS SDR104 speed is supported. + + sd-uhs-ddr50: + $ref: /schemas/types.yaml#/definitions/flag + description: + SD UHS DDR50 speed is supported. + + cap-power-off-card: + $ref: /schemas/types.yaml#/definitions/flag + description: + Powering off the card is safe. + + cap-mmc-hw-reset: + $ref: /schemas/types.yaml#/definitions/flag + description: + eMMC hardware reset is supported + + cap-sdio-irq: + $ref: /schemas/types.yaml#/definitions/flag + description: + enable SDIO IRQ signalling on this interface + + full-pwr-cycle: + $ref: /schemas/types.yaml#/definitions/flag + description: + Full power cycle of the card is supported. + + full-pwr-cycle-in-suspend: + $ref: /schemas/types.yaml#/definitions/flag + description: + Full power cycle of the card in suspend is supported. + + mmc-ddr-1_2v: + $ref: /schemas/types.yaml#/definitions/flag + description: + eMMC high-speed DDR mode (1.2V I/O) is supported. + + mmc-ddr-1_8v: + $ref: /schemas/types.yaml#/definitions/flag + description: + eMMC high-speed DDR mode (1.8V I/O) is supported. + + mmc-ddr-3_3v: + $ref: /schemas/types.yaml#/definitions/flag + description: + eMMC high-speed DDR mode (3.3V I/O) is supported. + + mmc-hs200-1_2v: + $ref: /schemas/types.yaml#/definitions/flag + description: + eMMC HS200 mode (1.2V I/O) is supported. + + mmc-hs200-1_8v: + $ref: /schemas/types.yaml#/definitions/flag + description: + eMMC HS200 mode (1.8V I/O) is supported. + + mmc-hs400-1_2v: + $ref: /schemas/types.yaml#/definitions/flag + description: + eMMC HS400 mode (1.2V I/O) is supported. + + mmc-hs400-1_8v: + $ref: /schemas/types.yaml#/definitions/flag + description: + eMMC HS400 mode (1.8V I/O) is supported. + + mmc-hs400-enhanced-strobe: + $ref: /schemas/types.yaml#/definitions/flag + description: + eMMC HS400 enhanced strobe mode is supported + + no-mmc-hs400: + $ref: /schemas/types.yaml#/definitions/flag + description: + All eMMC HS400 modes are not supported. + + dsr: + description: + Value the card Driver Stage Register (DSR) should be programmed + with. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 0xffff + + no-sdio: + $ref: /schemas/types.yaml#/definitions/flag + description: + Controller is limited to send SDIO commands during + initialization. + + no-sd: + $ref: /schemas/types.yaml#/definitions/flag + description: + Controller is limited to send SD commands during initialization. + + no-mmc: + $ref: /schemas/types.yaml#/definitions/flag + description: + Controller is limited to send MMC commands during + initialization. + + fixed-emmc-driver-type: + description: + For non-removable eMMC, enforce this driver type. The value is + the driver type as specified in the eMMC specification (table + 206 in spec version 5.1) + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 4 + + post-power-on-delay-ms: + description: + It was invented for MMC pwrseq-simple which could be referred to + mmc-pwrseq-simple.yaml. But now it\'s reused as a tunable delay + waiting for I/O signalling and card power supply to be stable, + regardless of whether pwrseq-simple is used. Default to 10ms if + no available. + default: 10 + + supports-cqe: + $ref: /schemas/types.yaml#/definitions/flag + description: + The presence of this property indicates that the corresponding + MMC host controller supports HW command queue feature. + + disable-cqe-dcmd: + $ref: /schemas/types.yaml#/definitions/flag + description: + The presence of this property indicates that the MMC + controller\'s command queue engine (CQE) does not support direct + commands (DCMDs). + + keep-power-in-suspend: + $ref: /schemas/types.yaml#/definitions/flag + description: + SDIO only. Preserves card power during a suspend/resume cycle. + + wakeup-source: + $ref: /schemas/types.yaml#/definitions/flag + description: + SDIO only. Enables wake up of host system on SDIO IRQ assertion. + + vmmc-supply: + description: + Supply for the card power + + vqmmc-supply: + description: + Supply for the bus IO line power, such as a level shifter. + If the level shifter is controlled by a GPIO line, this shall + be modeled as a "regulator-fixed" with a GPIO line for + switching the level shifter on/off. + + mmc-pwrseq: + $ref: /schemas/types.yaml#/definitions/phandle + description: + System-on-Chip designs may specify a specific MMC power + sequence. To successfully detect an (e)MMC/SD/SDIO card, that + power sequence must be maintained while initializing the card. + +patternProperties: + "^.*@[0-9]+$": + type: object + description: | + On embedded systems the cards connected to a host may need + additional properties. These can be specified in subnodes to the + host controller node. The subnodes are identified by the + standard \'reg\' property. Which information exactly can be + specified depends on the bindings for the SDIO function driver + for the subnode, as specified by the compatible string. + + properties: + compatible: + description: + Name of SDIO function following generic names recommended + practice + + reg: + items: + - minimum: 0 + maximum: 7 + description: + Must contain the SDIO function number of the function this + subnode describes. A value of 0 denotes the memory SD + function, values from 1 to 7 denote the SDIO functions. + + required: + - reg + + "^clk-phase-(legacy|sd-hs|mmc-(hs|hs[24]00|ddr52)|uhs-(sdr(12|25|50|104)|ddr50))$": + $ref: /schemas/types.yaml#/definitions/uint32-array + + minItems: 2 + maxItems: 2 + items: + minimum: 0 + maximum: 359 + description: + Set the clock (phase) delays which are to be configured in the + controller while switching to particular speed mode. These values + are in pair of degrees. + +dependencies: + cd-debounce-delay-ms: [ cd-gpios ] + fixed-emmc-driver-type: [ non-removable ] + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index 58ae298cd2fc..26e4f0f8dc1c 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -9,7 +9,7 @@ title: MMC Controller Common Properties maintainers: - Ulf Hansson <ulf.hansson@linaro.org> -description: | +description: These properties are common to multiple MMC host controllers. Any host that requires the respective functionality should implement them using these definitions. @@ -18,350 +18,12 @@ description: | (and the corresponding mmcblkN devices) by defining an alias in the /aliases device tree node. +$ref: mmc-controller-common.yaml# + properties: $nodename: pattern: "^mmc(@.*)?$" - "#address-cells": - const: 1 - description: | - The cell is the slot ID if a function subnode is used. - - "#size-cells": - const: 0 - - # Card Detection. - # If none of these properties are supplied, the host native card - # detect will be used. Only one of them should be provided. - - broken-cd: - $ref: /schemas/types.yaml#/definitions/flag - description: - There is no card detection available; polling must be used. - - cd-gpios: - maxItems: 1 - description: - The card detection will be done using the GPIO provided. - - non-removable: - $ref: /schemas/types.yaml#/definitions/flag - description: - Non-removable slot (like eMMC); assume always present. - - # *NOTE* on CD and WP polarity. To use common for all SD/MMC host - # controllers line polarity properties, we have to fix the meaning - # of the "normal" and "inverted" line levels. We choose to follow - # the SDHCI standard, which specifies both those lines as "active - # low." Therefore, using the "cd-inverted" property means, that the - # CD line is active high, i.e. it is high, when a card is - # inserted. Similar logic applies to the "wp-inverted" property. - # - # CD and WP lines can be implemented on the hardware in one of two - # ways: as GPIOs, specified in cd-gpios and wp-gpios properties, or - # as dedicated pins. Polarity of dedicated pins can be specified, - # using *-inverted properties. GPIO polarity can also be specified - # using the GPIO_ACTIVE_LOW flag. This creates an ambiguity in the - # latter case. We choose to use the XOR logic for GPIO CD and WP - # lines. This means, the two properties are "superimposed," for - # example leaving the GPIO_ACTIVE_LOW flag clear and specifying the - # respective *-inverted property property results in a - # double-inversion and actually means the "normal" line polarity is - # in effect. - wp-inverted: - $ref: /schemas/types.yaml#/definitions/flag - description: - The Write Protect line polarity is inverted. - - cd-inverted: - $ref: /schemas/types.yaml#/definitions/flag - description: - The CD line polarity is inverted. - - # Other properties - - bus-width: - description: - Number of data lines. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [1, 4, 8] - default: 1 - - max-frequency: - description: | - Maximum operating frequency of the bus: - - for eMMC, the maximum supported frequency is 200MHz, - - for SD/SDIO cards the SDR104 mode has a max supported - frequency of 208MHz, - - some mmc host controllers do support a max frequency upto - 384MHz. - So, lets keep the maximum supported value here. - - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 400000 - maximum: 384000000 - - disable-wp: - $ref: /schemas/types.yaml#/definitions/flag - description: - When set, no physical write-protect line is present. This - property should only be specified when the controller has a - dedicated write-protect detection logic. If a GPIO is always used - for the write-protect detection logic, it is sufficient to not - specify the wp-gpios property in the absence of a write-protect - line. Not used in combination with eMMC or SDIO. - - wp-gpios: - maxItems: 1 - description: - GPIO to use for the write-protect detection. - - cd-debounce-delay-ms: - description: - Set delay time before detecting card after card insert - interrupt. - - no-1-8-v: - $ref: /schemas/types.yaml#/definitions/flag - description: - When specified, denotes that 1.8V card voltage is not supported - on this system, even if the controller claims it. - - cap-sd-highspeed: - $ref: /schemas/types.yaml#/definitions/flag - description: - SD high-speed timing is supported. - - cap-mmc-highspeed: - $ref: /schemas/types.yaml#/definitions/flag - description: - MMC high-speed timing is supported. - - sd-uhs-sdr12: - $ref: /schemas/types.yaml#/definitions/flag - description: - SD UHS SDR12 speed is supported. - - sd-uhs-sdr25: - $ref: /schemas/types.yaml#/definitions/flag - description: - SD UHS SDR25 speed is supported. - - sd-uhs-sdr50: - $ref: /schemas/types.yaml#/definitions/flag - description: - SD UHS SDR50 speed is supported. - - sd-uhs-sdr104: - $ref: /schemas/types.yaml#/definitions/flag - description: - SD UHS SDR104 speed is supported. - - sd-uhs-ddr50: - $ref: /schemas/types.yaml#/definitions/flag - description: - SD UHS DDR50 speed is supported. - - cap-power-off-card: - $ref: /schemas/types.yaml#/definitions/flag - description: - Powering off the card is safe. - - cap-mmc-hw-reset: - $ref: /schemas/types.yaml#/definitions/flag - description: - eMMC hardware reset is supported - - cap-sdio-irq: - $ref: /schemas/types.yaml#/definitions/flag - description: - enable SDIO IRQ signalling on this interface - - full-pwr-cycle: - $ref: /schemas/types.yaml#/definitions/flag - description: - Full power cycle of the card is supported. - - full-pwr-cycle-in-suspend: - $ref: /schemas/types.yaml#/definitions/flag - description: - Full power cycle of the card in suspend is supported. - - mmc-ddr-1_2v: - $ref: /schemas/types.yaml#/definitions/flag - description: - eMMC high-speed DDR mode (1.2V I/O) is supported. - - mmc-ddr-1_8v: - $ref: /schemas/types.yaml#/definitions/flag - description: - eMMC high-speed DDR mode (1.8V I/O) is supported. - - mmc-ddr-3_3v: - $ref: /schemas/types.yaml#/definitions/flag - description: - eMMC high-speed DDR mode (3.3V I/O) is supported. - - mmc-hs200-1_2v: - $ref: /schemas/types.yaml#/definitions/flag - description: - eMMC HS200 mode (1.2V I/O) is supported. - - mmc-hs200-1_8v: - $ref: /schemas/types.yaml#/definitions/flag - description: - eMMC HS200 mode (1.8V I/O) is supported. - - mmc-hs400-1_2v: - $ref: /schemas/types.yaml#/definitions/flag - description: - eMMC HS400 mode (1.2V I/O) is supported. - - mmc-hs400-1_8v: - $ref: /schemas/types.yaml#/definitions/flag - description: - eMMC HS400 mode (1.8V I/O) is supported. - - mmc-hs400-enhanced-strobe: - $ref: /schemas/types.yaml#/definitions/flag - description: - eMMC HS400 enhanced strobe mode is supported - - no-mmc-hs400: - $ref: /schemas/types.yaml#/definitions/flag - description: - All eMMC HS400 modes are not supported. - - dsr: - description: - Value the card Driver Stage Register (DSR) should be programmed - with. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 0 - maximum: 0xffff - - no-sdio: - $ref: /schemas/types.yaml#/definitions/flag - description: - Controller is limited to send SDIO commands during - initialization. - - no-sd: - $ref: /schemas/types.yaml#/definitions/flag - description: - Controller is limited to send SD commands during initialization. - - no-mmc: - $ref: /schemas/types.yaml#/definitions/flag - description: - Controller is limited to send MMC commands during - initialization. - - fixed-emmc-driver-type: - description: - For non-removable eMMC, enforce this driver type. The value is - the driver type as specified in the eMMC specification (table - 206 in spec version 5.1) - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 0 - maximum: 4 - - post-power-on-delay-ms: - description: - It was invented for MMC pwrseq-simple which could be referred to - mmc-pwrseq-simple.yaml. But now it\'s reused as a tunable delay - waiting for I/O signalling and card power supply to be stable, - regardless of whether pwrseq-simple is used. Default to 10ms if - no available. - default: 10 - - supports-cqe: - $ref: /schemas/types.yaml#/definitions/flag - description: - The presence of this property indicates that the corresponding - MMC host controller supports HW command queue feature. - - disable-cqe-dcmd: - $ref: /schemas/types.yaml#/definitions/flag - description: - The presence of this property indicates that the MMC - controller\'s command queue engine (CQE) does not support direct - commands (DCMDs). - - keep-power-in-suspend: - $ref: /schemas/types.yaml#/definitions/flag - description: - SDIO only. Preserves card power during a suspend/resume cycle. - - wakeup-source: - $ref: /schemas/types.yaml#/definitions/flag - description: - SDIO only. Enables wake up of host system on SDIO IRQ assertion. - - vmmc-supply: - description: - Supply for the card power - - vqmmc-supply: - description: - Supply for the bus IO line power, such as a level shifter. - If the level shifter is controlled by a GPIO line, this shall - be modeled as a "regulator-fixed" with a GPIO line for - switching the level shifter on/off. - - mmc-pwrseq: - $ref: /schemas/types.yaml#/definitions/phandle - description: - System-on-Chip designs may specify a specific MMC power - sequence. To successfully detect an (e)MMC/SD/SDIO card, that - power sequence must be maintained while initializing the card. - -patternProperties: - "^.*@[0-9]+$": - type: object - description: | - On embedded systems the cards connected to a host may need - additional properties. These can be specified in subnodes to the - host controller node. The subnodes are identified by the - standard \'reg\' property. Which information exactly can be - specified depends on the bindings for the SDIO function driver - for the subnode, as specified by the compatible string. - - properties: - compatible: - description: | - Name of SDIO function following generic names recommended - practice - - reg: - items: - - minimum: 0 - maximum: 7 - description: - Must contain the SDIO function number of the function this - subnode describes. A value of 0 denotes the memory SD - function, values from 1 to 7 denote the SDIO functions. - - required: - - reg - - "^clk-phase-(legacy|sd-hs|mmc-(hs|hs[24]00|ddr52)|uhs-(sdr(12|25|50|104)|ddr50))$": - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 2 - maxItems: 2 - items: - minimum: 0 - maximum: 359 - description: - Set the clock (phase) delays which are to be configured in the - controller while switching to particular speed mode. These values - are in pair of degrees. - -dependencies: - cd-debounce-delay-ms: [ cd-gpios ] - fixed-emmc-driver-type: [ non-removable ] - additionalProperties: true examples: diff --git a/Documentation/devicetree/bindings/mmc/mmc-slot.yaml b/Documentation/devicetree/bindings/mmc/mmc-slot.yaml new file mode 100644 index 000000000000..ca3d0114bfc6 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc-slot.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-slot.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MMC slot properties + +maintainers: + - Ulf Hansson <ulf.hansson@linaro.org> + +description: + These properties defines slot properties for MMC controlers that + have multiple slots or ports provided by the same controller and + sharing the same resources. + +$ref: mmc-controller-common.yaml# + +properties: + $nodename: + pattern: "^slot(@.*)?$" + + compatible: + const: mmc-slot + + reg: + description: + the slot (or "port") ID + maxItems: 1 + +required: + - reg + +unevaluatedProperties: false + +examples: + - | + mmc { + #address-cells = <1>; + #size-cells = <0>; + slot@0 { + compatible = "mmc-slot"; + reg = <0>; + bus-width = <4>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index f86ebd81f5a5..0debccbd6519 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -235,11 +235,19 @@ allOf: properties: compatible: contains: - const: mediatek,mt8183-mmc + enum: + - mediatek,mt7986-mmc + - mediatek,mt7988-mmc + - mediatek,mt8183-mmc + - mediatek,mt8196-mmc then: properties: reg: minItems: 2 + else: + properties: + reg: + maxItems: 1 - if: properties: diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index af378b9ff3f4..773baa6c2656 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -68,6 +68,9 @@ properties: - renesas,sdhi-r9a08g045 # RZ/G3S - renesas,sdhi-r9a09g011 # RZ/V2M - const: renesas,rzg2l-sdhi + - items: + - const: renesas,sdhi-r9a09g047 # RZ/G3E + - const: renesas,sdhi-r9a09g057 # RZ/V2H(P) reg: maxItems: 1 @@ -211,6 +214,19 @@ allOf: sectioned off to be run by a separate second clock source to allow the main core clock to be turned off to save power. + - if: + properties: + compatible: + contains: + const: renesas,sdhi-r9a09g057 + then: + properties: + vqmmc-regulator: + type: object + description: VQMMC SD regulator + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml index 06df1269f247..bf273115235b 100644 --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml @@ -38,6 +38,8 @@ properties: - rockchip,rk3328-dw-mshc - rockchip,rk3368-dw-mshc - rockchip,rk3399-dw-mshc + - rockchip,rk3528-dw-mshc + - rockchip,rk3562-dw-mshc - rockchip,rk3568-dw-mshc - rockchip,rk3588-dw-mshc - rockchip,rv1108-dw-mshc diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml index 5fe65795f796..e8bd49d46794 100644 --- a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml +++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml @@ -24,11 +24,14 @@ properties: - samsung,exynos5420-dw-mshc-smu - samsung,exynos7-dw-mshc - samsung,exynos7-dw-mshc-smu + - samsung,exynos7870-dw-mshc + - samsung,exynos7870-dw-mshc-smu - items: - enum: - samsung,exynos5433-dw-mshc-smu - samsung,exynos7885-dw-mshc-smu - samsung,exynos850-dw-mshc-smu + - samsung,exynos8895-dw-mshc-smu - const: samsung,exynos7-dw-mshc-smu reg: diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml index 8b393e26e025..eed9063e9bb3 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml @@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm SDHCI controller (sdhci-msm) maintainers: - - Bhupesh Sharma <bhupesh.sharma@linaro.org> + - Bjorn Andersson <andersson@kernel.org> + - Konrad Dybcio <konradybcio@kernel.org> description: Secure Digital Host Controller Interface (SDHCI) present on diff --git a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml index c3d5e0230af1..e6e604072d3c 100644 --- a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml @@ -14,7 +14,10 @@ properties: compatible: oneOf: - items: - - const: rockchip,rk3576-dwcmshc + - enum: + - rockchip,rk3528-dwcmshc + - rockchip,rk3562-dwcmshc + - rockchip,rk3576-dwcmshc - const: rockchip,rk3588-dwcmshc - enum: - rockchip,rk3568-dwcmshc diff --git a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml index 15b63bbb82a2..b90d3b48c2f2 100644 --- a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml @@ -42,7 +42,7 @@ required: - clock-names - interrupts -unevaluatedProperties: true +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/mtd/atmel,dataflash.yaml b/Documentation/devicetree/bindings/mtd/atmel,dataflash.yaml new file mode 100644 index 000000000000..8c72fa346e36 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/atmel,dataflash.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/atmel,dataflash.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel DataFlash + +maintainers: + - Nayab Sayed <nayabbasha.sayed@microchip.com> + +description: + The Atmel DataFlash is a low pin-count serial interface sequential access + Flash memory, compatible with SPI standard. The device tree may optionally + contain sub-nodes describing partitions of the address space. + +properties: + compatible: + oneOf: + - items: + - enum: + - atmel,at45db321d + - atmel,at45db041e + - atmel,at45db642d + - atmel,at45db021d + - const: atmel,at45 + - const: atmel,dataflash + - items: + - const: atmel,at45 + - const: atmel,dataflash + + reg: + maxItems: 1 + +required: + - compatible + - reg + +allOf: + - $ref: mtd.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + flash@1 { + compatible = "atmel,at45db321d", "atmel,at45", "atmel,dataflash"; + reg = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt b/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt deleted file mode 100644 index 1889a4db5b7c..000000000000 --- a/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt +++ /dev/null @@ -1,17 +0,0 @@ -* Atmel Data Flash - -Required properties: -- compatible : "atmel,<model>", "atmel,<series>", "atmel,dataflash". - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - -flash@1 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "atmel,at45db321d", "atmel,at45", "atmel,dataflash"; - spi-max-frequency = <25000000>; - reg = <1>; -}; diff --git a/Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt b/Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt deleted file mode 100644 index d2eada5044b2..000000000000 --- a/Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt +++ /dev/null @@ -1,53 +0,0 @@ -* Cadence NAND controller - -Required properties: - - compatible : "cdns,hp-nfc" - - reg : Contains two entries, each of which is a tuple consisting of a - physical address and length. The first entry is the address and - length of the controller register set. The second entry is the - address and length of the Slave DMA data port. - - reg-names: should contain "reg" and "sdma" - - #address-cells: should be 1. The cell encodes the chip select connection. - - #size-cells : should be 0. - - interrupts : The interrupt number. - - clocks: phandle of the controller core clock (nf_clk). - -Optional properties: - - dmas: shall reference DMA channel associated to the NAND controller - - cdns,board-delay-ps : Estimated Board delay. The value includes the total - round trip delay for the signals and is used for deciding on values - associated with data read capture. The example formula for SDR mode is - the following: - board delay = RE#PAD delay + PCB trace to device + PCB trace from device - + DQ PAD delay - -Child nodes represent the available NAND chips. - -Required properties of NAND chips: - - reg: shall contain the native Chip Select ids from 0 to max supported by - the cadence nand flash controller - -See Documentation/devicetree/bindings/mtd/nand-controller.yaml for more details on -generic bindings. - -Example: - -nand_controller: nand-controller@60000000 { - compatible = "cdns,hp-nfc"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x60000000 0x10000>, <0x80000000 0x10000>; - reg-names = "reg", "sdma"; - clocks = <&nf_clk>; - cdns,board-delay-ps = <4830>; - interrupts = <2 0>; - nand@0 { - reg = <0>; - label = "nand-1"; - }; - nand@1 { - reg = <1>; - label = "nand-2"; - }; - -}; diff --git a/Documentation/devicetree/bindings/mtd/cdns,hp-nfc.yaml b/Documentation/devicetree/bindings/mtd/cdns,hp-nfc.yaml new file mode 100644 index 000000000000..e1f4d7c35a88 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/cdns,hp-nfc.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/cdns,hp-nfc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence NAND controller + +maintainers: + - Niravkumar L Rabara <niravkumar.l.rabara@intel.com> + +allOf: + - $ref: nand-controller.yaml + +properties: + compatible: + items: + - const: cdns,hp-nfc + + reg: + items: + - description: Controller register set + - description: Slave DMA data port register set + + reg-names: + items: + - const: reg + - const: sdma + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: nf_clk + + dmas: + maxItems: 1 + + cdns,board-delay-ps: + description: | + Estimated Board delay. The value includes the total round trip + delay for the signals and is used for deciding on values associated + with data read capture. The example formula for SDR mode is the + following. + board delay = RE#PAD delay + PCB trace to device + PCB trace from device + + DQ PAD delay + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + nand-controller@10b80000 { + compatible = "cdns,hp-nfc"; + reg = <0x10b80000 0x10000>, + <0x10840000 0x10000>; + reg-names = "reg", "sdma"; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk>; + clock-names = "nf_clk"; + cdns,board-delay-ps = <4830>; + + nand@0 { + reg = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt b/Documentation/devicetree/bindings/mtd/davinci-nand.txt deleted file mode 100644 index eb8e2ff4dbd2..000000000000 --- a/Documentation/devicetree/bindings/mtd/davinci-nand.txt +++ /dev/null @@ -1,94 +0,0 @@ -Device tree bindings for Texas instruments Davinci/Keystone NAND controller - -This file provides information, what the device node for the davinci/keystone -NAND interface contains. - -Documentation: -Davinci DM646x - https://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf -Kestone - https://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf - -Required properties: - -- compatible: "ti,davinci-nand" - "ti,keystone-nand" - -- reg: Contains 2 offset/length values: - - offset and length for the access window. - - offset and length for accessing the AEMIF - control registers. - -- ti,davinci-chipselect: number of chipselect. Indicates on the - davinci_nand driver which chipselect is used - for accessing the nand. - Can be in the range [0-3]. - -Recommended properties : - -- ti,davinci-mask-ale: mask for ALE. Needed for executing address - phase. These offset will be added to the base - address for the chip select space the NAND Flash - device is connected to. - If not set equal to 0x08. - -- ti,davinci-mask-cle: mask for CLE. Needed for executing command - phase. These offset will be added to the base - address for the chip select space the NAND Flash - device is connected to. - If not set equal to 0x10. - -- ti,davinci-mask-chipsel: mask for chipselect address. Needed to mask - addresses for given chipselect. - -- nand-ecc-mode: operation mode of the NAND ecc mode. ECC mode - valid values for davinci driver: - - "none" - - "soft" - - "hw" - -- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4. - -- nand-bus-width: buswidth 8 or 16. If not present 8. - -- nand-on-flash-bbt: use flash based bad block table support. OOB - identifier is saved in OOB area. If not present - false. - -Deprecated properties: - -- ti,davinci-ecc-mode: operation mode of the NAND ecc mode. ECC mode - valid values for davinci driver: - - "none" - - "soft" - - "hw" - -- ti,davinci-nand-buswidth: buswidth 8 or 16. If not present 8. - -- ti,davinci-nand-use-bbt: use flash based bad block table support. OOB - identifier is saved in OOB area. If not present - false. - -Nand device bindings may contain additional sub-nodes describing partitions of -the address space. See mtd.yaml for more detail. The NAND Flash timing -values must be programmed in the chip select’s node of AEMIF -memory-controller (see Documentation/devicetree/bindings/memory-controllers/ -davinci-aemif.txt). - -Example(da850 EVM ): - -nand_cs3@62000000 { - compatible = "ti,davinci-nand"; - reg = <0x62000000 0x807ff - 0x68000000 0x8000>; - ti,davinci-chipselect = <1>; - ti,davinci-mask-ale = <0>; - ti,davinci-mask-cle = <0>; - ti,davinci-mask-chipsel = <0>; - nand-ecc-mode = "hw"; - ti,davinci-ecc-bits = <4>; - nand-on-flash-bbt; - - partition@180000 { - label = "ubifs"; - reg = <0x180000 0x7e80000>; - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml index f9eb1868ca1f..0badb2e978c7 100644 --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml @@ -29,7 +29,14 @@ properties: - enum: - fsl,imx8mm-gpmi-nand - fsl,imx8mn-gpmi-nand + - fsl,imx8mp-gpmi-nand + - fsl,imx8mq-gpmi-nand - const: fsl,imx7d-gpmi-nand + - items: + - enum: + - fsl,imx8dxl-gpmi-nand + - fsl,imx8qm-gpmi-nand + - const: fsl,imx8qxp-gpmi-nand reg: items: diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 6e3afb42926e..335f8204aa1e 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -96,6 +96,10 @@ properties: If "broken-flash-reset" is present then having this property does not make any difference. + vcc-supply: + description: + Supply for the SPI NOR power. + spi-cpol: true spi-cpha: true diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml index 0ff32bd00bf6..5c6b628c608d 100644 --- a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml +++ b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml @@ -16,8 +16,9 @@ description: | properties: compatible: - items: - - const: microchip,48l640 + enum: + - fujitsu,mb85rs128ty + - microchip,48l640 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml index 18f6733408b4..1b375dee83b0 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml @@ -122,6 +122,8 @@ properties: '#size-cells': const: 1 + ranges: true + big-endian: true little-endian: true @@ -143,8 +145,7 @@ then: required: - syscon -# FIXME: A parent bus may define timing properties -additionalProperties: true +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml index cf4198e43d7f..bd8f7b683953 100644 --- a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml @@ -14,8 +14,12 @@ allOf: properties: compatible: - const: fsl,imx27-nand - + oneOf: + - const: fsl,imx27-nand + - items: + - enum: + - fsl,imx31-nand + - const: fsl,imx27-nand reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml b/Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml new file mode 100644 index 000000000000..0b651450a8f1 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/nuvoton,ma35d1-nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton MA35D1 NAND Flash Interface (NFI) Controller + +maintainers: + - Hui-Ping Chen <hpchen0nvt@gmail.com> + +allOf: + - $ref: nand-controller.yaml# + +properties: + compatible: + enum: + - nuvoton,ma35d1-nand-controller + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +patternProperties: + "^nand@[a-f0-9]$": + type: object + $ref: raw-nand-chip.yaml + properties: + reg: + minimum: 0 + maximum: 1 + + nand-ecc-step-size: + enum: [512, 1024] + + nand-ecc-strength: + enum: [8, 12, 24] + + required: + - reg + + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + nand-controller@401A0000 { + compatible = "nuvoton,ma35d1-nand-controller"; + reg = <0x0 0x401A0000 0x0 0x1000>; + interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk NAND_GATE>; + #address-cells = <1>; + #size-cells = <0>; + + nand@0 { + reg = <0>; + nand-on-flash-bbt; + nand-ecc-step-size = <512>; + nand-ecc-strength = <8>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + uboot@0 { + label = "nand-uboot"; + read-only; + reg = <0x0 0x300000>; + }; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mtd/ti,davinci-nand.yaml b/Documentation/devicetree/bindings/mtd/ti,davinci-nand.yaml new file mode 100644 index 000000000000..ed24b0ea86e5 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ti,davinci-nand.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/ti,davinci-nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI DaVinci NAND controller + +maintainers: + - Marcus Folkesson <marcus.folkesson@gmail.com> + +allOf: + - $ref: nand-controller.yaml + +properties: + compatible: + enum: + - ti,davinci-nand + - ti,keystone-nand + + reg: + items: + - description: Access window. + - description: AEMIF control registers. + + partitions: + $ref: /schemas/mtd/partitions/partitions.yaml + + ti,davinci-chipselect: + description: + Number of chipselect. Indicate on the davinci_nand driver which + chipselect is used for accessing the nand. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + ti,davinci-mask-ale: + description: + Mask for ALE. Needed for executing address phase. These offset will be + added to the base address for the chip select space the NAND Flash + device is connected to. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0x08 + + ti,davinci-mask-cle: + description: + Mask for CLE. Needed for executing command phase. These offset will be + added to the base address for the chip select space the NAND Flash device + is connected to. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0x10 + + ti,davinci-mask-chipsel: + description: + Mask for chipselect address. Needed to mask addresses for given + chipselect. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + + ti,davinci-ecc-bits: + description: Used ECC bits. + enum: [1, 4] + + ti,davinci-ecc-mode: + description: Operation mode of the NAND ECC mode. + $ref: /schemas/types.yaml#/definitions/string + enum: [none, soft, hw, on-die] + deprecated: true + + ti,davinci-nand-buswidth: + description: Bus width to the NAND chip. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16] + default: 8 + deprecated: true + + ti,davinci-nand-use-bbt: + type: boolean + description: + Use flash based bad block table support. OOB identifier is saved in OOB + area. + deprecated: true + +required: + - compatible + - reg + - ti,davinci-chipselect + +unevaluatedProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <1>; + + nand-controller@2000000,0 { + compatible = "ti,davinci-nand"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0 0x02000000 0x02000000>, + <1 0x00000000 0x00008000>; + + ti,davinci-chipselect = <1>; + ti,davinci-mask-ale = <0>; + ti,davinci-mask-cle = <0>; + ti,davinci-mask-chipsel = <0>; + + ti,davinci-nand-buswidth = <16>; + ti,davinci-ecc-mode = "hw"; + ti,davinci-ecc-bits = <4>; + ti,davinci-nand-use-bbt; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "u-boot env"; + reg = <0 0x020000>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index d1e2bca3c503..798a4c19f18c 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -166,11 +166,11 @@ unevaluatedProperties: false examples: - | ethmac: ethernet@c9410000 { - compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac"; - reg = <0xc9410000 0x10000>, <0xc8834540 0x8>; - interrupts = <8>; - interrupt-names = "macirq"; - clocks = <&clk_eth>, <&clk_fclk_div2>, <&clk_mpll2>, <&clk_fclk_div2>; - clock-names = "stmmaceth", "clkin0", "clkin1", "timing-adjustment"; - phy-mode = "rgmii"; + compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac"; + reg = <0xc9410000 0x10000>, <0xc8834540 0x8>; + interrupts = <8>; + interrupt-names = "macirq"; + clocks = <&clk_eth>, <&clk_fclk_div2>, <&clk_mpll2>, <&clk_fclk_div2>; + clock-names = "stmmaceth", "clkin0", "clkin1", "timing-adjustment"; + phy-mode = "rgmii"; }; diff --git a/Documentation/devicetree/bindings/net/asix,ax88178.yaml b/Documentation/devicetree/bindings/net/asix,ax88178.yaml index 768504ccbf74..03341b7438d5 100644 --- a/Documentation/devicetree/bindings/net/asix,ax88178.yaml +++ b/Documentation/devicetree/bindings/net/asix,ax88178.yaml @@ -63,8 +63,8 @@ examples: #size-cells = <0>; ethernet@1 { - compatible = "usbb95,772b"; - reg = <1>; + compatible = "usbb95,772b"; + reg = <1>; }; }; }; diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml index 7bb68311c609..a72152f7e29b 100644 --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml @@ -101,7 +101,10 @@ properties: max-speed: true firmware-name: - description: specify the name of nvm firmware to load + minItems: 1 + items: + - description: specify the name of nvm firmware to load + - description: specify the name of rampatch firmware to load local-bd-address: true @@ -154,16 +157,11 @@ allOf: - qcom,wcn6750-bt then: required: - - enable-gpios - - swctrl-gpios - - vddio-supply - vddaon-supply - - vddbtcxmx-supply - vddrfacmn-supply - vddrfa0p8-supply - vddrfa1p7-supply - vddrfa1p2-supply - - vddasd-supply - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml index 7c90a4390531..0e3fb4e42e3f 100644 --- a/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml +++ b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml @@ -85,16 +85,16 @@ examples: #size-cells = <1>; mdio0: mdio@e14 { - compatible = "brcm,genet-mdio-v4"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0xe14 0x8>; + compatible = "brcm,genet-mdio-v4"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xe14 0x8>; - phy1: ethernet-phy@1 { + phy1: ethernet-phy@1 { max-speed = <1000>; reg = <1>; compatible = "ethernet-phy-ieee802.3-c22"; - }; + }; }; }; @@ -110,10 +110,10 @@ examples: interrupts = <0x0 0x16 0x0>, <0x0 0x17 0x0>; mdio1: mdio@e14 { - compatible = "brcm,genet-mdio-v4"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0xe14 0x8>; + compatible = "brcm,genet-mdio-v4"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xe14 0x8>; }; }; @@ -129,15 +129,15 @@ examples: interrupts = <0x0 0x18 0x0>, <0x0 0x19 0x0>; mdio2: mdio@e14 { - compatible = "brcm,genet-mdio-v4"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0xe14 0x8>; + compatible = "brcm,genet-mdio-v4"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xe14 0x8>; - phy0: ethernet-phy@0 { + phy0: ethernet-phy@0 { max-speed = <1000>; reg = <0>; compatible = "ethernet-phy-ieee802.3-c22"; - }; + }; }; }; diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml index af96b4fd89d5..3f27746d9a56 100644 --- a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml +++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml @@ -38,43 +38,43 @@ unevaluatedProperties: false examples: - | - mdio_mux_iproc: mdio-mux@66020000 { + mdio-mux@66020000 { compatible = "brcm,mdio-mux-iproc"; reg = <0x66020000 0x250>; #address-cells = <1>; #size-cells = <0>; mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - - pci_phy0: pci-phy@0 { - compatible = "brcm,ns2-pcie-phy"; - reg = <0x0>; - #phy-cells = <0>; - }; + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + + pci-phy@0 { + compatible = "brcm,ns2-pcie-phy"; + reg = <0x0>; + #phy-cells = <0>; + }; }; mdio@7 { - reg = <0x7>; - #address-cells = <1>; - #size-cells = <0>; - - pci_phy1: pci-phy@0 { - compatible = "brcm,ns2-pcie-phy"; - reg = <0x0>; - #phy-cells = <0>; - }; + reg = <0x7>; + #address-cells = <1>; + #size-cells = <0>; + + pci-phy@0 { + compatible = "brcm,ns2-pcie-phy"; + reg = <0x0>; + #phy-cells = <0>; + }; }; mdio@10 { - reg = <0x10>; - #address-cells = <1>; - #size-cells = <0>; + reg = <0x10>; + #address-cells = <1>; + #size-cells = <0>; - gphy0: eth-phy@10 { - reg = <0x10>; - }; + eth-phy@10 { + reg = <0x10>; + }; }; }; diff --git a/Documentation/devicetree/bindings/net/can/atmel,at91sam9263-can.yaml b/Documentation/devicetree/bindings/net/can/atmel,at91sam9263-can.yaml new file mode 100644 index 000000000000..c818c01a718b --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/atmel,at91sam9263-can.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/atmel,at91sam9263-can.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip AT91 CAN Controller + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + +allOf: + - $ref: can-controller.yaml# + +properties: + compatible: + oneOf: + - enum: + - atmel,at91sam9263-can + - atmel,at91sam9x5-can + - items: + - enum: + - microchip,sam9x60-can + - const: atmel,at91sam9x5-can + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: can_clk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/at91.h> + can@f000c000 { + compatible = "atmel,at91sam9263-can"; + reg = <0xf000c000 0x300>; + interrupts = <30 IRQ_TYPE_LEVEL_HIGH 3>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 12>; + clock-names = "can_clk"; + }; diff --git a/Documentation/devicetree/bindings/net/can/atmel-can.txt b/Documentation/devicetree/bindings/net/can/atmel-can.txt deleted file mode 100644 index 218a3b3eb27e..000000000000 --- a/Documentation/devicetree/bindings/net/can/atmel-can.txt +++ /dev/null @@ -1,15 +0,0 @@ -* AT91 CAN * - -Required properties: - - compatible: Should be "atmel,at91sam9263-can", "atmel,at91sam9x5-can" or - "microchip,sam9x60-can" - - reg: Should contain CAN controller registers location and length - - interrupts: Should contain IRQ line for the CAN controller - -Example: - - can0: can@f000c000 { - compatible = "atmel,at91sam9x5-can"; - reg = <0xf000c000 0x300>; - interrupts = <40 4 5> - }; diff --git a/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml index 4d7d67ee175a..ff1b59a0294e 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml @@ -99,11 +99,11 @@ examples: #include <dt-bindings/reset/altr,rst-mgr.h> can@ffc00000 { - compatible = "bosch,d_can"; - reg = <0xffc00000 0x1000>; - interrupts = <0 131 4>, <0 132 4>, <0 133 4>, <0 134 4>; - clocks = <&can0_clk>; - resets = <&rst CAN0_RESET>; + compatible = "bosch,d_can"; + reg = <0xffc00000 0x1000>; + interrupts = <0 131 4>, <0 132 4>, <0 133 4>, <0 134 4>; + clocks = <&can0_clk>; + resets = <&rst CAN0_RESET>; }; - | can@0 { diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp2510.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp2510.yaml index db446dde6842..e0ec53bc10c6 100644 --- a/Documentation/devicetree/bindings/net/can/microchip,mcp2510.yaml +++ b/Documentation/devicetree/bindings/net/can/microchip,mcp2510.yaml @@ -56,15 +56,15 @@ examples: #size-cells = <0>; can@1 { - compatible = "microchip,mcp2515"; - reg = <1>; - clocks = <&clk24m>; - interrupt-parent = <&gpio4>; - interrupts = <13 IRQ_TYPE_LEVEL_LOW>; - vdd-supply = <®5v0>; - xceiver-supply = <®5v0>; - gpio-controller; - #gpio-cells = <2>; + compatible = "microchip,mcp2515"; + reg = <1>; + clocks = <&clk24m>; + interrupt-parent = <&gpio4>; + interrupts = <13 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <®5v0>; + xceiver-supply = <®5v0>; + gpio-controller; + #gpio-cells = <2>; }; }; diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml index 2a98b26630cb..c155c9c6db39 100644 --- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml +++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml @@ -40,7 +40,7 @@ properties: microchip,rx-int-gpios: description: - GPIO phandle of GPIO connected to to INT1 pin of the MCP251XFD, which + GPIO phandle of GPIO connected to INT1 pin of the MCP251XFD, which signals a pending RX interrupt. maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml b/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml index 01e4d4a54df6..1219c5cb601f 100644 --- a/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml +++ b/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml @@ -15,7 +15,11 @@ allOf: properties: compatible: - const: microchip,mpfs-can + oneOf: + - items: + - const: microchip,pic64gx-can + - const: microchip,mpfs-can + - const: microchip,mpfs-can reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml index 7c5ac5d2e880..f6884f6e59e7 100644 --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml @@ -170,7 +170,7 @@ allOf: const: renesas,r8a779h0-canfd then: patternProperties: - "^channel[5-7]$": false + "^channel[4-7]$": false else: if: not: diff --git a/Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml b/Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml index de1d4298893b..c7510b00954a 100644 --- a/Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml +++ b/Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml @@ -63,7 +63,7 @@ properties: maxItems: 1 st,gcan: - $ref: /schemas/types.yaml#/definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle to the gcan node which allows to access the 512-bytes SRAM memory shared by the two bxCAN cells (CAN1 primary and CAN2 diff --git a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt deleted file mode 100644 index 20c0572c9853..000000000000 --- a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt +++ /dev/null @@ -1,48 +0,0 @@ -Texas Instruments TCAN4x5x CAN Controller -================================================ - -This file provides device node information for the TCAN4x5x interface contains. - -Required properties: - - compatible: - "ti,tcan4552", "ti,tcan4x5x" - "ti,tcan4553", "ti,tcan4x5x" or - "ti,tcan4x5x" - - reg: 0 - - #address-cells: 1 - - #size-cells: 0 - - spi-max-frequency: Maximum frequency of the SPI bus the chip can - operate at should be less than or equal to 18 MHz. - - interrupt-parent: the phandle to the interrupt controller which provides - the interrupt. - - interrupts: interrupt specification for data-ready. - -See Documentation/devicetree/bindings/net/can/bosch,m_can.yaml for additional -required property details. - -Optional properties: - - reset-gpios: Hardwired output GPIO. If not defined then software - reset. - - device-state-gpios: Input GPIO that indicates if the device is in - a sleep state or if the device is active. Not - available with tcan4552/4553. - - device-wake-gpios: Wake up GPIO to wake up the TCAN device. Not - available with tcan4552/4553. - - wakeup-source: Leave the chip running when suspended, and configure - the RX interrupt to wake up the device. - -Example: -tcan4x5x: tcan4x5x@0 { - compatible = "ti,tcan4x5x"; - reg = <0>; - #address-cells = <1>; - #size-cells = <1>; - spi-max-frequency = <10000000>; - bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>; - interrupt-parent = <&gpio1>; - interrupts = <14 IRQ_TYPE_LEVEL_LOW>; - device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>; - device-wake-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>; - wakeup-source; -}; diff --git a/Documentation/devicetree/bindings/net/can/ti,tcan4x5x.yaml b/Documentation/devicetree/bindings/net/can/ti,tcan4x5x.yaml new file mode 100644 index 000000000000..384e15da2713 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/ti,tcan4x5x.yaml @@ -0,0 +1,199 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/ti,tcan4x5x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TCAN4x5x CAN Controller + +maintainers: + - Marc Kleine-Budde <mkl@pengutronix.de> + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,tcan4552 + - ti,tcan4553 + - const: ti,tcan4x5x + - const: ti,tcan4x5x + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + description: The GPIO parent interrupt. + + clocks: + maxItems: 1 + + clock-names: + items: + - const: cclk + + reset-gpios: + description: Hardwired output GPIO. If not defined then software reset. + maxItems: 1 + + device-state-gpios: + description: + Input GPIO that indicates if the device is in a sleep state or if the + device is active. Not available with tcan4552/4553. + maxItems: 1 + + device-wake-gpios: + description: + Wake up GPIO to wake up the TCAN device. + Not available with tcan4552/4553. + maxItems: 1 + + bosch,mram-cfg: + description: | + Message RAM configuration data. + Multiple M_CAN instances can share the same Message RAM + and each element(e.g Rx FIFO or Tx Buffer and etc) number + in Message RAM is also configurable, so this property is + telling driver how the shared or private Message RAM are + used by this M_CAN controller. + + The format should be as follows: + <offset sidf_elems xidf_elems rxf0_elems rxf1_elems rxb_elems txe_elems txb_elems> + The 'offset' is an address offset of the Message RAM where + the following elements start from. This is usually set to + 0x0 if you're using a private Message RAM. The remain cells + are used to specify how many elements are used for each FIFO/Buffer. + + M_CAN includes the following elements according to user manual: + 11-bit Filter 0-128 elements / 0-128 words + 29-bit Filter 0-64 elements / 0-128 words + Rx FIFO 0 0-64 elements / 0-1152 words + Rx FIFO 1 0-64 elements / 0-1152 words + Rx Buffers 0-64 elements / 0-1152 words + Tx Event FIFO 0-32 elements / 0-64 words + Tx Buffers 0-32 elements / 0-576 words + + Please refer to 2.4.1 Message RAM Configuration in Bosch + M_CAN user manual for details. + $ref: /schemas/types.yaml#/definitions/int32-array + items: + - description: The 'offset' is an address offset of the Message RAM where + the following elements start from. This is usually set to 0x0 if + you're using a private Message RAM. + default: 0 + - description: 11-bit Filter 0-128 elements / 0-128 words + minimum: 0 + maximum: 128 + - description: 29-bit Filter 0-64 elements / 0-128 words + minimum: 0 + maximum: 64 + - description: Rx FIFO 0 0-64 elements / 0-1152 words + minimum: 0 + maximum: 64 + - description: Rx FIFO 1 0-64 elements / 0-1152 words + minimum: 0 + maximum: 64 + - description: Rx Buffers 0-64 elements / 0-1152 words + minimum: 0 + maximum: 64 + - description: Tx Event FIFO 0-32 elements / 0-64 words + minimum: 0 + maximum: 32 + - description: Tx Buffers 0-32 elements / 0-576 words + minimum: 0 + maximum: 32 + minItems: 1 + + spi-max-frequency: + description: + Must be half or less of "clocks" frequency. + maximum: 18000000 + + ti,nwkrq-voltage-vio: + type: boolean + description: + nWKRQ Pin GPO buffer voltage configuration. + Set nWKRQ to use VIO voltage rail. + When not set nWKRQ will use internal voltage rail. + + wakeup-source: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable CAN remote wakeup. + +allOf: + - $ref: can-controller.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# + - if: + properties: + compatible: + contains: + enum: + - ti,tcan4552 + - ti,tcan4553 + then: + properties: + device-state-gpios: false + device-wake-gpios: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - bosch,mram-cfg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + can@0 { + compatible = "ti,tcan4x5x"; + reg = <0>; + clocks = <&can0_osc>; + clock-names = "cclk"; + pinctrl-names = "default"; + pinctrl-0 = <&can0_pins>; + spi-max-frequency = <10000000>; + bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>; + interrupt-parent = <&gpio1>; + interrupts = <14 IRQ_TYPE_LEVEL_LOW>; + device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>; + device-wake-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>; + ti,nwkrq-voltage-vio; + wakeup-source; + }; + }; + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + can@0 { + compatible = "ti,tcan4552", "ti,tcan4x5x"; + reg = <0>; + clocks = <&can0_osc>; + clock-names = "cclk"; + pinctrl-names = "default"; + pinctrl-0 = <&can0_pins>; + spi-max-frequency = <10000000>; + bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>; + interrupt-parent = <&gpio1>; + interrupts = <14 IRQ_TYPE_LEVEL_LOW>; + reset-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>; + wakeup-source; + }; + }; diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml index dedfad526666..a73fc5036905 100644 --- a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml +++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml @@ -129,6 +129,24 @@ properties: minimum: 0 maximum: 383 + rx-internal-delay-ps: + description: + RGMII Receive Clock Delay defined in pico seconds, used to select + the DLL phase shift between 1000 ps (45 degree shift at 1Gbps) and + 3300 ps (147 degree shift at 1Gbps). A value of 0 ps will disable + any delay. The Default is no delay. + enum: [0, 1000, 1700, 2000, 2500, 3000, 3300] + default: 0 + + tx-internal-delay-ps: + description: + RGMII Transmit Clock Delay defined in pico seconds, used to select + the DLL phase shift between 1000 ps (45 degree shift at 1Gbps) and + 3300 ps (147 degree shift at 1Gbps). A value of 0 ps will disable + any delay. The Default is no delay. + enum: [0, 1000, 1700, 2000, 2500, 3000, 3300] + default: 0 + required: - reg - phys diff --git a/Documentation/devicetree/bindings/net/nxp,s32-dwmac.yaml b/Documentation/devicetree/bindings/net/nxp,s32-dwmac.yaml new file mode 100644 index 000000000000..2b8b74c5feec --- /dev/null +++ b/Documentation/devicetree/bindings/net/nxp,s32-dwmac.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2021-2024 NXP +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nxp,s32-dwmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP S32G2xx/S32G3xx/S32R45 GMAC ethernet controller + +maintainers: + - Jan Petrous (OSS) <jan.petrous@oss.nxp.com> + +description: + This device is a Synopsys DWC IP, integrated on NXP S32G/R SoCs. + The SoC series S32G2xx and S32G3xx feature one DWMAC instance, + the SoC S32R45 has two instances. The devices can use RGMII/RMII/MII + interface over Pinctrl device or the output can be routed + to the embedded SerDes for SGMII connectivity. + +properties: + compatible: + oneOf: + - const: nxp,s32g2-dwmac + - items: + - enum: + - nxp,s32g3-dwmac + - nxp,s32r45-dwmac + - const: nxp,s32g2-dwmac + + reg: + items: + - description: Main GMAC registers + - description: GMAC PHY mode control register + + interrupts: + maxItems: 1 + + interrupt-names: + const: macirq + + clocks: + items: + - description: Main GMAC clock + - description: Transmit clock + - description: Receive clock + - description: PTP reference clock + + clock-names: + items: + - const: stmmaceth + - const: tx + - const: rx + - const: ptp_ref + +required: + - clocks + - clock-names + +allOf: + - $ref: snps,dwmac.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/phy/phy.h> + bus { + #address-cells = <2>; + #size-cells = <2>; + + ethernet@4033c000 { + compatible = "nxp,s32g2-dwmac"; + reg = <0x0 0x4033c000 0x0 0x2000>, /* gmac IP */ + <0x0 0x4007c004 0x0 0x4>; /* GMAC_0_CTRL_STS */ + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq"; + snps,mtl-rx-config = <&mtl_rx_setup>; + snps,mtl-tx-config = <&mtl_tx_setup>; + clocks = <&clks 24>, <&clks 17>, <&clks 16>, <&clks 15>; + clock-names = "stmmaceth", "tx", "rx", "ptp_ref"; + phy-mode = "rgmii-id"; + phy-handle = <&phy0>; + + mtl_rx_setup: rx-queues-config { + snps,rx-queues-to-use = <5>; + }; + + mtl_tx_setup: tx-queues-config { + snps,tx-queues-to-use = <5>; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + compatible = "snps,dwmac-mdio"; + + phy0: ethernet-phy@0 { + reg = <0>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml index 0bcd593a7bd0..e7ee0d9efed8 100644 --- a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml @@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Ethernet ETHQOS device maintainers: - - Bhupesh Sharma <bhupesh.sharma@linaro.org> + - Bjorn Andersson <andersson@kernel.org> + - Konrad Dybcio <konradybcio@kernel.org> description: dwmmac based Qualcomm ethernet devices which support Gigabit @@ -21,12 +22,12 @@ properties: oneOf: - items: - enum: - - qcom,qcs8300-ethqos - - const: qcom,sa8775p-ethqos + - qcom,qcs615-ethqos + - const: qcom,qcs404-ethqos - items: - enum: - - qcom,qcs615-ethqos - - const: qcom,sm8150-ethqos + - qcom,qcs8300-ethqos + - const: qcom,sa8775p-ethqos - enum: - qcom,qcs404-ethqos - qcom,sa8775p-ethqos diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 53cae71d9957..1a46d80a66e8 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -239,7 +239,7 @@ examples: qcom,gsi-loader = "self"; memory-region = <&ipa_fw_mem>; - firmware-name = "qcom/sc7180-trogdor/modem/modem.mdt"; + firmware-name = "qcom/sc7180-trogdor/modem/modem.mbn"; iommus = <&apps_smmu 0x440 0x0>, <&apps_smmu 0x442 0x0>; diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index eb1f3ae41ab9..91e75eb3f329 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -67,6 +67,7 @@ properties: - ingenic,x2000-mac - loongson,ls2k-dwmac - loongson,ls7a-dwmac + - nxp,s32g2-dwmac - qcom,qcs404-ethqos - qcom,sa8775p-ethqos - qcom,sc8280xp-ethqos diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index bf23838fe6e8..85cea9966a27 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -154,56 +154,56 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/stm32mp1-clks.h> //Example 1 - ethernet0: ethernet@5800a000 { - compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a"; - reg = <0x5800a000 0x2000>; - reg-names = "stmmaceth"; - interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "macirq"; - clock-names = "stmmaceth", - "mac-clk-tx", - "mac-clk-rx", - "ethstp", - "eth-ck"; - clocks = <&rcc ETHMAC>, - <&rcc ETHTX>, - <&rcc ETHRX>, - <&rcc ETHSTP>, - <&rcc ETHCK_K>; - st,syscon = <&syscfg 0x4>; - snps,pbl = <2>; - snps,axi-config = <&stmmac_axi_config_0>; - snps,tso; - phy-mode = "rgmii"; - }; + ethernet0: ethernet@5800a000 { + compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a"; + reg = <0x5800a000 0x2000>; + reg-names = "stmmaceth"; + interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq"; + clock-names = "stmmaceth", + "mac-clk-tx", + "mac-clk-rx", + "ethstp", + "eth-ck"; + clocks = <&rcc ETHMAC>, + <&rcc ETHTX>, + <&rcc ETHRX>, + <&rcc ETHSTP>, + <&rcc ETHCK_K>; + st,syscon = <&syscfg 0x4>; + snps,pbl = <2>; + snps,axi-config = <&stmmac_axi_config_0>; + snps,tso; + phy-mode = "rgmii"; + }; - | //Example 2 (MCU example) - ethernet1: ethernet@40028000 { - compatible = "st,stm32-dwmac", "snps,dwmac-3.50a"; - reg = <0x40028000 0x8000>; - reg-names = "stmmaceth"; - interrupts = <0 61 0>, <0 62 0>; - interrupt-names = "macirq", "eth_wake_irq"; - clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx"; - clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>; - st,syscon = <&syscfg 0x4>; - snps,pbl = <8>; - snps,mixed-burst; - phy-mode = "mii"; - }; + ethernet1: ethernet@40028000 { + compatible = "st,stm32-dwmac", "snps,dwmac-3.50a"; + reg = <0x40028000 0x8000>; + reg-names = "stmmaceth"; + interrupts = <0 61 0>, <0 62 0>; + interrupt-names = "macirq", "eth_wake_irq"; + clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx"; + clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>; + st,syscon = <&syscfg 0x4>; + snps,pbl = <8>; + snps,mixed-burst; + phy-mode = "mii"; + }; - | //Example 3 - ethernet2: ethernet@40027000 { - compatible = "st,stm32-dwmac", "snps,dwmac-4.10a"; - reg = <0x40028000 0x8000>; - reg-names = "stmmaceth"; - interrupts = <61>; - interrupt-names = "macirq"; - clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx"; - clocks = <&rcc 62>, <&rcc 61>, <&rcc 60>; - st,syscon = <&syscfg 0x4>; - snps,pbl = <8>; - phy-mode = "mii"; - }; + ethernet2: ethernet@40027000 { + compatible = "st,stm32-dwmac", "snps,dwmac-4.10a"; + reg = <0x40028000 0x8000>; + reg-names = "stmmaceth"; + interrupts = <61>; + interrupt-names = "macirq"; + clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx"; + clocks = <&rcc 62>, <&rcc 61>, <&rcc 60>; + st,syscon = <&syscfg 0x4>; + snps,pbl = <8>; + phy-mode = "mii"; + }; diff --git a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml index 53604fab0b73..08119b6880ee 100644 --- a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml +++ b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml @@ -72,9 +72,9 @@ unevaluatedProperties: false examples: - | davinci_mdio: mdio@4a101000 { - compatible = "ti,davinci_mdio"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x4a101000 0x1000>; - bus_freq = <1000000>; + compatible = "ti,davinci_mdio"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x4a101000 0x1000>; + bus_freq = <1000000>; }; diff --git a/Documentation/devicetree/bindings/net/ti,dp83822.yaml b/Documentation/devicetree/bindings/net/ti,dp83822.yaml index 784866ea392b..50c24248df26 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83822.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml @@ -96,6 +96,32 @@ properties: - master - slave + ti,gpio2-clk-out: + description: | + DP83822 PHY only. + The GPIO2 pin on the DP83822 can be configured as clock output. When + omitted, the PHY's default will be left as is. + + - 'mac-if': In MII mode the clock frequency is 25-MHz, in RMII Mode the + clock frequency is 50-MHz and in RGMII Mode the clock frequency is + 25-MHz. + - 'xi': XI clock(pass-through clock from XI pin). + - 'int-ref': Internal reference clock 25-MHz. + - 'rmii-master-mode-ref': RMII master mode reference clock 50-MHz. RMII + master mode reference clock is identical to MAC IF clock in RMII master + mode. + - 'free-running': Free running clock 125-MHz. + - 'recovered': Recovered clock is a 125-MHz recovered clock from a + connected link partner. + $ref: /schemas/types.yaml#/definitions/string + enum: + - mac-if + - xi + - int-ref + - rmii-master-mode-ref + - free-running + - recovered + required: - reg @@ -110,6 +136,7 @@ examples: reg = <0>; rx-internal-delay-ps = <1>; tx-internal-delay-ps = <1>; + ti,gpio2-clk-out = "xi"; }; }; diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml index 02b6d32003cc..b11894fbaec4 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml @@ -302,16 +302,16 @@ examples: ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>; }; }; - }; - cpts@3d000 { - compatible = "ti,am65-cpts"; - reg = <0x0 0x3d000 0x0 0x400>; - clocks = <&k3_clks 18 2>; - clock-names = "cpts"; - interrupts-extended = <&gic500 GIC_SPI 858 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "cpts"; - ti,cpts-ext-ts-inputs = <4>; - ti,cpts-periodic-outputs = <2>; + cpts@3d000 { + compatible = "ti,am65-cpts"; + reg = <0x0 0x3d000 0x0 0x400>; + clocks = <&k3_clks 18 2>; + clock-names = "cpts"; + interrupts-extended = <&gic500 GIC_SPI 858 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "cpts"; + ti,cpts-ext-ts-inputs = <4>; + ti,cpts-periodic-outputs = <2>; + }; }; }; diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml index 3888692275ad..3572749147fb 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml @@ -131,23 +131,23 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> cpts@310d0000 { - compatible = "ti,am65-cpts"; - reg = <0x310d0000 0x400>; - reg-names = "cpts"; - clocks = <&main_cpts_mux>; - clock-names = "cpts"; - interrupts-extended = <&k3_irq 163 0 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "cpts"; - ti,cpts-periodic-outputs = <6>; - ti,cpts-ext-ts-inputs = <8>; - - main_cpts_mux: refclk-mux { - #clock-cells = <0>; - clocks = <&k3_clks 118 5>, <&k3_clks 118 11>, - <&k3_clks 157 91>, <&k3_clks 157 77>, - <&k3_clks 157 102>, <&k3_clks 157 80>, - <&k3_clks 120 3>, <&k3_clks 121 3>; - assigned-clocks = <&main_cpts_mux>; - assigned-clock-parents = <&k3_clks 118 11>; - }; + compatible = "ti,am65-cpts"; + reg = <0x310d0000 0x400>; + reg-names = "cpts"; + clocks = <&main_cpts_mux>; + clock-names = "cpts"; + interrupts-extended = <&k3_irq 163 0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "cpts"; + ti,cpts-periodic-outputs = <6>; + ti,cpts-ext-ts-inputs = <8>; + + main_cpts_mux: refclk-mux { + #clock-cells = <0>; + clocks = <&k3_clks 118 5>, <&k3_clks 118 11>, + <&k3_clks 157 91>, <&k3_clks 157 77>, + <&k3_clks 157 102>, <&k3_clks 157 80>, + <&k3_clks 120 3>, <&k3_clks 121 3>; + assigned-clocks = <&main_cpts_mux>; + assigned-clock-parents = <&k3_clks 118 11>; + }; }; diff --git a/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml b/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml index 1715b22e0dcf..930b700b73d0 100644 --- a/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml +++ b/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml @@ -79,15 +79,14 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> mmc { - #address-cells = <1>; - #size-cells = <0>; - - wifi@1 { - compatible = "marvell,sd8897"; - reg = <1>; - interrupt-parent = <&pio>; - interrupts = <38 IRQ_TYPE_LEVEL_LOW>; - marvell,wakeup-pin = <3>; + #address-cells = <1>; + #size-cells = <0>; + + wifi@1 { + compatible = "marvell,sd8897"; + reg = <1>; + interrupt-parent = <&pio>; + interrupts = <38 IRQ_TYPE_LEVEL_LOW>; + marvell,wakeup-pin = <3>; }; }; - diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml index 070c4c9b8643..aace072e2d52 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml @@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies ath10k wireless devices maintainers: - - Kalle Valo <kvalo@kernel.org> - Jeff Johnson <jjohnson@kernel.org> description: diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml index a71fdf05bc1e..a4425cf196ab 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml @@ -8,7 +8,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies ath11k wireless devices (PCIe) maintainers: - - Kalle Valo <kvalo@kernel.org> - Jeff Johnson <jjohnson@kernel.org> description: | diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml index ff5763dc66a8..a69ffb7b3cb8 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml @@ -8,7 +8,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies ath11k wireless devices maintainers: - - Kalle Valo <kvalo@kernel.org> - Jeff Johnson <jjohnson@kernel.org> description: | diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml new file mode 100644 index 000000000000..318f305405e3 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml @@ -0,0 +1,203 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k-wsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies ath12k wireless devices (PCIe) with WSI interface + +maintainers: + - Jeff Johnson <jjohnson@kernel.org> + +description: | + Qualcomm Technologies IEEE 802.11be PCIe devices with WSI interface. + + The ath12k devices (QCN9274) feature WSI support. WSI stands for + WLAN Serial Interface. It is used for the exchange of specific + control information across radios based on the doorbell mechanism. + This WSI connection is essential to exchange control information + among these devices. + + The WSI interface includes TX and RX ports, which are used to connect + multiple WSI-supported devices together, forming a WSI group. + + Diagram to represent one WSI connection (one WSI group) among + three devices. + + +-------+ +-------+ +-------+ + | pcie1 | | pcie2 | | pcie3 | + | | | | | | + +----->| wsi |------->| wsi |------->| wsi |-----+ + | | grp 0 | | grp 0 | | grp 0 | | + | +-------+ +-------+ +-------+ | + +------------------------------------------------------+ + + Diagram to represent two WSI connections (two separate WSI groups) + among four devices. + + +-------+ +-------+ +-------+ +-------+ + | pcie0 | | pcie1 | | pcie2 | | pcie3 | + | | | | | | | | + +-->| wsi |--->| wsi |--+ +-->| wsi |--->| wsi |--+ + | | grp 0 | | grp 0 | | | | grp 1 | | grp 1 | | + | +-------+ +-------+ | | +-------+ +-------+ | + +---------------------------+ +---------------------------+ + +properties: + compatible: + enum: + - pci17cb,1109 # QCN9274 + + reg: + maxItems: 1 + + qcom,ath12k-calibration-variant: + $ref: /schemas/types.yaml#/definitions/string + description: + String to uniquely identify variant of the calibration data for designs + with colliding bus and device ids + + qcom,wsi-controller: + $ref: /schemas/types.yaml#/definitions/flag + description: + The WSI controller device in the WSI group aids (is capable) to + synchronize the Timing Synchronization Function (TSF) clock across + all devices in the WSI group. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + This is the TX port of WSI interface. It is attached to the RX + port of the next device in the WSI connection. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + This is the RX port of WSI interface. It is attached to the TX + port of the previous device in the WSI connection. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + pcie { + #address-cells = <3>; + #size-cells = <2>; + + pcie@0 { + device_type = "pci"; + reg = <0x0 0x0 0x0 0x0 0x0>; + #address-cells = <3>; + #size-cells = <2>; + ranges; + + wifi@0 { + compatible = "pci17cb,1109"; + reg = <0x0 0x0 0x0 0x0 0x0>; + + qcom,ath12k-calibration-variant = "RDP433_1"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + wifi1_wsi_tx: endpoint { + remote-endpoint = <&wifi2_wsi_rx>; + }; + }; + + port@1 { + reg = <1>; + + wifi1_wsi_rx: endpoint { + remote-endpoint = <&wifi3_wsi_tx>; + }; + }; + }; + }; + }; + + pcie@1 { + device_type = "pci"; + reg = <0x0 0x0 0x1 0x0 0x0>; + #address-cells = <3>; + #size-cells = <2>; + ranges; + + wifi@0 { + compatible = "pci17cb,1109"; + reg = <0x0 0x0 0x0 0x0 0x0>; + + qcom,ath12k-calibration-variant = "RDP433_2"; + qcom,wsi-controller; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + wifi2_wsi_tx: endpoint { + remote-endpoint = <&wifi3_wsi_rx>; + }; + }; + + port@1 { + reg = <1>; + + wifi2_wsi_rx: endpoint { + remote-endpoint = <&wifi1_wsi_tx>; + }; + }; + }; + }; + }; + + pcie@2 { + device_type = "pci"; + reg = <0x0 0x0 0x2 0x0 0x0>; + #address-cells = <3>; + #size-cells = <2>; + ranges; + + wifi@0 { + compatible = "pci17cb,1109"; + reg = <0x0 0x0 0x0 0x0 0x0>; + + qcom,ath12k-calibration-variant = "RDP433_3"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + wifi3_wsi_tx: endpoint { + remote-endpoint = <&wifi1_wsi_rx>; + }; + }; + + port@1 { + reg = <1>; + + wifi3_wsi_rx: endpoint { + remote-endpoint = <&wifi2_wsi_tx>; + }; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml index 1b5884015b15..9e557cb838c7 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml @@ -9,7 +9,6 @@ title: Qualcomm Technologies ath12k wireless devices (PCIe) maintainers: - Jeff Johnson <quic_jjohnson@quicinc.com> - - Kalle Valo <kvalo@kernel.org> description: Qualcomm Technologies IEEE 802.11be PCIe devices. diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml index 80845c722ae4..39c209249c9c 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml @@ -20,18 +20,23 @@ properties: - qcom,apq8064-qfprom - qcom,apq8084-qfprom - qcom,ipq5332-qfprom + - qcom,ipq5424-qfprom - qcom,ipq6018-qfprom - qcom,ipq8064-qfprom - qcom,ipq8074-qfprom - qcom,ipq9574-qfprom - qcom,msm8226-qfprom - qcom,msm8916-qfprom + - qcom,msm8917-qfprom - qcom,msm8974-qfprom - qcom,msm8976-qfprom - qcom,msm8996-qfprom - qcom,msm8998-qfprom - qcom,qcm2290-qfprom - qcom,qcs404-qfprom + - qcom,qcs615-qfprom + - qcom,qcs8300-qfprom + - qcom,sar2130p-qfprom - qcom,sc7180-qfprom - qcom,sc7280-qfprom - qcom,sc8280xp-qfprom diff --git a/Documentation/devicetree/bindings/nvmem/rmem.yaml b/Documentation/devicetree/bindings/nvmem/rmem.yaml index 1ec0d09bcafa..85f9f5de3906 100644 --- a/Documentation/devicetree/bindings/nvmem/rmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/rmem.yaml @@ -16,6 +16,7 @@ properties: compatible: items: - enum: + - mobileye,eyeq5-bootloader-config - raspberrypi,bootloader-config - raspberrypi,bootloader-public-key - const: nvmem-rmem diff --git a/Documentation/devicetree/bindings/nvmem/sprd,sc2731-efuse.yaml b/Documentation/devicetree/bindings/nvmem/sprd,sc2731-efuse.yaml index dc25fe3d1841..8672bde24a9b 100644 --- a/Documentation/devicetree/bindings/nvmem/sprd,sc2731-efuse.yaml +++ b/Documentation/devicetree/bindings/nvmem/sprd,sc2731-efuse.yaml @@ -36,33 +36,4 @@ allOf: - $ref: nvmem-deprecated-cells.yaml# unevaluatedProperties: false - -examples: - - | - pmic { - #address-cells = <1>; - #size-cells = <0>; - - efuse@380 { - compatible = "sprd,sc2731-efuse"; - reg = <0x380>; - hwlocks = <&hwlock 12>; - #address-cells = <1>; - #size-cells = <1>; - - /* Data cells */ - fgu_calib: calib@6 { - reg = <0x6 0x2>; - bits = <0 9>; - }; - - adc_big_scale: calib@24 { - reg = <0x24 0x2>; - }; - - adc_small_scale: calib@26 { - reg = <0x26 0x2>; - }; - }; - }; ... diff --git a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml index ec5e424bb3c8..75ab552f6ecd 100644 --- a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml +++ b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml @@ -22,6 +22,7 @@ allOf: properties: compatible: enum: + - allwinner,sun50i-a100-operating-points - allwinner,sun50i-h6-operating-points - allwinner,sun50i-h616-operating-points diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml index a8b34f58f8f4..cddbe21f99f2 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml @@ -17,11 +17,11 @@ description: properties: clocks: minItems: 3 - maxItems: 4 + maxItems: 5 clock-names: minItems: 3 - maxItems: 4 + maxItems: 5 num-lanes: const: 1 diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml index 84ca12e8b25b..0b3526de1d62 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml @@ -22,6 +22,7 @@ properties: - fsl,imx8mm-pcie-ep - fsl,imx8mq-pcie-ep - fsl,imx8mp-pcie-ep + - fsl,imx8q-pcie-ep - fsl,imx95-pcie-ep clocks: @@ -78,6 +79,20 @@ allOf: properties: compatible: enum: + - fsl,imx8q-pcie-ep + then: + properties: + reg: + maxItems: 2 + reg-names: + items: + - const: dbi + - const: addr_space + + - if: + properties: + compatible: + enum: - fsl,imx95-pcie-ep then: properties: @@ -103,13 +118,21 @@ allOf: properties: clocks: minItems: 4 + maxItems: 4 clock-names: items: - const: pcie - const: pcie_bus - const: pcie_phy - const: pcie_aux - else: + + - if: + properties: + compatible: + enum: + - fsl,imx8mm-pcie-ep + - fsl,imx8mp-pcie-ep + then: properties: clocks: maxItems: 3 @@ -119,6 +142,20 @@ allOf: - const: pcie_bus - const: pcie_aux + - if: + properties: + compatible: + enum: + - fsl,imxq-pcie-ep + then: + properties: + clocks: + maxItems: 3 + clock-names: + items: + - const: dbi + - const: mstr + - const: slv unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index 1e05c560d797..4c76cd3f98a9 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -40,10 +40,11 @@ properties: - description: PCIe PHY clock. - description: Additional required clock entry for imx6sx-pcie, imx6sx-pcie-ep, imx8mq-pcie, imx8mq-pcie-ep. + - description: PCIe reference clock. clock-names: minItems: 3 - maxItems: 4 + maxItems: 5 interrupts: items: @@ -127,7 +128,7 @@ allOf: then: properties: clocks: - minItems: 4 + maxItems: 4 clock-names: items: - const: pcie @@ -140,11 +141,10 @@ allOf: compatible: enum: - fsl,imx8mq-pcie - - fsl,imx95-pcie then: properties: clocks: - minItems: 4 + maxItems: 4 clock-names: items: - const: pcie @@ -200,6 +200,23 @@ allOf: - const: mstr - const: slv + - if: + properties: + compatible: + enum: + - fsl,imx95-pcie + then: + properties: + clocks: + maxItems: 5 + clock-names: + items: + - const: pcie + - const: pcie_bus + - const: pcie_phy + - const: pcie_aux + - const: ref + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt b/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt deleted file mode 100644 index b40fb5d15d3d..000000000000 --- a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt +++ /dev/null @@ -1,52 +0,0 @@ -NXP Layerscape PCIe Gen4 controller - -This PCIe controller is based on the Mobiveil PCIe IP and thus inherits all -the common properties defined in mobiveil-pcie.txt. - -Required properties: -- compatible: should contain the platform identifier such as: - "fsl,lx2160a-pcie" -- reg: base addresses and lengths of the PCIe controller register blocks. - "csr_axi_slave": Bridge config registers - "config_axi_slave": PCIe controller registers -- interrupts: A list of interrupt outputs of the controller. Must contain an - entry for each entry in the interrupt-names property. -- interrupt-names: It could include the following entries: - "intr": The interrupt that is asserted for controller interrupts - "aer": Asserted for aer interrupt when chip support the aer interrupt with - none MSI/MSI-X/INTx mode,but there is interrupt line for aer. - "pme": Asserted for pme interrupt when chip support the pme interrupt with - none MSI/MSI-X/INTx mode,but there is interrupt line for pme. -- dma-coherent: Indicates that the hardware IP block can ensure the coherency - of the data transferred from/to the IP block. This can avoid the software - cache flush/invalid actions, and improve the performance significantly. -- msi-parent : See the generic MSI binding described in - Documentation/devicetree/bindings/interrupt-controller/msi.txt. - -Example: - - pcie@3400000 { - compatible = "fsl,lx2160a-pcie"; - reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */ - 0x80 0x00000000 0x0 0x00001000>; /* configuration space */ - reg-names = "csr_axi_slave", "config_axi_slave"; - interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */ - <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */ - <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */ - interrupt-names = "aer", "pme", "intr"; - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - apio-wins = <8>; - ppio-wins = <8>; - dma-coherent; - bus-range = <0x0 0xff>; - msi-parent = <&its>; - ranges = <0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 7>; - interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, - <0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>, - <0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>, - <0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>; - }; diff --git a/Documentation/devicetree/bindings/pci/mbvl,gpex40-pcie.yaml b/Documentation/devicetree/bindings/pci/mbvl,gpex40-pcie.yaml new file mode 100644 index 000000000000..d286b77921e0 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/mbvl,gpex40-pcie.yaml @@ -0,0 +1,173 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/mbvl,gpex40-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mobiveil AXI PCIe Host Bridge + +maintainers: + - Frank Li <Frank Li@nxp.com> + +description: + Mobiveil's GPEX 4.0 is a PCIe Gen4 host bridge IP. This configurable IP + has up to 8 outbound and inbound windows for address translation. + + NXP Layerscape PCIe Gen4 controller (Deprecated) base on Mobiveil's GPEX 4.0. + +properties: + compatible: + enum: + - fsl,lx2160a-pcie + - mbvl,gpex40-pcie + + reg: + items: + - description: PCIe controller registers + - description: Bridge config registers + - description: GPIO registers to control slot power + - description: MSI registers + minItems: 2 + + reg-names: + items: + - const: csr_axi_slave + - const: config_axi_slave + - const: gpio_slave + - const: apb_csr + minItems: 2 + + apio-wins: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + number of requested APIO outbound windows + 1. Config window + 2. Memory window + default: 2 + maximum: 256 + + ppio-wins: + $ref: /schemas/types.yaml#/definitions/uint32 + description: number of requested PPIO inbound windows + default: 1 + maximum: 256 + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + + interrupts: + minItems: 1 + maxItems: 3 + + interrupt-names: + minItems: 1 + maxItems: 3 + + dma-coherent: true + + msi-parent: true + +required: + - compatible + - reg + - reg-names + +allOf: + - $ref: /schemas/pci/pci-host-bridge.yaml# + - if: + properties: + compatible: + enum: + - fsl,lx2160a-pcie + then: + properties: + reg: + maxItems: 2 + + reg-names: + maxItems: 2 + + interrupts: + minItems: 3 + + interrupt-names: + items: + - const: aer + - const: pme + - const: intr + else: + properties: + dma-coherent: false + msi-parent: false + interrupts: + maxItems: 1 + interrupt-names: false + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + pcie@b0000000 { + compatible = "mbvl,gpex40-pcie"; + reg = <0xb0000000 0x00010000>, + <0xa0000000 0x00001000>, + <0xff000000 0x00200000>, + <0xb0010000 0x00001000>; + reg-names = "csr_axi_slave", + "config_axi_slave", + "gpio_slave", + "apb_csr"; + ranges = <0x83000000 0 0x00000000 0xa8000000 0 0x8000000>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + apio-wins = <2>; + ppio-wins = <1>; + bus-range = <0x00 0xff>; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 0 &pci_express 0>, + <0 0 0 1 &pci_express 1>, + <0 0 0 2 &pci_express 2>, + <0 0 0 3 &pci_express 3>; + }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + pcie@3400000 { + compatible = "fsl,lx2160a-pcie"; + reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */ + 0x80 0x00000000 0x0 0x00001000>; /* configuration space */ + reg-names = "csr_axi_slave", "config_axi_slave"; + ranges = <0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */ + <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */ + <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */ + interrupt-names = "aer", "pme", "intr"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + apio-wins = <8>; + ppio-wins = <8>; + dma-coherent; + bus-range = <0x00 0xff>; + msi-parent = <&its>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, + <0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>, + <0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>, + <0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml index 2e1547569702..103574d18dbc 100644 --- a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml @@ -50,6 +50,8 @@ properties: items: pattern: '^fic[0-3]$' + dma-coherent: true + ranges: minItems: 1 maxItems: 3 diff --git a/Documentation/devicetree/bindings/pci/mobiveil-pcie.txt b/Documentation/devicetree/bindings/pci/mobiveil-pcie.txt deleted file mode 100644 index 64156993e052..000000000000 --- a/Documentation/devicetree/bindings/pci/mobiveil-pcie.txt +++ /dev/null @@ -1,72 +0,0 @@ -* Mobiveil AXI PCIe Root Port Bridge DT description - -Mobiveil's GPEX 4.0 is a PCIe Gen4 root port bridge IP. This configurable IP -has up to 8 outbound and inbound windows for the address translation. - -Required properties: -- #address-cells: Address representation for root ports, set to <3> -- #size-cells: Size representation for root ports, set to <2> -- #interrupt-cells: specifies the number of cells needed to encode an - interrupt source. The value must be 1. -- compatible: Should contain "mbvl,gpex40-pcie" -- reg: Should contain PCIe registers location and length - Mandatory: - "config_axi_slave": PCIe controller registers - "csr_axi_slave" : Bridge config registers - Optional: - "gpio_slave" : GPIO registers to control slot power - "apb_csr" : MSI registers - -- device_type: must be "pci" -- apio-wins : number of requested apio outbound windows - default 2 outbound windows are configured - - 1. Config window - 2. Memory window -- ppio-wins : number of requested ppio inbound windows - default 1 inbound memory window is configured. -- bus-range: PCI bus numbers covered -- interrupt-controller: identifies the node as an interrupt controller -- #interrupt-cells: specifies the number of cells needed to encode an - interrupt source. The value must be 1. -- interrupts: The interrupt line of the PCIe controller - last cell of this field is set to 4 to - denote it as IRQ_TYPE_LEVEL_HIGH type interrupt. -- interrupt-map-mask, - interrupt-map: standard PCI properties to define the mapping of the - PCI interface to interrupt numbers. -- ranges: ranges for the PCI memory regions (I/O space region is not - supported by hardware) - Please refer to the standard PCI bus binding document for a more - detailed explanation - - -Example: -++++++++ - pcie0: pcie@a0000000 { - #address-cells = <3>; - #size-cells = <2>; - compatible = "mbvl,gpex40-pcie"; - reg = <0xa0000000 0x00001000>, - <0xb0000000 0x00010000>, - <0xff000000 0x00200000>, - <0xb0010000 0x00001000>; - reg-names = "config_axi_slave", - "csr_axi_slave", - "gpio_slave", - "apb_csr"; - device_type = "pci"; - apio-wins = <2>; - ppio-wins = <1>; - bus-range = <0x00000000 0x000000ff>; - interrupt-controller; - interrupt-parent = <&gic>; - #interrupt-cells = <1>; - interrupts = < 0 89 4 >; - interrupt-map-mask = <0 0 0 7>; - interrupt-map = <0 0 0 0 &pci_express 0>, - <0 0 0 1 &pci_express 1>, - <0 0 0 2 &pci_express 2>, - <0 0 0 3 &pci_express 3>; - ranges = < 0x83000000 0 0x00000000 0xa8000000 0 0x8000000>; - - }; diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml index 2b5498a35dcc..dbce671ba011 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml @@ -57,9 +57,10 @@ properties: interrupts: minItems: 8 - maxItems: 8 + maxItems: 9 interrupt-names: + minItems: 8 items: - const: msi0 - const: msi1 @@ -69,6 +70,7 @@ properties: - const: msi5 - const: msi6 - const: msi7 + - const: global resets: minItems: 1 @@ -139,9 +141,10 @@ examples: <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>; + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "msi0", "msi1", "msi2", "msi3", - "msi4", "msi5", "msi6", "msi7"; + "msi4", "msi5", "msi6", "msi7", "global"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0x7>; interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml index bd87f6b49d68..7235d6554cfb 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml @@ -32,6 +32,10 @@ properties: - qcom,pcie-sdm845 - qcom,pcie-sdx55 - items: + - enum: + - qcom,pcie-ipq5424 + - const: qcom,pcie-ipq9574 + - items: - const: qcom,pcie-msm8998 - const: qcom,pcie-msm8996 diff --git a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml index 989fb0fa2577..b63a759ec2d7 100644 --- a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml +++ b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml @@ -17,6 +17,7 @@ properties: enum: - xlnx,versal-cpm-host-1.00 - xlnx,versal-cpm5-host + - xlnx,versal-cpm5-host1 reg: items: diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml index d3cd7997879f..1b3de6678c08 100644 --- a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml @@ -13,6 +13,7 @@ properties: compatible: enum: - rockchip,rk3568-naneng-combphy + - rockchip,rk3576-naneng-combphy - rockchip,rk3588-naneng-combphy reg: diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml index 58ce2d91d28c..f60804687412 100644 --- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml @@ -15,12 +15,21 @@ description: properties: compatible: - enum: - - qcom,ipq6018-qmp-pcie-phy - - qcom,ipq8074-qmp-gen3-pcie-phy - - qcom,ipq8074-qmp-pcie-phy - - qcom,ipq9574-qmp-gen3x1-pcie-phy - - qcom,ipq9574-qmp-gen3x2-pcie-phy + oneOf: + - enum: + - qcom,ipq6018-qmp-pcie-phy + - qcom,ipq8074-qmp-gen3-pcie-phy + - qcom,ipq8074-qmp-pcie-phy + - qcom,ipq9574-qmp-gen3x1-pcie-phy + - qcom,ipq9574-qmp-gen3x2-pcie-phy + - items: + - enum: + - qcom,ipq5424-qmp-gen3x1-pcie-phy + - const: qcom,ipq9574-qmp-gen3x1-pcie-phy + - items: + - enum: + - qcom,ipq5424-qmp-gen3x2-pcie-phy + - const: qcom,ipq9574-qmp-gen3x2-pcie-phy reg: items: diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index 4aed4b5d65ec..39851ba9de43 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -18,6 +18,7 @@ properties: oneOf: - items: - enum: + - qcom,ipq5424-qusb2-phy - qcom,ipq6018-qusb2-phy - qcom,ipq8074-qusb2-phy - qcom,ipq9574-qusb2-phy diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml index 13fdf5f1beba..89391649e0b5 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml @@ -16,8 +16,10 @@ description: properties: compatible: enum: + - qcom,qcs615-qmp-gen3x1-pcie-phy - qcom,sa8775p-qmp-gen4x2-pcie-phy - qcom,sa8775p-qmp-gen4x4-pcie-phy + - qcom,sar2130p-qmp-gen3x2-pcie-phy - qcom,sc8180x-qmp-pcie-phy - qcom,sc8280xp-qmp-gen3x1-pcie-phy - qcom,sc8280xp-qmp-gen3x2-pcie-phy @@ -32,6 +34,7 @@ properties: - qcom,sm8250-qmp-gen3x2-pcie-phy - qcom,sm8250-qmp-modem-pcie-phy - qcom,sm8350-qmp-gen3x1-pcie-phy + - qcom,sm8350-qmp-gen3x2-pcie-phy - qcom,sm8450-qmp-gen3x1-pcie-phy - qcom,sm8450-qmp-gen4x2-pcie-phy - qcom,sm8550-qmp-gen3x2-pcie-phy @@ -139,6 +142,7 @@ allOf: compatible: contains: enum: + - qcom,sar2130p-qmp-gen3x2-pcie-phy - qcom,sc8180x-qmp-pcie-phy - qcom,sdm845-qhp-pcie-phy - qcom,sdm845-qmp-pcie-phy @@ -149,6 +153,7 @@ allOf: - qcom,sm8250-qmp-gen3x2-pcie-phy - qcom,sm8250-qmp-modem-pcie-phy - qcom,sm8350-qmp-gen3x1-pcie-phy + - qcom,sm8350-qmp-gen3x2-pcie-phy - qcom,sm8450-qmp-gen3x1-pcie-phy - qcom,sm8450-qmp-gen3x2-pcie-phy - qcom,sm8550-qmp-gen3x2-pcie-phy @@ -167,6 +172,7 @@ allOf: compatible: contains: enum: + - qcom,qcs615-qmp-gen3x1-pcie-phy - qcom,sc8280xp-qmp-gen3x1-pcie-phy - qcom,sc8280xp-qmp-gen3x2-pcie-phy - qcom,sc8280xp-qmp-gen3x4-pcie-phy diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml index baf5134ea3d8..a1b55168e050 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml @@ -16,6 +16,7 @@ description: properties: compatible: enum: + - qcom,ipq5424-qmp-usb3-phy - qcom,ipq6018-qmp-usb3-phy - qcom,ipq8074-qmp-usb3-phy - qcom,ipq9574-qmp-usb3-phy @@ -89,6 +90,7 @@ allOf: compatible: contains: enum: + - qcom,ipq5424-qmp-usb3-phy - qcom,ipq6018-qmp-usb3-phy - qcom,ipq8074-qmp-usb3-phy - qcom,ipq9574-qmp-usb3-phy diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml index 2d0d7e9e6431..358a6736a951 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml @@ -16,6 +16,7 @@ description: properties: compatible: enum: + - qcom,sar2130p-qmp-usb3-dp-phy - qcom,sc7180-qmp-usb3-dp-phy - qcom,sc7280-qmp-usb3-dp-phy - qcom,sc8180x-qmp-usb3-dp-phy @@ -127,6 +128,7 @@ allOf: properties: compatible: enum: + - qcom,sar2130p-qmp-usb3-dp-phy - qcom,sc8280xp-qmp-usb43dp-phy - qcom,sm6350-qmp-usb3-dp-phy - qcom,sm8550-qmp-usb3-dp-phy diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml index 450240570314..990b78765427 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml @@ -44,6 +44,7 @@ properties: - allwinner,sun8i-r40-pinctrl - allwinner,sun8i-v3-pinctrl - allwinner,sun8i-v3s-pinctrl + - allwinner,sun8i-v853-pinctrl - allwinner,sun9i-a80-pinctrl - allwinner,sun9i-a80-r-pinctrl - allwinner,sun20i-d1-pinctrl @@ -183,6 +184,18 @@ allOf: properties: compatible: enum: + - allwinner,sun8i-v853-pinctrl + + then: + properties: + interrupts: + minItems: 8 + maxItems: 8 + + - if: + properties: + compatible: + enum: - allwinner,sun20i-d1-pinctrl then: diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91rm9200-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/atmel,at91rm9200-pinctrl.yaml index 1bb386b42039..a7ede29c1444 100644 --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91rm9200-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91rm9200-pinctrl.yaml @@ -145,40 +145,40 @@ additionalProperties: examples: - | - #include <dt-bindings/clock/at91.h> - #include <dt-bindings/interrupt-controller/irq.h> - #include <dt-bindings/pinctrl/at91.h> - - pinctrl@fffff400 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "atmel,at91rm9200-pinctrl", "simple-mfd"; - ranges = <0xfffff400 0xfffff400 0x600>; - - atmel,mux-mask = < - /* A B */ - 0xffffffff 0xffc00c3b /* pioA */ - 0xffffffff 0x7fff3ccf /* pioB */ - 0xffffffff 0x007fffff /* pioC */ - >; - - dbgu { - pinctrl_dbgu: dbgu-0 { - atmel,pins = - <AT91_PIOB 14 AT91_PERIPH_A AT91_PINCTRL_PULL_UP - AT91_PIOB 15 AT91_PERIPH_A AT91_PINCTRL_NONE>; - }; - }; - - pioA: gpio@fffff400 { - compatible = "atmel,at91rm9200-gpio"; - reg = <0xfffff400 0x200>; - interrupts = <2 IRQ_TYPE_LEVEL_HIGH 1>; - #gpio-cells = <2>; - gpio-controller; - interrupt-controller; - #interrupt-cells = <2>; - clocks = <&pmc PMC_TYPE_PERIPHERAL 2>; - }; - }; + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/pinctrl/at91.h> + + pinctrl@fffff400 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "atmel,at91rm9200-pinctrl", "simple-mfd"; + ranges = <0xfffff400 0xfffff400 0x600>; + + atmel,mux-mask = < + /* A B */ + 0xffffffff 0xffc00c3b /* pioA */ + 0xffffffff 0x7fff3ccf /* pioB */ + 0xffffffff 0x007fffff /* pioC */ + >; + + dbgu { + dbgu-0 { + atmel,pins = + <AT91_PIOB 14 AT91_PERIPH_A AT91_PINCTRL_PULL_UP + AT91_PIOB 15 AT91_PERIPH_A AT91_PINCTRL_NONE>; + }; + }; + + gpio@fffff400 { + compatible = "atmel,at91rm9200-gpio"; + reg = <0xfffff400 0x200>; + interrupts = <2 IRQ_TYPE_LEVEL_HIGH 1>; + #gpio-cells = <2>; + gpio-controller; + interrupt-controller; + #interrupt-cells = <2>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 2>; + }; + }; ... diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7988-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7988-pinctrl.yaml new file mode 100644 index 000000000000..26dfe7e7735a --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7988-pinctrl.yaml @@ -0,0 +1,575 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7988-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek MT7988 Pin Controller + +maintainers: + - Sean Wang <sean.wang@kernel.org> + +description: + The MediaTek's MT7988 Pin controller is used to control SoC pins. + +properties: + compatible: + enum: + - mediatek,mt7988-pinctrl + + reg: + minItems: 7 + maxItems: 7 + + reg-names: + items: + - const: gpio + - const: iocfg_tr + - const: iocfg_br + - const: iocfg_rb + - const: iocfg_lb + - const: iocfg_tl + - const: eint + + gpio-controller: true + + "#gpio-cells": + const: 2 + + gpio-ranges: + minItems: 1 + maxItems: 5 + description: + GPIO valid number range. + + interrupt-controller: true + + interrupts: + maxItems: 1 + + "#interrupt-cells": + const: 2 + +allOf: + - $ref: pinctrl.yaml# + +required: + - compatible + - reg + - reg-names + - gpio-controller + - "#gpio-cells" + +patternProperties: + '-pins$': + type: object + additionalProperties: false + + properties: + mux: + type: object + additionalProperties: false + $ref: /schemas/pinctrl/pinmux-node.yaml + description: | + pinmux configuration nodes. + + The following table shows the effective values of "group", "function" + properties and chip pinout pins + + groups function pins (in pin#) + --------------------------------------------------------------------- + "tops_jtag0_0" "jtag" 0, 1, 2, 3, 4 + "wo0_jtag" "jtag" 50, 51, 52, 53, 54 + "wo1_jtag" "jtag" 50, 51, 52, 53, 54 + "wo2_jtag" "jtag" 50, 51, 52, 53, 54 + "jtag" "jtag" 58, 59, 60, 61, 62 + "tops_jtag0_1" "jtag" 58, 59, 60, 61, 62 + "int_usxgmii" "int_usxgmii" 2, 3 + "pwm0" "pwm" 57 + "pwm1" "pwm" 21 + "pwm2" "pwm" 80 + "pwm2_0" "pwm" 58 + "pwm3" "pwm" 81 + "pwm3_0" "pwm" 59 + "pwm4" "pwm" 82 + "pwm4_0" "pwm" 60 + "pwm5" "pwm" 83 + "pwm5_0" "pwm" 61 + "pwm6" "pwm" 69 + "pwm6_0" "pwm" 62 + "pwm7" "pwm" 70 + "pwm7_0" "pwm" 4 + "dfd" "dfd" 0, 1, 2, 3, 4 + "xfi_phy0_i2c0" "i2c" 0, 1 + "xfi_phy1_i2c0" "i2c" 0, 1 + "xfi_phy_pll_i2c0" "i2c" 3, 4 + "xfi_phy_pll_i2c1" "i2c" 3, 4 + "i2c0_0" "i2c" 5, 6 + "i2c1_sfp" "i2c" 5, 6 + "xfi_pextp_phy0_i2c" "i2c" 5, 6 + "xfi_pextp_phy1_i2c" "i2c" 5, 6 + "i2c0_1" "i2c" 15, 16 + "u30_phy_i2c0" "i2c" 15, 16 + "u32_phy_i2c0" "i2c" 15, 16 + "xfi_phy0_i2c1" "i2c" 15, 16 + "xfi_phy1_i2c1" "i2c" 15, 16 + "xfi_phy_pll_i2c2" "i2c" 15, 16 + "i2c1_0" "i2c" 17, 18 + "u30_phy_i2c1" "i2c" 17, 18 + "u32_phy_i2c1" "i2c" 17, 18 + "xfi_phy_pll_i2c3" "i2c" 17, 18 + "sgmii0_i2c" "i2c" 17, 18 + "sgmii1_i2c" "i2c" 17, 18 + "i2c1_2" "i2c" 69, 70 + "i2c2_0" "i2c" 69, 70 + "i2c2_1" "i2c" 71, 72 + "mdc_mdio0" "eth" 5, 6 + "2p5g_ext_mdio" "eth" 28, 29 + "gbe_ext_mdio" "eth" 30, 31 + "mdc_mdio1" "eth" 69, 70 + "pcie_wake_n0_0" "pcie" 7 + "pcie_clk_req_n0_0" "pcie" 8 + "pcie_wake_n3_0" "pcie" 9 + "pcie_clk_req_n3" "pcie" 10 + "pcie_clk_req_n0_1" "pcie" 10 + "pcie_p0_phy_i2c" "pcie" 7, 8 + "pcie_p1_phy_i2c" "pcie" 7, 8 + "pcie_p3_phy_i2c" "pcie" 9, 10 + "pcie_p2_phy_i2c" "pcie" 7, 8 + "ckm_phy_i2c" "pcie" 9, 10 + "pcie_wake_n0_1" "pcie" 13 + "pcie_wake_n3_1" "pcie" 14 + "pcie_2l_0_pereset" "pcie" 19 + "pcie_1l_1_pereset" "pcie" 20 + "pcie_clk_req_n2_1" "pcie" 63 + "pcie_2l_1_pereset" "pcie" 73 + "pcie_1l_0_pereset" "pcie" 74 + "pcie_wake_n1_0" "pcie" 75 + "pcie_clk_req_n1" "pcie" 76 + "pcie_wake_n2_0" "pcie" 77 + "pcie_clk_req_n2_0" "pcie" 78 + "pcie_wake_n2_1" "pcie" 79 + "pmic" "pmic" 11 + "watchdog" "watchdog" 12 + "spi0_wp_hold" "spi" 22, 23 + "spi0" "spi" 24, 25, 26, 27 + "spi1" "spi" 28, 29, 30, 31 + "spi2" "spi" 32, 33, 34, 35 + "spi2_wp_hold" "spi" 36, 37 + "snfi" "flash" 22, 23, 24, 25, 26, 27 + "emmc_45" "flash" 21, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37 + "sdcard" "flash" 32, 33, 34, 35, 36, 37 + "emmc_51" "flash" 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49 + "uart2" "uart" 0, 1, 2, 3 + "tops_uart0_0" "uart" 22, 23 + "uart2_0" "uart" 28, 29, 30, 31 + "uart1_0" "uart" 32, 33, 34, 35 + "uart2_1" "uart" 32, 33, 34, 35 + "net_wo0_uart_txd_0" "uart" 28 + "net_wo1_uart_txd_0" "uart" 29 + "net_wo2_uart_txd_0" "uart" 30 + "tops_uart1_0" "uart" 28, 29 + "tops_uart0_1" "uart" 30, 31 + "tops_uart1_1" "uart" 36, 37 + "uart0" "uart" 55, 56 + "tops_uart0_2" "uart" 55, 56 + "uart2_2" "uart" 50, 51, 52, 53 + "uart1_1" "uart" 58, 59, 60, 61 + "uart2_3" "uart" 58, 59, 60, 61 + "uart1_2" "uart" 80, 81, 82, 83 + "uart1_2_lite" "uart" 80, 81 + "tops_uart1_2" "uart" 80, 81 + "net_wo0_uart_txd_1" "uart" 80 + "net_wo1_uart_txd_1" "uart" 81 + "net_wo2_uart_txd_1" "uart" 82 + "udi" "udi" 32, 33, 34, 35, 36 + "i2s" "audio" 50, 51, 52, 53, 54 + "pcm" "audio" 50, 51, 52, 53 + "gbe0_led1" "led" 58 + "gbe1_led1" "led" 59 + "gbe2_led1" "led" 60 + "gbe3_led1" "led" 61 + "2p5gbe_led1" "led" 62 + "gbe0_led0" "led" 64 + "gbe1_led0" "led" 65 + "gbe2_led0" "led" 66 + "gbe3_led0" "led" 67 + "2p5gbe_led0" "led" 68 + "drv_vbus_p1" "usb" 63 + "drv_vbus" "usb" 79 + + properties: + function: + description: + A string containing the name of the function to mux to the group. + enum: [audio, dfd, eth, flash, i2c, int_usxgmii, jtag, led, pcie, pmic, pwm, spi, + uart, udi, usb, watchdog] + groups: + description: + An array of strings. Each string contains the name of a group. + + required: + - function + - groups + + allOf: + - if: + properties: + function: + const: audio + then: + properties: + groups: + enum: [i2s, pcm] + - if: + properties: + function: + const: jtag + then: + properties: + groups: + enum: [jtag, tops_jtag0_0, tops_jtag0_1, wo0_jtag, wo1_jtag, wo2_jtag] + - if: + properties: + function: + const: int_usxgmii + then: + properties: + groups: + const: int_usxgmii + - if: + properties: + function: + const: dfd + then: + properties: + groups: + const: dfd + - if: + properties: + function: + const: flash + then: + properties: + groups: + enum: [emmc_45, emmc_51, sdcard, snfi] + - if: + properties: + function: + const: eth + then: + properties: + groups: + enum: [2p5g_ext_mdio, gbe_ext_mdio, mdc_mdio0, mdc_mdio1] + - if: + properties: + function: + const: i2c + then: + properties: + groups: + enum: [xfi_phy0_i2c0, xfi_phy1_i2c0, xfi_phy_pll_i2c0, + xfi_phy_pll_i2c1, i2c0_0, i2c1_sfp, xfi_pextp_phy0_i2c, + xfi_pextp_phy1_i2c, i2c0_1, u30_phy_i2c0, u32_phy_i2c0, + xfi_phy0_i2c1, xfi_phy1_i2c1, xfi_phy_pll_i2c2, i2c1_0, + u30_phy_i2c1, u32_phy_i2c1, xfi_phy_pll_i2c3, sgmii0_i2c, + sgmii1_i2c, i2c1_2, i2c2_0, i2c2_1] + - if: + properties: + function: + const: led + then: + properties: + groups: + enum: [2p5gbe_led0, 2p5gbe_led1, gbe0_led0, gbe0_led1, gbe1_led0, gbe1_led1, + gbe2_led0, gbe2_led1, gbe3_led0, gbe3_led1, wf5g_led0, wf5g_led1] + - if: + properties: + function: + const: pcie + then: + properties: + groups: + items: + enum: [pcie_wake_n0_0, pcie_clk_req_n0_0, pcie_wake_n3_0, + pcie_clk_req_n3, pcie_p0_phy_i2c, pcie_p1_phy_i2c, + pcie_p3_phy_i2c, pcie_p2_phy_i2c, ckm_phy_i2c, + pcie_wake_n0_1, pcie_wake_n3_1, pcie_2l_0_pereset, + pcie_1l_1_pereset, pcie_clk_req_n2_1, pcie_2l_1_pereset, + pcie_1l_0_pereset, pcie_wake_n1_0, pcie_clk_req_n1, + pcie_wake_n2_0, pcie_clk_req_n2_0, pcie_wake_n2_1, + pcie_clk_req_n0_1] + maxItems: 3 + - if: + properties: + function: + const: pmic + then: + properties: + groups: + const: pmic + - if: + properties: + function: + const: pwm + then: + properties: + groups: + items: + enum: [pwm0, pwm1, pwm2, pwm2_0, pwm3, pwm3_0, pwm4, pwm4_0, pwm5, pwm5_0, + pwm6, pwm6_0, pwm7, pwm7_0] + maxItems: 2 + - if: + properties: + function: + const: spi + then: + properties: + groups: + items: + enum: [spi0, spi0_wp_hold, spi1, spi2, spi2_wp_hold] + maxItems: 2 + - if: + properties: + function: + const: uart + then: + properties: + groups: + items: + enum: [net_wo0_uart_txd_0, net_wo0_uart_txd_1, net_wo1_uart_txd_0, + net_wo1_uart_txd_1, net_wo2_uart_txd_0, net_wo2_uart_txd_1, + tops_uart0_0, tops_uart0_1, tops_uart0_2, tops_uart1_0, + tops_uart1_1, tops_uart1_2, uart0, uart1_0, uart1_1, uart1_2, + uart1_2_lite, uart2, uart2_0, uart2_1, uart2_3] + maxItems: 2 + - if: + properties: + function: + const: watchdog + then: + properties: + groups: + const: watchdog + - if: + properties: + function: + const: udi + then: + properties: + groups: + const: udi + - if: + properties: + function: + const: usb + then: + properties: + groups: + items: + enum: [drv_vbus, drv_vbus_p1] + maxItems: 1 + + patternProperties: + '^conf(-[-a-z]*)?$': + type: object + additionalProperties: false + description: + pinconf configuration nodes. + $ref: /schemas/pinctrl/pincfg-node.yaml + + properties: + pins: + description: + An array of strings. Each string contains the name of a pin. + items: + enum: [UART2_RXD, UART2_TXD, UART2_CTS, UART2_RTS, GPIO_A, SMI_0_MDC, + SMI_0_MDIO, PCIE30_2L_0_WAKE_N, PCIE30_2L_0_CLKREQ_N, + PCIE30_1L_1_WAKE_N, PCIE30_1L_1_CLKREQ_N, GPIO_P, WATCHDOG, + GPIO_RESET, GPIO_WPS, PMIC_I2C_SCL, PMIC_I2C_SDA, I2C_1_SCL, + I2C_1_SDA, PCIE30_2L_0_PRESET_N, PCIE30_1L_1_PRESET_N, PWMD1, + SPI0_WP, SPI0_HOLD, SPI0_CSB, SPI0_MISO, SPI0_MOSI, SPI0_CLK, + SPI1_CSB, SPI1_MISO, SPI1_MOSI, SPI1_CLK, SPI2_CLK, SPI2_MOSI, + SPI2_MISO, SPI2_CSB, SPI2_HOLD, SPI2_WP, EMMC_RSTB, EMMC_DSL, + EMMC_CK, EMMC_CMD, EMMC_DATA_7, EMMC_DATA_6, EMMC_DATA_5, + EMMC_DATA_4, EMMC_DATA_3, EMMC_DATA_2, EMMC_DATA_1, + EMMC_DATA_0, PCM_FS_I2S_LRCK, PCM_CLK_I2S_BCLK, + PCM_DRX_I2S_DIN, PCM_DTX_I2S_DOUT, PCM_MCK_I2S_MCLK, + UART0_RXD, UART0_TXD, PWMD0, JTAG_JTDI, JTAG_JTDO, JTAG_JTMS, + JTAG_JTCLK, JTAG_JTRST_N, USB_DRV_VBUS_P1, LED_A, LED_B, LED_C, + LED_D, LED_E, GPIO_B, GPIO_C, I2C_2_SCL, I2C_2_SDA, + PCIE30_2L_1_PRESET_N, PCIE30_1L_0_PRESET_N, + PCIE30_2L_1_WAKE_N, PCIE30_2L_1_CLKREQ_N, + PCIE30_1L_0_WAKE_N, PCIE30_1L_0_CLKREQ_N, USB_DRV_VBUS_P0, + UART1_RXD, UART1_TXD, UART1_CTS, UART1_RTS] + maxItems: 84 + + bias-disable: true + + bias-pull-up: + oneOf: + - type: boolean + description: normal pull up. + - enum: [100, 101, 102, 103] + description: + PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in + dt-bindings/pinctrl/mt65xx.h. + + bias-pull-down: + oneOf: + - type: boolean + description: normal pull down. + - enum: [100, 101, 102, 103] + description: + PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in + dt-bindings/pinctrl/mt65xx.h. + + input-enable: true + + input-disable: true + + output-enable: true + + output-low: true + + output-high: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + + mediatek,pull-up-adv: + description: | + Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3' + Pull up settings for 2 pull resistors, R0 and R1. Valid arguments + are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + mediatek,pull-down-adv: + description: | + Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3' + Pull down settings for 2 pull resistors, R0 and R1. Valid arguments + are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + required: + - pins + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/mt65xx.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pio: pinctrl@1001f000 { + compatible = "mediatek,mt7988-pinctrl"; + reg = <0 0x1001f000 0 0x1000>, + <0 0x11c10000 0 0x1000>, + <0 0x11d00000 0 0x1000>, + <0 0x11d20000 0 0x1000>, + <0 0x11e00000 0 0x1000>, + <0 0x11f00000 0 0x1000>, + <0 0x1000b000 0 0x1000>; + reg-names = "gpio", "iocfg_tr", + "iocfg_br", "iocfg_rb", + "iocfg_lb", "iocfg_tl", "eint"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pio 0 0 84>; + interrupt-controller; + interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>; + interrupt-parent = <&gic>; + #interrupt-cells = <2>; + + i2c0_pins: i2c0-g0-pins { + mux { + function = "i2c"; + groups = "i2c0_1"; + }; + }; + + mdio0_pins: mdio0-pins { + mux { + function = "eth"; + groups = "mdc_mdio0"; + }; + + conf { + pins = "SMI_0_MDC", "SMI_0_MDIO"; + drive-strength = <8>; + }; + }; + + mmc0_pins_emmc_51: mmc0-emmc-51-pins { + mux { + function = "flash"; + groups = "emmc_51"; + }; + }; + + mmc0_pins_sdcard: mmc0-sdcard-pins { + mux { + function = "flash"; + groups = "sdcard"; + }; + }; + + pcie0_pins: pcie0-pins { + mux { + function = "pcie"; + groups = "pcie_2l_0_pereset", "pcie_clk_req_n0_0", + "pcie_wake_n0_0"; + }; + }; + + pcie1_pins: pcie1-pins { + mux { + function = "pcie"; + groups = "pcie_2l_1_pereset", "pcie_clk_req_n1", + "pcie_wake_n1_0"; + }; + }; + + pcie2_pins: pcie2-pins { + mux { + function = "pcie"; + groups = "pcie_1l_0_pereset", "pcie_clk_req_n2_0", + "pcie_wake_n2_0"; + }; + }; + + pcie3_pins: pcie3-pins { + mux { + function = "pcie"; + groups = "pcie_1l_1_pereset", "pcie_clk_req_n3", + "pcie_wake_n3_0"; + }; + }; + + uart0_pins: uart0-pins { + mux { + function = "uart"; + groups = "uart0"; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq5424-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5424-tlmm.yaml index 5e64a232fc7a..df284d3645c1 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq5424-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5424-tlmm.yaml @@ -79,8 +79,8 @@ $defs: qdss_cti_trig_out_b0, qdss_cti_trig_in_b1, qdss_cti_trig_out_b1, qdss_traceclk_a, qdss_tracectl_a, qdss_tracedata_a, qspi_clk, qspi_cs, qspi_data, resout, rx0, rx1, rx2, sdc_clk, sdc_cmd, - sdc_data, spi0, spi1, spi10, spi11, tsens_max, uart0, uart1, - wci_txd, wci_rxd, wsi_clk, wsi_data ] + sdc_data, spi0_cs, spi0_clk, spi0_miso, spi0_mosi, spi1, spi10, + spi11, tsens_max, uart0, uart1, wci_txd, wci_rxd, wsi_clk, wsi_data ] required: - pins diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8917-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8917-pinctrl.yaml new file mode 100644 index 000000000000..16d0c010e581 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8917-pinctrl.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,msm8917-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm MSM8917 TLMM pin controller + +maintainers: + - Barnabas Czeman <barnabas.czeman@mainlining.org> + +description: + Top Level Mode Multiplexer pin controller in Qualcomm MSM8917 SoC. + +properties: + compatible: + const: qcom,msm8917-pinctrl + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + gpio-reserved-ranges: + minItems: 1 + maxItems: 66 + + gpio-line-names: + maxItems: 134 + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-msm8917-tlmm-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-msm8917-tlmm-state" + additionalProperties: false + +$defs: + qcom-msm8917-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-3])$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk, + sdc2_cmd, sdc2_data, qdsd_clk, qdsd_cmd, qdsd_data0, + qdsd_data1, qdsd_data2, qdsd_data3 ] + minItems: 1 + maxItems: 16 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ accel_int, adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1, + atest_char, atest_char0, atest_char1, atest_char2, + atest_char3, atest_combodac_to_gpio_native, + atest_gpsadc_dtest0_native, atest_gpsadc_dtest1_native, + atest_tsens, atest_wlan0, atest_wlan1, audio_ref, + audio_reset, bimc_dte0, bimc_dte1, blsp6_spi, blsp8_spi, + blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5, + blsp_i2c6, blsp_i2c7, blsp_i2c8, blsp_spi1, blsp_spi2, + blsp_spi3, blsp_spi4, blsp_spi5, blsp_spi6, blsp_spi7, + blsp_spi8, blsp_uart1, blsp_uart2, blsp_uart3, blsp_uart4, + blsp_uart5, blsp_uart6, blsp_uart7, blsp_uart8, cam0_ldo, + cam1_rst, cam1_standby, cam2_rst, cam2_standby, cam_mclk, + cci_async, cci_i2c, cci_timer0, cci_timer1, cdc_pdm0, + codec_int1, codec_int2, codec_mad, coex_uart, cri_trng, + cri_trng0, cri_trng1, dbg_out, dmic0_clk, dmic0_data, + ebi_cdc, ebi_ch0, ext_lpass, forced_usb, fp_gpio, fp_int, + gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b, + gcc_gp3_clk_a, gcc_gp3_clk_b, gcc_plltest, gcc_tlmm, gpio, + gsm0_tx, key_focus, key_snapshot, key_volp, ldo_en, + ldo_update, lpass_slimbus, lpass_slimbus0, lpass_slimbus1, + m_voc, mag_int, mdp_vsync, mipi_dsi0, modem_tsync, nav_pps, + nav_pps_in_a, nav_pps_in_b, nav_tsync, nfc_pwr, ov_ldo, + pa_indicator, pbs0, pbs1, pbs2, pri_mi2s, pri_mi2s_mclk_a, + pri_mi2s_mclk_b, pri_mi2s_ws, prng_rosc, + pwr_crypto_enabled_a, pwr_crypto_enabled_b, + pwr_modem_enabled_a, pwr_modem_enabled_b, pwr_nav_enabled_a, + pwr_nav_enabled_b, qdss_cti_trig_in_a0, qdss_cti_trig_in_a1, + qdss_cti_trig_in_b0, qdss_cti_trig_in_b1, + qdss_cti_trig_out_a0, qdss_cti_trig_out_a1, + qdss_cti_trig_out_b0, qdss_cti_trig_out_b1, qdss_traceclk_a, + qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b, + qdss_tracedata_a, qdss_tracedata_b, sd_write, sdcard_det, + sec_mi2s, sec_mi2s_mclk_a, sec_mi2s_mclk_b, sensor_rst, + smb_int, ssbi_wtr1, ts_resout, ts_sample, uim1_clk, + uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data, + uim2_present, uim2_reset, uim_batt, us_emitter, us_euro, + wcss_bt, wcss_fm, wcss_wlan, wcss_wlan0, wcss_wlan1, + wcss_wlan2, webcam_rst, webcam_standby, wsa_io, wsa_irq ] + + required: + - pins + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + tlmm: pinctrl@1000000 { + compatible = "qcom,msm8917-pinctrl"; + reg = <0x01000000 0x300000>; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + gpio-ranges = <&tlmm 0 0 134>; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + + blsp1-uart2-sleep-state { + pins = "gpio4", "gpio5"; + function = "gpio"; + + drive-strength = <2>; + bias-pull-down; + }; + + spi1-default-state { + spi-pins { + pins = "gpio0", "gpio1", "gpio3"; + function = "blsp_spi1"; + + drive-strength = <12>; + bias-disable; + }; + + cs-pins { + pins = "gpio2"; + function = "gpio"; + + drive-strength = <16>; + bias-disable; + output-high; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml index fc6c65fea73b..90bd49d87d2e 100644 --- a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml @@ -159,30 +159,30 @@ additionalProperties: false examples: - | - pinctrl@4e000 { - compatible = "realtek,rtd1315e-pinctrl"; - reg = <0x4e000 0x130>; - - emmc-hs200-pins { - pins = "emmc_clk", - "emmc_cmd", - "emmc_data_0", - "emmc_data_1", - "emmc_data_2", - "emmc_data_3", - "emmc_data_4", - "emmc_data_5", - "emmc_data_6", - "emmc_data_7"; - function = "emmc"; - realtek,drive-strength-p = <0x2>; - realtek,drive-strength-n = <0x2>; - }; - - i2c-0-pins { - pins = "gpio_12", - "gpio_13"; - function = "i2c0"; - drive-strength = <4>; - }; - }; + pinctrl@4e000 { + compatible = "realtek,rtd1315e-pinctrl"; + reg = <0x4e000 0x130>; + + emmc-hs200-pins { + pins = "emmc_clk", + "emmc_cmd", + "emmc_data_0", + "emmc_data_1", + "emmc_data_2", + "emmc_data_3", + "emmc_data_4", + "emmc_data_5", + "emmc_data_6", + "emmc_data_7"; + function = "emmc"; + realtek,drive-strength-p = <0x2>; + realtek,drive-strength-n = <0x2>; + }; + + i2c-0-pins { + pins = "gpio_12", + "gpio_13"; + function = "i2c0"; + drive-strength = <4>; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml index f07361d60acd..b6211c8544ca 100644 --- a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml @@ -158,30 +158,30 @@ additionalProperties: false examples: - | - pinctrl@4e000 { - compatible = "realtek,rtd1319d-pinctrl"; - reg = <0x4e000 0x130>; - - emmc-hs200-pins { - pins = "emmc_clk", - "emmc_cmd", - "emmc_data_0", - "emmc_data_1", - "emmc_data_2", - "emmc_data_3", - "emmc_data_4", - "emmc_data_5", - "emmc_data_6", - "emmc_data_7"; - function = "emmc"; - realtek,drive-strength-p = <0x2>; - realtek,drive-strength-n = <0x2>; - }; - - i2c-0-pins { - pins = "gpio_12", - "gpio_13"; - function = "i2c0"; - drive-strength = <4>; - }; - }; + pinctrl@4e000 { + compatible = "realtek,rtd1319d-pinctrl"; + reg = <0x4e000 0x130>; + + emmc-hs200-pins { + pins = "emmc_clk", + "emmc_cmd", + "emmc_data_0", + "emmc_data_1", + "emmc_data_2", + "emmc_data_3", + "emmc_data_4", + "emmc_data_5", + "emmc_data_6", + "emmc_data_7"; + function = "emmc"; + realtek,drive-strength-p = <0x2>; + realtek,drive-strength-n = <0x2>; + }; + + i2c-0-pins { + pins = "gpio_12", + "gpio_13"; + function = "i2c0"; + drive-strength = <4>; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml index 671e4ec84624..e88bc649cc73 100644 --- a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml @@ -157,30 +157,30 @@ additionalProperties: false examples: - | - pinctrl@4e000 { - compatible = "realtek,rtd1619b-pinctrl"; - reg = <0x4e000 0x130>; - - emmc-hs200-pins { - pins = "emmc_clk", - "emmc_cmd", - "emmc_data_0", - "emmc_data_1", - "emmc_data_2", - "emmc_data_3", - "emmc_data_4", - "emmc_data_5", - "emmc_data_6", - "emmc_data_7"; - function = "emmc"; - realtek,drive-strength-p = <0x2>; - realtek,drive-strength-n = <0x2>; - }; - - i2c-0-pins { - pins = "gpio_12", - "gpio_13"; - function = "i2c0"; - drive-strength = <4>; - }; - }; + pinctrl@4e000 { + compatible = "realtek,rtd1619b-pinctrl"; + reg = <0x4e000 0x130>; + + emmc-hs200-pins { + pins = "emmc_clk", + "emmc_cmd", + "emmc_data_0", + "emmc_data_1", + "emmc_data_2", + "emmc_data_3", + "emmc_data_4", + "emmc_data_5", + "emmc_data_6", + "emmc_data_7"; + function = "emmc"; + realtek,drive-strength-p = <0x2>; + realtek,drive-strength-n = <0x2>; + }; + + i2c-0-pins { + pins = "gpio_12", + "gpio_13"; + function = "i2c0"; + drive-strength = <4>; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml index a1805b6e3f63..768bb3c2b456 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -26,6 +26,7 @@ properties: - renesas,r9a07g043-pinctrl # RZ/G2UL{Type-1,Type-2} and RZ/Five - renesas,r9a07g044-pinctrl # RZ/G2{L,LC} - renesas,r9a08g045-pinctrl # RZ/G3S + - renesas,r9a09g047-pinctrl # RZ/G3E - renesas,r9a09g057-pinctrl # RZ/V2H(P) - items: @@ -125,7 +126,7 @@ additionalProperties: drive-push-pull: true renesas,output-impedance: description: - Output impedance for pins on the RZ/V2H(P) SoC. The value provided by this + Output impedance for pins on the RZ/{G3E,V2H(P)} SoC. The value provided by this property corresponds to register bit values that can be set in the PFC_IOLH_mn register, which adjusts the drive strength value and is pin-dependent. $ref: /schemas/types.yaml#/definitions/uint32 @@ -142,7 +143,9 @@ allOf: properties: compatible: contains: - const: renesas,r9a09g057-pinctrl + enum: + - renesas,r9a09g047-pinctrl + - renesas,r9a09g057-pinctrl then: properties: resets: diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml index 6a23d845f1f2..80a2b1934849 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml @@ -44,6 +44,7 @@ properties: - rockchip,rk3328-pinctrl - rockchip,rk3368-pinctrl - rockchip,rk3399-pinctrl + - rockchip,rk3562-pinctrl - rockchip,rk3568-pinctrl - rockchip,rk3576-pinctrl - rockchip,rk3588-pinctrl diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml index de6c10ba36c4..70548cb37ada 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml @@ -180,38 +180,31 @@ additionalProperties: false examples: - | #include <dt-bindings/pinctrl/pinctrl-zynq.h> - pinctrl0: pinctrl@700 { - compatible = "xlnx,pinctrl-zynq"; - reg = <0x700 0x200>; - syscon = <&slcr>; - - pinctrl_uart1_default: uart1-default { - mux { - groups = "uart1_10_grp"; - function = "uart1"; - }; - - conf { - groups = "uart1_10_grp"; - slew-rate = <0>; - power-source = <IO_STANDARD_LVCMOS18>; - }; - - conf-rx { - pins = "MIO49"; - bias-high-impedance; - }; - - conf-tx { - pins = "MIO48"; - bias-disable; - }; - }; + pinctrl@700 { + compatible = "xlnx,pinctrl-zynq"; + reg = <0x700 0x200>; + syscon = <&slcr>; + + uart1-default { + mux { + groups = "uart1_10_grp"; + function = "uart1"; + }; + + conf { + groups = "uart1_10_grp"; + slew-rate = <0>; + power-source = <IO_STANDARD_LVCMOS18>; + }; + + conf-rx { + pins = "MIO49"; + bias-high-impedance; + }; + + conf-tx { + pins = "MIO48"; + bias-disable; + }; + }; }; - - uart1 { - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_uart1_default>; - }; - -... diff --git a/Documentation/devicetree/bindings/platform/huawei,gaokun-ec.yaml b/Documentation/devicetree/bindings/platform/huawei,gaokun-ec.yaml new file mode 100644 index 000000000000..4a03b0ee3149 --- /dev/null +++ b/Documentation/devicetree/bindings/platform/huawei,gaokun-ec.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/platform/huawei,gaokun-ec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Huawei Matebook E Go Embedded Controller + +maintainers: + - Pengyu Luo <mitltlatltl@gmail.com> + +description: + Different from other Qualcomm Snapdragon sc8180x and sc8280xp-based + machines, the Huawei Matebook E Go tablets use embedded controllers + while others use a system called PMIC GLink which handles battery, + UCSI, USB Type-C DP Alt Mode. In addition, Huawei's implementation + also handles additional features, such as charging thresholds, FN + lock, smart charging, tablet lid status, thermal sensors, and more. + +properties: + compatible: + enum: + - huawei,gaokun3-ec + + reg: + const: 0x38 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + interrupts: + maxItems: 1 + +patternProperties: + '^connector@[01]$': + $ref: /schemas/connector/usb-connector.yaml# + + properties: + reg: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + embedded-controller@38 { + compatible = "huawei,gaokun3-ec"; + reg = <0x38>; + + interrupts-extended = <&tlmm 107 IRQ_TYPE_LEVEL_LOW>; + + #address-cells = <1>; + #size-cells = <0>; + + connector@0 { + compatible = "usb-c-connector"; + reg = <0>; + power-role = "dual"; + data-role = "dual"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + ucsi0_ss_in: endpoint { + remote-endpoint = <&usb_0_qmpphy_out>; + }; + }; + + port@1 { + reg = <1>; + + ucsi0_sbu: endpoint { + remote-endpoint = <&usb0_sbu_mux>; + }; + }; + }; + }; + + connector@1 { + compatible = "usb-c-connector"; + reg = <1>; + power-role = "dual"; + data-role = "dual"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + ucsi1_ss_in: endpoint { + remote-endpoint = <&usb_1_qmpphy_out>; + }; + }; + + port@1 { + reg = <1>; + + ucsi1_sbu: endpoint { + remote-endpoint = <&usb1_sbu_mux>; + }; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml b/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml index 46e2647a5d72..f578be6a3bc8 100644 --- a/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml +++ b/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - allwinner,sun20i-d1-ppu + - allwinner,sun8i-v853-ppu reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.yaml b/Documentation/devicetree/bindings/power/domain-idle-state.yaml index ec1f6f669e50..4dd4f59bbbec 100644 --- a/Documentation/devicetree/bindings/power/domain-idle-state.yaml +++ b/Documentation/devicetree/bindings/power/domain-idle-state.yaml @@ -54,6 +54,11 @@ patternProperties: (i.e. idle states node with entry-method property is set to "psci") must specify this property. + idle-state-name: + $ref: /schemas/types.yaml#/definitions/string + description: + A string used as a descriptive name for the idle state. + required: - compatible - entry-latency-us diff --git a/Documentation/devicetree/bindings/power/raspberrypi,bcm2835-power.yaml b/Documentation/devicetree/bindings/power/raspberrypi,bcm2835-power.yaml new file mode 100644 index 000000000000..57579f70264c --- /dev/null +++ b/Documentation/devicetree/bindings/power/raspberrypi,bcm2835-power.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/raspberrypi,bcm2835-power.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM2835 power domain + +maintainers: + - Alexander Aring <alex.aring@gmail.com> + - Florian Fainelli <florian.fainelli@broadcom.com> + +description: + The Raspberry Pi power domain manages power for various subsystems + in the Raspberry Pi BCM2835 SoC. + +properties: + compatible: + enum: + - raspberrypi,bcm2835-power + + firmware: + $ref: /schemas/types.yaml#/definitions/phandle + description: Reference to the RPi firmware device node + + "#power-domain-cells": + const: 1 + +required: + - compatible + - firmware + - "#power-domain-cells" + +unevaluatedProperties: false + +examples: + - | + power-controller { + compatible = "raspberrypi,bcm2835-power"; + firmware = <&firmware>; + #power-domain-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml b/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml index 8c58e12cdb60..0735ceb7c103 100644 --- a/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml +++ b/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml @@ -22,6 +22,9 @@ properties: - enum: - atmel,sama5d2-shdwc - microchip,sam9x60-shdwc + - items: + - const: microchip,sam9x7-shdwc + - const: microchip,sam9x60-shdwc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml index 650dc0aae6f5..ebab98987e49 100644 --- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml @@ -132,6 +132,9 @@ $defs: A number of phandles to clocks that need to be enabled while power domain switches state. + domain-supply: + description: domain regulator supply. + pm_qos: $ref: /schemas/types.yaml#/definitions/phandle-array items: diff --git a/Documentation/devicetree/bindings/power/supply/bq24190.yaml b/Documentation/devicetree/bindings/power/supply/bq24190.yaml index 131b7e57d22f..07adf88997b4 100644 --- a/Documentation/devicetree/bindings/power/supply/bq24190.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq24190.yaml @@ -21,6 +21,7 @@ properties: - ti,bq24192i - ti,bq24196 - ti,bq24296 + - ti,bq24297 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml b/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml index 89f8e2bcb2d7..25826bfc289c 100644 --- a/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml @@ -58,6 +58,10 @@ properties: charge-current-limit-gpios property. Bit 1 second to last GPIO and so on. + charge-current-limit-default-microamp: + description: Default charge current limit. Must be listed in + charge-current-limit-mapping. + required: - compatible @@ -72,6 +76,7 @@ anyOf: dependencies: charge-current-limit-gpios: [ charge-current-limit-mapping ] charge-current-limit-mapping: [ charge-current-limit-gpios ] + charge-current-limit-default-microamp: [charge-current-limit-mapping] additionalProperties: false @@ -91,4 +96,5 @@ examples: charge-current-limit-mapping = <2500000 0x00>, // 2.5 A => both GPIOs low <700000 0x01>, // 700 mA => GPIO A.12 high <0 0x02>; // 0 mA => GPIO A.11 high + charge-current-limit-default-microamp = <700000>; }; diff --git a/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml b/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml index 29d536541152..06595a953659 100644 --- a/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml +++ b/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml @@ -17,12 +17,18 @@ description: | panels, etc., and a rechargeable Lithium-Ion/Polymer battery. Specifications about the charger can be found at: + https://www.analog.com/en/products/ltc4162-l.html + https://www.analog.com/en/products/ltc4162-f.html https://www.analog.com/en/products/ltc4162-s.html + https://www.analog.com/en/products/ltc4015.html properties: compatible: enum: + - lltc,ltc4015 + - lltc,ltc4162-f - lltc,ltc4162-l + - lltc,ltc4162-s reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml index 085e2504d0dc..14242de7fc08 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml @@ -19,6 +19,7 @@ properties: - maxim,max17047 - maxim,max17050 - maxim,max17055 + - maxim,max77705-battery - maxim,max77849-battery reg: diff --git a/Documentation/devicetree/bindings/power/supply/st,stc3117.yaml b/Documentation/devicetree/bindings/power/supply/st,stc3117.yaml new file mode 100644 index 000000000000..e486131a27a9 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/st,stc3117.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/st,stc3117.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STC3117 Fuel Gauge Unit Power Supply + +maintainers: + - Hardevsinh Palaniya <hardevsinh.palaniya@siliconsignals.io> + - Bhavin Sharma <bhavin.sharma@siliconsignals.io> + +description: | + The STC3117 includes the STMicroelectronics OptimGauge algorithm. + It provides accurate battery state-of-charge (SOC) monitoring, tracks + battery parameter changes with operation conditions, temperature, + and aging, and allows the application to get a battery state-of-health + (SOH) indication. + + An alarm output signals low SOC or low voltage conditions and also + indicates fault conditions like a missing or swapped battery. + + Datasheet is available at + https://www.st.com/resource/en/datasheet/stc3117.pdf + +allOf: + - $ref: power-supply.yaml# + +properties: + compatible: + enum: + - st,stc3117 + + reg: + maxItems: 1 + + monitored-battery: + description: | + The fuel gauge uses the following battery properties: + - charge-full-design-microamp-hours + - voltage-min-design-microvolt + - voltage-max-design-microvolt + + shunt-resistor-micro-ohms: + description: Current sense resistor + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - monitored-battery + - shunt-resistor-micro-ohms + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + battery@70 { + compatible = "st,stc3117"; + reg = <0x70>; + interrupt-parent = <&gpio0>; + interrupts = <31 IRQ_TYPE_LEVEL_LOW>; + monitored-battery = <&bat>; + shunt-resistor-micro-ohms = <10000>; + }; + }; diff --git a/Documentation/devicetree/bindings/pwm/adi,axi-pwmgen.yaml b/Documentation/devicetree/bindings/pwm/adi,axi-pwmgen.yaml index aa35209f74cf..45e112d0efb4 100644 --- a/Documentation/devicetree/bindings/pwm/adi,axi-pwmgen.yaml +++ b/Documentation/devicetree/bindings/pwm/adi,axi-pwmgen.yaml @@ -41,8 +41,8 @@ unevaluatedProperties: false examples: - | pwm@44b00000 { - compatible = "adi,axi-pwmgen-2.00.a"; - reg = <0x44b00000 0x1000>; - clocks = <&spi_clk>; - #pwm-cells = <3>; + compatible = "adi,axi-pwmgen-2.00.a"; + reg = <0x44b00000 0x1000>; + clocks = <&spi_clk>; + #pwm-cells = <3>; }; diff --git a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml index 119de3d7f9dd..44548a9da158 100644 --- a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml @@ -35,8 +35,8 @@ additionalProperties: false examples: - | pwm: pwm@f0408000 { - compatible = "brcm,bcm7038-pwm"; - reg = <0xf0408000 0x28>; - #pwm-cells = <2>; - clocks = <&upg_fixed>; + compatible = "brcm,bcm7038-pwm"; + reg = <0xf0408000 0x28>; + #pwm-cells = <2>; + clocks = <&upg_fixed>; }; diff --git a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml index e86c8053b366..fd785da5d3d7 100644 --- a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml @@ -43,9 +43,9 @@ examples: #include <dt-bindings/clock/bcm281xx.h> pwm@3e01a000 { - compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm"; - reg = <0x3e01a000 0xcc>; - clocks = <&slave_ccu BCM281XX_SLAVE_CCU_PWM>; - #pwm-cells = <3>; + compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm"; + reg = <0x3e01a000 0xcc>; + clocks = <&slave_ccu BCM281XX_SLAVE_CCU_PWM>; + #pwm-cells = <3>; }; ... diff --git a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml index ac0a35bf8648..d5a9340ff920 100644 --- a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml @@ -23,8 +23,15 @@ properties: const: 3 compatible: - enum: - - fsl,imx7ulp-pwm + oneOf: + - enum: + - fsl,imx7ulp-pwm + - items: + - enum: + - fsl,imx93-pwm + - fsl,imx94-pwm + - fsl,imx95-pwm + - const: fsl,imx7ulp-pwm reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/pwm/marvell,berlin-pwm.yaml b/Documentation/devicetree/bindings/pwm/marvell,berlin-pwm.yaml new file mode 100644 index 000000000000..091fec03df13 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/marvell,berlin-pwm.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/marvell,berlin-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Berlin PWM controller + +maintainers: + - Jisheng Zhang <jszhang@kernel.org> + - Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> + +properties: + compatible: + const: marvell,berlin-pwm + + reg: + maxItems: 1 + + "#pwm-cells": + const: 3 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + +allOf: + - $ref: pwm.yaml# + +unevaluatedProperties: false + +examples: + - | + pwm@f7f20000 { + compatible = "marvell,berlin-pwm"; + reg = <0xf7f20000 0x40>; + clocks = <&chip_clk 12>; + #pwm-cells = <3>; + }; + diff --git a/Documentation/devicetree/bindings/pwm/pwm-berlin.txt b/Documentation/devicetree/bindings/pwm/pwm-berlin.txt deleted file mode 100644 index f01e993a498a..000000000000 --- a/Documentation/devicetree/bindings/pwm/pwm-berlin.txt +++ /dev/null @@ -1,17 +0,0 @@ -Berlin PWM controller - -Required properties: -- compatible: should be "marvell,berlin-pwm" -- reg: physical base address and length of the controller's registers -- clocks: phandle to the input clock -- #pwm-cells: should be 3. See pwm.yaml in this directory for a description of - the cells format. - -Example: - -pwm: pwm@f7f20000 { - compatible = "marvell,berlin-pwm"; - reg = <0xf7f20000 0x40>; - clocks = <&chip_clk CLKID_CFG>; - #pwm-cells = <3>; -} diff --git a/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml new file mode 100644 index 000000000000..3b40e271fe8d --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/pwm-nexus-node.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PWM Nexus node properties + +description: > + Platforms can have a standardized connector/expansion slot that exposes PWMs + signals to expansion boards. + + A nexus node allows to remap a phandle list in a consumer node through a + connector node in a generic way. With this remapping, the consumer node needs + to know only about the nexus node. Resources behind the nexus node are + decoupled by the nexus node itself. + +maintainers: + - Herve Codina <herve.codina@bootlin.com> + +select: true + +properties: + '#pwm-cells': true + + pwm-map: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + + pwm-map-mask: + $ref: /schemas/types.yaml#/definitions/uint32-array + + pwm-map-pass-thru: + $ref: /schemas/types.yaml#/definitions/uint32-array + +dependentRequired: + pwm-map: ['#pwm-cells'] + pwm-map-mask: [ pwm-map ] + pwm-map-pass-thru: [ pwm-map ] + +additionalProperties: true + +examples: + - | + pwm1: pwm@100 { + reg = <0x100 0x10>; + #pwm-cells = <3>; + }; + + pwm2: pwm@200 { + reg = <0x200 0x10>; + #pwm-cells = <3>; + }; + + connector: connector { + #pwm-cells = <3>; + pwm-map = <0 0 0 &pwm1 1 0 0>, + <1 0 0 &pwm2 4 0 0>, + <2 0 0 &pwm1 3 0 0>; + pwm-map-mask = <0xffffffff 0x0 0x0>; + pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>; + }; + + device { + pwms = <&connector 1 57000 0>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml index 65bfb492b3a4..c8cdfb723336 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml @@ -30,6 +30,8 @@ properties: - enum: - rockchip,px30-pwm - rockchip,rk3308-pwm + - rockchip,rk3528-pwm + - rockchip,rk3562-pwm - rockchip,rk3568-pwm - rockchip,rk3588-pwm - rockchip,rv1126-pwm diff --git a/Documentation/devicetree/bindings/pwm/pwm-sprd.txt b/Documentation/devicetree/bindings/pwm/pwm-sprd.txt deleted file mode 100644 index 87b206fd0618..000000000000 --- a/Documentation/devicetree/bindings/pwm/pwm-sprd.txt +++ /dev/null @@ -1,40 +0,0 @@ -Spreadtrum PWM controller - -Spreadtrum SoCs PWM controller provides 4 PWM channels. - -Required properties: -- compatible : Should be "sprd,ums512-pwm". -- reg: Physical base address and length of the controller's registers. -- clocks: The phandle and specifier referencing the controller's clocks. -- clock-names: Should contain following entries: - "pwmn": used to derive the functional clock for PWM channel n (n range: 0 ~ 3). - "enablen": for PWM channel n enable clock (n range: 0 ~ 3). -- #pwm-cells: Should be 2. See pwm.yaml in this directory for a description of - the cells format. - -Optional properties: -- assigned-clocks: Reference to the PWM clock entries. -- assigned-clock-parents: The phandle of the parent clock of PWM clock. - -Example: - pwms: pwm@32260000 { - compatible = "sprd,ums512-pwm"; - reg = <0 0x32260000 0 0x10000>; - clock-names = "pwm0", "enable0", - "pwm1", "enable1", - "pwm2", "enable2", - "pwm3", "enable3"; - clocks = <&aon_clk CLK_PWM0>, <&aonapb_gate CLK_PWM0_EB>, - <&aon_clk CLK_PWM1>, <&aonapb_gate CLK_PWM1_EB>, - <&aon_clk CLK_PWM2>, <&aonapb_gate CLK_PWM2_EB>, - <&aon_clk CLK_PWM3>, <&aonapb_gate CLK_PWM3_EB>; - assigned-clocks = <&aon_clk CLK_PWM0>, - <&aon_clk CLK_PWM1>, - <&aon_clk CLK_PWM2>, - <&aon_clk CLK_PWM3>; - assigned-clock-parents = <&ext_26m>, - <&ext_26m>, - <&ext_26m>, - <&ext_26m>; - #pwm-cells = <2>; - }; diff --git a/Documentation/devicetree/bindings/pwm/sophgo,sg2042-pwm.yaml b/Documentation/devicetree/bindings/pwm/sophgo,sg2042-pwm.yaml new file mode 100644 index 000000000000..bbb6326d47d7 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/sophgo,sg2042-pwm.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/sophgo,sg2042-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sophgo SG2042 PWM controller + +maintainers: + - Chen Wang <unicorn_wang@outlook.com> + +description: + This controller contains 4 channels which can generate PWM waveforms. + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + const: sophgo,sg2042-pwm + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: apb + + resets: + maxItems: 1 + + "#pwm-cells": + const: 3 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/reset/sophgo,sg2042-reset.h> + + pwm@7f006000 { + compatible = "sophgo,sg2042-pwm"; + reg = <0x7f006000 0x1000>; + #pwm-cells = <3>; + clocks = <&clock 67>; + clock-names = "apb"; + resets = <&rstgen RST_PWM>; + }; diff --git a/Documentation/devicetree/bindings/pwm/sprd,ums512-pwm.yaml b/Documentation/devicetree/bindings/pwm/sprd,ums512-pwm.yaml new file mode 100644 index 000000000000..c806b6768087 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/sprd,ums512-pwm.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/sprd,ums512-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Spreadtrum/Unisoc UMS512 PWM Controller + +maintainers: + - Orson Zhai <orsonzhai@gmail.com> + - Baolin Wang <baolin.wang@linux.alibaba.com> + - Chunyan Zhang <zhang.lyra@gmail.com> + +properties: + compatible: + const: sprd,ums512-pwm + + reg: + maxItems: 1 + + clocks: + maxItems: 8 + + clock-names: + items: + - const: pwm0 + - const: enable0 + - const: pwm1 + - const: enable1 + - const: pwm2 + - const: enable2 + - const: pwm3 + - const: enable3 + + '#pwm-cells': + const: 2 + +required: + - compatible + - reg + - clocks + - clock-names + +allOf: + - $ref: pwm.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/sprd,ums512-clk.h> + + pwm@32260000 { + compatible = "sprd,ums512-pwm"; + reg = <0x32260000 0x10000>; + clocks = <&aon_clk CLK_PWM0>, <&aonapb_gate CLK_PWM0_EB>, + <&aon_clk CLK_PWM1>, <&aonapb_gate CLK_PWM1_EB>, + <&aon_clk CLK_PWM2>, <&aonapb_gate CLK_PWM2_EB>, + <&aon_clk CLK_PWM3>, <&aonapb_gate CLK_PWM3_EB>; + clock-names = "pwm0", "enable0", + "pwm1", "enable1", + "pwm2", "enable2", + "pwm3", "enable3"; + #pwm-cells = <2>; + }; +... diff --git a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml index cd4aa27218a1..fa6743bb269d 100644 --- a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml @@ -35,10 +35,6 @@ properties: $ref: regulator.yaml# unevaluatedProperties: false - properties: - regulator-compatible: - pattern: "^vbuck[1-4]$" - additionalProperties: false required: @@ -56,7 +52,6 @@ examples: regulators { vbuck1 { - regulator-compatible = "vbuck1"; regulator-min-microvolt = <300000>; regulator-max-microvolt = <1193750>; regulator-enable-ramp-delay = <256>; @@ -64,7 +59,6 @@ examples: }; vbuck3 { - regulator-compatible = "vbuck3"; regulator-min-microvolt = <300000>; regulator-max-microvolt = <1193750>; regulator-enable-ramp-delay = <256>; diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml index f8057bba747a..4ffe5c3faea0 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml @@ -17,6 +17,9 @@ description: | Datasheet is available at https://www.nxp.com/docs/en/data-sheet/PCA9450DS.pdf + Support PF9453, Datasheet is available at + https://www.nxp.com/docs/en/data-sheet/PF9453_SDS.pdf + # The valid names for PCA9450 regulator nodes are: # BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, # LDO1, LDO2, LDO3, LDO4, LDO5 @@ -29,6 +32,8 @@ properties: - nxp,pca9450b - nxp,pca9450c - nxp,pca9451a + - nxp,pca9452 + - nxp,pf9453 reg: maxItems: 1 @@ -41,8 +46,30 @@ properties: description: | list of regulators provided by this controller + properties: + LDO5: + type: object + $ref: regulator.yaml# + description: + Properties for single LDO5 regulator. + + properties: + nxp,sd-vsel-fixed-low: + type: boolean + description: + Let the driver know that SD_VSEL is hardwired to low level and + there is no GPIO to get the actual value from. + + sd-vsel-gpios: + description: + GPIO that can be used to read the current status of the SD_VSEL + signal in order for the driver to know if LDO5CTRL_L or LDO5CTRL_H + is used by the hardware. + + unevaluatedProperties: false + patternProperties: - "^LDO[1-5]$": + "^LDO([1-4]|-SNVS)$": type: object $ref: regulator.yaml# description: @@ -77,11 +104,6 @@ properties: additionalProperties: false - sd-vsel-gpios: - description: GPIO that is used to switch LDO5 between being configured by - LDO5CTRL_L or LDO5CTRL_H register. Use this if the SD_VSEL signal is - connected to a host GPIO. - nxp,i2c-lt-enable: type: boolean description: @@ -100,6 +122,24 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + const: nxp,pf9453 + then: + properties: + regulators: + patternProperties: + "^LDO[3-4]$": false + "^BUCK[5-6]$": false + else: + properties: + regulators: + properties: + LDO-SNVS: false + examples: - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index f2fd2df68a9e..b7241ce975b9 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -22,7 +22,7 @@ description: Each sub-node is identified using the node's name, with valid values listed for each of the pmics below. - For mp5496, s1, s2 + For mp5496, s1, s2, l2, l5 For pm2250, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22 diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index 1ef380d1515e..77573bcb6b79 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -34,6 +34,9 @@ properties: regulator-input-current-limit-microamp: description: maximum input current regulator allows + regulator-power-budget-milliwatt: + description: power budget of the regulator + regulator-always-on: description: boolean, regulator should never be disabled type: boolean diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml index 87accc6f13b8..022c1f197364 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml @@ -39,7 +39,7 @@ properties: interrupts: maxItems: 1 - + richtek,mtp-sel-high: type: boolean description: @@ -77,6 +77,7 @@ properties: properties: richtek,fixed-microvolt: + deprecated: true description: | This property can be used to set a fixed operating voltage that lies outside the range of the regulator's adjustable mode. diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml index 7fe401a06805..a66007951d58 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml @@ -15,12 +15,25 @@ description: properties: compatible: - enum: - - qcom,sa8775p-adsp-pas - - qcom,sa8775p-cdsp0-pas - - qcom,sa8775p-cdsp1-pas - - qcom,sa8775p-gpdsp0-pas - - qcom,sa8775p-gpdsp1-pas + oneOf: + - items: + - enum: + - qcom,qcs8300-adsp-pas + - const: qcom,sa8775p-adsp-pas + - items: + - enum: + - qcom,qcs8300-cdsp-pas + - const: qcom,sa8775p-cdsp0-pas + - items: + - enum: + - qcom,qcs8300-gpdsp-pas + - const: qcom,sa8775p-gpdsp0-pas + - enum: + - qcom,sa8775p-adsp-pas + - qcom,sa8775p-cdsp0-pas + - qcom,sa8775p-cdsp1-pas + - qcom,sa8775p-gpdsp0-pas + - qcom,sa8775p-gpdsp1-pas reg: maxItems: 1 @@ -63,8 +76,9 @@ allOf: - if: properties: compatible: - enum: - - qcom,sa8775p-adsp-pas + contains: + enum: + - qcom,sa8775p-adsp-pas then: properties: power-domains: @@ -79,9 +93,10 @@ allOf: - if: properties: compatible: - enum: - - qcom,sa8775p-cdsp0-pas - - qcom,sa8775p-cdsp1-pas + contains: + enum: + - qcom,sa8775p-cdsp0-pas + - qcom,sa8775p-cdsp1-pas then: properties: power-domains: @@ -98,9 +113,10 @@ allOf: - if: properties: compatible: - enum: - - qcom,sa8775p-gpdsp0-pas - - qcom,sa8775p-gpdsp1-pas + contains: + enum: + - qcom,sa8775p-gpdsp0-pas + - qcom,sa8775p-gpdsp1-pas then: properties: power-domains: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml index 758adb06c8dd..059cb87b4d6c 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml @@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm SM6115 Peripheral Authentication Service maintainers: - - Bhupesh Sharma <bhupesh.sharma@linaro.org> + - Bjorn Andersson <andersson@kernel.org> + - Konrad Dybcio <konradybcio@kernel.org> description: Qualcomm SM6115 SoC Peripheral Authentication Service loads and boots diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt index 01db34375192..384035e8e60b 100644 --- a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt @@ -3,4 +3,4 @@ STMicroelectronics STM32 Peripheral Reset Controller The RCC IP is both a reset and a clock controller. -Please see Documentation/devicetree/bindings/clock/st,stm32-rcc.txt +Please see Documentation/devicetree/bindings/clock/st,stm32-rcc.yaml diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index 8edc8261241a..2c72f148a74b 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -26,6 +26,18 @@ description: | allOf: - $ref: /schemas/cpu.yaml# - $ref: extensions.yaml + - if: + not: + properties: + compatible: + contains: + enum: + - thead,c906 + - thead,c910 + - thead,c920 + then: + properties: + thead,vlenb: false properties: compatible: @@ -46,6 +58,7 @@ properties: - sifive,u7 - sifive,u74 - sifive,u74-mc + - spacemit,x60 - thead,c906 - thead,c908 - thead,c910 @@ -95,6 +108,13 @@ properties: description: The blocksize in bytes for the Zicboz cache operations. + thead,vlenb: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + VLEN/8, the vector register length in bytes. This property is required on + thead systems where the vector register length is not identical on all harts, or + the vlenb CSR is not available. + # RISC-V has multiple properties for cache op block sizes as the sizes # differ between individual CBO extensions cache-op-block-size: false diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml index 9c7dd7e75e0c..a63b994e0763 100644 --- a/Documentation/devicetree/bindings/riscv/extensions.yaml +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml @@ -621,6 +621,10 @@ properties: latency, as ratified in commit 56ed795 ("Update riscv-crypto-spec-vector.adoc") of riscv-crypto. + # vendor extensions, each extension sorted alphanumerically under the + # vendor they belong to. Vendors are sorted alphanumerically as well. + + # Andes - const: xandespmu description: The Andes Technology performance monitor extension for counter overflow @@ -628,6 +632,12 @@ properties: Registers in the AX45MP datasheet. https://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf + # T-HEAD + - const: xtheadvector + description: + The T-HEAD specific 0.7.1 vector implementation as written in + https://github.com/T-head-Semi/thead-extension-spec/blob/95358cb2cca9489361c61d335e03d3134b14133f/xtheadvector.adoc. + allOf: # Zcb depends on Zca - if: diff --git a/Documentation/devicetree/bindings/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml new file mode 100644 index 000000000000..52e55077af1a --- /dev/null +++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/riscv/spacemit.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SpacemiT SoC-based boards + +maintainers: + - Yangyu Chen <cyy@cyyself.name> + - Yixun Lan <dlan@gentoo.org> + +description: + SpacemiT SoC-based boards + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - items: + - enum: + - bananapi,bpi-f3 + - const: spacemit,k1 + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml b/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml index a14b52178c4b..2599b847f406 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml +++ b/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml @@ -14,9 +14,13 @@ maintainers: properties: compatible: - enum: - - fsl,imx1-rtc - - fsl,imx21-rtc + oneOf: + - const: fsl,imx1-rtc + - const: fsl,imx21-rtc + - items: + - enum: + - fsl,imx31-rtc + - const: fsl,imx21-rtc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml index 692aa05500fd..0bde2379e864 100644 --- a/Documentation/devicetree/bindings/serial/8250.yaml +++ b/Documentation/devicetree/bindings/serial/8250.yaml @@ -111,7 +111,9 @@ properties: - mediatek,mt7623-btif - const: mediatek,mtk-btif - items: - - const: mrvl,mmp-uart + - enum: + - mrvl,mmp-uart + - spacemit,k1-uart - const: intel,xscale-uart - items: - enum: diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml index 88871480018e..ab39b95dae40 100644 --- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml +++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml @@ -23,6 +23,8 @@ properties: maxItems: 1 interrupts: + description: + When missing, device driver uses polling instead. maxItems: 1 clocks: @@ -76,7 +78,6 @@ properties: required: - compatible - reg - - interrupts allOf: - $ref: /schemas/spi/spi-peripheral-props.yaml# diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml index 51d9fb0f4763..8e82999e6acb 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml @@ -83,6 +83,11 @@ properties: - const: renesas,scif-r9a09g057 # RZ/V2H(P) + - items: + - enum: + - renesas,scif-r9a09g047 # RZ/G3E + - const: renesas,scif-r9a09g057 # RZ/V2H fallback + reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/soc/altera/altr,sys-mgr.yaml b/Documentation/devicetree/bindings/soc/altera/altr,sys-mgr.yaml new file mode 100644 index 000000000000..d56ff4c05ae5 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/altera/altr,sys-mgr.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/altera/altr,sys-mgr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Altera SOCFPGA System Manager + +maintainers: + - Dinh Nguyen <dinguyen@kernel.org> + +properties: + compatible: + oneOf: + - description: Cyclone5/Arria5/Arria10 + const: altr,sys-mgr + - description: Stratix10 SoC + items: + - const: altr,sys-mgr-s10 + - const: altr,sys-mgr + + reg: + maxItems: 1 + + cpu1-start-addr: + $ref: /schemas/types.yaml#/definitions/uint32 + description: CPU1 start address in hex + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: altr,sys-mgr-s10 + then: + properties: + cpu1-start-addr: false + +additionalProperties: false + +examples: + - | + sysmgr@ffd08000 { + compatible = "altr,sys-mgr"; + reg = <0xffd08000 0x1000>; + cpu1-start-addr = <0xffd080c4>; + }; diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml index c6bce40946d4..3dc66f1de023 100644 --- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml @@ -13,6 +13,7 @@ properties: compatible: items: - enum: + - amlogic,meson-hhi-sysctrl - amlogic,meson-gx-hhi-sysctrl - amlogic,meson-gx-ao-sysctrl - amlogic,meson-axg-hhi-sysctrl @@ -40,6 +41,19 @@ allOf: properties: compatible: enum: + - amlogic,meson-hhi-sysctrl + then: + properties: + clock-controller: + $ref: /schemas/clock/amlogic,meson8-clkc.yaml# + + pinctrl: false + phy: false + + - if: + properties: + compatible: + enum: - amlogic,meson-gx-hhi-sysctrl - amlogic,meson-axg-hhi-sysctrl then: diff --git a/Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt b/Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt deleted file mode 100644 index 30942cf7992b..000000000000 --- a/Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt +++ /dev/null @@ -1,47 +0,0 @@ -Raspberry Pi power domain driver - -Required properties: - -- compatible: Should be "raspberrypi,bcm2835-power". -- firmware: Reference to the RPi firmware device node. -- #power-domain-cells: Should be <1>, we providing multiple power domains. - -The valid defines for power domain are: - - RPI_POWER_DOMAIN_I2C0 - RPI_POWER_DOMAIN_I2C1 - RPI_POWER_DOMAIN_I2C2 - RPI_POWER_DOMAIN_VIDEO_SCALER - RPI_POWER_DOMAIN_VPU1 - RPI_POWER_DOMAIN_HDMI - RPI_POWER_DOMAIN_USB - RPI_POWER_DOMAIN_VEC - RPI_POWER_DOMAIN_JPEG - RPI_POWER_DOMAIN_H264 - RPI_POWER_DOMAIN_V3D - RPI_POWER_DOMAIN_ISP - RPI_POWER_DOMAIN_UNICAM0 - RPI_POWER_DOMAIN_UNICAM1 - RPI_POWER_DOMAIN_CCP2RX - RPI_POWER_DOMAIN_CSI2 - RPI_POWER_DOMAIN_CPI - RPI_POWER_DOMAIN_DSI0 - RPI_POWER_DOMAIN_DSI1 - RPI_POWER_DOMAIN_TRANSPOSER - RPI_POWER_DOMAIN_CCP2TX - RPI_POWER_DOMAIN_CDP - RPI_POWER_DOMAIN_ARM - -Example: - -power: power { - compatible = "raspberrypi,bcm2835-power"; - firmware = <&firmware>; - #power-domain-cells = <1>; -}; - -Example for using power domain: - -&usb { - power-domains = <&power RPI_POWER_DOMAIN_USB>; -}; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml index e63f800c6caa..41fbbe059d80 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml @@ -25,6 +25,7 @@ properties: compatible: items: - enum: + - qcom,qcs615-aoss-qmp - qcom,qcs8300-aoss-qmp - qcom,qdu1000-aoss-qmp - qcom,sa8255p-aoss-qmp diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml index b7acb65bdecd..225c0f07ae94 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml @@ -360,19 +360,21 @@ properties: - renesas,white-hawk-cpu # White Hawk CPU board (RTP8A779G0ASKB0FC0SA000) - const: renesas,r8a779g0 - - description: R-Car V4H (R8A779G2) - items: - - enum: - - renesas,white-hawk-single # White Hawk Single board (RTP8A779G2ASKB0F10SA001) - - const: renesas,r8a779g2 - - const: renesas,r8a779g0 - - items: - enum: - renesas,white-hawk-breakout # White Hawk BreakOut board (RTP8A779G0ASKB0SB0SA000) - const: renesas,white-hawk-cpu - const: renesas,r8a779g0 + - description: R-Car V4H (R8A779G[23]) + items: + - enum: + - renesas,white-hawk-single # White Hawk Single board (RTP8A779G[23]ASKB0F10SA001) + - enum: + - renesas,r8a779g2 # ES2.x + - renesas,r8a779g3 # ES3.x + - const: renesas,r8a779g0 + - description: R-Car V4M (R8A779H0) items: - enum: @@ -525,6 +527,23 @@ properties: - renesas,rzv2mevk2 # RZ/V2M Eval Board v2.0 - const: renesas,r9a09g011 + - description: RZ/G3E (R9A09G047) + items: + - enum: + - renesas,smarc2-evk # RZ SMARC Carrier-II EVK + - enum: + - renesas,rzg3e-smarcm # RZ/G3E SMARC Module (SoM) + - enum: + - renesas,r9a09g047e27 # Dual Cortex-A55 + Cortex-M33 (15mm BGA) + - renesas,r9a09g047e28 # Dual Cortex-A55 + Cortex-M33 (21mm BGA) + - renesas,r9a09g047e37 # Dual Cortex-A55 + Cortex-M33 + Ethos-U55 (15mm BGA) + - renesas,r9a09g047e38 # Dual Cortex-A55 + Cortex-M33 + Ethos-U55 (21mm BGA) + - renesas,r9a09g047e47 # Quad Cortex-A55 + Cortex-M33 (15mm BGA) + - renesas,r9a09g047e48 # Quad Cortex-A55 + Cortex-M33 (21mm BGA) + - renesas,r9a09g047e57 # Quad Cortex-A55 + Cortex-M33 + Ethos-U55 (15mm BGA) + - renesas,r9a09g047e58 # Quad Cortex-A55 + Cortex-M33 + Ethos-U55 (21mm BGA) + - const: renesas,r9a09g047 + - description: RZ/V2H(P) (R9A09G057) items: - enum: diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 7eca9e1ad6a3..61f38b68a4a3 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -23,6 +23,7 @@ properties: - rockchip,rk3576-bigcore-grf - rockchip,rk3576-cci-grf - rockchip,rk3576-gpu-grf + - rockchip,rk3576-hdptxphy-grf - rockchip,rk3576-litcore-grf - rockchip,rk3576-npu-grf - rockchip,rk3576-php-grf diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml index 6cdfe7e059a3..8e6d051d8c97 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml @@ -55,6 +55,7 @@ properties: - samsung,exynos7885-pmu - samsung,exynos8895-pmu - samsung,exynos9810-pmu + - samsung,exynos990-pmu - samsung,exynosautov9-pmu - samsung,exynosautov920-pmu - tesla,fsd-pmu diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml index f80fcbc3128b..5b046932fbc3 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml @@ -64,6 +64,7 @@ properties: samsung,mode: $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] description: Selects USI function (which serial protocol to use). Refer to <include/dt-bindings/soc/samsung,exynos-usi.h> for valid USI mode values. diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml index 3ca220582897..a75aef240629 100644 --- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml @@ -21,6 +21,10 @@ properties: - samsung,exynos3-sysreg - samsung,exynos4-sysreg - samsung,exynos5-sysreg + - samsung,exynos8895-fsys0-sysreg + - samsung,exynos8895-fsys1-sysreg + - samsung,exynos8895-peric0-sysreg + - samsung,exynos8895-peric1-sysreg - samsung,exynosautov920-peric0-sysreg - samsung,exynosautov920-peric1-sysreg - tesla,fsd-cam-sysreg @@ -79,6 +83,10 @@ allOf: - samsung,exynos850-cmgp-sysreg - samsung,exynos850-peri-sysreg - samsung,exynos850-sysreg + - samsung,exynos8895-fsys0-sysreg + - samsung,exynos8895-fsys1-sysreg + - samsung,exynos8895-peric0-sysreg + - samsung,exynos8895-peric1-sysreg then: required: - clocks diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index 3cb1471cc6b6..927b3200e29e 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -92,6 +92,16 @@ properties: description: | This property is as per sci-pm-domain.txt. + clocks: + items: + - description: ICSSG_CORE Clock + - description: ICSSG_IEP Clock + - description: ICSSG_RGMII_MHZ_250 Clock + - description: ICSSG_RGMII_MHZ_50 Clock + - description: ICSSG_RGMII_MHZ_5 Clock + - description: ICSSG_UART Clock + - description: ICSSG_ICLK Clock + patternProperties: memories@[a-f0-9]+$: diff --git a/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt deleted file mode 100644 index 2417b13ba468..000000000000 --- a/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt +++ /dev/null @@ -1,26 +0,0 @@ -LogicoreIP designed compatible with Xilinx ZYNQ family. -------------------------------------------------------- - -General concept ---------------- - -LogicoreIP design to provide the isolation between processing system -and programmable logic. Also provides the list of register set to configure -the frequency. - -Required properties: -- compatible: shall be one of: - "xlnx,vcu" - "xlnx,vcu-logicoreip-1.0" -- reg : The base offset and size of the VCU_PL_SLCR register space. -- clocks: phandle for aclk and pll_ref clocksource -- clock-names: The identification string, "aclk", is always required for - the axi clock. "pll_ref" is required for pll. -Example: - - xlnx_vcu: vcu@a0040000 { - compatible = "xlnx,vcu-logicoreip-1.0"; - reg = <0x0 0xa0040000 0x0 0x1000>; - clocks = <&si570_1>, <&clkc 71>; - clock-names = "pll_ref", "aclk"; - }; diff --git a/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml b/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml index f3f32540779c..f1beae84cad1 100644 --- a/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml +++ b/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml @@ -36,12 +36,14 @@ unevaluatedProperties: false examples: - | - i2c { - #address-cells = <1>; - #size-cells = <0>; - codec@34 { - compatible = "adi,ssm2518"; - reg = <0x34>; - gpios = <&gpio 5 0>; - }; - }; + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@34 { + compatible = "adi,ssm2518"; + reg = <0x34>; + gpios = <&gpio 5 GPIO_ACTIVE_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml index ebc9097f936a..b4eca702febc 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml @@ -23,6 +23,7 @@ properties: - allwinner,sun8i-h3-codec - allwinner,sun8i-v3s-codec - allwinner,sun50i-h616-codec + - allwinner,suniv-f1c100s-codec reg: maxItems: 1 @@ -77,6 +78,7 @@ properties: - MIC1 - MIC2 - MIC3 + - MIC # Microphone Biases from the SoC - HBIAS @@ -87,6 +89,8 @@ properties: - Headset Mic - Line In - Line Out + - Right FM In + - Left FM In - Mic - Speaker @@ -98,6 +102,10 @@ properties: maxItems: 1 description: GPIO to enable the external amplifier + hp-det-gpios: + maxItems: 1 + description: GPIO for headphone/line-out detection + required: - "#sound-dai-cells" - compatible @@ -247,8 +255,10 @@ allOf: allwinner,audio-routing: items: enum: + - Headphone - LINEOUT - Line Out + - Speaker dmas: items: @@ -270,6 +280,33 @@ allOf: - const: rx - const: tx + - if: + properties: + compatible: + enum: + - allwinner,suniv-f1c100s-codec + + then: + properties: + allwinner,audio-routing: + items: + enum: + - HP + - HPCOM + - LINEIN + - LINEOUT + - MIC + - HBIAS + - MBIAS + - Headphone + - Headset Mic + - Line In + - Line Out + - Right FM In + - Left FM In + - Mic + - Speaker + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml b/Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml new file mode 100644 index 000000000000..a05e61431824 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/atmel,at91-ssc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Serial Synchronous Serial (SSC) + +maintainers: + - Andrei Simion <andrei.simion@microchip.com> + +description: + The Atmel Synchronous Serial Controller (SSC) provides a versatile + synchronous communication link for audio and telecom applications, + supporting protocols like I2S, Short Frame Sync, and Long Frame Sync. + +properties: + compatible: + enum: + - atmel,at91rm9200-ssc + - atmel,at91sam9g45-ssc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: pclk + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel + + dma-names: + items: + - const: tx + - const: rx + + atmel,clk-from-rk-pin: + description: + Specify the clock source for the SSC (Synchronous Serial Controller) + when operating in slave mode. By default, the clock is sourced from + the TK pin. + type: boolean + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +allOf: + - $ref: dai-common.yaml# + - if: + properties: + compatible: + contains: + enum: + - atmel,at91sam9g45-ssc + then: + required: + - dmas + - dma-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/dma/at91.h> + #include <dt-bindings/interrupt-controller/irq.h> + + ssc@100000 { + compatible = "atmel,at91sam9g45-ssc"; + reg = <0x100000 0x4000>; + interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>; + dmas = <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) | + AT91_XDMAC_DT_PERID(38))>, + <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) | + AT91_XDMAC_DT_PERID(39))>; + dma-names = "tx", "rx"; + clocks = <&pmc PMC_TYPE_PERIPHERAL 28>; + clock-names = "pclk"; + #sound-dai-cells = <0>; + }; + + ssc@c00000 { + compatible = "atmel,at91rm9200-ssc"; + reg = <0xc00000 0x4000>; + interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 14>; + clock-names = "pclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/atmel,at91sam9g20ek-wm8731.yaml b/Documentation/devicetree/bindings/sound/atmel,at91sam9g20ek-wm8731.yaml new file mode 100644 index 000000000000..627da2d890b2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel,at91sam9g20ek-wm8731.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/atmel,at91sam9g20ek-wm8731.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel at91sam9g20ek wm8731 audio complex + +maintainers: + - Balakrishnan Sambath <balakrishnan.s@microchip.com> + +description: + The audio complex configuration for Atmel at91sam9g20ek with WM8731 audio codec. + +properties: + compatible: + const: atmel,at91sam9g20ek-wm8731-audio + + atmel,model: + $ref: /schemas/types.yaml#/definitions/string + description: The user-visible name of this sound complex. + + atmel,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: A list of the connections between audio components. + minItems: 2 + maxItems: 4 + items: + enum: + # Board Connectors + - Ext Spk + - Int Mic + + # CODEC Pins + - LOUT + - ROUT + - LHPOUT + - RHPOUT + - LLINEIN + - RLINEIN + - MICIN + + atmel,ssc-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the SSC controller. + + atmel,audio-codec: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of WM8731 audio codec. + +required: + - compatible + - atmel,model + - atmel,audio-routing + - atmel,ssc-controller + - atmel,audio-codec + +additionalProperties: false + +examples: + - | + sound { + compatible = "atmel,at91sam9g20ek-wm8731-audio"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pck0_as_mck>; + atmel,model = "wm8731 @ AT91SAMG20EK"; + atmel,audio-routing = + "Ext Spk", "LHPOUT", + "Int Mic", "MICIN"; + atmel,ssc-controller = <&ssc0>; + atmel,audio-codec = <&wm8731>; + }; diff --git a/Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt deleted file mode 100644 index 9c5a9947b64d..000000000000 --- a/Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt +++ /dev/null @@ -1,26 +0,0 @@ -* Atmel at91sam9g20ek wm8731 audio complex - -Required properties: - - compatible: "atmel,at91sam9g20ek-wm8731-audio" - - atmel,model: The user-visible name of this sound complex. - - atmel,audio-routing: A list of the connections between audio components. - - atmel,ssc-controller: The phandle of the SSC controller - - atmel,audio-codec: The phandle of the WM8731 audio codec -Optional properties: - - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt - -Example: -sound { - compatible = "atmel,at91sam9g20ek-wm8731-audio"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_pck0_as_mck>; - - atmel,model = "wm8731 @ AT91SAMG20EK"; - - atmel,audio-routing = - "Ext Spk", "LHPOUT", - "Int MIC", "MICIN"; - - atmel,ssc-controller = <&ssc0>; - atmel,audio-codec = <&wm8731>; -}; diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml index f943f90d8b15..94588353f852 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml +++ b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml @@ -37,6 +37,10 @@ properties: codec2codec: type: object description: Codec to Codec node + hp-det-gpios: + $ref: audio-graph.yaml#/properties/hp-det-gpios + widgets: + $ref: audio-graph.yaml#/properties/widgets required: - compatible diff --git a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml index 3b0b743e49c4..bb92d6ca3144 100644 --- a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml +++ b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml @@ -18,6 +18,8 @@ properties: compatible: enum: - awinic,aw88081 + - awinic,aw88083 + - awinic,aw88166 - awinic,aw88261 - awinic,aw88395 - awinic,aw88399 @@ -58,6 +60,7 @@ allOf: contains: enum: - awinic,aw88081 + - awinic,aw88083 - awinic,aw88261 then: properties: diff --git a/Documentation/devicetree/bindings/sound/dmic-codec.yaml b/Documentation/devicetree/bindings/sound/dmic-codec.yaml index 59ef0cf6b6e5..cc3c84dd4c26 100644 --- a/Documentation/devicetree/bindings/sound/dmic-codec.yaml +++ b/Documentation/devicetree/bindings/sound/dmic-codec.yaml @@ -19,6 +19,9 @@ properties: '#sound-dai-cells': const: 0 + vref-supply: + description: Phandle to the digital microphone reference supply + dmicen-gpios: description: GPIO specifier for DMIC to control start and stop maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/everest,es71x4.yaml b/Documentation/devicetree/bindings/sound/everest,es71x4.yaml index fd1b32812228..efe9f3fd3778 100644 --- a/Documentation/devicetree/bindings/sound/everest,es71x4.yaml +++ b/Documentation/devicetree/bindings/sound/everest,es71x4.yaml @@ -53,10 +53,10 @@ unevaluatedProperties: false examples: - | - codec { - compatible = "everest,es7134"; - #sound-dai-cells = <0>; - VDD-supply = <&vdd_supply>; - }; + codec { + compatible = "everest,es7134"; + #sound-dai-cells = <0>; + VDD-supply = <&vdd_supply>; + }; ... diff --git a/Documentation/devicetree/bindings/sound/everest,es7241.yaml b/Documentation/devicetree/bindings/sound/everest,es7241.yaml index f179af758730..e5cfb40f1ef2 100644 --- a/Documentation/devicetree/bindings/sound/everest,es7241.yaml +++ b/Documentation/devicetree/bindings/sound/everest,es7241.yaml @@ -54,14 +54,15 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/gpio/gpio.h> - codec { - compatible = "everest,es7241"; - #sound-dai-cells = <0>; - reset-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; - VDDP-supply = <&vddp_supply>; - VDDA-supply = <&vdda_supply>; - VDDD-supply = <&vddd_supply>; - }; + #include <dt-bindings/gpio/gpio.h> + + codec { + compatible = "everest,es7241"; + #sound-dai-cells = <0>; + reset-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; + VDDP-supply = <&vddp_supply>; + VDDA-supply = <&vdda_supply>; + VDDD-supply = <&vddd_supply>; + }; ... diff --git a/Documentation/devicetree/bindings/sound/everest,es8328.yaml b/Documentation/devicetree/bindings/sound/everest,es8328.yaml index ed18e40dcaac..ddddd7b143ab 100644 --- a/Documentation/devicetree/bindings/sound/everest,es8328.yaml +++ b/Documentation/devicetree/bindings/sound/everest,es8328.yaml @@ -24,9 +24,13 @@ maintainers: properties: compatible: - enum: - - everest,es8328 - - everest,es8388 + oneOf: + - enum: + - everest,es8328 + - items: + - enum: + - everest,es8388 + - const: everest,es8328 reg: maxItems: 1 @@ -56,6 +60,7 @@ properties: required: - compatible + - reg - clocks - DVDD-supply - AVDD-supply diff --git a/Documentation/devicetree/bindings/sound/fsl,audmix.yaml b/Documentation/devicetree/bindings/sound/fsl,audmix.yaml index 9413b901cf77..3ad197b3c82c 100644 --- a/Documentation/devicetree/bindings/sound/fsl,audmix.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,audmix.yaml @@ -61,13 +61,26 @@ properties: - description: serial audio input 2 maxItems: 1 + ports: + $ref: /schemas/graph.yaml#/properties/ports + patternProperties: + '^port@[0-1]': + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: Input port from SAI TX + + properties: + port@2: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: Output port to SAI RX + required: - compatible - reg - clocks - clock-names - power-domains - - dais unevaluatedProperties: false @@ -80,4 +93,50 @@ examples: clock-names = "ipg"; power-domains = <&pd_audmix>; dais = <&sai4>, <&sai5>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + playback-only; + + amix_endpoint0: endpoint { + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + dai-tdm-slot-width-map = <32 8 32>; + dai-format = "dsp_a"; + remote-endpoint = <&be00_ep>; + }; + }; + + port@1 { + reg = <1>; + playback-only; + + amix_endpoint1: endpoint { + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + dai-tdm-slot-width-map = <32 8 32>; + dai-format = "dsp_a"; + remote-endpoint = <&be01_ep>; + }; + }; + + port@2 { + reg = <2>; + capture-only; + + amix_endpoint2: endpoint { + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + dai-tdm-slot-width-map = <32 8 32>; + dai-format = "dsp_a"; + bitclock-master; + frame-master; + remote-endpoint = <&be02_ep>; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml index 0782f3f9947f..8f1108e7e14e 100644 --- a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml @@ -80,27 +80,30 @@ required: - fsl,asrc-rate - fsl,asrc-format -additionalProperties: false +allOf: + - $ref: dai-common.yaml# + +unevaluatedProperties: false examples: - | #include <dt-bindings/clock/imx8mn-clock.h> easrc: easrc@300c0000 { - compatible = "fsl,imx8mn-easrc"; - reg = <0x300c0000 0x10000>; - interrupts = <0x0 122 0x4>; - clocks = <&clk IMX8MN_CLK_ASRC_ROOT>; - clock-names = "mem"; - dmas = <&sdma2 16 23 0> , <&sdma2 17 23 0>, - <&sdma2 18 23 0> , <&sdma2 19 23 0>, - <&sdma2 20 23 0> , <&sdma2 21 23 0>, - <&sdma2 22 23 0> , <&sdma2 23 23 0>; - dma-names = "ctx0_rx", "ctx0_tx", - "ctx1_rx", "ctx1_tx", - "ctx2_rx", "ctx2_tx", - "ctx3_rx", "ctx3_tx"; - firmware-name = "imx/easrc/easrc-imx8mn.bin"; - fsl,asrc-rate = <8000>; - fsl,asrc-format = <2>; + compatible = "fsl,imx8mn-easrc"; + reg = <0x300c0000 0x10000>; + interrupts = <0x0 122 0x4>; + clocks = <&clk IMX8MN_CLK_ASRC_ROOT>; + clock-names = "mem"; + dmas = <&sdma2 16 23 0> , <&sdma2 17 23 0>, + <&sdma2 18 23 0> , <&sdma2 19 23 0>, + <&sdma2 20 23 0> , <&sdma2 21 23 0>, + <&sdma2 22 23 0> , <&sdma2 23 23 0>; + dma-names = "ctx0_rx", "ctx0_tx", + "ctx1_rx", "ctx1_tx", + "ctx2_rx", "ctx2_tx", + "ctx3_rx", "ctx3_tx"; + firmware-name = "imx/easrc/easrc-imx8mn.bin"; + fsl,asrc-rate = <8000>; + fsl,asrc-format = <2>; }; diff --git a/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml index 76aa1f248488..85799f83e65f 100644 --- a/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml @@ -77,6 +77,10 @@ properties: power-domains: maxItems: 1 + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + fsl,asrc-rate: $ref: /schemas/types.yaml#/definitions/uint32 description: The mutual sample rate used by DPCM Back Ends @@ -120,6 +124,7 @@ required: - fsl,asrc-width allOf: + - $ref: dai-common.yaml# - if: properties: compatible: @@ -145,7 +150,7 @@ allOf: required: - power-domains -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -173,4 +178,12 @@ examples: "txa", "txb", "txc"; fsl,asrc-rate = <48000>; fsl,asrc-width = <16>; + + port { + playback-only; + + asrc_endpoint: endpoint { + remote-endpoint = <&fe00_ep>; + }; + }; }; diff --git a/Documentation/devicetree/bindings/sound/fsl,imx95-cm7-sof.yaml b/Documentation/devicetree/bindings/sound/fsl,imx95-cm7-sof.yaml new file mode 100644 index 000000000000..f00ae3219e15 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,imx95-cm7-sof.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,imx95-cm7-sof.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP imx95 CM7 core + +maintainers: + - Daniel Baluta <daniel.baluta@nxp.com> + +description: NXP imx95 CM7 core used for audio processing + +properties: + compatible: + const: fsl,imx95-cm7-sof + + reg: + maxItems: 1 + + reg-names: + const: sram + + memory-region: + maxItems: 1 + + memory-region-names: + const: dma + + port: + description: SAI3 port + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + - reg-names + - memory-region + - memory-region-names + - port + +allOf: + - $ref: fsl,sof-cpu.yaml# + +unevaluatedProperties: false + +examples: + - | + cm7-cpu@80000000 { + compatible = "fsl,imx95-cm7-sof"; + reg = <0x80000000 0x6100000>; + reg-names = "sram"; + mboxes = <&mu7 2 0>, <&mu7 2 1>, <&mu7 3 0>, <&mu7 3 1>; + mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1"; + memory-region = <&adma_res>; + memory-region-names = "dma"; + port { + /* SAI3-WM8962 link */ + endpoint { + remote-endpoint = <&wm8962_ep>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml index c1e9803fc113..c47b7a097490 100644 --- a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml @@ -25,6 +25,7 @@ properties: - fsl,imx8mm-micfil - fsl,imx8mp-micfil - fsl,imx93-micfil + - fsl,imx943-micfil reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/fsl,mqs.yaml b/Documentation/devicetree/bindings/sound/fsl,mqs.yaml index 030ccc173130..8c22e8348b14 100644 --- a/Documentation/devicetree/bindings/sound/fsl,mqs.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,mqs.yaml @@ -23,6 +23,8 @@ properties: - fsl,imx8qm-mqs - fsl,imx8qxp-mqs - fsl,imx93-mqs + - fsl,imx943-aonmix-mqs + - fsl,imx943-wakeupmix-mqs - fsl,imx95-aonmix-mqs - fsl,imx95-netcmix-mqs diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml index a5d9c246cc47..0d733e5b08a4 100644 --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml @@ -41,6 +41,10 @@ properties: - fsl,imx93-sai - fsl,imx95-sai - fsl,vf610-sai + - items: + - enum: + - fsl,imx94-sai + - const: fsl,imx95-sai reg: maxItems: 1 @@ -93,6 +97,24 @@ properties: items: - description: receive and transmit interrupt + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: port for TX and RX + + port@1: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: port for TX only + + port@2: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: port for RX only + big-endian: description: | required if all the SAI registers are big-endian rather than little-endian. @@ -204,4 +226,37 @@ examples: dma-names = "rx", "tx"; fsl,dataline = <1 0xff 0xff 2 0xff 0x11>; #sound-dai-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + playback-only; + + sai1_endpoint0: endpoint { + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + dai-tdm-slot-width-map = <32 8 32>; + dai-format = "dsp_a"; + bitclock-master; + frame-master; + remote-endpoint = <&mcodec01_ep>; + }; + }; + + port@2 { + reg = <2>; + capture-only; + + sai1_endpoint1: endpoint { + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + dai-tdm-slot-width-map = <32 8 32>; + dai-format = "dsp_a"; + remote-endpoint = <&fe02_ep>; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/sound/fsl,sof-cpu.yaml b/Documentation/devicetree/bindings/sound/fsl,sof-cpu.yaml new file mode 100644 index 000000000000..31863932dbc3 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,sof-cpu.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,sof-cpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP audio processor common properties + +maintainers: + - Daniel Baluta <daniel.baluta@nxp.com> + +properties: + mboxes: + maxItems: 4 + + mbox-names: + items: + - const: txdb0 + - const: txdb1 + - const: rxdb0 + - const: rxdb1 + +required: + - mboxes + - mbox-names + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml index 5e2801014221..f68d0e0ecfe5 100644 --- a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml @@ -140,21 +140,21 @@ examples: #include <dt-bindings/reset/imx8mp-reset.h> xcvr: xcvr@30cc0000 { - compatible = "fsl,imx8mp-xcvr"; - reg = <0x30cc0000 0x800>, - <0x30cc0800 0x400>, - <0x30cc0c00 0x080>, - <0x30cc0e00 0x080>; - reg-names = "ram", "regs", "rxfifo", "txfifo"; - interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_IPG>, - <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_PHY>, - <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SPBA2_ROOT>, - <&audiomix_clk IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>; - clock-names = "ipg", "phy", "spba", "pll_ipg"; - dmas = <&sdma2 30 2 0>, <&sdma2 31 2 0>; - dma-names = "rx", "tx"; - resets = <&audiomix_reset 0>; + compatible = "fsl,imx8mp-xcvr"; + reg = <0x30cc0000 0x800>, + <0x30cc0800 0x400>, + <0x30cc0c00 0x080>, + <0x30cc0e00 0x080>; + reg-names = "ram", "regs", "rxfifo", "txfifo"; + interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_IPG>, + <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_PHY>, + <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SPBA2_ROOT>, + <&audiomix_clk IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>; + clock-names = "ipg", "phy", "spba", "pll_ipg"; + dmas = <&sdma2 30 2 0>, <&sdma2 31 2 0>; + dma-names = "rx", "tx"; + resets = <&audiomix_reset 0>; }; diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml index f7ad5ea2491e..3c75c8c78987 100644 --- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml @@ -46,6 +46,14 @@ patternProperties: description: see tdm-slot.txt. $ref: /schemas/types.yaml#/definitions/uint32 + playback-only: + description: link is used only for playback + $ref: /schemas/types.yaml#/definitions/flag + + capture-only: + description: link is used only for capture + $ref: /schemas/types.yaml#/definitions/flag + cpu: description: Holds subnode which indicates cpu dai. type: object @@ -71,6 +79,12 @@ patternProperties: - link-name - cpu + allOf: + - not: + required: + - playback-only + - capture-only + additionalProperties: false required: diff --git a/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml b/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml index 76b6f2cf25df..dca617860938 100644 --- a/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml @@ -72,19 +72,19 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/interrupt-controller/irq.h> - #define KEEM_BAY_PSS_AUX_I2S3 - #define KEEM_BAY_PSS_I2S3 - i2s3: i2s@20140000 { - compatible = "intel,keembay-i2s"; - #sound-dai-cells = <0>; - reg = <0x20140000 0x200>, /* I2S registers */ - <0x202a00a4 0x4>; /* I2S gen configuration */ - reg-names = "i2s-regs", "i2s_gen_cfg"; - interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; - clock-names = "osc", "apb_clk"; - clocks = <&scmi_clk KEEM_BAY_PSS_AUX_I2S3>, <&scmi_clk KEEM_BAY_PSS_I2S3>; - dmas = <&axi_dma0 29>, <&axi_dma0 33>; - dma-names = "tx", "rx"; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #define KEEM_BAY_PSS_AUX_I2S3 + #define KEEM_BAY_PSS_I2S3 + i2s@20140000 { + compatible = "intel,keembay-i2s"; + #sound-dai-cells = <0>; + reg = <0x20140000 0x200>, /* I2S registers */ + <0x202a00a4 0x4>; /* I2S gen configuration */ + reg-names = "i2s-regs", "i2s_gen_cfg"; + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "osc", "apb_clk"; + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_I2S3>, <&scmi_clk KEEM_BAY_PSS_I2S3>; + dmas = <&axi_dma0 29>, <&axi_dma0 33>; + dma-names = "tx", "rx"; + }; diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml index ba482747f0e6..76d5a437dc8f 100644 --- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml @@ -14,11 +14,15 @@ allOf: properties: compatible: - enum: - - mediatek,mt8188-es8326 - - mediatek,mt8188-mt6359-evb - - mediatek,mt8188-nau8825 - - mediatek,mt8188-rt5682s + oneOf: + - enum: + - mediatek,mt8188-es8326 + - mediatek,mt8188-mt6359-evb + - mediatek,mt8188-nau8825 + - mediatek,mt8188-rt5682s + - items: + - const: mediatek,mt8390-mt6359-evk + - const: mediatek,mt8188-mt6359-evb audio-routing: description: @@ -36,6 +40,14 @@ properties: hardware that provides additional audio functionalities if present. The AFE will link to ADSP when the phandle is provided. + mediatek,accdet: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle to the MT6359 accessory detection block, which detects audio + jack insertion and removal. This property should only be present if the + accdet block is actually wired to the audio jack pins and to be used for + jack detection. + patternProperties: "^dai-link-[0-9]+$": type: object @@ -56,6 +68,9 @@ patternProperties: - ETDM2_OUT_BE - ETDM3_OUT_BE - PCM1_BE + - DL_SRC_BE + - UL_SRC_BE + - DMIC_BE codec: description: Holds subnode which indicates codec dai. diff --git a/Documentation/devicetree/bindings/sound/neofidelity,ntp8918.yaml b/Documentation/devicetree/bindings/sound/neofidelity,ntp8918.yaml index 952768b35902..6946177e391a 100644 --- a/Documentation/devicetree/bindings/sound/neofidelity,ntp8918.yaml +++ b/Documentation/devicetree/bindings/sound/neofidelity,ntp8918.yaml @@ -55,16 +55,18 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/gpio/gpio.h> - i2c { - #address-cells = <1>; - #size-cells = <0>; - audio-codec@2a { - compatible = "neofidelity,ntp8918"; - #sound-dai-cells = <0>; - reg = <0x2a>; - clocks = <&clkc 150>, <&clkc 151>, <&clkc 152>; - clock-names = "wck", "scl", "bck"; - reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>; + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + audio-codec@2a { + compatible = "neofidelity,ntp8918"; + #sound-dai-cells = <0>; + reg = <0x2a>; + clocks = <&clkc 150>, <&clkc 151>, <&clkc 152>; + clock-names = "wck", "scl", "bck"; + reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>; + }; }; - }; diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml index d3cf8f59cb23..c8543f969ebb 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml @@ -58,6 +58,40 @@ properties: items: enum: [1, 2, 3, 4, 5] + qcom,tx-channel-mapping: + description: | + Specifies static channel mapping between slave and master tx port + channels. + In the order of slave port channels which is adc1, adc2, adc3, + dmic0, dmic1, mbhc, dmic2, dmic3, dmci4, dmic5, dmic6, dmic7. + $ref: /schemas/types.yaml#/definitions/uint8-array + minItems: 12 + maxItems: 12 + additionalItems: false + items: + enum: + - 1 # WCD9370_SWRM_CH1 + - 2 # WCD9370_SWRM_CH2 + - 3 # WCD9370_SWRM_CH3 + - 4 # WCD9370_SWRM_CH4 + + qcom,rx-channel-mapping: + description: | + Specifies static channels mapping between slave and master rx port + channels. + In the order of slave port channels, which is + hph_l, hph_r, clsh, comp_l, comp_r, lo, dsd_r, dsd_l. + $ref: /schemas/types.yaml#/definitions/uint8-array + minItems: 8 + maxItems: 8 + additionalItems: false + items: + enum: + - 1 # WCD9370_SWRM_CH1 + - 2 # WCD9370_SWRM_CH2 + - 3 # WCD9370_SWRM_CH3 + - 4 # WCD9370_SWRM_CH4 + required: - compatible - reg @@ -74,6 +108,7 @@ examples: compatible = "sdw20217010a00"; reg = <0 4>; qcom,rx-port-mapping = <1 2 3 4 5>; + qcom,rx-channel-mapping = /bits/ 8 <1 2 1 1 2 1 1 2>; }; }; @@ -85,6 +120,7 @@ examples: compatible = "sdw20217010a00"; reg = <0 3>; qcom,tx-port-mapping = <2 2 3 4>; + qcom,tx-channel-mapping = /bits/ 8 <1 2 1 1 2 3 3 4 1 2 3 4>; }; }; diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5682.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5682.yaml new file mode 100644 index 000000000000..39333ea05646 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/realtek,rt5682.yaml @@ -0,0 +1,156 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/realtek,rt5682.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek rt5682 and rt5682i codecs + +maintainers: + - Bard Liao <bardliao@realtek.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - realtek,rt5682 + - realtek,rt5682i + + reg: + maxItems: 1 + description: I2C address of the device. + + interrupts: + maxItems: 1 + description: The CODEC's interrupt output. + + realtek,dmic1-data-pin: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # dmic1 data is not used + - 1 # using GPIO2 pin as dmic1 data pin + - 2 # using GPIO5 pin as dmic1 data pin + description: + Specify which GPIO pin be used as DMIC1 data pin. + + realtek,dmic1-clk-pin: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # using GPIO1 pin as dmic1 clock pin + - 1 # using GPIO3 pin as dmic1 clock pin + description: + Specify which GPIO pin be used as DMIC1 clk pin. + + realtek,jd-src: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # No JD is used + - 1 # using JD1 as JD source + description: + Specify which JD source be used. + + realtek,ldo1-en-gpios: + description: + The GPIO that controls the CODEC's LDO1_EN pin. + + realtek,btndet-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The debounce delay for push button. + The delay time is realtek,btndet-delay value multiple of 8.192 ms. + If absent, the default is 16. + + realtek,dmic-clk-rate-hz: + description: + Set the clock rate (hz) for the requirement of the particular DMIC. + + realtek,dmic-delay-ms: + description: + Set the delay time (ms) for the requirement of the particular DMIC. + + realtek,dmic-clk-driving-high: + type: boolean + description: + Set the high driving of the DMIC clock out. + + clocks: + items: + - description: phandle and clock specifier for codec MCLK. + + clock-names: + items: + - const: mclk + + "#clock-cells": + const: 1 + + clock-output-names: + minItems: 2 + maxItems: 2 + description: Name given for DAI word clock and bit clock outputs. + + "#sound-dai-cells": + const: 1 + + AVDD-supply: + description: Regulator supplying analog power through the AVDD pin. + + MICVDD-supply: + description: Regulator supplying power for the microphone bias through + the MICVDD pin. + + VBAT-supply: + description: Regulator supplying battery power through the VBAT pin. + + DBVDD-supply: + description: Regulator supplying I/O power through the DBVDD pin. + + LDO1-IN-supply: + description: Regulator supplying power to the digital core and charge + pump through the LDO1_IN pin. + +required: + - compatible + - reg + - AVDD-supply + - VBAT-supply + - MICVDD-supply + - DBVDD-supply + - LDO1-IN-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + compatible = "realtek,rt5682"; + reg = <0x1a>; + interrupts = <6 IRQ_TYPE_LEVEL_HIGH>; + realtek,ldo1-en-gpios = + <&gpio 2 GPIO_ACTIVE_HIGH>; + realtek,dmic1-data-pin = <1>; + realtek,dmic1-clk-pin = <1>; + realtek,jd-src = <1>; + + #clock-cells = <1>; + clock-output-names = "rt5682-dai-wclk", "rt5682-dai-bclk"; + + clocks = <&osc>; + clock-names = "mclk"; + + AVDD-supply = <&avdd_reg>; + VBAT-supply = <&vbat_reg>; + MICVDD-supply = <&micvdd_reg>; + DBVDD-supply = <&dbvdd_reg>; + LDO1-IN-supply = <&ldo1_in_reg>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 6d0d1514cd42..e8a2acb92646 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -112,12 +112,6 @@ properties: description: List of necessary clock names. # details are defined below - post-init-providers: - description: At least if rsnd is using DPCM connection on Audio-Graph-Card2, - fw_devlink might doesn't have enough information to break the cycle. rsnd - driver will not be probed in such case. Same problem might occur with - Multi-CPU/Codec or Codec2Codec. - # ports is below port: $ref: audio-graph-port.yaml#/definitions/port-base diff --git a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml index f4610eaed1e1..e4cdbf2202b9 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml @@ -19,6 +19,7 @@ properties: - renesas,r9a07g043-ssi # RZ/G2UL and RZ/Five - renesas,r9a07g044-ssi # RZ/G2{L,LC} - renesas,r9a07g054-ssi # RZ/V2L + - renesas,r9a08g045-ssi # RZ/G3S - const: renesas,rz-ssi reg: @@ -57,24 +58,6 @@ properties: dmas: minItems: 1 maxItems: 2 - description: - The first cell represents a phandle to dmac. - The second cell specifies the encoded MID/RID values of the SSI port - connected to the DMA client and the slave channel configuration - parameters. - bits[0:9] - Specifies MID/RID value of a SSI channel as below - MID/RID value of SSI rx0 = 0x256 - MID/RID value of SSI tx0 = 0x255 - MID/RID value of SSI rx1 = 0x25a - MID/RID value of SSI tx1 = 0x259 - MID/RID value of SSI rt2 = 0x25f - MID/RID value of SSI rx3 = 0x262 - MID/RID value of SSI tx3 = 0x261 - bit[10] - HIEN = 1, Detects a request in response to the rising edge - of the signal - bit[11] - LVL = 0, Detects based on the edge - bits[12:14] - AM = 2, Bus cycle mode - bit[15] - TM = 0, Single transfer mode dma-names: oneOf: diff --git a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml index c3c989ef2a2c..32dea7392e8d 100644 --- a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml +++ b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml @@ -31,6 +31,10 @@ properties: - rockchip,rk3288-spdif - rockchip,rk3308-spdif - const: rockchip,rk3066-spdif + - items: + - enum: + - rockchip,rk3588-spdif + - const: rockchip,rk3568-spdif reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/rt5682.txt b/Documentation/devicetree/bindings/sound/rt5682.txt deleted file mode 100644 index 5e1d08de18a5..000000000000 --- a/Documentation/devicetree/bindings/sound/rt5682.txt +++ /dev/null @@ -1,98 +0,0 @@ -RT5682 audio CODEC - -This device supports I2C only. - -Required properties: - -- compatible : "realtek,rt5682" or "realtek,rt5682i" - -- reg : The I2C address of the device. - -- AVDD-supply: phandle to the regulator supplying analog power through the - AVDD pin - -- MICVDD-supply: phandle to the regulator supplying power for the microphone - bias through the MICVDD pin. Either MICVDD or VBAT should be present. - -- VBAT-supply: phandle to the regulator supplying battery power through the - VBAT pin. Either MICVDD or VBAT should be present. - -- DBVDD-supply: phandle to the regulator supplying I/O power through the DBVDD - pin. - -- LDO1-IN-supply: phandle to the regulator supplying power to the digital core - and charge pump through the LDO1_IN pin. - -Optional properties: - -- interrupts : The CODEC's interrupt output. - -- realtek,dmic1-data-pin - 0: dmic1 is not used - 1: using GPIO2 pin as dmic1 data pin - 2: using GPIO5 pin as dmic1 data pin - -- realtek,dmic1-clk-pin - 0: using GPIO1 pin as dmic1 clock pin - 1: using GPIO3 pin as dmic1 clock pin - -- realtek,jd-src - 0: No JD is used - 1: using JD1 as JD source - -- realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin. - -- realtek,btndet-delay - The debounce delay for push button. - The delay time is realtek,btndet-delay value multiple of 8.192 ms. - If absent, the default is 16. - -- #clock-cells : Should be set to '<1>', wclk and bclk sources provided. -- clock-output-names : Name given for DAI clocks output. - -- clocks : phandle and clock specifier for codec MCLK. -- clock-names : Clock name string for 'clocks' attribute, should be "mclk". - -- realtek,dmic-clk-rate-hz : Set the clock rate (hz) for the requirement of - the particular DMIC. - -- realtek,dmic-delay-ms : Set the delay time (ms) for the requirement of - the particular DMIC. - -- realtek,dmic-clk-driving-high : Set the high driving of the DMIC clock out. - -- #sound-dai-cells: Should be set to '<1>'. - -Pins on the device (for linking into audio routes) for RT5682: - - * DMIC L1 - * DMIC R1 - * IN1P - * HPOL - * HPOR - -Example: - -rt5682 { - compatible = "realtek,rt5682i"; - reg = <0x1a>; - interrupt-parent = <&gpio>; - interrupts = <TEGRA_GPIO(U, 6) IRQ_TYPE_LEVEL_HIGH>; - realtek,ldo1-en-gpios = - <&gpio TEGRA_GPIO(R, 2) GPIO_ACTIVE_HIGH>; - realtek,dmic1-data-pin = <1>; - realtek,dmic1-clk-pin = <1>; - realtek,jd-src = <1>; - realtek,btndet-delay = <16>; - - #clock-cells = <1>; - clock-output-names = "rt5682-dai-wclk", "rt5682-dai-bclk"; - - clocks = <&osc>; - clock-names = "mclk"; - - AVDD-supply = <&avdd_reg>; - MICVDD-supply = <&micvdd_reg>; - DBVDD-supply = <&dbvdd_reg>; - LDO1-IN-supply = <&ldo1_in_reg>; -}; diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml b/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml index 5aa00617291c..1f0e6787a746 100644 --- a/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml +++ b/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/sound/ti,pcm1681.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Texas Instruments PCM1681 8-channel PWM Processor +title: Texas Instruments PCM1681 8-channel Digital-to-Analog Converter maintainers: - Shenghao Ding <shenghao-ding@ti.com> diff --git a/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml b/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml index dd5b08e3d7a1..d89b4255b51c 100644 --- a/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml +++ b/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml @@ -159,19 +159,21 @@ additionalProperties: false examples: - | - #include <dt-bindings/gpio/gpio.h> - i2c { - /* example for two devices with interrupt support */ - #address-cells = <1>; - #size-cells = <0>; - pcm6240: audio-codec@48 { - compatible = "ti,pcm6240"; - reg = <0x48>, /* primary-device */ - <0x4b>; /* secondary-device */ - #sound-dai-cells = <0>; - reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; - interrupt-parent = <&gpio1>; - interrupts = <15>; - }; - }; + #include <dt-bindings/gpio/gpio.h> + + i2c { + /* example for two devices with interrupt support */ + #address-cells = <1>; + #size-cells = <0>; + + audio-codec@48 { + compatible = "ti,pcm6240"; + reg = <0x48>, /* primary-device */ + <0x4b>; /* secondary-device */ + #sound-dai-cells = <0>; + reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; + interrupt-parent = <&gpio1>; + interrupts = <15>; + }; + }; ... diff --git a/Documentation/devicetree/bindings/sound/ti,tas2562.yaml b/Documentation/devicetree/bindings/sound/ti,tas2562.yaml index 8bc3b0c7531e..3763ca16b91f 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas2562.yaml +++ b/Documentation/devicetree/bindings/sound/ti,tas2562.yaml @@ -65,17 +65,19 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/gpio/gpio.h> - i2c { - #address-cells = <1>; - #size-cells = <0>; - codec: codec@4c { - compatible = "ti,tas2562"; - reg = <0x4c>; - #sound-dai-cells = <0>; - interrupt-parent = <&gpio1>; - interrupts = <14>; - shutdown-gpios = <&gpio1 15 0>; - ti,imon-slot-no = <0>; - }; - }; + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@4c { + compatible = "ti,tas2562"; + reg = <0x4c>; + #sound-dai-cells = <0>; + interrupt-parent = <&gpio1>; + interrupts = <14>; + shutdown-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; + ti,imon-slot-no = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/ti,tas2770.yaml b/Documentation/devicetree/bindings/sound/ti,tas2770.yaml index 362c2e6154f0..8eab98a0f7a2 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas2770.yaml +++ b/Documentation/devicetree/bindings/sound/ti,tas2770.yaml @@ -23,6 +23,7 @@ properties: compatible: enum: - ti,tas2770 + - ti,tas5770l # Apple variant reg: maxItems: 1 @@ -69,19 +70,21 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/gpio/gpio.h> - i2c { - #address-cells = <1>; - #size-cells = <0>; - codec: codec@41 { - compatible = "ti,tas2770"; - reg = <0x41>; - #sound-dai-cells = <0>; - interrupt-parent = <&gpio1>; - interrupts = <14>; - reset-gpio = <&gpio1 15 0>; - shutdown-gpios = <&gpio1 14 0>; - ti,imon-slot-no = <0>; - ti,vmon-slot-no = <2>; - }; - }; + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@41 { + compatible = "ti,tas2770"; + reg = <0x41>; + #sound-dai-cells = <0>; + interrupt-parent = <&gpio1>; + interrupts = <14>; + reset-gpio = <&gpio1 15 GPIO_ACTIVE_HIGH>; + shutdown-gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>; + ti,imon-slot-no = <0>; + ti,vmon-slot-no = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml index 976238689249..5ea1cdc593b5 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml +++ b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml @@ -101,22 +101,24 @@ additionalProperties: false examples: - | - #include <dt-bindings/gpio/gpio.h> - i2c { - /* example with quad tas2781s, such as tablet or pad device */ - #address-cells = <1>; - #size-cells = <0>; - quad_tas2781: tas2781@38 { - compatible = "ti,tas2781"; - reg = <0x38>, /* Audio slot 0 */ - <0x3a>, /* Audio slot 1 */ - <0x39>, /* Audio slot 2 */ - <0x3b>; /* Audio slot 3 */ - - #sound-dai-cells = <0>; - reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; - interrupt-parent = <&gpio1>; - interrupts = <15>; - }; - }; + #include <dt-bindings/gpio/gpio.h> + + i2c { + /* example with quad tas2781s, such as tablet or pad device */ + #address-cells = <1>; + #size-cells = <0>; + + audio-codec@38 { + compatible = "ti,tas2781"; + reg = <0x38>, /* Audio slot 0 */ + <0x3a>, /* Audio slot 1 */ + <0x39>, /* Audio slot 2 */ + <0x3b>; /* Audio slot 3 */ + + #sound-dai-cells = <0>; + reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; + interrupt-parent = <&gpio1>; + interrupts = <15>; + }; + }; ... diff --git a/Documentation/devicetree/bindings/sound/ti,tas27xx.yaml b/Documentation/devicetree/bindings/sound/ti,tas27xx.yaml index 530bc3937847..fcaae848e78a 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas27xx.yaml +++ b/Documentation/devicetree/bindings/sound/ti,tas27xx.yaml @@ -24,6 +24,7 @@ properties: enum: - ti,tas2764 - ti,tas2780 + - ti,sn012776 # Apple variant of TAS2764 reg: maxItems: 1 @@ -62,21 +63,23 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/gpio/gpio.h> - i2c { - #address-cells = <1>; - #size-cells = <0>; - codec: codec@38 { - compatible = "ti,tas2764"; - reg = <0x38>; - #sound-dai-cells = <0>; - interrupt-parent = <&gpio1>; - interrupts = <14>; - reset-gpios = <&gpio1 15 0>; - shutdown-gpios = <&gpio1 15 0>; - ti,imon-slot-no = <0>; - ti,vmon-slot-no = <2>; - }; - }; + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@38 { + compatible = "ti,tas2764"; + reg = <0x38>; + #sound-dai-cells = <0>; + interrupt-parent = <&gpio1>; + interrupts = <14>; + reset-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; + shutdown-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; + ti,imon-slot-no = <0>; + ti,vmon-slot-no = <2>; + }; + }; ... diff --git a/Documentation/devicetree/bindings/sound/ti,tas57xx.yaml b/Documentation/devicetree/bindings/sound/ti,tas57xx.yaml index 2f917238db95..74f7d02b424b 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas57xx.yaml +++ b/Documentation/devicetree/bindings/sound/ti,tas57xx.yaml @@ -112,22 +112,24 @@ unevaluatedProperties: false examples: - | - i2c { - #address-cells = <1>; - #size-cells = <0>; - - codec@2a { - compatible = "ti,tas5717"; - reg = <0x2a>; - #sound-dai-cells = <0>; - reset-gpios = <&gpio1 15 0>; - pdn-gpios = <&gpio1 15 0>; - AVDD-supply = <&avdd_supply>; - DVDD-supply = <&dvdd_supply>; - HPVDD-supply = <&hpvdd_supply>; - PVDD_AB-supply = <&pvdd_ab_supply>; - PVDD_CD-supply = <&pvdd_cd_supply>; - }; - }; + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@2a { + compatible = "ti,tas5717"; + reg = <0x2a>; + #sound-dai-cells = <0>; + reset-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; + pdn-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; + AVDD-supply = <&avdd_supply>; + DVDD-supply = <&dvdd_supply>; + HPVDD-supply = <&hpvdd_supply>; + PVDD_AB-supply = <&pvdd_ab_supply>; + PVDD_CD-supply = <&pvdd_cd_supply>; + }; + }; ... diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml index 329260cf0fa0..3029a868e5e1 100644 --- a/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml +++ b/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml @@ -38,6 +38,82 @@ properties: DCVDD-supply: true MICVDD-supply: true + wlf,in1l-as-dmicdat1: + type: boolean + description: + Use IN1L/DMICDAT1 as DMICDAT1, enabling the DMIC input path. + Can be used separately or together with wlf,in1r-as-dmicdat2. + + wlf,in1r-as-dmicdat2: + type: boolean + description: + Use IN1R/DMICDAT2 as DMICDAT2, enabling the DMIC input path. + Can be used separately or together with wlf,in1l-as-dmicdat1. + + wlf,gpio-cfg: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 4 + maxItems: 4 + description: + Default register values for R121/122/123/124 (GPIO Control). + If any entry has the value 0xFFFF, the related register won't be set. + default: [0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF] + + wlf,micbias-cfg: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + description: + Default register values for R6/R7 (Mic Bias Control). + default: [0, 0] + + wlf,drc-cfg-names: + $ref: /schemas/types.yaml#/definitions/string-array + description: + List of strings for the available DRC modes. + If absent, DRC is disabled. + + wlf,drc-cfg-regs: + $ref: /schemas/types.yaml#/definitions/uint16-matrix + description: + Sets of default register values for R40/41/42/43 (DRC). + Each set corresponds to a DRC mode, so the number of sets should equal + the length of wlf,drc-cfg-names. + If absent, DRC is disabled. + items: + minItems: 4 + maxItems: 4 + + wlf,retune-mobile-cfg-names: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + List of strings for the available retune modes. + If absent, retune is disabled. + + wlf,retune-mobile-cfg-hz: + description: + The list must be the same length as wlf,retune-mobile-cfg-names. + If absent, retune is disabled. + + wlf,retune-mobile-cfg-regs: + $ref: /schemas/types.yaml#/definitions/uint16-matrix + description: + Sets of default register values for R134/.../157 (EQ). + Each set corresponds to a retune mode, so the number of sets should equal + the length of wlf,retune-mobile-cfg-names. + If absent, retune is disabled. + items: + minItems: 24 + maxItems: 24 + +dependencies: + wlf,drc-cfg-names: [ 'wlf,drc-cfg-regs' ] + wlf,drc-cfg-regs: [ 'wlf,drc-cfg-names' ] + + wlf,retune-mobile-cfg-names: [ 'wlf,retune-mobile-cfg-hz', 'wlf,retune-mobile-cfg-regs' ] + wlf,retune-mobile-cfg-regs: [ 'wlf,retune-mobile-cfg-names', 'wlf,retune-mobile-cfg-hz' ] + wlf,retune-mobile-cfg-hz: [ 'wlf,retune-mobile-cfg-names', 'wlf,retune-mobile-cfg-regs' ] + required: - compatible - reg @@ -70,5 +146,58 @@ examples: DBVDD-supply = <®_1p8v>; DCVDD-supply = <®_1p8v>; MICVDD-supply = <®_1p8v>; + + wlf,drc-cfg-names = "default", "peaklimiter", "tradition", "soft", + "music"; + /* + * Config registers per name, respectively: + * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1 + * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1 + * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1 + * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1 + * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1 + */ + wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>, + /bits/ 16 <0x04af 0x324b 0x0010 0x0408>, + /bits/ 16 <0x04af 0x324b 0x0028 0x0704>, + /bits/ 16 <0x04af 0x324b 0x0018 0x078c>, + /bits/ 16 <0x04af 0x324b 0x0010 0x050e>; + + /* GPIO1 = DMIC_CLK, don't touch others */ + wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>; + + /* Use IN1R as DMICDAT2, leave IN1L as an analog input path */ + wlf,in1r-as-dmicdat2; + + wlf,retune-mobile-cfg-names = "bassboost", "bassboost", "treble"; + wlf,retune-mobile-cfg-hz = <48000>, <44100>, <48000>; + /* + * Config registers per name, respectively: + * EQ_ENA, 100 Hz, 300 Hz, 875 Hz, 2400 Hz, 6900 Hz + * 1, +6 dB, +3 dB, 0 dB, 0 dB, 0 dB + * 1, +6 dB, +3 dB, 0 dB, 0 dB, 0 dB + * 1, -2 dB, -2 dB, 0 dB, 0 dB, +3 dB + * Each one uses the defaults for ReTune Mobile registers 140-157 + */ + wlf,retune-mobile-cfg-regs = /bits/ 16 <0x1 0x12 0xf 0xc 0xc 0xc + 0x0fca 0x0400 0x00d8 0x1eb5 + 0xf145 0x0bd5 0x0075 0x1c58 + 0xf3d3 0x0a54 0x0568 0x168e + 0xf829 0x07ad 0x1103 0x0564 + 0x0559 0x4000>, + + /bits/ 16 <0x1 0x12 0xf 0xc 0xc 0xc + 0x0fca 0x0400 0x00d8 0x1eb5 + 0xf145 0x0bd5 0x0075 0x1c58 + 0xf3d3 0x0a54 0x0568 0x168e + 0xf829 0x07ad 0x1103 0x0564 + 0x0559 0x4000>, + + /bits/ 16 <0x1 0xa 0xa 0xc 0xc 0xf + 0x0fca 0x0400 0x00d8 0x1eb5 + 0xf145 0x0bd5 0x0075 0x1c58 + 0xf3d3 0x0a54 0x0568 0x168e + 0xf829 0x07ad 0x1103 0x0564 + 0x0559 0x4000>; }; }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml index 62e62c335d07..3c2b9790ffcf 100644 --- a/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml +++ b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml @@ -75,6 +75,10 @@ properties: enable DACLRC pin. If shared-lrclk is present, no need to enable DAC for captrue. + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt b/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt deleted file mode 100644 index cbc93c8f4963..000000000000 --- a/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt +++ /dev/null @@ -1,29 +0,0 @@ -Device-Tree bindings for Xilinx PL audio formatter - -The IP core supports DMA, data formatting(AES<->PCM conversion) -of audio samples. - -Required properties: - - compatible: "xlnx,audio-formatter-1.0" - - interrupt-names: Names specified to list of interrupts in same - order mentioned under "interrupts". - List of supported interrupt names are: - "irq_mm2s" : interrupt from MM2S block - "irq_s2mm" : interrupt from S2MM block - - interrupts-parent: Phandle for interrupt controller. - - interrupts: List of Interrupt numbers. - - reg: Base address and size of the IP core instance. - - clock-names: List of input clocks. - Required elements: "s_axi_lite_aclk", "aud_mclk" - - clocks: Input clock specifier. Refer to common clock bindings. - -Example: - audio_ss_0_audio_formatter_0: audio_formatter@80010000 { - compatible = "xlnx,audio-formatter-1.0"; - interrupt-names = "irq_mm2s", "irq_s2mm"; - interrupt-parent = <&gic>; - interrupts = <0 104 4>, <0 105 4>; - reg = <0x0 0x80010000 0x0 0x1000>; - clock-names = "s_axi_lite_aclk", "aud_mclk"; - clocks = <&clk 71>, <&clk_wiz_1 0>; - }; diff --git a/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.yaml b/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.yaml new file mode 100644 index 000000000000..82fa448bd2e9 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/xlnx,audio-formatter.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx PL audio formatter + +description: + The IP core supports DMA, data formatting(AES<->PCM conversion) + of audio samples. + +maintainers: + - Vincenzo Frascino <vincenzo.frascino@arm.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - xlnx,audio-formatter-1.0 + + reg: + maxItems: 1 + + interrupt-names: + minItems: 1 + items: + - const: irq_mm2s + - const: irq_s2mm + + interrupts: + minItems: 1 + items: + - description: interrupt from MM2S block + - description: interrupt from S2MM block + + clock-names: + minItems: 1 + items: + - const: s_axi_lite_aclk + - const: aud_mclk + + clocks: + minItems: 1 + items: + - description: clock for the axi data stream + - description: clock for the MEMS microphone data stream + +required: + - compatible + - reg + - interrupt-names + - interrupts + - clock-names + - clocks + +additionalProperties: false + +examples: + - | + audio_formatter@80010000 { + compatible = "xlnx,audio-formatter-1.0"; + reg = <0x80010000 0x1000>; + interrupt-names = "irq_mm2s", "irq_s2mm"; + interrupt-parent = <&gic>; + interrupts = <0 104 4>, <0 105 4>; + clock-names = "s_axi_lite_aclk", "aud_mclk"; + clocks = <&clk 71>, <&clk_wiz_1 0>; + }; +... diff --git a/Documentation/devicetree/bindings/sound/xlnx,i2s.txt b/Documentation/devicetree/bindings/sound/xlnx,i2s.txt deleted file mode 100644 index 5e7c7d5bb60a..000000000000 --- a/Documentation/devicetree/bindings/sound/xlnx,i2s.txt +++ /dev/null @@ -1,28 +0,0 @@ -Device-Tree bindings for Xilinx I2S PL block - -The IP supports I2S based playback/capture audio - -Required property: - - compatible: "xlnx,i2s-transmitter-1.0" for playback and - "xlnx,i2s-receiver-1.0" for capture - -Required property common to both I2S playback and capture: - - reg: Base address and size of the IP core instance. - - xlnx,dwidth: sample data width. Can be any of 16, 24. - - xlnx,num-channels: Number of I2S streams. Can be any of 1, 2, 3, 4. - supported channels = 2 * xlnx,num-channels - -Example: - - i2s_receiver@a0080000 { - compatible = "xlnx,i2s-receiver-1.0"; - reg = <0x0 0xa0080000 0x0 0x10000>; - xlnx,dwidth = <0x18>; - xlnx,num-channels = <1>; - }; - i2s_transmitter@a0090000 { - compatible = "xlnx,i2s-transmitter-1.0"; - reg = <0x0 0xa0090000 0x0 0x10000>; - xlnx,dwidth = <0x18>; - xlnx,num-channels = <1>; - }; diff --git a/Documentation/devicetree/bindings/sound/xlnx,i2s.yaml b/Documentation/devicetree/bindings/sound/xlnx,i2s.yaml new file mode 100644 index 000000000000..3c2b0be07c53 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/xlnx,i2s.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/xlnx,i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx I2S PL block + +description: + The IP supports I2S based playback/capture audio. + +maintainers: + - Vincenzo Frascino <vincenzo.frascino@arm.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - xlnx,i2s-receiver-1.0 + - xlnx,i2s-transmitter-1.0 + + reg: + maxItems: 1 + + xlnx,dwidth: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 16 + - 24 + description: | + Sample data width. + + xlnx,num-channels: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 4 + description: | + Number of I2S streams. + +required: + - compatible + - reg + - xlnx,dwidth + - xlnx,num-channels + +additionalProperties: false + +examples: + - | + i2s@a0080000 { + compatible = "xlnx,i2s-receiver-1.0"; + reg = <0xa0080000 0x10000>; + xlnx,dwidth = <0x18>; + xlnx,num-channels = <1>; + }; + i2s@a0090000 { + compatible = "xlnx,i2s-transmitter-1.0"; + reg = <0xa0090000 0x10000>; + xlnx,dwidth = <0x18>; + xlnx,num-channels = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/xlnx,spdif.txt b/Documentation/devicetree/bindings/sound/xlnx,spdif.txt deleted file mode 100644 index 15c2d64d247c..000000000000 --- a/Documentation/devicetree/bindings/sound/xlnx,spdif.txt +++ /dev/null @@ -1,28 +0,0 @@ -Device-Tree bindings for Xilinx SPDIF IP - -The IP supports playback and capture of SPDIF audio - -Required properties: - - compatible: "xlnx,spdif-2.0" - - clock-names: List of input clocks. - Required elements: "s_axi_aclk", "aud_clk_i" - - clocks: Input clock specifier. Refer to common clock bindings. - - reg: Base address and address length of the IP core instance. - - interrupts-parent: Phandle for interrupt controller. - - interrupts: List of Interrupt numbers. - - xlnx,spdif-mode: 0 :- receiver mode - 1 :- transmitter mode - - xlnx,aud_clk_i: input audio clock value. - -Example: - spdif_0: spdif@80010000 { - clock-names = "aud_clk_i", "s_axi_aclk"; - clocks = <&misc_clk_0>, <&clk 71>; - compatible = "xlnx,spdif-2.0"; - interrupt-names = "spdif_interrupt"; - interrupt-parent = <&gic>; - interrupts = <0 91 4>; - reg = <0x0 0x80010000 0x0 0x10000>; - xlnx,spdif-mode = <1>; - xlnx,aud_clk_i = <49152913>; - }; diff --git a/Documentation/devicetree/bindings/sound/xlnx,spdif.yaml b/Documentation/devicetree/bindings/sound/xlnx,spdif.yaml new file mode 100644 index 000000000000..a45d8a0755fe --- /dev/null +++ b/Documentation/devicetree/bindings/sound/xlnx,spdif.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/xlnx,spdif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx SPDIF IP + +description: + The IP supports playback and capture of SPDIF audio. + +maintainers: + - Vincenzo Frascino <vincenzo.frascino@arm.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - xlnx,spdif-2.0 + + reg: + maxItems: 1 + + interrupts: + items: + - description: SPDIF audio interrupt + + clock-names: + items: + - const: aud_clk_i + - const: s_axi_aclk + + clocks: + minItems: 1 + items: + - description: input audio clock + - description: clock for the AXI data stream + + xlnx,spdif-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 + - 1 + description: | + 0 - receiver + 1 - transmitter + + xlnx,aud_clk_i: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Input audio clock frequency. It affects the sampling rate. + +required: + - compatible + - reg + - interrupts + - clock-names + - clocks + +additionalProperties: false + +examples: + - | + spdif@80010000 { + compatible = "xlnx,spdif-2.0"; + reg = <0x80010000 0x10000>; + clock-names = "aud_clk_i", "s_axi_aclk"; + clocks = <&misc_clk_0>, <&clk 71>; + interrupt-parent = <&gic>; + interrupts = <0 91 4>; + xlnx,spdif-mode = <1>; + xlnx,aud_clk_i = <49152913>; + }; + +... diff --git a/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml b/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml index d48faa42d025..4b3828eda6cb 100644 --- a/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml +++ b/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml @@ -41,6 +41,26 @@ properties: - const: s_axi_aclk - const: spi_clk + trigger-sources: + description: + An array of trigger source phandles for offload instances. The index in + the array corresponds to the offload instance number. + minItems: 1 + maxItems: 32 + + dmas: + description: + DMA channels connected to the input or output stream interface of an + offload instance. + minItems: 1 + maxItems: 32 + + dma-names: + items: + pattern: "^offload(?:[12]?[0-9]|3[01])-[tr]x$" + minItems: 1 + maxItems: 32 + required: - compatible - reg @@ -59,6 +79,10 @@ examples: clocks = <&clkc 15>, <&clkc 15>; clock-names = "s_axi_aclk", "spi_clk"; + trigger-sources = <&trigger_clock>; + dmas = <&dma 0>; + dma-names = "offload0-rx"; + #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml index d48ecd6cd5ad..53a52fb8b819 100644 --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Cadence Quad SPI controller +title: Cadence Quad/Octal SPI controller maintainers: - Vaishnav Achath <vaishnav.a@ti.com> @@ -68,6 +68,7 @@ properties: - items: - enum: - amd,pensando-elba-qspi + - amd,versal2-ospi - intel,lgm-qspi - intel,socfpga-qspi - mobileye,eyeq5-ospi @@ -75,8 +76,12 @@ properties: - ti,am654-ospi - ti,k2g-qspi - xlnx,versal-ospi-1.0 + # The compatible is qspi-nor for historical reasons but such + # controllers are meant to be used with flashes of all kinds, + # ie. also NAND flashes, not only NOR flashes. - const: cdns,qspi-nor - const: cdns,qspi-nor + deprecated: true reg: items: @@ -141,6 +146,18 @@ properties: items: enum: [ qspi, qspi-ocp, rstc_ref ] +patternProperties: + "^flash@[0-9a-f]+$": + type: object + $ref: cdns,qspi-nor-peripheral-props.yaml + additionalProperties: true + required: + - cdns,read-delay + - cdns,tshsl-ns + - cdns,tsd2d-ns + - cdns,tchsh-ns + - cdns,tslch-ns + required: - compatible - reg @@ -156,7 +173,7 @@ unevaluatedProperties: false examples: - | qspi: spi@ff705000 { - compatible = "cdns,qspi-nor"; + compatible = "intel,socfpga-qspi", "cdns,qspi-nor"; #address-cells = <1>; #size-cells = <0>; reg = <0xff705000 0x1000>, @@ -172,5 +189,10 @@ examples: flash@0 { compatible = "jedec,spi-nor"; reg = <0x0>; + cdns,read-delay = <4>; + cdns,tshsl-ns = <60>; + cdns,tsd2d-ns = <60>; + cdns,tchsh-ns = <60>; + cdns,tslch-ns = <60>; }; }; diff --git a/Documentation/devicetree/bindings/spi/fsl,espi.yaml b/Documentation/devicetree/bindings/spi/fsl,espi.yaml new file mode 100644 index 000000000000..d267bbfaf02f --- /dev/null +++ b/Documentation/devicetree/bindings/spi/fsl,espi.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/fsl,espi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale eSPI (Enhanced Serial Peripheral Interface) controller + +maintainers: + - J. Neuschäfer <j.ne@posteo.net> + +properties: + compatible: + const: fsl,mpc8536-espi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + fsl,espi-num-chipselects: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 4 ] + description: The number of the chipselect signals. + + fsl,csbef: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Chip select assertion time in bits before frame starts + + fsl,csaft: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Chip select negation time in bits after frame ends + +required: + - compatible + - reg + - interrupts + - fsl,espi-num-chipselects + +allOf: + - $ref: spi-controller.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + spi@110000 { + compatible = "fsl,mpc8536-espi"; + reg = <0x110000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <53 IRQ_TYPE_EDGE_FALLING>; + fsl,espi-num-chipselects = <4>; + fsl,csbef = <1>; + fsl,csaft = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/spi/fsl,spi.yaml b/Documentation/devicetree/bindings/spi/fsl,spi.yaml new file mode 100644 index 000000000000..d74792fc9bf2 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/fsl,spi.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/fsl,spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale SPI (Serial Peripheral Interface) controller + +maintainers: + - J. Neuschäfer <j.ne@posteo.net> + +properties: + compatible: + enum: + - fsl,spi + - aeroflexgaisler,spictrl + + reg: + maxItems: 1 + + cell-index: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + QE SPI subblock index. + 0: QE subblock SPI1 + 1: QE subblock SPI2 + + mode: + description: SPI operation mode + enum: + - cpu + - cpu-qe + + interrupts: + maxItems: 1 + + clock-frequency: + description: input clock frequency to non FSL_SOC cores + + cs-gpios: true + + fsl,spisel_boot: + $ref: /schemas/types.yaml#/definitions/flag + description: + For the MPC8306 and MPC8309, specifies that the SPISEL_BOOT signal is used + as chip select for a slave device. Use reg = <number of gpios> in the + corresponding child node, i.e. 0 if the cs-gpios property is not present. + +required: + - compatible + - reg + - mode + - interrupts + +allOf: + - $ref: spi-controller.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + spi@4c0 { + compatible = "fsl,spi"; + reg = <0x4c0 0x40>; + cell-index = <0>; + interrupts = <82 0>; + mode = "cpu"; + cs-gpios = <&gpio 18 IRQ_TYPE_EDGE_RISING // device reg=<0> + &gpio 19 IRQ_TYPE_EDGE_RISING>; // device reg=<1> + }; + +... diff --git a/Documentation/devicetree/bindings/spi/fsl-spi.txt b/Documentation/devicetree/bindings/spi/fsl-spi.txt deleted file mode 100644 index 0654380eb751..000000000000 --- a/Documentation/devicetree/bindings/spi/fsl-spi.txt +++ /dev/null @@ -1,62 +0,0 @@ -* SPI (Serial Peripheral Interface) - -Required properties: -- cell-index : QE SPI subblock index. - 0: QE subblock SPI1 - 1: QE subblock SPI2 -- compatible : should be "fsl,spi" or "aeroflexgaisler,spictrl". -- mode : the SPI operation mode, it can be "cpu" or "cpu-qe". -- reg : Offset and length of the register set for the device -- interrupts : <a b> where a is the interrupt number and b is a - field that represents an encoding of the sense and level - information for the interrupt. This should be encoded based on - the information in section 2) depending on the type of interrupt - controller you have. -- clock-frequency : input clock frequency to non FSL_SOC cores - -Optional properties: -- cs-gpios : specifies the gpio pins to be used for chipselects. - The gpios will be referred to as reg = <index> in the SPI child nodes. - If unspecified, a single SPI device without a chip select can be used. -- fsl,spisel_boot : for the MPC8306 and MPC8309, specifies that the - SPISEL_BOOT signal is used as chip select for a slave device. Use - reg = <number of gpios> in the corresponding child node, i.e. 0 if - the cs-gpios property is not present. - -Example: - spi@4c0 { - cell-index = <0>; - compatible = "fsl,spi"; - reg = <4c0 40>; - interrupts = <82 0>; - interrupt-parent = <700>; - mode = "cpu"; - cs-gpios = <&gpio 18 1 // device reg=<0> - &gpio 19 1>; // device reg=<1> - }; - - -* eSPI (Enhanced Serial Peripheral Interface) - -Required properties: -- compatible : should be "fsl,mpc8536-espi". -- reg : Offset and length of the register set for the device. -- interrupts : should contain eSPI interrupt, the device has one interrupt. -- fsl,espi-num-chipselects : the number of the chipselect signals. - -Optional properties: -- fsl,csbef: chip select assertion time in bits before frame starts -- fsl,csaft: chip select negation time in bits after frame ends - -Example: - spi@110000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,mpc8536-espi"; - reg = <0x110000 0x1000>; - interrupts = <53 0x2>; - interrupt-parent = <&mpic>; - fsl,espi-num-chipselects = <4>; - fsl,csbef = <1>; - fsl,csaft = <1>; - }; diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml index e1f5bfa4433c..ed17815263a8 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml @@ -35,6 +35,8 @@ properties: - enum: - mediatek,mt7981-spi-ipm - mediatek,mt7986-spi-ipm + - mediatek,mt7988-spi-quad + - mediatek,mt7988-spi-single - mediatek,mt8188-spi-ipm - const: mediatek,spi-ipm - items: diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qpic-snand.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qpic-snand.yaml new file mode 100644 index 000000000000..aa3f93319203 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qpic-snand.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/qcom,spi-qpic-snand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm QPIC NAND controller + +maintainers: + - Md sadre Alam <quic_mdalam@quicinc.com> + +description: + The QCOM QPIC-SPI-NAND flash controller is an extended version of + the QCOM QPIC NAND flash controller. It can work both in serial + and parallel mode. It supports typical SPI-NAND page cache + operations in single, dual or quad IO mode with pipelined ECC + encoding/decoding using the QPIC ECC HW engine. + +allOf: + - $ref: /schemas/spi/spi-controller.yaml# + +properties: + compatible: + enum: + - qcom,ipq9574-snand + + reg: + maxItems: 1 + + clocks: + maxItems: 3 + + clock-names: + items: + - const: core + - const: aon + - const: iom + + dmas: + items: + - description: tx DMA channel + - description: rx DMA channel + - description: cmd DMA channel + + dma-names: + items: + - const: tx + - const: rx + - const: cmd + +required: + - compatible + - reg + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,ipq9574-gcc.h> + spi@79b0000 { + compatible = "qcom,ipq9574-snand"; + reg = <0x1ac00000 0x800>; + + clocks = <&gcc GCC_QPIC_CLK>, + <&gcc GCC_QPIC_AHB_CLK>, + <&gcc GCC_QPIC_IO_MACRO_CLK>; + clock-names = "core", "aon", "iom"; + + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "spi-nand"; + reg = <0>; + #address-cells = <1>; + #size-cells = <1>; + nand-ecc-engine = <&qpic_nand>; + nand-ecc-strength = <4>; + nand-ecc-step-size = <512>; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 093150c0cb87..82d051f7bd6e 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -69,6 +69,11 @@ properties: Should be generally avoided and be replaced by spi-cs-high + ACTIVE_HIGH. + The simplest way to obtain an active-high CS signal is to configure the + controller's cs-gpio property with the ACTIVE_HIGH flag and set the + peripheral's spi-cs-high property. See example below for a better + understanding. + fifo-depth: $ref: /schemas/types.yaml#/definitions/uint32 description: @@ -189,3 +194,23 @@ examples: stacked-memories = /bits/ 64 <0x10000000 0x10000000>; }; }; + + - | + #include <dt-bindings/gpio/gpio.h> + + spi@20204000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "brcm,bcm2835-spi"; + reg = <0x7e204000 0x1000>; + interrupts = <2 22>; + clocks = <&clk_spi>; + cs-gpios = <&gpio 8 GPIO_ACTIVE_HIGH>; + + display@0 { + compatible = "lg,lg4573"; + spi-max-frequency = <1000000>; + reg = <0>; + spi-cs-high; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml index ed1d4aa41b8c..a65a42ccaafe 100644 --- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml @@ -24,6 +24,7 @@ properties: - enum: - fsl,imx8ulp-spi - fsl,imx93-spi + - fsl,imx94-spi - fsl,imx95-spi - const: fsl,imx7ulp-spi reg: diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml index 46d9d6ee0923..104f5ffdd04e 100644 --- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml +++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml @@ -34,6 +34,7 @@ properties: - rockchip,rk3328-spi - rockchip,rk3368-spi - rockchip,rk3399-spi + - rockchip,rk3562-spi - rockchip,rk3568-spi - rockchip,rk3576-spi - rockchip,rk3588-spi diff --git a/Documentation/devicetree/bindings/spi/spi-sg2044-nor.yaml b/Documentation/devicetree/bindings/spi/spi-sg2044-nor.yaml new file mode 100644 index 000000000000..948ff7a09643 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-sg2044-nor.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-sg2044-nor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SG2044 SPI NOR controller + +maintainers: + - Longbin Li <looong.bin@gmail.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + const: sophgo,sg2044-spifmc-nor + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + spi@1000000 { + compatible = "sophgo,sg2044-spifmc-nor"; + reg = <0x1000000 0x4000000>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&clk 0>; + interrupts = <37 IRQ_TYPE_LEVEL_HIGH>; + resets = <&rst 0>; + }; diff --git a/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml new file mode 100644 index 000000000000..5f276f27dc4c --- /dev/null +++ b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/st,stm32mp25-ospi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STM32 Octal Serial Peripheral Interface (OSPI) + +maintainers: + - Patrice Chotard <patrice.chotard@foss.st.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + const: st,stm32mp25-ospi + + reg: + maxItems: 1 + + memory-region: + description: + Memory region to be used for memory-map read access. + In memory-mapped mode, read access are performed from the memory + device using the direct mapping. + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + resets: + items: + - description: phandle to OSPI block reset + - description: phandle to delay block reset + + dmas: + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + st,syscfg-dlyb: + description: configure OCTOSPI delay block. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - description: phandle to syscfg + - description: register offset within syscfg + + access-controllers: + description: phandle to the rifsc device to check access right + and in some cases, an additional phandle to the rcc device for + secure clock control. + items: + - description: phandle to bus controller + - description: phandle to clock controller + minItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + - st,syscfg-dlyb + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/st,stm32mp25-rcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/reset/st,stm32mp25-rcc.h> + + spi@40430000 { + compatible = "st,stm32mp25-ospi"; + reg = <0x40430000 0x400>; + memory-region = <&mm_ospi1>; + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&hpdma 2 0x62 0x00003121 0x0>, + <&hpdma 2 0x42 0x00003112 0x0>; + dma-names = "tx", "rx"; + clocks = <&scmi_clk CK_SCMI_OSPI1>; + resets = <&scmi_reset RST_SCMI_OSPI1>, <&scmi_reset RST_SCMI_OSPI1DLL>; + access-controllers = <&rifsc 74>; + power-domains = <&CLUSTER_PD>; + st,syscfg-dlyb = <&syscfg 0x1000>; + + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + spi-rx-bus-width = <4>; + spi-max-frequency = <108000000>; + }; + }; diff --git a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml index d9322704f358..a7236f7db4ec 100644 --- a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml +++ b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml @@ -47,7 +47,9 @@ properties: - const: allwinner,sun8i-v3s-system-control - const: allwinner,sun8i-h3-system-control - items: - - const: allwinner,sun50i-h6-system-control + - enum: + - allwinner,sun50i-a100-system-control + - allwinner,sun50i-h6-system-control - const: allwinner,sun50i-a64-system-control reg: diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml index 9b06bcd01957..2711f90d9664 100644 --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml @@ -20,6 +20,7 @@ properties: - qcom,apq8064-imem - qcom,msm8226-imem - qcom,msm8974-imem + - qcom,msm8976-imem - qcom,qcs404-imem - qcom,qcs8300-imem - qcom,qdu1000-imem diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index ed5de0f92a9e..b9829bb22cc0 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -80,6 +80,7 @@ properties: - description: v2 of TSENS with combined interrupt items: - enum: + - qcom,ipq6018-tsens - qcom,ipq9574-tsens - const: qcom,ipq8074-tsens diff --git a/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml index 5684df6448ef..eb1127352c7b 100644 --- a/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml +++ b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml @@ -50,7 +50,7 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> timer@2c000600 { - compatible = "arm,arm11mp-twd-timer"; - reg = <0x2c000600 0x20>; - interrupts = <GIC_PPI 13 0xf01>; + compatible = "arm,arm11mp-twd-timer"; + reg = <0x2c000600 0x20>; + interrupts = <GIC_PPI 13 0xf01>; }; diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml index e2607377cbae..9898dc7ea97b 100644 --- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml +++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml @@ -21,6 +21,7 @@ properties: - items: - enum: - fsl,imx25-gpt + - fsl,imx35-gpt - fsl,imx50-gpt - fsl,imx51-gpt - fsl,imx53-gpt @@ -31,6 +32,7 @@ properties: - enum: - fsl,imx6sl-gpt - fsl,imx6sx-gpt + - fsl,imx7d-gpt - fsl,imx8mp-gpt - fsl,imxrt1050-gpt - fsl,imxrt1170-gpt @@ -38,7 +40,6 @@ properties: - items: - enum: - fsl,imx6ul-gpt - - fsl,imx7d-gpt - const: fsl,imx6sx-gpt reg: diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.yaml b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml index 5e09c04da30e..260b05f213e6 100644 --- a/Documentation/devicetree/bindings/timer/renesas,cmt.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml @@ -178,29 +178,29 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/power/r8a7790-sysc.h> cmt0: timer@ffca0000 { - compatible = "renesas,r8a7790-cmt0", "renesas,rcar-gen2-cmt0"; - reg = <0xffca0000 0x1004>; - interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 124>; - clock-names = "fck"; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 124>; + compatible = "renesas,r8a7790-cmt0", "renesas,rcar-gen2-cmt0"; + reg = <0xffca0000 0x1004>; + interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 124>; + clock-names = "fck"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 124>; }; cmt1: timer@e6130000 { - compatible = "renesas,r8a7790-cmt1", "renesas,rcar-gen2-cmt1"; - reg = <0xe6130000 0x1004>; - interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 329>; - clock-names = "fck"; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 329>; + compatible = "renesas,r8a7790-cmt1", "renesas,rcar-gen2-cmt1"; + reg = <0xe6130000 0x1004>; + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 329>; + clock-names = "fck"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 329>; }; diff --git a/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml b/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml index 233d74d5402c..a7385d865bca 100644 --- a/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml @@ -38,9 +38,9 @@ examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> timer@e0180000 { - compatible = "renesas,em-sti"; - reg = <0xe0180000 0x54>; - interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&sti_sclk>; - clock-names = "sclk"; + compatible = "renesas,em-sti"; + reg = <0xe0180000 0x54>; + interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&sti_sclk>; + clock-names = "sclk"; }; diff --git a/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml b/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml index 15d8dddf4ae9..e56c12f03f72 100644 --- a/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml @@ -66,11 +66,11 @@ examples: #include <dt-bindings/clock/r7s72100-clock.h> #include <dt-bindings/interrupt-controller/arm-gic.h> mtu2: timer@fcff0000 { - compatible = "renesas,mtu2-r7s72100", "renesas,mtu2"; - reg = <0xfcff0000 0x400>; - interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "tgi0a"; - clocks = <&mstp3_clks R7S72100_CLK_MTU2>; - clock-names = "fck"; - power-domains = <&cpg_clocks>; + compatible = "renesas,mtu2-r7s72100", "renesas,mtu2"; + reg = <0xfcff0000 0x400>; + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "tgi0a"; + clocks = <&mstp3_clks R7S72100_CLK_MTU2>; + clock-names = "fck"; + power-domains = <&cpg_clocks>; }; diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml index e8c642166462..9ba858f094ab 100644 --- a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml @@ -71,9 +71,9 @@ examples: #include <dt-bindings/clock/r7s72100-clock.h> #include <dt-bindings/interrupt-controller/arm-gic.h> ostm0: timer@fcfec000 { - compatible = "renesas,r7s72100-ostm", "renesas,ostm"; - reg = <0xfcfec000 0x30>; - interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING>; - clocks = <&mstp5_clks R7S72100_CLK_OSTM0>; - power-domains = <&cpg_clocks>; + compatible = "renesas,r7s72100-ostm", "renesas,ostm"; + reg = <0xfcfec000 0x30>; + interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING>; + clocks = <&mstp5_clks R7S72100_CLK_OSTM0>; + power-domains = <&cpg_clocks>; }; diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml index 75b0e7c70b62..b1229595acfb 100644 --- a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml @@ -122,15 +122,15 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/power/r8a7779-sysc.h> tmu0: timer@ffd80000 { - compatible = "renesas,tmu-r8a7779", "renesas,tmu"; - reg = <0xffd80000 0x30>; - interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "tuni0", "tuni1", "tuni2", "ticpi2"; - clocks = <&mstp0_clks R8A7779_CLK_TMU0>; - clock-names = "fck"; - power-domains = <&sysc R8A7779_PD_ALWAYS_ON>; - #renesas,channels = <3>; + compatible = "renesas,tmu-r8a7779", "renesas,tmu"; + reg = <0xffd80000 0x30>; + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "tuni0", "tuni1", "tuni2", "ticpi2"; + clocks = <&mstp0_clks R8A7779_CLK_TMU0>; + clock-names = "fck"; + power-domains = <&sysc R8A7779_PD_ALWAYS_ON>; + #renesas,channels = <3>; }; diff --git a/Documentation/devicetree/bindings/timer/renesas,tpu.yaml b/Documentation/devicetree/bindings/timer/renesas,tpu.yaml index 01554dff23d8..7a473b302775 100644 --- a/Documentation/devicetree/bindings/timer/renesas,tpu.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,tpu.yaml @@ -49,8 +49,8 @@ additionalProperties: false examples: - | tpu: tpu@ffffe0 { - compatible = "renesas,tpu"; - reg = <0xffffe0 16>, <0xfffff0 12>; - clocks = <&pclk>; - clock-names = "fck"; + compatible = "renesas,tpu"; + reg = <0xffffe0 16>, <0xfffff0 12>; + clocks = <&pclk>; + clock-names = "fck"; }; diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml index 02d1c355808e..10578f544581 100644 --- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml @@ -27,6 +27,7 @@ properties: - enum: - axis,artpec8-mct - google,gs101-mct + - samsung,exynos2200-mct-peris - samsung,exynos3250-mct - samsung,exynos5250-mct - samsung,exynos5260-mct @@ -34,6 +35,7 @@ properties: - samsung,exynos5433-mct - samsung,exynos850-mct - samsung,exynos8895-mct + - samsung,exynos990-mct - tesla,fsd-mct - const: samsung,exynos4210-mct @@ -130,11 +132,13 @@ allOf: enum: - axis,artpec8-mct - google,gs101-mct + - samsung,exynos2200-mct-peris - samsung,exynos5260-mct - samsung,exynos5420-mct - samsung,exynos5433-mct - samsung,exynos850-mct - samsung,exynos8895-mct + - samsung,exynos990-mct then: properties: interrupts: diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml index b42d43d2de48..653e2e0ca878 100644 --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml @@ -31,11 +31,18 @@ properties: - enum: - canaan,k210-clint # Canaan Kendryte K210 - sifive,fu540-c000-clint # SiFive FU540 + - spacemit,k1-clint # SpacemiT K1 - starfive,jh7100-clint # StarFive JH7100 - starfive,jh7110-clint # StarFive JH7110 - starfive,jh8100-clint # StarFive JH8100 - const: sifive,clint0 # SiFive CLINT v0 IP block - items: + - {} + - const: sifive,clint2 # SiFive CLINT v2 IP block + description: + SiFive CLINT v2 is the HRT that supports the Zicntr. The control of sifive,clint2 + differs from that of sifive,clint0, making them incompatible. + - items: - enum: - allwinner,sun20i-d1-clint - sophgo,cv1800b-clint @@ -61,6 +68,22 @@ properties: minItems: 1 maxItems: 4095 + sifive,fine-ctr-bits: + maximum: 15 + description: The width in bits of the fine counter. + +if: + properties: + compatible: + contains: + const: sifive,clint2 +then: + required: + - sifive,fine-ctr-bits +else: + properties: + sifive,fine-ctr-bits: false + additionalProperties: false required: @@ -76,6 +99,6 @@ examples: <&cpu2intc 3>, <&cpu2intc 7>, <&cpu3intc 3>, <&cpu3intc 7>, <&cpu4intc 3>, <&cpu4intc 7>; - reg = <0x2000000 0x10000>; + reg = <0x2000000 0x10000>; }; ... diff --git a/Documentation/devicetree/bindings/trigger-source/pwm-trigger.yaml b/Documentation/devicetree/bindings/trigger-source/pwm-trigger.yaml new file mode 100644 index 000000000000..1eac20031dc3 --- /dev/null +++ b/Documentation/devicetree/bindings/trigger-source/pwm-trigger.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/trigger-source/pwm-trigger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic trigger source using PWM + +description: Remaps a PWM channel as a trigger source. + +maintainers: + - David Lechner <dlechner@baylibre.com> + +properties: + compatible: + const: pwm-trigger + + '#trigger-source-cells': + const: 0 + + pwms: + maxItems: 1 + +required: + - compatible + - '#trigger-source-cells' + - pwms + +additionalProperties: false + +examples: + - | + trigger { + compatible = "pwm-trigger"; + #trigger-source-cells = <0>; + pwms = <&pwm 0 1000000 0>; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 88abb5c174f3..30e8f89fa032 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -55,8 +55,6 @@ properties: - atmel,atsha204a # BPA-RS600: Power Supply - blutek,bpa-rs600 - # Bosch Sensortec pressure, temperature, humididty and VOC sensor - - bosch,bme680 # CM32181: Ambient Light Sensor - capella,cm32181 # CM3232: Ambient Light Sensor @@ -147,8 +145,12 @@ properties: - injoinic,ip5207 # Injoinic IP5209 2.4A Power Bank IC with I2C - injoinic,ip5209 + # Injoinic IP5306 2.1A Power Bank IC with I2C option + - injoinic,ip5306 # Inspur Power System power supply unit version 1 - inspur,ipsps1 + # Intel common redudant power supply crps185 + - intel,crps185 # Intersil ISL29028 Ambient Light and Proximity Sensor - isil,isl29028 # Intersil ISL29030 Ambient Light and Proximity Sensor @@ -187,6 +189,8 @@ properties: - mcube,mc3230 # Measurement Specialities I2C temperature and humidity sensor - meas,htu21 + # Measurement Specialities I2C temperature and humidity sensor + - meas,htu31 # Measurement Specialities I2C pressure and temperature sensor - meas,ms5637 # Measurement Specialities I2C pressure and temperature sensor diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml index cde334e3206b..a03fff5df5ef 100644 --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml @@ -26,6 +26,7 @@ properties: - qcom,msm8994-ufshc - qcom,msm8996-ufshc - qcom,msm8998-ufshc + - qcom,qcs615-ufshc - qcom,qcs8300-ufshc - qcom,sa8775p-ufshc - qcom,sc7180-ufshc @@ -243,6 +244,7 @@ allOf: compatible: contains: enum: + - qcom,qcs615-ufshc - qcom,sm6115-ufshc - qcom,sm6125-ufshc then: diff --git a/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml b/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml index f04f9f61fa9f..1949a15e73d2 100644 --- a/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml @@ -50,12 +50,12 @@ examples: #include <dt-bindings/power/r8a779f0-sysc.h> ufs: ufs@e686000 { - compatible = "renesas,r8a779f0-ufs"; - reg = <0xe6860000 0x100>; - interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 1514>, <&ufs30_clk>; - clock-names = "fck", "ref_clk"; - freq-table-hz = <200000000 200000000>, <38400000 38400000>; - power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>; - resets = <&cpg 1514>; + compatible = "renesas,r8a779f0-ufs"; + reg = <0xe6860000 0x100>; + interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 1514>, <&ufs30_clk>; + clock-names = "fck", "ref_clk"; + freq-table-hz = <200000000 200000000>, <38400000 38400000>; + power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>; + resets = <&cpg 1514>; }; diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml index 720879820f66..b4e744ebffd1 100644 --- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml @@ -112,19 +112,19 @@ examples: #include <dt-bindings/clock/exynos7-clk.h> ufs: ufs@15570000 { - compatible = "samsung,exynos7-ufs"; - reg = <0x15570000 0x100>, - <0x15570100 0x100>, - <0x15571000 0x200>, - <0x15572000 0x300>; - reg-names = "hci", "vs_hci", "unipro", "ufsp"; - interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clock_fsys1 ACLK_UFS20_LINK>, - <&clock_fsys1 SCLK_UFSUNIPRO20_USER>; - clock-names = "core_clk", "sclk_unipro_main"; - pinctrl-names = "default"; - pinctrl-0 = <&ufs_rst_n &ufs_refclk_out>; - phys = <&ufs_phy>; - phy-names = "ufs-phy"; + compatible = "samsung,exynos7-ufs"; + reg = <0x15570000 0x100>, + <0x15570100 0x100>, + <0x15571000 0x200>, + <0x15572000 0x300>; + reg-names = "hci", "vs_hci", "unipro", "ufsp"; + interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clock_fsys1 ACLK_UFS20_LINK>, + <&clock_fsys1 SCLK_UFSUNIPRO20_USER>; + clock-names = "core_clk", "sclk_unipro_main"; + pinctrl-names = "default"; + pinctrl-0 = <&ufs_rst_n &ufs_refclk_out>; + phys = <&ufs_phy>; + phy-names = "ufs-phy"; }; ... diff --git a/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml b/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml index a86bcd95100e..7f22f9c031b2 100644 --- a/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml +++ b/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml @@ -113,27 +113,27 @@ examples: - | #include <dt-bindings/clock/aspeed-clock.h> vhub: usb-vhub@1e6a0000 { - compatible = "aspeed,ast2500-usb-vhub"; - reg = <0x1e6a0000 0x300>; - interrupts = <5>; - clocks = <&syscon ASPEED_CLK_GATE_USBPORT1CLK>; - aspeed,vhub-downstream-ports = <5>; - aspeed,vhub-generic-endpoints = <15>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_usb2ad_default>; - - vhub-vendor-id = <0x1d6b>; - vhub-product-id = <0x0107>; - vhub-device-revision = <0x0100>; - vhub-strings { - #address-cells = <1>; - #size-cells = <0>; - - string@409 { - reg = <0x409>; - manufacturer = "ASPEED"; - product = "USB Virtual Hub"; - serial-number = "0000"; - }; + compatible = "aspeed,ast2500-usb-vhub"; + reg = <0x1e6a0000 0x300>; + interrupts = <5>; + clocks = <&syscon ASPEED_CLK_GATE_USBPORT1CLK>; + aspeed,vhub-downstream-ports = <5>; + aspeed,vhub-generic-endpoints = <15>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usb2ad_default>; + + vhub-vendor-id = <0x1d6b>; + vhub-product-id = <0x0107>; + vhub-device-revision = <0x0100>; + vhub-strings { + #address-cells = <1>; + #size-cells = <0>; + + string@409 { + reg = <0x409>; + manufacturer = "ASPEED"; + product = "USB Virtual Hub"; + serial-number = "0000"; }; + }; }; diff --git a/Documentation/devicetree/bindings/usb/brcm,bdc.yaml b/Documentation/devicetree/bindings/usb/brcm,bdc.yaml index 9e561fee98f1..f9375c69e86b 100644 --- a/Documentation/devicetree/bindings/usb/brcm,bdc.yaml +++ b/Documentation/devicetree/bindings/usb/brcm,bdc.yaml @@ -41,10 +41,10 @@ additionalProperties: false examples: - | - usb@f0b02000 { - compatible = "brcm,bdc-udc-v2"; - reg = <0xf0b02000 0xfc4>; - interrupts = <0x0 0x60 0x0>; - phys = <&usbphy_0 0x0>; - clocks = <&sw_usbd>; - }; + usb@f0b02000 { + compatible = "brcm,bdc-udc-v2"; + reg = <0xf0b02000 0xfc4>; + interrupts = <0x0 0x60 0x0>; + phys = <&usbphy_0 0x0>; + clocks = <&sw_usbd>; + }; diff --git a/Documentation/devicetree/bindings/usb/cypress,hx3.yaml b/Documentation/devicetree/bindings/usb/cypress,hx3.yaml index e44e88d993d0..1033b7a4b8f9 100644 --- a/Documentation/devicetree/bindings/usb/cypress,hx3.yaml +++ b/Documentation/devicetree/bindings/usb/cypress,hx3.yaml @@ -56,21 +56,21 @@ examples: /* 2.0 hub on port 1 */ hub_2_0: hub@1 { - compatible = "usb4b4,6504"; - reg = <1>; - peer-hub = <&hub_3_0>; - reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; - vdd-supply = <®_1v2_usb>; - vdd2-supply = <®_3v3_usb>; + compatible = "usb4b4,6504"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; + vdd-supply = <®_1v2_usb>; + vdd2-supply = <®_3v3_usb>; }; /* 3.0 hub on port 2 */ hub_3_0: hub@2 { - compatible = "usb4b4,6506"; - reg = <2>; - peer-hub = <&hub_2_0>; - reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; - vdd-supply = <®_1v2_usb>; - vdd2-supply = <®_3v3_usb>; + compatible = "usb4b4,6506"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; + vdd-supply = <®_1v2_usb>; + vdd2-supply = <®_3v3_usb>; }; }; diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index a5f2e3442a0e..e83d30a91b88 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -192,7 +192,7 @@ unevaluatedProperties: false examples: - | - usb@101c0000 { + usb@101c0000 { compatible = "rockchip,rk3066-usb", "snps,dwc2"; reg = <0x10180000 0x40000>; interrupts = <18>; @@ -200,6 +200,6 @@ examples: clock-names = "otg"; phys = <&usbphy>; phy-names = "usb2-phy"; - }; + }; ... diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml index 8b25b9a01ced..e3a7df91f7f1 100644 --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml @@ -87,21 +87,21 @@ examples: #size-cells = <0>; typec-mux@42 { - compatible = "fcs,fsa4480"; - reg = <0x42>; + compatible = "fcs,fsa4480"; + reg = <0x42>; - interrupts-extended = <&tlmm 2 IRQ_TYPE_LEVEL_LOW>; + interrupts-extended = <&tlmm 2 IRQ_TYPE_LEVEL_LOW>; - vcc-supply = <&vreg_bob>; + vcc-supply = <&vreg_bob>; - mode-switch; - orientation-switch; + mode-switch; + orientation-switch; - port { - fsa4480_ept: endpoint { - remote-endpoint = <&typec_controller>; + port { + fsa4480_ept: endpoint { + remote-endpoint = <&typec_controller>; + }; }; - }; }; }; ... diff --git a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml index 8a5f837eff94..e588514fab2d 100644 --- a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml +++ b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml @@ -20,6 +20,7 @@ properties: items: - enum: - nxp,cbdtu02043 + - onnn,fsusb42 - onnn,fsusb43l10x - pericom,pi3usb102 - ti,tmuxhs4212 diff --git a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml index d3511f48cd55..1a75544a8c31 100644 --- a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml @@ -58,20 +58,20 @@ examples: #define KEEM_BAY_A53_AUX_USB_SUSPEND usb { - compatible = "intel,keembay-dwc3"; - clocks = <&scmi_clk KEEM_BAY_A53_AUX_USB>, - <&scmi_clk KEEM_BAY_A53_AUX_USB_REF>, - <&scmi_clk KEEM_BAY_A53_AUX_USB_ALT_REF>, - <&scmi_clk KEEM_BAY_A53_AUX_USB_SUSPEND>; - clock-names = "async_master", "ref", "alt_ref", "suspend"; - ranges; - #address-cells = <1>; - #size-cells = <1>; - - usb@34000000 { - compatible = "snps,dwc3"; - reg = <0x34000000 0x10000>; - interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>; - dr_mode = "peripheral"; - }; + compatible = "intel,keembay-dwc3"; + clocks = <&scmi_clk KEEM_BAY_A53_AUX_USB>, + <&scmi_clk KEEM_BAY_A53_AUX_USB_REF>, + <&scmi_clk KEEM_BAY_A53_AUX_USB_ALT_REF>, + <&scmi_clk KEEM_BAY_A53_AUX_USB_SUSPEND>; + clock-names = "async_master", "ref", "alt_ref", "suspend"; + ranges; + #address-cells = <1>; + #size-cells = <1>; + + usb@34000000 { + compatible = "snps,dwc3"; + reg = <0x34000000 0x10000>; + interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>; + dr_mode = "peripheral"; + }; }; diff --git a/Documentation/devicetree/bindings/usb/ite,it5205.yaml b/Documentation/devicetree/bindings/usb/ite,it5205.yaml index 36ec4251b5f2..889710733de5 100644 --- a/Documentation/devicetree/bindings/usb/ite,it5205.yaml +++ b/Documentation/devicetree/bindings/usb/ite,it5205.yaml @@ -54,19 +54,19 @@ examples: #size-cells = <0>; typec-mux@48 { - compatible = "ite,it5205"; - reg = <0x48>; + compatible = "ite,it5205"; + reg = <0x48>; - mode-switch; - orientation-switch; + mode-switch; + orientation-switch; - vcc-supply = <&mt6359_vibr_ldo_reg>; + vcc-supply = <&mt6359_vibr_ldo_reg>; - port { - it5205_usbss_sbu: endpoint { - remote-endpoint = <&typec_controller>; + port { + it5205_usbss_sbu: endpoint { + remote-endpoint = <&typec_controller>; + }; }; - }; }; }; ... diff --git a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml index 20b62228371b..3de4dc40b791 100644 --- a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml +++ b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml @@ -13,8 +13,12 @@ description: Maxim TCPCI Type-C PD controller properties: compatible: - enum: - - maxim,max33359 + oneOf: + - enum: + - maxim,max33359 + - items: + - const: maxim,max77759-tcpci + - const: maxim,max33359 reg: maxItems: 1 @@ -70,6 +74,7 @@ examples: PDO_FIXED_DUAL_ROLE) PDO_FIXED(9000, 2000, 0)>; sink-bc12-completion-time-ms = <500>; + pd-revision = /bits/ 8 <0x03 0x01 0x01 0x08>; }; }; }; diff --git a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml index 8e0f4ecc010d..6edb1fc5044e 100644 --- a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml +++ b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml @@ -50,18 +50,18 @@ additionalProperties: false examples: - | - #include <dt-bindings/gpio/gpio.h> - #include <dt-bindings/interrupt-controller/irq.h> - spi { - #address-cells = <1>; - #size-cells = <0>; + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; - udc@0 { - compatible = "maxim,max3420-udc"; - reg = <0>; - interrupt-parent = <&gpio>; - interrupts = <0 IRQ_TYPE_EDGE_FALLING>, <10 IRQ_TYPE_EDGE_BOTH>; - interrupt-names = "udc", "vbus"; - spi-max-frequency = <12500000>; - }; - }; + udc@0 { + compatible = "maxim,max3420-udc"; + reg = <0>; + interrupt-parent = <&gpio>; + interrupts = <0 IRQ_TYPE_EDGE_FALLING>, <10 IRQ_TYPE_EDGE_BOTH>; + interrupt-names = "udc", "vbus"; + spi-max-frequency = <12500000>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra210-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra210-xusb.yaml index 90296613b3a5..c0e313c70bba 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra210-xusb.yaml +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra210-xusb.yaml @@ -189,7 +189,7 @@ examples: #size-cells = <0>; ethernet@1 { - compatible = "usb955,9ff"; - reg = <1>; + compatible = "usb955,9ff"; + reg = <1>; }; }; diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index 935e204b607b..a2b3cf625e5b 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -16,6 +16,7 @@ properties: - qcom,ipq4019-dwc3 - qcom,ipq5018-dwc3 - qcom,ipq5332-dwc3 + - qcom,ipq5424-dwc3 - qcom,ipq6018-dwc3 - qcom,ipq8064-dwc3 - qcom,ipq8074-dwc3 @@ -26,6 +27,7 @@ properties: - qcom,msm8998-dwc3 - qcom,qcm2290-dwc3 - qcom,qcs404-dwc3 + - qcom,qcs615-dwc3 - qcom,qcs8300-dwc3 - qcom,qdu1000-dwc3 - qcom,sa8775p-dwc3 @@ -341,6 +343,7 @@ allOf: contains: enum: - qcom,qcm2290-dwc3 + - qcom,qcs615-dwc3 - qcom,sar2130p-dwc3 - qcom,sc8180x-dwc3 - qcom,sc8180x-dwc3-mp @@ -453,8 +456,10 @@ allOf: then: properties: interrupts: + minItems: 3 maxItems: 4 interrupt-names: + minItems: 3 items: - const: pwr_event - const: dp_hs_phy_irq @@ -469,6 +474,7 @@ allOf: - qcom,ipq4019-dwc3 - qcom,ipq8064-dwc3 - qcom,msm8994-dwc3 + - qcom,qcs615-dwc3 - qcom,qcs8300-dwc3 - qcom,qdu1000-dwc3 - qcom,sa8775p-dwc3 diff --git a/Documentation/devicetree/bindings/usb/renesas,rzv2m-usb3drd.yaml b/Documentation/devicetree/bindings/usb/renesas,rzv2m-usb3drd.yaml index ff625600d9af..b87e139c29e5 100644 --- a/Documentation/devicetree/bindings/usb/renesas,rzv2m-usb3drd.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,rzv2m-usb3drd.yaml @@ -104,26 +104,26 @@ examples: #size-cells = <1>; usb3host: usb@85060000 { - compatible = "renesas,r9a09g011-xhci", - "renesas,rzv2m-xhci"; - reg = <0x85060000 0x2000>; - interrupts = <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD R9A09G011_USB_ACLK_H>, - <&cpg CPG_MOD R9A09G011_USB_PCLK>; - clock-names = "axi", "reg"; - power-domains = <&cpg>; - resets = <&cpg R9A09G011_USB_ARESETN_H>; + compatible = "renesas,r9a09g011-xhci", + "renesas,rzv2m-xhci"; + reg = <0x85060000 0x2000>; + interrupts = <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD R9A09G011_USB_ACLK_H>, + <&cpg CPG_MOD R9A09G011_USB_PCLK>; + clock-names = "axi", "reg"; + power-domains = <&cpg>; + resets = <&cpg R9A09G011_USB_ARESETN_H>; }; usb3peri: usb3peri@85070000 { - compatible = "renesas,r9a09g011-usb3-peri", - "renesas,rzv2m-usb3-peri"; - reg = <0x85070000 0x400>; - interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD R9A09G011_USB_ACLK_P>, - <&cpg CPG_MOD R9A09G011_USB_PCLK>; - clock-names = "axi", "reg"; - power-domains = <&cpg>; - resets = <&cpg R9A09G011_USB_ARESETN_P>; + compatible = "renesas,r9a09g011-usb3-peri", + "renesas,rzv2m-usb3-peri"; + reg = <0x85070000 0x400>; + interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD R9A09G011_USB_ACLK_P>, + <&cpg CPG_MOD R9A09G011_USB_PCLK>; + clock-names = "axi", "reg"; + power-domains = <&cpg>; + resets = <&cpg R9A09G011_USB_ARESETN_P>; }; }; diff --git a/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml index b2b811a0ade8..4e56e4ffeaf2 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml @@ -132,19 +132,19 @@ examples: usb-role-switch; ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - usb3_hs_ep: endpoint { - remote-endpoint = <&hs_ep>; - }; + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + usb3_hs_ep: endpoint { + remote-endpoint = <&hs_ep>; }; - port@1 { - reg = <1>; - usb3_role_switch: endpoint { - remote-endpoint = <&hd3ss3220_out_ep>; - }; + }; + port@1 { + reg = <1>; + usb3_role_switch: endpoint { + remote-endpoint = <&hd3ss3220_out_ep>; }; + }; }; }; diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index b23ef29bf794..980f325341d4 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml @@ -26,6 +26,7 @@ properties: - renesas,usbhs-r9a07g043 # RZ/G2UL and RZ/Five - renesas,usbhs-r9a07g044 # RZ/G2{L,LC} - renesas,usbhs-r9a07g054 # RZ/V2L + - renesas,usbhs-r9a08g045 # RZ/G3S - const: renesas,rzg2l-usbhs - items: @@ -130,6 +131,7 @@ allOf: - renesas,usbhs-r9a07g043 - renesas,usbhs-r9a07g044 - renesas,usbhs-r9a07g054 + - renesas,usbhs-r9a08g045 then: properties: interrupts: diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml new file mode 100644 index 000000000000..c956053fd036 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml @@ -0,0 +1,415 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/snps,dwc3-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare USB3 Controller common properties + +maintainers: + - Felipe Balbi <balbi@kernel.org> + +description: + Defines the properties of the DWC3 core as being embedded in either an + vendor-specific implementation or as a standalone component. + +allOf: + - $ref: usb-drd.yaml# + - if: + properties: + dr_mode: + const: peripheral + + required: + - dr_mode + then: + $ref: usb.yaml# + else: + $ref: usb-xhci.yaml# + +properties: + extcon: + maxItems: 1 + deprecated: true + + usb-phy: + minItems: 1 + items: + - description: USB2/HS PHY + - description: USB3/SS PHY + + phys: + minItems: 1 + maxItems: 19 + + phy-names: + minItems: 1 + maxItems: 19 + oneOf: + - items: + enum: [ usb2-phy, usb3-phy ] + - items: + pattern: "^usb(2-([0-9]|1[0-4])|3-[0-3])$" + + snps,usb2-lpm-disable: + description: Indicate if we don't want to enable USB2 HW LPM for host + mode. + type: boolean + + snps,usb3_lpm_capable: + description: Determines if platform is USB3 LPM capable + type: boolean + + snps,usb2-gadget-lpm-disable: + description: Indicate if we don't want to enable USB2 HW LPM for gadget + mode. + type: boolean + + snps,dis-start-transfer-quirk: + description: + When set, disable isoc START TRANSFER command failure SW work-around + for DWC_usb31 version 1.70a-ea06 and prior. + type: boolean + + snps,disable_scramble_quirk: + description: + True when SW should disable data scrambling. Only really useful for FPGA + builds. + type: boolean + + snps,has-lpm-erratum: + description: True when DWC3 was configured with LPM Erratum enabled + type: boolean + + snps,lpm-nyet-threshold: + description: LPM NYET threshold + $ref: /schemas/types.yaml#/definitions/uint8 + + snps,u2exit_lfps_quirk: + description: Set if we want to enable u2exit lfps quirk + type: boolean + + snps,u2ss_inp3_quirk: + description: Set if we enable P3 OK for U2/SS Inactive quirk + type: boolean + + snps,req_p1p2p3_quirk: + description: + When set, the core will always request for P1/P2/P3 transition sequence. + type: boolean + + snps,del_p1p2p3_quirk: + description: + When set core will delay P1/P2/P3 until a certain amount of 8B10B errors + occur. + type: boolean + + snps,del_phy_power_chg_quirk: + description: When set core will delay PHY power change from P0 to P1/P2/P3. + type: boolean + + snps,lfps_filter_quirk: + description: When set core will filter LFPS reception. + type: boolean + + snps,rx_detect_poll_quirk: + description: + when set core will disable a 400us delay to start Polling LFPS after + RX.Detect. + type: boolean + + snps,tx_de_emphasis_quirk: + description: When set core will set Tx de-emphasis value + type: boolean + + snps,tx_de_emphasis: + description: + The value driven to the PHY is controlled by the LTSSM during USB3 + Compliance mode. + $ref: /schemas/types.yaml#/definitions/uint8 + enum: + - 0 # -6dB de-emphasis + - 1 # -3.5dB de-emphasis + - 2 # No de-emphasis + + snps,dis_u3_susphy_quirk: + description: When set core will disable USB3 suspend phy + type: boolean + + snps,dis_u2_susphy_quirk: + description: When set core will disable USB2 suspend phy + type: boolean + + snps,dis_enblslpm_quirk: + description: + When set clears the enblslpm in GUSB2PHYCFG, disabling the suspend signal + to the PHY. + type: boolean + + snps,dis-u1-entry-quirk: + description: Set if link entering into U1 needs to be disabled + type: boolean + + snps,dis-u2-entry-quirk: + description: Set if link entering into U2 needs to be disabled + type: boolean + + snps,dis_rxdet_inp3_quirk: + description: + When set core will disable receiver detection in PHY P3 power state. + type: boolean + + snps,dis-u2-freeclk-exists-quirk: + description: + When set, clear the u2_freeclk_exists in GUSB2PHYCFG, specify that USB2 + PHY doesn't provide a free-running PHY clock. + type: boolean + + snps,dis-del-phy-power-chg-quirk: + description: + When set core will change PHY power from P0 to P1/P2/P3 without delay. + type: boolean + + snps,dis-tx-ipgap-linecheck-quirk: + description: When set, disable u2mac linestate check during HS transmit + type: boolean + + snps,parkmode-disable-ss-quirk: + description: + When set, all SuperSpeed bus instances in park mode are disabled. + type: boolean + + snps,parkmode-disable-hs-quirk: + description: + When set, all HighSpeed bus instances in park mode are disabled. + type: boolean + + snps,dis_metastability_quirk: + description: + When set, disable metastability workaround. CAUTION! Use only if you are + absolutely sure of it. + type: boolean + + snps,dis-split-quirk: + description: + When set, change the way URBs are handled by the driver. Needed to + avoid -EPROTO errors with usbhid on some devices (Hikey 970). + type: boolean + + snps,gfladj-refclk-lpm-sel-quirk: + description: + When set, run the SOF/ITP counter based on ref_clk. + type: boolean + + snps,resume-hs-terminations: + description: + Fix the issue of HS terminations CRC error on resume by enabling this + quirk. When set, all the termsel, xcvrsel, opmode becomes 0 during end + of resume. This option is to support certain legacy ULPI PHYs. + type: boolean + + snps,ulpi-ext-vbus-drv: + description: + Some ULPI USB PHY does not support internal VBUS supply, and driving + the CPEN pin, requires the configuration of the ulpi DRVVBUSEXTERNAL + bit. When set, the xhci host will configure the USB2 PHY drives VBUS + with an external supply. + type: boolean + + snps,is-utmi-l1-suspend: + description: + True when DWC3 asserts output signal utmi_l1_suspend_n, false when + asserts utmi_sleep_n. + type: boolean + + snps,hird-threshold: + description: HIRD threshold + $ref: /schemas/types.yaml#/definitions/uint8 + + snps,hsphy_interface: + description: + High-Speed PHY interface selection between UTMI+ and ULPI when the + DWC_USB3_HSPHY_INTERFACE has value 3. + $ref: /schemas/types.yaml#/definitions/string + enum: [utmi, ulpi] + + snps,quirk-frame-length-adjustment: + description: + Value for GFLADJ_30MHZ field of GFLADJ register for post-silicon frame + length adjustment when the fladj_30mhz_sdbnd signal is invalid or + incorrect. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 0x3f + + snps,ref-clock-period-ns: + description: + Value for REFCLKPER field of GUCTL register for reference clock period in + nanoseconds, when the hardware set default does not match the actual + clock. + + This binding is deprecated. Instead, provide an appropriate reference clock. + minimum: 8 + maximum: 62 + deprecated: true + + snps,rx-thr-num-pkt: + description: + USB RX packet threshold count. In host mode, this field specifies + the space that must be available in the RX FIFO before the core can + start the corresponding USB RX transaction (burst). + In device mode, this field specifies the space that must be + available in the RX FIFO before the core can send ERDY for a + flow-controlled endpoint. It is only used for SuperSpeed. + The valid values for this field are from 1 to 15. (DWC3 SuperSpeed + USB 3.0 Controller Databook) + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 1 + maximum: 15 + + snps,rx-max-burst: + description: + Max USB RX burst size. In host mode, this field specifies the + Maximum Bulk IN burst the DWC_usb3 core can perform. When the system + bus is slower than the USB, RX FIFO can overrun during a long burst. + You can program a smaller value to this field to limit the RX burst + size that the core can perform. It only applies to SS Bulk, + Isochronous, and Interrupt IN endpoints in the host mode. + In device mode, this field specifies the NUMP value that is sent in + ERDY for an OUT endpoint. + The valid values for this field are from 1 to 16. (DWC3 SuperSpeed + USB 3.0 Controller Databook) + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 1 + maximum: 16 + + snps,tx-thr-num-pkt: + description: + USB TX packet threshold count. This field specifies the number of + packets that must be in the TXFIFO before the core can start + transmission for the corresponding USB transaction (burst). + This count is valid in both host and device modes. It is only used + for SuperSpeed operation. + Valid values are from 1 to 15. (DWC3 SuperSpeed USB 3.0 Controller + Databook) + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 1 + maximum: 15 + + snps,tx-max-burst: + description: + Max USB TX burst size. When the system bus is slower than the USB, + TX FIFO can underrun during a long burst. Program a smaller value + to this field to limit the TX burst size that the core can execute. + In Host mode, it only applies to SS Bulk, Isochronous, and Interrupt + OUT endpoints. This value is not used in device mode. + Valid values are from 1 to 16. (DWC3 SuperSpeed USB 3.0 Controller + Databook) + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 1 + maximum: 16 + + snps,rx-thr-num-pkt-prd: + description: + Periodic ESS RX packet threshold count (host mode only). Set this and + snps,rx-max-burst-prd to a valid, non-zero value 1-16 (DWC_usb31 + programming guide section 1.2.4) to enable periodic ESS RX threshold. + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 1 + maximum: 16 + + snps,rx-max-burst-prd: + description: + Max periodic ESS RX burst size (host mode only). Set this and + snps,rx-thr-num-pkt-prd to a valid, non-zero value 1-16 (DWC_usb31 + programming guide section 1.2.4) to enable periodic ESS RX threshold. + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 1 + maximum: 16 + + snps,tx-thr-num-pkt-prd: + description: + Periodic ESS TX packet threshold count (host mode only). Set this and + snps,tx-max-burst-prd to a valid, non-zero value 1-16 (DWC_usb31 + programming guide section 1.2.3) to enable periodic ESS TX threshold. + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 1 + maximum: 16 + + snps,tx-max-burst-prd: + description: + Max periodic ESS TX burst size (host mode only). Set this and + snps,tx-thr-num-pkt-prd to a valid, non-zero value 1-16 (DWC_usb31 + programming guide section 1.2.3) to enable periodic ESS TX threshold. + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 1 + maximum: 16 + + tx-fifo-resize: + description: Determines if the TX fifos can be dynamically resized depending + on the number of IN endpoints used and if bursting is supported. This + may help improve bandwidth on platforms with higher system latencies, as + increased fifo space allows for the controller to prefetch data into its + internal memory. + type: boolean + + tx-fifo-max-num: + description: Specifies the max number of packets the txfifo resizing logic + can account for when higher endpoint bursting is used. (bMaxBurst > 6) The + higher the number, the more fifo space the txfifo resizing logic will + allocate for that endpoint. + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 3 + + snps,incr-burst-type-adjustment: + description: + Value for INCR burst type of GSBUSCFG0 register, undefined length INCR + burst type enable and INCRx type. A single value means INCRX burst mode + enabled. If more than one value specified, undefined length INCR burst + type will be enabled with burst lengths utilized up to the maximum + of the values passed in this property. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + uniqueItems: true + items: + enum: [1, 4, 8, 16, 32, 64, 128, 256] + + num-hc-interrupters: + maximum: 8 + default: 1 + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + This port is used with the 'usb-role-switch' property to connect the + dwc3 to type C connector. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + Those ports should be used with any connector to the data bus of this + controller using the OF graph bindings specified if the "usb-role-switch" + property is used. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: High Speed (HS) data bus. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Super Speed (SS) data bus. + + wakeup-source: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable USB remote wakeup. + +required: + - compatible + - reg + +additionalProperties: true +... + diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 1cd0ca90127d..4380bb6fa2f0 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -15,18 +15,7 @@ description: compatible string. allOf: - - $ref: usb-drd.yaml# - - if: - properties: - dr_mode: - const: peripheral - - required: - - dr_mode - then: - $ref: usb.yaml# - else: - $ref: usb-xhci.yaml# + - $ref: snps,dwc3-common.yaml# properties: compatible: @@ -70,32 +59,9 @@ properties: dma-coherent: true - extcon: - maxItems: 1 - deprecated: true - iommus: maxItems: 1 - usb-phy: - minItems: 1 - items: - - description: USB2/HS PHY - - description: USB3/SS PHY - - phys: - minItems: 1 - maxItems: 19 - - phy-names: - minItems: 1 - maxItems: 19 - oneOf: - - items: - enum: [ usb2-phy, usb3-phy ] - - items: - pattern: "^usb(2-([0-9]|1[0-4])|3-[0-3])$" - power-domains: description: The DWC3 has 2 power-domains. The power management unit (PMU) and @@ -109,361 +75,6 @@ properties: resets: minItems: 1 - snps,usb2-lpm-disable: - description: Indicate if we don't want to enable USB2 HW LPM for host - mode. - type: boolean - - snps,usb3_lpm_capable: - description: Determines if platform is USB3 LPM capable - type: boolean - - snps,usb2-gadget-lpm-disable: - description: Indicate if we don't want to enable USB2 HW LPM for gadget - mode. - type: boolean - - snps,dis-start-transfer-quirk: - description: - When set, disable isoc START TRANSFER command failure SW work-around - for DWC_usb31 version 1.70a-ea06 and prior. - type: boolean - - snps,disable_scramble_quirk: - description: - True when SW should disable data scrambling. Only really useful for FPGA - builds. - type: boolean - - snps,has-lpm-erratum: - description: True when DWC3 was configured with LPM Erratum enabled - type: boolean - - snps,lpm-nyet-threshold: - description: LPM NYET threshold - $ref: /schemas/types.yaml#/definitions/uint8 - - snps,u2exit_lfps_quirk: - description: Set if we want to enable u2exit lfps quirk - type: boolean - - snps,u2ss_inp3_quirk: - description: Set if we enable P3 OK for U2/SS Inactive quirk - type: boolean - - snps,req_p1p2p3_quirk: - description: - When set, the core will always request for P1/P2/P3 transition sequence. - type: boolean - - snps,del_p1p2p3_quirk: - description: - When set core will delay P1/P2/P3 until a certain amount of 8B10B errors - occur. - type: boolean - - snps,del_phy_power_chg_quirk: - description: When set core will delay PHY power change from P0 to P1/P2/P3. - type: boolean - - snps,lfps_filter_quirk: - description: When set core will filter LFPS reception. - type: boolean - - snps,rx_detect_poll_quirk: - description: - when set core will disable a 400us delay to start Polling LFPS after - RX.Detect. - type: boolean - - snps,tx_de_emphasis_quirk: - description: When set core will set Tx de-emphasis value - type: boolean - - snps,tx_de_emphasis: - description: - The value driven to the PHY is controlled by the LTSSM during USB3 - Compliance mode. - $ref: /schemas/types.yaml#/definitions/uint8 - enum: - - 0 # -6dB de-emphasis - - 1 # -3.5dB de-emphasis - - 2 # No de-emphasis - - snps,dis_u3_susphy_quirk: - description: When set core will disable USB3 suspend phy - type: boolean - - snps,dis_u2_susphy_quirk: - description: When set core will disable USB2 suspend phy - type: boolean - - snps,dis_enblslpm_quirk: - description: - When set clears the enblslpm in GUSB2PHYCFG, disabling the suspend signal - to the PHY. - type: boolean - - snps,dis-u1-entry-quirk: - description: Set if link entering into U1 needs to be disabled - type: boolean - - snps,dis-u2-entry-quirk: - description: Set if link entering into U2 needs to be disabled - type: boolean - - snps,dis_rxdet_inp3_quirk: - description: - When set core will disable receiver detection in PHY P3 power state. - type: boolean - - snps,dis-u2-freeclk-exists-quirk: - description: - When set, clear the u2_freeclk_exists in GUSB2PHYCFG, specify that USB2 - PHY doesn't provide a free-running PHY clock. - type: boolean - - snps,dis-del-phy-power-chg-quirk: - description: - When set core will change PHY power from P0 to P1/P2/P3 without delay. - type: boolean - - snps,dis-tx-ipgap-linecheck-quirk: - description: When set, disable u2mac linestate check during HS transmit - type: boolean - - snps,parkmode-disable-ss-quirk: - description: - When set, all SuperSpeed bus instances in park mode are disabled. - type: boolean - - snps,parkmode-disable-hs-quirk: - description: - When set, all HighSpeed bus instances in park mode are disabled. - type: boolean - - snps,dis_metastability_quirk: - description: - When set, disable metastability workaround. CAUTION! Use only if you are - absolutely sure of it. - type: boolean - - snps,dis-split-quirk: - description: - When set, change the way URBs are handled by the driver. Needed to - avoid -EPROTO errors with usbhid on some devices (Hikey 970). - type: boolean - - snps,gfladj-refclk-lpm-sel-quirk: - description: - When set, run the SOF/ITP counter based on ref_clk. - type: boolean - - snps,resume-hs-terminations: - description: - Fix the issue of HS terminations CRC error on resume by enabling this - quirk. When set, all the termsel, xcvrsel, opmode becomes 0 during end - of resume. This option is to support certain legacy ULPI PHYs. - type: boolean - - snps,ulpi-ext-vbus-drv: - description: - Some ULPI USB PHY does not support internal VBUS supply, and driving - the CPEN pin, requires the configuration of the ulpi DRVVBUSEXTERNAL - bit. When set, the xhci host will configure the USB2 PHY drives VBUS - with an external supply. - type: boolean - - snps,is-utmi-l1-suspend: - description: - True when DWC3 asserts output signal utmi_l1_suspend_n, false when - asserts utmi_sleep_n. - type: boolean - - snps,hird-threshold: - description: HIRD threshold - $ref: /schemas/types.yaml#/definitions/uint8 - - snps,hsphy_interface: - description: - High-Speed PHY interface selection between UTMI+ and ULPI when the - DWC_USB3_HSPHY_INTERFACE has value 3. - $ref: /schemas/types.yaml#/definitions/string - enum: [utmi, ulpi] - - snps,quirk-frame-length-adjustment: - description: - Value for GFLADJ_30MHZ field of GFLADJ register for post-silicon frame - length adjustment when the fladj_30mhz_sdbnd signal is invalid or - incorrect. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 0 - maximum: 0x3f - - snps,ref-clock-period-ns: - description: - Value for REFCLKPER field of GUCTL register for reference clock period in - nanoseconds, when the hardware set default does not match the actual - clock. - - This binding is deprecated. Instead, provide an appropriate reference clock. - minimum: 8 - maximum: 62 - deprecated: true - - snps,rx-thr-num-pkt: - description: - USB RX packet threshold count. In host mode, this field specifies - the space that must be available in the RX FIFO before the core can - start the corresponding USB RX transaction (burst). - In device mode, this field specifies the space that must be - available in the RX FIFO before the core can send ERDY for a - flow-controlled endpoint. It is only used for SuperSpeed. - The valid values for this field are from 1 to 15. (DWC3 SuperSpeed - USB 3.0 Controller Databook) - $ref: /schemas/types.yaml#/definitions/uint8 - minimum: 1 - maximum: 15 - - snps,rx-max-burst: - description: - Max USB RX burst size. In host mode, this field specifies the - Maximum Bulk IN burst the DWC_usb3 core can perform. When the system - bus is slower than the USB, RX FIFO can overrun during a long burst. - You can program a smaller value to this field to limit the RX burst - size that the core can perform. It only applies to SS Bulk, - Isochronous, and Interrupt IN endpoints in the host mode. - In device mode, this field specifies the NUMP value that is sent in - ERDY for an OUT endpoint. - The valid values for this field are from 1 to 16. (DWC3 SuperSpeed - USB 3.0 Controller Databook) - $ref: /schemas/types.yaml#/definitions/uint8 - minimum: 1 - maximum: 16 - - snps,tx-thr-num-pkt: - description: - USB TX packet threshold count. This field specifies the number of - packets that must be in the TXFIFO before the core can start - transmission for the corresponding USB transaction (burst). - This count is valid in both host and device modes. It is only used - for SuperSpeed operation. - Valid values are from 1 to 15. (DWC3 SuperSpeed USB 3.0 Controller - Databook) - $ref: /schemas/types.yaml#/definitions/uint8 - minimum: 1 - maximum: 15 - - snps,tx-max-burst: - description: - Max USB TX burst size. When the system bus is slower than the USB, - TX FIFO can underrun during a long burst. Program a smaller value - to this field to limit the TX burst size that the core can execute. - In Host mode, it only applies to SS Bulk, Isochronous, and Interrupt - OUT endpoints. This value is not used in device mode. - Valid values are from 1 to 16. (DWC3 SuperSpeed USB 3.0 Controller - Databook) - $ref: /schemas/types.yaml#/definitions/uint8 - minimum: 1 - maximum: 16 - - snps,rx-thr-num-pkt-prd: - description: - Periodic ESS RX packet threshold count (host mode only). Set this and - snps,rx-max-burst-prd to a valid, non-zero value 1-16 (DWC_usb31 - programming guide section 1.2.4) to enable periodic ESS RX threshold. - $ref: /schemas/types.yaml#/definitions/uint8 - minimum: 1 - maximum: 16 - - snps,rx-max-burst-prd: - description: - Max periodic ESS RX burst size (host mode only). Set this and - snps,rx-thr-num-pkt-prd to a valid, non-zero value 1-16 (DWC_usb31 - programming guide section 1.2.4) to enable periodic ESS RX threshold. - $ref: /schemas/types.yaml#/definitions/uint8 - minimum: 1 - maximum: 16 - - snps,tx-thr-num-pkt-prd: - description: - Periodic ESS TX packet threshold count (host mode only). Set this and - snps,tx-max-burst-prd to a valid, non-zero value 1-16 (DWC_usb31 - programming guide section 1.2.3) to enable periodic ESS TX threshold. - $ref: /schemas/types.yaml#/definitions/uint8 - minimum: 1 - maximum: 16 - - snps,tx-max-burst-prd: - description: - Max periodic ESS TX burst size (host mode only). Set this and - snps,tx-thr-num-pkt-prd to a valid, non-zero value 1-16 (DWC_usb31 - programming guide section 1.2.3) to enable periodic ESS TX threshold. - $ref: /schemas/types.yaml#/definitions/uint8 - minimum: 1 - maximum: 16 - - tx-fifo-resize: - description: Determines if the TX fifos can be dynamically resized depending - on the number of IN endpoints used and if bursting is supported. This - may help improve bandwidth on platforms with higher system latencies, as - increased fifo space allows for the controller to prefetch data into its - internal memory. - type: boolean - - tx-fifo-max-num: - description: Specifies the max number of packets the txfifo resizing logic - can account for when higher endpoint bursting is used. (bMaxBurst > 6) The - higher the number, the more fifo space the txfifo resizing logic will - allocate for that endpoint. - $ref: /schemas/types.yaml#/definitions/uint8 - minimum: 3 - - snps,incr-burst-type-adjustment: - description: - Value for INCR burst type of GSBUSCFG0 register, undefined length INCR - burst type enable and INCRx type. A single value means INCRX burst mode - enabled. If more than one value specified, undefined length INCR burst - type will be enabled with burst lengths utilized up to the maximum - of the values passed in this property. - $ref: /schemas/types.yaml#/definitions/uint32-array - minItems: 1 - maxItems: 8 - uniqueItems: true - items: - enum: [1, 4, 8, 16, 32, 64, 128, 256] - - num-hc-interrupters: - maximum: 8 - default: 1 - - port: - $ref: /schemas/graph.yaml#/properties/port - description: - This port is used with the 'usb-role-switch' property to connect the - dwc3 to type C connector. - - ports: - $ref: /schemas/graph.yaml#/properties/ports - description: - Those ports should be used with any connector to the data bus of this - controller using the OF graph bindings specified if the "usb-role-switch" - property is used. - - properties: - port@0: - $ref: /schemas/graph.yaml#/properties/port - description: High Speed (HS) data bus. - - port@1: - $ref: /schemas/graph.yaml#/properties/port - description: Super Speed (SS) data bus. - - wakeup-source: - $ref: /schemas/types.yaml#/definitions/flag - description: - Enable USB remote wakeup. - unevaluatedProperties: false required: diff --git a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml index 54c6586cb56d..bec1c8047bc0 100644 --- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml +++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml @@ -56,26 +56,26 @@ examples: #size-cells = <0>; hd3ss3220@47 { - compatible = "ti,hd3ss3220"; - reg = <0x47>; - interrupt-parent = <&gpio6>; - interrupts = <3>; + compatible = "ti,hd3ss3220"; + reg = <0x47>; + interrupt-parent = <&gpio6>; + interrupts = <3>; - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - hd3ss3220_in_ep: endpoint { - remote-endpoint = <&ss_ep>; - }; - }; - port@1 { - reg = <1>; - hd3ss3220_out_ep: endpoint { - remote-endpoint = <&usb3_role_switch>; - }; - }; + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + hd3ss3220_in_ep: endpoint { + remote-endpoint = <&ss_ep>; + }; }; + port@1 { + reg = <1>; + hd3ss3220_out_ep: endpoint { + remote-endpoint = <&usb3_role_switch>; + }; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/usb/ti,tusb73x0-pci.yaml b/Documentation/devicetree/bindings/usb/ti,tusb73x0-pci.yaml index ddda734f36fb..c4a91b3d6612 100644 --- a/Documentation/devicetree/bindings/usb/ti,tusb73x0-pci.yaml +++ b/Documentation/devicetree/bindings/usb/ti,tusb73x0-pci.yaml @@ -48,8 +48,8 @@ examples: device_type = "pci"; usb@0 { - compatible = "pci104c,8241"; - reg = <0x0 0x0 0x0 0x0 0x0>; - ti,pwron-active-high; + compatible = "pci104c,8241"; + reg = <0x0 0x0 0x0 0x0 0x0>; + ti,pwron-active-high; }; }; diff --git a/Documentation/devicetree/bindings/usb/ti,usb8020b.yaml b/Documentation/devicetree/bindings/usb/ti,usb8020b.yaml index 8ef117793e11..61217da8b2f3 100644 --- a/Documentation/devicetree/bindings/usb/ti,usb8020b.yaml +++ b/Documentation/devicetree/bindings/usb/ti,usb8020b.yaml @@ -51,19 +51,19 @@ examples: /* 2.0 hub on port 1 */ hub_2_0: hub@1 { - compatible = "usb451,8027"; - reg = <1>; - peer-hub = <&hub_3_0>; - reset-gpios = <&pio 7 GPIO_ACTIVE_HIGH>; - vdd-supply = <&usb_hub_fixed_3v3>; + compatible = "usb451,8027"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&pio 7 GPIO_ACTIVE_HIGH>; + vdd-supply = <&usb_hub_fixed_3v3>; }; /* 3.0 hub on port 2 */ hub_3_0: hub@2 { - compatible = "usb451,8025"; - reg = <2>; - peer-hub = <&hub_2_0>; - reset-gpios = <&pio 7 GPIO_ACTIVE_HIGH>; - vdd-supply = <&usb_hub_fixed_3v3>; + compatible = "usb451,8025"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&pio 7 GPIO_ACTIVE_HIGH>; + vdd-supply = <&usb_hub_fixed_3v3>; }; }; diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml index c2e29bd61e11..bce730a5e237 100644 --- a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml +++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml @@ -51,17 +51,17 @@ examples: /* 2.0 hub on port 1 */ hub_2_0: hub@1 { - compatible = "usb451,8142"; - reg = <1>; - peer-hub = <&hub_3_0>; - reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; + compatible = "usb451,8142"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; }; /* 3.0 hub on port 2 */ hub_3_0: hub@2 { - compatible = "usb451,8140"; - reg = <2>; - peer-hub = <&hub_2_0>; - reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; + compatible = "usb451,8140"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; }; }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index da01616802c7..b5979832ddce 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -218,6 +218,8 @@ patternProperties: description: Shenzhen BigTree Tech Co., LTD "^bitmain,.*": description: Bitmain Technologies + "^blaize,.*": + description: Blaize, Inc. "^blutek,.*": description: BluTek Power "^boe,.*": @@ -575,6 +577,8 @@ patternProperties: description: Gemtek Technology Co., Ltd. "^genesys,.*": description: Genesys Logic, Inc. + "^genexis,.*": + description: Genexis BV/AB "^geniatech,.*": description: Geniatech, Inc. "^giantec,.*": @@ -589,6 +593,8 @@ patternProperties: description: GlobalTop Technology, Inc. "^gmt,.*": description: Global Mixed-mode Technology, Inc. + "^gocontroll,.*": + description: GOcontroll Modular Embedded Electronics B.V. "^goldelico,.*": description: Golden Delicious Computers GmbH & Co. KG "^goodix,.*": @@ -1204,6 +1210,8 @@ patternProperties: description: PulsedLight, Inc "^purism,.*": description: Purism, SPC + "^puya,.*": + description: Puya Semiconductor (Shanghai) Co., Ltd. "^qca,.*": description: Qualcomm Atheros, Inc. "^qcom,.*": @@ -1336,6 +1344,8 @@ patternProperties: description: Siemens AG "^sifive,.*": description: SiFive, Inc. + "^siflower,.*": + description: Shanghai Siflower Communication Co. "^sigma,.*": description: Sigma Designs, Inc. "^sii,.*": @@ -1524,6 +1534,8 @@ patternProperties: description: Topeet "^topic,.*": description: Topic Embedded Systems + "^topland,.*": + description: Topland Electronics (H.K) Co., Ltd. "^toppoly,.*": description: TPO (deprecated, use tpo) deprecated: true diff --git a/Documentation/devicetree/bindings/w1/maxim,ds2482.yaml b/Documentation/devicetree/bindings/w1/maxim,ds2482.yaml index 422becc6e1fa..fe6b3f9a3f8b 100644 --- a/Documentation/devicetree/bindings/w1/maxim,ds2482.yaml +++ b/Documentation/devicetree/bindings/w1/maxim,ds2482.yaml @@ -25,6 +25,8 @@ properties: reg: maxItems: 1 + vcc-supply: true + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml index 34896a39fa91..49e2b807db0b 100644 --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml @@ -20,6 +20,7 @@ properties: - qcom,kpss-wdt-ipq4019 - qcom,apss-wdt-ipq5018 - qcom,apss-wdt-ipq5332 + - qcom,apss-wdt-ipq5424 - qcom,apss-wdt-ipq9574 - qcom,apss-wdt-msm8226 - qcom,apss-wdt-msm8974 diff --git a/Documentation/devicetree/of_unittest.rst b/Documentation/devicetree/of_unittest.rst index 8864b52d1195..a6c05962add3 100644 --- a/Documentation/devicetree/of_unittest.rst +++ b/Documentation/devicetree/of_unittest.rst @@ -50,15 +50,13 @@ from 'scripts/dtc/of_unittest_expect --help'. The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains the test data required for executing the unit tests automated in -drivers/of/unittest.c. Currently, following Device Tree Source Include files -(.dtsi) are included in testcases.dts:: +drivers/of/unittest.c. See the content of the folder:: - drivers/of/unittest-data/tests-interrupts.dtsi - drivers/of/unittest-data/tests-platform.dtsi - drivers/of/unittest-data/tests-phandle.dtsi - drivers/of/unittest-data/tests-match.dtsi + drivers/of/unittest-data/tests-*.dtsi -When the kernel is build with OF_SELFTEST enabled, then the following make +for the Device Tree Source Include files (.dtsi) included in testcases.dts. + +When the kernel is build with CONFIG_OF_UNITTEST enabled, then the following make rule:: $(obj)/%.dtb: $(src)/%.dts FORCE diff --git a/Documentation/driver-api/crypto/iaa/iaa-crypto.rst b/Documentation/driver-api/crypto/iaa/iaa-crypto.rst index bba40158dd5c..8e50b900d51c 100644 --- a/Documentation/driver-api/crypto/iaa/iaa-crypto.rst +++ b/Documentation/driver-api/crypto/iaa/iaa-crypto.rst @@ -272,7 +272,7 @@ The available attributes are: echo async_irq > /sys/bus/dsa/drivers/crypto/sync_mode Async mode without interrupts (caller must poll) can be enabled by - writing 'async' to it:: + writing 'async' to it (please see Caveat):: echo async > /sys/bus/dsa/drivers/crypto/sync_mode @@ -283,6 +283,13 @@ The available attributes are: The default mode is 'sync'. + Caveat: since the only mechanism that iaa_crypto currently implements + for async polling without interrupts is via the 'sync' mode as + described earlier, writing 'async' to + '/sys/bus/dsa/drivers/crypto/sync_mode' will internally enable the + 'sync' mode. This is to ensure correct iaa_crypto behavior until true + async polling without interrupts is enabled in iaa_crypto. + .. _iaa_default_config: IAA Default Configuration diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index d594d0ea0e9d..d75728eb05f8 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -404,7 +404,6 @@ PHY devm_usb_get_phy() devm_usb_get_phy_by_node() devm_usb_get_phy_by_phandle() - devm_usb_put_phy() PINCTRL devm_pinctrl_get() diff --git a/Documentation/driver-api/extcon.rst b/Documentation/driver-api/extcon.rst new file mode 100644 index 000000000000..d3217b9cdcd5 --- /dev/null +++ b/Documentation/driver-api/extcon.rst @@ -0,0 +1,255 @@ +======================= +Extcon Device Subsystem +======================= + +Overview +======== + +The Extcon (External Connector) subsystem provides a unified framework for +managing external connectors in Linux systems. It allows drivers to report +the state of external connectors and provides a standardized interface for +userspace to query and monitor these states. + +Extcon is particularly useful in modern devices with multiple connectivity +options, such as smartphones, tablets, and laptops. It helps manage various +types of connectors, including: + +1. USB connectors (e.g., USB-C, micro-USB) +2. Charging ports (e.g., fast charging, wireless charging) +3. Audio jacks (e.g., 3.5mm headphone jack) +4. Video outputs (e.g., HDMI, DisplayPort) +5. Docking stations + +Real-world examples: + +1. Smartphone USB-C port: + A single USB-C port on a smartphone can serve multiple functions. Extcon + can manage the different states of this port, such as: + - USB data connection + - Charging (various types like fast charging, USB Power Delivery) + - Audio output (USB-C headphones) + - Video output (USB-C to HDMI adapter) + +2. Laptop docking station: + When a laptop is connected to a docking station, multiple connections are + made simultaneously. Extcon can handle the state changes for: + - Power delivery + - External displays + - USB hub connections + - Ethernet connectivity + +3. Wireless charging pad: + Extcon can manage the state of a wireless charging connection, allowing + the system to respond appropriately when a device is placed on or removed + from the charging pad. + +4. Smart TV HDMI ports: + In a smart TV, Extcon can manage multiple HDMI ports, detecting when + devices are connected or disconnected, and potentially identifying the + type of device (e.g., gaming console, set-top box, Blu-ray player). + +The Extcon framework simplifies the development of drivers for these complex +scenarios by providing a standardized way to report and query connector +states, handle mutually exclusive connections, and manage connector +properties. This allows for more robust and flexible handling of external +connections in modern devices. + +Key Components +============== + +extcon_dev +---------- + +The core structure representing an Extcon device:: + + struct extcon_dev { + const char *name; + const unsigned int *supported_cable; + const u32 *mutually_exclusive; + + /* Internal data */ + struct device dev; + unsigned int id; + struct raw_notifier_head nh_all; + struct raw_notifier_head *nh; + struct list_head entry; + int max_supported; + spinlock_t lock; + u32 state; + + /* Sysfs related */ + struct device_type extcon_dev_type; + struct extcon_cable *cables; + struct attribute_group attr_g_muex; + struct attribute **attrs_muex; + struct device_attribute *d_attrs_muex; + }; + +Key fields: + +- ``name``: Name of the Extcon device +- ``supported_cable``: Array of supported cable types +- ``mutually_exclusive``: Array defining mutually exclusive cable types + This field is crucial for enforcing hardware constraints. It's an array of + 32-bit unsigned integers, where each element represents a set of mutually + exclusive cable types. The array should be terminated with a 0. + + For example: + + :: + + static const u32 mutually_exclusive[] = { + BIT(0) | BIT(1), /* Cable 0 and 1 are mutually exclusive */ + BIT(2) | BIT(3) | BIT(4), /* Cables 2, 3, and 4 are mutually exclusive */ + 0 /* Terminator */ + }; + + In this example, cables 0 and 1 cannot be connected simultaneously, and + cables 2, 3, and 4 are also mutually exclusive. This is useful for + scenarios like a single port that can either be USB or HDMI, but not both + at the same time. + + The Extcon core uses this information to prevent invalid combinations of + cable states, ensuring that the reported states are always consistent + with the hardware capabilities. + +- ``state``: Current state of the device (bitmap of connected cables) + + +extcon_cable +------------ + +Represents an individual cable managed by an Extcon device:: + + struct extcon_cable { + struct extcon_dev *edev; + int cable_index; + struct attribute_group attr_g; + struct device_attribute attr_name; + struct device_attribute attr_state; + struct attribute *attrs[3]; + union extcon_property_value usb_propval[EXTCON_PROP_USB_CNT]; + union extcon_property_value chg_propval[EXTCON_PROP_CHG_CNT]; + union extcon_property_value jack_propval[EXTCON_PROP_JACK_CNT]; + union extcon_property_value disp_propval[EXTCON_PROP_DISP_CNT]; + DECLARE_BITMAP(usb_bits, EXTCON_PROP_USB_CNT); + DECLARE_BITMAP(chg_bits, EXTCON_PROP_CHG_CNT); + DECLARE_BITMAP(jack_bits, EXTCON_PROP_JACK_CNT); + DECLARE_BITMAP(disp_bits, EXTCON_PROP_DISP_CNT); + }; + +Core Functions +============== + +.. kernel-doc:: drivers/extcon/extcon.c + :identifiers: extcon_get_state + +.. kernel-doc:: drivers/extcon/extcon.c + :identifiers: extcon_set_state + +.. kernel-doc:: drivers/extcon/extcon.c + :identifiers: extcon_set_state_sync + +.. kernel-doc:: drivers/extcon/extcon.c + :identifiers: extcon_get_property + + +Sysfs Interface +=============== + +Extcon devices expose the following sysfs attributes: + +- ``name``: Name of the Extcon device +- ``state``: Current state of all supported cables +- ``cable.N/name``: Name of the Nth supported cable +- ``cable.N/state``: State of the Nth supported cable + +Usage Example +------------- + +.. code-block:: c + + #include <linux/module.h> + #include <linux/platform_device.h> + #include <linux/extcon.h> + + struct my_extcon_data { + struct extcon_dev *edev; + struct device *dev; + }; + + static const unsigned int my_extcon_cable[] = { + EXTCON_USB, + EXTCON_USB_HOST, + EXTCON_NONE, + }; + + static int my_extcon_probe(struct platform_device *pdev) + { + struct my_extcon_data *data; + int ret; + + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL); + if (!data) + return -ENOMEM; + + data->dev = &pdev->dev; + + /* Initialize extcon device */ + data->edev = devm_extcon_dev_allocate(data->dev, my_extcon_cable); + if (IS_ERR(data->edev)) { + dev_err(data->dev, "Failed to allocate extcon device\n"); + return PTR_ERR(data->edev); + } + + /* Register extcon device */ + ret = devm_extcon_dev_register(data->dev, data->edev); + if (ret < 0) { + dev_err(data->dev, "Failed to register extcon device\n"); + return ret; + } + + platform_set_drvdata(pdev, data); + + /* Example: Set initial state */ + extcon_set_state_sync(data->edev, EXTCON_USB, true); + + dev_info(data->dev, "My extcon driver probed successfully\n"); + return 0; + } + + static int my_extcon_remove(struct platform_device *pdev) + { + struct my_extcon_data *data = platform_get_drvdata(pdev); + + /* Example: Clear state before removal */ + extcon_set_state_sync(data->edev, EXTCON_USB, false); + + dev_info(data->dev, "My extcon driver removed\n"); + return 0; + } + + static const struct of_device_id my_extcon_of_match[] = { + { .compatible = "my,extcon-device", }, + { }, + }; + MODULE_DEVICE_TABLE(of, my_extcon_of_match); + + static struct platform_driver my_extcon_driver = { + .driver = { + .name = "my-extcon-driver", + .of_match_table = my_extcon_of_match, + }, + .probe = my_extcon_probe, + .remove = my_extcon_remove, + }; + + module_platform_driver(my_extcon_driver); + +This example demonstrates: +--------------------------- + +- Defining supported cable types (USB and USB Host in this case). +- Allocating and registering an extcon device. +- Setting an initial state for a cable (USB connected in this example). +- Clearing the state when the driver is removed. diff --git a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst index fdcfce42c6d2..336e912281c3 100644 --- a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst +++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst @@ -42,3 +42,8 @@ then of course these rules will not apply strictly.) deprecating old major versions, then this should only be done as a last option, and be stated clearly in all communications. +* Firmware files that affect the User API (UAPI) shall not introduce + changes that break existing userspace programs. Updates to such firmware + must ensure backward compatibility with existing userspace applications. + This includes maintaining consistent interfaces and behaviors that + userspace programs rely on. diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst index 71ccc30e586b..e826f16ea43d 100644 --- a/Documentation/driver-api/generic-counter.rst +++ b/Documentation/driver-api/generic-counter.rst @@ -467,7 +467,7 @@ Counter sysfs Translates counter data to the standard Counter sysfs interface format and vice versa. -Please refer to the ``Documentation/ABI/testing/sysfs-bus-counter`` file +Please refer to the Documentation/ABI/testing/sysfs-bus-counter file for a detailed breakdown of the available Generic Counter interface sysfs attributes. @@ -483,7 +483,7 @@ Sysfs Interface Several sysfs attributes are generated by the Generic Counter interface, and reside under the ``/sys/bus/counter/devices/counterX`` directory, where ``X`` is to the respective counter device id. Please see -``Documentation/ABI/testing/sysfs-bus-counter`` for detailed information +Documentation/ABI/testing/sysfs-bus-counter for detailed information on each Generic Counter interface sysfs attribute. Through these sysfs attributes, programs and scripts may interact with diff --git a/Documentation/driver-api/iio/core.rst b/Documentation/driver-api/iio/core.rst index dfe438dc91a7..42b580fb2989 100644 --- a/Documentation/driver-api/iio/core.rst +++ b/Documentation/driver-api/iio/core.rst @@ -60,7 +60,7 @@ directory. Common attributes are: * :file:`sampling_frequency_available`, available discrete set of sampling frequency values for device. * Available standard attributes for IIO devices are described in the - :file:`Documentation/ABI/testing/sysfs-bus-iio` file in the Linux kernel + :file:Documentation/ABI/testing/sysfs-bus-iio file in the Linux kernel sources. IIO device channels diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 7f83e05769b4..16e2c4ec3c01 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -86,6 +86,7 @@ Subsystem-specific APIs dmaengine/index dpll edac + extcon firmware/index fpga/index frame-buffer diff --git a/Documentation/driver-api/infiniband.rst b/Documentation/driver-api/infiniband.rst index 30e142ccbee9..10d8be9e74fe 100644 --- a/Documentation/driver-api/infiniband.rst +++ b/Documentation/driver-api/infiniband.rst @@ -77,14 +77,14 @@ iSCSI Extensions for RDMA (iSER) :internal: .. kernel-doc:: drivers/infiniband/ulp/iser/iscsi_iser.c - :functions: iscsi_iser_pdu_alloc iser_initialize_task_headers \ - iscsi_iser_task_init iscsi_iser_mtask_xmit iscsi_iser_task_xmit \ - iscsi_iser_cleanup_task iscsi_iser_check_protection \ - iscsi_iser_conn_create iscsi_iser_conn_bind \ - iscsi_iser_conn_start iscsi_iser_conn_stop \ - iscsi_iser_session_destroy iscsi_iser_session_create \ - iscsi_iser_set_param iscsi_iser_ep_connect iscsi_iser_ep_poll \ - iscsi_iser_ep_disconnect + :functions: iscsi_iser_pdu_alloc iser_initialize_task_headers + iscsi_iser_task_init iscsi_iser_mtask_xmit iscsi_iser_task_xmit + iscsi_iser_cleanup_task iscsi_iser_check_protection + iscsi_iser_conn_create iscsi_iser_conn_bind + iscsi_iser_conn_start iscsi_iser_conn_stop + iscsi_iser_session_destroy iscsi_iser_session_create + iscsi_iser_set_param iscsi_iser_ep_connect iscsi_iser_ep_poll + iscsi_iser_ep_disconnect .. kernel-doc:: drivers/infiniband/ulp/iser/iser_initiator.c :internal: diff --git a/Documentation/driver-api/infrastructure.rst b/Documentation/driver-api/infrastructure.rst index 3d52dfdfa9fd..35e36fee4238 100644 --- a/Documentation/driver-api/infrastructure.rst +++ b/Documentation/driver-api/infrastructure.rst @@ -41,6 +41,12 @@ Device Drivers Base .. kernel-doc:: drivers/base/class.c :export: +.. kernel-doc:: include/linux/device/faux.h + :internal: + +.. kernel-doc:: drivers/base/faux.c + :export: + .. kernel-doc:: drivers/base/node.c :internal: diff --git a/Documentation/driver-api/media/drivers/zoran.rst b/Documentation/driver-api/media/drivers/zoran.rst index b205e10c3154..3e05b7f0442a 100644 --- a/Documentation/driver-api/media/drivers/zoran.rst +++ b/Documentation/driver-api/media/drivers/zoran.rst @@ -222,7 +222,7 @@ The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong, Ireland, Nigeria, South Africa. The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate, -and is used in Argentinia, Uruguay, an a few others +and is used in Argentina, Uruguay, an a few others We do not talk about how the audio is broadcast ! diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst index ffc712a5f632..ad96a89ee916 100644 --- a/Documentation/driver-api/media/maintainer-entry-profile.rst +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst @@ -116,7 +116,7 @@ CEC drivers ``cec-compliance`` .. [3] The ``v4l2-compliance`` also covers the media controller usage inside V4L2 drivers. -Other compilance tools are under development to check other parts of the +Other compliance tools are under development to check other parts of the subsystem. Those tests need to pass before the patches go upstream. diff --git a/Documentation/driver-api/media/tx-rx.rst b/Documentation/driver-api/media/tx-rx.rst index dd09484df1d3..0b8c9cde8ee4 100644 --- a/Documentation/driver-api/media/tx-rx.rst +++ b/Documentation/driver-api/media/tx-rx.rst @@ -49,8 +49,15 @@ Link frequency The :ref:`V4L2_CID_LINK_FREQ <v4l2-cid-link-freq>` control is used to tell the receiver the frequency of the bus (i.e. it is not the same as the symbol rate). +Drivers that do not have user-configurable link frequency should report it +through the ``.get_mbus_config()`` subdev pad operation, in the ``link_freq`` +field of struct v4l2_mbus_config, instead of through controls. + +Receiver drivers should use :c:func:`v4l2_get_link_freq` helper to obtain the +link frequency from the transmitter sub-device. + ``.enable_streams()`` and ``.disable_streams()`` callbacks -^^^^^^^^^^^^^^^^^^^^^^^^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The struct v4l2_subdev_pad_ops->enable_streams() and struct v4l2_subdev_pad_ops->disable_streams() callbacks are used by the receiver driver @@ -58,6 +65,15 @@ to control the transmitter driver's streaming state. These callbacks may not be called directly, but by using ``v4l2_subdev_enable_streams()`` and ``v4l2_subdev_disable_streams()``. +Stopping the transmitter +^^^^^^^^^^^^^^^^^^^^^^^^ + +A transmitter stops sending the stream of images as a result of +calling the ``.disable_streams()`` callback. Some transmitters may stop the +stream at a frame boundary whereas others stop immediately, +effectively leaving the current frame unfinished. The receiver driver +should not make assumptions either way, but function properly in both +cases. CSI-2 transmitter drivers ------------------------- @@ -79,14 +95,15 @@ where * - link_freq - The value of the ``V4L2_CID_LINK_FREQ`` integer64 menu item. * - nr_of_lanes - - Number of data lanes used on the CSI-2 link. This can - be obtained from the OF endpoint configuration. + - Number of data lanes used on the CSI-2 link. * - 2 - Data is transferred on both rising and falling edge of the signal. * - bits_per_sample - Number of bits per sample. * - k - - 16 for D-PHY and 7 for C-PHY + - 16 for D-PHY and 7 for C-PHY. + +Information on whether D-PHY or C-PHY is used, and the value of ``nr_of_lanes``, can be obtained from the OF endpoint configuration. .. note:: @@ -125,13 +142,3 @@ device, so this should be only done when it is needed. Receiver drivers that do not need explicit LP-11 or LP-111 state setup are waived from calling the two callbacks. - -Stopping the transmitter -^^^^^^^^^^^^^^^^^^^^^^^^ - -A transmitter stops sending the stream of images as a result of -calling the ``.disable_streams()`` callback. Some transmitters may stop the -stream at a frame boundary whereas others stop immediately, -effectively leaving the current frame unfinished. The receiver driver -should not make assumptions either way, but function properly in both -cases. diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst index ca16b5acbf30..c205efa4d45b 100644 --- a/Documentation/driver-api/nvdimm/nvdimm.rst +++ b/Documentation/driver-api/nvdimm/nvdimm.rst @@ -535,12 +535,12 @@ internally with a static identifier:: char devname[50]; snprintf(devname, sizeof(devname), "namespace%d.%d", - ndctl_region_get_id(region), paramaters->id); + ndctl_region_get_id(region), parameters->id); ndctl_namespace_set_alt_name(ndns, devname); /* 'uuid' must be set prior to setting size! */ - ndctl_namespace_set_uuid(ndns, paramaters->uuid); - ndctl_namespace_set_size(ndns, paramaters->size); + ndctl_namespace_set_uuid(ndns, parameters->uuid); + ndctl_namespace_set_size(ndns, parameters->size); /* unlike pmem namespaces, blk namespaces have a sector size */ if (parameters->lbasize) ndctl_namespace_set_sector_size(ndns, parameters->lbasize); diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index d448cb57df86..8d86d5da4023 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -358,7 +358,7 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``, ``suspend_noirq``. is probed against the device in question by passing them to the :c:func:`dev_pm_set_driver_flags` helper function.] If the first of these flags is set, the PM core will not apply the direct-complete - procedure described above to the given device and, consequenty, to any + procedure described above to the given device and, consequently, to any of its ancestors. The second flag, when set, informs the middle layer code (bus types, device types, PM domains, classes) that it should take the return value of the ``->prepare`` callback provided by the driver diff --git a/Documentation/driver-api/pps.rst b/Documentation/driver-api/pps.rst index 78dded03e5d8..71ad04c82d6c 100644 --- a/Documentation/driver-api/pps.rst +++ b/Documentation/driver-api/pps.rst @@ -202,6 +202,46 @@ Sometimes one needs to be able not only to catch PPS signals but to produce them also. For example, running a distributed simulation, which requires computers' clock to be synchronized very tightly. +To do so the class pps-gen has been added. PPS generators can be +registered in the kernel by defining a struct pps_gen_source_info as +follows:: + + static struct pps_gen_source_info pps_gen_dummy_info = { + .name = "dummy", + .use_system_clock = true, + .get_time = pps_gen_dummy_get_time, + .enable = pps_gen_dummy_enable, + }; + +Where the use_system_clock states if the generator uses the system +clock to generate its pulses, or they are from a peripheral device +clock. Method get_time() is used to query the time stored into the +generator clock, while the method enable() is used to enable or +disable the PPS pulse generation. + +Then calling the function pps_gen_register_source() in your +initialization routine as follows creates a new generator in the +system:: + + pps_gen = pps_gen_register_source(&pps_gen_dummy_info); + +Generators SYSFS support +------------------------ + +If the SYSFS filesystem is enabled in the kernel it provides a new class:: + + $ ls /sys/class/pps-gen/ + pps-gen0/ pps-gen1/ pps-gen2/ + +Every directory is the ID of a PPS generator defined in the system and +inside of it you find several files:: + + $ ls -F /sys/class/pps-gen/pps-gen0/ + dev enable name power/ subsystem@ system time uevent + +To enable the PPS signal generation you can use the command below:: + + $ echo 1 > /sys/class/pps-gen/pps-gen0/enable Parallel port generator ------------------------ diff --git a/Documentation/driver-api/scsi.rst b/Documentation/driver-api/scsi.rst index 273281474c09..bf2be96cc2d6 100644 --- a/Documentation/driver-api/scsi.rst +++ b/Documentation/driver-api/scsi.rst @@ -126,7 +126,7 @@ Manage scsi_dev_info_list, which tracks blacklisted and whitelisted devices. .. kernel-doc:: drivers/scsi/scsi_devinfo.c - :internal: + :export: drivers/scsi/scsi_ioctl.c ~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -162,7 +162,6 @@ statistics and to pass information directly to the lowlevel driver. I.E. plumbing to manage /proc/scsi/\* .. kernel-doc:: drivers/scsi/scsi_proc.c - :internal: drivers/scsi/scsi_netlink.c ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -193,7 +192,7 @@ else, sequentially scan LUNs up until some maximum is reached, or a LUN is seen that cannot have a device attached to it. .. kernel-doc:: drivers/scsi/scsi_scan.c - :internal: + :export: drivers/scsi/scsi_sysctl.c ~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/edac/features.rst b/Documentation/edac/features.rst new file mode 100644 index 000000000000..3f283de297c7 --- /dev/null +++ b/Documentation/edac/features.rst @@ -0,0 +1,103 @@ +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later + +================= +EDAC/RAS features +================= + +Copyright (c) 2024-2025 HiSilicon Limited. + +:Author: Shiju Jose <shiju.jose@huawei.com> +:License: The GNU Free Documentation License, Version 1.2 without + Invariant Sections, Front-Cover Texts nor Back-Cover Texts. + (dual licensed under the GPL v2) + +- Written for: 6.15 + +Introduction +------------ + +EDAC/RAS components plugging and high-level design: + +1. Scrub control + +2. Error Check Scrub (ECS) control + +3. ACPI RAS2 features + +4. Post Package Repair (PPR) control + +5. Memory Sparing Repair control + +High level design is illustrated in the following diagram:: + + +-----------------------------------------------+ + | Userspace - Rasdaemon | + | +-------------+ | + | | RAS CXL mem | +---------------+ | + | |error handler|---->| | | + | +-------------+ | RAS dynamic | | + | +-------------+ | scrub, memory | | + | | RAS memory |---->| repair control| | + | |error handler| +----|----------+ | + | +-------------+ | | + +--------------------------|--------------------+ + | + | + +-------------------------------|------------------------------+ + | Kernel EDAC extension for | controlling RAS Features | + |+------------------------------|----------------------------+ | + || EDAC Core Sysfs EDAC| Bus | | + || +--------------------------|---------------------------+| | + || |/sys/bus/edac/devices/<dev>/scrubX/ | | EDAC device || | + || |/sys/bus/edac/devices/<dev>/ecsX/ |<->| EDAC MC || | + || |/sys/bus/edac/devices/<dev>/repairX | | EDAC sysfs || | + || +---------------------------|--------------------------+| | + || EDAC|Bus | | + || | | | + || +----------+ Get feature | Get feature | | + || | | desc +---------|------+ desc +----------+ | | + || |EDAC scrub|<-----| EDAC device | | | | | + || +----------+ | driver- RAS |----->| EDAC mem | | | + || +----------+ | feature control| | repair | | | + || | |<-----| | +----------+ | | + || |EDAC ECS | +---------|------+ | | + || +----------+ Register RAS|features | | + || ______________________|_____________ | | + |+---------|---------------|------------------|--------------+ | + | +-------|----+ +-------|-------+ +----|----------+ | + | | | | CXL mem driver| | Client driver | | + | | ACPI RAS2 | | scrub, ECS, | | memory repair | | + | | driver | | sparing, PPR | | features | | + | +-----|------+ +-------|-------+ +------|--------+ | + | | | | | + +--------|-----------------|--------------------|--------------+ + | | | + +--------|-----------------|--------------------|--------------+ + | +---|-----------------|--------------------|-------+ | + | | | | + | | Platform HW and Firmware | | + | +--------------------------------------------------+ | + +--------------------------------------------------------------+ + + +1. EDAC Features components - Create feature-specific descriptors. For + example: scrub, ECS, memory repair in the above diagram. + +2. EDAC device driver for controlling RAS Features - Get feature's attribute + descriptors from EDAC RAS feature component and registers device's RAS + features with EDAC bus and expose the features control attributes via + sysfs. For example, /sys/bus/edac/devices/<dev-name>/<feature>X/ + +3. RAS dynamic feature controller - Userspace sample modules in rasdaemon for + dynamic scrub/repair control to issue scrubbing/repair when excess number + of corrected memory errors are reported in a short span of time. + +RAS features +------------ +1. Memory Scrub + +Memory scrub features are documented in `Documentation/edac/scrub.rst`. + +2. Memory Repair + +Memory repair features are documented in `Documentation/edac/memory_repair.rst`. diff --git a/Documentation/edac/index.rst b/Documentation/edac/index.rst new file mode 100644 index 000000000000..420c6601dbae --- /dev/null +++ b/Documentation/edac/index.rst @@ -0,0 +1,12 @@ +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later + +============== +EDAC Subsystem +============== + +.. toctree:: + :maxdepth: 1 + + features + memory_repair + scrub diff --git a/Documentation/edac/memory_repair.rst b/Documentation/edac/memory_repair.rst new file mode 100644 index 000000000000..52162a422864 --- /dev/null +++ b/Documentation/edac/memory_repair.rst @@ -0,0 +1,121 @@ +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later + +========================== +EDAC Memory Repair Control +========================== + +Copyright (c) 2024-2025 HiSilicon Limited. + +:Author: Shiju Jose <shiju.jose@huawei.com> +:License: The GNU Free Documentation License, Version 1.2 without + Invariant Sections, Front-Cover Texts nor Back-Cover Texts. + (dual licensed under the GPL v2) +:Original Reviewers: + +- Written for: 6.15 + +Introduction +------------ + +Some memory devices support repair operations to address issues in their +memory media. Post Package Repair (PPR) and memory sparing are examples of +such features. + +Post Package Repair (PPR) +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Post Package Repair is a maintenance operation which requests the memory +device to perform repair operation on its media. It is a memory self-healing +feature that fixes a failing memory location by replacing it with a spare row +in a DRAM device. + +For example, a CXL memory device with DRAM components that support PPR +features implements maintenance operations. DRAM components support those +types of PPR functions: + + - hard PPR, for a permanent row repair, and + - soft PPR, for a temporary row repair. + +Soft PPR is much faster than hard PPR, but the repair is lost after a power +cycle. + +The data may not be retained and memory requests may not be correctly +processed during a repair operation. In such case, the repair operation should +not be executed at runtime. + +For example, for CXL memory devices, see CXL spec rev 3.1 [1]_ sections +8.2.9.7.1.1 PPR Maintenance Operations, 8.2.9.7.1.2 sPPR Maintenance Operation +and 8.2.9.7.1.3 hPPR Maintenance Operation for more details. + +Memory Sparing +~~~~~~~~~~~~~~ + +Memory sparing is a repair function that replaces a portion of memory with +a portion of functional memory at a particular granularity. Memory +sparing has cacheline/row/bank/rank sparing granularities. For example, in +rank memory-sparing mode, one memory rank serves as a spare for other ranks on +the same channel in case they fail. + +The spare rank is held in reserve and not used as active memory until +a failure is indicated, with reserved capacity subtracted from the total +available memory in the system. + +After an error threshold is surpassed in a system protected by memory sparing, +the content of a failing rank of DIMMs is copied to the spare rank. The +failing rank is then taken offline and the spare rank placed online for use as +active memory in place of the failed rank. + +For example, CXL memory devices can support various subclasses for sparing +operation vary in terms of the scope of the sparing being performed. + +Cacheline sparing subclass refers to a sparing action that can replace a full +cacheline. Row sparing is provided as an alternative to PPR sparing functions +and its scope is that of a single DDR row. Bank sparing allows an entire bank +to be replaced. Rank sparing is defined as an operation in which an entire DDR +rank is replaced. + +See CXL spec 3.1 [1]_ section 8.2.9.7.1.4 Memory Sparing Maintenance +Operations for more details. + +.. [1] https://computeexpresslink.org/cxl-specification/ + +Use cases of generic memory repair features control +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +1. The soft PPR, hard PPR and memory-sparing features share similar control + attributes. Therefore, there is a need for a standardized, generic sysfs + repair control that is exposed to userspace and used by administrators, + scripts and tools. + +2. When a CXL device detects an error in a memory component, it informs the + host of the need for a repair maintenance operation by using an event + record where the "maintenance needed" flag is set. The event record + specifies the device physical address (DPA) and attributes of the memory + that requires repair. The kernel reports the corresponding CXL general + media or DRAM trace event to userspace, and userspace tools (e.g. + rasdaemon) initiate a repair maintenance operation in response to the + device request using the sysfs repair control. + +3. Userspace tools, such as rasdaemon, request a repair operation on a memory + region when maintenance need flag set or an uncorrected memory error or + excess of corrected memory errors above a threshold value is reported or an + exceed corrected errors threshold flag set for that memory. + +4. Multiple PPR/sparing instances may be present per memory device. + +5. Drivers should enforce that live repair is safe. In systems where memory + mapping functions can change between boots, one approach to this is to log + memory errors seen on this boot against which to check live memory repair + requests. + +The File System +--------------- + +The control attributes of a registered memory repair instance could be +accessed in the /sys/bus/edac/devices/<dev-name>/mem_repairX/ + +sysfs +----- + +Sysfs files are documented in +`Documentation/ABI/testing/sysfs-edac-memory-repair`. diff --git a/Documentation/edac/scrub.rst b/Documentation/edac/scrub.rst new file mode 100644 index 000000000000..daab929cdba1 --- /dev/null +++ b/Documentation/edac/scrub.rst @@ -0,0 +1,266 @@ +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later + +============= +Scrub Control +============= + +Copyright (c) 2024-2025 HiSilicon Limited. + +:Author: Shiju Jose <shiju.jose@huawei.com> +:License: The GNU Free Documentation License, Version 1.2 without + Invariant Sections, Front-Cover Texts nor Back-Cover Texts. + (dual licensed under the GPL v2) + +- Written for: 6.15 + +Introduction +------------ + +Increasing DRAM size and cost have made memory subsystem reliability an +important concern. These modules are used where potentially corrupted data +could cause expensive or fatal issues. Memory errors are among the top +hardware failures that cause server and workload crashes. + +Memory scrubbing is a feature where an ECC (Error-Correcting Code) engine +reads data from each memory media location, corrects if necessary and writes +the corrected data back to the same memory media location. + +DIMMs can be scrubbed at a configurable rate to detect uncorrected memory +errors and attempt recovery from detected errors, providing the following +benefits: + +1. Proactively scrubbing DIMMs reduces the chance of a correctable error + becoming uncorrectable. + +2. When detected, uncorrected errors caught in unallocated memory pages are + isolated and prevented from being allocated to an application or the OS. + +3. This reduces the likelihood of software or hardware products encountering + memory errors. + +4. The additional data on failures in memory may be used to build up + statistics that are later used to decide whether to use memory repair + technologies such as Post Package Repair or Sparing. + +There are 2 types of memory scrubbing: + +1. Background (patrol) scrubbing while the DRAM is otherwise idle. + +2. On-demand scrubbing for a specific address range or region of memory. + +Several types of interfaces to hardware memory scrubbers have been +identified, such as CXL memory device patrol scrub, CXL DDR5 ECS, ACPI +RAS2 memory scrubbing, and ACPI NVDIMM ARS (Address Range Scrub). + +The control mechanisms vary across different memory scrubbers. To enable +standardized userspace tooling, there is a need to present these controls +through a standardized ABI. + +A generic memory EDAC scrub control allows users to manage underlying +scrubbers in the system through a standardized sysfs control interface. It +abstracts the management of various scrubbing functionalities into a unified +set of functions. + +Use cases of common scrub control feature +----------------------------------------- + +1. Several types of interfaces for hardware memory scrubbers have been + identified, including the CXL memory device patrol scrub, CXL DDR5 ECS, + ACPI RAS2 memory scrubbing features, ACPI NVDIMM ARS (Address Range Scrub), + and software-based memory scrubbers. + + Of the identified interfaces to hardware memory scrubbers some support + control over patrol (background) scrubbing (e.g., ACPI RAS2, CXL) and/or + on-demand scrubbing (e.g., ACPI RAS2, ACPI ARS). However, the scrub control + interfaces vary between memory scrubbers, highlighting the need for + a standardized, generic sysfs scrub control interface that is accessible to + userspace for administration and use by scripts/tools. + +2. User-space scrub controls allow users to disable scrubbing if necessary, + for example, to disable background patrol scrubbing or adjust the scrub + rate for performance-aware operations where background activities need to + be minimized or disabled. + +3. User-space tools enable on-demand scrubbing for specific address ranges, + provided that the scrubber supports this functionality. + +4. User-space tools can also control memory DIMM scrubbing at a configurable + scrub rate via sysfs scrub controls. This approach offers several benefits: + + 4.1. Detects uncorrectable memory errors early, before user access to affected + memory, helping facilitate recovery. + + 4.2. Reduces the likelihood of correctable errors developing into uncorrectable + errors. + +5. Policy control for hotplugged memory is necessary because there may not + be a system-wide BIOS or similar control to manage scrub settings for a CXL + device added after boot. Determining these settings is a policy decision, + balancing reliability against performance, so userspace should control it. + Therefore, a unified interface is recommended for handling this function in + a way that aligns with other similar interfaces, rather than creating a + separate one. + +Scrubbing features +------------------ + +CXL Memory Scrubbing features +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +CXL spec r3.1 [1]_ section 8.2.9.9.11.1 describes the memory device patrol +scrub control feature. The device patrol scrub proactively locates and makes +corrections to errors in regular cycle. The patrol scrub control allows the +userspace request to change CXL patrol scrubber's configurations. + +The patrol scrub control allows the requester to specify the number of +hours in which the patrol scrub cycles must be completed, provided that +the requested scrub rate must be within the supported range of the +scrub rate that the device is capable of. In the CXL driver, the +number of seconds per scrub cycles, which user requests via sysfs, is +rescaled to hours per scrub cycles. + +In addition, they allow the host to disable the feature in case it interferes +with performance-aware operations which require the background operations to +be turned off. + +Error Check Scrub (ECS) +~~~~~~~~~~~~~~~~~~~~~~~ + +CXL spec r3.1 [1]_ section 8.2.9.9.11.2 describes Error Check Scrub (ECS) +- a feature defined in the JEDEC DDR5 SDRAM Specification (JESD79-5) and +allowing DRAM to internally read, correct single-bit errors, and write back +corrected data bits to the DRAM array while providing transparency to error +counts. + +The DDR5 device contains number of memory media Field Replaceable Units (FRU) +per device. The DDR5 ECS feature and thus the ECS control driver supports +configuring the ECS parameters per FRU. + +ACPI RAS2 Hardware-based Memory Scrubbing +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ACPI spec 6.5 [2]_ section 5.2.21 ACPI RAS2 describes an ACPI RAS2 table +which provides interfaces for platform RAS features and supports independent +RAS controls and capabilities for a given RAS feature for multiple instances +of the same component in a given system. + +Memory RAS features apply to RAS capabilities, controls and operations that +are specific to memory. RAS2 PCC sub-spaces for memory-specific RAS features +have a Feature Type of 0x00 (Memory). + +The platform can use the hardware-based memory scrubbing feature to expose +controls and capabilities associated with hardware-based memory scrub +engines. The RAS2 memory scrubbing feature supports as per spec, + +1. Independent memory scrubbing controls for each NUMA domain, identified + using its proximity domain. + +2. Provision for background (patrol) scrubbing of the entire memory system, + as well as on-demand scrubbing for a specific region of memory. + +ACPI Address Range Scrubbing (ARS) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ACPI spec 6.5 [2]_ section 9.19.7.2 describes Address Range Scrubbing (ARS). +ARS allows the platform to communicate memory errors to system software. +This capability allows system software to prevent accesses to addresses with +uncorrectable errors in memory. ARS functions manage all NVDIMMs present in +the system. Only one scrub can be in progress system wide at any given time. + +The following functions are supported as per the specification: + +1. Query ARS Capabilities for a given address range, indicates platform + supports the ACPI NVDIMM Root Device Unconsumed Error Notification. + +2. Start ARS triggers an Address Range Scrub for the given memory range. + Address scrubbing can be done for volatile or persistent memory, or both. + +3. Query ARS Status command allows software to get the status of ARS, + including the progress of ARS and ARS error record. + +4. Clear Uncorrectable Error. + +5. Translate SPA + +6. ARS Error Inject etc. + +The kernel supports an existing control for ARS and ARS is currently not +supported in EDAC. + +.. [1] https://computeexpresslink.org/cxl-specification/ + +.. [2] https://uefi.org/specs/ACPI/6.5/ + +Comparison of various scrubbing features +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +--------------+-----------+-----------+-----------+-----------+ + | | ACPI | CXL patrol| CXL ECS | ARS | + | Name | RAS2 | scrub | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | On-demand | Supported | No | No | Supported | + | Scrubbing | | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Background | Supported | Supported | Supported | No | + | scrubbing | | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Mode of | Scrub ctrl| per device| per memory| Unknown | + | scrubbing | per NUMA | | media | | + | | domain. | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Query scrub | Supported | Supported | Supported | Supported | + | capabilities | | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Setting | Supported | No | No | Supported | + | address range| | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Setting | Supported | Supported | No | No | + | scrub rate | | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Unit for | Not | in hours | No | No | + | scrub rate | Defined | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | Supported | | | | + | Scrub | on-demand | No | No | Supported | + | status/ | scrubbing | | | | + | Completion | only | | | | + +--------------+-----------+-----------+-----------+-----------+ + | UC error | |CXL general|CXL general| ACPI UCE | + | reporting | Exception |media/DRAM |media/DRAM | notify and| + | | |event/media|event/media| query | + | | |scan? |scan? | ARS status| + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Support for | Supported | Supported | Supported | No | + | EDAC control | | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + +The File System +--------------- + +The control attributes of a registered scrubber instance could be +accessed in: + +/sys/bus/edac/devices/<dev-name>/scrubX/ + +sysfs +----- + +Sysfs files are documented in +`Documentation/ABI/testing/sysfs-edac-scrub` + +`Documentation/ABI/testing/sysfs-edac-ecs` diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt index 02febc883588..d937b7a03575 100644 --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt @@ -20,7 +20,7 @@ | openrisc: | TODO | | parisc: | ok | | powerpc: | ok | - | riscv: | ok | + | riscv: | TODO | | s390: | ok | | sh: | TODO | | sparc: | TODO | diff --git a/Documentation/features/list-arch.sh b/Documentation/features/list-arch.sh index e73aa35848f0..ac8ff7f6f859 100755 --- a/Documentation/features/list-arch.sh +++ b/Documentation/features/list-arch.sh @@ -6,6 +6,6 @@ # (If no arguments are given then it will print the host architecture's status.) # -ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/')} +ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/' | sed 's/s390x/s390/')} $(dirname $0)/../../scripts/get_feat.pl list --arch $ARCH diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst index 2bbf68b56b0d..3078f3c9256a 100644 --- a/Documentation/filesystems/9p.rst +++ b/Documentation/filesystems/9p.rst @@ -90,7 +90,7 @@ Just start the 9pfs capable network server like diod/nfs-ganesha e.g.:: $ diod -f -n -d 0 -S -l 0.0.0.0:9999 -e $PWD -Optionaly scan your bus if there are more then one usbg gadgets to find their path:: +Optionally scan your bus if there are more then one usbg gadgets to find their path:: $ python $kernel_dir/tools/usb/p9_fwd.py list diff --git a/Documentation/filesystems/bcachefs/SubmittingPatches.rst b/Documentation/filesystems/bcachefs/SubmittingPatches.rst new file mode 100644 index 000000000000..4b79ca58faf2 --- /dev/null +++ b/Documentation/filesystems/bcachefs/SubmittingPatches.rst @@ -0,0 +1,98 @@ +Submitting patches to bcachefs: +=============================== + +Patches must be tested before being submitted, either with the xfstests suite +[0], or the full bcachefs test suite in ktest [1], depending on what's being +touched. Note that ktest wraps xfstests and will be an easier method to running +it for most users; it includes single-command wrappers for all the mainstream +in-kernel local filesystems. + +Patches will undergo more testing after being merged (including +lockdep/kasan/preempt/etc. variants), these are not generally required to be +run by the submitter - but do put some thought into what you're changing and +which tests might be relevant, e.g. are you dealing with tricky memory layout +work? kasan, are you doing locking work? then lockdep; and ktest includes +single-command variants for the debug build types you'll most likely need. + +The exception to this rule is incomplete WIP/RFC patches: if you're working on +something nontrivial, it's encouraged to send out a WIP patch to let people +know what you're doing and make sure you're on the right track. Just make sure +it includes a brief note as to what's done and what's incomplete, to avoid +confusion. + +Rigorous checkpatch.pl adherence is not required (many of its warnings are +considered out of date), but try not to deviate too much without reason. + +Focus on writing code that reads well and is organized well; code should be +aesthetically pleasing. + +CI: +=== + +Instead of running your tests locally, when running the full test suite it's +preferable to let a server farm do it in parallel, and then have the results +in a nice test dashboard (which can tell you which failures are new, and +presents results in a git log view, avoiding the need for most bisecting). + +That exists [2], and community members may request an account. If you work for +a big tech company, you'll need to help out with server costs to get access - +but the CI is not restricted to running bcachefs tests: it runs any ktest test +(which generally makes it easy to wrap other tests that can run in qemu). + +Other things to think about: +============================ + +- How will we debug this code? Is there sufficient introspection to diagnose + when something starts acting wonky on a user machine? + + We don't necessarily need every single field of every data structure visible + with introspection, but having the important fields of all the core data + types wired up makes debugging drastically easier - a bit of thoughtful + foresight greatly reduces the need to have people build custom kernels with + debug patches. + + More broadly, think about all the debug tooling that might be needed. + +- Does it make the codebase more or less of a mess? Can we also try to do some + organizing, too? + +- Do new tests need to be written? New assertions? How do we know and verify + that the code is correct, and what happens if something goes wrong? + + We don't yet have automated code coverage analysis or easy fault injection - + but for now, pretend we did and ask what they might tell us. + + Assertions are hugely important, given that we don't yet have a systems + language that can do ergonomic embedded correctness proofs. Hitting an assert + in testing is much better than wandering off into undefined behaviour la-la + land - use them. Use them judiciously, and not as a replacement for proper + error handling, but use them. + +- Does it need to be performance tested? Should we add new performance counters? + + bcachefs has a set of persistent runtime counters which can be viewed with + the 'bcachefs fs top' command; this should give users a basic idea of what + their filesystem is currently doing. If you're doing a new feature or looking + at old code, think if anything should be added. + +- If it's a new on disk format feature - have upgrades and downgrades been + tested? (Automated tests exists but aren't in the CI, due to the hassle of + disk image management; coordinate to have them run.) + +Mailing list, IRC: +================== + +Patches should hit the list [3], but much discussion and code review happens on +IRC as well [4]; many people appreciate the more conversational approach and +quicker feedback. + +Additionally, we have a lively user community doing excellent QA work, which +exists primarily on IRC. Please make use of that resource; user feedback is +important for any nontrivial feature, and documenting it in commit messages +would be a good idea. + +[0]: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git +[1]: https://evilpiepirate.org/git/ktest.git/ +[2]: https://evilpiepirate.org/~testdashboard/ci/ +[3]: linux-bcachefs@vger.kernel.org +[4]: irc.oftc.net#bcache, #bcachefs-dev diff --git a/Documentation/filesystems/bcachefs/index.rst b/Documentation/filesystems/bcachefs/index.rst index 95fc4b90739e..7db4d7ceab58 100644 --- a/Documentation/filesystems/bcachefs/index.rst +++ b/Documentation/filesystems/bcachefs/index.rst @@ -9,4 +9,5 @@ bcachefs Documentation :numbered: CodingStyle + SubmittingPatches errorcodes diff --git a/Documentation/filesystems/coda.rst b/Documentation/filesystems/coda.rst index bdde7e4e010b..0db3c83a50e5 100644 --- a/Documentation/filesystems/coda.rst +++ b/Documentation/filesystems/coda.rst @@ -141,7 +141,7 @@ kernel support. a process P which accessing a Coda file. It makes a system call which traps to the OS kernel. Examples of such calls trapping to the kernel are ``read``, ``write``, ``open``, ``close``, ``create``, ``mkdir``, - ``rmdir``, ``chmod`` in a Unix ontext. Similar calls exist in the Win32 + ``rmdir``, ``chmod`` in a Unix context. Similar calls exist in the Win32 environment, and are named ``CreateFile``. Generally the operating system handles the request in a virtual diff --git a/Documentation/filesystems/debugfs.rst b/Documentation/filesystems/debugfs.rst index dc35da8b8792..610f718ef8b5 100644 --- a/Documentation/filesystems/debugfs.rst +++ b/Documentation/filesystems/debugfs.rst @@ -211,18 +211,16 @@ seq_file content. There are a couple of other directory-oriented helper functions:: - struct dentry *debugfs_rename(struct dentry *old_dir, - struct dentry *old_dentry, - struct dentry *new_dir, - const char *new_name); + struct dentry *debugfs_change_name(struct dentry *dentry, + const char *fmt, ...); struct dentry *debugfs_create_symlink(const char *name, struct dentry *parent, const char *target); -A call to debugfs_rename() will give a new name to an existing debugfs -file, possibly in a different directory. The new_name must not exist prior -to the call; the return value is old_dentry with updated information. +A call to debugfs_change_name() will give a new name to an existing debugfs +file, always in the same directory. The new_name must not exist prior +to the call; the return value is 0 on success and -E... on failure. Symbolic links can be created with debugfs_create_symlink(). There is one important thing that all debugfs users must take into account: diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 04eaab01314b..e80329908549 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -137,9 +137,8 @@ However, these ioctls have some limitations: - In general, decrypted contents and filenames in the kernel VFS caches are freed but not wiped. Therefore, portions thereof may be recoverable from freed memory, even after the corresponding key(s) - were wiped. To partially solve this, you can set - CONFIG_PAGE_POISONING=y in your kernel config and add page_poison=1 - to your kernel command line. However, this has a performance cost. + were wiped. To partially solve this, you can add init_on_free=1 to + your kernel command line. However, this has a performance cost. - Secret keys might still exist in CPU registers, in crypto accelerator hardware (if used by the crypto API to implement any of @@ -428,11 +427,8 @@ API, but the filenames mode still does. - Mandatory: - CONFIG_CRYPTO_ADIANTUM - Recommended: - - arm32: CONFIG_CRYPTO_CHACHA20_NEON - arm32: CONFIG_CRYPTO_NHPOLY1305_NEON - - arm64: CONFIG_CRYPTO_CHACHA20_NEON - arm64: CONFIG_CRYPTO_NHPOLY1305_NEON - - x86: CONFIG_CRYPTO_CHACHA20_X86_64 - x86: CONFIG_CRYPTO_NHPOLY1305_SSE2 - x86: CONFIG_CRYPTO_NHPOLY1305_AVX2 diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst index 76e538217868..dacdbc1149e6 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -248,11 +248,17 @@ FS_IOC_READ_VERITY_METADATA The FS_IOC_READ_VERITY_METADATA ioctl reads verity metadata from a verity file. This ioctl is available since Linux v5.12. -This ioctl allows writing a server program that takes a verity file -and serves it to a client program, such that the client can do its own -fs-verity compatible verification of the file. This only makes sense -if the client doesn't trust the server and if the server needs to -provide the storage for the client. +This ioctl is useful for cases where the verity verification should be +performed somewhere other than the currently running kernel. + +One example is a server program that takes a verity file and serves it +to a client program, such that the client can do its own fs-verity +compatible verification of the file. This only makes sense if the +client doesn't trust the server and if the server needs to provide the +storage for the client. + +Another example is copying verity metadata when creating filesystem +images in userspace (such as with ``mkfs.ext4 -d``). This is a fairly specialized use case, and most fs-verity users won't need this ioctl. diff --git a/Documentation/filesystems/fuse-io-uring.rst b/Documentation/filesystems/fuse-io-uring.rst new file mode 100644 index 000000000000..d73dd0dbd238 --- /dev/null +++ b/Documentation/filesystems/fuse-io-uring.rst @@ -0,0 +1,99 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================= +FUSE-over-io-uring design documentation +======================================= + +This documentation covers basic details how the fuse +kernel/userspace communication through io-uring is configured +and works. For generic details about FUSE see fuse.rst. + +This document also covers the current interface, which is +still in development and might change. + +Limitations +=========== +As of now not all requests types are supported through io-uring, userspace +is required to also handle requests through /dev/fuse after io-uring setup +is complete. Specifically notifications (initiated from the daemon side) +and interrupts. + +Fuse io-uring configuration +=========================== + +Fuse kernel requests are queued through the classical /dev/fuse +read/write interface - until io-uring setup is complete. + +In order to set up fuse-over-io-uring fuse-server (user-space) +needs to submit SQEs (opcode = IORING_OP_URING_CMD) to the /dev/fuse +connection file descriptor. Initial submit is with the sub command +FUSE_URING_REQ_REGISTER, which will just register entries to be +available in the kernel. + +Once at least one entry per queue is submitted, kernel starts +to enqueue to ring queues. +Note, every CPU core has its own fuse-io-uring queue. +Userspace handles the CQE/fuse-request and submits the result as +subcommand FUSE_URING_REQ_COMMIT_AND_FETCH - kernel completes +the requests and also marks the entry available again. If there are +pending requests waiting the request will be immediately submitted +to the daemon again. + +Initial SQE +-----------:: + + | | FUSE filesystem daemon + | | + | | >io_uring_submit() + | | IORING_OP_URING_CMD / + | | FUSE_URING_CMD_REGISTER + | | [wait cqe] + | | >io_uring_wait_cqe() or + | | >io_uring_submit_and_wait() + | | + | >fuse_uring_cmd() | + | >fuse_uring_register() | + + +Sending requests with CQEs +--------------------------:: + + | | FUSE filesystem daemon + | | [waiting for CQEs] + | "rm /mnt/fuse/file" | + | | + | >sys_unlink() | + | >fuse_unlink() | + | [allocate request] | + | >fuse_send_one() | + | ... | + | >fuse_uring_queue_fuse_req | + | [queue request on fg queue] | + | >fuse_uring_add_req_to_ring_ent() | + | ... | + | >fuse_uring_copy_to_ring() | + | >io_uring_cmd_done() | + | >request_wait_answer() | + | [sleep on req->waitq] | + | | [receives and handles CQE] + | | [submit result and fetch next] + | | >io_uring_submit() + | | IORING_OP_URING_CMD/ + | | FUSE_URING_CMD_COMMIT_AND_FETCH + | >fuse_uring_cmd() | + | >fuse_uring_commit_fetch() | + | >fuse_uring_commit() | + | >fuse_uring_copy_from_ring() | + | [ copy the result to the fuse req] | + | >fuse_uring_req_end() | + | >fuse_request_end() | + | [wake up req->waitq] | + | >fuse_uring_next_fuse_req | + | [wait or handle next req] | + | | + | [req->waitq woken up] | + | <fuse_unlink() | + | <sys_unlink() | + + + diff --git a/Documentation/filesystems/idmappings.rst b/Documentation/filesystems/idmappings.rst index 77930c77fcfe..2a206129f828 100644 --- a/Documentation/filesystems/idmappings.rst +++ b/Documentation/filesystems/idmappings.rst @@ -63,8 +63,8 @@ what id ``k11000`` corresponds to in the second or third idmapping. The straightforward algorithm to use is to apply the inverse of the first idmapping, mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using either the second idmapping mapping or third idmapping mapping. The second -idmapping would map ``u1000`` down to ``21000``. The third idmapping would map -``u1000`` down to ``u31000``. +idmapping would map ``u1000`` down to ``k21000``. The third idmapping would map +``u1000`` down to ``k31000``. If we were given the same task for the following three idmappings:: diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index 44e9e77ffe0d..a9cf8e950b15 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -98,6 +98,7 @@ Documentation for filesystem implementations. hpfs fuse fuse-io + fuse-io-uring inotify isofs nilfs2 @@ -117,7 +118,6 @@ Documentation for filesystem implementations. spufs/index squashfs sysfs - sysv-fs tmpfs ubifs ubifs-authentication diff --git a/Documentation/filesystems/iomap/design.rst b/Documentation/filesystems/iomap/design.rst index b0d0188a095e..e29651a42eec 100644 --- a/Documentation/filesystems/iomap/design.rst +++ b/Documentation/filesystems/iomap/design.rst @@ -246,6 +246,10 @@ The fields are as follows: * **IOMAP_F_PRIVATE**: Starting with this value, the upper bits can be set by the filesystem for its own purposes. + * **IOMAP_F_ANON_WRITE**: Indicates that (write) I/O does not have a target + block assigned to it yet and the file system will do that in the bio + submission handler, splitting the I/O as needed. + These flags can be set by iomap itself during file operations. The filesystem should supply an ``->iomap_end`` function if it needs to observe these flags: @@ -352,6 +356,11 @@ operations: ``IOMAP_NOWAIT`` is often set on behalf of ``IOCB_NOWAIT`` or ``RWF_NOWAIT``. + * ``IOMAP_DONTCACHE`` is set when the caller wishes to perform a + buffered file I/O and would like the kernel to drop the pagecache + after the I/O completes, if it isn't already being used by another + thread. + If it is necessary to read existing file contents from a `different <https://lore.kernel.org/all/20191008071527.29304-9-hch@lst.de/>`_ device or address range on a device, the filesystem should return that diff --git a/Documentation/filesystems/iomap/operations.rst b/Documentation/filesystems/iomap/operations.rst index ef082e5a4e0c..3b628e370d88 100644 --- a/Documentation/filesystems/iomap/operations.rst +++ b/Documentation/filesystems/iomap/operations.rst @@ -104,7 +104,7 @@ iomap calls these functions: For the pagecache, races can happen if writeback doesn't take ``i_rwsem`` or ``invalidate_lock`` and updates mapping information. - Races can also happen if the filesytem allows concurrent writes. + Races can also happen if the filesystem allows concurrent writes. For such files, the mapping *must* be revalidated after the folio lock has been taken so that iomap can manage the folio correctly. @@ -131,6 +131,8 @@ These ``struct kiocb`` flags are significant for buffered I/O with iomap: * ``IOCB_NOWAIT``: Turns on ``IOMAP_NOWAIT``. + * ``IOCB_DONTCACHE``: Turns on ``IOMAP_DONTCACHE``. + Internal per-Folio State ------------------------ @@ -283,7 +285,7 @@ The ``ops`` structure must be specified and is as follows: struct iomap_writeback_ops { int (*map_blocks)(struct iomap_writepage_ctx *wpc, struct inode *inode, loff_t offset, unsigned len); - int (*prepare_ioend)(struct iomap_ioend *ioend, int status); + int (*submit_ioend)(struct iomap_writepage_ctx *wpc, int status); void (*discard_folio)(struct folio *folio, loff_t pos); }; @@ -306,13 +308,12 @@ The fields are as follows: purpose. This function must be supplied by the filesystem. - - ``prepare_ioend``: Enables filesystems to transform the writeback - ioend or perform any other preparatory work before the writeback I/O - is submitted. + - ``submit_ioend``: Allows the file systems to hook into writeback bio + submission. This might include pre-write space accounting updates, or installing a custom ``->bi_end_io`` function for internal purposes, such as deferring the ioend completion to a workqueue to run metadata update - transactions from process context. + transactions from process context before submitting the bio. This function is optional. - ``discard_folio``: iomap calls this function after ``->map_blocks`` @@ -341,7 +342,7 @@ This can happen in interrupt or process context, depending on the storage device. Filesystems that need to update internal bookkeeping (e.g. unwritten -extent conversions) should provide a ``->prepare_ioend`` function to +extent conversions) should provide a ``->submit_ioend`` function to set ``struct iomap_end::bio::bi_end_io`` to its own function. This function should call ``iomap_finish_ioends`` after finishing its own work (e.g. unwritten extent conversion). @@ -515,18 +516,33 @@ IOMAP_WRITE`` with any combination of the following enhancements: * ``IOMAP_ATOMIC``: This write is being issued with torn-write protection. - Only a single bio can be created for the write, and the write must - not be split into multiple I/O requests, i.e. flag REQ_ATOMIC must be - set. + Torn-write protection may be provided based on HW-offload or by a + software mechanism provided by the filesystem. + + For HW-offload based support, only a single bio can be created for the + write, and the write must not be split into multiple I/O requests, i.e. + flag REQ_ATOMIC must be set. The file range to write must be aligned to satisfy the requirements of both the filesystem and the underlying block device's atomic commit capabilities. If filesystem metadata updates are required (e.g. unwritten extent - conversion or copy on write), all updates for the entire file range + conversion or copy-on-write), all updates for the entire file range must be committed atomically as well. - Only one space mapping is allowed per untorn write. - Untorn writes must be aligned to, and must not be longer than, a - single file block. + Untorn-writes may be longer than a single file block. In all cases, + the mapping start disk block must have at least the same alignment as + the write offset. + The filesystems must set IOMAP_F_ATOMIC_BIO to inform iomap core of an + untorn-write based on HW-offload. + + For untorn-writes based on a software mechanism provided by the + filesystem, all the disk block alignment and single bio restrictions + which apply for HW-offload based untorn-writes do not apply. + The mechanism would typically be used as a fallback for when + HW-offload based untorn-writes may not be issued, e.g. the range of the + write covers multiple extents, meaning that it is not possible to issue + a single bio. + All filesystem metadata updates for the entire file range must be + committed atomically as well. Callers commonly hold ``i_rwsem`` in shared or exclusive mode before calling this function. diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index f5e3676db954..0ec0bb6eb0fb 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -17,7 +17,8 @@ dentry_operations prototypes:: - int (*d_revalidate)(struct dentry *, unsigned int); + int (*d_revalidate)(struct inode *, const struct qstr *, + struct dentry *, unsigned int); int (*d_weak_revalidate)(struct dentry *, unsigned int); int (*d_hash)(const struct dentry *, struct qstr *); int (*d_compare)(const struct dentry *, @@ -30,6 +31,8 @@ prototypes:: struct vfsmount *(*d_automount)(struct path *path); int (*d_manage)(const struct path *, bool); struct dentry *(*d_real)(struct dentry *, enum d_real_type type); + bool (*d_unalias_trylock)(const struct dentry *); + void (*d_unalias_unlock)(const struct dentry *); locking rules: @@ -49,6 +52,8 @@ d_dname: no no no no d_automount: no no yes no d_manage: no no yes (ref-walk) maybe d_real no no yes no +d_unalias_trylock yes no no no +d_unalias_unlock yes no no no ================== =========== ======== ============== ======== inode_operations @@ -61,7 +66,7 @@ prototypes:: int (*link) (struct dentry *,struct inode *,struct dentry *); int (*unlink) (struct inode *,struct dentry *); int (*symlink) (struct mnt_idmap *, struct inode *,struct dentry *,const char *); - int (*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t); + struct dentry *(*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t); int (*rmdir) (struct inode *,struct dentry *); int (*mknod) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t,dev_t); int (*rename) (struct mnt_idmap *, struct inode *, struct dentry *, diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 73f0bfd7e903..3886c14f89f4 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -515,7 +515,7 @@ The methods defined in the table are: the cache to expand a request in either direction. This allows the cache to size the request appropriately for the cache granularity. - The function is passed poiners to the start and length in its parameters, + The function is passed pointers to the start and length in its parameters, plus the size of the file for reference, and adjusts the start and length appropriately. It should return one of: diff --git a/Documentation/filesystems/nfs/localio.rst b/Documentation/filesystems/nfs/localio.rst index bd1967e2eab3..79808b37d745 100644 --- a/Documentation/filesystems/nfs/localio.rst +++ b/Documentation/filesystems/nfs/localio.rst @@ -218,64 +218,30 @@ NFS Client and Server Interlock =============================== LOCALIO provides the nfs_uuid_t object and associated interfaces to -allow proper network namespace (net-ns) and NFSD object refcounting: - - We don't want to keep a long-term counted reference on each NFSD's - net-ns in the client because that prevents a server container from - completely shutting down. - - So we avoid taking a reference at all and rely on the per-cpu - reference to the server (detailed below) being sufficient to keep - the net-ns active. This involves allowing the NFSD's net-ns exit - code to iterate all active clients and clear their ->net pointers - (which are needed to find the per-cpu-refcount for the nfsd_serv). - - Details: - - - Embed nfs_uuid_t in nfs_client. nfs_uuid_t provides a list_head - that can be used to find the client. It does add the 16-byte - uuid_t to nfs_client so it is bigger than needed (given that - uuid_t is only used during the initial NFS client and server - LOCALIO handshake to determine if they are local to each other). - If that is really a problem we can find a fix. - - - When the nfs server confirms that the uuid_t is local, it moves - the nfs_uuid_t onto a per-net-ns list in NFSD's nfsd_net. - - - When each server's net-ns is shutting down - in a "pre_exit" - handler, all these nfs_uuid_t have their ->net cleared. There is - an rcu_synchronize() call between pre_exit() handlers and exit() - handlers so any caller that sees nfs_uuid_t ->net as not NULL can - safely manage the per-cpu-refcount for nfsd_serv. - - - The client's nfs_uuid_t is passed to nfsd_open_local_fh() so it - can safely dereference ->net in a private rcu_read_lock() section - to allow safe access to the associated nfsd_net and nfsd_serv. - -So LOCALIO required the introduction and use of NFSD's percpu_ref to -interlock nfsd_destroy_serv() and nfsd_open_local_fh(), to ensure each -nn->nfsd_serv is not destroyed while in use by nfsd_open_local_fh(), and +allow proper network namespace (net-ns) and NFSD object refcounting. + +LOCALIO required the introduction and use of NFSD's percpu nfsd_net_ref +to interlock nfsd_shutdown_net() and nfsd_open_local_fh(), to ensure +each net-ns is not destroyed while in use by nfsd_open_local_fh(), and warrants a more detailed explanation: - nfsd_open_local_fh() uses nfsd_serv_try_get() before opening its + nfsd_open_local_fh() uses nfsd_net_try_get() before opening its nfsd_file handle and then the caller (NFS client) must drop the - reference for the nfsd_file and associated nn->nfsd_serv using - nfs_file_put_local() once it has completed its IO. + reference for the nfsd_file and associated net-ns using + nfsd_file_put_local() once it has completed its IO. This interlock working relies heavily on nfsd_open_local_fh() being afforded the ability to safely deal with the possibility that the NFSD's net-ns (and nfsd_net by association) may have been destroyed - by nfsd_destroy_serv() via nfsd_shutdown_net() -- which is only - possible given the nfs_uuid_t ->net pointer managemenet detailed - above. - -All told, this elaborate interlock of the NFS client and server has been -verified to fix an easy to hit crash that would occur if an NFSD -instance running in a container, with a LOCALIO client mounted, is -shutdown. Upon restart of the container and associated NFSD the client -would go on to crash due to NULL pointer dereference that occurred due -to the LOCALIO client's attempting to nfsd_open_local_fh(), using -nn->nfsd_serv, without having a proper reference on nn->nfsd_serv. + by nfsd_destroy_serv() via nfsd_shutdown_net(). + +This interlock of the NFS client and server has been verified to fix an +easy to hit crash that would occur if an NFSD instance running in a +container, with a LOCALIO client mounted, is shutdown. Upon restart of +the container and associated NFSD, the client would go on to crash due +to NULL pointer dereference that occurred due to the LOCALIO client's +attempting to nfsd_open_local_fh() without having a proper reference on +NFSD's net-ns. NFS Client issues IO instead of Server ====================================== @@ -306,10 +272,26 @@ is issuing IO to the underlying local filesystem that it is sharing with the NFS server. See: fs/nfs/localio.c:nfs_local_doio() and fs/nfs/localio.c:nfs_local_commit(). +With normal NFS that makes use of RPC to issue IO to the server, if an +application uses O_DIRECT the NFS client will bypass the pagecache but +the NFS server will not. The NFS server's use of buffered IO affords +applications to be less precise with their alignment when issuing IO to +the NFS client. But if all applications properly align their IO, LOCALIO +can be configured to use end-to-end O_DIRECT semantics from the NFS +client to the underlying local filesystem, that it is sharing with +the NFS server, by setting the 'localio_O_DIRECT_semantics' nfs module +parameter to Y, e.g.: + + echo Y > /sys/module/nfs/parameters/localio_O_DIRECT_semantics + +Once enabled, it will cause LOCALIO to use end-to-end O_DIRECT semantics +(but again, this may cause IO to fail if applications do not properly +align their IO). + Security ======== -Localio is only supported when UNIX-style authentication (AUTH_UNIX, aka +LOCALIO is only supported when UNIX-style authentication (AUTH_UNIX, aka AUTH_SYS) is used. Care is taken to ensure the same NFS security mechanisms are used @@ -324,6 +306,24 @@ client is afforded this same level of access (albeit in terms of the NFS protocol via SUNRPC). No other namespaces (user, mount, etc) have been altered or purposely extended from the server to the client. +Module Parameters +================= + +/sys/module/nfs/parameters/localio_enabled (bool) +controls if LOCALIO is enabled, defaults to Y. If client and server are +local but 'localio_enabled' is set to N then LOCALIO will not be used. + +/sys/module/nfs/parameters/localio_O_DIRECT_semantics (bool) +controls if O_DIRECT extends down to the underlying filesystem, defaults +to N. Application IO must be logical blocksize aligned, otherwise +O_DIRECT will fail. + +/sys/module/nfsv3/parameters/nfs3_localio_probe_throttle (uint) +controls if NFSv3 read and write IOs will trigger (re)enabling of +LOCALIO every N (nfs3_localio_probe_throttle) IOs, defaults to 0 +(disabled). Must be power-of-2, admin keeps all the pieces if they +misconfigure (too low a value or non-power-of-2). + Testing ======= diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index 4c8387e1c880..2db379b4b31e 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst @@ -156,7 +156,7 @@ A directory is made opaque by setting the xattr "trusted.overlay.opaque" to "y". Where the upper filesystem contains an opaque directory, any directory in the lower filesystem with the same name is ignored. -An opaque directory should not conntain any whiteouts, because they do not +An opaque directory should not contain any whiteouts, because they do not serve any purpose. A merge directory containing regular files with the xattr "trusted.overlay.whiteout", should be additionally marked by setting the xattr "trusted.overlay.opaque" to "x" on the merge directory itself. @@ -266,7 +266,7 @@ Non-directories Objects that are not directories (files, symlinks, device-special files etc.) are presented either from the upper or lower filesystem as appropriate. When a file in the lower filesystem is accessed in a way -the requires write-access, such as opening for write access, changing +that requires write-access, such as opening for write access, changing some metadata etc., the file is first copied from the lower filesystem to the upper filesystem (copy_up). Note that creating a hard-link also requires copy_up, though of course creation of a symlink does @@ -292,13 +292,27 @@ rename or unlink will of course be noticed and handled). Permission model ---------------- +An overlay filesystem stashes credentials that will be used when +accessing lower or upper filesystems. + +In the old mount api the credentials of the task calling mount(2) are +stashed. In the new mount api the credentials of the task creating the +superblock through FSCONFIG_CMD_CREATE command of fsconfig(2) are +stashed. + +Starting with kernel v6.15 it is possible to use the "override_creds" +mount option which will cause the credentials of the calling task to be +recorded. Note that "override_creds" is only meaningful when used with +the new mount api as the old mount api combines setting options and +superblock creation in a single mount(2) syscall. + Permission checking in the overlay filesystem follows these principles: 1) permission check SHOULD return the same result before and after copy up 2) task creating the overlay mount MUST NOT gain additional privileges - 3) non-mounting task MAY gain additional privileges through the overlay, + 3) task[*] MAY gain additional privileges through the overlay, compared to direct access on underlying lower or upper filesystems This is achieved by performing two permission checks on each access: @@ -306,7 +320,7 @@ This is achieved by performing two permission checks on each access: a) check if current task is allowed access based on local DAC (owner, group, mode and posix acl), as well as MAC checks - b) check if mounting task would be allowed real operation on lower or + b) check if stashed credentials would be allowed real operation on lower or upper layer based on underlying filesystem permissions, again including MAC checks @@ -315,10 +329,10 @@ are copied up. On the other hand it can result in server enforced permissions (used by NFS, for example) being ignored (3). Check (b) ensures that no task gains permissions to underlying layers that -the mounting task does not have (2). This also means that it is possible +the stashed credentials do not have (2). This also means that it is possible to create setups where the consistency rule (1) does not hold; normally, -however, the mounting task will have sufficient privileges to perform all -operations. +however, the stashed credentials will have sufficient privileges to +perform all operations. Another way to demonstrate this model is drawing parallels between:: @@ -549,8 +563,8 @@ Nesting overlayfs mounts It is possible to use a lower directory that is stored on an overlayfs mount. For regular files this does not need any special care. However, files -that have overlayfs attributes, such as whiteouts or "overlay.*" xattrs will be -interpreted by the underlying overlayfs mount and stripped out. In order to +that have overlayfs attributes, such as whiteouts or "overlay.*" xattrs, will +be interpreted by the underlying overlayfs mount and stripped out. In order to allow the second overlayfs mount to see the attributes they must be escaped. Overlayfs specific xattrs are escaped by using a special prefix of diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index 9ab2a3d6f2b4..767b2927c762 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -313,7 +313,7 @@ done. **mandatory** -block truncatation on error exit from ->write_begin, and ->direct_IO +block truncation on error exit from ->write_begin, and ->direct_IO moved from generic methods (block_write_begin, cont_write_begin, nobh_write_begin, blockdev_direct_IO*) to callers. Take a look at ext2_write_failed and callers for an example. @@ -1141,3 +1141,65 @@ pointer are gone. set_blocksize() takes opened struct file instead of struct block_device now and it *must* be opened exclusive. + +--- + +**mandatory** + +->d_revalidate() gets two extra arguments - inode of parent directory and +name our dentry is expected to have. Both are stable (dir is pinned in +non-RCU case and will stay around during the call in RCU case, and name +is guaranteed to stay unchanging). Your instance doesn't have to use +either, but it often helps to avoid a lot of painful boilerplate. +Note that while name->name is stable and NUL-terminated, it may (and +often will) have name->name[name->len] equal to '/' rather than '\0' - +in normal case it points into the pathname being looked up. +NOTE: if you need something like full path from the root of filesystem, +you are still on your own - this assists with simple cases, but it's not +magic. + +--- + +**recommended** + +kern_path_locked() and user_path_locked() no longer return a negative +dentry so this doesn't need to be checked. If the name cannot be found, +ERR_PTR(-ENOENT) is returned. + +--- + +**recommended** + +lookup_one_qstr_excl() is changed to return errors in more cases, so +these conditions don't require explicit checks: + + - if LOOKUP_CREATE is NOT given, then the dentry won't be negative, + ERR_PTR(-ENOENT) is returned instead + - if LOOKUP_EXCL IS given, then the dentry won't be positive, + ERR_PTR(-EEXIST) is rreturned instread + +LOOKUP_EXCL now means "target must not exist". It can be combined with +LOOK_CREATE or LOOKUP_RENAME_TARGET. + +--- + +**mandatory** +invalidate_inodes() is gone use evict_inodes() instead. + +--- + +**mandatory** + +->mkdir() now returns a dentry. If the created inode is found to +already be in cache and have a dentry (often IS_ROOT()), it will need to +be spliced into the given name in place of the given dentry. That dentry +now needs to be returned. If the original dentry is used, NULL should +be returned. Any error should be returned with ERR_PTR(). + +In general, filesystems which use d_instantiate_new() to install the new +inode can safely return NULL. Filesystems which may not have an I_NEW inode +should use d_drop();d_splice_alias() and return the result of the latter. + +If a positive dentry cannot be returned for some reason, in-kernel +clients such as cachefiles, nfsd, smb/server may not perform ideally but +will fail-safe. diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 6a882c57a7e7..09f0aed5a08b 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -48,6 +48,7 @@ fixes/update part 1.1 Stefani Seibold <stefani@seibold.net> June 9 2009 3.11 /proc/<pid>/patch_state - Livepatch patch operation state 3.12 /proc/<pid>/arch_status - Task architecture specific information 3.13 /proc/<pid>/fd - List of symlinks to open files + 3.14 /proc/<pid/ksm_stat - Information about the process's ksm status. 4 Configuring procfs 4.1 Mount options @@ -484,14 +485,15 @@ Memory Area, or VMA) there is a series of lines such as the following:: THPeligible: 0 VmFlags: rd ex mr mw me dw -The first of these lines shows the same information as is displayed for the -mapping in /proc/PID/maps. Following lines show the size of the mapping -(size); the size of each page allocated when backing a VMA (KernelPageSize), -which is usually the same as the size in the page table entries; the page size -used by the MMU when backing a VMA (in most cases, the same as KernelPageSize); -the amount of the mapping that is currently resident in RAM (RSS); the -process' proportional share of this mapping (PSS); and the number of clean and -dirty shared and private pages in the mapping. +The first of these lines shows the same information as is displayed for +the mapping in /proc/PID/maps. Following lines show the size of the +mapping (size); the size of each page allocated when backing a VMA +(KernelPageSize), which is usually the same as the size in the page table +entries; the page size used by the MMU when backing a VMA (in most cases, +the same as KernelPageSize); the amount of the mapping that is currently +resident in RAM (RSS); the process's proportional share of this mapping +(PSS); and the number of clean and dirty shared and private pages in the +mapping. The "proportional set size" (PSS) of a process is the count of pages it has in memory, where each page is divided by the number of processes sharing it. @@ -2232,6 +2234,74 @@ The number of open files for the process is stored in 'size' member of stat() output for /proc/<pid>/fd for fast access. ------------------------------------------------------- +3.14 /proc/<pid/ksm_stat - Information about the process's ksm status +--------------------------------------------------------------------- +When CONFIG_KSM is enabled, each process has this file which displays +the information of ksm merging status. + +Example +~~~~~~~ + +:: + + / # cat /proc/self/ksm_stat + ksm_rmap_items 0 + ksm_zero_pages 0 + ksm_merging_pages 0 + ksm_process_profit 0 + ksm_merge_any: no + ksm_mergeable: no + +Description +~~~~~~~~~~~ + +ksm_rmap_items +^^^^^^^^^^^^^^ + +The number of ksm_rmap_item structures in use. The structure +ksm_rmap_item stores the reverse mapping information for virtual +addresses. KSM will generate a ksm_rmap_item for each ksm-scanned page of +the process. + +ksm_zero_pages +^^^^^^^^^^^^^^ + +When /sys/kernel/mm/ksm/use_zero_pages is enabled, it represent how many +empty pages are merged with kernel zero pages by KSM. + +ksm_merging_pages +^^^^^^^^^^^^^^^^^ + +It represents how many pages of this process are involved in KSM merging +(not including ksm_zero_pages). It is the same with what +/proc/<pid>/ksm_merging_pages shows. + +ksm_process_profit +^^^^^^^^^^^^^^^^^^ + +The profit that KSM brings (Saved bytes). KSM can save memory by merging +identical pages, but also can consume additional memory, because it needs +to generate a number of rmap_items to save each scanned page's brief rmap +information. Some of these pages may be merged, but some may not be abled +to be merged after being checked several times, which are unprofitable +memory consumed. + +ksm_merge_any +^^^^^^^^^^^^^ + +It specifies whether the process's 'mm is added by prctl() into the +candidate list of KSM or not, and if KSM scanning is fully enabled at +process level. + +ksm_mergeable +^^^^^^^^^^^^^ + +It specifies whether any VMAs of the process''s mms are currently +applicable to KSM. + +More information about KSM can be found in +Documentation/admin-guide/mm/ksm.rst. + Chapter 4: Configuring procfs ============================= @@ -2261,7 +2331,7 @@ arguments are now protected against local eavesdroppers. hidepid=invisible or hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible to other users. It doesn't mean that it hides a fact whether a process with a specific pid value exists (it can be learned by other means, e.g. -by "kill -0 $PID"), but it hides process' uid and gid, which may be learned by +by "kill -0 $PID"), but it hides process's uid and gid, which may be learned by stat()'ing /proc/<pid>/ otherwise. It greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether diff --git a/Documentation/filesystems/squashfs.rst b/Documentation/filesystems/squashfs.rst index 4af8d6207509..45653b3228f9 100644 --- a/Documentation/filesystems/squashfs.rst +++ b/Documentation/filesystems/squashfs.rst @@ -6,7 +6,7 @@ Squashfs 4.0 Filesystem Squashfs is a compressed read-only filesystem for Linux. -It uses zlib, lz4, lzo, or xz compression to compress files, inodes and +It uses zlib, lz4, lzo, xz or zstd compression to compress files, inodes and directories. Inodes in the system are very small and all blocks are packed to minimise data overhead. Block sizes greater than 4K are supported up to a maximum of 1Mbytes (default block size 128K). @@ -16,8 +16,8 @@ use (i.e. in cases where a .tar.gz file may be used), and in constrained block device/memory systems (e.g. embedded systems) where low overhead is needed. -Mailing list: squashfs-devel@lists.sourceforge.net -Web site: www.squashfs.org +Mailing list (kernel code): linux-fsdevel@vger.kernel.org +Web site: github.com/plougher/squashfs-tools 1. Filesystem Features ---------------------- @@ -58,11 +58,9 @@ inodes have different sizes). As squashfs is a read-only filesystem, the mksquashfs program must be used to create populated squashfs filesystems. This and other squashfs utilities -can be obtained from http://www.squashfs.org. Usage instructions can be -obtained from this site also. - -The squashfs-tools development tree is now located on kernel.org - git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git +are very likely packaged by your linux distribution (called squashfs-tools). +The source code can be obtained from github.com/plougher/squashfs-tools. +Usage instructions can also be obtained from this site. 2.1 Mount options ----------------- diff --git a/Documentation/filesystems/sysv-fs.rst b/Documentation/filesystems/sysv-fs.rst deleted file mode 100644 index 89e40911ad7c..000000000000 --- a/Documentation/filesystems/sysv-fs.rst +++ /dev/null @@ -1,264 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -================== -SystemV Filesystem -================== - -It implements all of - - Xenix FS, - - SystemV/386 FS, - - Coherent FS. - -To install: - -* Answer the 'System V and Coherent filesystem support' question with 'y' - when configuring the kernel. -* To mount a disk or a partition, use:: - - mount [-r] -t sysv device mountpoint - - The file system type names:: - - -t sysv - -t xenix - -t coherent - - may be used interchangeably, but the last two will eventually disappear. - -Bugs in the present implementation: - -- Coherent FS: - - - The "free list interleave" n:m is currently ignored. - - Only file systems with no filesystem name and no pack name are recognized. - (See Coherent "man mkfs" for a description of these features.) - -- SystemV Release 2 FS: - - The superblock is only searched in the blocks 9, 15, 18, which - corresponds to the beginning of track 1 on floppy disks. No support - for this FS on hard disk yet. - - -These filesystems are rather similar. Here is a comparison with Minix FS: - -* Linux fdisk reports on partitions - - - Minix FS 0x81 Linux/Minix - - Xenix FS ?? - - SystemV FS ?? - - Coherent FS 0x08 AIX bootable - -* Size of a block or zone (data allocation unit on disk) - - - Minix FS 1024 - - Xenix FS 1024 (also 512 ??) - - SystemV FS 1024 (also 512 and 2048) - - Coherent FS 512 - -* General layout: all have one boot block, one super block and - separate areas for inodes and for directories/data. - On SystemV Release 2 FS (e.g. Microport) the first track is reserved and - all the block numbers (including the super block) are offset by one track. - -* Byte ordering of "short" (16 bit entities) on disk: - - - Minix FS little endian 0 1 - - Xenix FS little endian 0 1 - - SystemV FS little endian 0 1 - - Coherent FS little endian 0 1 - - Of course, this affects only the file system, not the data of files on it! - -* Byte ordering of "long" (32 bit entities) on disk: - - - Minix FS little endian 0 1 2 3 - - Xenix FS little endian 0 1 2 3 - - SystemV FS little endian 0 1 2 3 - - Coherent FS PDP-11 2 3 0 1 - - Of course, this affects only the file system, not the data of files on it! - -* Inode on disk: "short", 0 means non-existent, the root dir ino is: - - ================================= == - Minix FS 1 - Xenix FS, SystemV FS, Coherent FS 2 - ================================= == - -* Maximum number of hard links to a file: - - =========== ========= - Minix FS 250 - Xenix FS ?? - SystemV FS ?? - Coherent FS >=10000 - =========== ========= - -* Free inode management: - - - Minix FS - a bitmap - - Xenix FS, SystemV FS, Coherent FS - There is a cache of a certain number of free inodes in the super-block. - When it is exhausted, new free inodes are found using a linear search. - -* Free block management: - - - Minix FS - a bitmap - - Xenix FS, SystemV FS, Coherent FS - Free blocks are organized in a "free list". Maybe a misleading term, - since it is not true that every free block contains a pointer to - the next free block. Rather, the free blocks are organized in chunks - of limited size, and every now and then a free block contains pointers - to the free blocks pertaining to the next chunk; the first of these - contains pointers and so on. The list terminates with a "block number" - 0 on Xenix FS and SystemV FS, with a block zeroed out on Coherent FS. - -* Super-block location: - - =========== ========================== - Minix FS block 1 = bytes 1024..2047 - Xenix FS block 1 = bytes 1024..2047 - SystemV FS bytes 512..1023 - Coherent FS block 1 = bytes 512..1023 - =========== ========================== - -* Super-block layout: - - - Minix FS:: - - unsigned short s_ninodes; - unsigned short s_nzones; - unsigned short s_imap_blocks; - unsigned short s_zmap_blocks; - unsigned short s_firstdatazone; - unsigned short s_log_zone_size; - unsigned long s_max_size; - unsigned short s_magic; - - - Xenix FS, SystemV FS, Coherent FS:: - - unsigned short s_firstdatazone; - unsigned long s_nzones; - unsigned short s_fzone_count; - unsigned long s_fzones[NICFREE]; - unsigned short s_finode_count; - unsigned short s_finodes[NICINOD]; - char s_flock; - char s_ilock; - char s_modified; - char s_rdonly; - unsigned long s_time; - short s_dinfo[4]; -- SystemV FS only - unsigned long s_free_zones; - unsigned short s_free_inodes; - short s_dinfo[4]; -- Xenix FS only - unsigned short s_interleave_m,s_interleave_n; -- Coherent FS only - char s_fname[6]; - char s_fpack[6]; - - then they differ considerably: - - Xenix FS:: - - char s_clean; - char s_fill[371]; - long s_magic; - long s_type; - - SystemV FS:: - - long s_fill[12 or 14]; - long s_state; - long s_magic; - long s_type; - - Coherent FS:: - - unsigned long s_unique; - - Note that Coherent FS has no magic. - -* Inode layout: - - - Minix FS:: - - unsigned short i_mode; - unsigned short i_uid; - unsigned long i_size; - unsigned long i_time; - unsigned char i_gid; - unsigned char i_nlinks; - unsigned short i_zone[7+1+1]; - - - Xenix FS, SystemV FS, Coherent FS:: - - unsigned short i_mode; - unsigned short i_nlink; - unsigned short i_uid; - unsigned short i_gid; - unsigned long i_size; - unsigned char i_zone[3*(10+1+1+1)]; - unsigned long i_atime; - unsigned long i_mtime; - unsigned long i_ctime; - - -* Regular file data blocks are organized as - - - Minix FS: - - - 7 direct blocks - - 1 indirect block (pointers to blocks) - - 1 double-indirect block (pointer to pointers to blocks) - - - Xenix FS, SystemV FS, Coherent FS: - - - 10 direct blocks - - 1 indirect block (pointers to blocks) - - 1 double-indirect block (pointer to pointers to blocks) - - 1 triple-indirect block (pointer to pointers to pointers to blocks) - - - =========== ========== ================ - Inode size inodes per block - =========== ========== ================ - Minix FS 32 32 - Xenix FS 64 16 - SystemV FS 64 16 - Coherent FS 64 8 - =========== ========== ================ - -* Directory entry on disk - - - Minix FS:: - - unsigned short inode; - char name[14/30]; - - - Xenix FS, SystemV FS, Coherent FS:: - - unsigned short inode; - char name[14]; - - =========== ============== ===================== - Dir entry size dir entries per block - =========== ============== ===================== - Minix FS 16/32 64/32 - Xenix FS 16 64 - SystemV FS 16 64 - Coherent FS 16 32 - =========== ============== ===================== - -* How to implement symbolic links such that the host fsck doesn't scream: - - - Minix FS normal - - Xenix FS kludge: as regular files with chmod 1000 - - SystemV FS ?? - - Coherent FS kludge: as regular files with chmod 1000 - - -Notation: We often speak of a "block" but mean a zone (the allocation unit) -and not the disk driver's notion of "block". diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index 0b18af3f954e..ae79c30b6c0c 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -495,7 +495,7 @@ As of kernel 2.6.22, the following members are defined: int (*link) (struct dentry *,struct inode *,struct dentry *); int (*unlink) (struct inode *,struct dentry *); int (*symlink) (struct mnt_idmap *, struct inode *,struct dentry *,const char *); - int (*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t); + struct dentry *(*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t); int (*rmdir) (struct inode *,struct dentry *); int (*mknod) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t,dev_t); int (*rename) (struct mnt_idmap *, struct inode *, struct dentry *, @@ -562,7 +562,26 @@ otherwise noted. ``mkdir`` called by the mkdir(2) system call. Only required if you want to support creating subdirectories. You will probably need to - call d_instantiate() just as you would in the create() method + call d_instantiate_new() just as you would in the create() method. + + If d_instantiate_new() is not used and if the fh_to_dentry() + export operation is provided, or if the storage might be + accessible by another path (e.g. with a network filesystem) + then more care may be needed. Importantly d_instantate() + should not be used with an inode that is no longer I_NEW if there + any chance that the inode could already be attached to a dentry. + This is because of a hard rule in the VFS that a directory must + only ever have one dentry. + + For example, if an NFS filesystem is mounted twice the new directory + could be visible on the other mount before it is on the original + mount, and a pair of name_to_handle_at(), open_by_handle_at() + calls could instantiate the directory inode with an IS_ROOT() + dentry before the first mkdir returns. + + If there is any chance this could happen, then the new inode + should be d_drop()ed and attached with d_splice_alias(). The + returned dentry (if any) should be returned by ->mkdir(). ``rmdir`` called by the rmdir(2) system call. Only required if you want @@ -1251,7 +1270,8 @@ defined: .. code-block:: c struct dentry_operations { - int (*d_revalidate)(struct dentry *, unsigned int); + int (*d_revalidate)(struct inode *, const struct qstr *, + struct dentry *, unsigned int); int (*d_weak_revalidate)(struct dentry *, unsigned int); int (*d_hash)(const struct dentry *, struct qstr *); int (*d_compare)(const struct dentry *, @@ -1264,6 +1284,8 @@ defined: struct vfsmount *(*d_automount)(struct path *); int (*d_manage)(const struct path *, bool); struct dentry *(*d_real)(struct dentry *, enum d_real_type type); + bool (*d_unalias_trylock)(const struct dentry *); + void (*d_unalias_unlock)(const struct dentry *); }; ``d_revalidate`` @@ -1427,6 +1449,25 @@ defined: For non-regular files, the 'dentry' argument is returned. +``d_unalias_trylock`` + if present, will be called by d_splice_alias() before moving a + preexisting attached alias. Returning false prevents __d_move(), + making d_splice_alias() fail with -ESTALE. + + Rationale: setting FS_RENAME_DOES_D_MOVE will prevent d_move() + and d_exchange() calls from the outside of filesystem methods; + however, it does not guarantee that attached dentries won't + be renamed or moved by d_splice_alias() finding a preexisting + alias for a directory inode. Normally we would not care; + however, something that wants to stabilize the entire path to + root over a blocking operation might need that. See 9p for one + (and hopefully only) example. + +``d_unalias_unlock`` + should be paired with ``d_unalias_trylock``; that one is called after + __d_move() call in __d_unalias(). + + Each dentry has a pointer to its parent dentry, as well as a hash list of child dentries. Child dentries are basically like files in a directory. diff --git a/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst b/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst index 6402ab8e370c..2a2705e975e8 100644 --- a/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst +++ b/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst @@ -219,7 +219,7 @@ The log is circular, so the positions in the log are defined by the combination of a cycle number - the number of times the log has been overwritten - and the offset into the log. A LSN carries the cycle in the upper 32 bits and the offset in the lower 32 bits. The offset is in units of "basic blocks" (512 -bytes). Hence we can do realtively simple LSN based math to keep track of +bytes). Hence we can do relatively simple LSN based math to keep track of available space in the log. Log space accounting is done via a pair of constructs called "grant heads". The diff --git a/Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst b/Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst index 32b6ac4ca9d6..ce4584fb3103 100644 --- a/Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst +++ b/Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst @@ -93,7 +93,7 @@ others on a regular basis about burnout. sponsoring work on any part of XFS. - **LTS Maintainer**: Someone who backports and tests bug fixes from - uptream to the LTS kernels. + upstream to the LTS kernels. There tend to be six separate LTS trees at any given time. The maintainer for a given LTS release should identify themselves with an diff --git a/Documentation/filesystems/xfs/xfs-online-fsck-design.rst b/Documentation/filesystems/xfs/xfs-online-fsck-design.rst index 12aa63840830..e231d127cd40 100644 --- a/Documentation/filesystems/xfs/xfs-online-fsck-design.rst +++ b/Documentation/filesystems/xfs/xfs-online-fsck-design.rst @@ -4521,8 +4521,8 @@ Both online and offline repair can use this strategy. | For this second effort, the ondisk parent pointer format as originally | | proposed was ``(parent_inum, parent_gen, dirent_pos) → (dirent_name)``. | | The format was changed during development to eliminate the requirement | -| of repair tools needing to to ensure that the ``dirent_pos`` field | -| always matched when reconstructing a directory. | +| of repair tools needing to ensure that the ``dirent_pos`` field always | +| matched when reconstructing a directory. | | | | There were a few other ways to have solved that problem: | | | diff --git a/Documentation/gpu/drm-compute.rst b/Documentation/gpu/drm-compute.rst new file mode 100644 index 000000000000..f90c3e63aa9e --- /dev/null +++ b/Documentation/gpu/drm-compute.rst @@ -0,0 +1,54 @@ +================================== +Long running workloads and compute +================================== + +Long running workloads (compute) are workloads that will not complete in 10 +seconds. (The time let the user wait before he reaches for the power button). +This means that other techniques need to be used to manage those workloads, +that cannot use fences. + +Some hardware may schedule compute jobs, and have no way to pre-empt them, or +have their memory swapped out from them. Or they simply want their workload +not to be preempted or swapped out at all. + +This means that it differs from what is described in driver-api/dma-buf.rst. + +As with normal compute jobs, dma-fence may not be used at all. In this case, +not even to force preemption. The driver with is simply forced to unmap a BO +from the long compute job's address space on unbind immediately, not even +waiting for the workload to complete. Effectively this terminates the workload +when there is no hardware support to recover. + +Since this is undesirable, there need to be mitigations to prevent a workload +from being terminated. There are several possible approach, all with their +advantages and drawbacks. + +The first approach you will likely try is to pin all buffers used by compute. +This guarantees that the job will run uninterrupted, but also allows a very +denial of service attack by pinning as much memory as possible, hogging the +all GPU memory, and possibly a huge chunk of CPU memory. + +A second approach that will work slightly better on its own is adding an option +not to evict when creating a new job (any kind). If all of userspace opts in +to this flag, it would prevent cooperating userspace from forced terminating +older compute jobs to start a new one. + +If job preemption and recoverable pagefaults are not available, those are the +only approaches possible. So even with those, you want a separate way of +controlling resources. The standard kernel way of doing so is cgroups. + +This creates a third option, using cgroups to prevent eviction. Both GPU and +driver-allocated CPU memory would be accounted to the correct cgroup, and +eviction would be made cgroup aware. This allows the GPU to be partitioned +into cgroups, that will allow jobs to run next to each other without +interference. + +The interface to the cgroup would be similar to the current CPU memory +interface, with similar semantics for min/low/high/max, if eviction can +be made cgroup aware. + +What should be noted is that each memory region (tiled memory for example) +should have its own accounting. + +The key is set to the regionid set by the driver, for example "tile0". +For the value of $card, we use drmGetUnique(). diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 8cf2f041af47..b4ee25af1702 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -221,6 +221,9 @@ Panel Helper Reference .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c :export: +.. kernel-doc:: drivers/gpu/drm/drm_panel_backlight_quirks.c + :export: + Panel Self Refresh Helper Reference =================================== diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index 2717cb2a597e..b7fc106dad99 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -145,57 +145,57 @@ both. Memory ^^^^^^ -- drm-memory-<region>: <uint> [KiB|MiB] - -Each possible memory type which can be used to store buffer objects by the -GPU in question shall be given a stable and unique name to be returned as the -string here. +Each possible memory type which can be used to store buffer objects by the GPU +in question shall be given a stable and unique name to be used as the "<region>" +string. The region name "memory" is reserved to refer to normal system memory. -Value shall reflect the amount of storage currently consumed by the buffer +The value shall reflect the amount of storage currently consumed by the buffer objects belong to this client, in the respective memory region. Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' indicating kibi- or mebi-bytes. -This key is deprecated and is an alias for drm-resident-<region>. Only one of -the two should be present in the output. - -- drm-shared-<region>: <uint> [KiB|MiB] +- drm-total-<region>: <uint> [KiB|MiB] -The total size of buffers that are shared with another file (e.g., have more -than a single handle). +The total size of all requested buffers, including both shared and private +memory. The backing store for the buffers does not need to be currently +instantiated to count under this category. To avoid double-counting, if a buffer +has multiple regions where it can be allocated to, the implementation should +consistently select a single region for accounting purposes. -- drm-total-<region>: <uint> [KiB|MiB] +- drm-shared-<region>: <uint> [KiB|MiB] -The total size of all created buffers including shared and private memory. The -backing store for the buffers does not have to be currently instantiated to be -counted under this category. +The total size of buffers that are shared with another file (i.e., have more +than one handle). The same requirement to avoid double-counting that applies to +drm-total-<region> also applies here. - drm-resident-<region>: <uint> [KiB|MiB] -The total size of buffers that are resident (have their backing store present or -instantiated) in the specified region. +The total size of buffers that are resident (i.e., have their backing store +present or instantiated) in the specified region. + +- drm-memory-<region>: <uint> [KiB|MiB] -This is an alias for drm-memory-<region> and only one of the two should be -present in the output. +This key is deprecated and is only printed by amdgpu; it is an alias for +drm-resident-<region>. - drm-purgeable-<region>: <uint> [KiB|MiB] -The total size of buffers that are purgeable. +The total size of buffers that are resident and purgeable. -For example drivers which implement a form of 'madvise' like functionality can -here count buffers which have instantiated backing store, but have been marked -with an equivalent of MADV_DONTNEED. +For example, drivers that implement functionality similar to 'madvise' can count +buffers that have instantiated backing stores but have been marked with an +equivalent of MADV_DONTNEED. - drm-active-<region>: <uint> [KiB|MiB] The total size of buffers that are active on one or more engines. -One practical example of this can be presence of unsignaled fences in an GEM -buffer reservation object. Therefore the active category is a subset of -resident. +One practical example of this could be the presence of unsignaled fences in a +GEM buffer reservation object. Therefore, the active category is a subset of the +resident category. Implementation Details ====================== diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 37e383ccf73f..7dcb15850afd 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -13,6 +13,7 @@ GPU Driver Developer's Guide drm-usage-stats driver-uapi drm-client + drm-compute drivers backlight vga-switcheroo diff --git a/Documentation/gpu/xe/index.rst b/Documentation/gpu/xe/index.rst index 3f07aa3b5432..92cfb25e64d3 100644 --- a/Documentation/gpu/xe/index.rst +++ b/Documentation/gpu/xe/index.rst @@ -23,4 +23,5 @@ DG2, etc is provided to prototype the driver. xe_firmware xe_tile xe_debugging + xe_devcoredump xe-drm-usage-stats.rst diff --git a/Documentation/gpu/xe/xe_devcoredump.rst b/Documentation/gpu/xe/xe_devcoredump.rst new file mode 100644 index 000000000000..ae4ec0e34dc0 --- /dev/null +++ b/Documentation/gpu/xe/xe_devcoredump.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +================== +Xe Device Coredump +================== + +.. kernel-doc:: drivers/gpu/drm/xe/xe_devcoredump.c + :doc: Xe device coredump + +Internal API +============ + +.. kernel-doc:: drivers/gpu/drm/xe/xe_devcoredump.c + :internal: diff --git a/Documentation/gpu/zynqmp.rst b/Documentation/gpu/zynqmp.rst index f57bfa0ad6ec..1a6f9193de22 100644 --- a/Documentation/gpu/zynqmp.rst +++ b/Documentation/gpu/zynqmp.rst @@ -144,6 +144,4 @@ Internals .. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_dp.c -.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_dpsub.c - .. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_kms.c diff --git a/Documentation/hid/index.rst b/Documentation/hid/index.rst index af02cf7cfa82..baf156b44b58 100644 --- a/Documentation/hid/index.rst +++ b/Documentation/hid/index.rst @@ -18,4 +18,5 @@ Human Interface Devices (HID) hid-alps intel-ish-hid + intel-thc-hid amd-sfh-hid diff --git a/Documentation/hid/intel-thc-hid.rst b/Documentation/hid/intel-thc-hid.rst new file mode 100644 index 000000000000..6c417205ac6a --- /dev/null +++ b/Documentation/hid/intel-thc-hid.rst @@ -0,0 +1,568 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================= +Intel Touch Host Controller (THC) +================================= + +Touch Host Controller is the name of the IP block in PCH that interface with Touch Devices (ex: +touchscreen, touchpad etc.). It is comprised of 3 key functional blocks: + +- A natively half-duplex Quad I/O capable SPI master +- Low latency I2C interface to support HIDI2C compliant devices +- A HW sequencer with RW DMA capability to system memory + +It has a single root space IOSF Primary interface that supports transactions to/from touch devices. +Host driver configures and controls the touch devices over THC interface. THC provides high +bandwidth DMA services to the touch driver and transfers the HID report to host system main memory. + +Hardware sequencer within the THC is responsible for transferring (via DMA) data from touch devices +into system memory. A ring buffer is used to avoid data loss due to asynchronous nature of data +consumption (by host) in relation to data production (by touch device via DMA). + +Unlike other common SPI/I2C controllers, THC handles the HID device data interrupt and reset +signals directly. + +1. Overview +=========== + +1.1 THC software/hardware stack +------------------------------- + +Below diagram illustrates the high-level architecture of THC software/hardware stack, which is fully +capable of supporting HIDSPI/HIDI2C protocol in Linux OS. + +:: + + ---------------------------------------------- + | +-----------------------------------+ | + | | Input Device | | + | +-----------------------------------+ | + | +-----------------------------------+ | + | | HID Multi-touch Driver | | + | +-----------------------------------+ | + | +-----------------------------------+ | + | | HID Core | | + | +-----------------------------------+ | + | +-----------------------------------+ | + | | THC QuickSPI/QuickI2C Driver | | + | +-----------------------------------+ | + | +-----------------------------------+ | + | | THC Hardware Driver | | + | +-----------------------------------+ | + | +----------------+ +----------------+ | + | SW | PCI Bus Driver | | ACPI Resource | | + | +----------------+ +----------------+ | + ---------------------------------------------- + ---------------------------------------------- + | +-----------------------------------+ | + | HW | PCI Bus | | + | +-----------------------------------+ | + | +-----------------------------------+ | + | | THC Controller | | + | +-----------------------------------+ | + | +-----------------------------------+ | + | | Touch IC | | + | +-----------------------------------+ | + ---------------------------------------------- + +Touch IC (TIC), also as known as the Touch devices (touchscreen or touchpad). The discrete analog +components that sense and transfer either discrete touch data or heatmap data in the form of HID +reports over the SPI/I2C bus to the THC Controller on the host. + +THC Host Controller, which is a PCI device HBA (host bus adapter), integrated into the PCH, that +serves as a bridge between the Touch ICs and the host. + +THC Hardware Driver, provides THC hardware operation APIs for above QuickSPI/QuickI2C driver, it +accesses THC MMIO registers to configure and control THC hardware. + +THC QuickSPI/QuickI2C driver, also as known as HIDSPI/HIDI2C driver, is registered as a HID +low-level driver that manages the THC Controller and implements HIDSPI/HIDI2C protocol. + + +1.2 THC hardware diagram +------------------------ +Below diagram shows THC hardware components:: + + --------------------------------- + | THC Controller | + | +---------------------------+ | + | | PCI Config Space | | + | +---------------------------+ | + | +---------------------------+ | + | + MMIO Registers | | + | +---------------------------+ | + +---------------+ | +------------+ +------------+ | + | System Memory +---+--+ DMA | | PIO | | + +---------------+ | +------------+ +------------+ | + | +---------------------------+ | + | | HW Sequencer | | + | +---------------------------+ | + | +------------+ +------------+ | + | | SPI/I2C | | GPIO | | + | | Controller | | Controller | | + | +------------+ +------------+ | + --------------------------------- + +As THC is exposed as a PCI devices, so it has standard PCI config space registers for PCI +enumeration and configuration. + +MMIO Registers, which provide registers access for driver to configure and control THC hardware, +the registers include several categories: Interrupt status and control, DMA configure, +PIO (Programmed I/O, defined in section 3.2) status and control, SPI bus configure, I2C subIP +status and control, reset status and control... + +THC provides two ways for driver to communicate with external Touch ICs: PIO and DMA. +PIO can let driver manually write/read data to/from Touch ICs, instead, THC DMA can +automatically write/read data without driver involved. + +HW Sequencer includes THC major logic, it gets instruction from MMIO registers to control +SPI bus and I2C bus to finish a bus data transaction, it also can automatically handle +Touch ICs interrupt and start DMA receive/send data from/to Touch ICs according to interrupt +type. That means THC HW Sequencer understands HIDSPI/HIDI2C transfer protocol, and handle +the communication without driver involved, what driver needs to do is just configure the THC +properly, and prepare the formatted data packet or handle received data packet. + +As THC supports HIDSPI/HIDI2C protocols, it has SPI controller and I2C subIP in it to expose +SPI bus and I2C bus. THC also integrates a GPIO controller to provide interrupt line support +and reset line support. + +2. THC Hardware Interface +========================= + +2.1 Host Interface +------------------ + +THC is exposed as "PCI Digitizer device" to the host. The PCI product and device IDs are +changed from different generations of processors. So the source code which enumerates drivers +needs to update from generation to generation. + + +2.2 Device Interface +-------------------- + +THC supports two types of bus for Touch IC connection: Enhanced SPI bus and I2C bus. + +2.2.1 SPI Port +~~~~~~~~~~~~~~ + +When PORT_TYPE = 00b in MMIO registers, THC uses SPI interfaces to communicate with external +Touch IC. THC enhanced SPI Bus supports different SPI modes: standard Single IO mode, +Dual IO mode and Quad IO mode. + +In Single IO mode, THC drives MOSI line to send data to Touch ICs, and receives data from Touch +ICs data from MISO line. In Dual IO mode, THC drivers MOSI and MISO both for data sending, and +also receives the data on both line. In Quad IO mode, there are other two lines (IO2 and IO3) +are added, THC drives MOSI (IO0), MISO (IO1), IO2 and IO3 at the same time for data sending, and +also receives the data on those 4 lines. Driver needs to configure THC in different mode by +setting different opcode. + +Beside IO mode, driver also needs to configure SPI bus speed. THC supports up to 42MHz SPI clock +on Intel Lunar Lake platform. + +For THC sending data to Touch IC, the data flow on SPI bus:: + + | --------------------THC sends---------------------------------| + <8Bits OPCode><24Bits Slave Address><Data><Data><Data>........... + +For THC receiving data from Touch IC, the data flow on SPI bus:: + + | ---------THC Sends---------------||-----Touch IC sends--------| + <8Bits OPCode><24Bits Slave Address><Data><Data><Data>........... + +2.2.2 I2C Port +~~~~~~~~~~~~~~ + +THC also integrates I2C controller in it, it's called I2C SubSystem. When PORT_TYPE = 01, THC +is configured to I2C mode. Comparing to SPI mode which can be configured through MMIO registers +directly, THC needs to use PIO read (by setting SubIP read opcode) to I2C subIP APB registers' +value and use PIO write (by setting SubIP write opcode) to do a write operation. + +2.2.3 GPIO interface +~~~~~~~~~~~~~~~~~~~~ + +THC also includes two GPIO pins, one for interrupt and the other for device reset control. + +Interrupt line can be configured to either level triggerred or edge triggerred by setting MMIO +Control register. + +Reset line is controlled by BIOS (or EFI) through ACPI _RST method, driver needs to call this +device ACPI _RST method to reset touch IC during initialization. + +3. High level concept +===================== + +3.1 Opcode +---------- + +Opcode (operation code) is used to tell THC or Touch IC what the operation will be, such as PIO +read or PIO write. + +When THC is configured to SPI mode, opcodes are used for determining the read/write IO mode. +There are some OPCode examples for SPI IO mode: + +======= ============================== +opcode Corresponding SPI command +======= ============================== +0x0B Read Single I/O +0x02 Write Single I/O +0xBB Read Dual I/O +0xB2 Write Dual I/O +0xEB Read Quad I/O +0xE2 Write Quad I/O +======= ============================== + +In general, different touch IC has different OPCode definition. According to HIDSPI +protocol whitepaper, those OPCodes are defined in device ACPI table, and driver needs to +query those information through OS ACPI APIs during driver initialization, then configures +THC MMIO OPCode registers with correct setting. + +When THC is working in I2C mode, opcodes are used to tell THC what's the next PIO type: +I2C SubIP APB register read, I2C SubIP APB register write, I2C touch IC device read, +I2C touch IC device write, I2C touch IC device write followed by read. + +Here are the THC pre-defined opcodes for I2C mode: + +======= =================================================== =========== +opcode Corresponding I2C command Address +======= =================================================== =========== +0x12 Read I2C SubIP APB internal registers 0h - FFh +0x13 Write I2C SubIP APB internal registers 0h - FFh +0x14 Read external Touch IC through I2C bus N/A +0x18 Write external Touch IC through I2C bus N/A +0x1C Write then read external Touch IC through I2C bus N/A +======= =================================================== =========== + +3.2 PIO +------- + +THC provides a programmed I/O (PIO) access interface for the driver to access the touch IC's +configuration registers, or access I2C subIP's configuration registers. To use PIO to perform +I/O operations, driver should pre-program PIO control registers and PIO data registers and kick +off the sequencing cycle. THC uses different PIO opcodes to distinguish different PIO +operations (PIO read/write/write followed by read). + +If there is a Sequencing Cycle In Progress and an attempt is made to program any of the control, +address, or data register the cycle is blocked and a sequence error will be encountered. + +A status bit indicates when the cycle has completed allowing the driver to know when read results +can be checked and/or when to initiate a new command. If enabled, the cycle done assertion can +interrupt driver with an interrupt. + +Because THC only has 16 FIFO registers for PIO, so all the data transfer through PIO shouldn't +exceed 64 bytes. + +As DMA needs max packet size for transferring configuration, and the max packet size information +always in HID device descriptor which needs THC driver to read it out from HID Device (Touch IC). +So PIO typical use case is, before DMA initialization, write RESET command (PIO write), read +RESET response (PIO read or PIO write followed by read), write Power ON command (PIO write), read +device descriptor (PIO read). + +For how to issue a PIO operation, here is the steps which driver needs follow: + +- Program read/write data size in THC_SS_BC. +- Program I/O target address in THC_SW_SEQ_DATA0_ADDR. +- If write, program the write data in THC_SW_SEQ_DATA0..THC_SW_SEQ_DATAn. +- Program the PIO opcode in THC_SS_CMD. +- Set TSSGO = 1 to start the PIO write sequence. +- If THC_SS_CD_IE = 1, SW will receives a MSI when the PIO is completed. +- If read, read out the data in THC_SW_SEQ_DATA0..THC_SW_SEQ_DATAn. + +3.3 DMA +------- + +THC has 4 DMA channels: Read DMA1, Read DMA2, Write DMA and Software DMA. + +3.3.1 Read DMA Channel +~~~~~~~~~~~~~~~~~~~~~~ + +THC has two Read DMA engines: 1st RxDMA (RxDMA1) and 2nd RxDMA (RxDMA2). RxDMA1 is reserved for +raw data mode. RxDMA2 is used for HID data mode and it is the RxDMA engine currently driver uses +for HID input report data retrieval. + +RxDMA's typical use case is auto receiving the data from Touch IC. Once RxDMA is enabled by +software, THC will start auto-handling receiving logic. + +For SPI mode, THC RxDMA sequence is: when Touch IC triggers a interrupt to THC, THC reads out +report header to identify what's the report type, and what's the report length, according to +above information, THC reads out report body to internal FIFO and start RxDMA coping the data +to system memory. After that, THC update interrupt cause register with report type, and update +RxDMA PRD table read pointer, then trigger a MSI interrupt to notify driver RxDMA finishing +data receiving. + +For I2C mode, THC RxDMA's behavior is a little bit different, because of HIDI2C protocol difference +with HIDSPI protocol, RxDMA only be used to receive input report. The sequence is, when Touch IC +triggers a interrupt to THC, THC first reads out 2 bytes from input report address to determine the +packet length, then use this packet length to start a DMA reading from input report address for +input report data. After that, THC update RxDMA PRD table read pointer, then trigger a MSI interrupt +to notify driver input report data is ready in system memory. + +All above sequence is hardware automatically handled, all driver needs to do is configure RxDMA and +waiting for interrupt ready then read out the data from system memory. + +3.3.2 Software DMA channel +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +THC supports a software triggerred RxDMA mode to read the touch data from touch IC. This SW RxDMA +is the 3rd THC RxDMA engine with the similar functionalities as the existing two RxDMAs, the only +difference is this SW RxDMA is triggerred by software, and RxDMA2 is triggerred by external Touch IC +interrupt. It gives a flexiblity to software driver to use RxDMA read Touch IC data in any time. + +Before software starts a SW RxDMA, it shall stop the 1st and 2nd RxDMA, clear PRD read/write pointer +and quiesce the device interrupt (THC_DEVINT_QUIESCE_HW_STS = 1), other operations are the same with +RxDMA. + +3.3.3 Write DMA Channel +~~~~~~~~~~~~~~~~~~~~~~~ + +THC has one write DMA engine, which can be used for sending data to Touch IC automatically. +According to HIDSPI and HIDI2C protocol, every time only one command can be sent to touch IC, and +before last command is completely handled, next command cannot be sent, THC write DMA engine only +supports single PRD table. + +What driver needs to do is, preparing PRD table and DMA buffer, then copy data to DMA buffer and +update PRD table with buffer address and buffer length, then start write DMA. THC will +automatically send the data to touch IC, and trigger a DMA completion interrupt once transferring +is done. + +3.4 PRD +------- + +Physical Region Descriptor (PRD) provides the memory mapping description for THC DMAs. + +3.4.1 PRD table and entry +~~~~~~~~~~~~~~~~~~~~~~~~~ + +In order to improve physical DMA memory usage, modern drivers trend to allocate a virtually +contiguous, but physically fragmented buffer of memory for each data buffer. Linux OS also +provide SGL (scatter gather list) APIs to support this usage. + +THC uses PRD table (physical region descriptor) to support the corresponding OS kernel +SGL that describes the virtual to physical buffer mapping. + +:: + + ------------------------ -------------- -------------- + | PRD table base address +----+ PRD table #1 +-----+ PRD Entry #1 | + ------------------------ -------------- -------------- + -------------- + | PRD Entry #2 | + -------------- + -------------- + | PRD Entry #n | + -------------- + +The read DMA engine supports multiple PRD tables held within a circular buffer that allow the THC +to support multiple data buffers from the Touch IC. This allows host SW to arm the Read DMA engine +with multiple buffers, allowing the Touch IC to send multiple data frames to the THC without SW +interaction. This capability is required when the CPU processes touch frames slower than the +Touch IC can send them. + +To simplify the design, SW assumes worst-case memory fragmentation. Therefore,each PRD table shall +contain the same number of PRD entries, allowing for a global register (per Touch IC) to hold the +number of PRD-entries per PRD table. + +SW allocates up to 128 PRD tables per Read DMA engine as specified in the THC_M_PRT_RPRD_CNTRL.PCD +register field. The number of PRD tables should equal the number of data buffers. + +Max OS memory fragmentation will be at a 4KB boundary, thus to address 1MB of virtually contiguous +memory 256 PRD entries are required for a single PRD Table. SW writes the number of PRD entries +for each PRD table in the THC_M_PRT_RPRD_CNTRL.PTEC register field. The PRD entry's length must be +multiple of 4KB except for the last entry in a PRD table. + +SW allocates all the data buffers and PRD tables only once at host initialization. + +3.4.2 PRD Write pointer and read pointer +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As PRD tables are organized as a Circular Buffer (CB), a read pointer and a write pointer for a CB +are needed. + +DMA HW consumes the PRD tables in the CB, one PRD entry at a time until the EOP bit is found set +in a PRD entry. At this point HW increments the PRD read pointer. Thus, the read pointer points +to the PRD which the DMA engine is currently processing. This pointer rolls over once the circular +buffer's depth has been traversed with bit[7] the Rollover bit. E.g. if the DMA CB depth is equal +to 4 entries (0011b), then the read pointers will follow this pattern (HW is required to honor +this behavior): 00h 01h 02h 03h 80h 81h 82h 83h 00h 01h ... + +The write pointer is updated by SW. The write pointer points to location in the DMA CB, where the +next PRD table is going to be stored. SW needs to ensure that this pointer rolls over once the +circular buffer's depth has been traversed with Bit[7] as the rollover bit. E.g. if the DMA CB +depth is equal to 5 entries (0100b), then the write pointers will follow this pattern (SW is +required to honor this behavior): 00h 01h 02h 03h 04h 80h 81h 82h 83h 84h 00h 01h .. + +3.4.3 PRD descriptor structure +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Intel THC uses PRD entry descriptor for every PRD entry. Every PRD entry descriptor occupies +128 bits memories: + +=================== ======== =============================================== +struct field bit(s) description +=================== ======== =============================================== +dest_addr 53..0 destination memory address, as every entry + is 4KB, ignore lowest 10 bits of address. +reserved1 54..62 reserved +int_on_completion 63 completion interrupt enable bit, if this bit + set it means THC will trigger a completion + interrupt. This bit is set by SW driver. +len 87..64 how many bytes of data in this entry. +end_of_prd 88 end of PRD table bit, if this bit is set, + it means this entry is last entry in this PRD + table. This bit is set by SW driver. +hw_status 90..89 HW status bits +reserved2 127..91 reserved +=================== ======== =============================================== + +And one PRD table can include up to 256 PRD entries, as every entries is 4K bytes, so every +PRD table can describe 1M bytes memory. + +.. code-block:: c + + struct thc_prd_table { + struct thc_prd_entry entries[PRD_ENTRIES_NUM]; + }; + +In general, every PRD table means one HID touch data packet. Every DMA engine can support +up to 128 PRD tables (except write DMA, write DMA only has one PRD table). SW driver is responsible +to get max packet length from touch IC, and use this max packet length to create PRD entries for +each PRD table. + +4. HIDSPI support (QuickSPI) +============================ + +Intel THC is total compatible with HIDSPI protocol, THC HW sequenser can accelerate HIDSPI +protocol transferring. + +4.1 Reset Flow +-------------- + +- Call ACPI _RST method to reset Touch IC device. +- Read the reset response from TIC through PIO read. +- Issue a command to retrieve device descriptor from Touch IC through PIO write. +- Read the device descriptor from Touch IC through PIO read. +- If the device descriptor is valid, allocate DMA buffers and configure all DMA channels. +- Issue a command to retrieve report descriptor from Touch IC through DMA. + +4.2 Input Report Data Flow +-------------------------- + +Basic Flow: + +- Touch IC interrupts the THC Controller using an in-band THC interrupt. +- THC Sequencer reads the input report header by transmitting read approval as a signal + to the Touch IC to prepare for host to read from the device. +- THC Sequencer executes a Input Report Body Read operation corresponding to the value + reflected in “Input Report Length” field of the Input Report Header. +- THC DMA engine begins fetching data from the THC Sequencer and writes to host memory + at PRD entry 0 for the current CB PRD table entry. This process continues until the + THC Sequencer signals all data has been read or the THC DMA Read Engine reaches the + end of it's last PRD entry (or both). +- The THC Sequencer checks for the “Last Fragment Flag” bit in the Input Report Header. + If it is clear, the THC Sequencer enters an idle state. +- If the “Last Fragment Flag” bit is enabled the THC Sequencer enters End-of-Frame Processing. + +THC Sequencer End of Frame Processing: + +- THC DMA engine increments the read pointer of the Read PRD CB, sets EOF interrupt status + in RxDMA2 register (THC_M_PRT_READ_DMA_INT_STS_2). +- If THC EOF interrupt is enabled by the driver in the control register (THC_M_PRT_READ_DMA_CNTRL_2), + generates interrupt to software. + +Sequence of steps to read data from RX DMA buffer: + +- THC QuickSPI driver checks CB write Ptr and CB read Ptr to identify if any data frame in DMA + circular buffers. +- THC QuickSPI driver gets first unprocessed PRD table. +- THC QuickSPI driver scans all PRD entries in this PRD table to calculate the total frame size. +- THC QuickSPI driver copies all frame data out. +- THC QuickSPI driver checks the data type according to input report body, and calls related + callbacks to process the data. +- THC QuickSPI driver updates write Ptr. + +4.3 Output Report Data Flow +--------------------------- + +Generic Output Report Flow: + +- HID core calls raw_request callback with a request to THC QuickSPI driver. +- THC QuickSPI Driver converts request provided data into the output report packet and copies it + to THC's write DMA buffer. +- Start TxDMA to complete the write operation. + +5. HIDI2C support (QuickI2C) +============================ + +5.1 Reset Flow +-------------- + +- Read device descriptor from Touch IC device through PIO write followed by read. +- If the device descriptor is valid, allocate DMA buffers and configure all DMA channels. +- Use PIO or TxDMA to write a SET_POWER request to TIC's command register, and check if the + write operation is successfully completed. +- Use PIO or TxDMA to write a RESET request to TIC's command register. If the write operation + is successfully completed, wait for reset response from TIC. +- Use SWDMA to read report descriptor through TIC's report descriptor register. + +5.2 Input Report Data Flow +-------------------------- + +Basic Flow: + +- Touch IC asserts the interrupt indicating that it has an interrupt to send to HOST. + THC Sequencer issues a READ request over the I2C bus. The HIDI2C device returns the + first 2 bytes from the HIDI2C device which contains the length of the received data. +- THC Sequencer continues the Read operation as per the size of data indicated in the + length field. +- THC DMA engine begins fetching data from the THC Sequencer and writes to host memory + at PRD entry 0 for the current CB PRD table entry. THC writes 2Bytes for length field + plus the remaining data to RxDMA buffer. This process continues until the THC Sequencer + signals all data has been read or the THC DMA Read Engine reaches the end of it's last + PRD entry (or both). +- THC Sequencer enters End-of-Input Report Processing. +- If the device has no more input reports to send to the host, it de-asserts the interrupt + line. For any additional input reports, device keeps the interrupt line asserted and + steps 1 through 4 in the flow are repeated. + +THC Sequencer End of Input Report Processing: + +- THC DMA engine increments the read pointer of the Read PRD CB, sets EOF interrupt status + in RxDMA 2 register (THC_M_PRT_READ_DMA_INT_STS_2). +- If THC EOF interrupt is enabled by the driver in the control register + (THC_M_PRT_READ_DMA_CNTRL_2), generates interrupt to software. + +Sequence of steps to read data from RX DMA buffer: + +- THC QuickI2C driver checks CB write Ptr and CB read Ptr to identify if any data frame in DMA + circular buffers. +- THC QuickI2C driver gets first unprocessed PRD table. +- THC QuickI2C driver scans all PRD entries in this PRD table to calculate the total frame size. +- THC QuickI2C driver copies all frame data out. +- THC QuickI2C driver call hid_input_report to send the input report content to HID core, which + includes Report ID + Report Data Content (remove the length field from the original report + data). +- THC QuickI2C driver updates write Ptr. + +5.3 Output Report Data Flow +--------------------------- + +Generic Output Report Flow: + +- HID core call THC QuickI2C raw_request callback. +- THC QuickI2C uses PIO or TXDMA to write a SET_REPORT request to TIC's command register. Report + type in SET_REPORT should be set to Output. +- THC QuickI2C programs TxDMA buffer with TX Data to be written to TIC's data register. The first + 2 bytes should indicate the length of the report followed by the report contents including + Report ID. + +6. THC Debugging +================ + +To debug THC, event tracing mechanism is used. To enable debug logs:: + + echo 1 > /sys/kernel/debug/tracing/events/intel_thc/enable + cat /sys/kernel/debug/tracing/trace + +7. Reference +============ +- HIDSPI: https://download.microsoft.com/download/c/a/0/ca07aef3-3e10-4022-b1e9-c98cea99465d/HidSpiProtocolSpec.pdf +- HIDI2C: https://download.microsoft.com/download/7/d/d/7dd44bb7-2a7a-4505-ac1c-7227d3d96d5b/hid-over-i2c-protocol-spec-v1-0.docx diff --git a/Documentation/hwmon/abituguru-datasheet.rst b/Documentation/hwmon/abituguru-datasheet.rst index 0cd61471d2a2..19ba4b4cd034 100644 --- a/Documentation/hwmon/abituguru-datasheet.rst +++ b/Documentation/hwmon/abituguru-datasheet.rst @@ -6,9 +6,9 @@ First of all, what I know about uGuru is no fact based on any help, hints or datasheet from Abit. The data I have got on uGuru have I assembled through my weak knowledge in "backwards engineering". And just for the record, you may have noticed uGuru isn't a chip developed by -Abit, as they claim it to be. It's really just an microprocessor (uC) created by +Abit, as they claim it to be. It's really just a microprocessor (uC) created by Winbond (W83L950D). And no, reading the manual for this specific uC or -mailing Windbond for help won't give any useful data about uGuru, as it is +mailing Winbond for help won't give any useful data about uGuru, as it is the program inside the uC that is responding to calls. Olle Sandberg <ollebull@gmail.com>, 2005-05-25 @@ -35,7 +35,7 @@ As far as known the uGuru is always placed at and using the (ISA) I/O-ports ports are holding for detection. We will refer to 0xE0 as CMD (command-port) and 0xE4 as DATA because Abit refers to them with these names. -If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC an uGuru could be +If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC a uGuru could be present. We have to check for two different values at data-port, because after a reboot uGuru will hold 0x00 here, but if the driver is removed and later on attached again data-port will hold 0x08, more about this later. @@ -46,7 +46,7 @@ have to test CMD for two different values. On these uGuru's DATA will initially hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read first! -To be really sure an uGuru is present a test read of one or more register +To be really sure a uGuru is present a test read of one or more register sets should be done. diff --git a/Documentation/hwmon/abituguru.rst b/Documentation/hwmon/abituguru.rst index cfda60b757ce..4a5ee16b1048 100644 --- a/Documentation/hwmon/abituguru.rst +++ b/Documentation/hwmon/abituguru.rst @@ -40,7 +40,7 @@ Supported chips: .. [2] There is a separate abituguru3 driver for these motherboards, the abituguru (without the 3 !) driver will not work on these - motherboards (and visa versa)! + motherboards (and vice versa)! Authors: - Hans de Goede <j.w.r.degoede@hhs.nl>, diff --git a/Documentation/hwmon/adm1275.rst b/Documentation/hwmon/adm1275.rst index 467daf8ce3c5..57bd7a850558 100644 --- a/Documentation/hwmon/adm1275.rst +++ b/Documentation/hwmon/adm1275.rst @@ -19,6 +19,14 @@ Supported chips: Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1272.pdf + * Analog Devices ADM1273 + + Prefix: 'adm1273' + + Addresses scanned: - + + Datasheet: Not yet publicly available + * Analog Devices ADM1275 Prefix: 'adm1275' @@ -66,14 +74,14 @@ Description ----------- This driver supports hardware monitoring for Analog Devices ADM1075, ADM1272, -ADM1275, ADM1276, ADM1278, ADM1281, ADM1293, and ADM1294 Hot-Swap Controller and -Digital Power Monitors. +ADM1273, ADM1275, ADM1276, ADM1278, ADM1281, ADM1293, and ADM1294 Hot-Swap +Controller and Digital Power Monitors. -ADM1075, ADM1272, ADM1275, ADM1276, ADM1278, ADM1281, ADM1293, and ADM1294 are hot-swap -controllers that allow a circuit board to be removed from or inserted into -a live backplane. They also feature current and voltage readback via an -integrated 12 bit analog-to-digital converter (ADC), accessed using a -PMBus interface. +ADM1075, ADM1272, ADM1273, ADM1275, ADM1276, ADM1278, ADM1281, ADM1293, and +ADM1294 are hot-swap controllers that allow a circuit board to be removed from +or inserted into a live backplane. They also feature current and voltage +readback via an integrated 12 bit analog-to-digital converter (ADC), accessed +using a PMBus interface. The driver is a client driver to the core PMBus driver. Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers. @@ -141,7 +149,7 @@ power1_input_highest Highest observed input power. power1_reset_history Write any value to reset history. Power attributes are supported on ADM1075, ADM1272, - ADM1276, ADM1293, and ADM1294. + ADM1273, ADM1276, ADM1293, and ADM1294. temp1_input Chip temperature. temp1_max Maximum chip temperature. @@ -151,6 +159,6 @@ temp1_crit_alarm Critical temperature high alarm. temp1_highest Highest observed temperature. temp1_reset_history Write any value to reset history. - Temperature attributes are supported on ADM1272 and - ADM1278, and ADM1281. + Temperature attributes are supported on ADM1272, + ADM1273, ADM1278, and ADM1281. ======================= ======================================================= diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst index ca38922f4ec5..d2be9db29614 100644 --- a/Documentation/hwmon/asus_ec_sensors.rst +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -6,6 +6,7 @@ Kernel driver asus_ec_sensors Supported boards: * PRIME X470-PRO * PRIME X570-PRO + * PRIME X670E-PRO WIFI * Pro WS X570-ACE * ProArt X570-CREATOR WIFI * ProArt X670E-CREATOR WIFI @@ -29,6 +30,7 @@ Supported boards: * ROG STRIX Z690-A GAMING WIFI D4 * ROG ZENITH II EXTREME * ROG ZENITH II EXTREME ALPHA + * TUF GAMING X670E PLUS Authors: - Eugene Shalygin <eugene.shalygin@gmail.com> diff --git a/Documentation/hwmon/cgbc-hwmon.rst b/Documentation/hwmon/cgbc-hwmon.rst new file mode 100644 index 000000000000..3a5e6e6e8639 --- /dev/null +++ b/Documentation/hwmon/cgbc-hwmon.rst @@ -0,0 +1,63 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver cgbc-hwmon +======================== + +Supported chips: + + * Congatec Board Controller. + + Prefix: 'cgbc-hwmon' + +Author: Thomas Richard <thomas.richard@bootlin.com> + +Description +----------- + +This driver enables monitoring support for the Congatec Board Controller. +This controller is embedded on the x86 SoMs of Congatec. + +Sysfs entries +------------- + +The following sysfs entries list contains all sensors defined in the Board +Controller. The available sensors in sysfs depend on the SoM and the +system. + +============= ====================== +Name Description +============= ====================== +temp1_input CPU temperature +temp2_input Box temperature +temp3_input Ambient temperature +temp4_input Board temperature +temp5_input Carrier temperature +temp6_input Chipset temperature +temp7_input Video temperature +temp8_input Other temperature +temp9_input TOPDIM temperature +temp10_input BOTTOMDIM temperature +in0_input CPU voltage +in1_input DC Runtime voltage +in2_input DC Standby voltage +in3_input CMOS Battery voltage +in4_input Battery voltage +in5_input AC voltage +in6_input Other voltage +in7_input 5V voltage +in8_input 5V Standby voltage +in9_input 3V3 voltage +in10_input 3V3 Standby voltage +in11_input VCore A voltage +in12_input VCore B voltage +in13_input 12V voltage +curr1_input DC current +curr2_input 5V current +curr3_input 12V current +fan1_input CPU fan +fan2_input Box fan +fan3_input Ambient fan +fan4_input Chiptset fan +fan5_input Video fan +fan6_input Other fan +============= ====================== diff --git a/Documentation/hwmon/crps.rst b/Documentation/hwmon/crps.rst new file mode 100644 index 000000000000..87380b496558 --- /dev/null +++ b/Documentation/hwmon/crps.rst @@ -0,0 +1,97 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver crps +================== + +Supported chips: + + * Intel CRPS185 + + Prefix: 'crps185' + + Addresses scanned: - + + Datasheet: Only available under NDA. + +Authors: + Ninad Palsule <ninad@linux.ibm.com> + + +Description +----------- + +This driver implements support for Intel Common Redundant Power supply with +PMBus support. + +The driver is a client driver to the core PMBus driver. +Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers. + + +Usage Notes +----------- + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for +details. + + +Sysfs entries +------------- + +======================= ====================================================== +curr1_label "iin" +curr1_input Measured input current +curr1_max Maximum input current +curr1_max_alarm Input maximum current high alarm +curr1_crit Critial high input current +curr1_crit_alarm Input critical current high alarm +curr1_rated_max Maximum rated input current + +curr2_label "iout1" +curr2_input Measured output current +curr2_max Maximum output current +curr2_max_alarm Output maximum current high alarm +curr2_crit Critial high output current +curr2_crit_alarm Output critical current high alarm +curr2_rated_max Maximum rated output current + +in1_label "vin" +in1_input Measured input voltage +in1_crit Critical input over voltage +in1_crit_alarm Critical input over voltage alarm +in1_max Maximum input over voltage +in1_max_alarm Maximum input over voltage alarm +in1_rated_min Minimum rated input voltage +in1_rated_max Maximum rated input voltage + +in2_label "vout1" +in2_input Measured input voltage +in2_crit Critical input over voltage +in2_crit_alarm Critical input over voltage alarm +in2_lcrit Critical input under voltage fault +in2_lcrit_alarm Critical input under voltage fault alarm +in2_max Maximum input over voltage +in2_max_alarm Maximum input over voltage alarm +in2_min Minimum input under voltage warning +in2_min_alarm Minimum input under voltage warning alarm +in2_rated_min Minimum rated input voltage +in2_rated_max Maximum rated input voltage + +power1_label "pin" +power1_input Measured input power +power1_alarm Input power high alarm +power1_max Maximum input power +power1_rated_max Maximum rated input power + +temp[1-2]_input Measured temperature +temp[1-2]_crit Critical temperature +temp[1-2]_crit_alarm Critical temperature alarm +temp[1-2]_max Maximum temperature +temp[1-2]_max_alarm Maximum temperature alarm +temp[1-2]_rated_max Maximum rated temperature + +fan1_alarm Fan 1 warning. +fan1_fault Fan 1 fault. +fan1_input Fan 1 speed in RPM. +fan1_target Fan 1 target. +======================= ====================================================== diff --git a/Documentation/hwmon/dell-smm-hwmon.rst b/Documentation/hwmon/dell-smm-hwmon.rst index 74905675d71f..5a4edb6565cf 100644 --- a/Documentation/hwmon/dell-smm-hwmon.rst +++ b/Documentation/hwmon/dell-smm-hwmon.rst @@ -32,12 +32,12 @@ Temperature sensors and fans can be queried and set via the standard =============================== ======= ======================================= Name Perm Description =============================== ======= ======================================= -fan[1-3]_input RO Fan speed in RPM. -fan[1-3]_label RO Fan label. -fan[1-3]_min RO Minimal Fan speed in RPM -fan[1-3]_max RO Maximal Fan speed in RPM -fan[1-3]_target RO Expected Fan speed in RPM -pwm[1-3] RW Control the fan PWM duty-cycle. +fan[1-4]_input RO Fan speed in RPM. +fan[1-4]_label RO Fan label. +fan[1-4]_min RO Minimal Fan speed in RPM +fan[1-4]_max RO Maximal Fan speed in RPM +fan[1-4]_target RO Expected Fan speed in RPM +pwm[1-4] RW Control the fan PWM duty-cycle. pwm1_enable WO Enable or disable automatic BIOS fan control (not supported on all laptops, see below for details). @@ -93,7 +93,7 @@ Again, when you find new codes, we'd be happy to have your patches! --------------------------- The driver also exports the fans as thermal cooling devices with -``type`` set to ``dell-smm-fan[1-3]``. This allows for easy fan control +``type`` set to ``dell-smm-fan[1-4]``. This allows for easy fan control using one of the thermal governors. Module parameters diff --git a/Documentation/hwmon/htu31.rst b/Documentation/hwmon/htu31.rst new file mode 100644 index 000000000000..ccde84264643 --- /dev/null +++ b/Documentation/hwmon/htu31.rst @@ -0,0 +1,37 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver HTU31 +==================== + +Supported chips: + + * Measurement Specialties HTU31 + + Prefix: 'htu31' + + Addresses scanned: - + + Datasheet: Publicly available from https://www.te.com/en/product-CAT-HSC0007.html + +Author: + + - Andrei Lalaev <andrey.lalaev@gmail.com> + +Description +----------- + +HTU31 is a humidity and temperature sensor. + +Supported temperature range is from -40 to 125 degrees Celsius. + +Communication with the device is performed via I2C protocol. Sensor's default address +is 0x40. + +sysfs-Interface +--------------- + +=================== ================= +temp1_input: temperature input +humidity1_input: humidity input +heater_enable: heater control +=================== ================= diff --git a/Documentation/hwmon/hwmon-kernel-api.rst b/Documentation/hwmon/hwmon-kernel-api.rst index 8297acfa3a2d..e47fc757e63e 100644 --- a/Documentation/hwmon/hwmon-kernel-api.rst +++ b/Documentation/hwmon/hwmon-kernel-api.rst @@ -64,7 +64,8 @@ hwmon_device_register_with_info. All supported hwmon device registration functions only accept valid device names. Device names including invalid characters (whitespace, '*', or '-') -will be rejected. The 'name' parameter is mandatory. +will be rejected. If NULL is passed as name parameter, the hardware monitoring +device name will be derived from the parent device name. If the driver doesn't use a static device name (for example it uses dev_name()), and therefore cannot make sure the name only contains valid diff --git a/Documentation/hwmon/ina233.rst b/Documentation/hwmon/ina233.rst new file mode 100644 index 000000000000..42323162e6db --- /dev/null +++ b/Documentation/hwmon/ina233.rst @@ -0,0 +1,75 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver ina233 +==================== + +Supported chips: + + * TI INA233 + + Prefix: 'ina233' + + * Datasheet + + Publicly available at the TI website : https://www.ti.com/lit/ds/symlink/ina233.pdf + +Author: Leo Yang <leo.yang.sy0@gmail.com> + +Usage Notes +----------- + +The shunt resistor value can be configured by a device tree property; +see Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml for details. + + +Description +----------- + +This driver supports hardware monitoring for TI INA233. + +The driver is a client driver to the core PMBus driver. Please see +Documentation/hwmon/pmbus.rst for details on PMBus client drivers. + +The driver provides the following attributes for input voltage: + +**in1_input** + +**in1_label** + +**in1_max** + +**in1_max_alarm** + +**in1_min** + +**in1_min_alarm** + +The driver provides the following attributes for shunt voltage: + +**in2_input** + +**in2_label** + +The driver provides the following attributes for output voltage: + +**in3_input** + +**in3_label** + +**in3_alarm** + +The driver provides the following attributes for output current: + +**curr1_input** + +**curr1_label** + +**curr1_max** + +**curr1_max_alarm** + +The driver provides the following attributes for input power: + +**power1_input** + +**power1_label** diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 55f1111594b2..f0ddf6222c44 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -53,11 +53,13 @@ Hardware Monitoring Kernel Drivers bel-pfe bpa-rs600 bt1-pvt + cgbc-hwmon chipcap2 coretemp corsair-cpro corsair-psu cros_ec_hwmon + crps da9052 da9055 dell-smm-hwmon @@ -84,11 +86,13 @@ Hardware Monitoring Kernel Drivers hih6130 hp-wmi-sensors hs3001 + htu31 ibmaem ibm-cffps ibmpowernv ina209 ina2xx + ina233 ina238 ina3221 inspur-ipsps1 @@ -201,6 +205,7 @@ Hardware Monitoring Kernel Drivers pxe1610 pwm-fan q54sj108a2 + qnap-mcu-hwmon raspberrypi-hwmon sbrmi sbtsi_temp @@ -236,6 +241,7 @@ Hardware Monitoring Kernel Drivers tmp464 tmp513 tps23861 + tps25990 tps40422 tps53679 tps546d24 diff --git a/Documentation/hwmon/isl28022.rst b/Documentation/hwmon/isl28022.rst index 8d4422a2dacd..273ce5460135 100644 --- a/Documentation/hwmon/isl28022.rst +++ b/Documentation/hwmon/isl28022.rst @@ -33,7 +33,7 @@ details. The shunt value in micro-ohms, shunt voltage range and averaging can be set with device properties. -Please refer to the Documentation/devicetree/bindings/hwmon/isl,isl28022.yaml +Please refer to the Documentation/devicetree/bindings/hwmon/renesas,isl28022.yaml for bindings if the device tree is used. The driver supports only shunt and bus continuous ADC mode at 15bit resolution. @@ -48,6 +48,7 @@ The following attributes are supported. All attributes are read-only. ======================= ======================================================= in0_input bus voltage (milli Volt) +in1_input shunt voltage (milli Volt) curr1_input current (milli Ampere) power1_input power (micro Watt) diff --git a/Documentation/hwmon/lm75.rst b/Documentation/hwmon/lm75.rst index 6adab608dd05..c6a54bbca3c5 100644 --- a/Documentation/hwmon/lm75.rst +++ b/Documentation/hwmon/lm75.rst @@ -121,15 +121,17 @@ Supported chips: https://www.ti.com/product/TMP1075 - * NXP LM75B, PCT2075 + * NXP LM75B, P3T1755, PCT2075 - Prefix: 'lm75b', 'pct2075' + Prefix: 'lm75b', 'p3t1755', 'pct2075' Addresses scanned: none Datasheet: Publicly available at the NXP website - https://www.nxp.com/documents/data_sheet/LM75B.pdf + https://www.nxp.com/docs/en/data-sheet/LM75B.pdf + + https://www.nxp.com/docs/en/data-sheet/P3T1755.pdf https://www.nxp.com/docs/en/data-sheet/PCT2075.pdf diff --git a/Documentation/hwmon/lm90.rst b/Documentation/hwmon/lm90.rst index 23af17a0ab44..98452eed16d5 100644 --- a/Documentation/hwmon/lm90.rst +++ b/Documentation/hwmon/lm90.rst @@ -365,6 +365,34 @@ Supported chips: Datasheet: Not publicly available, can be requested from Nuvoton + * Nuvoton NCT7716 + + Prefix: 'nct7716' + + Addresses scanned: I2C 0x48, 0x49 + + Datasheet: Not publicly available, can be requested from Nuvoton + + * Nuvoton NCT7717 + + Prefix: 'nct7717' + + Addresses scanned: I2C 0x48 + + Datasheet: Publicly available at Nuvoton website + + https://www.nuvoton.com/resource-files/Nuvoton_NCT7717U_Datasheet_V111.pdf + + * Nuvoton NCT7718 + + Prefix: 'nct7718' + + Addresses scanned: I2C 0x4c + + Datasheet: Publicly available at Nuvoton website + + https://www.nuvoton.com/resource-files/Nuvoton_NCT7718W_Datasheet_V11.pdf + * Philips/NXP SA56004X Prefix: 'sa56004' @@ -573,6 +601,21 @@ W83L771AWG/ASG * The AWG and ASG variants only differ in package format. * Diode ideality factor configuration (remote sensor) at 0xE3 +NCT7716: + * 8 bit sensor resolution + * Selectable address + * Configurable conversion rate + +NCT7717: + * 8 bit sensor resolution + * Configurable conversion rate + +NCT7718: + * Temperature offset register for remote temperature sensor + * 11 bit resolution for remote temperature sensor + * Low temperature limits + * Configurable conversion rate + SA56004X: * Better local resolution diff --git a/Documentation/hwmon/ltc2978.rst b/Documentation/hwmon/ltc2978.rst index 651ca4904c66..0b72d566cac7 100644 --- a/Documentation/hwmon/ltc2978.rst +++ b/Documentation/hwmon/ltc2978.rst @@ -5,6 +5,22 @@ Kernel driver ltc2978 Supported chips: + * Analog Devices LT7170 + + Prefix: 'lt7170' + + Addresses scanned: - + + Datasheet: https://www.analog.com/en/products/lt7170.html + + * Analog Devices LT7171 + + Prefix: 'lt7171' + + Addresses scanned: - + + Datasheet: https://www.analog.com/en/products/lt7171.html + * Linear Technology LTC2972 Prefix: 'ltc2972' @@ -151,6 +167,14 @@ Supported chips: Datasheet: https://www.analog.com/en/products/ltm4644 + * Linear Technology LTM4673 + + Prefix: 'ltm4673' + + Addresses scanned: - + + Datasheet: https://www.analog.com/en/products/ltm4673 + * Linear Technology LTM4675 Prefix: 'ltm4675' @@ -215,6 +239,8 @@ Author: Guenter Roeck <linux@roeck-us.net> Description ----------- +- LT7170 and LT7171 are 20 A, 16 V, single- or dual-phase Silent Switcher +- step-down regulators with Digital Power System Management. - LTC2974 and LTC2975 are quad digital power supply managers. - LTC2978 is an octal power supply monitor. - LTC2977 is a pin compatible replacement for LTC2978. @@ -292,6 +318,7 @@ in1_reset_history Reset input voltage history. in[N]_label "vout[1-8]". + - LT7170, LT7171: N=2 - LTC2972: N=2-3 - LTC2974, LTC2975: N=2-5 - LTC2977, LTC2979, LTC2980, LTM2987: N=2-9 @@ -330,6 +357,8 @@ in[N]_reset_history Reset output voltage history. temp[N]_input Measured temperature. + - On LT7170 and LT7171, temp1 reports the chip + temperature. - On LTC2972, temp[1-2] report external temperatures, and temp 3 reports the chip temperature. - On LTC2974 and LTC2975, temp[1-4] report external @@ -403,9 +432,9 @@ power[N]_input Measured output power. curr1_label "iin". - LTC3880, LTC3883, LTC3884, LTC3886, LTC3887, LTC3889, - LTM4644, LTM4675, LTM4676, LTM4677, LTM4678, LTM4680, - and LTM4700 only. + LT7170, LT7171, LTC3880, LTC3883, LTC3884, LTC3886, + LTC3887, LTC3889, LTM4644, LTM4675, LTM4676, LTM4677, + LTM4678, LTM4680, and LTM4700 only. curr1_input Measured input current. @@ -423,6 +452,7 @@ curr1_reset_history Reset input current history. curr[N]_label "iout[1-4]". + - LT7170, LT7171: N=1 - LTC2972: N-1-2 - LTC2974, LTC2975: N=1-4 - LTC2977, LTC2979, LTC2980, LTM2987: not supported diff --git a/Documentation/hwmon/max15301.rst b/Documentation/hwmon/max15301.rst index e3dc22fe1c6d..e2222e98304f 100644 --- a/Documentation/hwmon/max15301.rst +++ b/Documentation/hwmon/max15301.rst @@ -13,6 +13,14 @@ Supported chips: Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX15301.pdf + * Maxim MAX15303 + + Prefix: 'max15303' + + Addresses scanned: - + + Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max15303.pdf + Author: Erik Rosen <erik.rosen@metormote.com> diff --git a/Documentation/hwmon/nct6683.rst b/Documentation/hwmon/nct6683.rst index 2a7a78eb1b46..3e549ba95a15 100644 --- a/Documentation/hwmon/nct6683.rst +++ b/Documentation/hwmon/nct6683.rst @@ -3,7 +3,7 @@ Kernel driver nct6683 Supported chips: - * Nuvoton NCT6683D/NCT6687D + * Nuvoton NCT6683D/NCT6686D/NCT6687D Prefix: 'nct6683' @@ -55,14 +55,17 @@ Tested Boards and Firmware Versions The driver has been reported to work with the following boards and firmware versions. -=============== =============================================== -Board Firmware version -=============== =============================================== -Intel DH87RL NCT6683D EC firmware version 1.0 build 04/03/13 -Intel DH87MC NCT6683D EC firmware version 1.0 build 04/03/13 -Intel DB85FL NCT6683D EC firmware version 1.0 build 04/03/13 -ASRock X570 NCT6683D EC firmware version 1.0 build 06/28/19 -ASRock X670E NCT6686D EC firmware version 1.0 build 05/19/22 -MSI B550 NCT6687D EC firmware version 1.0 build 05/07/20 -MSI X670-P NCT6687D EC firmware version 0.0 build 09/27/22 -=============== =============================================== +=============================== =============================================== +Board Firmware version +=============================== =============================================== +Intel DH87RL NCT6683D EC firmware version 1.0 build 04/03/13 +Intel DH87MC NCT6683D EC firmware version 1.0 build 04/03/13 +Intel DB85FL NCT6683D EC firmware version 1.0 build 04/03/13 +AMD BC-250 NCT6686D EC firmware version 1.0 build 07/28/21 +ASRock X570 NCT6683D EC firmware version 1.0 build 06/28/19 +ASRock X670E NCT6686D EC firmware version 1.0 build 05/19/22 +ASRock B650 Steel Legend WiFi NCT6686D EC firmware version 1.0 build 11/09/23 +MSI B550 NCT6687D EC firmware version 1.0 build 05/07/20 +MSI X670-P NCT6687D EC firmware version 0.0 build 09/27/22 +MSI X870E NCT6687D EC firmware version 0.0 build 11/13/24 +=============================== =============================================== diff --git a/Documentation/hwmon/pmbus-core.rst b/Documentation/hwmon/pmbus-core.rst index 686a00265bf7..fdfb23773148 100644 --- a/Documentation/hwmon/pmbus-core.rst +++ b/Documentation/hwmon/pmbus-core.rst @@ -312,6 +312,10 @@ currently provides a flags field with four bits used:: #define PMBUS_USE_COEFFICIENTS_CMD BIT(5) + #define PMBUS_OP_PROTECTED BIT(6) + + #define PMBUS_VOUT_PROTECTED BIT(7) + struct pmbus_platform_data { u32 flags; /* Device specific flags */ @@ -373,3 +377,34 @@ PMBUS_USE_COEFFICIENTS_CMD When this flag is set the PMBus core driver will use the COEFFICIENTS register to initialize the coefficients for the direct mode format. + +PMBUS_OP_PROTECTED + +Set if the chip OPERATION command is protected and protection is not +determined by the standard WRITE_PROTECT command. + +PMBUS_VOUT_PROTECTED + +Set if the chip VOUT_COMMAND command is protected and protection is not +determined by the standard WRITE_PROTECT command. + +Module parameter +---------------- + +pmbus_core.wp: PMBus write protect forced mode + +PMBus may come up with a variety of write protection configuration. +'pmbus_core.wp' may be used if a particular write protection is necessary. +The ability to actually alter the protection may also depend on the chip +so the actual runtime write protection configuration may differ from +the requested one. pmbus_core currently support the following value: + +* 0: write protection removed. +* 1: Disable all writes except to the WRITE_PROTECT, OPERATION, + PAGE, ON_OFF_CONFIG and VOUT_COMMAND commands. +* 2: Disable all writes except to the WRITE_PROTECT, OPERATION and + PAGE commands. +* 3: Disable all writes except to the WRITE_PROTECT command. Note that + protection should include the PAGE register. This may be problematic + for multi-page chips, if the chips strictly follows the PMBus + specification, preventing the chip from changing the active page. diff --git a/Documentation/hwmon/qnap-mcu-hwmon.rst b/Documentation/hwmon/qnap-mcu-hwmon.rst new file mode 100644 index 000000000000..83407e3408f2 --- /dev/null +++ b/Documentation/hwmon/qnap-mcu-hwmon.rst @@ -0,0 +1,27 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver qnap-mcu-hwmon +============================ + +This driver enables the use of the hardware monitoring and fan control +of the MCU used on some QNAP network attached storage devices. + +Author: Heiko Stuebner <heiko@sntech.de> + +Description +----------- + +The driver implements a simple interface for driving the fan controlled by +setting its PWM output value and exposes the fan rpm and case-temperature +to user space through hwmon's sysfs interface. + +The fan rotation speed returned via the optional 'fan1_input' is calculated +inside the MCU device. + +The driver provides the following sensor accesses in sysfs: + +=============== ======= ======================================================= +fan1_input ro fan tachometer speed in RPM +pwm1 rw relative speed (0-255), 255=max. speed. +temp1_input ro Measured temperature in millicelsius +=============== ======= ======================================================= diff --git a/Documentation/hwmon/tps25990.rst b/Documentation/hwmon/tps25990.rst new file mode 100644 index 000000000000..04faec780d26 --- /dev/null +++ b/Documentation/hwmon/tps25990.rst @@ -0,0 +1,147 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver tps25990 +====================== + +Supported chips: + + * TI TPS25990 + + Prefix: 'tps25990' + + * Datasheet + + Publicly available at Texas Instruments website: https://www.ti.com/lit/gpn/tps25990 + +Author: + + Jerome Brunet <jbrunet@baylibre.com> + +Description +----------- + +This driver implements support for TI TPS25990 eFuse. +This is an integrated, high-current circuit protection and power +management device with PMBUS interface + +Device compliant with: + +- PMBus rev 1.3 interface. + +Device supports direct format for reading input voltages, +output voltage, input current, input power and temperature. + +Due to the specificities of the chip, all history reset attributes +are tied together. Resetting the history of a sensor, resets the +history of all the sensors. + +The driver exports the following attributes via the 'sysfs' files +for input current: + +**curr1_average** + +**curr1_crit** + +**curr1_crit_alarm** + +**curr1_highest** + +**curr1_input** + +**curr1_label** + +**curr1_max** + +**curr1_max_alarm** + +**curr1_reset_history** + +The driver provides the following attributes for main input voltage: + +**in1_average** + +**in1_crit** + +**in1_crit_alarm** + +**in1_highest** + +**in1_input** + +**in1_label** + +**in1_lcrit** + +**in1_lcrit_alarm** + +**in1_lowest** + +**in1_max** + +**in1_max_alarm** + +**in1_min** + +**in1_min_alarm** + +**in1_reset_history** + +The driver provides the following attributes for auxiliary input voltage: + +**in2_input** + +**in2_label** + +The driver provides the following attributes for output voltage: + +**in3_average** + +**in3_input** + +**in3_label** + +**in3_lowest** + +**in3_min** + +**in3_min_alarm** + +**in3_reset_history** + +The driver provides the following attributes for input power: + +**power1_alarm** + +**power1_average** + +**power1_input** + +**power1_input_highest** + +**power1_label** + +**power1_max** + +**power1_reset_history** + +The driver provides the following attributes for temperature: + +**temp1_average** + +**temp1_crit** + +**temp1_crit_alarm** + +**temp1_highest** + +**temp1_input** + +**temp1_max** + +**temp1_max_alarm** + +**temp1_reset_history** + +The driver provides the following attributes for sampling: + +**samples** diff --git a/Documentation/iio/ad4695.rst b/Documentation/iio/ad4695.rst index 33ed29b7c98a..9ec8bf466c15 100644 --- a/Documentation/iio/ad4695.rst +++ b/Documentation/iio/ad4695.rst @@ -101,7 +101,7 @@ The macro comes from: .. code-block:: - #include <dt-bindings/iio/adi,ad4695.h> + #include <dt-bindings/iio/adc/adi,ad4695.h> Pairing two INx pins ^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/iio/adis16480.rst b/Documentation/iio/adis16480.rst index bc78fa04d958..4a2d40e0daa7 100644 --- a/Documentation/iio/adis16480.rst +++ b/Documentation/iio/adis16480.rst @@ -12,7 +12,10 @@ This driver supports Analog Device's IMUs on SPI bus. * `ADIS16375 <https://www.analog.com/ADIS16375>`_ * `ADIS16480 <https://www.analog.com/ADIS16480>`_ * `ADIS16485 <https://www.analog.com/ADIS16485>`_ +* `ADIS16486 <https://www.analog.com/ADIS16486>`_ +* `ADIS16487 <https://www.analog.com/ADIS16487>`_ * `ADIS16488 <https://www.analog.com/ADIS16488>`_ +* `ADIS16489 <https://www.analog.com/ADIS16489>`_ * `ADIS16490 <https://www.analog.com/ADIS16490>`_ * `ADIS16495 <https://www.analog.com/ADIS16495>`_ * `ADIS16497 <https://www.analog.com/ADIS16497>`_ diff --git a/Documentation/iio/iio_devbuf.rst b/Documentation/iio/iio_devbuf.rst index 9919e4792d0e..dca1f0200b0d 100644 --- a/Documentation/iio/iio_devbuf.rst +++ b/Documentation/iio/iio_devbuf.rst @@ -148,5 +148,5 @@ applied), however there are corner cases in which the buffered data may be found in a processed form. Please note that these corner cases are not addressed by this documentation. -Please see ``Documentation/ABI/testing/sysfs-bus-iio`` for a complete +Please see Documentation/ABI/testing/sysfs-bus-iio for a complete description of the attributes. diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst index 074dbbf7ba0a..5710f5b9e958 100644 --- a/Documentation/iio/index.rst +++ b/Documentation/iio/index.rst @@ -29,3 +29,4 @@ Industrial I/O Kernel Drivers adxl380 bno055 ep93xx_adc + opt4060 diff --git a/Documentation/iio/opt4060.rst b/Documentation/iio/opt4060.rst new file mode 100644 index 000000000000..eb155089b6d2 --- /dev/null +++ b/Documentation/iio/opt4060.rst @@ -0,0 +1,61 @@ +============================== +OPT4060 driver +============================== + +1. Overview +============================= + +This driver supports the Texas Instrument RGBW high resolution color sensor over +I2C. +https://www.ti.com/lit/gpn/opt4060 + +The driver supports: +- Raw values for red, green, blue and clear. +- Illuminance values. +- Scaled color values for red, green and blue. +- IIO events for thresholds. +- IIO triggered buffer using both its own data ready trigger and triggers from +other drivers. + +2. Illuminance calculation +============================= + +Illuminance is calculated using the wide spectrum green channel. + +lux = GREEN_RAW x 2.15e-3 + +The value is accessed from: +/sys/bus/iio/devices/iio:deviceX/in_illuminance_input + +See section 8.4.5.2 in the data sheet for additional details. + +3. Color scale values +============================= + +The sensor has different sensitivity for the different color components and +compensating factors are exposed from the driver. + +The values are accessed from: +/sys/bus/iio/devices/iio:deviceX/in_intensity_red_scale +/sys/bus/iio/devices/iio:deviceX/in_intensity_green_scale +/sys/bus/iio/devices/iio:deviceX/in_intensity_blue_scale + +A userspace application can multiply the raw values with the scale values so +that for a particular test light source, typically white, the measurement +intensity is the same across the different color channels. This is calculated +in the following way: + +R = RED_RAW x SCALE_RED(2.4) +G = GREEN_RAW x SCALE_GREEN(1.0) +B = BLUE_RAW x SCALE_BLUE(1.3) + +The data sheet suggests using the scaled values to normalize the scaled R, G +and B values. This is useful to get a value for the ratio between colors +independent of light intensity. A userspace application can do this in the +following way: + +R_NORMALIZED = R / (R + G + B) +G_NORMALIZED = G / (R + G + B) +B_NORMALIZED = B / (R + G + B) + +See section 8.4.5.2 in the data sheet for additional details. diff --git a/Documentation/input/devices/elantech.rst b/Documentation/input/devices/elantech.rst index c3374a7ce7af..98163a258b83 100644 --- a/Documentation/input/devices/elantech.rst +++ b/Documentation/input/devices/elantech.rst @@ -556,7 +556,7 @@ Note on debounce: In case the box has unstable power supply or other electricity issues, or when number of finger changes, F/W would send "debounce packet" to inform driver that the hardware is in debounce status. -The debouce packet has the following signature:: +The debounce packet has the following signature:: byte 0: 0xc4 byte 1: 0xff diff --git a/Documentation/input/input-programming.rst b/Documentation/input/input-programming.rst index c9264814c7aa..2b3e6a34e34b 100644 --- a/Documentation/input/input-programming.rst +++ b/Documentation/input/input-programming.rst @@ -346,3 +346,22 @@ driver can handle these events, it has to set the respective bits in evbit, This callback routine can be called from an interrupt or a BH (although that isn't a rule), and thus must not sleep, and must not take too long to finish. + +Polled input devices +~~~~~~~~~~~~~~~~~~~~ + +Input polling is set up by passing an input device struct and a callback to +the function:: + + int input_setup_polling(struct input_dev *dev, + void (*poll_fn)(struct input_dev *dev)) + +Within the callback, devices should use the regular input_report_* functions +and input_sync as is used by other devices. + +There is also the function:: + + void input_set_poll_interval(struct input_dev *dev, unsigned int interval) + +which is used to configure the interval, in milliseconds, that the device will +be polled at. diff --git a/Documentation/kbuild/gendwarfksyms.rst b/Documentation/kbuild/gendwarfksyms.rst new file mode 100644 index 000000000000..e4beaae7e456 --- /dev/null +++ b/Documentation/kbuild/gendwarfksyms.rst @@ -0,0 +1,308 @@ +======================= +DWARF module versioning +======================= + +1. Introduction +=============== + +When CONFIG_MODVERSIONS is enabled, symbol versions for modules +are typically calculated from preprocessed source code using the +**genksyms** tool. However, this is incompatible with languages such +as Rust, where the source code has insufficient information about +the resulting ABI. With CONFIG_GENDWARFKSYMS (and CONFIG_DEBUG_INFO) +selected, **gendwarfksyms** is used instead to calculate symbol versions +from the DWARF debugging information, which contains the necessary +details about the final module ABI. + +1.1. Usage +========== + +gendwarfksyms accepts a list of object files on the command line, and a +list of symbol names (one per line) in standard input:: + + Usage: gendwarfksyms [options] elf-object-file ... < symbol-list + + Options: + -d, --debug Print debugging information + --dump-dies Dump DWARF DIE contents + --dump-die-map Print debugging information about die_map changes + --dump-types Dump type strings + --dump-versions Dump expanded type strings used for symbol versions + -s, --stable Support kABI stability features + -T, --symtypes file Write a symtypes file + -h, --help Print this message + + +2. Type information availability +================================ + +While symbols are typically exported in the same translation unit (TU) +where they're defined, it's also perfectly fine for a TU to export +external symbols. For example, this is done when calculating symbol +versions for exports in stand-alone assembly code. + +To ensure the compiler emits the necessary DWARF type information in the +TU where symbols are actually exported, gendwarfksyms adds a pointer +to exported symbols in the `EXPORT_SYMBOL()` macro using the following +macro:: + + #define __GENDWARFKSYMS_EXPORT(sym) \ + static typeof(sym) *__gendwarfksyms_ptr_##sym __used \ + __section(".discard.gendwarfksyms") = &sym; + + +When a symbol pointer is found in DWARF, gendwarfksyms can use its +type for calculating symbol versions even if the symbol is defined +elsewhere. The name of the symbol pointer is expected to start with +`__gendwarfksyms_ptr_`, followed by the name of the exported symbol. + +3. Symtypes output format +========================= + +Similarly to genksyms, gendwarfksyms supports writing a symtypes +file for each processed object that contain types for exported +symbols and each referenced type that was used in calculating symbol +versions. These files can be useful when trying to determine what +exactly caused symbol versions to change between builds. To generate +symtypes files during a kernel build, set `KBUILD_SYMTYPES=1`. + +Matching the existing format, the first column of each line contains +either a type reference or a symbol name. Type references have a +one-letter prefix followed by "#" and the name of the type. Four +reference types are supported:: + + e#<type> = enum + s#<type> = struct + t#<type> = typedef + u#<type> = union + +Type names with spaces in them are wrapped in single quotes, e.g.:: + + s#'core::result::Result<u8, core::num::error::ParseIntError>' + +The rest of the line contains a type string. Unlike with genksyms that +produces C-style type strings, gendwarfksyms uses the same simple parsed +DWARF format produced by **--dump-dies**, but with type references +instead of fully expanded strings. + +4. Maintaining a stable kABI +============================ + +Distribution maintainers often need the ability to make ABI compatible +changes to kernel data structures due to LTS updates or backports. Using +the traditional `#ifndef __GENKSYMS__` to hide these changes from symbol +versioning won't work when processing object files. To support this +use case, gendwarfksyms provides kABI stability features designed to +hide changes that won't affect the ABI when calculating versions. These +features are all gated behind the **--stable** command line flag and are +not used in the mainline kernel. To use stable features during a kernel +build, set `KBUILD_GENDWARFKSYMS_STABLE=1`. + +Examples for using these features are provided in the +**scripts/gendwarfksyms/examples** directory, including helper macros +for source code annotation. Note that as these features are only used to +transform the inputs for symbol versioning, the user is responsible for +ensuring that their changes actually won't break the ABI. + +4.1. kABI rules +=============== + +kABI rules allow distributions to fine-tune certain parts +of gendwarfksyms output and thus control how symbol +versions are calculated. These rules are defined in the +`.discard.gendwarfksyms.kabi_rules` section of the object file and +consist of simple null-terminated strings with the following structure:: + + version\0type\0target\0value\0 + +This string sequence is repeated as many times as needed to express all +the rules. The fields are as follows: + +- `version`: Ensures backward compatibility for future changes to the + structure. Currently expected to be "1". +- `type`: Indicates the type of rule being applied. +- `target`: Specifies the target of the rule, typically the fully + qualified name of the DWARF Debugging Information Entry (DIE). +- `value`: Provides rule-specific data. + +The following helper macro, for example, can be used to specify rules +in the source code:: + + #define __KABI_RULE(hint, target, value) \ + static const char __PASTE(__gendwarfksyms_rule_, \ + __COUNTER__)[] __used __aligned(1) \ + __section(".discard.gendwarfksyms.kabi_rules") = \ + "1\0" #hint "\0" #target "\0" #value + + +Currently, only the rules discussed in this section are supported, but +the format is extensible enough to allow further rules to be added as +need arises. + +4.1.1. Managing definition visibility +===================================== + +A declaration can change into a full definition when additional includes +are pulled into the translation unit. This changes the versions of any +symbol that references the type even if the ABI remains unchanged. As +it may not be possible to drop includes without breaking the build, the +`declonly` rule can be used to specify a type as declaration-only, even +if the debugging information contains the full definition. + +The rule fields are expected to be as follows: + +- `type`: "declonly" +- `target`: The fully qualified name of the target data structure + (as shown in **--dump-dies** output). +- `value`: This field is ignored. + +Using the `__KABI_RULE` macro, this rule can be defined as:: + + #define KABI_DECLONLY(fqn) __KABI_RULE(declonly, fqn, ) + +Example usage:: + + struct s { + /* definition */ + }; + + KABI_DECLONLY(s); + +4.1.2. Adding enumerators +========================= + +For enums, all enumerators and their values are included in calculating +symbol versions, which becomes a problem if we later need to add more +enumerators without changing symbol versions. The `enumerator_ignore` +rule allows us to hide named enumerators from the input. + +The rule fields are expected to be as follows: + +- `type`: "enumerator_ignore" +- `target`: The fully qualified name of the target enum + (as shown in **--dump-dies** output) and the name of the + enumerator field separated by a space. +- `value`: This field is ignored. + +Using the `__KABI_RULE` macro, this rule can be defined as:: + + #define KABI_ENUMERATOR_IGNORE(fqn, field) \ + __KABI_RULE(enumerator_ignore, fqn field, ) + +Example usage:: + + enum e { + A, B, C, D, + }; + + KABI_ENUMERATOR_IGNORE(e, B); + KABI_ENUMERATOR_IGNORE(e, C); + +If the enum additionally includes an end marker and new values must +be added in the middle, we may need to use the old value for the last +enumerator when calculating versions. The `enumerator_value` rule allows +us to override the value of an enumerator for version calculation: + +- `type`: "enumerator_value" +- `target`: The fully qualified name of the target enum + (as shown in **--dump-dies** output) and the name of the + enumerator field separated by a space. +- `value`: Integer value used for the field. + +Using the `__KABI_RULE` macro, this rule can be defined as:: + + #define KABI_ENUMERATOR_VALUE(fqn, field, value) \ + __KABI_RULE(enumerator_value, fqn field, value) + +Example usage:: + + enum e { + A, B, C, LAST, + }; + + KABI_ENUMERATOR_IGNORE(e, C); + KABI_ENUMERATOR_VALUE(e, LAST, 2); + +4.3. Adding structure members +============================= + +Perhaps the most common ABI compatible change is adding a member to a +kernel data structure. When changes to a structure are anticipated, +distribution maintainers can pre-emptively reserve space in the +structure and take it into use later without breaking the ABI. If +changes are needed to data structures without reserved space, existing +alignment holes can potentially be used instead. While kABI rules could +be added for these type of changes, using unions is typically a more +natural method. This section describes gendwarfksyms support for using +reserved space in data structures and hiding members that don't change +the ABI when calculating symbol versions. + +4.3.1. Reserving space and replacing members +============================================ + +Space is typically reserved for later use by appending integer types, or +arrays, to the end of the data structure, but any type can be used. Each +reserved member needs a unique name, but as the actual purpose is usually +not known at the time the space is reserved, for convenience, names that +start with `__kabi_` are left out when calculating symbol versions:: + + struct s { + long a; + long __kabi_reserved_0; /* reserved for future use */ + }; + +The reserved space can be taken into use by wrapping the member in a +union, which includes the original type and the replacement member:: + + struct s { + long a; + union { + long __kabi_reserved_0; /* original type */ + struct b b; /* replaced field */ + }; + }; + +If the `__kabi_` naming scheme was used when reserving space, the name +of the first member of the union must start with `__kabi_reserved`. This +ensures the original type is used when calculating versions, but the name +is again left out. The rest of the union is ignored. + +If we're replacing a member that doesn't follow this naming convention, +we also need to preserve the original name to avoid changing versions, +which we can do by changing the first union member's name to start with +`__kabi_renamed` followed by the original name. + +The examples include `KABI_(RESERVE|USE|REPLACE)*` macros that help +simplify the process and also ensure the replacement member is correctly +aligned and its size won't exceed the reserved space. + +4.3.2. Hiding members +===================== + +Predicting which structures will require changes during the support +timeframe isn't always possible, in which case one might have to resort +to placing new members into existing alignment holes:: + + struct s { + int a; + /* a 4-byte alignment hole */ + unsigned long b; + }; + + +While this won't change the size of the data structure, one needs to +be able to hide the added members from symbol versioning. Similarly +to reserved fields, this can be accomplished by wrapping the added +member to a union where one of the fields has a name starting with +`__kabi_ignored`:: + + struct s { + int a; + union { + char __kabi_ignored_0; + int n; + }; + unsigned long b; + }; + +With **--stable**, both versions produce the same symbol version. diff --git a/Documentation/kbuild/index.rst b/Documentation/kbuild/index.rst index cee2f99f734b..e82af05cd652 100644 --- a/Documentation/kbuild/index.rst +++ b/Documentation/kbuild/index.rst @@ -21,6 +21,7 @@ Kernel Build System reproducible-builds gcc-plugins llvm + gendwarfksyms .. only:: subproject and html diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst index 17c9f920f03d..3388a10f2dcc 100644 --- a/Documentation/kbuild/kbuild.rst +++ b/Documentation/kbuild/kbuild.rst @@ -91,6 +91,17 @@ HOSTRUSTFLAGS ------------- Additional flags to be passed to $(HOSTRUSTC) when building host programs. +PROCMACROLDFLAGS +---------------- +Flags to be passed when linking Rust proc macros. Since proc macros are loaded +by rustc at build time, they must be linked in a way that is compatible with +the rustc toolchain being used. + +For instance, it can be useful when rustc uses a different C library than +the one the user wants to use for host programs. + +If unset, it defaults to the flags passed when linking host programs. + HOSTLDFLAGS ----------- Additional flags to be passed when linking host programs. diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst index 101de236cd0c..a42f00d8cb90 100644 --- a/Documentation/kbuild/modules.rst +++ b/Documentation/kbuild/modules.rst @@ -423,6 +423,26 @@ Symbols From the Kernel (vmlinux + modules) 1) It lists all exported symbols from vmlinux and all modules. 2) It lists the CRC if CONFIG_MODVERSIONS is enabled. +Version Information Formats +--------------------------- + + Exported symbols have information stored in __ksymtab or __ksymtab_gpl + sections. Symbol names and namespaces are stored in __ksymtab_strings, + using a format similar to the string table used for ELF. If + CONFIG_MODVERSIONS is enabled, the CRCs corresponding to exported + symbols will be added to the __kcrctab or __kcrctab_gpl. + + If CONFIG_BASIC_MODVERSIONS is enabled (default with + CONFIG_MODVERSIONS), imported symbols will have their symbol name and + CRC stored in the __versions section of the importing module. This + mode only supports symbols of length up to 64 bytes. + + If CONFIG_EXTENDED_MODVERSIONS is enabled (required to enable both + CONFIG_MODVERSIONS and CONFIG_RUST at the same time), imported symbols + will have their symbol name recorded in the __version_ext_names + section as a series of concatenated, null-terminated strings. CRCs for + these symbols will be recorded in the __version_ext_crcs section. + Symbols and External Modules ---------------------------- diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst index 3ade16c18328..0ab0a2128a11 100644 --- a/Documentation/leds/index.rst +++ b/Documentation/leds/index.rst @@ -28,4 +28,5 @@ LEDs leds-mlxcpld leds-mt6370-rgb leds-sc27xx + leds-st1202.rst leds-qcom-lpg diff --git a/Documentation/leds/leds-st1202.rst b/Documentation/leds/leds-st1202.rst new file mode 100644 index 000000000000..1a09fbfcedcf --- /dev/null +++ b/Documentation/leds/leds-st1202.rst @@ -0,0 +1,34 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================ +Kernel driver for STMicroelectronics LED1202 +============================================ + +/sys/class/leds/<led>/hw_pattern +-------------------------------- + +Specify a hardware pattern for the ST1202 LED. The LED controller +implements 12 low-side current generators with independent dimming +control. Internal volatile memory allows the user to store up to 8 +different patterns. Each pattern is a particular output configuration +in terms of PWM duty-cycle and duration (ms). + +To be compatible with the hardware pattern format, maximum 8 tuples of +brightness (PWM) and duration must be written to hw_pattern. + +- Min pattern duration: 22 ms +- Max pattern duration: 5660 ms + +The format of the hardware pattern values should be: +"brightness duration brightness duration ..." + +/sys/class/leds/<led>/repeat +---------------------------- + +Specify a pattern repeat number, which is common for all channels. +Default is 1; negative numbers and 0 are invalid. + +This file will always return the originally written repeat number. + +When the 255 value is written to it, all patterns will repeat +indefinitely. diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst index f9c50525bdbf..e28c6a1b40ae 100644 --- a/Documentation/mm/damon/design.rst +++ b/Documentation/mm/damon/design.rst @@ -203,6 +203,8 @@ This scheme, however, cannot preserve the quality of the output if the assumption is not guaranteed. +.. _damon_design_adaptive_regions_adjustment: + Adaptive Regions Adjustment ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -264,6 +266,61 @@ tracepoints. For more details, please refer to the documentations for respectively. +.. _damon_design_monitoring_params_tuning_guide: + +Monitoring Parameters Tuning Guide +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In short, set ``aggregation interval`` to capture meaningful amount of accesses +for the purpose. The amount of accesses can be measured using ``nr_accesses`` +and ``age`` of regions in the aggregated monitoring results snapshot. The +default value of the interval, ``100ms``, turns out to be too short in many +cases. Set ``sampling interval`` proportional to ``aggregation interval``. By +default, ``1/20`` is recommended as the ratio. + +``Aggregation interval`` should be set as the time interval that the workload +can make an amount of accesses for the monitoring purpose, within the interval. +If the interval is too short, only small number of accesses are captured. As a +result, the monitoring results look everything is samely accessed only rarely. +For many purposes, that would be useless. If it is too long, however, the time +to converge regions with the :ref:`regions adjustment mechanism +<damon_design_adaptive_regions_adjustment>` can be too long, depending on the +time scale of the given purpose. This could happen if the workload is actually +making only rare accesses but the user thinks the amount of accesses for the +monitoring purpose too high. For such cases, the target amount of access to +capture per ``aggregation interval`` should carefully reconsidered. Also, note +that the captured amount of accesses is represented with not only +``nr_accesses``, but also ``age``. For example, even if every region on the +monitoring results show zero ``nr_accesses``, regions could still be +distinguished using ``age`` values as the recency information. + +Hence the optimum value of ``aggregation interval`` depends on the access +intensiveness of the workload. The user should tune the interval based on the +amount of access that captured on each aggregated snapshot of the monitoring +results. + +Note that the default value of the interval is 100 milliseconds, which is too +short in many cases, especially on large systems. + +``Sampling interval`` defines the resolution of each aggregation. If it is set +too large, monitoring results will look like every region was samely rarely +accessed, or samely frequently accessed. That is, regions become +undistinguishable based on access pattern, and therefore the results will be +useless in many use cases. If ``sampling interval`` is too small, it will not +degrade the resolution, but will increase the monitoring overhead. If it is +appropriate enough to provide a resolution of the monitoring results that +sufficient for the given purpose, it shouldn't be unnecessarily further +lowered. It is recommended to be set proportional to ``aggregation interval``. +By default, the ratio is set as ``1/20``, and it is still recommended. + +Refer to below documents for an example tuning based on the above guide. + +.. toctree:: + :maxdepth: 1 + + monitoring_intervals_tuning_example + + .. _damon_design_damos: Operation Schemes @@ -504,9 +561,34 @@ have a list of latency-critical processes. To let users optimize DAMOS schemes with such special knowledge, DAMOS provides a feature called DAMOS filters. The feature allows users to set an arbitrary -number of filters for each scheme. Each filter specifies the type of target -memory, and whether it should exclude the memory of the type (filter-out), or -all except the memory of the type (filter-in). +number of filters for each scheme. Each filter specifies + +- a type of memory (``type``), +- whether it is for the memory of the type or all except the type + (``matching``), and +- whether it is to allow (include) or reject (exclude) applying + the scheme's action to the memory (``allow``). + +When multiple filters are installed, each filter is evaluated in the installed +order. If a part of memory is matched to one of the filter, next filters are +ignored. If the memory passes through the filters evaluation stage because it +is not matched to any of the filters, applying the scheme's action to it is +allowed, same to the behavior when no filter exists. + +For example, let's assume 1) a filter for allowing anonymous pages and 2) +another filter for rejecting young pages are installed in the order. If a page +of a region that eligible to apply the scheme's action is an anonymous page, +the scheme's action will be applied to the page regardless of whether it is +young or not, since it matches with the first allow-filter. If the page is +not anonymous but young, the scheme's action will not be applied, since the +second reject-filter blocks it. If the page is neither anonymous nor young, +the page will pass through the filters evaluation stage since there is no +matching filter, and the action will be applied to the page. + +Note that the action can equally be applied to memory that either explicitly +filter-allowed or filters evaluation stage passed. It means that installing +allow-filters at the end of the list makes no practical change but only +filters-checking overhead. For efficient handling of filters, some types of filters are handled by the core layer, while others are handled by operations set. In the latter case, @@ -516,7 +598,7 @@ filter are not counted as the scheme has tried to the region. In contrast, if a memory regions is filtered by an operations set layer-handled filter, it is counted as the scheme has tried. This difference affects the statistics. -Below types of filters are currently supported. +Below ``type`` of filters are currently supported. - anonymous page - Applied to pages that containing data that not stored in files. @@ -539,6 +621,60 @@ To know how user-space can set the watermarks via :ref:`DAMON sysfs interface <sysfs_interface>`, refer to :ref:`filters <sysfs_filters>` part of the documentation. +.. _damon_design_damos_stat: + +Statistics +~~~~~~~~~~ + +The statistics of DAMOS behaviors that designed to help monitoring, tuning and +debugging of DAMOS. + +DAMOS accounts below statistics for each scheme, from the beginning of the +scheme's execution. + +- ``nr_tried``: Total number of regions that the scheme is tried to be applied. +- ``sz_trtied``: Total size of regions that the scheme is tried to be applied. +- ``sz_ops_filter_passed``: Total bytes that passed operations set + layer-handled DAMOS filters. +- ``nr_applied``: Total number of regions that the scheme is applied. +- ``sz_applied``: Total size of regions that the scheme is applied. +- ``qt_exceeds``: Total number of times the quota of the scheme has exceeded. + +"A scheme is tried to be applied to a region" means DAMOS core logic determined +the region is eligible to apply the scheme's :ref:`action +<damon_design_damos_action>`. The :ref:`access pattern +<damon_design_damos_access_pattern>`, :ref:`quotas +<damon_design_damos_quotas>`, :ref:`watermarks +<damon_design_damos_watermarks>`, and :ref:`filters +<damon_design_damos_filters>` that handled on core logic could affect this. +The core logic will only ask the underlying :ref:`operation set +<damon_operations_set>` to do apply the action to the region, so whether the +action is really applied or not is unclear. That's why it is called "tried". + +"A scheme is applied to a region" means the :ref:`operation set +<damon_operations_set>` has applied the action to at least a part of the +region. The :ref:`filters <damon_design_damos_filters>` that handled by the +operation set, and the types of the :ref:`action <damon_design_damos_action>` +and the pages of the region can affect this. For example, if a filter is set +to exclude anonymous pages and the region has only anonymous pages, or if the +action is ``pageout`` while all pages of the region are unreclaimable, applying +the action to the region will fail. + +To know how user-space can read the stats via :ref:`DAMON sysfs interface +<sysfs_interface>`, refer to :ref:s`stats <sysfs_stats>` part of the +documentation. + +Regions Walking +~~~~~~~~~~~~~~~ + +DAMOS feature allowing users access each region that a DAMOS action has just +applied. Using this feature, DAMON :ref:`API <damon_design_api>` allows users +access full properties of the regions including the access monitoring results +and amount of the region's internal memory that passed the DAMOS filters. +:ref:`DAMON sysfs interface <sysfs_interface>` also allows users read the data +via special :ref:`files <sysfs_schemes_tried_regions>`. + +.. _damon_design_api: Application Programming Interface --------------------------------- @@ -573,15 +709,11 @@ General Purpose User Interface Modules DAMON modules that provide user space ABIs for general purpose DAMON usage in runtime. -DAMON user interface modules, namely 'DAMON sysfs interface' and 'DAMON debugfs -interface' are DAMON API user kernel modules that provide ABIs to the -user-space. Please note that DAMON debugfs interface is currently deprecated. - -Like many other ABIs, the modules create files on sysfs and debugfs, allow -users to specify their requests to and get the answers from DAMON by writing to -and reading from the files. As a response to such I/O, DAMON user interface -modules control DAMON and retrieve the results as user requested via the DAMON -API, and return the results to the user-space. +Like many other ABIs, the modules create files on pseudo file systems like +'sysfs', allow users to specify their requests to and get the answers from +DAMON by writing to and reading from the files. As a response to such I/O, +DAMON user interface modules control DAMON and retrieve the results as user +requested via the DAMON API, and return the results to the user-space. The ABIs are designed to be used for user space applications development, rather than human beings' fingers. Human users are recommended to use such @@ -590,8 +722,9 @@ Github (https://github.com/damonitor/damo), Pypi (https://pypistats.org/packages/damo), and Fedora (https://packages.fedoraproject.org/pkgs/python-damo/damo/). -Please refer to the ABI :doc:`document </admin-guide/mm/damon/usage>` for -details of the interfaces. +Currently, one module for this type, namely 'DAMON sysfs interface' is +available. Please refer to the ABI :ref:`doc <sysfs_interface>` for details of +the interfaces. Special-Purpose Access-aware Kernel Modules @@ -599,8 +732,8 @@ Special-Purpose Access-aware Kernel Modules DAMON modules that provide user space ABI for specific purpose DAMON usage. -DAMON sysfs/debugfs user interfaces are for full control of all DAMON features -in runtime. For each special-purpose system-wide data access-aware system +DAMON user interface modules are for full control of all DAMON features in +runtime. For each special-purpose system-wide data access-aware system operations such as proactive reclamation or LRU lists balancing, the interfaces could be simplified by removing unnecessary knobs for the specific purpose, and extended for boot-time and even compile time control. Default values of DAMON diff --git a/Documentation/mm/damon/monitoring_intervals_tuning_example.rst b/Documentation/mm/damon/monitoring_intervals_tuning_example.rst new file mode 100644 index 000000000000..334a854efb40 --- /dev/null +++ b/Documentation/mm/damon/monitoring_intervals_tuning_example.rst @@ -0,0 +1,247 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================================= +DAMON Moniting Interval Parameters Tuning Example +================================================= + +DAMON's monitoring parameters need tuning based on given workload and the +monitoring purpose. There is a :ref:`tuning guide +<damon_design_monitoring_params_tuning_guide>` for that. This document +provides an example tuning based on the guide. + +Setup +===== + +For below example, DAMON of Linux kernel v6.11 and `damo +<https://github.com/damonitor/damo>`_ (DAMON user-space tool) v2.5.9 was used to +monitor and visualize access patterns on the physical address space of a system +running a real-world server workload. + +5ms/100ms intervals: Too Short Interval +======================================= + +Let's start by capturing the access pattern snapshot on the physical address +space of the system using DAMON, with the default interval parameters (5 +milliseconds and 100 milliseconds for the sampling and the aggregation +intervals, respectively). Wait ten minutes between the start of DAMON and +the capturing of the snapshot, to show a meaningful time-wise access patterns. +:: + + # damo start + # sleep 600 + # damo record --snapshot 0 1 + # damo stop + +Then, list the DAMON-found regions of different access patterns, sorted by the +"access temperature". "Access temperature" is a metric representing the +access-hotness of a region. It is calculated as a weighted sum of the access +frequency and the age of the region. If the access frequency is 0 %, the +temperature is multipled by minus one. That is, if a region is not accessed, +it gets minus temperature and it gets lower as not accessed for longer time. +The sorting is in temperature-ascendint order, so the region at the top of the +list is the coldest, and the one at the bottom is the hottest one. :: + + # damo report access --sort_regions_by temperature + 0 addr 16.052 GiB size 5.985 GiB access 0 % age 5.900 s # coldest + 1 addr 22.037 GiB size 6.029 GiB access 0 % age 5.300 s + 2 addr 28.065 GiB size 6.045 GiB access 0 % age 5.200 s + 3 addr 10.069 GiB size 5.983 GiB access 0 % age 4.500 s + 4 addr 4.000 GiB size 6.069 GiB access 0 % age 4.400 s + 5 addr 62.008 GiB size 3.992 GiB access 0 % age 3.700 s + 6 addr 56.795 GiB size 5.213 GiB access 0 % age 3.300 s + 7 addr 39.393 GiB size 6.096 GiB access 0 % age 2.800 s + 8 addr 50.782 GiB size 6.012 GiB access 0 % age 2.800 s + 9 addr 34.111 GiB size 5.282 GiB access 0 % age 2.300 s + 10 addr 45.489 GiB size 5.293 GiB access 0 % age 1.800 s # hottest + total size: 62.000 GiB + +The list shows not seemingly hot regions, and only minimum access pattern +diversity. Every region has zero access frequency. The number of region is +10, which is the default ``min_nr_regions value``. Size of each region is also +nearly idential. We can suspect this is because “adaptive regions adjustment” +mechanism was not well working. As the guide suggested, we can get relative +hotness of regions using ``age`` as the recency information. That would be +better than nothing, but given the fact that the longest age is only about 6 +seconds while we waited about ten minuts, it is unclear how useful this will +be. + +The temperature ranges to total size of regions of each range histogram +visualization of the results also shows no interesting distribution pattern. :: + + # damo report access --style temperature-sz-hist + <temperature> <total size> + [-,590,000,000, -,549,000,000) 5.985 GiB |********** | + [-,549,000,000, -,508,000,000) 12.074 GiB |********************| + [-,508,000,000, -,467,000,000) 0 B | | + [-,467,000,000, -,426,000,000) 12.052 GiB |********************| + [-,426,000,000, -,385,000,000) 0 B | | + [-,385,000,000, -,344,000,000) 3.992 GiB |******* | + [-,344,000,000, -,303,000,000) 5.213 GiB |********* | + [-,303,000,000, -,262,000,000) 12.109 GiB |********************| + [-,262,000,000, -,221,000,000) 5.282 GiB |********* | + [-,221,000,000, -,180,000,000) 0 B | | + [-,180,000,000, -,139,000,000) 5.293 GiB |********* | + total size: 62.000 GiB + +In short, the parameters provide poor quality monitoring results for hot +regions detection. According to the :ref:`guide +<damon_design_monitoring_params_tuning_guide>`, this is due to the too short +aggregation interval. + +100ms/2s intervals: Starts Showing Small Hot Regions +==================================================== + +Following the guide, increase the interval 20 times (100 milliseocnds and 2 +seconds for sampling and aggregation intervals, respectively). :: + + # damo start -s 100ms -a 2s + # sleep 600 + # damo record --snapshot 0 1 + # damo stop + # damo report access --sort_regions_by temperature + 0 addr 10.180 GiB size 6.117 GiB access 0 % age 7 m 8 s # coldest + 1 addr 49.275 GiB size 6.195 GiB access 0 % age 6 m 14 s + 2 addr 62.421 GiB size 3.579 GiB access 0 % age 6 m 4 s + 3 addr 40.154 GiB size 6.127 GiB access 0 % age 5 m 40 s + 4 addr 16.296 GiB size 6.182 GiB access 0 % age 5 m 32 s + 5 addr 34.254 GiB size 5.899 GiB access 0 % age 5 m 24 s + 6 addr 46.281 GiB size 2.995 GiB access 0 % age 5 m 20 s + 7 addr 28.420 GiB size 5.835 GiB access 0 % age 5 m 6 s + 8 addr 4.000 GiB size 6.180 GiB access 0 % age 4 m 16 s + 9 addr 22.478 GiB size 5.942 GiB access 0 % age 3 m 58 s + 10 addr 55.470 GiB size 915.645 MiB access 0 % age 3 m 6 s + 11 addr 56.364 GiB size 6.056 GiB access 0 % age 2 m 8 s + 12 addr 56.364 GiB size 4.000 KiB access 95 % age 16 s + 13 addr 49.275 GiB size 4.000 KiB access 100 % age 8 m 24 s # hottest + total size: 62.000 GiB + # damo report access --style temperature-sz-hist + <temperature> <total size> + [-42,800,000,000, -33,479,999,000) 22.018 GiB |***************** | + [-33,479,999,000, -24,159,998,000) 27.090 GiB |********************| + [-24,159,998,000, -14,839,997,000) 6.836 GiB |****** | + [-14,839,997,000, -5,519,996,000) 6.056 GiB |***** | + [-5,519,996,000, 3,800,005,000) 4.000 KiB |* | + [3,800,005,000, 13,120,006,000) 0 B | | + [13,120,006,000, 22,440,007,000) 0 B | | + [22,440,007,000, 31,760,008,000) 0 B | | + [31,760,008,000, 41,080,009,000) 0 B | | + [41,080,009,000, 50,400,010,000) 0 B | | + [50,400,010,000, 59,720,011,000) 4.000 KiB |* | + total size: 62.000 GiB + +DAMON found two distinct 4 KiB regions that pretty hot. The regions are also +well aged. The hottest 4 KiB region was keeping the access frequency for about +8 minutes, and the coldest region was keeping no access for about 7 minutes. +The distribution on the histogram also looks like having a pattern. + +Especially, the finding of the 4 KiB regions among the 62 GiB total memory +shows DAMON’s adaptive regions adjustment is working as designed. + +Still the number of regions is close to the ``min_nr_regions``, and sizes of +cold regions are similar, though. Apparently it is improved, but it still has +rooms to improve. + +400ms/8s intervals: Pretty Improved Results +=========================================== + +Increase the intervals four times (400 milliseconds and 8 seconds +for sampling and aggregation intervals, respectively). :: + + # damo start -s 400ms -a 8s + # sleep 600 + # damo record --snapshot 0 1 + # damo stop + # damo report access --sort_regions_by temperature + 0 addr 64.492 GiB size 1.508 GiB access 0 % age 6 m 48 s # coldest + 1 addr 21.749 GiB size 5.674 GiB access 0 % age 6 m 8 s + 2 addr 27.422 GiB size 5.801 GiB access 0 % age 6 m + 3 addr 49.431 GiB size 8.675 GiB access 0 % age 5 m 28 s + 4 addr 33.223 GiB size 5.645 GiB access 0 % age 5 m 12 s + 5 addr 58.321 GiB size 6.170 GiB access 0 % age 5 m 4 s + [...] + 25 addr 6.615 GiB size 297.531 MiB access 15 % age 0 ns + 26 addr 9.513 GiB size 12.000 KiB access 20 % age 0 ns + 27 addr 9.511 GiB size 108.000 KiB access 25 % age 0 ns + 28 addr 9.513 GiB size 20.000 KiB access 25 % age 0 ns + 29 addr 9.511 GiB size 12.000 KiB access 30 % age 0 ns + 30 addr 9.520 GiB size 4.000 KiB access 40 % age 0 ns + [...] + 41 addr 9.520 GiB size 4.000 KiB access 80 % age 56 s + 42 addr 9.511 GiB size 12.000 KiB access 100 % age 6 m 16 s + 43 addr 58.321 GiB size 4.000 KiB access 100 % age 6 m 24 s + 44 addr 9.512 GiB size 4.000 KiB access 100 % age 6 m 48 s + 45 addr 58.106 GiB size 4.000 KiB access 100 % age 6 m 48 s # hottest + total size: 62.000 GiB + # damo report access --style temperature-sz-hist + <temperature> <total size> + [-40,800,000,000, -32,639,999,000) 21.657 GiB |********************| + [-32,639,999,000, -24,479,998,000) 17.938 GiB |***************** | + [-24,479,998,000, -16,319,997,000) 16.885 GiB |**************** | + [-16,319,997,000, -8,159,996,000) 586.879 MiB |* | + [-8,159,996,000, 5,000) 4.946 GiB |***** | + [5,000, 8,160,006,000) 260.000 KiB |* | + [8,160,006,000, 16,320,007,000) 0 B | | + [16,320,007,000, 24,480,008,000) 0 B | | + [24,480,008,000, 32,640,009,000) 0 B | | + [32,640,009,000, 40,800,010,000) 16.000 KiB |* | + [40,800,010,000, 48,960,011,000) 8.000 KiB |* | + total size: 62.000 GiB + +The number of regions having different access patterns has significantly +increased. Size of each region is also more varied. Total size of non-zero +access frequency regions is also significantly increased. Maybe this is already +good enough to make some meaningful memory management efficieny changes. + +800ms/16s intervals: Another bias +================================= + +Further double the intervals (800 milliseconds and 16 seconds for sampling +and aggregation intervals, respectively). The results is more improved for the +hot regions detection, but starts looking degrading cold regions detection. :: + + # damo start -s 800ms -a 16s + # sleep 600 + # damo record --snapshot 0 1 + # damo stop + # damo report access --sort_regions_by temperature + 0 addr 64.781 GiB size 1.219 GiB access 0 % age 4 m 48 s + 1 addr 24.505 GiB size 2.475 GiB access 0 % age 4 m 16 s + 2 addr 26.980 GiB size 504.273 MiB access 0 % age 4 m + 3 addr 29.443 GiB size 2.462 GiB access 0 % age 4 m + 4 addr 37.264 GiB size 5.645 GiB access 0 % age 4 m + 5 addr 31.905 GiB size 5.359 GiB access 0 % age 3 m 44 s + [...] + 20 addr 8.711 GiB size 40.000 KiB access 5 % age 2 m 40 s + 21 addr 27.473 GiB size 1.970 GiB access 5 % age 4 m + 22 addr 48.185 GiB size 4.625 GiB access 5 % age 4 m + 23 addr 47.304 GiB size 902.117 MiB access 10 % age 4 m + 24 addr 8.711 GiB size 4.000 KiB access 100 % age 4 m + 25 addr 20.793 GiB size 3.713 GiB access 5 % age 4 m 16 s + 26 addr 8.773 GiB size 4.000 KiB access 100 % age 4 m 16 s + total size: 62.000 GiB + # damo report access --style temperature-sz-hist + <temperature> <total size> + [-28,800,000,000, -23,359,999,000) 12.294 GiB |***************** | + [-23,359,999,000, -17,919,998,000) 9.753 GiB |************* | + [-17,919,998,000, -12,479,997,000) 15.131 GiB |********************| + [-12,479,997,000, -7,039,996,000) 0 B | | + [-7,039,996,000, -1,599,995,000) 7.506 GiB |********** | + [-1,599,995,000, 3,840,006,000) 6.127 GiB |********* | + [3,840,006,000, 9,280,007,000) 0 B | | + [9,280,007,000, 14,720,008,000) 136.000 KiB |* | + [14,720,008,000, 20,160,009,000) 40.000 KiB |* | + [20,160,009,000, 25,600,010,000) 11.188 GiB |*************** | + [25,600,010,000, 31,040,011,000) 4.000 KiB |* | + total size: 62.000 GiB + +It found more non-zero access frequency regions. The number of regions is still +much higher than the ``min_nr_regions``, but it is reduced from that of the +previous setup. And apparently the distribution seems bit biased to hot +regions. + +Conclusion +========== + +With the above experimental tuning results, we can conclude the theory and the +guide makes sense to at least this workload, and could be applied to similar +cases. diff --git a/Documentation/mm/physical_memory.rst b/Documentation/mm/physical_memory.rst index 531e73b003dd..71fd4a6acf42 100644 --- a/Documentation/mm/physical_memory.rst +++ b/Documentation/mm/physical_memory.rst @@ -33,7 +33,7 @@ The entire physical address space is partitioned into one or more blocks called zones which represent ranges within memory. These ranges are usually determined by architectural constraints for accessing the physical memory. The memory range within a node that corresponds to a particular zone is -described by a ``struct zone``, typedeffed to ``zone_t``. Each zone has +described by a ``struct zone``. Each zone has one of the types described below. * ``ZONE_DMA`` and ``ZONE_DMA32`` historically represented memory suitable for diff --git a/Documentation/mm/process_addrs.rst b/Documentation/mm/process_addrs.rst index 1d416658d7f5..81417fa2ed20 100644 --- a/Documentation/mm/process_addrs.rst +++ b/Documentation/mm/process_addrs.rst @@ -531,6 +531,10 @@ are extra requirements for accessing them: new page table has been installed in the same location and filled with entries. Writers normally need to take the PTE lock and revalidate that the PMD entry still refers to the same PTE-level page table. + If the writer does not care whether it is the same PTE-level page table, it + can take the PMD lock and revalidate that the contents of pmd entry still meet + the requirements. In particular, this also happens in :c:func:`!retract_page_tables` + when handling :c:macro:`!MADV_COLLAPSE`. To access PTE-level page tables, a helper like :c:func:`!pte_offset_map_lock` or :c:func:`!pte_offset_map` can be used depending on stability requirements. diff --git a/Documentation/mm/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst index 581446d4a4eb..cc3cd46abd1b 100644 --- a/Documentation/mm/split_page_table_lock.rst +++ b/Documentation/mm/split_page_table_lock.rst @@ -4,7 +4,7 @@ Split page table lock Originally, mm->page_table_lock spinlock protected all page tables of the mm_struct. But this approach leads to poor page fault scalability of -multi-threaded applications due high contention on the lock. To improve +multi-threaded applications due to high contention on the lock. To improve scalability, split page table lock was introduced. With split page table lock we have separate per-table lock to serialize @@ -62,7 +62,7 @@ Support of split page table lock by an architecture =================================================== There's no need in special enabling of PTE split page table lock: everything -required is done by pagetable_pte_ctor() and pagetable_pte_dtor(), which +required is done by pagetable_pte_ctor() and pagetable_dtor(), which must be called on PTE table allocation / freeing. Make sure the architecture doesn't use slab allocator for page table @@ -73,7 +73,7 @@ PMD split lock only makes sense if you have more than two page table levels. PMD split lock enabling requires pagetable_pmd_ctor() call on PMD table -allocation and pagetable_pmd_dtor() on freeing. +allocation and pagetable_dtor() on freeing. Allocation usually happens in pmd_alloc_one(), freeing in pmd_free() and pmd_free_tlb(), but make sure you cover all PMD table allocation / freeing diff --git a/Documentation/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml index 4f803eaac6d8..9660ffb1ed6a 100644 --- a/Documentation/netlink/genetlink-c.yaml +++ b/Documentation/netlink/genetlink-c.yaml @@ -106,6 +106,9 @@ properties: name-prefix: description: For enum the prefix of the values, optional. type: string + enum-cnt-name: + description: Name of the render-max counter enum entry. + type: string # End genetlink-c attribute-sets: diff --git a/Documentation/netlink/genetlink-legacy.yaml b/Documentation/netlink/genetlink-legacy.yaml index 8db0e22fa72c..16380e12cabe 100644 --- a/Documentation/netlink/genetlink-legacy.yaml +++ b/Documentation/netlink/genetlink-legacy.yaml @@ -117,6 +117,9 @@ properties: name-prefix: description: For enum the prefix of the values, optional. type: string + enum-cnt-name: + description: Name of the render-max counter enum entry. + type: string # End genetlink-c # Start genetlink-legacy members: diff --git a/Documentation/netlink/netlink-raw.yaml b/Documentation/netlink/netlink-raw.yaml index 914aa1c0a273..1b0772c8e333 100644 --- a/Documentation/netlink/netlink-raw.yaml +++ b/Documentation/netlink/netlink-raw.yaml @@ -221,7 +221,7 @@ properties: type: &attr-type description: The netlink attribute type enum: [ unused, pad, flag, binary, bitfield32, - u8, u16, u32, u64, s8, s16, s32, s64, + uint, sint, u8, u16, u32, u64, s8, s16, s32, s64, string, nest, indexed-array, nest-type-value, sub-message ] doc: diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml index 93369f0eb816..655d8d10fe24 100644 --- a/Documentation/netlink/specs/ethtool.yaml +++ b/Documentation/netlink/specs/ethtool.yaml @@ -5,6 +5,7 @@ name: ethtool protocol: genetlink-legacy doc: Partial family for Ethtool Netlink. +uapi-header: linux/ethtool_netlink_generated.h definitions: - @@ -12,44 +13,100 @@ definitions: enum-name: type: enum entries: [ vxlan, geneve, vxlan-gpe ] + enum-cnt-name: __ethtool-udp-tunnel-type-cnt + render-max: true - name: stringset type: enum entries: [] + header: linux/ethtool.h # skip rendering, no actual definition - name: header-flags type: flags - entries: [ compact-bitsets, omit-reply, stats ] + name-prefix: ethtool-flag- + doc: common ethtool header flags + entries: + - + name: compact-bitsets + doc: use compact bitsets in reply + - + name: omit-reply + doc: provide optional reply for SET or ACT requests + - + name: stats + doc: request statistics, if supported by the driver - name: module-fw-flash-status type: enum - entries: [ started, in_progress, completed, error ] + doc: plug-in module firmware flashing status + header: linux/ethtool.h + entries: + - + name: started + doc: The firmware flashing process has started. + - + name: in_progress + doc: The firmware flashing process is in progress. + - + name: completed + doc: The firmware flashing process was completed successfully. + - + name: error + doc: The firmware flashing process was stopped due to an error. - name: c33-pse-ext-state - enum-name: + doc: "groups of PSE extended states functions. IEEE 802.3-2022 33.2.4.4 Variables" type: enum name-prefix: ethtool-c33-pse-ext-state- + header: linux/ethtool.h entries: - - none - - error-condition - - mr-mps-valid - - mr-pse-enable - - option-detect-ted - - option-vport-lim - - ovld-detected - - power-not-available - - short-detected + - + name: none + doc: none + - + name: error-condition + doc: Group of error_condition states + - + name: mr-mps-valid + doc: Group of mr_mps_valid states + - + name: mr-pse-enable + doc: Group of mr_pse_enable states + - + name: option-detect-ted + doc: Group of option_detect_ted states + - + name: option-vport-lim + doc: Group of option_vport_lim states + - + name: ovld-detected + doc: Group of ovld_detected states + - + name: power-not-available + doc: Group of power_not_available states + - + name: short-detected + doc: Group of short_detected states - name: phy-upstream-type enum-name: type: enum entries: [ mac, phy ] + - + name: tcp-data-split + type: enum + entries: [ unknown, disabled, enabled ] attribute-sets: - name: header + attr-cnt-name: __ethtool-a-header-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: dev-index type: u32 - @@ -65,8 +122,13 @@ attribute-sets: - name: bitset-bit + attr-cnt-name: __ethtool-a-bitset-bit-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: index type: u32 - @@ -77,16 +139,26 @@ attribute-sets: type: flag - name: bitset-bits + attr-cnt-name: __ethtool-a-bitset-bits-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: bit type: nest multi-attr: true nested-attributes: bitset-bit - name: bitset + attr-cnt-name: __ethtool-a-bitset-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: nomask type: flag - @@ -104,8 +176,13 @@ attribute-sets: type: binary - name: string + attr-cnt-name: __ethtool-a-string-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: index type: u32 - @@ -113,16 +190,30 @@ attribute-sets: type: string - name: strings + attr-cnt-name: __ethtool-a-strings-cnt attributes: - + name: unspec + type: unused + value: 0 + - + name: unspec + type: unused + value: 0 + - name: string type: nest multi-attr: true nested-attributes: string - name: stringset + attr-cnt-name: __ethtool-a-stringset-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: id type: u32 - @@ -135,16 +226,26 @@ attribute-sets: nested-attributes: strings - name: stringsets + attr-cnt-name: __ethtool-a-stringsets-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: stringset type: nest multi-attr: true nested-attributes: stringset - name: strset + attr-cnt-name: __ethtool-a-strset-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -158,8 +259,13 @@ attribute-sets: - name: privflags + attr-cnt-name: __ethtool-a-privflags-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -170,8 +276,13 @@ attribute-sets: - name: rings + attr-cnt-name: __ethtool-a-rings-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -205,6 +316,7 @@ attribute-sets: - name: tcp-data-split type: u8 + enum: tcp-data-split - name: cqe-size type: u32 @@ -220,35 +332,58 @@ attribute-sets: - name: tx-push-buf-len-max type: u32 + - + name: hds-thresh + type: u32 + - + name: hds-thresh-max + type: u32 - name: mm-stat + attr-cnt-name: __ethtool-a-mm-stat-cnt + doc: MAC Merge (802.3) attributes: - + name: unspec + type: unused + value: 0 + - name: pad type: pad - name: reassembly-errors + doc: aMACMergeFrameAssErrorCount type: u64 - name: smd-errors + doc: aMACMergeFrameSmdErrorCount type: u64 - name: reassembly-ok + doc: aMACMergeFrameAssOkCount type: u64 - name: rx-frag-count + doc: aMACMergeFragCountRx type: u64 - name: tx-frag-count + doc: aMACMergeFragCountTx type: u64 - name: hold-count + doc: aMACMergeHoldCount type: u64 - name: mm + attr-cnt-name: __ethtool-a-mm-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -285,8 +420,13 @@ attribute-sets: nested-attributes: mm-stat - name: linkinfo + attr-cnt-name: __ethtool-a-linkinfo-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -307,8 +447,13 @@ attribute-sets: type: u8 - name: linkmodes + attr-cnt-name: __ethtool-a-linkmodes-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -343,8 +488,13 @@ attribute-sets: type: u8 - name: linkstate + attr-cnt-name: __ethtool-a-linkstate-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -368,8 +518,13 @@ attribute-sets: type: u32 - name: debug + attr-cnt-name: __ethtool-a-debug-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -379,8 +534,13 @@ attribute-sets: nested-attributes: bitset - name: wol + attr-cnt-name: __ethtool-a-wol-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -393,8 +553,13 @@ attribute-sets: type: binary - name: features + attr-cnt-name: __ethtool-a-features-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -416,8 +581,13 @@ attribute-sets: nested-attributes: bitset - name: channels + attr-cnt-name: __ethtool-a-channels-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -448,8 +618,13 @@ attribute-sets: - name: irq-moderation + attr-cnt-name: __ethtool-a-irq-moderation-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: usec type: u32 - @@ -460,16 +635,26 @@ attribute-sets: type: u32 - name: profile + attr-cnt-name: __ethtool-a-profile-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: irq-moderation type: nest multi-attr: true nested-attributes: irq-moderation - name: coalesce + attr-cnt-name: __ethtool-a-coalesce-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -565,8 +750,13 @@ attribute-sets: - name: pause-stat + attr-cnt-name: __ethtool-a-pause-stat-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: pad type: pad - @@ -577,8 +767,13 @@ attribute-sets: type: u64 - name: pause + attr-cnt-name: __ethtool-a-pause-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -600,8 +795,13 @@ attribute-sets: type: u32 - name: eee + attr-cnt-name: __ethtool-a-eee-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -627,8 +827,13 @@ attribute-sets: type: u32 - name: ts-stat + attr-cnt-name: __ethtool-a-ts-stat-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: tx-pkts type: uint - @@ -637,10 +842,32 @@ attribute-sets: - name: tx-err type: uint + - + name: tx-onestep-pkts-unconfirmed + type: uint + - + name: ts-hwtstamp-provider + attr-cnt-name: __ethtool-a-ts-hwtstamp-provider-cnt + attributes: + - + name: unspec + type: unused + value: 0 + - + name: index + type: u32 + - + name: qualifier + type: u32 - name: tsinfo + attr-cnt-name: __ethtool-a-tsinfo-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -663,22 +890,39 @@ attribute-sets: name: stats type: nest nested-attributes: ts-stat + - + name: hwtstamp-provider + type: nest + nested-attributes: ts-hwtstamp-provider - name: cable-result + attr-cnt-name: __ethtool-a-cable-result-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: pair + doc: ETHTOOL_A_CABLE_PAIR type: u8 - name: code + doc: ETHTOOL_A_CABLE_RESULT_CODE type: u8 - name: src + doc: ETHTOOL_A_CABLE_INF_SRC type: u32 - name: cable-fault-length + attr-cnt-name: __ethtool-a-cable-fault-length-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: pair type: u8 - @@ -689,8 +933,13 @@ attribute-sets: type: u32 - name: cable-nest + attr-cnt-name: __ethtool-a-cable-nest-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: result type: nest nested-attributes: cable-result @@ -700,20 +949,31 @@ attribute-sets: nested-attributes: cable-fault-length - name: cable-test + attr-cnt-name: __ethtool-a-cable-test-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header - name: cable-test-ntf + attr-cnt-name: __ethtool-a-cable-test-ntf-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header - name: status + doc: _STARTED/_COMPLETE type: u8 - name: nest @@ -721,8 +981,13 @@ attribute-sets: nested-attributes: cable-nest - name: cable-test-tdr-cfg + attr-cnt-name: __ethtool-a-cable-test-tdr-cfg-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: first type: u32 - @@ -736,8 +1001,13 @@ attribute-sets: type: u8 - name: cable-test-tdr-ntf + attr-cnt-name: __ethtool-a-cable-test-tdr-ntf-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -750,8 +1020,13 @@ attribute-sets: nested-attributes: cable-nest - name: cable-test-tdr + attr-cnt-name: __ethtool-a-cable-test-tdr-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -761,8 +1036,13 @@ attribute-sets: nested-attributes: cable-test-tdr-cfg - name: tunnel-udp-entry + attr-cnt-name: __ethtool-a-tunnel-udp-entry-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: port type: u16 byte-order: big-endian @@ -772,8 +1052,13 @@ attribute-sets: enum: udp-tunnel-type - name: tunnel-udp-table + attr-cnt-name: __ethtool-a-tunnel-udp-table-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: size type: u32 - @@ -787,15 +1072,25 @@ attribute-sets: nested-attributes: tunnel-udp-entry - name: tunnel-udp + attr-cnt-name: __ethtool-a-tunnel-udp-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: table type: nest nested-attributes: tunnel-udp-table - name: tunnel-info + attr-cnt-name: __ethtool-a-tunnel-info-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -805,8 +1100,13 @@ attribute-sets: nested-attributes: tunnel-udp - name: fec-stat + attr-cnt-name: __ethtool-a-fec-stat-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: pad type: pad - @@ -823,8 +1123,13 @@ attribute-sets: sub-type: u64 - name: fec + attr-cnt-name: __ethtool-a-fec-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -844,8 +1149,13 @@ attribute-sets: nested-attributes: fec-stat - name: module-eeprom + attr-cnt-name: __ethtool-a-module-eeprom-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -869,8 +1179,13 @@ attribute-sets: type: binary - name: stats-grp + attr-cnt-name: __ethtool-a-stats-grp-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: pad type: pad - @@ -912,8 +1227,13 @@ attribute-sets: name: hist-val - name: stats + attr-cnt-name: __ethtool-a-stats-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: pad type: pad - @@ -933,8 +1253,13 @@ attribute-sets: type: u32 - name: phc-vclocks + attr-cnt-name: __ethtool-a-phc-vclocks-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -947,8 +1272,13 @@ attribute-sets: sub-type: s32 - name: module + attr-cnt-name: __ethtool-a-module-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -960,8 +1290,14 @@ attribute-sets: type: u8 - name: c33-pse-pw-limit + attr-cnt-name: __ethtool-a-c33-pse-pw-limit-cnt + attr-max-name: __ethtool-a-c33-pse-pw-limit-max attributes: - + name: unspec + type: unused + value: 0 + - name: min type: u32 - @@ -969,8 +1305,13 @@ attribute-sets: type: u32 - name: pse + attr-cnt-name: __ethtool-a-pse-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -1027,8 +1368,13 @@ attribute-sets: nested-attributes: c33-pse-pw-limit - name: rss + attr-cnt-name: __ethtool-a-rss-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -1053,8 +1399,13 @@ attribute-sets: type: u32 - name: plca + attr-cnt-name: __ethtool-a-plca-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -1084,8 +1435,13 @@ attribute-sets: type: u32 - name: module-fw-flash + attr-cnt-name: __ethtool-a-module-fw-flash-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -1110,8 +1466,13 @@ attribute-sets: type: uint - name: phy + attr-cnt-name: __ethtool-a-phy-cnt attributes: - + name: unspec + type: unused + value: 0 + - name: header type: nest nested-attributes: header @@ -1137,6 +1498,34 @@ attribute-sets: - name: downstream-sfp-name type: string + - + name: tsconfig + attr-cnt-name: __ethtool-a-tsconfig-cnt + attributes: + - + name: unspec + type: unused + value: 0 + - + name: header + type: nest + nested-attributes: header + - + name: hwtstamp-provider + type: nest + nested-attributes: ts-hwtstamp-provider + - + name: tx-types + type: nest + nested-attributes: bitset + - + name: rx-filters + type: nest + nested-attributes: bitset + - + name: hwtstamp-flags + type: nest + nested-attributes: bitset operations: enum-model: directional @@ -1398,6 +1787,8 @@ operations: - rx-push - tx-push-buf-len - tx-push-buf-len-max + - hds-thresh + - hds-thresh-max dump: *ring-get-op - name: rings-set @@ -1578,6 +1969,7 @@ operations: request: attributes: - header + - hwtstamp-provider reply: attributes: - header @@ -1586,6 +1978,7 @@ operations: - rx-filters - phc-index - stats + - hwtstamp-provider dump: *tsinfo-get-op - name: cable-test-act @@ -1960,3 +2353,32 @@ operations: name: phy-ntf doc: Notification for change in PHY devices. notify: phy-get + - + name: tsconfig-get + doc: Get hwtstamp config. + + attribute-set: tsconfig + + do: &tsconfig-get-op + request: + attributes: + - header + reply: + attributes: &tsconfig + - header + - hwtstamp-provider + - tx-types + - rx-filters + - hwtstamp-flags + dump: *tsconfig-get-op + - + name: tsconfig-set + doc: Set hwtstamp config. + + attribute-set: tsconfig + + do: + request: + attributes: *tsconfig + reply: + attributes: *tsconfig diff --git a/Documentation/netlink/specs/rt_link.yaml b/Documentation/netlink/specs/rt_link.yaml index 9ffa13b77dcf..0d492500c7e5 100644 --- a/Documentation/netlink/specs/rt_link.yaml +++ b/Documentation/netlink/specs/rt_link.yaml @@ -1826,6 +1826,48 @@ attribute-sets: name: erspan-hwid type: u16 - + name: linkinfo-vti-attrs + name-prefix: ifla-vti- + attributes: + - + name: link + type: u32 + - + name: ikey + type: u32 + - + name: okey + type: u32 + - + name: local + type: binary + display-hint: ipv4 + - + name: remote + type: binary + display-hint: ipv4 + - + name: fwmark + type: u32 + - + name: linkinfo-vti6-attrs + subset-of: linkinfo-vti-attrs + attributes: + - + name: link + - + name: ikey + - + name: okey + - + name: local + display-hint: ipv6 + - + name: remote + display-hint: ipv6 + - + name: fwmark + - name: linkinfo-geneve-attrs name-prefix: ifla-geneve- attributes: @@ -1942,6 +1984,42 @@ attribute-sets: name: fwmark type: u32 - + name: linkinfo-ip6tnl-attrs + subset-of: linkinfo-iptun-attrs + attributes: + - + name: link + - + name: local + display-hint: ipv6 + - + name: remote + display-hint: ipv6 + - + name: ttl + - + name: encap-limit + - + name: flowinfo + - + name: flags + # ip6tnl unlike ipip and sit has 32b flags + type: u32 + - + name: proto + - + name: encap-type + - + name: encap-flags + - + name: encap-sport + - + name: encap-dport + - + name: collect-metadata + - + name: fwmark + - name: linkinfo-tun-attrs name-prefix: ifla-tun- attributes: @@ -2086,6 +2164,9 @@ attribute-sets: - name: mctp-net type: u32 + - + name: phys-binding + type: u8 - name: stats-attrs name-prefix: ifla-stats- @@ -2166,6 +2247,12 @@ attribute-sets: name: peer-scrub type: u32 enum: netkit-scrub + - + name: headroom + type: u16 + - + name: tailroom + type: u16 sub-messages: - @@ -2193,6 +2280,9 @@ sub-messages: value: ipip attribute-set: linkinfo-iptun-attrs - + value: ip6tnl + attribute-set: linkinfo-ip6tnl-attrs + - value: sit attribute-set: linkinfo-iptun-attrs - @@ -2205,6 +2295,12 @@ sub-messages: value: vrf attribute-set: linkinfo-vrf-attrs - + value: vti + attribute-set: linkinfo-vti-attrs + - + value: vti6 + attribute-set: linkinfo-vti6-attrs + - value: netkit attribute-set: linkinfo-netkit-attrs - diff --git a/Documentation/netlink/specs/rt_route.yaml b/Documentation/netlink/specs/rt_route.yaml index f4368be0caed..a674103e5bc4 100644 --- a/Documentation/netlink/specs/rt_route.yaml +++ b/Documentation/netlink/specs/rt_route.yaml @@ -177,6 +177,11 @@ attribute-sets: - name: rta-nh-id type: u32 + - + name: rta-flowlabel + type: u32 + byte-order: big-endian + display-hint: hex - name: rta-metrics attributes: @@ -260,6 +265,7 @@ operations: - rta-dport - rta-mark - rta-uid + - rta-flowlabel reply: value: 24 attributes: &all-route-attrs @@ -299,6 +305,7 @@ operations: - rta-sport - rta-dport - rta-nh-id + - rta-flowlabel dump: request: value: 26 diff --git a/Documentation/netlink/specs/rt_rule.yaml b/Documentation/netlink/specs/rt_rule.yaml index 03a8eef7952e..a9debac3058a 100644 --- a/Documentation/netlink/specs/rt_rule.yaml +++ b/Documentation/netlink/specs/rt_rule.yaml @@ -172,6 +172,16 @@ attribute-sets: - name: dscp type: u8 + - + name: flowlabel + type: u32 + byte-order: big-endian + display-hint: hex + - + name: flowlabel-mask + type: u32 + byte-order: big-endian + display-hint: hex operations: enum-model: directional @@ -203,6 +213,8 @@ operations: - sport-range - dport-range - dscp + - flowlabel + - flowlabel-mask - name: newrule-ntf doc: Notify a rule creation diff --git a/Documentation/networking/batman-adv.rst b/Documentation/networking/batman-adv.rst index 8a0dcb1894b4..44b9b5cc0e24 100644 --- a/Documentation/networking/batman-adv.rst +++ b/Documentation/networking/batman-adv.rst @@ -164,5 +164,5 @@ Mailing-list: You can also contact the Authors: -* Marek Lindner <mareklindner@neomailbox.ch> +* Marek Lindner <marek.lindner@mailbox.org> * Simon Wunderlich <sw@simonwunderlich.de> diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst index 7c8d22d68682..a4c1291d2561 100644 --- a/Documentation/networking/bonding.rst +++ b/Documentation/networking/bonding.rst @@ -1963,7 +1963,7 @@ obtain its hardware address from the first slave, which might not match the hardware address of the VLAN interfaces (which was ultimately copied from an earlier slave). -There are two methods to insure that the VLAN device operates +There are two methods to ensure that the VLAN device operates with the correct hardware address if all slaves are removed from a bond interface: @@ -2078,7 +2078,7 @@ as an unsolicited ARP reply (because ARP matches replies on an interface basis), and is discarded. The MII monitor is not affected by the state of the routing table. -The solution here is simply to insure that slaves do not have +The solution here is simply to ensure that slaves do not have routes of their own, and if for some reason they must, those routes do not supersede routes of their master. This should generally be the case, but unusual configurations or errant manual or automatic static @@ -2295,7 +2295,7 @@ active-backup: the switches have an ISL and play together well. If the network configuration is such that one switch is specifically a backup switch (e.g., has lower capacity, higher cost, etc), - then the primary option can be used to insure that the + then the primary option can be used to ensure that the preferred link is always used when it is available. broadcast: @@ -2322,7 +2322,7 @@ monitor can provide a higher level of reliability in detecting end to end connectivity failures (which may be caused by the failure of any individual component to pass traffic for any reason). Additionally, the ARP monitor should be configured with multiple targets (at least -one for each switch in the network). This will insure that, +one for each switch in the network). This will ensure that, regardless of which switch is active, the ARP monitor has a suitable target to query. diff --git a/Documentation/networking/can.rst b/Documentation/networking/can.rst index 62519d38c58b..b018ce346392 100644 --- a/Documentation/networking/can.rst +++ b/Documentation/networking/can.rst @@ -699,10 +699,10 @@ RAW socket option CAN_RAW_JOIN_FILTERS The CAN_RAW socket can set multiple CAN identifier specific filters that lead to multiple filters in the af_can.c filter processing. These filters -are indenpendent from each other which leads to logical OR'ed filters when +are independent from each other which leads to logical OR'ed filters when applied (see :ref:`socketcan-rawfilter`). -This socket option joines the given CAN filters in the way that only CAN +This socket option joins the given CAN filters in the way that only CAN frames are passed to user space that matched *all* given CAN filters. The semantic for the applied filters is therefore changed to a logical AND. diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst index 4fbaa1a2d674..53d9d5829d69 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst @@ -299,6 +299,18 @@ Use ethtool to view and set link-down-on-close, as follows:: ethtool --show-priv-flags ethX ethtool --set-priv-flags ethX link-down-on-close [on|off] +Setting the mdd-auto-reset-vf Private Flag +------------------------------------------ + +When the mdd-auto-reset-vf private flag is set to "on", the problematic VF will +be automatically reset if a malformed descriptor is detected. If the flag is +set to "off", the problematic VF will be disabled. + +Use ethtool to view and set mdd-auto-reset-vf, as follows:: + + ethtool --show-priv-flags ethX + ethtool --set-priv-flags ethX mdd-auto-reset-vf [on|off] + Viewing Link Messages --------------------- Link messages will not be displayed to the console if the distribution is diff --git a/Documentation/networking/devlink/mlx5.rst b/Documentation/networking/devlink/mlx5.rst index 456985407475..41618538fc70 100644 --- a/Documentation/networking/devlink/mlx5.rst +++ b/Documentation/networking/devlink/mlx5.rst @@ -53,6 +53,9 @@ parameters. * ``smfs`` Software managed flow steering. In SMFS mode, the HW steering entities are created and manage through the driver without firmware intervention. + * ``hmfs`` Hardware managed flow steering. In HMFS mode, the driver + is configuring steering rules directly to the HW using Work Queues with + a special new type of WQE (Work Queue Element). SMFS mode is faster and provides better rule insertion rate compared to default DMFS mode. diff --git a/Documentation/networking/diagnostic/twisted_pair_layer1_diagnostics.rst b/Documentation/networking/diagnostic/twisted_pair_layer1_diagnostics.rst index c9be5cc7e113..079e17effadf 100644 --- a/Documentation/networking/diagnostic/twisted_pair_layer1_diagnostics.rst +++ b/Documentation/networking/diagnostic/twisted_pair_layer1_diagnostics.rst @@ -713,17 +713,23 @@ driver supports reporting such events. - **Monitor Error Counters**: - - While some NIC drivers and PHYs provide error counters, there is no unified - set of PHY-specific counters across all hardware. Additionally, not all - PHYs provide useful information related to errors like CRC errors, frame - drops, or link flaps. Therefore, this step is dependent on the specific - hardware and driver support. - - - **Next Steps**: Use `ethtool -S <interface>` to check if your driver - provides useful error counters. In some cases, counters may provide - information about errors like link flaps or physical layer problems (e.g., - excessive CRC errors), but results can vary significantly depending on the - PHY. + - Use `ethtool -S <interface> --all-groups` to retrieve standardized interface + statistics if the driver supports the unified interface: + + - **Command:** `ethtool -S <interface> --all-groups` + + - **Example Output (if supported)**: + + .. code-block:: bash + + phydev-RxFrames: 100391 + phydev-RxErrors: 0 + phydev-TxFrames: 9 + phydev-TxErrors: 0 + + - If the unified interface is not supported, use `ethtool -S <interface>` to + retrieve MAC and PHY counters. Note that non-standardized PHY counter names + vary by driver and must be interpreted accordingly: - **Command:** `ethtool -S <interface>` @@ -740,6 +746,17 @@ driver supports reporting such events. condition) or kernel log messages (e.g., link up/down events) to further diagnose the issue. + - **Compare Counters**: + + - Compare the egress and ingress frame counts reported by the PHY and MAC. + + - A small difference may occur due to sampling rate differences between the + MAC and PHY drivers, or if the PHY and MAC are not always fully + synchronized in their UP or DOWN states. + + - Significant discrepancies indicate potential issues in the data path + between the MAC and PHY. + When All Else Fails... ~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index b25926071ece..3770a2294509 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -237,6 +237,8 @@ Userspace to kernel: ``ETHTOOL_MSG_MM_SET`` set MAC merge layer parameters ``ETHTOOL_MSG_MODULE_FW_FLASH_ACT`` flash transceiver module firmware ``ETHTOOL_MSG_PHY_GET`` get Ethernet PHY information + ``ETHTOOL_MSG_TSCONFIG_GET`` get hw timestamping configuration + ``ETHTOOL_MSG_TSCONFIG_SET`` set hw timestamping configuration ===================================== ================================= Kernel to userspace: @@ -286,6 +288,8 @@ Kernel to userspace: ``ETHTOOL_MSG_MODULE_FW_FLASH_NTF`` transceiver module flash updates ``ETHTOOL_MSG_PHY_GET_REPLY`` Ethernet PHY information ``ETHTOOL_MSG_PHY_NTF`` Ethernet PHY information change + ``ETHTOOL_MSG_TSCONFIG_GET_REPLY`` hw timestamping configuration + ``ETHTOOL_MSG_TSCONFIG_SET_REPLY`` new hw timestamping configuration ======================================== ================================= ``GET`` requests are sent by userspace applications to retrieve device @@ -895,6 +899,10 @@ Kernel response contents: ``ETHTOOL_A_RINGS_RX_PUSH`` u8 flag of RX Push mode ``ETHTOOL_A_RINGS_TX_PUSH_BUF_LEN`` u32 size of TX push buffer ``ETHTOOL_A_RINGS_TX_PUSH_BUF_LEN_MAX`` u32 max size of TX push buffer + ``ETHTOOL_A_RINGS_HDS_THRESH`` u32 threshold of + header / data split + ``ETHTOOL_A_RINGS_HDS_THRESH_MAX`` u32 max threshold of + header / data split ======================================= ====== =========================== ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` indicates whether the device is usable with @@ -937,10 +945,12 @@ Request contents: ``ETHTOOL_A_RINGS_RX_JUMBO`` u32 size of RX jumbo ring ``ETHTOOL_A_RINGS_TX`` u32 size of TX ring ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring + ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` u8 TCP header / data split ``ETHTOOL_A_RINGS_CQE_SIZE`` u32 Size of TX/RX CQE ``ETHTOOL_A_RINGS_TX_PUSH`` u8 flag of TX Push mode ``ETHTOOL_A_RINGS_RX_PUSH`` u8 flag of RX Push mode ``ETHTOOL_A_RINGS_TX_PUSH_BUF_LEN`` u32 size of TX push buffer + ``ETHTOOL_A_RINGS_HDS_THRESH`` u32 threshold of header / data split ==================================== ====== =========================== Kernel checks that requested ring sizes do not exceed limits reported by @@ -957,6 +967,10 @@ A bigger CQE can have more receive buffer pointers, and in turn the NIC can transfer a bigger frame from wire. Based on the NIC hardware, the overall completion queue size can be adjusted in the driver if CQE size is modified. +``ETHTOOL_A_RINGS_HDS_THRESH`` specifies the threshold value of +header / data split feature. If a received packet size is larger than this +threshold value, header and data will be split. + CHANNELS_GET ============ @@ -1245,9 +1259,10 @@ Gets timestamping information like ``ETHTOOL_GET_TS_INFO`` ioctl request. Request contents: - ===================================== ====== ========================== - ``ETHTOOL_A_TSINFO_HEADER`` nested request header - ===================================== ====== ========================== + ======================================== ====== ============================ + ``ETHTOOL_A_TSINFO_HEADER`` nested request header + ``ETHTOOL_A_TSINFO_HWTSTAMP_PROVIDER`` nested PTP hw clock provider + ======================================== ====== ============================ Kernel response contents: @@ -1266,11 +1281,17 @@ would be empty (no bit set). Additional hardware timestamping statistics response contents: - ===================================== ====== =================================== - ``ETHTOOL_A_TS_STAT_TX_PKTS`` uint Packets with Tx HW timestamps - ``ETHTOOL_A_TS_STAT_TX_LOST`` uint Tx HW timestamp not arrived count - ``ETHTOOL_A_TS_STAT_TX_ERR`` uint HW error request Tx timestamp count - ===================================== ====== =================================== + ================================================== ====== ===================== + ``ETHTOOL_A_TS_STAT_TX_PKTS`` uint Packets with Tx + HW timestamps + ``ETHTOOL_A_TS_STAT_TX_LOST`` uint Tx HW timestamp + not arrived count + ``ETHTOOL_A_TS_STAT_TX_ERR`` uint HW error request + Tx timestamp count + ``ETHTOOL_A_TS_STAT_TX_ONESTEP_PKTS_UNCONFIRMED`` uint Packets with one-step + HW TX timestamps with + unconfirmed delivery + ================================================== ====== ===================== CABLE_TEST ========== @@ -1611,6 +1632,7 @@ the ``ETHTOOL_A_STATS_GROUPS`` bitset. Currently defined values are: ETHTOOL_STATS_ETH_PHY eth-phy Basic IEEE 802.3 PHY statistics (30.3.2.1.*) ETHTOOL_STATS_ETH_CTRL eth-ctrl Basic IEEE 802.3 MAC Ctrl statistics (30.3.3.*) ETHTOOL_STATS_RMON rmon RMON (RFC 2819) statistics + ETHTOOL_STATS_PHY phy Additional PHY statistics, not defined by IEEE ====================== ======== =============================================== Each group should have a corresponding ``ETHTOOL_A_STATS_GRP`` in the reply. @@ -2243,6 +2265,75 @@ Kernel response contents: When ``ETHTOOL_A_PHY_UPSTREAM_TYPE`` is PHY_UPSTREAM_PHY, the PHY's parent is another PHY. +TSCONFIG_GET +============ + +Retrieves the information about the current hardware timestamping source and +configuration. + +It is similar to the deprecated ``SIOCGHWTSTAMP`` ioctl request. + +Request contents: + + ==================================== ====== ========================== + ``ETHTOOL_A_TSCONFIG_HEADER`` nested request header + ==================================== ====== ========================== + +Kernel response contents: + + ======================================== ====== ============================ + ``ETHTOOL_A_TSCONFIG_HEADER`` nested request header + ``ETHTOOL_A_TSCONFIG_HWTSTAMP_PROVIDER`` nested PTP hw clock provider + ``ETHTOOL_A_TSCONFIG_TX_TYPES`` bitset hwtstamp Tx type + ``ETHTOOL_A_TSCONFIG_RX_FILTERS`` bitset hwtstamp Rx filter + ``ETHTOOL_A_TSCONFIG_HWTSTAMP_FLAGS`` u32 hwtstamp flags + ======================================== ====== ============================ + +When set the ``ETHTOOL_A_TSCONFIG_HWTSTAMP_PROVIDER`` attribute identifies the +source of the hw timestamping provider. It is composed by +``ETHTOOL_A_TS_HWTSTAMP_PROVIDER_INDEX`` attribute which describe the index of +the PTP device and ``ETHTOOL_A_TS_HWTSTAMP_PROVIDER_QUALIFIER`` which describe +the qualifier of the timestamp. + +When set the ``ETHTOOL_A_TSCONFIG_TX_TYPES``, ``ETHTOOL_A_TSCONFIG_RX_FILTERS`` +and the ``ETHTOOL_A_TSCONFIG_HWTSTAMP_FLAGS`` attributes identify the Tx +type, the Rx filter and the flags configured for the current hw timestamping +provider. The attributes are propagated to the driver through the following +structure: + +.. kernel-doc:: include/linux/net_tstamp.h + :identifiers: kernel_hwtstamp_config + +TSCONFIG_SET +============ + +Set the information about the current hardware timestamping source and +configuration. + +It is similar to the deprecated ``SIOCSHWTSTAMP`` ioctl request. + +Request contents: + + ======================================== ====== ============================ + ``ETHTOOL_A_TSCONFIG_HEADER`` nested request header + ``ETHTOOL_A_TSCONFIG_HWTSTAMP_PROVIDER`` nested PTP hw clock provider + ``ETHTOOL_A_TSCONFIG_TX_TYPES`` bitset hwtstamp Tx type + ``ETHTOOL_A_TSCONFIG_RX_FILTERS`` bitset hwtstamp Rx filter + ``ETHTOOL_A_TSCONFIG_HWTSTAMP_FLAGS`` u32 hwtstamp flags + ======================================== ====== ============================ + +Kernel response contents: + + ======================================== ====== ============================ + ``ETHTOOL_A_TSCONFIG_HEADER`` nested request header + ``ETHTOOL_A_TSCONFIG_HWTSTAMP_PROVIDER`` nested PTP hw clock provider + ``ETHTOOL_A_TSCONFIG_TX_TYPES`` bitset hwtstamp Tx type + ``ETHTOOL_A_TSCONFIG_RX_FILTERS`` bitset hwtstamp Rx filter + ``ETHTOOL_A_TSCONFIG_HWTSTAMP_FLAGS`` u32 hwtstamp flags + ======================================== ====== ============================ + +For a description of each attribute, see ``TSCONFIG_GET``. + Request translation =================== @@ -2351,4 +2442,6 @@ are netlink only. n/a ``ETHTOOL_MSG_MM_SET`` n/a ``ETHTOOL_MSG_MODULE_FW_FLASH_ACT`` n/a ``ETHTOOL_MSG_PHY_GET`` + ``SIOCGHWTSTAMP`` ``ETHTOOL_MSG_TSCONFIG_GET`` + ``SIOCSHWTSTAMP`` ``ETHTOOL_MSG_TSCONFIG_SET`` =================================== ===================================== diff --git a/Documentation/networking/ieee802154.rst b/Documentation/networking/ieee802154.rst index c652d383fe10..743c0a80e309 100644 --- a/Documentation/networking/ieee802154.rst +++ b/Documentation/networking/ieee802154.rst @@ -72,7 +72,8 @@ exports a management (e.g. MLME) and data API. possibly with some kinds of acceleration like automatic CRC computation and comparison, automagic ACK handling, address matching, etc. -Those types of devices require different approach to be hooked into Linux kernel. +Each type of device requires a different approach to be hooked into the Linux +kernel. HardMAC ------- @@ -81,10 +82,10 @@ See the header include/net/ieee802154_netdev.h. You have to implement Linux net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family code via plain sk_buffs. On skb reception skb->cb must contain additional info as described in the struct ieee802154_mac_cb. During packet transmission -the skb->cb is used to provide additional data to device's header_ops->create -function. Be aware that this data can be overridden later (when socket code -submits skb to qdisc), so if you need something from that cb later, you should -store info in the skb->data on your own. +the skb->cb is used to provide additional data to the device's +header_ops->create function. Be aware that this data can be overridden later +(when socket code submits skb to qdisc), so if you need something from that cb +later, you should store info in the skb->data on your own. To hook the MLME interface you have to populate the ml_priv field of your net_device with a pointer to struct ieee802154_mlme_ops instance. The fields @@ -94,8 +95,9 @@ All other fields are required. SoftMAC ------- -The MAC is the middle layer in the IEEE 802.15.4 Linux stack. This moment it -provides interface for drivers registration and management of slave interfaces. +The MAC is the middle layer in the IEEE 802.15.4 Linux stack. At the moment, it +provides an interface for driver registration and management of slave +interfaces. NOTE: Currently the only monitor device type is supported - it's IEEE 802.15.4 stack interface for network sniffers (e.g. WireShark). diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 46c178e564b3..058193ed2eeb 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -86,6 +86,7 @@ Contents: netdevices netfilter-sysctl netif-msg + netmem nexthop-group-resilient nf_conntrack-sysctl nf_flowtable diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index dcbb6f6caf6d..363b4950d542 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -1000,6 +1000,20 @@ tcp_tw_reuse - INTEGER Default: 2 +tcp_tw_reuse_delay - UNSIGNED INTEGER + The delay in milliseconds before a TIME-WAIT socket can be reused by a + new connection, if TIME-WAIT socket reuse is enabled. The actual reuse + threshold is within [N, N+1] range, where N is the requested delay in + milliseconds, to ensure the delay interval is never shorter than the + configured value. + + This setting contains an assumption about the other TCP timestamp clock + tick interval. It should not be set to a value lower than the peer's + clock tick for PAWS (Protection Against Wrapped Sequence numbers) + mechanism work correctly for the reused connection. + + Default: 1000 (milliseconds) + tcp_window_scaling - BOOLEAN Enable window scaling as defined in RFC1323. diff --git a/Documentation/networking/iso15765-2.rst b/Documentation/networking/iso15765-2.rst index 0e9d96074178..37ebb2c417cb 100644 --- a/Documentation/networking/iso15765-2.rst +++ b/Documentation/networking/iso15765-2.rst @@ -369,8 +369,8 @@ to their default. addr.can_family = AF_CAN; addr.can_ifindex = if_nametoindex("can0"); - addr.tp.tx_id = 0x18DA42F1 | CAN_EFF_FLAG; - addr.tp.rx_id = 0x18DAF142 | CAN_EFF_FLAG; + addr.can_addr.tp.tx_id = 0x18DA42F1 | CAN_EFF_FLAG; + addr.can_addr.tp.rx_id = 0x18DAF142 | CAN_EFF_FLAG; ret = bind(s, (struct sockaddr *)&addr, sizeof(addr)); if (ret < 0) diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index 95598c21fc8e..03e1d3610333 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -41,7 +41,7 @@ blackhole_timeout - INTEGER (seconds) MPTCP is re-enabled and will reset to the initial value when the blackhole issue goes away. - 0 to disable the blackhole detection. + 0 to disable the blackhole detection. This is a per-namespace sysctl. Default: 3600 @@ -108,3 +108,19 @@ stale_loss_cnt - INTEGER This is a per-namespace sysctl. Default: 4 + +syn_retrans_before_tcp_fallback - INTEGER + The number of SYN + MP_CAPABLE retransmissions before falling back to + TCP, i.e. dropping the MPTCP options. In other words, if all the packets + are dropped on the way, there will be: + + * The initial SYN with MPTCP support + * This number of SYN retransmitted with MPTCP support + * The next SYN retransmissions will be without MPTCP support + + 0 means the first retransmission will be done without MPTCP options. + >= 128 means that all SYN retransmissions will keep the MPTCP options. A + lower number might increase false-positive MPTCP blackholes detections. + This is a per-namespace sysctl. + + Default: 2 diff --git a/Documentation/networking/multi-pf-netdev.rst b/Documentation/networking/multi-pf-netdev.rst index 2cd25d81aaa7..2f5a5bb3ca9a 100644 --- a/Documentation/networking/multi-pf-netdev.rst +++ b/Documentation/networking/multi-pf-netdev.rst @@ -89,7 +89,7 @@ Observability ============= The relation between PF, irq, napi, and queue can be observed via netlink spec:: - $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/netdev.yaml --dump queue-get --json='{"ifindex": 13}' + $ ./tools/net/ynl/pyynl/cli.py --spec Documentation/netlink/specs/netdev.yaml --dump queue-get --json='{"ifindex": 13}' [{'id': 0, 'ifindex': 13, 'napi-id': 539, 'type': 'rx'}, {'id': 1, 'ifindex': 13, 'napi-id': 540, 'type': 'rx'}, {'id': 2, 'ifindex': 13, 'napi-id': 541, 'type': 'rx'}, @@ -101,7 +101,7 @@ The relation between PF, irq, napi, and queue can be observed via netlink spec:: {'id': 3, 'ifindex': 13, 'napi-id': 542, 'type': 'tx'}, {'id': 4, 'ifindex': 13, 'napi-id': 543, 'type': 'tx'}] - $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/netdev.yaml --dump napi-get --json='{"ifindex": 13}' + $ ./tools/net/ynl/pyynl/cli.py --spec Documentation/netlink/specs/netdev.yaml --dump napi-get --json='{"ifindex": 13}' [{'id': 543, 'ifindex': 13, 'irq': 42}, {'id': 542, 'ifindex': 13, 'irq': 41}, {'id': 541, 'ifindex': 13, 'irq': 40}, diff --git a/Documentation/networking/napi.rst b/Documentation/networking/napi.rst index 02720dd71a76..f970a2be271a 100644 --- a/Documentation/networking/napi.rst +++ b/Documentation/networking/napi.rst @@ -199,13 +199,13 @@ parameters mentioned above use hyphens instead of underscores: Per-NAPI configuration can be done programmatically in a user application or by using a script included in the kernel source tree: -``tools/net/ynl/cli.py``. +``tools/net/ynl/pyynl/cli.py``. For example, using the script: .. code-block:: bash - $ kernel-source/tools/net/ynl/cli.py \ + $ kernel-source/tools/net/ynl/pyynl/cli.py \ --spec Documentation/netlink/specs/netdev.yaml \ --do napi-set \ --json='{"id": 345, @@ -362,7 +362,7 @@ It is expected that ``irq-suspend-timeout`` will be set to a value much larger than ``gro_flush_timeout`` as ``irq-suspend-timeout`` should suspend IRQs for the duration of one userland processing cycle. -While it is not stricly necessary to use ``napi_defer_hard_irqs`` and +While it is not strictly necessary to use ``napi_defer_hard_irqs`` and ``gro_flush_timeout`` to use IRQ suspension, their use is strongly recommended. diff --git a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst index 629da6dc6d74..de0263302f16 100644 --- a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst +++ b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst @@ -79,6 +79,7 @@ u8 sysctl_tcp_retries1 u8 sysctl_tcp_retries2 u8 sysctl_tcp_orphan_retries u8 sysctl_tcp_tw_reuse timewait_sock_ops +unsigned_int sysctl_tcp_tw_reuse_delay timewait_sock_ops int sysctl_tcp_fin_timeout TCP_LAST_ACK/tcp_rcv_state_process unsigned_int sysctl_tcp_notsent_lowat read_mostly tcp_notsent_lowat/tcp_stream_memory_free u8 sysctl_tcp_sack tcp_syn_options diff --git a/Documentation/networking/netconsole.rst b/Documentation/networking/netconsole.rst index d55c2a22ec7a..94c4680fdf3e 100644 --- a/Documentation/networking/netconsole.rst +++ b/Documentation/networking/netconsole.rst @@ -124,7 +124,7 @@ To remove a target:: The interface exposes these parameters of a netconsole target to userspace: - ============== ================================= ============ + =============== ================================= ============ enabled Is this target currently enabled? (read-write) extended Extended mode enabled (read-write) release Prepend kernel release to message (read-write) @@ -135,7 +135,8 @@ The interface exposes these parameters of a netconsole target to userspace: remote_ip Remote agent's IP address (read-write) local_mac Local interface's MAC address (read-only) remote_mac Remote agent's MAC address (read-write) - ============== ================================= ============ + transmit_errors Number of packet send errors (read-only) + =============== ================================= ============ The "enabled" attribute is also used to control whether the parameters of a target can be updated or not -- you can modify the parameters of only diff --git a/Documentation/networking/netdevices.rst b/Documentation/networking/netdevices.rst index 857c9784f87e..1d37038e9fbe 100644 --- a/Documentation/networking/netdevices.rst +++ b/Documentation/networking/netdevices.rst @@ -297,3 +297,13 @@ napi->poll: Context: softirq will be called with interrupts disabled by netconsole. + +NETDEV_INTERNAL symbol namespace +================================ + +Symbols exported as NETDEV_INTERNAL can only be used in networking +core and drivers which exclusively flow via the main networking list and trees. +Note that the inverse is not true, most symbols outside of NETDEV_INTERNAL +are not expected to be used by random code outside netdev either. +Symbols may lack the designation because they predate the namespaces, +or simply due to an oversight. diff --git a/Documentation/networking/netlink_spec/readme.txt b/Documentation/networking/netlink_spec/readme.txt index 6763f99d216c..030b44aca4e6 100644 --- a/Documentation/networking/netlink_spec/readme.txt +++ b/Documentation/networking/netlink_spec/readme.txt @@ -1,4 +1,4 @@ SPDX-License-Identifier: GPL-2.0 This file is populated during the build of the documentation (htmldocs) by the -tools/net/ynl/ynl-gen-rst.py script. +tools/net/ynl/pyynl/ynl_gen_rst.py script. diff --git a/Documentation/networking/netmem.rst b/Documentation/networking/netmem.rst new file mode 100644 index 000000000000..7de21ddb5412 --- /dev/null +++ b/Documentation/networking/netmem.rst @@ -0,0 +1,79 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +Netmem Support for Network Drivers +================================== + +This document outlines the requirements for network drivers to support netmem, +an abstract memory type that enables features like device memory TCP. By +supporting netmem, drivers can work with various underlying memory types +with little to no modification. + +Benefits of Netmem : + +* Flexibility: Netmem can be backed by different memory types (e.g., struct + page, DMA-buf), allowing drivers to support various use cases such as device + memory TCP. +* Future-proof: Drivers with netmem support are ready for upcoming + features that rely on it. +* Simplified Development: Drivers interact with a consistent API, + regardless of the underlying memory implementation. + +Driver Requirements +=================== + +1. The driver must support page_pool. + +2. The driver must support the tcp-data-split ethtool option. + +3. The driver must use the page_pool netmem APIs for payload memory. The netmem + APIs currently 1-to-1 correspond with page APIs. Conversion to netmem should + be achievable by switching the page APIs to netmem APIs and tracking memory + via netmem_refs in the driver rather than struct page * : + + - page_pool_alloc -> page_pool_alloc_netmem + - page_pool_get_dma_addr -> page_pool_get_dma_addr_netmem + - page_pool_put_page -> page_pool_put_netmem + + Not all page APIs have netmem equivalents at the moment. If your driver + relies on a missing netmem API, feel free to add and propose to netdev@, or + reach out to the maintainers and/or almasrymina@google.com for help adding + the netmem API. + +4. The driver must use the following PP_FLAGS: + + - PP_FLAG_DMA_MAP: netmem is not dma-mappable by the driver. The driver + must delegate the dma mapping to the page_pool, which knows when + dma-mapping is (or is not) appropriate. + - PP_FLAG_DMA_SYNC_DEV: netmem dma addr is not necessarily dma-syncable + by the driver. The driver must delegate the dma syncing to the page_pool, + which knows when dma-syncing is (or is not) appropriate. + - PP_FLAG_ALLOW_UNREADABLE_NETMEM. The driver must specify this flag iff + tcp-data-split is enabled. + +5. The driver must not assume the netmem is readable and/or backed by pages. + The netmem returned by the page_pool may be unreadable, in which case + netmem_address() will return NULL. The driver must correctly handle + unreadable netmem, i.e. don't attempt to handle its contents when + netmem_address() is NULL. + + Ideally, drivers should not have to check the underlying netmem type via + helpers like netmem_is_net_iov() or convert the netmem to any of its + underlying types via netmem_to_page() or netmem_to_net_iov(). In most cases, + netmem or page_pool helpers that abstract this complexity are provided + (and more can be added). + +6. The driver must use page_pool_dma_sync_netmem_for_cpu() in lieu of + dma_sync_single_range_for_cpu(). For some memory providers, dma_syncing for + CPU will be done by the page_pool, for others (particularly dmabuf memory + provider), dma syncing for CPU is the responsibility of the userspace using + dmabuf APIs. The driver must delegate the entire dma-syncing operation to + the page_pool which will do it correctly. + +7. Avoid implementing driver-specific recycling on top of the page_pool. Drivers + cannot hold onto a struct page to do their own recycling as the netmem may + not be backed by a struct page. However, you may hold onto a page_pool + reference with page_pool_fragment_netmem() or page_pool_ref_netmem() for + that purpose, but be mindful that some netmem types might have longer + circulation times, such as when userspace holds a reference in zerocopy + scenarios. diff --git a/Documentation/networking/statistics.rst b/Documentation/networking/statistics.rst index 75e017dfa825..518284e287b0 100644 --- a/Documentation/networking/statistics.rst +++ b/Documentation/networking/statistics.rst @@ -143,7 +143,7 @@ reading multiple stats as it internally performs a full dump of and reports only the stat corresponding to the accessed file. Sysfs files are documented in -`Documentation/ABI/testing/sysfs-class-net-statistics`. +Documentation/ABI/testing/sysfs-class-net-statistics. netlink diff --git a/Documentation/networking/strparser.rst b/Documentation/networking/strparser.rst index 6cab1f74ae05..7f623d1db72a 100644 --- a/Documentation/networking/strparser.rst +++ b/Documentation/networking/strparser.rst @@ -112,7 +112,7 @@ Functions Callbacks ========= -There are six callbacks: +There are seven callbacks: :: @@ -184,6 +184,13 @@ There are six callbacks: :: + int (*read_sock)(struct strparser *strp, read_descriptor_t *desc, + sk_read_actor_t recv_actor); + + The read_sock callback is used by strparser instead of + sock->ops->read_sock, if provided. + :: + int (*read_sock_done)(struct strparser *strp, int err); read_sock_done is called when the stream parser is done reading diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index b37bfbfc7d79..61ef9da10e28 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -525,8 +525,8 @@ implicitly defined. ts[0] holds a software timestamp if set, ts[1] is again deprecated and ts[2] holds a hardware timestamp if set. -3. Hardware Timestamping configuration: SIOCSHWTSTAMP and SIOCGHWTSTAMP -======================================================================= +3. Hardware Timestamping configuration: ETHTOOL_MSG_TSCONFIG_SET/GET +==================================================================== Hardware time stamping must also be initialized for each device driver that is expected to do hardware time stamping. The parameter is defined in @@ -539,12 +539,14 @@ include/uapi/linux/net_tstamp.h as:: }; Desired behavior is passed into the kernel and to a specific device by -calling ioctl(SIOCSHWTSTAMP) with a pointer to a struct ifreq whose -ifr_data points to a struct hwtstamp_config. The tx_type and -rx_filter are hints to the driver what it is expected to do. If -the requested fine-grained filtering for incoming packets is not -supported, the driver may time stamp more than just the requested types -of packets. +calling the tsconfig netlink socket ``ETHTOOL_MSG_TSCONFIG_SET``. +The ``ETHTOOL_A_TSCONFIG_TX_TYPES``, ``ETHTOOL_A_TSCONFIG_RX_FILTERS`` and +``ETHTOOL_A_TSCONFIG_HWTSTAMP_FLAGS`` netlink attributes are then used to set +the struct hwtstamp_config accordingly. + +The ``ETHTOOL_A_TSCONFIG_HWTSTAMP_PROVIDER`` netlink nested attribute is used +to select the source of the hardware time stamping. It is composed of an index +for the device source and a qualifier for the type of time stamping. Drivers are free to use a more permissive configuration than the requested configuration. It is expected that drivers should only implement directly the @@ -563,9 +565,16 @@ Only a processes with admin rights may change the configuration. User space is responsible to ensure that multiple processes don't interfere with each other and that the settings are reset. -Any process can read the actual configuration by passing this -structure to ioctl(SIOCGHWTSTAMP) in the same way. However, this has -not been implemented in all drivers. +Any process can read the actual configuration by requesting tsconfig netlink +socket ``ETHTOOL_MSG_TSCONFIG_GET``. + +The legacy configuration is the use of the ioctl(SIOCSHWTSTAMP) with a pointer +to a struct ifreq whose ifr_data points to a struct hwtstamp_config. +The tx_type and rx_filter are hints to the driver what it is expected to do. +If the requested fine-grained filtering for incoming packets is not +supported, the driver may time stamp more than just the requested types +of packets. ioctl(SIOCGHWTSTAMP) is used in the same way as the +ioctl(SIOCSHWTSTAMP). However, this has not been implemented in all drivers. :: @@ -610,9 +619,10 @@ not been implemented in all drivers. -------------------------------------------------------- A driver which supports hardware time stamping must support the -SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with -the actual values as described in the section on SIOCSHWTSTAMP. It -should also support SIOCGHWTSTAMP. +ndo_hwtstamp_set NDO or the legacy SIOCSHWTSTAMP ioctl and update the +supplied struct hwtstamp_config with the actual values as described in +the section on SIOCSHWTSTAMP. It should also support ndo_hwtstamp_get or +the legacy SIOCGHWTSTAMP. Time stamps for received packets must be stored in the skb. To get a pointer to the shared time stamp structure of the skb call skb_hwtstamps(). Then diff --git a/Documentation/networking/tls.rst b/Documentation/networking/tls.rst index 658ed3a71e1b..c7904a1bc167 100644 --- a/Documentation/networking/tls.rst +++ b/Documentation/networking/tls.rst @@ -200,6 +200,32 @@ received without a cmsg buffer set. recv will never return data from mixed types of TLS records. +TLS 1.3 Key Updates +------------------- + +In TLS 1.3, KeyUpdate handshake messages signal that the sender is +updating its TX key. Any message sent after a KeyUpdate will be +encrypted using the new key. The userspace library can pass the new +key to the kernel using the TLS_TX and TLS_RX socket options, as for +the initial keys. TLS version and cipher cannot be changed. + +To prevent attempting to decrypt incoming records using the wrong key, +decryption will be paused when a KeyUpdate message is received by the +kernel, until the new key has been provided using the TLS_RX socket +option. Any read occurring after the KeyUpdate has been read and +before the new key is provided will fail with EKEYEXPIRED. poll() will +not report any read events from the socket until the new key is +provided. There is no pausing on the transmit side. + +Userspace should make sure that the crypto_info provided has been set +properly. In particular, the kernel will not check for key/nonce +reuse. + +The number of successful and failed key updates is tracked in the +``TlsTxRekeyOk``, ``TlsRxRekeyOk``, ``TlsTxRekeyError``, +``TlsRxRekeyError`` statistics. The ``TlsRxRekeyReceived`` statistic +counts KeyUpdate handshake messages that have been received. + Integrating in to userspace TLS library --------------------------------------- @@ -286,3 +312,13 @@ TLS implementation exposes the following per-namespace statistics - ``TlsRxNoPadViolation`` - number of data RX records which had to be re-decrypted due to ``TLS_RX_EXPECT_NO_PAD`` mis-prediction. + +- ``TlsTxRekeyOk``, ``TlsRxRekeyOk`` - + number of successful rekeys on existing sessions for TX and RX + +- ``TlsTxRekeyError``, ``TlsRxRekeyError`` - + number of failed rekeys on existing sessions for TX and RX + +- ``TlsRxRekeyReceived`` - + number of received KeyUpdate handshake messages, requiring userspace + to provide a new RX key diff --git a/Documentation/networking/xfrm_device.rst b/Documentation/networking/xfrm_device.rst index bfea9d8579ed..66f6e9a9b59a 100644 --- a/Documentation/networking/xfrm_device.rst +++ b/Documentation/networking/xfrm_device.rst @@ -169,7 +169,8 @@ the stack in xfrm_input(). hand the packet to napi_gro_receive() as usual -In ESN mode, xdo_dev_state_advance_esn() is called from xfrm_replay_advance_esn(). +In ESN mode, xdo_dev_state_advance_esn() is called from +xfrm_replay_advance_esn() for RX, and xfrm_replay_overflow_offload_esn for TX. Driver will check packet seq number and update HW ESN state machine if needed. Packet offload mode: diff --git a/Documentation/nvme/nvme-pci-endpoint-target.rst b/Documentation/nvme/nvme-pci-endpoint-target.rst index 66e7b7d869b4..b699595d1762 100644 --- a/Documentation/nvme/nvme-pci-endpoint-target.rst +++ b/Documentation/nvme/nvme-pci-endpoint-target.rst @@ -86,7 +86,7 @@ configurable through configfs before starting the controller. To avoid issues with excessive local memory usage for executing commands, MDTS defaults to 512 KB and is limited to a maximum of 2 MB (arbitrary limit). -Mimimum number of PCI Address Mapping Windows Required +Minimum number of PCI Address Mapping Windows Required ------------------------------------------------------ Most PCI endpoint controllers provide a limited number of mapping windows for diff --git a/Documentation/power/video.rst b/Documentation/power/video.rst index 337a2ba9f32f..8ab2458d1304 100644 --- a/Documentation/power/video.rst +++ b/Documentation/power/video.rst @@ -190,7 +190,7 @@ Toshiba Portege 3020CT s3_mode (3) Toshiba Satellite 4030CDT s3_mode (3) (S1 also works OK) Toshiba Satellite 4080XCDT s3_mode (3) (S1 also works OK) Toshiba Satellite 4090XCDT ??? [#f1]_ -Toshiba Satellite P10-554 s3_bios,s3_mode (4)[#f3]_ +Toshiba Satellite P10-554 s3_bios,s3_mode (4) [#f3]_ Toshiba M30 (2) xor X with nvidia driver using internal AGP Uniwill 244IIO ??? [#f1]_ =============================== =============================================== diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst index b3eff03ea249..22fa925353cf 100644 --- a/Documentation/process/5.Posting.rst +++ b/Documentation/process/5.Posting.rst @@ -261,13 +261,22 @@ The tags in common use are: can be used instead of Closes: if the patch fixes a part of the issue(s) being reported. + - A Suggested-by: tag indicates that the patch idea is suggested by the person + named and ensures credit to the person for the idea. This will, hopefully, + inspire them to help us again in the future. + - Cc: the named person received a copy of the patch and had the opportunity to comment on it. -Be careful in the addition of tags to your patches, as only Cc: is appropriate -for addition without the explicit permission of the person named; using -Reported-by: is fine most of the time as well, but ask for permission if -the bug was reported in private. +Be careful in the addition of the aforementioned tags to your patches, as all +except for Cc:, Reported-by:, and Suggested-by: need explicit permission of the +person named. For those three implicit permission is sufficient if the person +contributed to the Linux kernel using that name and email address according +to the lore archives or the commit history -- and in case of Reported-by: +and Suggested-by: did the reporting or suggestion in public. Note, +bugzilla.kernel.org is a public place in this sense, but email addresses +used there are private; so do not expose them in tags, unless the person +used them in earlier contributions. Sending the patch diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 82b5e378eebf..d564362773b5 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -58,12 +58,11 @@ mcelog 0.6 mcelog --version iptables 1.4.2 iptables -V openssl & libcrypto 1.0.0 openssl version bc 1.06.95 bc --version -Sphinx\ [#f1]_ 2.4.4 sphinx-build --version -cpio any cpio --version +Sphinx\ [#f1]_ 3.4.3 sphinx-build --version GNU tar 1.28 tar --version gtags (optional) 6.6.5 gtags --version mkimage (optional) 2017.01 mkimage --version -Python (optional) 3.5.x python3 --version +Python (optional) 3.9.x python3 --version GNU AWK (optional) 5.1.0 gawk --version ====================== =============== ======================================== @@ -536,11 +535,6 @@ mcelog - <https://www.mcelog.org/> -cpio ----- - -- <https://www.gnu.org/software/cpio/> - Networking ********** diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst index 1d1150954be3..4cdef8360698 100644 --- a/Documentation/process/code-of-conduct-interpretation.rst +++ b/Documentation/process/code-of-conduct-interpretation.rst @@ -145,13 +145,16 @@ kernel community. Any decisions regarding enforcement recommendations will be brought to the TAB for implementation of enforcement with the relevant maintainers -if needed. A decision by the Code of Conduct Committee can be overturned -by the TAB by a two-thirds vote. +if needed. Once the TAB approves one or more of the measures outlined +in the scope of the ban by two-thirds of the members voting for the +measures, the Code of Conduct Committee will enforce the TAB approved +measures. Any Code of Conduct Committee members serving on the TAB will +not vote on the measures. At quarterly intervals, the Code of Conduct Committee and TAB will provide a report summarizing the anonymised reports that the Code of Conduct committee has received and their status, as well details of any -overridden decisions including complete and identifiable voting details. +TAB approved decisions including complete and identifiable voting details. Because how we interpret and enforce the Code of Conduct will evolve over time, this document will be updated when necessary to reflect any @@ -227,9 +230,11 @@ The scope of the ban for a period of time could include: such as mailing lists and social media sites Once the TAB approves one or more of the measures outlined in the scope of -the ban by a two-thirds vote, the Code of Conduct Committee will enforce -the TAB approved measure(s) in collaboration with the community, maintainers, -sub-maintainers, and kernel.org administrators. +the ban by two-thirds of the members voting for the measures, the Code of +Conduct Committee will enforce the TAB approved measure(s) in collaboration +with the community, maintainers, sub-maintainers, and kernel.org +administrators. Any Code of Conduct Committee members serving on the TAB +will not vote on the measures. The Code of Conduct Committee is mindful of the negative impact of seeking public apology and instituting ban could have on individuals. It is also diff --git a/Documentation/process/debugging/driver_development_debugging_guide.rst b/Documentation/process/debugging/driver_development_debugging_guide.rst index aef204094205..46becda8764b 100644 --- a/Documentation/process/debugging/driver_development_debugging_guide.rst +++ b/Documentation/process/debugging/driver_development_debugging_guide.rst @@ -207,17 +207,29 @@ resources, that can cause performance disruptions or even OOM kills. device coredump --------------- -Prerequisite: ``#include <linux/devcoredump.h>`` +Prerequisite: ``CONFIG_DEV_COREDUMP`` & ``#include <linux/devcoredump.h>`` Provides the infrastructure for a driver to provide arbitrary data to userland. It is most often used in conjunction with udev or similar userland application to listen for kernel uevents, which indicate that the dump is ready. Udev has rules to copy that file somewhere for long-term storage and analysis, as by -default, the data for the dump is automatically cleaned up after 5 minutes. -That data is analyzed with driver-specific tools or GDB. +default, the data for the dump is automatically cleaned up after a default +5 minutes. That data is analyzed with driver-specific tools or GDB. + +A device coredump can be created with a vmalloc area, with read/free +methods, or as a scatter/gather list. You can find an example implementation at: `drivers/media/platform/qcom/venus/core.c -<https://elixir.bootlin.com/linux/v6.11.6/source/drivers/media/platform/qcom/venus/core.c#L30>`__ +<https://elixir.bootlin.com/linux/v6.11.6/source/drivers/media/platform/qcom/venus/core.c#L30>`__, +in the Bluetooth HCI layer, in several wireless drivers, and in several +DRM drivers. + +devcoredump interfaces +~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/linux/devcoredump.h + +.. kernel-doc:: drivers/base/devcoredump.c **Copyright** ©2024 : Collabora diff --git a/Documentation/dev-tools/gdb-kernel-debugging.rst b/Documentation/process/debugging/gdb-kernel-debugging.rst index 895285c037c7..895285c037c7 100644 --- a/Documentation/dev-tools/gdb-kernel-debugging.rst +++ b/Documentation/process/debugging/gdb-kernel-debugging.rst diff --git a/Documentation/process/debugging/index.rst b/Documentation/process/debugging/index.rst index f6e4a00dfee3..387d33d16f5e 100644 --- a/Documentation/process/debugging/index.rst +++ b/Documentation/process/debugging/index.rst @@ -11,6 +11,8 @@ general guides :maxdepth: 1 driver_development_debugging_guide + gdb-kernel-debugging + kgdb userspace_debugging_guide .. only:: subproject and html diff --git a/Documentation/dev-tools/kgdb.rst b/Documentation/process/debugging/kgdb.rst index cb626a7a000c..b29b0aac2717 100644 --- a/Documentation/dev-tools/kgdb.rst +++ b/Documentation/process/debugging/kgdb.rst @@ -255,10 +255,10 @@ scenarios. .. note:: Kgdboc does not support interrupting the target via the gdb remote - protocol. You must manually send a :kbd:`SysRq-G` unless you have a proxy + protocol. You must manually send a `SysRq-G` unless you have a proxy that splits console output to a terminal program. A console proxy has a separate TCP port for the debugger and a separate TCP port for the - "human" console. The proxy can take care of sending the :kbd:`SysRq-G` + "human" console. The proxy can take care of sending the `SysRq-G` for you. When using kgdboc with no debugger proxy, you can end up connecting the @@ -267,9 +267,9 @@ have loaded kgdboc, a message should print on the console stating it is waiting for the debugger. In this case you disconnect your terminal program and then connect the debugger in its place. If you want to interrupt the target system and forcibly enter a debug session you have -to issue a :kbd:`Sysrq` sequence and then type the letter :kbd:`g`. Then you +to issue a `Sysrq` sequence and then type the letter `g`. Then you disconnect the terminal session and connect gdb. Your options if you -don't like this are to hack gdb to send the :kbd:`SysRq-G` for you as well as +don't like this are to hack gdb to send the `SysRq-G` for you as well as on the initial connect, or to use a debugger proxy that allows an unmodified gdb to do the debugging. @@ -401,7 +401,7 @@ This is a quick example of how to use kdb. 2. Enter the kernel debugger manually or by waiting for an oops or fault. There are several ways you can enter the kernel debugger - manually; all involve using the :kbd:`SysRq-G`, which means you must have + manually; all involve using the `SysRq-G`, which means you must have enabled ``CONFIG_MAGIC_SYSRQ=y`` in your kernel config. - When logged in as root or with a super user session you can run:: @@ -410,16 +410,16 @@ This is a quick example of how to use kdb. - Example using minicom 2.2 - Press: :kbd:`CTRL-A` :kbd:`f` :kbd:`g` + Press: `CTRL-A` `f` `g` - When you have telneted to a terminal server that supports sending a remote break - Press: :kbd:`CTRL-]` + Press: `CTRL-]` Type in: ``send break`` - Press: :kbd:`Enter` :kbd:`g` + Press: `Enter` `g` 3. From the kdb prompt you can run the ``help`` command to see a complete list of the commands that are available. @@ -460,7 +460,7 @@ This is a quick example of how to use kdb with a keyboard. 2. Enter the kernel debugger manually or by waiting for an oops or fault. There are several ways you can enter the kernel debugger - manually; all involve using the :kbd:`SysRq-G`, which means you must have + manually; all involve using the `SysRq-G`, which means you must have enabled ``CONFIG_MAGIC_SYSRQ=y`` in your kernel config. - When logged in as root or with a super user session you can run:: @@ -469,27 +469,27 @@ This is a quick example of how to use kdb with a keyboard. - Example using a laptop keyboard: - Press and hold down: :kbd:`Alt` + Press and hold down: `Alt` - Press and hold down: :kbd:`Fn` + Press and hold down: `Fn` - Press and release the key with the label: :kbd:`SysRq` + Press and release the key with the label: `SysRq` - Release: :kbd:`Fn` + Release: `Fn` - Press and release: :kbd:`g` + Press and release: `g` - Release: :kbd:`Alt` + Release: `Alt` - Example using a PS/2 101-key keyboard - Press and hold down: :kbd:`Alt` + Press and hold down: `Alt` - Press and release the key with the label: :kbd:`SysRq` + Press and release the key with the label: `SysRq` - Press and release: :kbd:`g` + Press and release: `g` - Release: :kbd:`Alt` + Release: `Alt` 3. Now type in a kdb command such as ``help``, ``dmesg``, ``bt`` or ``go`` to continue kernel execution. @@ -531,7 +531,7 @@ Connecting with gdb to a serial port In order to connect to gdb via kgdboc, the kernel must first be stopped. There are several ways to stop the kernel which include - using kgdbwait as a boot argument, via a :kbd:`SysRq-G`, or running the + using kgdbwait as a boot argument, via a `SysRq-G`, or running the kernel until it takes an exception where it waits for the debugger to attach. @@ -541,16 +541,16 @@ Connecting with gdb to a serial port - Example using minicom 2.2 - Press: :kbd:`CTRL-A` :kbd:`f` :kbd:`g` + Press: `CTRL-A` `f` `g` - When you have telneted to a terminal server that supports sending a remote break - Press: :kbd:`CTRL-]` + Press: `CTRL-]` Type in: ``send break`` - Press: :kbd:`Enter` :kbd:`g` + Press: `Enter` `g` 3. Connect from gdb @@ -578,7 +578,7 @@ Connecting with gdb to a serial port set debug remote 1 Remember if you continue in gdb, and need to "break in" again, you need -to issue an other :kbd:`SysRq-G`. It is easy to create a simple entry point by +to issue an other `SysRq-G`. It is easy to create a simple entry point by putting a breakpoint at ``sys_sync`` and then you can run ``sync`` from a shell or script to break into the debugger. @@ -612,7 +612,7 @@ or delete because kgdb will interpret that as part of the debug stream. .. note:: - Now you must kill gdb. Typically you press :kbd:`CTRL-Z` and issue + Now you must kill gdb. Typically you press `CTRL-Z` and issue the command:: kill -9 % diff --git a/Documentation/process/email-clients.rst b/Documentation/process/email-clients.rst index e6b9173a1845..84a2450bb6ec 100644 --- a/Documentation/process/email-clients.rst +++ b/Documentation/process/email-clients.rst @@ -86,7 +86,7 @@ In the :menuselection:`Sending Preferences` section: - :menuselection:`Strip Whitespace Before Sending` must be ``disabled`` When composing the message, the cursor should be placed where the patch -should appear, and then pressing :kbd:`CTRL-R` let you specify the patch file +should appear, and then pressing `CTRL-R` let you specify the patch file to insert into the message. Claws Mail (GUI) @@ -94,7 +94,7 @@ Claws Mail (GUI) Works. Some people use this successfully for patches. -To insert a patch use :menuselection:`Message-->Insert File` (:kbd:`CTRL-I`) +To insert a patch use :menuselection:`Message-->Insert File` (`CTRL-I`) or an external editor. If the inserted patch has to be edited in the Claws composition window @@ -108,11 +108,11 @@ Evolution (GUI) Some people use this successfully for patches. When composing mail select: Preformat - from :menuselection:`Format-->Paragraph Style-->Preformatted` (:kbd:`CTRL-7`) + from :menuselection:`Format-->Paragraph Style-->Preformatted` (`CTRL-7`) or the toolbar Then use: -:menuselection:`Insert-->Text File...` (:kbd:`ALT-N x`) +:menuselection:`Insert-->Text File...` (`ALT-N x`) to insert the patch. You can also ``diff -Nru old.c new.c | xclip``, select diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst index daebce49cfdf..0e19d2f0d6bb 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -308,7 +308,7 @@ an involved disclosed party. The current ambassadors list: Google Kees Cook <keescook@chromium.org> - LLVM Nick Desaulniers <ndesaulniers@google.com> + LLVM Nick Desaulniers <nick.desaulniers+lkml@gmail.com> ============= ======================================================== If you want your organization to be added to the ambassadors list, please diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst index 3b5b5983fea8..c67ac12cf789 100644 --- a/Documentation/process/kernel-docs.rst +++ b/Documentation/process/kernel-docs.rst @@ -75,6 +75,17 @@ On-line docs Published books --------------- + * Title: **The Linux Memory Manager** + + :Author: Lorenzo Stoakes + :Publisher: No Starch Press + :Date: February 2025 + :Pages: 1300 + :ISBN: 978-1718504462 + :Notes: Memory management. Full draft available as early access for + pre-order, full release scheduled for Fall 2025. See + https://nostarch.com/linux-memory-manager for further info. + * Title: **Practical Linux System Administration: A Guide to Installation, Configuration, and Management, 1st Edition** :Author: Kenneth Hess diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index 1ae71e31591c..e497729525d5 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -470,6 +470,52 @@ in a way which would break what would normally be considered uAPI. new ``netdevsim`` features must be accompanied by selftests under ``tools/testing/selftests/``. +Supported status for drivers +---------------------------- + +.. note: The following requirements apply only to Ethernet NIC drivers. + +Netdev defines additional requirements for drivers which want to acquire +the ``Supported`` status in the MAINTAINERS file. ``Supported`` drivers must +be running all upstream driver tests and reporting the results twice a day. +Drivers which do not comply with this requirement should use the ``Maintained`` +status. There is currently no difference in how ``Supported`` and ``Maintained`` +drivers are treated upstream. + +The exact rules a driver must follow to acquire the ``Supported`` status: + +1. Must run all tests under ``drivers/net`` and ``drivers/net/hw`` targets + of Linux selftests. Running and reporting private / internal tests is + also welcome, but upstream tests are a must. + +2. The minimum run frequency is once every 12 hours. Must test the + designated branch from the selected branch feed. Note that branches + are auto-constructed and exposed to intentional malicious patch posting, + so the test systems must be isolated. + +3. Drivers supporting multiple generations of devices must test at + least one device from each generation. A testbed manifest (exact + format TBD) should describe the device models tested. + +4. The tests must run reliably, if multiple branches are skipped or tests + are failing due to execution environment problems the ``Supported`` + status will be withdrawn. + +5. Test failures due to bugs either in the driver or the test itself, + or lack of support for the feature the test is targgeting are + *not* a basis for losing the ``Supported`` status. + +netdev CI will maintain an official page of supported devices, listing their +recent test results. + +The driver maintainer may arrange for someone else to run the test, +there is no requirement for the person listed as maintainer (or their +employer) to be responsible for running the tests. Collaboration between +vendors, hosting GH CI, other repos under linux-netdev, etc. is most welcome. + +See https://github.com/linux-netdev/nipa/wiki for more information about +netdev CI. Feel free to reach out to maintainers or the list with any questions. + Reviewer guidance ----------------- diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst index e374b67b3277..41d5855700cd 100644 --- a/Documentation/process/maintainer-tip.rst +++ b/Documentation/process/maintainer-tip.rst @@ -270,7 +270,7 @@ Ordering of commit tags To have a uniform view of the commit tags, the tip maintainers use the following tag ordering scheme: - - Fixes: 12char-SHA1 ("sub/sys: Original subject line") + - Fixes: 12+char-SHA1 ("sub/sys: Original subject line") A Fixes tag should be added even for changes which do not need to be backported to stable kernels, i.e. when addressing a recently introduced diff --git a/Documentation/process/submit-checklist.rst b/Documentation/process/submit-checklist.rst index e531dd504b6c..beb7f94279fd 100644 --- a/Documentation/process/submit-checklist.rst +++ b/Documentation/process/submit-checklist.rst @@ -52,7 +52,8 @@ Provide documentation 4) All new module parameters are documented with ``MODULE_PARM_DESC()`` 5) All new userspace interfaces are documented in ``Documentation/ABI/``. - See ``Documentation/ABI/README`` for more information. + See Documentation/admin-guide/abi.rst (or ``Documentation/ABI/README``) + for more information. Patches that change userspace interfaces should be CCed to linux-api@vger.kernel.org. @@ -91,9 +92,12 @@ Build your code fix any issues. 2) Builds on multiple CPU architectures by using local cross-compile tools - or some other build farm. Note that ppc64 is a good architecture for - cross-compilation checking because it tends to use ``unsigned long`` for - 64-bit quantities. + or some other build farm. + Note that testing against architectures of different word sizes + (32- and 64-bit) and different endianness (big- and little-) is effective + in catching various portability issues due to false assumptions on + representable quantity range, data alignment, or endianness, among + others. 3) Newly-added code has been compiled with ``gcc -W`` (use ``make KCFLAGS=-W``). This will generate lots of noise, but is good diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 1518bd57adab..cede4e7b29af 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -143,10 +143,10 @@ also track such tags and take certain actions. Private bug trackers and invalid URLs are forbidden. If your patch fixes a bug in a specific commit, e.g. you found an issue using -``git bisect``, please use the 'Fixes:' tag with the first 12 characters of -the SHA-1 ID, and the one line summary. Do not split the tag across multiple -lines, tags are exempt from the "wrap at 75 columns" rule in order to simplify -parsing scripts. For example:: +``git bisect``, please use the 'Fixes:' tag with at least the first 12 +characters of the SHA-1 ID, and the one line summary. Do not split the tag +across multiple lines, tags are exempt from the "wrap at 75 columns" rule in +order to simplify parsing scripts. For example:: Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed") @@ -463,28 +463,42 @@ If a person was not directly involved in the preparation or handling of a patch but wishes to signify and record their approval of it then they can ask to have an Acked-by: line added to the patch's changelog. -Acked-by: is often used by the maintainer of the affected code when that +Acked-by: is meant to be used by those responsible for or involved with the +affected code in one way or another. Most commonly, the maintainer when that maintainer neither contributed to nor forwarded the patch. +Acked-by: may also be used by other stakeholders, such as people with domain +knowledge (e.g. the original author of the code being modified), userspace-side +reviewers for a kernel uAPI patch or key users of a feature. Optionally, in +these cases, it can be useful to add a "# Suffix" to clarify its meaning:: + + Acked-by: The Stakeholder <stakeholder@example.org> # As primary user + Acked-by: is not as formal as Signed-off-by:. It is a record that the acker has at least reviewed the patch and has indicated acceptance. Hence patch mergers will sometimes manually convert an acker's "yep, looks good to me" into an Acked-by: (but note that it is usually better to ask for an explicit ack). +Acked-by: is also less formal than Reviewed-by:. For instance, maintainers may +use it to signify that they are OK with a patch landing, but they may not have +reviewed it as thoroughly as if a Reviewed-by: was provided. Similarly, a key +user may not have carried out a technical review of the patch, yet they may be +satisfied with the general approach, the feature or the user-facing interface. + Acked-by: does not necessarily indicate acknowledgement of the entire patch. For example, if a patch affects multiple subsystems and has an Acked-by: from one subsystem maintainer then this usually indicates acknowledgement of just the part which affects that maintainer's code. Judgement should be used here. When in doubt people should refer to the original discussion in the mailing -list archives. +list archives. A "# Suffix" may also be used in this case to clarify. If a person has had the opportunity to comment on a patch, but has not provided such comments, you may optionally add a ``Cc:`` tag to the patch. -This is the only tag which might be added without an explicit action by the -person it names - but it should indicate that this person was copied on the -patch. This tag documents that potentially interested parties -have been included in the discussion. +This tag documents that potentially interested parties have been included in +the discussion. Note, this is one of only three tags you might be able to use +without explicit permission of the person named (see 'Tagging people requires +permission' below for details). Co-developed-by: states that the patch was co-created by multiple developers; it is used to give attribution to co-authors (in addition to the author @@ -530,9 +544,9 @@ hopefully inspires them to help us again in the future. The tag is intended for bugs; please do not use it to credit feature requests. The tag should be followed by a Closes: tag pointing to the report, unless the report is not available on the web. The Link: tag can be used instead of Closes: if the patch -fixes a part of the issue(s) being reported. Please note that if the bug was -reported in private, then ask for permission first before using the Reported-by -tag. +fixes a part of the issue(s) being reported. Note, the Reported-by tag is one +of only three tags you might be able to use without explicit permission of the +person named (see 'Tagging people requires permission' below for details). A Tested-by: tag indicates that the patch has been successfully tested (in some environment) by the person named. This tag informs maintainers that @@ -582,11 +596,11 @@ Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned in the patch changelog (after the '---' separator). A Suggested-by: tag indicates that the patch idea is suggested by the person -named and ensures credit to the person for the idea. Please note that this -tag should not be added without the reporter's permission, especially if the -idea was not posted in a public forum. That said, if we diligently credit our -idea reporters, they will, hopefully, be inspired to help us again in the -future. +named and ensures credit to the person for the idea: if we diligently credit +our idea reporters, they will, hopefully, be inspired to help us again in the +future. Note, this is one of only three tags you might be able to use without +explicit permission of the person named (see 'Tagging people requires +permission' below for details). A Fixes: tag indicates that the patch fixes an issue in a previous commit. It is used to make it easy to determine where a bug originated, which can help @@ -600,6 +614,25 @@ process nor the requirement to Cc: stable@vger.kernel.org on all stable patch candidates. For more information, please read Documentation/process/stable-kernel-rules.rst. +Finally, while providing tags is welcome and typically very appreciated, please +note that signers (i.e. submitters and maintainers) may use their discretion in +applying offered tags. + +.. _tagging_people: + +Tagging people requires permission +---------------------------------- + +Be careful in the addition of the aforementioned tags to your patches, as all +except for Cc:, Reported-by:, and Suggested-by: need explicit permission of the +person named. For those three implicit permission is sufficient if the person +contributed to the Linux kernel using that name and email address according +to the lore archives or the commit history -- and in case of Reported-by: +and Suggested-by: did the reporting or suggestion in public. Note, +bugzilla.kernel.org is a public place in this sense, but email addresses +used there are private; so do not expose them in tags, unless the person +used them in earlier contributions. + .. _the_canonical_patch_format: The canonical patch format @@ -610,6 +643,9 @@ that, if you have your patches stored in a ``git`` repository, proper patch formatting can be had with ``git format-patch``. The tools cannot create the necessary text, though, so read the instructions below anyway. +Subject Line +^^^^^^^^^^^^ + The canonical patch subject line is:: Subject: [PATCH 001/123] subsystem: summary phrase @@ -683,6 +719,9 @@ Here are some good example Subjects:: Subject: [PATCH v2] sub/sys: Condensed patch summary Subject: [PATCH v2 M/N] sub/sys: Condensed patch summary +From Line +^^^^^^^^^ + The ``from`` line must be the very first line in the message body, and has the form: @@ -693,6 +732,15 @@ patch in the permanent changelog. If the ``from`` line is missing, then the ``From:`` line from the email header will be used to determine the patch author in the changelog. +The author may indicate their affiliation or the sponsor of the work +by adding the name of an organization to the ``from`` and ``SoB`` lines, +e.g.: + + From: Patch Author (Company) <author@example.com> + +Explanation Body +^^^^^^^^^^^^^^^^ + The explanation body will be committed to the permanent source changelog, so should make sense to a competent reader who has long since forgotten the immediate details of the discussion that might have led to @@ -708,6 +756,31 @@ _all_ of the compile failures; just enough that it is likely that someone searching for the patch can find it. As in the ``summary phrase``, it is important to be both succinct as well as descriptive. +.. _backtraces: + +Backtraces in commit messages +""""""""""""""""""""""""""""" + +Backtraces help document the call chain leading to a problem. However, +not all backtraces are helpful. For example, early boot call chains are +unique and obvious. Copying the full dmesg output verbatim, however, +adds distracting information like timestamps, module lists, register and +stack dumps. + +Therefore, the most useful backtraces should distill the relevant +information from the dump, which makes it easier to focus on the real +issue. Here is an example of a well-trimmed backtrace:: + + unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x0000000000000064) + at rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20) + Call Trace: + mba_wrmsr + update_domains + rdtgroup_mkdir + +Commentary +^^^^^^^^^^ + The ``---`` marker line serves the essential purpose of marking for patch handling tools where the changelog message ends. @@ -746,28 +819,6 @@ patch:: See more details on the proper patch format in the following references. -.. _backtraces: - -Backtraces in commit messages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Backtraces help document the call chain leading to a problem. However, -not all backtraces are helpful. For example, early boot call chains are -unique and obvious. Copying the full dmesg output verbatim, however, -adds distracting information like timestamps, module lists, register and -stack dumps. - -Therefore, the most useful backtraces should distill the relevant -information from the dump, which makes it easier to focus on the real -issue. Here is an example of a well-trimmed backtrace:: - - unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x0000000000000064) - at rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20) - Call Trace: - mba_wrmsr - update_domains - rdtgroup_mkdir - .. _explicit_in_reply_to: Explicit In-Reply-To headers diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst index 4aa50e5fcb8c..6d2607870ba4 100644 --- a/Documentation/rust/quick-start.rst +++ b/Documentation/rust/quick-start.rst @@ -145,7 +145,7 @@ Rust standard library source **************************** The Rust standard library source is required because the build system will -cross-compile ``core`` and ``alloc``. +cross-compile ``core``. If ``rustup`` is being used, run:: diff --git a/Documentation/rust/testing.rst b/Documentation/rust/testing.rst index 568b71b415a4..180b886e0f1e 100644 --- a/Documentation/rust/testing.rst +++ b/Documentation/rust/testing.rst @@ -97,7 +97,7 @@ operator are also supported as usual, e.g.: /// ``` /// # use kernel::{spawn_work_item, workqueue}; - /// spawn_work_item!(workqueue::system(), || pr_info!("x"))?; + /// spawn_work_item!(workqueue::system(), || pr_info!("x\n"))?; /// # Ok::<(), Error>(()) /// ``` diff --git a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst index 41ed2ceafc92..e881a945c188 100644 --- a/Documentation/scheduler/sched-bwc.rst +++ b/Documentation/scheduler/sched-bwc.rst @@ -59,7 +59,7 @@ At the same time, we can say that the worst case deadline miss, will be \Sum e_i; that is, there is a bounded tardiness (under the assumption that x+e is indeed WCET). -The interferenece when using burst is valued by the possibilities for +The interference when using burst is valued by the possibilities for missing the deadline and the average WCET. Test results showed that when there many cgroups or CPU is under utilized, the interference is limited. More details are shown in: diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst index 22838ed8e13a..a727827b8dd5 100644 --- a/Documentation/scheduler/sched-deadline.rst +++ b/Documentation/scheduler/sched-deadline.rst @@ -591,12 +591,13 @@ Deadline Task Scheduling The system wide settings are configured under the /proc virtual file system. - For now the -rt knobs are used for -deadline admission control and the - -deadline runtime is accounted against the -rt runtime. We realize that this - isn't entirely desirable; however, it is better to have a small interface for - now, and be able to change it easily later. The ideal situation (see 5.) is to - run -rt tasks from a -deadline server; in which case the -rt bandwidth is a - direct subset of dl_bw. + For now the -rt knobs are used for -deadline admission control and with + CONFIG_RT_GROUP_SCHED the -deadline runtime is accounted against the (root) + -rt runtime. With !CONFIG_RT_GROUP_SCHED the knob only serves for the -dl + admission control. We realize that this isn't entirely desirable; however, it + is better to have a small interface for now, and be able to change it easily + later. The ideal situation (see 5.) is to run -rt tasks from a -deadline + server; in which case the -rt bandwidth is a direct subset of dl_bw. This means that, for a root_domain comprising M CPUs, -deadline tasks can be created while the sum of their bandwidths stays below: diff --git a/Documentation/scheduler/sched-debug.rst b/Documentation/scheduler/sched-debug.rst index 4d3d24f2a439..b5a92a39eccd 100644 --- a/Documentation/scheduler/sched-debug.rst +++ b/Documentation/scheduler/sched-debug.rst @@ -2,7 +2,7 @@ Scheduler debugfs ================= -Booting a kernel with CONFIG_SCHED_DEBUG=y will give access to +Booting a kernel with debugfs enabled will give access to scheduler specific debug files under /sys/kernel/debug/sched. Some of those files are described below. diff --git a/Documentation/scheduler/sched-design-CFS.rst b/Documentation/scheduler/sched-design-CFS.rst index 8786f219fc73..b574a2644c77 100644 --- a/Documentation/scheduler/sched-design-CFS.rst +++ b/Documentation/scheduler/sched-design-CFS.rst @@ -96,7 +96,7 @@ picked and the current task is preempted. CFS uses nanosecond granularity accounting and does not rely on any jiffies or other HZ detail. Thus the CFS scheduler has no notion of "timeslices" in the way the previous scheduler had, and has no heuristics whatsoever. There is -only one central tunable (you have to switch on CONFIG_SCHED_DEBUG): +only one central tunable: /sys/kernel/debug/sched/base_slice_ns diff --git a/Documentation/scheduler/sched-domains.rst b/Documentation/scheduler/sched-domains.rst index 5e996fe973b1..15e3a4cb304a 100644 --- a/Documentation/scheduler/sched-domains.rst +++ b/Documentation/scheduler/sched-domains.rst @@ -73,9 +73,8 @@ Architectures may override the generic domain builder and the default SD flags for a given topology level by creating a sched_domain_topology_level array and calling set_sched_topology() with this array as the parameter. -The sched-domains debugging infrastructure can be enabled by enabling -CONFIG_SCHED_DEBUG and adding 'sched_verbose' to your cmdline. If you -forgot to tweak your cmdline, you can also flip the +The sched-domains debugging infrastructure can be enabled by 'sched_verbose' +to your cmdline. If you forgot to tweak your cmdline, you can also flip the /sys/kernel/debug/sched/verbose knob. This enables an error checking parse of the sched domains which should catch most possible errors (described above). It also prints out the domain structure in a visual format. diff --git a/Documentation/scheduler/sched-ext.rst b/Documentation/scheduler/sched-ext.rst index 6cb8b676ce03..0b2654e2164b 100644 --- a/Documentation/scheduler/sched-ext.rst +++ b/Documentation/scheduler/sched-ext.rst @@ -16,12 +16,12 @@ programs - the BPF scheduler. * The system integrity is maintained no matter what the BPF scheduler does. The default scheduling behavior is restored anytime an error is detected, a runnable task stalls, or on invoking the SysRq key sequence - :kbd:`SysRq-S`. + `SysRq-S`. * When the BPF scheduler triggers an error, debug information is dumped to aid debugging. The debug dump is passed to and printed out by the scheduler binary. The debug dump can also be accessed through the - `sched_ext_dump` tracepoint. The SysRq key sequence :kbd:`SysRq-D` + `sched_ext_dump` tracepoint. The SysRq key sequence `SysRq-D` triggers a debug dump. This doesn't terminate the BPF scheduler and can only be read through the tracepoint. @@ -59,7 +59,7 @@ set in ``ops->flags``, only tasks with the ``SCHED_EXT`` policy are scheduled by sched_ext, while tasks with ``SCHED_NORMAL``, ``SCHED_BATCH`` and ``SCHED_IDLE`` policies are scheduled by CFS. -Terminating the sched_ext scheduler program, triggering :kbd:`SysRq-S`, or +Terminating the sched_ext scheduler program, triggering `SysRq-S`, or detection of any internal error including stalled runnable tasks aborts the BPF scheduler and reverts all tasks back to CFS. @@ -107,8 +107,7 @@ detailed information: nr_rejected : 0 enable_seq : 1 -If ``CONFIG_SCHED_DEBUG`` is set, whether a given task is on sched_ext can -be determined as follows: +Whether a given task is on sched_ext can be determined as follows: .. code-block:: none @@ -242,9 +241,9 @@ The following briefly shows how a waking task is scheduled and executed. task was inserted directly from ``ops.select_cpu()``). ``ops.enqueue()`` can make one of the following decisions: - * Immediately insert the task into either the global or local DSQ by - calling ``scx_bpf_dsq_insert()`` with ``SCX_DSQ_GLOBAL`` or - ``SCX_DSQ_LOCAL``, respectively. + * Immediately insert the task into either the global or a local DSQ by + calling ``scx_bpf_dsq_insert()`` with one of the following options: + ``SCX_DSQ_GLOBAL``, ``SCX_DSQ_LOCAL``, or ``SCX_DSQ_LOCAL_ON | cpu``. * Immediately insert the task into a custom DSQ by calling ``scx_bpf_dsq_insert()`` with a DSQ ID which is smaller than 2^63. @@ -294,6 +293,42 @@ dispatching, and must be dispatched to with ``scx_bpf_dsq_insert()``. See the function documentation and usage in ``tools/sched_ext/scx_simple.bpf.c`` for more information. +Task Lifecycle +-------------- + +The following pseudo-code summarizes the entire lifecycle of a task managed +by a sched_ext scheduler: + +.. code-block:: c + + ops.init_task(); /* A new task is created */ + ops.enable(); /* Enable BPF scheduling for the task */ + + while (task in SCHED_EXT) { + if (task can migrate) + ops.select_cpu(); /* Called on wakeup (optimization) */ + + ops.runnable(); /* Task becomes ready to run */ + + while (task is runnable) { + if (task is not in a DSQ) { + ops.enqueue(); /* Task can be added to a DSQ */ + + /* A CPU becomes available */ + + ops.dispatch(); /* Task is moved to a local DSQ */ + } + ops.running(); /* Task starts running on its assigned CPU */ + ops.tick(); /* Called every 1/HZ seconds */ + ops.stopping(); /* Task stops running (time slice expires or wait) */ + } + + ops.quiescent(); /* Task releases its assigned CPU (wait) */ + } + + ops.disable(); /* Disable BPF scheduling for the task */ + ops.exit_task(); /* Task is destroyed */ + Where to Look ============= diff --git a/Documentation/scheduler/sched-rt-group.rst b/Documentation/scheduler/sched-rt-group.rst index d685609ed3d7..ab464335d320 100644 --- a/Documentation/scheduler/sched-rt-group.rst +++ b/Documentation/scheduler/sched-rt-group.rst @@ -92,16 +92,19 @@ The system wide settings are configured under the /proc virtual file system: /proc/sys/kernel/sched_rt_runtime_us: A global limit on how much time real-time scheduling may use. This is always less or equal to the period_us, as it denotes the time allocated from the - period_us for the real-time tasks. Even without CONFIG_RT_GROUP_SCHED enabled, - this will limit time reserved to real-time processes. With - CONFIG_RT_GROUP_SCHED=y it signifies the total bandwidth available to all - real-time groups. + period_us for the real-time tasks. Without CONFIG_RT_GROUP_SCHED enabled, + this only serves for admission control of deadline tasks. With + CONFIG_RT_GROUP_SCHED=y it also signifies the total bandwidth available to + all real-time groups. * Time is specified in us because the interface is s32. This gives an operating range from 1us to about 35 minutes. * sched_rt_period_us takes values from 1 to INT_MAX. * sched_rt_runtime_us takes values from -1 to sched_rt_period_us. * A run time of -1 specifies runtime == period, ie. no limit. + * sched_rt_runtime_us/sched_rt_period_us > 0.05 inorder to preserve + bandwidth for fair dl_server. For accurate value check average of + runtime/period in /sys/kernel/debug/sched/fair_server/cpuX/ 2.2 Default behaviour diff --git a/Documentation/scheduler/sched-stats.rst b/Documentation/scheduler/sched-stats.rst index 7c2b16c4729d..08b6bc9a315c 100644 --- a/Documentation/scheduler/sched-stats.rst +++ b/Documentation/scheduler/sched-stats.rst @@ -2,6 +2,12 @@ Scheduler Statistics ==================== +Version 17 of schedstats removed 'lb_imbalance' field as it has no +significance anymore and instead added more relevant fields namely +'lb_imbalance_load', 'lb_imbalance_util', 'lb_imbalance_task' and +'lb_imbalance_misfit'. The domain field prints the name of the +corresponding sched domain from this version onwards. + Version 16 of schedstats changed the order of definitions within 'enum cpu_idle_type', which changed the order of [CPU_MAX_IDLE_TYPES] columns in show_schedstat(). In particular the position of CPU_IDLE @@ -9,7 +15,9 @@ and __CPU_NOT_IDLE changed places. The size of the array is unchanged. Version 15 of schedstats dropped counters for some sched_yield: yld_exp_empty, yld_act_empty and yld_both_empty. Otherwise, it is -identical to version 14. +identical to version 14. Details are available at + + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/scheduler/sched-stats.txt?id=1e1dbb259c79b Version 14 of schedstats includes support for sched_domains, which hit the mainline kernel in 2.6.20 although it is identical to the stats from version @@ -26,7 +34,14 @@ cpus on the machine, while domain0 is the most tightly focused domain, sometimes balancing only between pairs of cpus. At this time, there are no architectures which need more than three domain levels. The first field in the domain stats is a bit map indicating which cpus are affected -by that domain. +by that domain. Details are available at + + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sched-stats.txt?id=b762f3ffb797c + +The schedstat documentation is maintained version 10 onwards and is not +updated for version 11 and 12. The details for version 10 are available at + + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sched-stats.txt?id=1da177e4c3f4 These fields are counters, and only increment. Programs which make use of these will need to start with a baseline observation and then calculate @@ -71,88 +86,97 @@ Domain statistics ----------------- One of these is produced per domain for each cpu described. (Note that if CONFIG_SMP is not defined, *no* domains are utilized and these lines -will not appear in the output.) +will not appear in the output. <name> is an extension to the domain field +that prints the name of the corresponding sched domain. It can appear in +schedstat version 17 and above. -domain<N> <cpumask> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 +domain<N> <name> <cpumask> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 The first field is a bit mask indicating what cpus this domain operates over. -The next 24 are a variety of sched_balance_rq() statistics in grouped into types -of idleness (idle, busy, and newly idle): +The next 33 are a variety of sched_balance_rq() statistics in grouped into types +of idleness (busy, idle and newly idle): 1) # of times in this domain sched_balance_rq() was called when the + cpu was busy + 2) # of times in this domain sched_balance_rq() checked but found the + load did not require balancing when busy + 3) # of times in this domain sched_balance_rq() tried to move one or + more tasks and failed, when the cpu was busy + 4) Total imbalance in load when the cpu was busy + 5) Total imbalance in utilization when the cpu was busy + 6) Total imbalance in number of tasks when the cpu was busy + 7) Total imbalance due to misfit tasks when the cpu was busy + 8) # of times in this domain pull_task() was called when busy + 9) # of times in this domain pull_task() was called even though the + target task was cache-hot when busy + 10) # of times in this domain sched_balance_rq() was called but did not + find a busier queue while the cpu was busy + 11) # of times in this domain a busier queue was found while the cpu + was busy but no busier group was found + + 12) # of times in this domain sched_balance_rq() was called when the cpu was idle - 2) # of times in this domain sched_balance_rq() checked but found + 13) # of times in this domain sched_balance_rq() checked but found the load did not require balancing when the cpu was idle - 3) # of times in this domain sched_balance_rq() tried to move one or + 14) # of times in this domain sched_balance_rq() tried to move one or more tasks and failed, when the cpu was idle - 4) sum of imbalances discovered (if any) with each call to - sched_balance_rq() in this domain when the cpu was idle - 5) # of times in this domain pull_task() was called when the cpu + 15) Total imbalance in load when the cpu was idle + 16) Total imbalance in utilization when the cpu was idle + 17) Total imbalance in number of tasks when the cpu was idle + 18) Total imbalance due to misfit tasks when the cpu was idle + 19) # of times in this domain pull_task() was called when the cpu was idle - 6) # of times in this domain pull_task() was called even though + 20) # of times in this domain pull_task() was called even though the target task was cache-hot when idle - 7) # of times in this domain sched_balance_rq() was called but did + 21) # of times in this domain sched_balance_rq() was called but did not find a busier queue while the cpu was idle - 8) # of times in this domain a busier queue was found while the + 22) # of times in this domain a busier queue was found while the cpu was idle but no busier group was found - 9) # of times in this domain sched_balance_rq() was called when the - cpu was busy - 10) # of times in this domain sched_balance_rq() checked but found the - load did not require balancing when busy - 11) # of times in this domain sched_balance_rq() tried to move one or - more tasks and failed, when the cpu was busy - 12) sum of imbalances discovered (if any) with each call to - sched_balance_rq() in this domain when the cpu was busy - 13) # of times in this domain pull_task() was called when busy - 14) # of times in this domain pull_task() was called even though the - target task was cache-hot when busy - 15) # of times in this domain sched_balance_rq() was called but did not - find a busier queue while the cpu was busy - 16) # of times in this domain a busier queue was found while the cpu - was busy but no busier group was found - 17) # of times in this domain sched_balance_rq() was called when the - cpu was just becoming idle - 18) # of times in this domain sched_balance_rq() checked but found the + 23) # of times in this domain sched_balance_rq() was called when the + was just becoming idle + 24) # of times in this domain sched_balance_rq() checked but found the load did not require balancing when the cpu was just becoming idle - 19) # of times in this domain sched_balance_rq() tried to move one or more + 25) # of times in this domain sched_balance_rq() tried to move one or more tasks and failed, when the cpu was just becoming idle - 20) sum of imbalances discovered (if any) with each call to - sched_balance_rq() in this domain when the cpu was just becoming idle - 21) # of times in this domain pull_task() was called when newly idle - 22) # of times in this domain pull_task() was called even though the + 26) Total imbalance in load when the cpu was just becoming idle + 27) Total imbalance in utilization when the cpu was just becoming idle + 28) Total imbalance in number of tasks when the cpu was just becoming idle + 29) Total imbalance due to misfit tasks when the cpu was just becoming idle + 30) # of times in this domain pull_task() was called when newly idle + 31) # of times in this domain pull_task() was called even though the target task was cache-hot when just becoming idle - 23) # of times in this domain sched_balance_rq() was called but did not + 32) # of times in this domain sched_balance_rq() was called but did not find a busier queue while the cpu was just becoming idle - 24) # of times in this domain a busier queue was found while the cpu + 33) # of times in this domain a busier queue was found while the cpu was just becoming idle but no busier group was found Next three are active_load_balance() statistics: - 25) # of times active_load_balance() was called - 26) # of times active_load_balance() tried to move a task and failed - 27) # of times active_load_balance() successfully moved a task + 34) # of times active_load_balance() was called + 35) # of times active_load_balance() tried to move a task and failed + 36) # of times active_load_balance() successfully moved a task Next three are sched_balance_exec() statistics: - 28) sbe_cnt is not used - 29) sbe_balanced is not used - 30) sbe_pushed is not used + 37) sbe_cnt is not used + 38) sbe_balanced is not used + 39) sbe_pushed is not used Next three are sched_balance_fork() statistics: - 31) sbf_cnt is not used - 32) sbf_balanced is not used - 33) sbf_pushed is not used + 40) sbf_cnt is not used + 41) sbf_balanced is not used + 42) sbf_pushed is not used Next three are try_to_wake_up() statistics: - 34) # of times in this domain try_to_wake_up() awoke a task that + 43) # of times in this domain try_to_wake_up() awoke a task that last ran on a different cpu in this domain - 35) # of times in this domain try_to_wake_up() moved a task to the + 44) # of times in this domain try_to_wake_up() moved a task to the waking cpu because it was cache-cold on its own cpu anyway - 36) # of times in this domain try_to_wake_up() started passive balancing + 45) # of times in this domain try_to_wake_up() started passive balancing /proc/<pid>/schedstat --------------------- diff --git a/Documentation/scsi/scsi_eh.rst b/Documentation/scsi/scsi_eh.rst index 104d09e9af09..36cff176c5e6 100644 --- a/Documentation/scsi/scsi_eh.rst +++ b/Documentation/scsi/scsi_eh.rst @@ -54,13 +54,13 @@ invoking hostt->queuecommand() or the block layer will time it out. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For all non-EH commands, scsi_done() is the completion callback. It -just calls blk_complete_request() to delete the block layer timer and -raise SCSI_SOFTIRQ +just calls blk_mq_complete_request() to delete the block layer timer and +raise BLOCK_SOFTIRQ. -SCSI_SOFTIRQ handler scsi_softirq calls scsi_decide_disposition() to -determine what to do with the command. scsi_decide_disposition() -looks at the scmd->result value and sense data to determine what to do -with the command. +The BLOCK_SOFTIRQ indirectly calls scsi_complete(), which calls +scsi_decide_disposition() to determine what to do with the command. +scsi_decide_disposition() looks at the scmd->result value and sense +data to determine what to do with the command. - SUCCESS @@ -110,7 +110,7 @@ The timeout handler is scsi_timeout(). When a timeout occurs, this function retry which failed), when retries are exceeded, or when the EH deadline is expired. In these cases Step #3 is taken. - 3. scsi_eh_scmd_add(scmd, SCSI_EH_CANCEL_CMD) is invoked for the + 3. scsi_eh_scmd_add(scmd) is invoked for the command. See [1-4] for more information. 1.3 Asynchronous command aborts @@ -277,7 +277,6 @@ scmd->allowed. :ACTION: scsi_eh_finish_cmd() is invoked to EH-finish scmd - - scsi_setup_cmd_retry() - move from local eh_work_q to local eh_done_q :LOCKING: none @@ -317,7 +316,7 @@ scmd->allowed. ``scsi_eh_get_sense`` This action is taken for each error-completed - (!SCSI_EH_CANCEL_CMD) commands without valid sense data. Most + command without valid sense data. Most SCSI transports/LLDDs automatically acquire sense data on command failures (autosense). Autosense is recommended for performance reasons and as sense information could get out of @@ -347,30 +346,6 @@ scmd->allowed. - otherwise No action. - 3. If !list_empty(&eh_work_q), invoke scsi_eh_abort_cmds(). - - ``scsi_eh_abort_cmds`` - - This action is taken for each timed out command when - no_async_abort is enabled in the host template. - hostt->eh_abort_handler() is invoked for each scmd. The - handler returns SUCCESS if it has succeeded to make LLDD and - all related hardware forget about the scmd. - - If a timedout scmd is successfully aborted and the sdev is - either offline or ready, scsi_eh_finish_cmd() is invoked for - the scmd. Otherwise, the scmd is left in eh_work_q for - higher-severity actions. - - Note that both offline and ready status mean that the sdev is - ready to process new scmds, where processing also implies - immediate failing; thus, if a sdev is in one of the two - states, no further recovery action is needed. - - Device readiness is tested using scsi_eh_tur() which issues - TEST_UNIT_READY command. Note that the scmd must have been - aborted successfully before reusing it for TEST_UNIT_READY. - 4. If !list_empty(&eh_work_q), invoke scsi_eh_ready_devs() ``scsi_eh_ready_devs`` @@ -384,7 +359,7 @@ scmd->allowed. For each sdev which has failed scmds with valid sense data of which scsi_check_sense()'s verdict is FAILED, - START_STOP_UNIT command is issued w/ start=1. Note that + START STOP UNIT command is issued w/ start=1. Note that as we explicitly choose error-completed scmds, it is known that lower layers have forgotten about the scmd and we can reuse it for STU. @@ -478,9 +453,6 @@ except for #1 must be implemented by eh_strategy_handler(). - shost->host_failed is zero. - - Each scmd is in such a state that scsi_setup_cmd_retry() on the - scmd doesn't make any difference. - - shost->eh_cmd_q is cleared. - Each scmd->eh_entry is cleared. diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst index 2df29b92e196..3cd6dce98e74 100644 --- a/Documentation/scsi/scsi_mid_low_api.rst +++ b/Documentation/scsi/scsi_mid_low_api.rst @@ -101,7 +101,7 @@ supplied functions" below. Those functions in group b) are listed in a section entitled "Interface functions" below. Their function pointers are placed in the members of "struct scsi_host_template", an instance of which is passed to -scsi_host_alloc() [#]_. Those interface functions that the LLD does not +scsi_host_alloc(). Those interface functions that the LLD does not wish to supply should have NULL placed in the corresponding member of struct scsi_host_template. Defining an instance of struct scsi_host_template at file scope will cause NULL to be placed in function @@ -112,12 +112,9 @@ Those usages in group c) should be handled with care, especially in a that are shared with the mid level and other layers. All functions defined within an LLD and all data defined at file scope -should be static. For example the slave_alloc() function in an LLD +should be static. For example the sdev_init() function in an LLD called "xxx" could be defined as -``static int xxx_slave_alloc(struct scsi_device * sdev) { /* code */ }`` - -.. [#] the scsi_host_alloc() function is a replacement for the rather vaguely - named scsi_register() function in most situations. +``static int xxx_sdev_init(struct scsi_device * sdev) { /* code */ }`` Hotplug initialization model @@ -149,21 +146,21 @@ scsi devices of which only the first 2 respond:: scsi_add_host() ----> scsi_scan_host() -------+ | - slave_alloc() - slave_configure() --> scsi_change_queue_depth() + sdev_init() + sdev_configure() --> scsi_change_queue_depth() | - slave_alloc() - slave_configure() + sdev_init() + sdev_configure() | - slave_alloc() *** - slave_destroy() *** + sdev_init() *** + sdev_destroy() *** *** For scsi devices that the mid level tries to scan but do not - respond, a slave_alloc(), slave_destroy() pair is called. + respond, a sdev_init(), sdev_destroy() pair is called. If the LLD wants to adjust the default queue settings, it can invoke -scsi_change_queue_depth() in its slave_configure() routine. +scsi_change_queue_depth() in its sdev_configure() routine. When an HBA is being removed it could be as part of an orderly shutdown associated with the LLD module being unloaded (e.g. with the "rmmod" @@ -176,8 +173,8 @@ same:: ===----------------------=========-----------------===------ scsi_remove_host() ---------+ | - slave_destroy() - slave_destroy() + sdev_destroy() + sdev_destroy() scsi_host_put() It may be useful for a LLD to keep track of struct Scsi_Host instances @@ -202,8 +199,8 @@ An LLD can use this sequence to make the mid level aware of a SCSI device:: ===-------------------=========--------------------===------ scsi_add_device() ------+ | - slave_alloc() - slave_configure() [--> scsi_change_queue_depth()] + sdev_init() + sdev_configure() [--> scsi_change_queue_depth()] In a similar fashion, an LLD may become aware that a SCSI device has been removed (unplugged) or the connection to it has been interrupted. Some @@ -218,12 +215,12 @@ upper layers with this sequence:: ===----------------------=========-----------------===------ scsi_remove_device() -------+ | - slave_destroy() + sdev_destroy() It may be useful for an LLD to keep track of struct scsi_device instances -(a pointer is passed as the parameter to slave_alloc() and -slave_configure() callbacks). Such instances are "owned" by the mid-level. -struct scsi_device instances are freed after slave_destroy(). +(a pointer is passed as the parameter to sdev_init() and +sdev_configure() callbacks). Such instances are "owned" by the mid-level. +struct scsi_device instances are freed after sdev_destroy(). Reference Counting @@ -302,14 +299,12 @@ Summary: - scsi_host_alloc - return a new scsi_host instance whose refcount==1 - scsi_host_get - increments Scsi_Host instance's refcount - scsi_host_put - decrements Scsi_Host instance's refcount (free if 0) - - scsi_register - create and register a scsi host adapter instance. - scsi_remove_device - detach and remove a SCSI device - scsi_remove_host - detach and remove all SCSI devices owned by host - scsi_report_bus_reset - report scsi _bus_ reset observed - scsi_scan_host - scan SCSI bus - scsi_track_queue_full - track successive QUEUE_FULL events - scsi_unblock_requests - allow further commands to be queued to given host - - scsi_unregister - [calls scsi_host_put()] Details:: @@ -331,7 +326,7 @@ Details:: * bus scan when an HBA is added (i.e. scsi_scan_host()). So it * should only be called if the HBA becomes aware of a new scsi * device (lu) after scsi_scan_host() has completed. If successful - * this call can lead to slave_alloc() and slave_configure() callbacks + * this call can lead to sdev_init() and sdev_configure() callbacks * into the LLD. * * Defined in: drivers/scsi/scsi_scan.c @@ -374,8 +369,8 @@ Details:: * Might block: no * * Notes: Can be invoked any time on a SCSI device controlled by this - * LLD. [Specifically during and after slave_configure() and prior to - * slave_destroy().] Can safely be invoked from interrupt code. + * LLD. [Specifically during and after sdev_configure() and prior to + * sdev_destroy().] Can safely be invoked from interrupt code. * * Defined in: drivers/scsi/scsi.c [see source code for more notes] * @@ -475,27 +470,6 @@ Details:: /** - * scsi_register - create and register a scsi host adapter instance. - * @sht: pointer to scsi host template - * @privsize: extra bytes to allocate in hostdata array (which is the - * last member of the returned Scsi_Host instance) - * - * Returns pointer to new Scsi_Host instance or NULL on failure - * - * Might block: yes - * - * Notes: When this call returns to the LLD, the SCSI bus scan on - * this host has _not_ yet been done. - * The hostdata array (by default zero length) is a per host scratch - * area for the LLD. - * - * Defined in: drivers/scsi/hosts.c . - **/ - struct Scsi_Host * scsi_register(struct scsi_host_template * sht, - int privsize) - - - /** * scsi_remove_device - detach and remove a SCSI device * @sdev: a pointer to a scsi device instance * @@ -506,7 +480,7 @@ Details:: * Notes: If an LLD becomes aware that a scsi device (lu) has * been removed but its host is still present then it can request * the removal of that scsi device. If successful this call will - * lead to the slave_destroy() callback being invoked. sdev is an + * lead to the sdev_destroy() callback being invoked. sdev is an * invalid pointer after this call. * * Defined in: drivers/scsi/scsi_sysfs.c . @@ -524,7 +498,7 @@ Details:: * * Notes: Should only be invoked if the "hotplug initialization * model" is being used. It should be called _prior_ to - * scsi_unregister(). + * calling scsi_host_put(). * * Defined in: drivers/scsi/hosts.c . **/ @@ -601,43 +575,24 @@ Details:: void scsi_unblock_requests(struct Scsi_Host * shost) - /** - * scsi_unregister - unregister and free memory used by host instance - * @shp: pointer to scsi host instance to unregister. - * - * Returns nothing - * - * Might block: no - * - * Notes: Should not be invoked if the "hotplug initialization - * model" is being used. Called internally by exit_this_scsi_driver() - * in the "passive initialization model". Hence a LLD has no need to - * call this function directly. - * - * Defined in: drivers/scsi/hosts.c . - **/ - void scsi_unregister(struct Scsi_Host * shp) - - - Interface Functions =================== Interface functions are supplied (defined) by LLDs and their function pointers are placed in an instance of struct scsi_host_template which -is passed to scsi_host_alloc() [or scsi_register() / init_this_scsi_driver()]. +is passed to scsi_host_alloc(). Some are mandatory. Interface functions should be declared static. The -accepted convention is that driver "xyz" will declare its slave_configure() +accepted convention is that driver "xyz" will declare its sdev_configure() function as:: - static int xyz_slave_configure(struct scsi_device * sdev); + static int xyz_sdev_configure(struct scsi_device * sdev); and so forth for all interface functions listed below. -A pointer to this function should be placed in the 'slave_configure' member +A pointer to this function should be placed in the 'sdev_configure' member of a "struct scsi_host_template" instance. A pointer to such an instance -should be passed to the mid level's scsi_host_alloc() [or scsi_register() / -init_this_scsi_driver()]. +should be passed to the mid level's scsi_host_alloc(). +. The interface functions are also described in the include/scsi/scsi_host.h file immediately above their definition point in "struct scsi_host_template". @@ -657,9 +612,9 @@ Summary: - ioctl - driver can respond to ioctls - proc_info - supports /proc/scsi/{driver_name}/{host_no} - queuecommand - queue scsi command, invoke 'done' on completion - - slave_alloc - prior to any commands being sent to a new device - - slave_configure - driver fine tuning for given device after attach - - slave_destroy - given device is about to be shut down + - sdev_init - prior to any commands being sent to a new device + - sdev_configure - driver fine tuning for given device after attach + - sdev_destroy - given device is about to be shut down Details:: @@ -728,11 +683,7 @@ Details:: * * Calling context: kernel thread * - * Notes: If 'no_async_abort' is defined this callback - * will be invoked from scsi_eh thread. No other commands - * will then be queued on current host during eh. - * Otherwise it will be called whenever scsi_timeout() - * is called due to a command timeout. + * Notes: This is called only for a command that has timed out. * * Optionally defined in: LLD **/ @@ -817,10 +768,6 @@ Details:: * The SCSI_IOCTL_PROBE_HOST ioctl yields the string returned by this * function (or struct Scsi_Host::name if this function is not * available). - * In a similar manner, init_this_scsi_driver() outputs to the console - * each host's "info" (or name) for the driver it is registering. - * Also if proc_info() is not supplied, the output of this function - * is used instead. * * Optionally defined in: LLD **/ @@ -960,7 +907,7 @@ Details:: /** - * slave_alloc - prior to any commands being sent to a new device + * sdev_init - prior to any commands being sent to a new device * (i.e. just prior to scan) this call is made * @sdp: pointer to new device (about to be scanned) * @@ -975,24 +922,24 @@ Details:: * prior to its initial scan. The corresponding scsi device may not * exist but the mid level is just about to scan for it (i.e. send * and INQUIRY command plus ...). If a device is found then - * slave_configure() will be called while if a device is not found - * slave_destroy() is called. + * sdev_configure() will be called while if a device is not found + * sdev_destroy() is called. * For more details see the include/scsi/scsi_host.h file. * * Optionally defined in: LLD **/ - int slave_alloc(struct scsi_device *sdp) + int sdev_init(struct scsi_device *sdp) /** - * slave_configure - driver fine tuning for given device just after it + * sdev_configure - driver fine tuning for given device just after it * has been first scanned (i.e. it responded to an * INQUIRY) * @sdp: device that has just been attached * * Returns 0 if ok. Any other return is assumed to be an error and * the device is taken offline. [offline devices will _not_ have - * slave_destroy() called on them so clean up resources.] + * sdev_destroy() called on them so clean up resources.] * * Locks: none * @@ -1004,11 +951,11 @@ Details:: * * Optionally defined in: LLD **/ - int slave_configure(struct scsi_device *sdp) + int sdev_configure(struct scsi_device *sdp) /** - * slave_destroy - given device is about to be shut down. All + * sdev_destroy - given device is about to be shut down. All * activity has ceased on this device. * @sdp: device that is about to be shut down * @@ -1023,12 +970,12 @@ Details:: * by this driver for given device should be freed now. No further * commands will be sent for this sdp instance. [However the device * could be re-attached in the future in which case a new instance - * of struct scsi_device would be supplied by future slave_alloc() - * and slave_configure() calls.] + * of struct scsi_device would be supplied by future sdev_init() + * and sdev_configure() calls.] * * Optionally defined in: LLD **/ - void slave_destroy(struct scsi_device *sdp) + void sdev_destroy(struct scsi_device *sdp) @@ -1039,7 +986,7 @@ struct scsi_host_template There is one "struct scsi_host_template" instance per LLD [#]_. It is typically initialized as a file scope static in a driver's header file. That way members that are not explicitly initialized will be set to 0 or NULL. -Member of interest: +Members of interest: name - name of driver (may contain spaces, please limit to @@ -1055,6 +1002,13 @@ Member of interest: - primary callback that the mid level uses to inject SCSI commands into an LLD. + vendor_id + - a unique value that identifies the vendor supplying + the LLD for the Scsi_Host. Used most often in validating + vendor-specific message requests. Value consists of an + identifier type and a vendor-specific value. + See scsi_netlink.h for a description of valid formats. + The structure is defined and commented in include/scsi/scsi_host.h .. [#] In extreme situations a single driver may have several instances @@ -1095,9 +1049,6 @@ of interest: - maximum number of commands that can be queued on devices controlled by the host. Overridden by LLD calls to scsi_change_queue_depth(). - no_async_abort - - 1=>Asynchronous aborts are not supported - - 0=>Timed-out commands will be aborted asynchronously hostt - pointer to driver's struct scsi_host_template from which this struct Scsi_Host instance was spawned @@ -1106,22 +1057,10 @@ of interest: transportt - pointer to driver's struct scsi_transport_template instance (if any). FC and SPI transports currently supported. - sh_list - - a double linked list of pointers to all struct Scsi_Host - instances (currently ordered by ascending host_no) - my_devices - - a double linked list of pointers to struct scsi_device - instances that belong to this host. hostdata[0] - area reserved for LLD at end of struct Scsi_Host. Size - is set by the second argument (named 'xtr_bytes') to - scsi_host_alloc() or scsi_register(). - vendor_id - - a unique value that identifies the vendor supplying - the LLD for the Scsi_Host. Used most often in validating - vendor-specific message requests. Value consists of an - identifier type and a vendor-specific value. - See scsi_netlink.h for a description of valid formats. + is set by the second argument (named 'privsize') to + scsi_host_alloc(). The scsi_host structure is defined in include/scsi/scsi_host.h @@ -1143,30 +1082,11 @@ Members of interest: cmnd - array containing SCSI command - cmnd_len + cmd_len - length (in bytes) of SCSI command sc_data_direction - direction of data transfer in data phase. See "enum dma_data_direction" in include/linux/dma-mapping.h - request_bufflen - - number of data bytes to transfer (0 if no data phase) - use_sg - - ==0 -> no scatter gather list, hence transfer data - to/from request_buffer - - >0 -> scatter gather list (actually an array) in - request_buffer with use_sg elements - request_buffer - - either contains data buffer or scatter gather list - depending on the setting of use_sg. Scatter gather - elements are defined by 'struct scatterlist' found - in include/linux/scatterlist.h . - done - - function pointer that should be invoked by LLD when the - SCSI command is completed (successfully or otherwise). - Should only be called by an LLD if the LLD has accepted - the command (i.e. queuecommand() returned or will return - 0). The LLD may invoke 'done' prior to queuecommand() - finishing. result - should be set by LLD prior to calling 'done'. A value of 0 implies a successfully completed command (and all @@ -1189,13 +1109,13 @@ Members of interest: device - pointer to scsi_device object that this command is associated with. - resid + resid_len (access by calling scsi_set_resid() / scsi_get_resid()) - an LLD should set this unsigned integer to the requested transfer length (i.e. 'request_bufflen') less the number - of bytes that are actually transferred. 'resid' is + of bytes that are actually transferred. 'resid_len' is preset to 0 so an LLD can ignore it if it cannot detect underruns (overruns should not be reported). An LLD - should set 'resid' prior to invoking 'done'. The most + should set 'resid_len' prior to invoking 'done'. The most interesting case is data transfers from a SCSI target device (e.g. READs) that underrun. underflow @@ -1204,10 +1124,10 @@ Members of interest: figure. Not many LLDs implement this check and some that do just output an error message to the log rather than report a DID_ERROR. Better for an LLD to implement - 'resid'. + 'resid_len'. -It is recommended that a LLD set 'resid' on data transfers from a SCSI -target device (e.g. READs). It is especially important that 'resid' is set +It is recommended that a LLD set 'resid_len' on data transfers from a SCSI +target device (e.g. READs). It is especially important that 'resid_len' is set when such data transfers have sense keys of MEDIUM ERROR and HARDWARE ERROR (and possibly RECOVERED ERROR). In these cases if a LLD is in doubt how much data has been received then the safest approach is to indicate no bytes have @@ -1217,7 +1137,7 @@ a LLD might use these helpers:: scsi_set_resid(SCpnt, scsi_bufflen(SCpnt)); where 'SCpnt' is a pointer to a scsi_cmnd object. To indicate only three 512 -bytes blocks has been received 'resid' could be set like this:: +bytes blocks have been received 'resid_len' could be set like this:: scsi_set_resid(SCpnt, scsi_bufflen(SCpnt) - (3 * 512)); diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst index 04254474fa04..a45174d165eb 100644 --- a/Documentation/sound/alsa-configuration.rst +++ b/Documentation/sound/alsa-configuration.rst @@ -58,7 +58,7 @@ debug 2 = verbose debug messages); This option appears only when ``CONFIG_SND_DEBUG=y``. This option can be dynamically changed via sysfs - /sys/modules/snd/parameters/debug file. + /sys/module/snd/parameters/debug file. Module snd-pcm-oss ------------------ diff --git a/Documentation/sound/designs/midi-2.0.rst b/Documentation/sound/designs/midi-2.0.rst index 086487ca7ab1..71a343c93fe7 100644 --- a/Documentation/sound/designs/midi-2.0.rst +++ b/Documentation/sound/designs/midi-2.0.rst @@ -293,6 +293,17 @@ Rawmidi API Extensions status 0x05). When UMP core receives such a message, it updates the UMP EP info and the corresponding sequencer clients as well. +* The legacy rawmidi device number is found in the new `tied_device` + field of the rawmidi info. + On the other hand, the UMP rawmidi device number is found in + `tied_device` field of the legacy rawmidi info, too. + +* Each substream of the legacy rawmidi may be enabled / disabled + dynamically depending on the UMP FB state. + When the selected substream is inactive, it's indicated by the bit + 0x10 (`SNDRV_RAWMIDI_INFO_STREAM_INACTIVE`) in the `flags` field of + the legacy rawmidi info. + Control API Extensions ====================== @@ -377,6 +388,13 @@ Sequencer API Extensions announcement to the ALSA sequencer system port, similarly like the normal port change notification. +* There are two extended event types for notifying the UMP Endpoint and + Function Block changes via the system announcement port: + type 68 (`SNDRV_SEQ_EVENT_UMP_EP_CHANGE`) and type 69 + (`SNDRV_SEQ_EVENT_UMP_BLOCK_CHANGE`). They take the new type, + `snd_seq_ev_ump_notify` in the payload, indicating the client number + and the FB number that are changed. + MIDI2 USB Gadget Function Driver ================================ diff --git a/Documentation/sound/designs/powersave.rst b/Documentation/sound/designs/powersave.rst index 138157452eb9..ca7d1e838b4d 100644 --- a/Documentation/sound/designs/powersave.rst +++ b/Documentation/sound/designs/powersave.rst @@ -25,15 +25,15 @@ operations. The ``power_save`` option is exported as writable. This means you can adjust the value via sysfs on the fly. For example, to turn on the automatic power-save mode with 10 seconds, write to -``/sys/modules/snd_ac97_codec/parameters/power_save`` (usually as root): +``/sys/module/snd_ac97_codec/parameters/power_save`` (usually as root): :: - # echo 10 > /sys/modules/snd_ac97_codec/parameters/power_save + # echo 10 > /sys/module/snd_ac97_codec/parameters/power_save Note that you might hear click noise/pop when changing the power state. Also, it often takes certain time to wake up from the -power-down to the active state. These are often hardly to fix, so +power-down to the active state. These are often hard to fix, so don't report extra bug reports unless you have a fix patch ;-) For HD-audio interface, there is another module option, diff --git a/Documentation/sound/soc/codec-to-codec.rst b/Documentation/sound/soc/codec-to-codec.rst index 0418521b6e03..973c147d9d82 100644 --- a/Documentation/sound/soc/codec-to-codec.rst +++ b/Documentation/sound/soc/codec-to-codec.rst @@ -68,7 +68,7 @@ file: .codec_dai_name = "codec-2-dai_name", .platform_name = "samsung-i2s.0", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF - | SND_SOC_DAIFMT_CBM_CFM, + | SND_SOC_DAIFMT_CBP_CFP, .ignore_suspend = 1, .c2c_params = &dsp_codec_params, .num_c2c_params = 1, @@ -80,7 +80,7 @@ file: .codec_name = "codec-3, .codec_dai_name = "codec-3-dai_name", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF - | SND_SOC_DAIFMT_CBM_CFM, + | SND_SOC_DAIFMT_CBP_CFP, .ignore_suspend = 1, .c2c_params = &dsp_codec_params, .num_c2c_params = 1, diff --git a/Documentation/sound/soc/dpcm.rst b/Documentation/sound/soc/dpcm.rst index 02419a6f8213..7b6aeab3c207 100644 --- a/Documentation/sound/soc/dpcm.rst +++ b/Documentation/sound/soc/dpcm.rst @@ -147,14 +147,16 @@ For the example above we have to define 4 FE DAI links and 6 BE DAI links. The FE DAI links are defined as follows :- :: + SND_SOC_DAILINK_DEFS(pcm0, + DAILINK_COMP_ARRAY(COMP_CPU("System Pin")), + DAILINK_COMP_ARRAY(COMP_DUMMY()), + DAILINK_COMP_ARRAY(COMP_PLATFORM("dsp-audio"))); + static struct snd_soc_dai_link machine_dais[] = { { .name = "PCM0 System", .stream_name = "System Playback", - .cpu_dai_name = "System Pin", - .platform_name = "dsp-audio", - .codec_name = "snd-soc-dummy", - .codec_dai_name = "snd-soc-dummy-dai", + SND_SOC_DAILINK_REG(pcm0), .dynamic = 1, .trigger = {SND_SOC_DPCM_TRIGGER_POST, SND_SOC_DPCM_TRIGGER_POST}, }, @@ -174,15 +176,16 @@ dynamic and will change depending on runtime config. The BE DAIs are configured as follows :- :: + SND_SOC_DAILINK_DEFS(headset, + DAILINK_COMP_ARRAY(COMP_CPU("ssp-dai.0")), + DAILINK_COMP_ARRAY(COMP_CODEC("rt5640.0-001c", "rt5640-aif1"))); + static struct snd_soc_dai_link machine_dais[] = { .....< FE DAI links here > { .name = "Codec Headset", - .cpu_dai_name = "ssp-dai.0", - .platform_name = "snd-soc-dummy", + SND_SOC_DAILINK_REG(headset), .no_pcm = 1, - .codec_name = "rt5640.0-001c", - .codec_dai_name = "rt5640-aif1", .ignore_suspend = 1, .ignore_pmdown_time = 1, .be_hw_params_fixup = hswult_ssp0_fixup, @@ -362,7 +365,7 @@ The machine driver sets some additional parameters to the DAI link i.e. .codec_dai_name = "modem-aif1", .codec_name = "modem", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF - | SND_SOC_DAIFMT_CBM_CFM, + | SND_SOC_DAIFMT_CBP_CFP, .c2c_params = &dai_params, .num_c2c_params = 1, } diff --git a/Documentation/sound/soc/machine.rst b/Documentation/sound/soc/machine.rst index 9db132bc0070..1828f5edca3e 100644 --- a/Documentation/sound/soc/machine.rst +++ b/Documentation/sound/soc/machine.rst @@ -75,7 +75,7 @@ In the above struct, dai’s are registered using names but you can pass either dai name or device tree node but not both. Also, names used here for cpu/codec/platform dais should be globally unique. -Additionaly below example macro can be used to register cpu, codec and +Additionally below example macro can be used to register cpu, codec and platform dai:: SND_SOC_DAILINK_DEFS(wm2200_cpu_dsp, diff --git a/Documentation/sphinx/automarkup.py b/Documentation/sphinx/automarkup.py index a413f8dd5115..ecf54d22e9dc 100644 --- a/Documentation/sphinx/automarkup.py +++ b/Documentation/sphinx/automarkup.py @@ -11,13 +11,7 @@ from sphinx.errors import NoUri import re from itertools import chain -# -# Python 2 lacks re.ASCII... -# -try: - ascii_p3 = re.ASCII -except AttributeError: - ascii_p3 = 0 +from kernel_abi import get_kernel_abi # # Regex nastiness. Of course. @@ -26,28 +20,30 @@ except AttributeError: # :c:func: block (i.e. ":c:func:`mmap()`s" flakes out), so the last # bit tries to restrict matches to things that won't create trouble. # -RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=ascii_p3) +RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=re.ASCII) # # Sphinx 2 uses the same :c:type role for struct, union, enum and typedef # RE_generic_type = re.compile(r'\b(struct|union|enum|typedef)\s+([a-zA-Z_]\w+)', - flags=ascii_p3) + flags=re.ASCII) # # Sphinx 3 uses a different C role for each one of struct, union, enum and # typedef # -RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=ascii_p3) -RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=ascii_p3) -RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=ascii_p3) -RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=ascii_p3) +RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=re.ASCII) +RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=re.ASCII) +RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=re.ASCII) +RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=re.ASCII) # # Detects a reference to a documentation page of the form Documentation/... with # an optional extension # RE_doc = re.compile(r'(\bDocumentation/)?((\.\./)*[\w\-/]+)\.(rst|txt)') +RE_abi_file = re.compile(r'(\bDocumentation/ABI/[\w\-/]+)') +RE_abi_symbol = re.compile(r'(\b/(sys|config|proc)/[\w\-/]+)') RE_namespace = re.compile(r'^\s*..\s*c:namespace::\s*(\S+)\s*$') @@ -83,11 +79,10 @@ def markup_refs(docname, app, node): # # Associate each regex with the function that will markup its matches # - markup_func_sphinx2 = {RE_doc: markup_doc_ref, - RE_function: markup_c_ref, - RE_generic_type: markup_c_ref} - markup_func_sphinx3 = {RE_doc: markup_doc_ref, + markup_func = {RE_doc: markup_doc_ref, + RE_abi_file: markup_abi_file_ref, + RE_abi_symbol: markup_abi_ref, RE_function: markup_func_ref_sphinx3, RE_struct: markup_c_ref, RE_union: markup_c_ref, @@ -95,11 +90,6 @@ def markup_refs(docname, app, node): RE_typedef: markup_c_ref, RE_git: markup_git} - if sphinx.version_info[0] >= 3: - markup_func = markup_func_sphinx3 - else: - markup_func = markup_func_sphinx2 - match_iterators = [regex.finditer(t) for regex in markup_func] # # Sort all references by the starting position in text @@ -270,6 +260,54 @@ def markup_doc_ref(docname, app, match): else: return nodes.Text(match.group(0)) +# +# Try to replace a documentation reference for ABI symbols and files +# with a cross reference to that page +# +def markup_abi_ref(docname, app, match, warning=False): + stddom = app.env.domains['std'] + # + # Go through the dance of getting an xref out of the std domain + # + kernel_abi = get_kernel_abi() + + fname = match.group(1) + target = kernel_abi.xref(fname) + + # Kernel ABI doesn't describe such file or symbol + if not target: + if warning: + kernel_abi.log.warning("%s not found", fname) + return nodes.Text(match.group(0)) + + pxref = addnodes.pending_xref('', refdomain = 'std', reftype = 'ref', + reftarget = target, modname = None, + classname = None, refexplicit = False) + + # + # XXX The Latex builder will throw NoUri exceptions here, + # work around that by ignoring them. + # + try: + xref = stddom.resolve_xref(app.env, docname, app.builder, 'ref', + target, pxref, None) + except NoUri: + xref = None + # + # Return the xref if we got it; otherwise just return the plain text. + # + if xref: + return xref + else: + return nodes.Text(match.group(0)) + +# +# Variant of markup_abi_ref() that warns whan a reference is not found +# +def markup_abi_file_ref(docname, app, match): + return markup_abi_ref(docname, app, match, warning=True) + + def get_c_namespace(app, docname): source = app.env.doc2path(docname) with open(source) as f: diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py index e6959af25402..e8ea80d4324c 100644 --- a/Documentation/sphinx/cdomain.py +++ b/Documentation/sphinx/cdomain.py @@ -1,6 +1,6 @@ # -*- coding: utf-8; mode: python -*- # pylint: disable=W0141,C0113,C0103,C0325 -u""" +""" cdomain ~~~~~~~ @@ -45,9 +45,6 @@ import re __version__ = '1.1' -# Get Sphinx version -major, minor, patch = sphinx.version_info[:3] - # Namespace to be prepended to the full name namespace = None @@ -145,7 +142,7 @@ class CObject(Base_CObject): } def handle_func_like_macro(self, sig, signode): - u"""Handles signatures of function-like macros. + """Handles signatures of function-like macros. If the objtype is 'function' and the signature ``sig`` is a function-like macro, the name of the macro is returned. Otherwise diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py index 5911bd0d7965..db6f0380de94 100644 --- a/Documentation/sphinx/kernel_abi.py +++ b/Documentation/sphinx/kernel_abi.py @@ -2,7 +2,7 @@ # coding=utf-8 # SPDX-License-Identifier: GPL-2.0 # -u""" +""" kernel-abi ~~~~~~~~~~ @@ -14,7 +14,7 @@ u""" :license: GPL Version 2, June 1991 see Linux/COPYING for details. The ``kernel-abi`` (:py:class:`KernelCmd`) directive calls the - scripts/get_abi.pl script to parse the Kernel ABI files. + scripts/get_abi.py script to parse the Kernel ABI files. Overview of directive's argument and options. @@ -32,107 +32,137 @@ u""" """ -import codecs import os -import subprocess -import sys import re -import kernellog +import sys from docutils import nodes, statemachine from docutils.statemachine import ViewList from docutils.parsers.rst import directives, Directive -from docutils.utils.error_reporting import ErrorString from sphinx.util.docutils import switch_source_input +from sphinx.util import logging + +srctree = os.path.abspath(os.environ["srctree"]) +sys.path.insert(0, os.path.join(srctree, "scripts/lib/abi")) + +from abi_parser import AbiParser + +__version__ = "1.0" + +logger = logging.getLogger('kernel_abi') +path = os.path.join(srctree, "Documentation/ABI") -__version__ = '1.0' +_kernel_abi = None + +def get_kernel_abi(): + """ + Initialize kernel_abi global var, if not initialized yet. + + This is needed to avoid warnings during Sphinx module initialization. + """ + global _kernel_abi + + if not _kernel_abi: + # Parse ABI symbols only once + _kernel_abi = AbiParser(path, logger=logger) + _kernel_abi.parse_abi() + _kernel_abi.check_issues() + + return _kernel_abi def setup(app): app.add_directive("kernel-abi", KernelCmd) - return dict( - version = __version__ - , parallel_read_safe = True - , parallel_write_safe = True - ) + return { + "version": __version__, + "parallel_read_safe": True, + "parallel_write_safe": True + } -class KernelCmd(Directive): - u"""KernelABI (``kernel-abi``) directive""" +class KernelCmd(Directive): + """KernelABI (``kernel-abi``) directive""" required_arguments = 1 - optional_arguments = 2 + optional_arguments = 3 has_content = False final_argument_whitespace = True + parser = None option_spec = { - "debug" : directives.flag, - "rst" : directives.unchanged + "debug": directives.flag, + "no-symbols": directives.flag, + "no-files": directives.flag, } def run(self): + kernel_abi = get_kernel_abi() + doc = self.state.document if not doc.settings.file_insertion_enabled: raise self.warning("docutils: file insertion disabled") - srctree = os.path.abspath(os.environ["srctree"]) - - args = [ - os.path.join(srctree, 'scripts/get_abi.pl'), - 'rest', - '--enable-lineno', - '--dir', os.path.join(srctree, 'Documentation', self.arguments[0]), - ] - - if 'rst' in self.options: - args.append('--rst-source') - - lines = subprocess.check_output(args, cwd=os.path.dirname(doc.current_source)).decode('utf-8') - nodeList = self.nestedParse(lines, self.arguments[0]) - return nodeList - - def nestedParse(self, lines, fname): env = self.state.document.settings.env content = ViewList() node = nodes.section() - if "debug" in self.options: - code_block = "\n\n.. code-block:: rst\n :linenos:\n" - for l in lines.split("\n"): - code_block += "\n " + l - lines = code_block + "\n\n" + abi_type = self.arguments[0] - line_regex = re.compile(r"^\.\. LINENO (\S+)\#([0-9]+)$") - ln = 0 - n = 0 - f = fname + if "no-symbols" in self.options: + show_symbols = False + else: + show_symbols = True - for line in lines.split("\n"): - n = n + 1 - match = line_regex.search(line) - if match: - new_f = match.group(1) + if "no-files" in self.options: + show_file = False + else: + show_file = True - # Sphinx parser is lazy: it stops parsing contents in the - # middle, if it is too big. So, handle it per input file - if new_f != f and content: - self.do_parse(content, node) - content = ViewList() + tab_width = self.options.get('tab-width', + self.state.document.settings.tab_width) - # Add the file to Sphinx build dependencies - env.note_dependency(os.path.abspath(f)) - - f = new_f - - # sphinx counts lines from 0 - ln = int(match.group(2)) - 1 + old_f = None + n = 0 + n_sym = 0 + for msg, f, ln in kernel_abi.doc(show_file=show_file, + show_symbols=show_symbols, + filter_path=abi_type): + n_sym += 1 + msg_list = statemachine.string2lines(msg, tab_width, + convert_whitespace=True) + if "debug" in self.options: + lines = [ + "", "", ".. code-block:: rst", + " :linenos:", "" + ] + for m in msg_list: + lines.append(" " + m) else: - content.append(line, f, ln) - - kernellog.info(self.state.document.settings.env.app, "%s: parsed %i lines" % (fname, n)) + lines = msg_list - if content: - self.do_parse(content, node) + for line in lines: + # sphinx counts lines from 0 + content.append(line, f, ln - 1) + n += 1 + + if f != old_f: + # Add the file to Sphinx build dependencies + env.note_dependency(os.path.abspath(f)) + + old_f = f + + # Sphinx doesn't like to parse big messages. So, let's + # add content symbol by symbol + if content: + self.do_parse(content, node) + content = ViewList() + + if show_symbols and not show_file: + logger.verbose("%s ABI: %i symbols (%i ReST lines)" % (abi_type, n_sym, n)) + elif not show_symbols and show_file: + logger.verbose("%s ABI: %i files (%i ReST lines)" % (abi_type, n_sym, n)) + else: + logger.verbose("%s ABI: %i data (%i ReST lines)" % (abi_type, n_sym, n)) return node.children diff --git a/Documentation/sphinx/kernel_feat.py b/Documentation/sphinx/kernel_feat.py index 03ace5f01b5c..e3a51867f27b 100644 --- a/Documentation/sphinx/kernel_feat.py +++ b/Documentation/sphinx/kernel_feat.py @@ -1,7 +1,7 @@ # coding=utf-8 # SPDX-License-Identifier: GPL-2.0 # -u""" +""" kernel-feat ~~~~~~~~~~~ @@ -56,7 +56,7 @@ def setup(app): class KernelFeat(Directive): - u"""KernelFeat (``kernel-feat``) directive""" + """KernelFeat (``kernel-feat``) directive""" required_arguments = 1 optional_arguments = 2 diff --git a/Documentation/sphinx/kernel_include.py b/Documentation/sphinx/kernel_include.py index 638762442336..8db176045bc5 100755 --- a/Documentation/sphinx/kernel_include.py +++ b/Documentation/sphinx/kernel_include.py @@ -2,7 +2,7 @@ # -*- coding: utf-8; mode: python -*- # pylint: disable=R0903, C0330, R0914, R0912, E0401 -u""" +""" kernel-include ~~~~~~~~~~~~~~ @@ -56,7 +56,7 @@ def setup(app): class KernelInclude(Include): # ============================================================================== - u"""KernelInclude (``kernel-include``) directive""" + """KernelInclude (``kernel-include``) directive""" def run(self): env = self.state.document.settings.env diff --git a/Documentation/sphinx/kerneldoc.py b/Documentation/sphinx/kerneldoc.py index ec1ddfff1863..39ddae6ae7dd 100644 --- a/Documentation/sphinx/kerneldoc.py +++ b/Documentation/sphinx/kerneldoc.py @@ -39,7 +39,7 @@ from docutils.statemachine import ViewList from docutils.parsers.rst import directives, Directive import sphinx from sphinx.util.docutils import switch_source_input -import kernellog +from sphinx.util import logging __version__ = '1.0' @@ -56,16 +56,12 @@ class KernelDocDirective(Directive): 'functions': directives.unchanged, } has_content = False + logger = logging.getLogger('kerneldoc') def run(self): env = self.state.document.settings.env cmd = [env.config.kerneldoc_bin, '-rst', '-enable-lineno'] - # Pass the version string to kernel-doc, as it needs to use a different - # dialect, depending what the C domain supports for each specific - # Sphinx versions - cmd += ['-sphinx-version', sphinx.__version__] - filename = env.config.kerneldoc_srctree + '/' + self.arguments[0] export_file_patterns = [] @@ -109,8 +105,7 @@ class KernelDocDirective(Directive): cmd += [filename] try: - kernellog.verbose(env.app, - 'calling kernel-doc \'%s\'' % (" ".join(cmd))) + self.logger.verbose("calling kernel-doc '%s'" % (" ".join(cmd))) p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE) out, err = p.communicate() @@ -120,8 +115,8 @@ class KernelDocDirective(Directive): if p.returncode != 0: sys.stderr.write(err) - kernellog.warn(env.app, - 'kernel-doc \'%s\' failed with return code %d' % (" ".join(cmd), p.returncode)) + self.logger.warning("kernel-doc '%s' failed with return code %d" + % (" ".join(cmd), p.returncode)) return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))] elif env.config.kerneldoc_verbosity > 0: sys.stderr.write(err) @@ -148,8 +143,8 @@ class KernelDocDirective(Directive): return node.children except Exception as e: # pylint: disable=W0703 - kernellog.warn(env.app, 'kernel-doc \'%s\' processing failed with: %s' % - (" ".join(cmd), str(e))) + self.logger.warning("kernel-doc '%s' processing failed with: %s" % + (" ".join(cmd), str(e))) return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))] def do_parse(self, result, node): diff --git a/Documentation/sphinx/kernellog.py b/Documentation/sphinx/kernellog.py deleted file mode 100644 index 0bc00c138cad..000000000000 --- a/Documentation/sphinx/kernellog.py +++ /dev/null @@ -1,22 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -# -# Sphinx has deprecated its older logging interface, but the replacement -# only goes back to 1.6. So here's a wrapper layer to keep around for -# as long as we support 1.4. -# -# We don't support 1.4 anymore, but we'll keep the wrappers around until -# we change all the code to not use them anymore :) -# -import sphinx -from sphinx.util import logging - -logger = logging.getLogger('kerneldoc') - -def warn(app, message): - logger.warning(message) - -def verbose(app, message): - logger.verbose(message) - -def info(app, message): - logger.info(message) diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py index 97166333b727..f1a7f13c9c60 100644 --- a/Documentation/sphinx/kfigure.py +++ b/Documentation/sphinx/kfigure.py @@ -1,6 +1,6 @@ # -*- coding: utf-8; mode: python -*- # pylint: disable=C0103, R0903, R0912, R0915 -u""" +""" scalable figure and image handling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -59,12 +59,14 @@ from docutils.parsers.rst import directives from docutils.parsers.rst.directives import images import sphinx from sphinx.util.nodes import clean_astext -import kernellog +from sphinx.util import logging Figure = images.Figure __version__ = '1.0.0' +logger = logging.getLogger('kfigure') + # simple helper # ------------- @@ -163,14 +165,14 @@ def setup(app): def setupTools(app): - u""" + """ Check available build tools and log some *verbose* messages. This function is called once, when the builder is initiated. """ global dot_cmd, dot_Tpdf, convert_cmd, rsvg_convert_cmd # pylint: disable=W0603 global inkscape_cmd, inkscape_ver_one # pylint: disable=W0603 - kernellog.verbose(app, "kfigure: check installed tools ...") + logger.verbose("kfigure: check installed tools ...") dot_cmd = which('dot') convert_cmd = which('convert') @@ -178,7 +180,7 @@ def setupTools(app): inkscape_cmd = which('inkscape') if dot_cmd: - kernellog.verbose(app, "use dot(1) from: " + dot_cmd) + logger.verbose("use dot(1) from: " + dot_cmd) try: dot_Thelp_list = subprocess.check_output([dot_cmd, '-Thelp'], @@ -190,10 +192,11 @@ def setupTools(app): dot_Tpdf_ptn = b'pdf' dot_Tpdf = re.search(dot_Tpdf_ptn, dot_Thelp_list) else: - kernellog.warn(app, "dot(1) not found, for better output quality install " - "graphviz from https://www.graphviz.org") + logger.warning( + "dot(1) not found, for better output quality install graphviz from https://www.graphviz.org" + ) if inkscape_cmd: - kernellog.verbose(app, "use inkscape(1) from: " + inkscape_cmd) + logger.verbose("use inkscape(1) from: " + inkscape_cmd) inkscape_ver = subprocess.check_output([inkscape_cmd, '--version'], stderr=subprocess.DEVNULL) ver_one_ptn = b'Inkscape 1' @@ -204,26 +207,27 @@ def setupTools(app): else: if convert_cmd: - kernellog.verbose(app, "use convert(1) from: " + convert_cmd) + logger.verbose("use convert(1) from: " + convert_cmd) else: - kernellog.verbose(app, + logger.verbose( "Neither inkscape(1) nor convert(1) found.\n" - "For SVG to PDF conversion, " - "install either Inkscape (https://inkscape.org/) (preferred) or\n" - "ImageMagick (https://www.imagemagick.org)") + "For SVG to PDF conversion, install either Inkscape (https://inkscape.org/) (preferred) or\n" + "ImageMagick (https://www.imagemagick.org)" + ) if rsvg_convert_cmd: - kernellog.verbose(app, "use rsvg-convert(1) from: " + rsvg_convert_cmd) - kernellog.verbose(app, "use 'dot -Tsvg' and rsvg-convert(1) for DOT -> PDF conversion") + logger.verbose("use rsvg-convert(1) from: " + rsvg_convert_cmd) + logger.verbose("use 'dot -Tsvg' and rsvg-convert(1) for DOT -> PDF conversion") dot_Tpdf = False else: - kernellog.verbose(app, + logger.verbose( "rsvg-convert(1) not found.\n" - " SVG rendering of convert(1) is done by ImageMagick-native renderer.") + " SVG rendering of convert(1) is done by ImageMagick-native renderer." + ) if dot_Tpdf: - kernellog.verbose(app, "use 'dot -Tpdf' for DOT -> PDF conversion") + logger.verbose("use 'dot -Tpdf' for DOT -> PDF conversion") else: - kernellog.verbose(app, "use 'dot -Tsvg' and convert(1) for DOT -> PDF conversion") + logger.verbose("use 'dot -Tsvg' and convert(1) for DOT -> PDF conversion") # integrate conversion tools @@ -257,13 +261,12 @@ def convert_image(img_node, translator, src_fname=None): # in kernel builds, use 'make SPHINXOPTS=-v' to see verbose messages - kernellog.verbose(app, 'assert best format for: ' + img_node['uri']) + logger.verbose('assert best format for: ' + img_node['uri']) if in_ext == '.dot': if not dot_cmd: - kernellog.verbose(app, - "dot from graphviz not available / include DOT raw.") + logger.verbose("dot from graphviz not available / include DOT raw.") img_node.replace_self(file2literal(src_fname)) elif translator.builder.format == 'latex': @@ -290,10 +293,11 @@ def convert_image(img_node, translator, src_fname=None): if translator.builder.format == 'latex': if not inkscape_cmd and convert_cmd is None: - kernellog.warn(app, - "no SVG to PDF conversion available / include SVG raw." - "\nIncluding large raw SVGs can cause xelatex error." - "\nInstall Inkscape (preferred) or ImageMagick.") + logger.warning( + "no SVG to PDF conversion available / include SVG raw.\n" + "Including large raw SVGs can cause xelatex error.\n" + "Install Inkscape (preferred) or ImageMagick." + ) img_node.replace_self(file2literal(src_fname)) else: dst_fname = path.join(translator.builder.outdir, fname + '.pdf') @@ -306,15 +310,14 @@ def convert_image(img_node, translator, src_fname=None): _name = dst_fname[len(str(translator.builder.outdir)) + 1:] if isNewer(dst_fname, src_fname): - kernellog.verbose(app, - "convert: {out}/%s already exists and is newer" % _name) + logger.verbose("convert: {out}/%s already exists and is newer" % _name) else: ok = False mkdir(path.dirname(dst_fname)) if in_ext == '.dot': - kernellog.verbose(app, 'convert DOT to: {out}/' + _name) + logger.verbose('convert DOT to: {out}/' + _name) if translator.builder.format == 'latex' and not dot_Tpdf: svg_fname = path.join(translator.builder.outdir, fname + '.svg') ok1 = dot2format(app, src_fname, svg_fname) @@ -325,7 +328,7 @@ def convert_image(img_node, translator, src_fname=None): ok = dot2format(app, src_fname, dst_fname) elif in_ext == '.svg': - kernellog.verbose(app, 'convert SVG to: {out}/' + _name) + logger.verbose('convert SVG to: {out}/' + _name) ok = svg2pdf(app, src_fname, dst_fname) if not ok: @@ -354,7 +357,7 @@ def dot2format(app, dot_fname, out_fname): with open(out_fname, "w") as out: exit_code = subprocess.call(cmd, stdout = out) if exit_code != 0: - kernellog.warn(app, + logger.warning( "Error #%d when calling: %s" % (exit_code, " ".join(cmd))) return bool(exit_code == 0) @@ -388,13 +391,14 @@ def svg2pdf(app, svg_fname, pdf_fname): pass if exit_code != 0: - kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd))) + logger.warning("Error #%d when calling: %s" % + (exit_code, " ".join(cmd))) if warning_msg: - kernellog.warn(app, "Warning msg from %s: %s" - % (cmd_name, str(warning_msg, 'utf-8'))) + logger.warning( "Warning msg from %s: %s" % + (cmd_name, str(warning_msg, 'utf-8'))) elif warning_msg: - kernellog.verbose(app, "Warning msg from %s (likely harmless):\n%s" - % (cmd_name, str(warning_msg, 'utf-8'))) + logger.verbose("Warning msg from %s (likely harmless):\n%s" % + (cmd_name, str(warning_msg, 'utf-8'))) return bool(exit_code == 0) @@ -418,7 +422,8 @@ def svg2pdf_by_rsvg(app, svg_fname, pdf_fname): # use stdout and stderr from parent exit_code = subprocess.call(cmd) if exit_code != 0: - kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd))) + logger.warning("Error #%d when calling: %s" % + (exit_code, " ".join(cmd))) ok = bool(exit_code == 0) return ok @@ -440,7 +445,7 @@ class kernel_image(nodes.image): pass class KernelImage(images.Image): - u"""KernelImage directive + """KernelImage directive Earns everything from ``.. image::`` directive, except *remote URI* and *glob* pattern. The KernelImage wraps a image node into a @@ -476,7 +481,7 @@ class kernel_figure(nodes.figure): """Node for ``kernel-figure`` directive.""" class KernelFigure(Figure): - u"""KernelImage directive + """KernelImage directive Earns everything from ``.. figure::`` directive, except *remote URI* and *glob* pattern. The KernelFigure wraps a figure node into a kernel_figure @@ -513,15 +518,15 @@ def visit_kernel_render(self, node): app = self.builder.app srclang = node.get('srclang') - kernellog.verbose(app, 'visit kernel-render node lang: "%s"' % (srclang)) + logger.verbose('visit kernel-render node lang: "%s"' % srclang) tmp_ext = RENDER_MARKUP_EXT.get(srclang, None) if tmp_ext is None: - kernellog.warn(app, 'kernel-render: "%s" unknown / include raw.' % (srclang)) + logger.warning( 'kernel-render: "%s" unknown / include raw.' % srclang) return if not dot_cmd and tmp_ext == '.dot': - kernellog.verbose(app, "dot from graphviz not available / include raw.") + logger.verbose("dot from graphviz not available / include raw.") return literal_block = node[0] @@ -552,7 +557,7 @@ class kernel_render(nodes.General, nodes.Inline, nodes.Element): pass class KernelRender(Figure): - u"""KernelRender directive + """KernelRender directive Render content by external tool. Has all the options known from the *figure* directive, plus option ``caption``. If ``caption`` has a diff --git a/Documentation/sphinx/load_config.py b/Documentation/sphinx/load_config.py index 8b416bfd75ac..ec50e1ee5223 100644 --- a/Documentation/sphinx/load_config.py +++ b/Documentation/sphinx/load_config.py @@ -9,7 +9,7 @@ from sphinx.util.osutil import fs_encoding def loadConfig(namespace): # ------------------------------------------------------------------------------ - u"""Load an additional configuration file into *namespace*. + """Load an additional configuration file into *namespace*. The name of the configuration file is taken from the environment ``SPHINX_CONF``. The external configuration file extends (or overwrites) the diff --git a/Documentation/sphinx/maintainers_include.py b/Documentation/sphinx/maintainers_include.py index dcad0fff4723..d31cff867436 100755 --- a/Documentation/sphinx/maintainers_include.py +++ b/Documentation/sphinx/maintainers_include.py @@ -3,7 +3,7 @@ # -*- coding: utf-8; mode: python -*- # pylint: disable=R0903, C0330, R0914, R0912, E0401 -u""" +""" maintainers-include ~~~~~~~~~~~~~~~~~~~ @@ -37,7 +37,7 @@ def setup(app): ) class MaintainersInclude(Include): - u"""MaintainersInclude (``maintainers-include``) directive""" + """MaintainersInclude (``maintainers-include``) directive""" required_arguments = 0 def parse_maintainers(self, path): diff --git a/Documentation/sphinx/rstFlatTable.py b/Documentation/sphinx/rstFlatTable.py index 16bea0632555..180fbb50c337 100755 --- a/Documentation/sphinx/rstFlatTable.py +++ b/Documentation/sphinx/rstFlatTable.py @@ -2,7 +2,7 @@ # -*- coding: utf-8; mode: python -*- # pylint: disable=C0330, R0903, R0912 -u""" +""" flat-table ~~~~~~~~~~ @@ -99,7 +99,7 @@ class colSpan(nodes.General, nodes.Element): pass # pylint: disable=C0103,C0321 class FlatTable(Table): # ============================================================================== - u"""FlatTable (``flat-table``) directive""" + """FlatTable (``flat-table``) directive""" option_spec = { 'name': directives.unchanged @@ -135,7 +135,7 @@ class FlatTable(Table): class ListTableBuilder(object): # ============================================================================== - u"""Builds a table from a double-stage list""" + """Builds a table from a double-stage list""" def __init__(self, directive): self.directive = directive @@ -212,7 +212,7 @@ class ListTableBuilder(object): raise SystemMessagePropagation(error) def parseFlatTableNode(self, node): - u"""parses the node from a :py:class:`FlatTable` directive's body""" + """parses the node from a :py:class:`FlatTable` directive's body""" if len(node) != 1 or not isinstance(node[0], nodes.bullet_list): self.raiseError( @@ -225,7 +225,7 @@ class ListTableBuilder(object): self.roundOffTableDefinition() def roundOffTableDefinition(self): - u"""Round off the table definition. + """Round off the table definition. This method rounds off the table definition in :py:member:`rows`. diff --git a/Documentation/sunrpc/xdr/nfs4_1.x b/Documentation/sunrpc/xdr/nfs4_1.x new file mode 100644 index 000000000000..ca95150a3a29 --- /dev/null +++ b/Documentation/sunrpc/xdr/nfs4_1.x @@ -0,0 +1,186 @@ +/* + * Copyright (c) 2010 IETF Trust and the persons identified + * as the document authors. All rights reserved. + * + * The document authors are identified in RFC 3530 and + * RFC 5661. + * + * Redistribution and use in source and binary forms, with + * or without modification, are permitted provided that the + * following conditions are met: + * + * - Redistributions of source code must retain the above + * copyright notice, this list of conditions and the + * following disclaimer. + * + * - Redistributions in binary form must reproduce the above + * copyright notice, this list of conditions and the + * following disclaimer in the documentation and/or other + * materials provided with the distribution. + * + * - Neither the name of Internet Society, IETF or IETF + * Trust, nor the names of specific contributors, may be + * used to endorse or promote products derived from this + * software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS + * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO + * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, + * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF + * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING + * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF + * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +pragma header nfs4; + +/* + * Basic typedefs for RFC 1832 data type definitions + */ +typedef hyper int64_t; +typedef unsigned int uint32_t; + +/* + * Basic data types + */ +typedef uint32_t bitmap4<>; + +/* + * Timeval + */ +struct nfstime4 { + int64_t seconds; + uint32_t nseconds; +}; + + +/* + * The following content was extracted from draft-ietf-nfsv4-delstid + */ + +typedef bool fattr4_offline; + + +const FATTR4_OFFLINE = 83; + + +struct open_arguments4 { + bitmap4 oa_share_access; + bitmap4 oa_share_deny; + bitmap4 oa_share_access_want; + bitmap4 oa_open_claim; + bitmap4 oa_create_mode; +}; + + +enum open_args_share_access4 { + OPEN_ARGS_SHARE_ACCESS_READ = 1, + OPEN_ARGS_SHARE_ACCESS_WRITE = 2, + OPEN_ARGS_SHARE_ACCESS_BOTH = 3 +}; + + +enum open_args_share_deny4 { + OPEN_ARGS_SHARE_DENY_NONE = 0, + OPEN_ARGS_SHARE_DENY_READ = 1, + OPEN_ARGS_SHARE_DENY_WRITE = 2, + OPEN_ARGS_SHARE_DENY_BOTH = 3 +}; + + +enum open_args_share_access_want4 { + OPEN_ARGS_SHARE_ACCESS_WANT_ANY_DELEG = 3, + OPEN_ARGS_SHARE_ACCESS_WANT_NO_DELEG = 4, + OPEN_ARGS_SHARE_ACCESS_WANT_CANCEL = 5, + OPEN_ARGS_SHARE_ACCESS_WANT_SIGNAL_DELEG_WHEN_RESRC_AVAIL + = 17, + OPEN_ARGS_SHARE_ACCESS_WANT_PUSH_DELEG_WHEN_UNCONTENDED + = 18, + OPEN_ARGS_SHARE_ACCESS_WANT_DELEG_TIMESTAMPS = 20, + OPEN_ARGS_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION = 21 +}; + + +enum open_args_open_claim4 { + OPEN_ARGS_OPEN_CLAIM_NULL = 0, + OPEN_ARGS_OPEN_CLAIM_PREVIOUS = 1, + OPEN_ARGS_OPEN_CLAIM_DELEGATE_CUR = 2, + OPEN_ARGS_OPEN_CLAIM_DELEGATE_PREV = 3, + OPEN_ARGS_OPEN_CLAIM_FH = 4, + OPEN_ARGS_OPEN_CLAIM_DELEG_CUR_FH = 5, + OPEN_ARGS_OPEN_CLAIM_DELEG_PREV_FH = 6 +}; + + +enum open_args_createmode4 { + OPEN_ARGS_CREATEMODE_UNCHECKED4 = 0, + OPEN_ARGS_CREATE_MODE_GUARDED = 1, + OPEN_ARGS_CREATEMODE_EXCLUSIVE4 = 2, + OPEN_ARGS_CREATE_MODE_EXCLUSIVE4_1 = 3 +}; + + +typedef open_arguments4 fattr4_open_arguments; +pragma public fattr4_open_arguments; + + +%/* +% * Determine what OPEN supports. +% */ +const FATTR4_OPEN_ARGUMENTS = 86; + + + + +const OPEN4_RESULT_NO_OPEN_STATEID = 0x00000010; + + +/* + * attributes for the delegation times being + * cached and served by the "client" + */ +typedef nfstime4 fattr4_time_deleg_access; +typedef nfstime4 fattr4_time_deleg_modify; +pragma public fattr4_time_deleg_access; +pragma public fattr4_time_deleg_modify; + + +%/* +% * New RECOMMENDED Attribute for +% * delegation caching of times +% */ +const FATTR4_TIME_DELEG_ACCESS = 84; +const FATTR4_TIME_DELEG_MODIFY = 85; + + + +/* new flags for share_access field of OPEN4args */ +const OPEN4_SHARE_ACCESS_WANT_DELEG_MASK = 0xFF00; +const OPEN4_SHARE_ACCESS_WANT_NO_PREFERENCE = 0x0000; +const OPEN4_SHARE_ACCESS_WANT_READ_DELEG = 0x0100; +const OPEN4_SHARE_ACCESS_WANT_WRITE_DELEG = 0x0200; +const OPEN4_SHARE_ACCESS_WANT_ANY_DELEG = 0x0300; +const OPEN4_SHARE_ACCESS_WANT_NO_DELEG = 0x0400; +const OPEN4_SHARE_ACCESS_WANT_CANCEL = 0x0500; + +const OPEN4_SHARE_ACCESS_WANT_SIGNAL_DELEG_WHEN_RESRC_AVAIL = 0x10000; +const OPEN4_SHARE_ACCESS_WANT_PUSH_DELEG_WHEN_UNCONTENDED = 0x20000; +const OPEN4_SHARE_ACCESS_WANT_DELEG_TIMESTAMPS = 0x100000; +const OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION = 0x200000; + +enum open_delegation_type4 { + OPEN_DELEGATE_NONE = 0, + OPEN_DELEGATE_READ = 1, + OPEN_DELEGATE_WRITE = 2, + OPEN_DELEGATE_NONE_EXT = 3, /* new to v4.1 */ + OPEN_DELEGATE_READ_ATTRS_DELEG = 4, + OPEN_DELEGATE_WRITE_ATTRS_DELEG = 5 +}; diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst index 759907c20e75..2d88a2acacc0 100644 --- a/Documentation/trace/events.rst +++ b/Documentation/trace/events.rst @@ -55,6 +55,30 @@ command:: # echo 'irq:*' > /sys/kernel/tracing/set_event +The set_event file may also be used to enable events associated to only +a specific module:: + + # echo ':mod:<module>' > /sys/kernel/tracing/set_event + +Will enable all events in the module ``<module>``. If the module is not yet +loaded, the string will be saved and when a module is that matches ``<module>`` +is loaded, then it will apply the enabling of events then. + +The text before ``:mod:`` will be parsed to specify specific events that the +module creates:: + + # echo '<match>:mod:<module>' > /sys/kernel/tracing/set_event + +The above will enable any system or event that ``<match>`` matches. If +``<match>`` is ``"*"`` then it will match all events. + +To enable only a specific event within a system:: + + # echo '<system>:<event>:mod:<module>' > /sys/kernel/tracing/set_event + +If ``<event>`` is ``"*"`` then it will match all events within the system +for a given module. + 2.2 Via the 'enable' toggle --------------------------- diff --git a/Documentation/trace/fprobe.rst b/Documentation/trace/fprobe.rst index 196f52386aaa..71cd40472d36 100644 --- a/Documentation/trace/fprobe.rst +++ b/Documentation/trace/fprobe.rst @@ -9,9 +9,10 @@ Fprobe - Function entry/exit probe Introduction ============ -Fprobe is a function entry/exit probe mechanism based on ftrace. -Instead of using ftrace full feature, if you only want to attach callbacks -on function entry and exit, similar to the kprobes and kretprobes, you can +Fprobe is a function entry/exit probe based on the function-graph tracing +feature in ftrace. +Instead of tracing all functions, if you want to attach callbacks on specific +function entry and exit, similar to the kprobes and kretprobes, you can use fprobe. Compared with kprobes and kretprobes, fprobe gives faster instrumentation for multiple functions with single handler. This document describes how to use fprobe. @@ -91,12 +92,14 @@ The prototype of the entry/exit callback function are as follows: .. code-block:: c - int entry_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long ret_ip, struct pt_regs *regs, void *entry_data); + int entry_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long ret_ip, struct ftrace_regs *fregs, void *entry_data); - void exit_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long ret_ip, struct pt_regs *regs, void *entry_data); + void exit_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long ret_ip, struct ftrace_regs *fregs, void *entry_data); -Note that the @entry_ip is saved at function entry and passed to exit handler. -If the entry callback function returns !0, the corresponding exit callback will be cancelled. +Note that the @entry_ip is saved at function entry and passed to exit +handler. +If the entry callback function returns !0, the corresponding exit callback +will be cancelled. @fp This is the address of `fprobe` data structure related to this handler. @@ -112,12 +115,10 @@ If the entry callback function returns !0, the corresponding exit callback will This is the return address that the traced function will return to, somewhere in the caller. This can be used at both entry and exit. -@regs - This is the `pt_regs` data structure at the entry and exit. Note that - the instruction pointer of @regs may be different from the @entry_ip - in the entry_handler. If you need traced instruction pointer, you need - to use @entry_ip. On the other hand, in the exit_handler, the instruction - pointer of @regs is set to the current return address. +@fregs + This is the `ftrace_regs` data structure at the entry and exit. This + includes the function parameters, or the return values. So user can + access thos values via appropriate `ftrace_regs_*` APIs. @entry_data This is a local storage to share the data between entry and exit handlers. @@ -125,6 +126,17 @@ If the entry callback function returns !0, the corresponding exit callback will and `entry_data_size` field when registering the fprobe, the storage is allocated and passed to both `entry_handler` and `exit_handler`. +Entry data size and exit handlers on the same function +====================================================== + +Since the entry data is passed via per-task stack and it has limited size, +the entry data size per probe is limited to `15 * sizeof(long)`. You also need +to take care that the different fprobes are probing on the same function, this +limit becomes smaller. The entry data size is aligned to `sizeof(long)` and +each fprobe which has exit handler uses a `sizeof(long)` space on the stack, +you should keep the number of fprobes on the same function as small as +possible. + Share the callbacks with kprobes ================================ @@ -165,8 +177,8 @@ This counter counts up when; - fprobe fails to take ftrace_recursion lock. This usually means that a function which is traced by other ftrace users is called from the entry_handler. - - fprobe fails to setup the function exit because of the shortage of rethook - (the shadow stack for hooking the function return.) + - fprobe fails to setup the function exit because of failing to allocate the + data buffer from the per-task shadow stack. The `fprobe::nmissed` field counts up in both cases. Therefore, the former skips both of entry and exit callback and the latter skips the exit diff --git a/Documentation/trace/postprocess/decode_msr.py b/Documentation/trace/postprocess/decode_msr.py index aa9cc7abd5c2..f5609b16f589 100644 --- a/Documentation/trace/postprocess/decode_msr.py +++ b/Documentation/trace/postprocess/decode_msr.py @@ -32,6 +32,6 @@ for j in sys.stdin: break if r: j = j.replace(" " + m.group(2), " " + r + "(" + m.group(2) + ")") - print j, + print(j) diff --git a/Documentation/trace/rv/runtime-verification.rst b/Documentation/trace/rv/runtime-verification.rst index dae78dfa7cdc..c700dde9259c 100644 --- a/Documentation/trace/rv/runtime-verification.rst +++ b/Documentation/trace/rv/runtime-verification.rst @@ -8,14 +8,14 @@ checking* and *theorem proving*) with a more practical approach for complex systems. Instead of relying on a fine-grained model of a system (e.g., a -re-implementation a instruction level), RV works by analyzing the trace of the +re-implementation at instruction level), RV works by analyzing the trace of the system's actual execution, comparing it against a formal specification of the system behavior. The main advantage is that RV can give precise information on the runtime behavior of the monitored system, without the pitfalls of developing models that require a re-implementation of the entire system in a modeling language. -Moreover, given an efficient monitoring method, it is possible execute an +Moreover, given an efficient monitoring method, it is possible to execute an *online* verification of a system, enabling the *reaction* for unexpected events, avoiding, for example, the propagation of a failure on safety-critical systems. diff --git a/Documentation/translations/it_IT/process/email-clients.rst b/Documentation/translations/it_IT/process/email-clients.rst index 97173746d8c9..9f8fe8abab4a 100644 --- a/Documentation/translations/it_IT/process/email-clients.rst +++ b/Documentation/translations/it_IT/process/email-clients.rst @@ -95,7 +95,7 @@ Nella sezione :menuselection:`Sending Preferences`: - :menuselection:`Strip Whitespace Before Sending` deve essere ``disabled`` Quando state scrivendo un messaggio, il cursore dev'essere posizionato -dove volete che la patch inizi, poi premendo :kbd:`CTRL-R` vi verrà chiesto +dove volete che la patch inizi, poi premendo `CTRL-R` vi verrà chiesto di selezionare il file patch da inserire nel messaggio. Claws Mail (GUI) @@ -104,7 +104,7 @@ Claws Mail (GUI) Funziona. Alcune persone riescono ad usarlo con successo per inviare le patch. Per inserire una patch usate :menuselection:`Messaggio-->Inserisci file` -(:kbd:`CTRL-I`) oppure un editor esterno. +(`CTRL-I`) oppure un editor esterno. Se la patch che avete inserito dev'essere modificata usando la finestra di scrittura di Claws, allora assicuratevi che l'"auto-interruzione" sia @@ -117,10 +117,10 @@ Alcune persone riescono ad usarlo con successo per inviare le patch. Quando state scrivendo una lettera selezionate: Preformattato da :menuselection:`Formato-->Stile del paragrafo-->Preformattato` - (:kbd:`CTRL-7`) o dalla barra degli strumenti + (`CTRL-7`) o dalla barra degli strumenti Poi per inserire la patch usate: -:menuselection:`Inserisci--> File di testo...` (:kbd:`ALT-N x`) +:menuselection:`Inserisci--> File di testo...` (`ALT-N x`) Potete anche eseguire ``diff -Nru old.c new.c | xclip``, selezionare :menuselection:`Preformattato`, e poi usare il tasto centrale del mouse. diff --git a/Documentation/translations/it_IT/process/submit-checklist.rst b/Documentation/translations/it_IT/process/submit-checklist.rst index 692be4af9c9b..5bf1b4adebc1 100644 --- a/Documentation/translations/it_IT/process/submit-checklist.rst +++ b/Documentation/translations/it_IT/process/submit-checklist.rst @@ -58,9 +58,10 @@ Fornite documentazione 4) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``. 5) Tutte le nuove interfacce verso lo spazio utente sono documentate in - ``Documentation/ABI/``. Leggete ``Documentation/ABI/README`` per maggiori - informazioni. Le patch che modificano le interfacce utente dovrebbero - essere inviate in copia anche a linux-api@vger.kernel.org. + ``Documentation/ABI/``. Leggete Documentation/admin-guide/abi.rst + (o ``Documentation/ABI/README``) per maggiori informazioni. + Le patch che modificano le interfacce utente dovrebbero essere inviate + in copia anche a linux-api@vger.kernel.org. 6) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate ``Documentation/userspace-api/ioctl/ioctl-number.rst``. diff --git a/Documentation/translations/ja_JP/SubmitChecklist b/Documentation/translations/ja_JP/SubmitChecklist deleted file mode 100644 index 1759c6b452d6..000000000000 --- a/Documentation/translations/ja_JP/SubmitChecklist +++ /dev/null @@ -1,105 +0,0 @@ -NOTE: -This is a version of Documentation/process/submit-checklist.rst into Japanese. -This document is maintained by Takenori Nagano <t-nagano@ah.jp.nec.com> -and the JF Project team <http://www.linux.or.jp/JF/>. -If you find any difference between this document and the original file -or a problem with the translation, -please contact the maintainer of this file or JF project. - -Please also note that the purpose of this file is to be easier to read -for non English (read: Japanese) speakers and is not intended as a -fork. So if you have any comments or updates of this file, please try -to update the original English file first. - -Last Updated: 2008/07/14 -================================== -これは、 -linux-2.6.26/Documentation/process/submit-checklist.rst の和訳です。 - -翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > -翻訳日： 2008/07/14 -翻訳者： Takenori Nagano <t-nagano at ah dot jp dot nec dot com> -校正者： Masanori Kobayashi さん <zap03216 at nifty dot ne dot jp> -================================== - - -Linux カーネルパッチ投稿者向けチェックリスト -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -本書では、パッチをより素早く取り込んでもらいたい開発者が実践すべき基本的な事柄 -をいくつか紹介します。ここにある全ての事柄は、Documentation/process/submitting-patches.rst -などのLinuxカーネルパッチ投稿に際しての心得を補足するものです。 - - 1: 妥当なCONFIGオプションや変更されたCONFIGオプション、つまり =y, =m, =n - 全てで正しくビルドできることを確認してください。その際、gcc及びリンカが - warningやerrorを出していないことも確認してください。 - - 2: allnoconfig, allmodconfig オプションを用いて正しくビルドできることを - 確認してください。 - - 3: 手許のクロスコンパイルツールやOSDLのPLMのようなものを用いて、複数の - アーキテクチャにおいても正しくビルドできることを確認してください。 - - 4: 64bit長の'unsigned long'を使用しているppc64は、クロスコンパイルでの - チェックに適当なアーキテクチャです。 - - 5: カーネルコーディングスタイルに準拠しているかどうか確認してください(!) - - 6: CONFIGオプションの追加・変更をした場合には、CONFIGメニューが壊れていない - ことを確認してください。 - - 7: 新しくKconfigのオプションを追加する際には、必ずそのhelpも記述してください。 - - 8: 適切なKconfigの依存関係を考えながら慎重にチェックしてください。 - ただし、この作業はマシンを使ったテストできちんと行うのがとても困難です。 - うまくやるには、自分の頭で考えることです。 - - 9: sparseを利用してちゃんとしたコードチェックをしてください。 - -10: 'make checkstack' を利用し、問題が発見されたら修正してください。 - 'make checkstack' は明示的に問題を示しませんが、どれか - １つの関数が512バイトより大きいスタックを使っていれば、修正すべき候補と - なります。 - -11: グローバルなkernel API を説明する kernel-doc をソースの中に含めてください。 - ( staticな関数においては必須ではありませんが、含めてもらっても結構です ) - そして、'make htmldocs' もしくは 'make mandocs' を利用して追記した - ドキュメントのチェックを行い、問題が見つかった場合には修正を行ってください。 - -12: CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB, - CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK, - CONFIG_DEBUG_ATOMIC_SLEEP これら全てを同時に有効にして動作確認を - 行ってください。 - -13: CONFIG_SMP, CONFIG_PREEMPT を有効にした場合と無効にした場合の両方で - ビルドした上、動作確認を行ってください。 - -14: lockdepの機能を全て有効にした上で、全てのコードパスを評価してください。 - -15: /proc に新しいエントリを追加した場合には、Documentation/ 配下に - 必ずドキュメントを追加してください。 - -16: 新しいブートパラメータを追加した場合には、 - 必ずDocumentation/admin-guide/kernel-parameters.rst に説明を追加してください。 - -17: 新しくmoduleにパラメータを追加した場合には、MODULE_PARM_DESC()を - 利用して必ずその説明を記述してください。 - -18: 新しいuserspaceインタフェースを作成した場合には、Documentation/ABI/ に - Documentation/ABI/README を参考にして必ずドキュメントを追加してください。 - -19: 少なくともslabアロケーションとpageアロケーションに失敗した場合の - 挙動について、fault-injectionを利用して確認してください。 - Documentation/fault-injection/ を参照してください。 - - 追加したコードがかなりの量であったならば、サブシステム特有の - fault-injectionを追加したほうが良いかもしれません。 - -20: 新たに追加したコードは、`gcc -W'でコンパイルしてください。 - このオプションは大量の不要なメッセージを出力しますが、 - "warning: comparison between signed and unsigned" のようなメッセージは、 - バグを見つけるのに役に立ちます。 - -21: 投稿したパッチが -mm パッチセットにマージされた後、全ての既存のパッチや - VM, VFS およびその他のサブシステムに関する様々な変更と、現時点でも共存 - できることを確認するテストを行ってください。 diff --git a/Documentation/translations/ja_JP/disclaimer-ja_JP.rst b/Documentation/translations/ja_JP/disclaimer-ja_JP.rst new file mode 100644 index 000000000000..46a026000407 --- /dev/null +++ b/Documentation/translations/ja_JP/disclaimer-ja_JP.rst @@ -0,0 +1,24 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _translations_ja_JP_disclaimer: + +========================== +免責条項 (Disclaimer) 抄訳 +========================== + +.. note:: 【訳註】 + この文書は、 + :ref:`Disclaimer (英語版) <translations_disclaimer>` + の一部を翻訳したものです。全文は英語版を参照願います。 + +Documentation/translations/ja_JP/ 以下のファイルは、対応する +Documentation/ 以下のファイル (原文) の日本語訳です。 +翻訳と原文との違いや翻訳上の問題を見つけたら、 +MAINTAINERS に記載の維持管理者に知らせてください。 +翻訳が原文の更新に追いついていない場合は、それを日本語版に反映するパッチの +投稿も歓迎です。 + +なお、この翻訳の目的は非英語 (ここでは日本語) 話者への便宜提供であり、 +フォークを意図したものではない事を念頭においてください。したがって、 +このファイルの内容に対するコメントや更新すべきことがあれば、先に原文の +更新を検討してください。 diff --git a/Documentation/translations/ja_JP/index.rst b/Documentation/translations/ja_JP/index.rst index 0b476b429e3b..4159b417bfdd 100644 --- a/Documentation/translations/ja_JP/index.rst +++ b/Documentation/translations/ja_JP/index.rst @@ -11,7 +11,9 @@ .. toctree:: :maxdepth: 1 + disclaimer-ja_JP process/howto + process/submit-checklist .. raw:: latex diff --git a/Documentation/translations/ja_JP/process/howto.rst b/Documentation/translations/ja_JP/process/howto.rst index d9ba40588e46..5e307f90982c 100644 --- a/Documentation/translations/ja_JP/process/howto.rst +++ b/Documentation/translations/ja_JP/process/howto.rst @@ -1,35 +1,18 @@ -.. raw:: latex +.. SPDX-License-Identifier: GPL-2.0 - \kerneldocCJKoff - -NOTE: -This is a version of Documentation/process/howto.rst translated into Japanese. -This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com> -If you find any difference between this document and the original file or -a problem with the translation, please contact the maintainer of this file. - -Please also note that the purpose of this file is to be easier to -read for non English (read: Japanese) speakers and is not intended as -a fork. So if you have any comments or updates for this file, please -try to update the original English file first. - ----------------------------------- - -.. raw:: latex - - \kerneldocCJKon - -この文書は、 -Documentation/process/howto.rst -の和訳です。 - -翻訳者： Tsugikazu Shibata <tshibata@ab.jp.nec.com> - ----------------------------------- +.. Originally contributed by Tsugikazu Shibata Linux カーネル開発のやり方 ========================== +.. note:: 【訳註】 + この文書は、 + Documentation/process/howto.rst + の翻訳です。 + 免責条項については、 + :ref:`免責条項の抄訳 <translations_ja_JP_disclaimer>` および、 + :ref:`Disclaimer (英語版) <translations_disclaimer>` を参照してください。 + これは上のトピック( Linux カーネル開発のやり方)の重要な事柄を網羅した ドキュメントです。ここには Linux カーネル開発者になるための方法とLinux カーネル開発コミュニティと共に活動するやり方を学ぶ方法が含まれています。 diff --git a/Documentation/translations/ja_JP/process/submit-checklist.rst b/Documentation/translations/ja_JP/process/submit-checklist.rst new file mode 100644 index 000000000000..fb3b9e3bd8ee --- /dev/null +++ b/Documentation/translations/ja_JP/process/submit-checklist.rst @@ -0,0 +1,163 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. Translated by Akira Yokosawa <akiyks@gmail.com> + +.. An old translation of this document of a different origin was at + Documentation/translations/ja_JP/SubmitChecklist, which can be found + in the pre-v6.14 tree if you are interested. + Please note that this translation is independent of the previous one. + +====================================== +Linux カーネルパッチ投稿チェックリスト +====================================== + +.. note:: 【訳註】 + この文書は、 + Documentation/process/submit-checklist.rst + の翻訳です。 + 免責条項については、 + :ref:`免責条項の抄訳 <translations_ja_JP_disclaimer>` および、 + :ref:`Disclaimer (英語版) <translations_disclaimer>` を参照してください。 + +以下は、カーネルパッチの投稿時に、そのスムーズな受け入れのために心がける +べき基本的な事項です。 + +これは、 Documentation/process/submitting-patches.rst およびその他の +Linux カーネルパッチ投稿に関する文書を踏まえ、それを補足するものです。 + +.. note:: 【訳註】 + 可能な項目については、パッチもしくはパッチ内の更新を暗黙の主語として、 + その望ましい状態を表す文体とします。その他、原義を損なわない範囲で + 係り結びを調整するなど、簡潔で把握しやすい箇条書きを目指します。 + + +コードのレビュー +================ + +1) 利用する機能について、その機能を定義・宣言しているファイルを + ``#include`` している。 + 他のヘッダーファイル経由での取り込みに依存しない。 + +2) Documentation/process/coding-style.rst に詳述されている一般的なスタイル + についてチェック済み。 + +3) メモリバリアー (例, ``barrier()``, ``rmb()``, ``wmb()``) について、 + そのすべてに、作用と目的、及び必要理由についての説明がソースコード内の + コメントとして記述されている。 + + +Kconfig 変更のレビュー +====================== + +1) 新規の、もしくは変更された ``CONFIG`` オプションについて、それが関係する + コンフィグメニューへの悪影響がない。また、 + Documentation/kbuild/kconfig-language.rst の + "Menu attibutes: default value" に記載の例外条件を満たす場合を除き、 + そのデフォルトが無効になっている。 + +2) 新規の ``Kconfig`` オプションにヘルプテキストがある。 + +3) 妥当な ``Kconfig`` の組み合わせについて注意深くレビューされている。 + これをテストでやり切るのは困難で、知力が決め手となる。 + +ドキュメンテーションの作成 +========================== + +1) グローバルなカーネル API が :ref:`kernel-doc <kernel_doc>` の形式で + ドキュメント化されている (静的関数には求められないが、付けてもよい)。 + +2) 新規 ``/proc`` エントリーが、すべて ``Documentation/`` 以下に記載されて + いる。 + +3) 新規カーネル・ブート・パラメータが、すべて + ``Documentation/admin-guide/kernel-parameters.rst`` に記載されている。 + +4) 新規モジュール・パラメータが、すべて ``MODULE_PARM_DESC()`` によって記述 + されている。 + +5) 新規ユーザースペース・インターフェースが、すべて ``Documentaion/ABI/`` + 以下に記載されている。詳しくは、 Documentation/admin-guide/abi.rst + (もしくは ``Documentation/ABI/README``) を参照。 + ユーザースペース・インターフェースを変更するパッチは、 + linux-api@vger.kernel.org にも CC すべし。 + +6) なんらかの ioctl を追加するパッチは、 + ``Documentation/userspace-api/ioctl/ioctl-number.rst`` + の更新を伴う。 + +ツールによるコードのチェック +============================ + +1) スタイル・チェッカー (``scripts/checkpatch.pl``) によって、犯しがちな + パッチ・スタイルの違反がないことを確認済み。 + 指摘される違反を残す場合は、それを正当化できること。 + +2) sparse により入念にチェック済み。 + +3) ``make checkstack`` で指摘される問題があれば、それが修正済み。 + ``checkstack`` は問題点を明示的には指摘しないが、 スタック消費が + 512 バイトを越える関数は見直しの候補。 + +コードのビルド +============== + +1) 以下の条件でクリーンにビルドできる。 + + a) 適用可能な、および ``=y``, ``=m``, ``=n`` を変更した ``CONFIG`` + オプションでのビルド。 + ``gcc`` およびリンカーからの警告・エラーがないこと。 + + b) ``allnoconfig`` と ``allmodconfig`` がパス + + c) ``O=builddir`` を指定してのビルド + + d) Documentation/ 以下の変更に関して、ドキュメントのビルドで新たな警告や + エラーが出ない。 + ``make htmldocs`` または ``make pdfdocs`` でビルドし、問題があれば修正。 + +2) ローカルのクロス・コンパイル・ツール、その他のビルド環境 (訳註: build farm) + を使って、複数の CPU アーキテクチャ向けにビルドできる。 + 特に、ワードサイズ (32 ビットと 64 ビット) やエンディアン (ビッグとリトル) + の異なるアーキテクチャを対象とするテストは、表現可能数値範囲・データ整列・ + エンディアンなどについての誤った仮定に起因する様々な移植上の問題を捕える + のに効果的。 + +3) 新規に追加されたコードについて (``make KCFLAGS=-W`` を使って) + ``gcc -W`` でコンパイル。 + これは多くのノイズを伴うが、 + ``warning: comparison between signed and unsigned`` + の類いのバグをあぶり出すのに効果的。 + +4) 変更されるソースコードが、下記の ``Kconfig`` シンボルに関連するカーネル + API や機能に依存 (もしくは利用) する場合、それらの ``Kconfig`` シンボルが、 + 無効、および (可能なら) ``=m`` の場合を組み合わせた複数のビルドを + (全部まとめてではなく、いろいろなランダムの組み合わせで) テスト済み。 + + ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, + ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, + ``CONFIG_NET``, ``CONFIG_INET=n`` (ただし、後者は ``CONFIG_NET=y`` + との組み合わせ)。 + +コードのテスト +============== + +1) ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, + ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, + ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, + ``CONFIG_PROVE_RCU`` および ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` をすべて + 同時に有効にしてのテスト済み。 + +2) ``CONFIG_SMP`` と ``CONFIG_PREEMPT`` が有効と無効の場合について、ビルドと + ランタイムのテスト済み。 + +3) lockdep の機能をすべて有効にしての実行で、すべてのコード経路が確認済み。 + +4) 最低限、slab と ページ・アロケーションの失敗に関する誤り注入 + (訳註: fault injection) によるチェック済み。 + 詳しくは、 Documentation/fault-injection/index.rst を参照。 + 新規のコードが多い場合は、サブシステム対象の誤り注入を追加するのが望ましい + 可能性あり。 + +5) linux-next の最新タグに対するテストにより、他でキューイングされている + パッチや、VM、VFS、その他のサブシステム内のすべての変更と組み合わせての + 動作を確認済み。 diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst index aae7018b0d1a..2b50283e1608 100644 --- a/Documentation/translations/sp_SP/index.rst +++ b/Documentation/translations/sp_SP/index.rst @@ -7,7 +7,7 @@ Traducción al español \kerneldocCJKoff -:maintainer: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> +:maintainer: Carlos Bilbao <carlos.bilbao@kernel.org> .. _sp_disclaimer: diff --git a/Documentation/translations/sp_SP/process/3.Early-stage.rst b/Documentation/translations/sp_SP/process/3.Early-stage.rst index 71cfb3fb0fda..bb3c630c7fd4 100644 --- a/Documentation/translations/sp_SP/process/3.Early-stage.rst +++ b/Documentation/translations/sp_SP/process/3.Early-stage.rst @@ -1,11 +1,241 @@ .. include:: ../disclaimer-sp.rst :Original: Documentation/process/3.Early-stage.rst +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com> .. _sp_development_early_stage: Planificación en etapa inicial ============================== -.. warning:: - TODO aún no traducido +Cuando uno se sienta a planear un proyecto de desarrollo del kernel Linux, +puede ser tentador lanzarse directamente a escribir código. Sin embargo, +como ocurre con cualquier proyecto significativo, gran parte del trabajo +que conduce al éxito es mejor realizarlo antes de escribir la primera línea +de código. Dedicar tiempo a la planificación y comunicación temprana puede +ahorrar mucho más tiempo en adelante. + +Especificar el problema +----------------------- + +Como en cualquier proyecto de ingeniería, una mejora exitosa del kernel +comienza con una descripción clara del problema a resolver. En algunos +casos, este paso es sencillo: cuando se necesita un driver para un hardware +específico, por ejemplo. En otros, sin embargo, es tentador confundir el +problema real con la solución propuesta, lo que puede generar dificultades. + +Consideremos un ejemplo: hace algunos años, los desarrolladores que +trabajaban con audio en Linux buscaban una forma de ejecutar aplicaciones +sin interrupciones u otros artefactos causados por la latencia excesiva en +el sistema. La solución a la que llegaron fue un módulo del kernel +destinado a integrarse en el marco del Módulo de Seguridad de Linux (LSM, +por sus siglas en inglés); este módulo podía configurarse para dar acceso a +aplicaciones específicas al planificador en tiempo real. Este módulo fue +implementado y enviado a la lista de correo del kernel de Linux, donde +inmediatamente encontró problemas. + +Para los desarrolladores de audio, este módulo de seguridad era suficiente +para resolver su problema inmediato. Sin embargo, para la comunidad más +amplia del kernel, se veía como un uso indebido del marco LSM (que no está +diseñado para otorgar privilegios a procesos que de otro modo no los +tendrían) y como un riesgo para la estabilidad del sistema. Sus soluciones +preferidas implicaban el acceso a la programación en tiempo real a través +del mecanismo de rlimit a corto plazo, y trabajo continuo para reducir la +latencia a largo plazo. + +La comunidad de audio, sin embargo, no podía ver más allá de la solución +particular que habían implementado; no estaban dispuestos a aceptar +alternativas. El desacuerdo resultante dejó a esos desarrolladores +desilusionados con todo el proceso de desarrollo del kernel; uno de ellos +volvió a una lista de audio y publicó esto (traducido): + + "Hay un buen número de desarrolladores muy competentes del kernel de Linux, pero tienden a ser opacados por una multitud de arrogantes necios. Intentar comunicar los requisitos de los usuarios a estas personas es una pérdida de tiempo. Son demasiado 'inteligentes' como para escuchar a simples mortales". + +Siendo el texto original: + + There are a number of very good Linux kernel developers, but they + tend to get outshouted by a large crowd of arrogant fools. Trying + to communicate user requirements to these people is a waste of + time. They are much too "intelligent" to listen to lesser mortals. + +(https://lwn.net/Articles/131776/). + +La realidad de la situación era diferente; los desarrolladores del kernel +estaban mucho más preocupados por la estabilidad del sistema, el +mantenimiento a largo plazo y encontrar la solución correcta al problema +que por un módulo específico. La moraleja de la historia es centrarse en el +problema, no en una solución específica, y discutirlo con la comunidad de +desarrollo antes de invertir en la creación de un cuerpo de código. + +Por lo tanto, al contemplar un proyecto de desarrollo del kernel, se deben +obtener respuestas a un conjunto corto de preguntas: + +- ¿Cuál es exactamente el problema que necesita ser resuelto? + +- ¿Quiénes son los usuarios afectados por este problema? ¿Qué casos de uso + debería abordar la solución? + +- ¿En qué aspectos el kernel actual no logra abordar ese problema? + +Solo entonces tiene sentido comenzar a considerar posibles soluciones. + +Discusión temprana +------------------ + +Al planificar un proyecto de desarrollo del kernel, tiene mucho sentido +realizar discusiones con la comunidad antes de lanzarse a la +implementación. La comunicación temprana puede ahorrar tiempo y problemas +de varias maneras: + +- Es posible que el problema ya esté siendo abordado por el kernel de + maneras que no haya comprendido. El kernel de Linux es grande y tiene + una serie de características y capacidades que no son inmediatamente + obvias. No todas las capacidades del kernel están documentadas tan bien + como uno quisiera, y es fácil pasar cosas por alto. El autor de este + texto ha visto la publicación de un driver completo que duplicaba uno + existente del que el nuevo autor no tenía conocimiento. El código que + reinventa ruedas existentes no solo es desperdicio; tampoco será aceptado + en el kernel principal. + +- Puede haber elementos de la solución propuesta que no serán aceptables + para su inclusión en el kernel principal. Es mejor descubrir problemas + como este antes de escribir el código. + +- Es completamente posible que otros desarrolladores ya hayan pensado en el + problema; pueden tener ideas para una mejor solución y estar dispuestos a + ayudar en la creación de esa solución. + +Años de experiencia con la comunidad de desarrollo del kernel han enseñado +una lección clara: el código del kernel que se diseña y desarrolla a +puertas cerradas invariablemente tiene problemas que solo se revelan cuando +el código se libera a la comunidad. A veces, estos problemas son graves, +requiriendo meses o años de esfuerzo antes de que el código pueda cumplir +con los estándares de la comunidad del kernel. Algunos ejemplos incluyen: + +- La pila de red Devicescape fue diseñada e implementada para sistemas de + un solo procesador. No pudo fusionarse en la rama principal hasta que se + hizo adecuada para sistemas multiprocesador. Adaptar el bloqueo y otros + aspectos en el código es una tarea difícil; como resultado, la fusión de + este código (ahora llamado mac80211) se retrasó más de un año. + +- El sistema de archivos Reiser4 incluía una serie de capacidades que, en + opinión de los desarrolladores principales del kernel, deberían haberse + implementado en la capa de sistemas de archivos virtuales. También + incluía funciones que no podían implementarse fácilmente sin exponer el + sistema a bloqueos causados por los usuarios. La revelación tardía de + estos problemas, y la negativa a abordar algunos de ellos, ha mantenido a + Reiser4 fuera del kernel principal. + +- El módulo de seguridad AppArmor hacía uso de estructuras de datos + internas del sistema de archivos virtual de maneras que se consideraban + inseguras y poco fiables. Esta preocupación (entre otras) mantuvo a + AppArmor fuera de la rama principal durante años. + +En cada uno de estos casos, se podría haber evitado mucho dolor y trabajo +adicional con algunas discusiones tempranas con los desarrolladores del +kernel. + +¿Con quién hablar? +------------------- + +Cuando los desarrolladores deciden hacer públicas sus ideas, la siguiente +pregunta será: ¿dónde empezar? La respuesta es encontrar la lista de correo +adecuada y el maintainer correcto. Para las listas de correo, la mejor +opción es buscar en el archivo MAINTAINERS un lugar relevante para +publicar. Si existe una lista de subsistema adecuada, es preferible +publicarla allí en lugar de en linux-kernel; es más probable que llegues a +desarrolladores con experiencia en el subsistema relevante y el ambiente +puede ser más propicio. + +Encontrar a los maintainers puede ser un poco más difícil. Nuevamente, el +archivo MAINTAINERS es el lugar para empezar. Sin embargo, ese archivo +tiende a no estar siempre actualizado, y no todos los subsistemas están +representados allí. La persona listada en el archivo MAINTAINERS puede, de +hecho, no ser la persona que está actuando en ese rol actualmente. Por lo +tanto, cuando haya dudas sobre a quién contactar, un truco útil es usar git +(y "git log" en particular) para ver quién está activo actualmente en el +subsistema de interés. Mira quién está escribiendo parches y quién, si +alguien, está adjuntando líneas de Signed-off-by a esos parches. Esas son +las personas que estarán mejor posicionadas para ayudar con un nuevo +proyecto de desarrollo. + +La tarea de encontrar al maintainer correcto es lo suficientemente +desafiante como para que los desarrolladores del kernel hayan añadido un +script para facilitar el proceso: + +:: + + .../scripts/get_maintainer.pl + +Este script devolverá los maintainers actuales de un archivo o directorio +dado cuando se le pase la opción "-f". Si se le pasa un parche en la línea +de comandos, listará a los maintainers que probablemente deberían recibir +copias del parche. Esta es la manera preferida (a diferencia de la opción +"-f") de obtener la lista de personas a las que hay que enviar las copias +de sus parches. Hay varias opciones que regulan cuán agresivamente +get_maintainer.pl buscará maintainers; por favor, ten cuidado al usar las +opciones más agresivas, ya que podrías terminar incluyendo desarrolladores +que no tienen ningún interés real en el código que estás modificando. + +Si todo lo demás falla, hablar con Andrew Morton puede ser una forma +efectiva de encontrar a un maintainer para un código específico. + +¿Cuándo publicar? +------------------ + +Si es posible, publicar sus planes en las primeras etapas solo puede ser +útil. Describa el problema que se está resolviendo y cualquier plan que se +haya hecho sobre cómo se llevará a cabo la implementación. Cualquier +información que puedas proporcionar puede ayudar a la comunidad de +desarrollo a ofrecer comentarios útiles sobre el proyecto. + +Una cosa desalentadora que puede suceder en esta etapa no es una reacción +hostil, sino, en cambio, poca o ninguna reacción en absoluto. La triste +realidad es que (1) los desarrolladores del kernel tienden a estar +ocupados, (2) no hay escasez de personas con grandes planes y poco código +(o incluso perspectivas de código) para respaldarlos, y (3) nadie está +obligado a revisar o comentar las ideas publicadas por otros. Además, los +diseños de alto nivel a menudo esconden problemas que solo se revelan +cuando alguien realmente intenta implementar esos diseños; por esa razón, +los desarrolladores del kernel prefieren ver el código. + +Si una publicación de solicitud de comentarios genera pocos comentarios, no +asuma que significa que no hay interés en el proyecto. Desafortunadamente, +tampoco puedes asumir que no hay problemas con tu idea. Lo mejor que puede +hacer en esta situación es seguir adelante, manteniendo informada a +comunidad a medida que avanza. + +Obtener respaldo oficial +------------------------ + +Si su trabajo se está realizando en un entorno corporativo — como ocurre +con la mayoría del trabajo en el kernel de Linux — es obvio que debe tener +permiso de los jefes debidamente autorizados antes de poder publicar los +planes o el código de su empresa en una lista de correo pública. La +publicación de código que no ha sido autorizado para su liberación bajo una +licencia compatible con la GPL puede ser especialmente problemática; cuanto +antes la gerencia y el personal legal de una empresa lleguen a un acuerdo +sobre la publicación de un proyecto de desarrollo del kernel, mejor será +para todos los involucrados. + +Algunos lectores pueden estar pensando en este momento que su trabajo en el +kernel está destinado a respaldar un producto que aún no ha sido reconocido +oficialmente. Revelar los planes de su empleador en una lista de correo +pública puede no ser una opción viable. En casos como este, vale la pena +considerar si realmente es necesario mantener el secreto; a menudo no hay +una necesidad real de mantener los planes de desarrollo en secreto. + +Dicho esto, también hay casos en los que una empresa legítimamente no puede +revelar sus planes al inicio del proceso de desarrollo. Las empresas con +desarrolladores experimentados en el kernel pueden optar por proceder de +manera abierta, bajo el supuesto de que podrán evitar problemas graves de +integración más adelante. Para las empresas sin ese tipo de experiencia +interna, la mejor opción suele ser contratar a un desarrollador externo +para que revise los planes bajo un acuerdo de confidencialidad (NDA). La +Linux Foundation opera un programa de NDA diseñado para ayudar en este tipo +de situaciones; se puede encontrar más información en: + + https://www.linuxfoundation.org/nda/ + +Este tipo de revisión suele ser suficiente para evitar problemas graves más +adelante sin necesidad de revelar públicamente el proyecto. diff --git a/Documentation/translations/sp_SP/process/4.Coding.rst b/Documentation/translations/sp_SP/process/4.Coding.rst index d9436e039b4b..7cc347c34354 100644 --- a/Documentation/translations/sp_SP/process/4.Coding.rst +++ b/Documentation/translations/sp_SP/process/4.Coding.rst @@ -1,11 +1,470 @@ .. include:: ../disclaimer-sp.rst :Original: Documentation/process/4.Coding.rst +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com> .. _sp_development_coding: Conseguir el código correcto ============================ -.. warning:: - TODO aún no traducido +Si bien hay mucho que decir a favor de un proceso de diseño sólido y +orientado a la comunidad, la prueba de cualquier proyecto de desarrollo del +kernel está en el código resultante. Es el código lo que será examinado por +otros desarrolladores y lo que será incluido (o no) en el árbol principal. +Por lo tanto, es la calidad de este código lo que determinará el éxito +final del proyecto. + +Esta sección examinará el proceso de programación. Comenzaremos observando +algunas de las maneras en que los desarrolladores del kernel pueden cometer +errores. Luego, el enfoque se dirigirá hacia hacer las cosas bien y las +herramientas que pueden ayudar en dicha búsqueda. + +Problemas +--------- + +Estilo de programación +********************** + +El kernel ha tenido durante mucho tiempo un estilo de programación +estándar, descrito en la documentación del kernel en +`Documentation/process/coding-style.rst`. Durante gran parte de ese tiempo, +las políticas descritas en ese archivo se tomaban como, en el mejor de los +casos, orientativas. Como resultado, hay una cantidad considerable de +código en el kernel que no cumple con las pautas de estilo de programación. +La presencia de ese código lleva a dos peligros independientes para los +desarrolladores del kernel. + +El primero de estos es creer que los estándares de programación del kernel +no importan y no se aplican. La realidad es que agregar nuevo código al +kernel es muy difícil si ese código no está escrito de acuerdo con el +estándar; muchos desarrolladores solicitarán que el código sea reformateado +antes de revisarlo. Una base de código tan grande como el kernel requiere +cierta uniformidad para que los desarrolladores puedan comprender +rápidamente cualquier parte de él. Así que ya no hay lugar para el código +con formato extraño. + +Ocasionalmente, el estilo de programación del kernel entrará en conflicto +con el estilo obligatorio de un empleador. En tales casos, el estilo del +kernel tendrá que prevalecer antes de que el código pueda ser fusionado. +Incluir código en el kernel significa renunciar a cierto grado de control +de varias maneras, incluida la forma en que se formatea el código. + +La otra trampa es asumir que el código que ya está en el kernel necesita +urgentemente correcciones de estilo de programación. Los desarrolladores +pueden comenzar a generar parches de reformateo como una forma de +familiarizarse con el proceso o como una forma de incluir su nombre en los +registros de cambios del kernel, o ambos. Pero las correcciones puramente +de estilo de programación son vistas como ruido por la comunidad de +desarrollo; tienden a recibir una recepción adversa. Por lo tanto, este +tipo de parche es mejor evitarlo. Es natural corregir el estilo de una +parte del código mientras se trabaja en él por otras razones, pero los +cambios de estilo de programación no deben hacerse por sí mismos. + +El documento de estilo de programación tampoco debe leerse como una ley +absoluta que nunca puede transgredirse. Si hay una buena razón para ir en +contra del estilo (una línea que se vuelve mucho menos legible si se divide +para ajustarse al límite de 80 columnas, por ejemplo), perfecto. + +Tenga en cuenta que también puedes usar la herramienta `clang-format` para +ayudarle con estas reglas, para reformatear rápidamente partes de su código +automáticamente y para revisar archivos completos a fin de detectar errores +de estilo de programación, errores tipográficos y posibles mejoras. También +es útil para ordenar `#includes`, alinear variables/macros, reformatear +texto y otras tareas similares. Consulte el archivo +`Documentation/dev-tools/clang-format.rst` para más detalles. + +Algunas configuraciones básicas del editor, como la indentación y los +finales de línea, se configurarán automáticamente si utilizas un editor +compatible con EditorConfig. Consulte el sitio web oficial de EditorConfig +para obtener más información: https://editorconfig.org/ + +Capas de abstracción +******************** + +Los profesores de ciencias de la computación enseñan a los estudiantes a +hacer un uso extensivo de capas de abstracción en nombre de la +flexibilidad y el ocultamiento de la información. Sin duda, el kernel hace +un uso extensivo de la abstracción; ningún proyecto que involucre varios +millones de líneas de código podría sobrevivir de otra manera. Pero la +experiencia ha demostrado que una abstracción excesiva o prematura puede +ser tan perjudicial como la optimización prematura. La abstracción debe +usarse en la medida necesaria y ya. + +A un nivel simple, considere una función que tiene un argumento que siempre +se pasa como cero por todos los que la invocan. Uno podría mantener ese +argumento por si alguien eventualmente necesita usar la flexibilidad +adicional que proporciona. Sin embargo, para entonces, es probable que el +código que implementa este argumento adicional se haya roto de alguna +manera sutil que nunca se notó, porque nunca se ha utilizado. O, cuando +surge la necesidad de flexibilidad adicional, no lo hace de una manera que +coincida con la expectativa temprana del programador. Los desarrolladores +del kernel rutinariamente enviarán parches para eliminar argumentos no +utilizados; en general, no deberían añadirse en primer lugar. + +Las capas de abstracción que ocultan el acceso al hardware, a menudo para +permitir que la mayor parte de un controlador se utilice con varios +sistemas operativos, son especialmente mal vistas. Dichas capas oscurecen +el código y pueden imponer una penalización en el rendimiento; no +pertenecen al kernel de Linux. + +Por otro lado, si se encuentra copiando cantidades significativas de código +de otro subsistema del kernel, es hora de preguntar si, de hecho, tendría +sentido extraer parte de ese código en una biblioteca separada o +implementar esa funcionalidad a un nivel superior. No tiene sentido +replicar el mismo código en todo el kernel. + +Uso de #ifdef y del preprocesador en general +******************************************** + +El preprocesador de C tiene una tentación poderosa para algunos +programadores de C, quienes lo ven como una forma de programar +eficientemente una gran cantidad de flexibilidad en un archivo fuente. Pero +el preprocesador no es C, y el uso intensivo de él da como resultado un +código mucho más difícil de leer para otros y más difícil de verificar por +el compilador para su corrección. El uso intensivo del preprocesador es +asi siempre un signo de un código que necesita algo de limpieza. + +La compilación condicional con `#ifdef` es, de hecho, una característica +poderosa, y se usa dentro del kernel. Pero hay poco deseo de ver código que +sté salpicado liberalmente con bloques `#ifdef`. Como regla general, el uso +de `#ifdef` debe limitarse a los archivos de encabezado siempre que sea +posible. El código condicionalmente compilado puede confinarse a funciones +que, si el código no va a estar presente, simplemente se convierten en +vacías. El compilador luego optimizará silenciosamente la llamada a la +función vacía. El resultado es un código mucho más limpio y fácil de +seguir. + +Las macros del preprocesador de C presentan varios peligros, incluida la +posible evaluación múltiple de expresiones con efectos secundarios y la +falta de seguridad de tipos. Si te sientes tentado a definir una macro, +considera crear una función en línea en su lugar. El código resultante será +el mismo, pero las funciones en línea son más fáciles de leer, no evalúan +sus argumentos varias veces y permiten que el compilador realice +comprobaciones de tipo en los argumentos y el valor de retorno. + +Funciones en línea +****************** + +Las funciones en línea presentan su propio peligro, sin embargo. Los +programadores pueden enamorarse de la eficiencia percibida al evitar una +llamada a función y llenar un archivo fuente con funciones en línea. Esas +funciones, sin embargo, pueden en realidad reducir el rendimiento. Dado que +su código se replica en cada sitio de llamada, terminan hinchando el tamaño +del kernel compilado. Eso, a su vez, crea presión en las cachés de memoria +del procesador, lo que puede ralentizar la ejecución de manera drástica +Las funciones en línea, como regla, deben ser bastante pequeñas y +relativamente raras. El costo de una llamada a función, después de todo, no +es tan alto; la creación de un gran número de funciones en línea es un +ejemplo clásico de optimización prematura. + +En general, los programadores del kernel ignoran los efectos de caché bajo +su propio riesgo. El clásico intercambio de tiempo/espacio que se enseña en +las clases de estructuras de datos iniciales a menudo no se aplica al +hardware contemporáneo. El espacio *es* tiempo, en el sentido de que un +programa más grande se ejecutará más lentamente que uno más compacto. + +Los compiladores más recientes toman un papel cada vez más activo al +decidir si una función dada debe realmente ser en línea o no. Por lo tanto, +la colocación liberal de palabras clave "inline" puede no solo ser +excesiva; también podría ser irrelevante. + +Bloqueo +******* + +En mayo de 2006, la pila de red "Devicescape" fue, con gran fanfarria, +lanzada bajo la licencia GPL y puesta a disposición para su inclusión en el +kernel principal. Esta donación fue una noticia bienvenida; el soporte para +redes inalámbricas en Linux se consideraba, en el mejor de los casos, +deficiente, y la pila de Devicescape ofrecía la promesa de solucionar esa +situación. Sin embargo, este código no fue incluido en el kernel principal +hasta junio de 2007 (versión 2.6.22). ¿Qué sucedió? + +Este código mostró varios signos de haber sido desarrollado a puertas +cerradas en una empresa. Pero un problema importante en particular fue que +no estaba diseñado para funcionar en sistemas multiprocesador. Antes de que +esta pila de red (ahora llamada mac80211) pudiera fusionarse, se tuvo que +implementar un esquema de bloqueo en ella. + +Hubo un tiempo en que se podía desarrollar código para el kernel de Linux +sin pensar en los problemas de concurrencia que presentan los sistemas +multiprocesador. Ahora, sin embargo, este documento se está escribiendo en +una computadora portátil con dos núcleos. Incluso en sistemas de un solo +procesador, el trabajo que se está realizando para mejorar la capacidad de +respuesta aumentará el nivel de concurrencia dentro del kernel. Los días en +que se podía escribir código para el kernel sin pensar en el bloqueo han +quedado atrás. + +Cualquier recurso (estructuras de datos, registros de hardware, etc.) que +pueda ser accedido concurrentemente por más de un hilo debe estar protegido +por un bloqueo. El nuevo código debe escribirse teniendo en cuenta este +requisito; implementar el bloqueo después de que el código ya ha sido +desarrollado es una tarea mucho más difícil. Los desarrolladores del kernel +deben tomarse el tiempo para comprender bien los primitivos de bloqueo +disponibles para elegir la herramienta adecuada para el trabajo. El código +que muestre una falta de atención a la concurrencia tendrá un camino +difícil para ser incluido en el kernel principal. + +Regresiones +*********** + +Un último peligro que vale la pena mencionar es el siguiente: puede ser +tentador realizar un cambio (que puede traer grandes mejoras) que cause un +problema para los usuarios existentes. Este tipo de cambio se llama una +"regresión", y las regresiones se han vuelto muy mal recibidas en el kernel +principal. Con pocas excepciones, los cambios que causan regresiones serán +revertidos si la regresión no se puede solucionar de manera oportuna. Es +mucho mejor evitar la regresión desde el principio. + +A menudo se argumenta que una regresión puede justificarse si hace que las +cosas funcionen para más personas de las que crea problemas. ¿Por qué no +hacer un cambio si trae nueva funcionalidad a diez sistemas por cada uno +que rompe? La mejor respuesta a esta pregunta fue expresada por Linus en +julio de 2007 (traducido): + +:: + + Entonces, no arreglamos errores introduciendo nuevos problemas. Eso + lleva a la locura, y nadie sabe si realmente se avanza. ¿Es dos pasos + adelante, uno atrás, o un paso adelante y dos atrás? + +(https://lwn.net/Articles/243460/). + +Un tipo de regresión especialmente mal recibido es cualquier tipo de cambio +en la ABI del espacio de usuario. Una vez que se ha exportado una interfaz +al espacio de usuario, debe ser soportada indefinidamente. Este hecho hace +que la creación de interfaces para el espacio de usuario sea +particularmente desafiante: dado que no pueden cambiarse de manera +incompatible, deben hacerse bien desde el principio. Por esta razón, +siempre se requiere una gran cantidad de reflexión, documentación clara y +una amplia revisión para las interfaces del espacio de usuario. + +Herramientas de verificación de código +************************************** + +Por ahora, al menos, escribir código libre de errores sigue siendo un ideal +que pocos de nosotros podemos alcanzar. Sin embargo, lo que podemos esperar +hacer es detectar y corregir tantos de esos errores como sea posible antes +de que nuestro código se integre en el kernel principal. Con ese fin, los +desarrolladores del kernel han reunido una impresionante variedad de +herramientas que pueden detectar una amplia variedad de problemas oscuros +de manera automatizada. Cualquier problema detectado por el ordenador es +un problema que no afectará a un usuario más adelante, por lo que es lógico +que las herramientas automatizadas se utilicen siempre que sea posible. + +El primer paso es simplemente prestar atención a las advertencias +producidas por el compilador. Las versiones contemporáneas de gcc pueden +detectar (y advertir sobre) una gran cantidad de errores potenciales. Con +bastante frecuencia, estas advertencias apuntan a problemas reales. El +código enviado para revisión no debería, por regla general, producir +ninguna advertencia del compilador. Al silenciar las advertencias, tenga +cuidado de comprender la causa real e intente evitar "correcciones" que +hagan desaparecer la advertencia sin abordar su causa. + +Tenga en cuenta que no todas las advertencias del compilador están +habilitadas de forma predeterminada. Compile el kernel con +"make KCFLAGS=-W" para obtener el conjunto completo. + +El kernel proporciona varias opciones de configuración que activan +funciones de depuración; la mayoría de estas se encuentran en el submenú +"kernel hacking". Varias de estas opciones deben estar activadas para +cualquier kernel utilizado para desarrollo o pruebas. En particular, +debería activar: + + - FRAME_WARN para obtener advertencias sobre marcos de pila más grandes + que una cantidad determinada. La salida generada puede ser extensa, pero + no es necesario preocuparse por las advertencias de otras partes del + kernel. + + - DEBUG_OBJECTS agregará código para rastrear la vida útil de varios + objetos creados por el kernel y advertir cuando se realicen cosas fuera + de orden. Si está agregando un subsistema que crea (y exporta) objetos + complejos propios, considere agregar soporte para la infraestructura de + depuración de objetos. + + - DEBUG_SLAB puede encontrar una variedad de errores en la asignación y + uso de memoria; debe usarse en la mayoría de los kernels de desarrollo. + + - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP y DEBUG_MUTEXES encontrarán una serie + de errores comunes de bloqueo. + +Hay bastantes otras opciones de depuración, algunas de las cuales se +discutirán más adelante. Algunas de ellas tienen un impacto significativo +en el rendimiento y no deben usarse todo el tiempo. Pero dedicar tiempo a +aprender las opciones disponibles probablemente será recompensado muchas +veces en poco tiempo. + +Una de las herramientas de depuración más pesadas es el verificador de +bloqueos, o "lockdep". Esta herramienta rastreará la adquisición y +liberación de cada bloqueo (spinlock o mutex) en el sistema, el orden en +que se adquieren los bloqueos en relación entre sí, el entorno actual de +interrupción, y más. Luego, puede asegurarse de que los bloqueos siempre se +adquieran en el mismo orden, que las mismas suposiciones de interrupción se +apliquen en todas las situaciones, y así sucesivamente. En otras palabras, +lockdep puede encontrar varios escenarios en los que el sistema podría, en +raras ocasiones, bloquearse. Este tipo de problema puede ser doloroso +(tanto para desarrolladores como para usuarios) en un sistema desplegado; +lockdep permite encontrarlos de manera automatizada con anticipación. El +código con cualquier tipo de bloqueo no trivial debe ejecutarse con lockdep +habilitado antes de ser enviado para su inclusión. + +Como programador diligente del kernel, sin duda alguna, verificará el +estado de retorno de cualquier operación (como una asignación de memoria) +que pueda fallar. Sin embargo, el hecho es que las rutas de recuperación de +fallos resultantes probablemente no hayan sido probadas en absoluto. El +código no probado tiende a ser código roto; podría tener mucha más +confianza en su código si todas esas rutas de manejo de errores se hubieran +ejercitado algunas veces. + +El kernel proporciona un marco de inyección de fallos que puede hacer +precisamente eso, especialmente donde están involucradas las asignaciones +de memoria. Con la inyección de fallos habilitada, un porcentaje +configurable de las asignaciones de memoria fallarán; estas fallas pueden +restringirse a un rango específico de código. Ejecutar con la inyección de +fallos habilitada permite al programador ver cómo responde el código cuando +las cosas van mal. Consulte +Documentation/fault-injection/fault-injection.rst para obtener más +información sobre cómo utilizar esta funcionalidad. + +Otros tipos de errores se pueden encontrar con la herramienta de análisis +estático "sparse". Con sparse, el programador puede recibir advertencias +sobre confusiones entre direcciones del espacio de usuario y del kernel, +mezcla de cantidades big-endian y little-endian, el paso de valores enteros +donde se espera un conjunto de banderas de bits, y así sucesivamente. +Sparse debe instalarse por separado (puede encontrarse en +https://sparse.wiki.kernel.org/index.php/Main_Page si su distribución no lo +empaqueta); luego, puede ejecutarse en el código agregando "C=1" a su +comando make. + +La herramienta "Coccinelle" (http://coccinelle.lip6.fr/) puede encontrar +una amplia variedad de posibles problemas de codificación; también puede +proponer correcciones para esos problemas. Bastantes "parches semánticos" +para el kernel se han empaquetado en el directorio scripts/coccinelle; +ejecutar "make coccicheck" ejecutará esos parches semánticos e informará +sobre cualquier problema encontrado. Consulte: +ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>` para +obtener más información. + +Otros tipos de errores de portabilidad se encuentran mejor compilando su +código para otras arquitecturas. Si no tiene un sistema S/390 o una placa +de desarrollo Blackfin a mano, aún puede realizar el paso de compilación. +Un gran conjunto de compiladores cruzados para sistemas x86 se puede +encontrar en + + https://www.kernel.org/pub/tools/crosstool/ + +Muchos sistemas de compilación disponibles comercialmente también se pueden +utilizar para compilar código de kernel para una amplia gama de +arquitecturas. + +Los desarrolladores del kernel son afortunados: tienen acceso a una +variedad de herramientas de verificación de código de la que los +desarrolladores de la mayoría de los otros sistemas pueden estar celosos. +Pero todas esas herramientas no servirán de nada si no las usa. El +resultado final de ignorar estas herramientas es simple: alguien más puede +notificarle de un problema en su código a través de un "oportuno" +comentario en la lista de correo o, peor aún, el código problemático podría +ser eliminado. Es mucho más fácil usar estas herramientas en primer lugar. + +Documentación +************* + +La documentación a menudo ha sido más la excepción que la regla en el +desarrollo del kernel. Aun así, una documentación adecuada ayudará a +facilitar la integración de nuevo código en el kernel, hará la vida más +fácil a otros desarrolladores, y será útil para sus usuarios. En muchos +casos, la inclusión de documentación se ha vuelto esencialmente +obligatoria. + +La primera pieza de documentación para cualquier parche es su changelog +asociado. Las entradas de registro deben describir el problema que se está +esolviendo, la forma de la solución, las personas que trabajaron en el +parche, cualquier efecto relevante en el rendimiento, y cualquier otra cosa +que pueda ser necesaria para entender el parche. Asegúrese de que el +changelog diga *por qué* el parche vale la pena ser aplicado; un +sorprendente número de desarrolladores no proporciona esa información. + +Cualquier código que agregue una nueva interfaz para el espacio de usuario, +incluidos los nuevos archivos de sysfs o /proc, debe incluir documentación +de esa interfaz que permita a los desarrolladores del espacio de usuario +saber con qué están trabajando. Consulte `Documentation/ABI/README` para +una descripción de cómo debe formatearse esta documentación y qué +información debe proporcionarse. + +El archivo +:ref:`Documentation/admin-guide/kernel-parameters.rst <kernelparameters>` +describe todos los parámetros de arranque del kernel. Cualquier parche que +agregue nuevos parámetros debe agregar las entradas correspondientes a este +archivo. + +Cualquier nueva opción de configuración debe ir acompañada de un texto de +ayuda que explique claramente las opciones y cuándo el usuario podría +querer seleccionarlas. + +La información de la API interna para muchos subsistemas está documentada +mediante comentarios especialmente formateados; estos comentarios pueden +extraerse y formatearse de diversas maneras mediante el script +"kernel-doc". Si está trabajando dentro de un subsistema que tiene +comentarios de kerneldoc, debe mantenerlos y agregarlos según corresponda +para las funciones disponibles externamente. Incluso en áreas que no han +sido tan documentadas, no hay ningún inconveniente en agregar comentarios +de kerneldoc para el futuro; de hecho, esta puede ser una actividad útil +para desarrolladores de kernel principiantes. El formato de estos +comentarios, junto con alguna información sobre cómo crear plantillas de +kerneldoc, se puede encontrar en +:ref:`Documentation/doc-guide/ <doc_guide>`. + +Cualquiera que lea una cantidad significativa de código existente del +kernel notará que, a menudo, los comentarios son notables por su ausencia. +Una vez más, las expectativas para el nuevo código son más altas que en el +pasado; integrar código sin comentarios será más difícil. Dicho esto, hay +poco deseo de tener código excesivamente comentado. El código en sí debe +ser legible, con comentarios que expliquen los aspectos más sutiles. + +Ciertas cosas siempre deben comentarse. El uso de barreras de memoria debe +ir acompañado de una línea que explique por qué la barrera es necesaria. +Las reglas de bloqueo para las estructuras de datos generalmente necesitan +explicarse en algún lugar. Las estructuras de datos importantes en general +necesitan documentación completa. Las dependencias no obvias entre +fragmentos de código separados deben señalarse. Cualquier cosa que pueda +tentar a un maintainer de código a hacer una "limpieza" incorrecta necesita +un comentario que explique por qué se hace de esa manera. Y así +sucesivamente. + +Cambios en la API interna +************************* + +La interfaz binaria proporcionada por el kernel al espacio de usuario no se +puede romper, excepto en las circunstancias más graves. Las interfaces de +programación internas del kernel, en cambio, son altamente fluidas y pueden +cambiarse cuando surge la necesidad. Si usted se encuentra teniendo que +hacer un rodeo alrededor de una API del kernel, o simplemente no utilizando +una funcionalidad específica porque no cumple con sus necesidades, eso +puede ser una señal de que la API necesita cambiar. Como desarrollador del +kernel, usted está autorizado a hacer esos cambios. + +Hay, por supuesto, algunas condiciones. Los cambios en la API se pueden +hacer, pero necesitan estar bien justificados. Entonces, cualquier parche +que realice un cambio en la API interna debe ir acompañado de una +descripción de cuál es el cambio y por qué es necesario. Este tipo de +cambio también debe desglosarse en un parche separado, en lugar de estar +enterrado dentro de un parche más grande. + +La otra condición es que un desarrollador que cambia una API interna +generalmente está encargado de la tarea de corregir cualquier código dentro +del árbol del kernel que se vea afectado por el cambio. Para una función +ampliamente utilizada, este deber puede llevar a literalmente cientos o +miles de cambios, muchos de los cuales probablemente entren en conflicto +con el trabajo que otros desarrolladores están realizando. No hace falta +decir que esto puede ser un trabajo grande, por lo que es mejor asegurarse +de que la justificación sea sólida. Tenga en cuenta que la herramienta +Coccinelle puede ayudar con los cambios de API a gran escala. + +Cuando se realice un cambio incompatible en la API, siempre que sea +posible, se debe asegurar que el código que no ha sido actualizado sea +detectado por el compilador. Esto le ayudará a estar seguro de que ha +encontrado todos los usos en el árbol de esa interfaz. También alertará a +los desarrolladores de código fuera del árbol de que hay un cambio al que +necesitan responder. Apoyar el código fuera del árbol no es algo de lo que +los desarrolladores del kernel deban preocuparse, pero tampoco tenemos que +dificultarles la vida más de lo necesario. diff --git a/Documentation/translations/sp_SP/process/5.Posting.rst b/Documentation/translations/sp_SP/process/5.Posting.rst index 50a3bc5998a8..9e2ac9fdd63d 100644 --- a/Documentation/translations/sp_SP/process/5.Posting.rst +++ b/Documentation/translations/sp_SP/process/5.Posting.rst @@ -1,11 +1,391 @@ .. include:: ../disclaimer-sp.rst :Original: Documentation/process/5.Posting.rst +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com> .. _sp_development_posting: -Publicar parches -================ +Publicación de parches +====================== -.. warning:: - TODO aún no traducido +Tarde o temprano, llega el momento en que su trabajo esté listo para ser +presentado a la comunidad para su revisión y, eventualmente, su inclusión +en el kernel mainline. Como era de esperar, la comunidad de desarrollo del +kernel ha desarrollado un conjunto de convenciones y procedimientos que se +utilizan en la publicación de parches; seguirlos hará la vida mucho más +fácil para todos los involucrados. Este documento intentará cubrir estas +expectativas con un detalle razonable; también se puede encontrar más +información en los archivos. +:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>` +and :ref:`Documentation/translations/sp_SP/process/submit-checklist.rst <sp_submitchecklist>` + +Cuando publicar +--------------- + +Hay una tentación constante de evitar publicar parches antes de que +estén completamente “listos”. Para parches simples, eso no es un +problema. Sin embargo, si el trabajo que se está realizando es complejo, +hay mucho que ganar al obtener comentarios de la comunidad antes de que +se complete el trabajo. Por lo tanto, se debería considerar publicar +trabajo en progreso, o incluso poner a disposición un árbol de git para +que los desarrolladores interesados puedan ponerse al día con su trabajo +en cualquier momento. + +Al publicar código que aún no se considera listo para su inclusión, es +una buena idea decirlo en la propia publicación. Además, mencione +cualquier trabajo importante que aún falte por hacer y cualquier problema +conocido. Menos personas mirarán los parches que se sabe que están a +medias, pero aquellos que lo hagan vendrán con la idea de que pueden +ayudarlo a llevar el trabajo en la dirección correcta. + +Antes de crear parches +---------------------- + +Se deben hacer varias cosas antes de considerar enviar parches a la +comunidad de desarrollo. Estas incluyen: + + - Pruebe el código en la medida de lo posible. Utilice las herramientas + de depuración del kernel, asegúrese de que el kernel se compilará con + todas las combinaciones razonables de opciones de configuración, use + compiladores cruzados para compilar para diferentes arquitecturas, etc. + + - Asegúrese de que su código cumpla con las directrices de estilo de + codificación del kernel. + + - ¿Su cambio tiene implicaciones de rendimiento? Si es así, debe ejecutar + puntos de referencia que muestren cuál es el impacto (o beneficio) de + su cambio; se debe incluir un resumen de los resultados con el parche. + + - Asegúrese de que tiene derecho a publicar el código. Si este trabajo + se realizó para un empleador, es probable que el empleador tenga + derecho al trabajo y debe estar de acuerdo con su lanzamiento bajo la + GPL. + +Como regla general, pensar un poco más antes de publicar el código casi +siempre compensa el esfuerzo en poco tiempo. + +Preparación del parche +---------------------- + +La preparación de parches para su publicación puede ser una cantidad +sorprendente de trabajo, pero, una vez más, intentar ahorrar tiempo aquí +generalmente no es recomendable, ni siquiera a corto plazo. + +Los parches deben prepararse contra una versión específica del kernel. +Como regla general, un parche debe basarse en el mainline actual que se +encuentra en el árbol git de Linus. Al basarse en el mainline, comience +con un punto de lanzamiento bien conocido, una versión estable o -rc, en +lugar de bifurcarse fuera del mainline en un punto arbitrario. + +Puede ser necesario hacer revisiones contra -mm, linux-next o un árbol de +subsistemas para facilitar pruebas y revisiones más amplias. Dependiendo +del área de su parche y de lo que esté sucediendo en otros lugares, basar +un parche en estos otros árboles puede requerir una cantidad significativa +de trabajo para resolver conflictos y lidiar con los cambios de API. + +Solo los cambios más simples deben formatearse como un solo parche; todo +lo demás debe hacerse como una serie lógica de cambios. Dividir parches +es un poco un arte; algunos desarrolladores pasan mucho tiempo averiguando +cómo hacerlo de la manera que la comunidad espera. Sin embargo, hay +algunas reglas generales que pueden ayudar considerablemente: + + - La serie de parches que publique casi seguramente no será la serie de + cambios que se encuentran en su sistema de control de revisiones. En su + lugar, los cambios que ha realizado deben considerarse en su forma + final y luego dividirse de manera que tengan sentido. A los + desarrolladores les interesan los cambios discretos y autónomos, no el + camino que tomó para llegar a esos cambios. + + - Cada cambio lógicamente independiente debe formatearse como un parche + separado. Estos cambios pueden ser pequeños (“agregar un campo a esta + estructura”) o grandes (agregar un nuevo controlador significativo, + por ejemplo), pero deben ser conceptualmente pequeños y susceptibles + de una descripción de una línea. Cada parche debe hacer un cambio + especifico que pueda ser revisado por sí mismo y verificado para hacer + lo que dice que hace. + + - Para reafirmar la pauta anterior: no mezcle diferentes tipos de cambios + en el mismo parche. Si un solo parche corrige un error de seguridad + crítico, reorganiza algunas estructuras y reformatea el código, es muy + probable que se pase por alto y se pierda la solución importante. + + - Cada parche debe producir un kernel que se compile y funcione + correctamente; si su serie de parches se interrumpe en el medio, el + resultado debería seguir siendo un kernel funcional. La aplicación + parcial de una serie de parches es un escenario común cuando se + utiliza la herramienta “git bisect” para encontrar regresiones; si + el resultado es un kernel roto, hará la vida más difícil para los + desarrolladores y usuarios que participan en el noble trabajo de + rastrear problemas. + + - Sin embargo, no lo exagere. Un desarrollador una vez publicó un conjunto + de ediciones en un solo archivo como 500 parches separados – un acto + que no lo convirtió en la persona más popular en la lista de correo del + kernel. Un solo parche puede ser razonablemente grande si todavía + contiene un solo cambio *lógico*. + + - Puede ser tentador agregar una infraestructura completamente nueva con + una serie de parches, pero dejar esa infraestructura sin usar hasta el + parche final de la serie lo habilite todo. Esta tentación debe evitarse + si es posible; si esa serie agrega regresiones, bisection señalará el + ultimo parche como el que causó el problema, aunque el error real esté + en otra parte. Siempre que sea posible, un parche que agregue código + nuevo debe hacer que ese código se active de inmediato. + +Trabajar para crear la serie de parches perfecta puede ser un proceso +frustrante que lleva mucho tiempo y reflexión después de que el “trabajo +real” se ha hecho. Sin embargo, cuando se hace correctamente, es un tiempo +bien empleado. + +Formato de parches y registros de cambios +----------------------------------------- + +Así que ahora tiene una serie perfecta de parches para publicar, pero el +trabajo aún no se ha hecho. Cada parche necesita ser formateado en un +mensaje que comunique rápida y claramente su propósito al resto del +mundo. A tal fin, cada parche se compondrá de lo siguiente: + + - Una línea opcional “From” que nombra al autor del parche. Esta línea + solo es necesaria si pasa el parche de otra persona por correo + electrónico, pero nunca está de más agregarla en caso de duda. + + - Una descripción de una línea de lo que hace el parche. Este mensaje + debería ser suficiente para que un lector que lo vea sin otro contexto + pueda entender el alcance del parche; la línea aparecerá en los + registros de cambios de “forma corta”. Este mensaje generalmente se + formatea con el nombre del subsistema relevante primero, seguido del + propósito del parche. Por ejemplo: + + :: + + gpio: fix build on CONFIG_GPIO_SYSFS=n + + - Una línea en blanco seguida de una descripción detallada del contenido + del parche. Esta descripción puede ser tan larga como sea necesario; + debería decir qué hace el parche y por qué debe aplicarse al kernel. + + - Una o más líneas de etiquetas, con, como mínimo, una línea + Signed-off-by: del autor del parche. Las etiquetas se describirán con + más detalle a continuación. + +Los elementos de arriba, juntos, forman el registro de cambios para el +parche. Escribir buenos registros de cambios es un arte crucial, pero a +menudo descuidado; vale la pena pasar otro momento discutiendo este tema. +Al escribir un registro de cambios, debe recordar que muchas personas +diferentes leerán sus palabras. Estos incluyen a los maintainers y +revisores de subsistemas que necesitan decidir si el parche debe +incluirse, a los distribuidores y otros maintainers que intentan +determinar si un parche debe ser “backported” a otros kernels, a los +cazadores de errores que se preguntan si el parche es responsable de un +problema que están persiguiendo, a los usuarios que quieren saber cómo +ha cambiado el kernel, y más. Un buen registro de cambios transmite la +información necesaria a todas estas personas de la forma más directa y +concisa posible. + +Con ese fin, la línea de resumen debe describir los efectos y la +motivación del cambio, así como lo mejor posible dada la restricción de +una línea. La descripción detallada puede ampliar esos temas y +proporcionar cualquier información adicional necesaria. Si el parche +corrige un error, cita el commit que introdujo el error si es posible (y +por favor, proporcione tanto el ID del commit como el título al citar +commits). Si un problema está asociado con un registro específico o la +salida del compilador, incluya esa salida para ayudar a otros usuarios a +buscar una solución al mismo problema. Si el cambio está destinado a +apoyar otros cambios que llegarán en un parche posterior, dígalo. Si se +cambian las API internas, detalle esos cambios y cómo deben responder +otros desarrolladores. En general, cuanto más pueda ponerse en los zapatos +de todos los que leerán su registro de cambios, mejor será ese registro de +cambios (y el kernel en su conjunto). + +No hace falta decir que el registro de cambios debe ser el texto utilizado +al realizar el commit en un sistema de control de revisiones. Será seguido +por: + + - El parche, en el formato unificado de parche (“-u”). Usar la opción + “-p” en diff asociará los nombres de las funciones con los cambios, lo + que hará que el parche resultante sea más fácil de leer para otros. + +Debe evitar incluir cambios en archivos irrelevantes (los generados por +el proceso de compilación, por ejemplo, o los archivos de respaldo del +editor) en el parche. El archivo “dontdiff” en el directorio de +Documentation puede ayudar en este sentido; páselo a diff con la +opción “-X”. + +Las etiquetas ya mencionadas brevemente anteriormente proporcionan +información sobre cómo surgió el parche. Se describen en detalle en el +documento +:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`; +lo que sigue aquí es un breve resumen. + +Una etiqueta se usa para referirse a commits anteriores que introdujeron +problemas corregidos por el parche:: + + Fixes: 1f2e3d4c5b6a ("La primera línea del commit especificada por los primeros 12 caracteres de su ID SHA-1.") + +Otra etiqueta se utiliza para vincular páginas web con información +adicional o detalles, por ejemplo, una discusión previa que condujo al +parche o un documento con una especificación implementada por el parche:: + + Link: https://example.com/somewhere.html otras cosas opcionales + +Muchos maintainers, al aplicar un parche, también agregan esta etiqueta +para vincular a la última publicación de revisión pública del parche; a +menudo, eso se hace automáticamente mediante herramientas como b4 o git +hook como el que se describe en +'Documentation/maintainer/configure-git.rst'. + +Si la URL apunta a un informe de error público que está siendo corregido +por el parche, use la etiqueta “Closes:” (Cierra) en su lugar:: + + Closes: https://example.com/issues/1234 otras cosas opcionales + +Algunos rastreadores de errores tienen la capacidad de cerrar problemas +automáticamente cuando se aplica un commit con tal etiqueta. Algunos bots +que monitorean listas de correo también pueden rastrear dichas etiquetas +y realizar ciertas acciones. Los rastreadores de errores privados y las +URL no válidas están prohibidos. + +Otro tipo de etiqueta se utiliza para documentar quién estuvo involucrado +en el desarrollo del parche. Cada uno de estos utiliza este formato:: + + tag: Full Name <email address> otras cosas opcionales + +Las etiquetas de uso común son: + + - Signed-off-by: esta es una certificación del desarrollador de que él + o ella tiene el derecho de enviar el parche para su inclusión en el + kernel. Es un acuerdo con el Certificado de Origen del Desarrollador, + que se encuentra en + :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`. + El código sin la firma adecuada no se puede fusionar en el mainline. + + - Co-developed-by: indica que el parche fue co-creado por varios + desarrolladores; se utiliza para atribuir a los coautores (además del + autor atribuido por la etiqueta From:) cuando varias personas trabajan + en un solo parche. Cada Co-developed-by: debe ir seguido inmediatamente + por un Signedoff-by: del coautor asociado. Los detalles y ejemplos se + pueden encontrar en + :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`. + + - Acked-by: indica un acuerdo por parte de otro desarrollador (a menudo + un maintainer del código relevante) de que el parche es apropiado para + su inclusión en el kernel. + + - Tested-by: indica que la persona nombrada ha probado el parche y ha + encontrado que funciona. + + - Reviewed-by: el desarrollador nombrado ha revisado el parche para + verificar que sea correcto; consulte la declaración del revisor en + :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>` + para obtener más detalles. + + - Reported-by: nombra a un usuario que informó un problema que se + soluciona con este parche; esta etiqueta se utiliza para dar crédito + a las personas (a menudo infravalorada) que prueban nuestro código y + nos hacen saber cuándo las cosas no funcionan correctamente. Tenga en + cuenta que esta etiqueta debe ir seguida de una etiqueta Closes: que + apunte al informe, a menos que el informe no esté disponible en la + web. La etiqueta Link: se puede usar en lugar de Closes: si el parche + corrige una parte de los problemas reportados. + + - Cc: la persona nombrada recibió una copia del parche y tuvo la + oportunidad de comentar sobre él. + +Tenga cuidado al agregar etiquetas a sus parches, ya que solo Cc: es +apropiado para la adición sin el permiso explícito de la persona nombrada; +usar Reported-by: está casi bien en su mayoría, pero pida permiso si el +error fue reportado en privado. + +Envió del parche +---------------- + +Antes de enviar sus parches por correo, hay un par de cosas más de las +que debe ocuparse: + + - ¿Está seguro de que su correo no corromperá los parches? Los parches + con cambios gratuitos de espacio en blanco o ajuste de línea + realizados por el cliente de correo no se aplicarán en el otro + extremo, y a menudo, no se examinarán en detalle. Si tiene alguna + duda, envíese el parche por correo y convénzase de que parece + intacto. + + :ref:`Documentation/translations/sp_SP/process/email-clients.rst <sp_email_clients>` + tiene algunos consejos útiles sobre cómo hacer que clientes de correo + específicos funcionen para enviar parches. + + - ¿Está seguro de que su parche está libre de errores tontos? Siempre + debe ejecutar parches a través de scripts/checkpatch.pl y abordar las + quejas que surjan. Por favor, tenga en cuenta que checkpatch.pl, aunque + es la encarnación de una buena cantidad de pensamiento sobre cómo + deberían ser los parches del kernel, no es más inteligente que usted. + Si corregir una queja de checkpatch.pl empeoraría el código, no lo + haga. + +Los parches siempre deben enviarse como texto sin formato. Por favor, no +los envíe como archivos adjuntos; eso hace que sea mucho más difícil para +los revisores citar secciones del parche en sus respuestas. En su lugar, +simplemente coloca el parche directamente en su mensaje. + +Al enviar parches por correo, es importante enviar copias a cualquier +persona que pueda estar interesada en ellos. A diferencia de otros +proyectos, el kernel anima a la gente a equivocarse por el lado de enviar +demasiadas copias; no asuma que las personas relevantes verán su +publicación en las listas de correo. En particular, las copias deben +ir a: + + - El (los) maintainer(s) del (de los) subsistema(s) afectado(s). Como se + describió anteriormente, el archivo MAINTAINERS es el primer lugar para + buscar a estas personas. + + - Otros desarrolladores que han estado trabajando en la misma + área – especialmente aquellos que podrían estar trabajando allí ahora. + Usar git para ver quién más ha modificado los archivos en los que está + trabajando puede ser útil. + + - Si está respondiendo a un informe de error o a una solicitud de + función, copie también al autor. + + - Envié una copia a la lista de correo relevante o, si no se aplica nada + más, a la lista de linux-kernel. + + - Si está corrigiendo un error, piense si la corrección debe incluirse en + la próxima actualización estable. Si es así, stable@vger.kernel.org + debería obtener una copia del parche. También agregue un + "Cc: stable@vger.kernel.org" a las etiquetas dentro del parche; eso + hará que el equipo estable reciba una notificación cuando su solución + incluya en el mainline. + +Al seleccionar destinatarios para un parche, es bueno saber quién cree que +eventualmente aceptará el parche y lo fusionará. Aunque es posible enviar +parches directamente a Linus Torvalds y hacer que los fusione, las cosas +normalmente no se hacen de esa manera. Linus está ocupado y hay +maintainers de subsistemas que vigilan partes específicas del kernel. +Generalmente, querrá que ese maintainer fusione sus parches. Andrew Morton +es a menudo el objetivo del parche de último recurso si no hay un +maintainer obvio. + +Los parches necesitan buenas líneas de asunto. El formato canónico de una +línea de parche es algo así como: + +:: + + [PATCH nn/mm] subsys: descripción en una línea del parche + +donde “nn” es el número ordinal del parche, “”mm” es el número total de +parches en la serie, y “subsys” es el nombre del subsistema afectado. +Claramente, nn/mm se puede omitir para un parche único e independiente. + +Si tiene una serie significativa de parches, es costumbre enviar una +descripción introductoria como parte cero. Sin embargo, esta convención no +se sigue universalmente; si la utiliza, recuerde que la información en la +introducción no se incluye en los registros de cambios del kernel. Por lo +tanto, asegúrese de que los parches, en sí mismos, tengan información +completa del registro de cambios. + +En general, la segunda y las siguientes partes de un parche de varias +partes deben enviarse como una respuesta a la primera parte para que todas +se hilen juntas en el extremo receptor. Herramientas como git y quilt +tienen comandos para enviar por correo un conjunto de parches con el +subproceso adecuado. Sin embargo, si tiene una serie larga y está usando +git, por favor evite la opción –chain-reply-to para evitar crear un +anidamiento excepcionalmente profundo. diff --git a/Documentation/translations/sp_SP/process/6.Followthrough.rst b/Documentation/translations/sp_SP/process/6.Followthrough.rst index f0acf9082bb3..083898af46f5 100644 --- a/Documentation/translations/sp_SP/process/6.Followthrough.rst +++ b/Documentation/translations/sp_SP/process/6.Followthrough.rst @@ -1,11 +1,230 @@ .. include:: ../disclaimer-sp.rst :Original: Documentation/process/6.Followthrough.rst +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com> .. _sp_development_followthrough: Seguimiento =========== -.. warning:: - TODO aún no traducido +Llegados a este punto, ha seguido las directrices dadas hasta ahora, lo que +sumado a sus propias habilidades de ingeniería, ha resultado en una serie +de parches perfectos. Uno de los mayores errores que incluso los +desarrolladores de kernel experimentados pueden cometer es concluir que su +trabajo ya está hecho. En verdad, publicar parches indica una transición a +la siguiente etapa del proceso, con, posiblemente, bastante trabajo aún por +hacer. + +Es raro un parche que sea tan bueno en su primera publicación que no haya +espacio para la mejora. El proceso de desarrollo del kernel reconoce este +hecho y, como resultado, está muy orientado hacia la mejora del código +publicado. Y usted, como autor de ese código, se espera que trabaje con la +comunidad del kernel para asegurarse de que su código esté a la altura de +los estándares de calidad del kernel. No participar en este proceso es muy +probable que impida la inclusión de sus parches en la línea principal. + +Trabajando con revisores +------------------------ + +Un parche de cualquier importancia resultará en una serie de comentarios de +otros desarrolladores a medida que revisan el código. Trabajar con los +revisores puede ser, para muchos desarrolladores, la parte más intimidante +del proceso de desarrollo del kernel. Sin embargo, la vida puede ser mucho +más fácil si tiene en cuenta algunas cosas: + +- Si ha explicado bien su parche, los revisores entenderán su valor y por + qué se tomó la molestia de escribirlo. Pero ese valor no les impedirá + hacer una pregunta fundamental: ¿cómo será mantener un kernel con este + código en él cinco o diez años después? Muchos de los cambios que se le + pueden pedir que haga, desde ajustes de estilo de codificación hasta + reescrituras sustanciales, provienen de la comprensión de que Linux + seguirá existiendo y en desarrollo dentro de una década. + +- La revisión de código es un trabajo arduo y es una ocupación + relativamente ingrata; la gente recuerda quién escribió el código del + kernel, pero hay poca fama duradera para aquellos que lo revisaron. Así + que los revisores pueden ponerse de mal humor, especialmente cuando ven + los mismos errores repetirse una y otra vez. Si recibe una revisión que + parece enojada, insultante o abiertamente ofensiva, resista el impulso de + responder de la misma manera. La revisión de código se trata del código, + no de las personas, y los revisores de código no lo están atacando + personalmente. + +- De manera similar, los revisores de código no están tratando de promover + las agendas de sus empleadores a expensas de la suya. Los desarrolladores + del kernel a menudo esperan estar trabajando en el kernel dentro de + varios años, pero entienden que su empleador podría cambiar. + Verdaderamente, casi sin excepción, están trabajando hacia la creación + del mejor kernel posible; no están tratando de causar incomodidad a los + competidores de sus empleadores. + +- Esté preparado para solicitudes aparentemente ridículas de cambios en el + estilo de codificación y solicitudes para factorizar parte de su código + en partes compartidas del kernel. Una de las tareas que realizan los + maintainers es mantener las cosas con una apariencia uniforme. A veces, esto significa que el truco ingenioso en su driver para sortear un problema necesita convertirse en una característica generalizada del kernel lista para la próxima vez. + +En resumen, cuando los revisores le envían comentarios, necesita prestar +atención a las observaciones técnicas que están haciendo. No permita que su +forma de expresarse o su propio orgullo le impidan hacerlo. Cuando reciba +comentarios de revisión sobre un parche, tómese el tiempo para entender lo +que el revisor está tratando de decir. Si es posible, arregle las cosas que +el revisor le está pidiendo que corrija. Y responda al revisor: +agradézcales y describa cómo responderá a sus preguntas. + +Tenga en cuenta que no tiene que estar de acuerdo con cada cambio sugerido +por los revisores. Si cree que el revisor ha malinterpretado su código, +explique lo que realmente está sucediendo. Si tiene una objeción técnica a +un cambio sugerido, descríbalo y justifique su solución al problema. Si sus +explicaciones tienen sentido, el revisor las aceptará. Sin embargo, si su +explicación no resulta persuasiva, especialmente si otros comienzan a estar +de acuerdo con el revisor, tómese un tiempo para reflexionar nuevamente +sobre las cosas. Puede ser fácil quedar cegado por su propia solución a un +problema hasta el punto de no darse cuenta de que algo está +fundamentalmente mal o, quizás, ni siquiera está resolviendo el problema +correcto. + +Andrew Morton ha sugerido que cada comentario de revisión que no resulte en +un cambio de código debería resultar en un comentario adicional en el +código; eso puede ayudar a los revisores futuros a evitar las preguntas que +surgieron la primera vez. + +Un error fatal es ignorar los comentarios de revisión con la esperanza de +que desaparezcan. No desaparecerán. Si vuelve a publicar código sin haber +respondido a los comentarios que recibió la vez anterior, es probable que +descubra que sus parches no van a ninguna parte. + +Hablando de volver a publicar código: tenga en cuenta que los revisores no +recordarán todos los detalles del código que publicó la vez anterior. Así +que siempre es una buena idea recordarles sobre problemas planteados +anteriormente y cómo los manejó; el registro de cambios del parche es un +buen lugar para este tipo de información. Los revisores no deberían tener +que buscar en los archivos de la lista para familiarizarse con lo que se +dijo la última vez; si les ayuda a tener un buen comienzo, estarán de mejor +humor cuando revisiten su código. + +¿Qué sucede si ha intentado hacer todo bien y las cosas aún no van a +ninguna parte? La mayoría de los desacuerdos técnicos pueden resolverse +mediante discusión, pero hay momentos en los que alguien simplemente tiene +que tomar una decisión. Si realmente cree que esta decisión está en su +contra de manera incorrecta, siempre puede intentar apelar a una autoridad +superior. En el momento de escribir esto, esa autoridad superior tiende a +ser Andrew Morton. Andrew tiene un gran respeto en la comunidad de +desarrollo del kernel; a menudo puede desbloquear una situación que parece +estar irremediablemente bloqueada. Sin embargo, apelar a Andrew no debe +hacerse a la ligera, y no antes de que se hayan explorado todas las demás +alternativas. Y tenga en cuenta, por supuesto, que él puede no estar de +acuerdo con usted tampoco. + +¿Qué pasa después? +-------------------- + +Si un parche se considera algo bueno para agregar al kernel, y una vez que +se hayan resuelto la mayoría de los problemas de revisión, el siguiente +paso suele ser la entrada en el árbol del mantenedor de un subsistema. Cómo +funciona eso varía de un subsistema a otro; cada mantenedor tiene su propia +forma de hacer las cosas. En particular, puede haber más de un árbol, uno, +quizás, dedicado a los parches planificados para la próxima ventana de +fusión y otro para trabajos a más largo plazo. + +Para los parches que se aplican a áreas para las que no hay un árbol de +subsistema obvio (parches de gestión de memoria, por ejemplo), el árbol +predeterminado suele ser -mm. Los parches que afectan a múltiples +subsistemas también pueden terminar pasando por el árbol -mm. + +La inclusión en un árbol de subsistema puede dar mayor visibilidad a un +parche. Ahora, otros desarrolladores que trabajan con ese árbol recibirán +el parche por defecto. Los árboles de subsistemas típicamente alimentan +linux-next también, haciendo que su contenido sea visible para la comunidad +de desarrollo en su conjunto. En este punto, hay una buena probabilidad de +que reciba más comentarios de un nuevo conjunto de revisores; estos +comentarios necesitan ser respondidos como en la ronda anterior. + +Lo que también puede suceder en este punto, dependiendo de la naturaleza de +su parche, es que aparezcan conflictos con el trabajo que están realizando +otros. En el peor de los casos, conflictos pesados de parches pueden +resultar en que algunos trabajos se pongan en espera para que los parches +restantes puedan ser ajustados y fusionados. Otras veces, la resolución de +conflictos involucrará trabajar con otros desarrolladores y, posiblemente, +mover algunos parches entre árboles para asegurarse de que todo se aplique +sin problemas. Este trabajo puede ser un dolor, pero cuente sus +bendiciones: antes de la llegada del árbol linux-next, estos conflictos a +menudo solo surgían durante la ventana de fusión y tenían que ser abordados +de prisa. Ahora pueden resolverse con calma, antes de que se abra la +ventana de fusión (merge window). + +Algún día, si todo va bien, iniciará sesión y verá que su parche ha sido +incluido en el kernel principal. ¡Felicidades! Una vez que la celebración +termine (y se hayas agregado al archivo MAINTAINERS), vale la pena +recordar un pequeño hecho importante: el trabajo aún no está hecho. La +inclusión trae sus propios desafíos. + +Para empezar, la visibilidad de su parche ha aumentado una vez más. Puede +haber una nueva ronda de comentarios de desarrolladores que no estaban al +tanto del parche antes. Puede ser tentador ignorarlos, ya que ya no hay +cuestión de que su código sea fusionado. Sin embargo, resista esa +tentación; aún necesita ser receptivo a los desarrolladores que tienen +preguntas o sugerencias. + +Más importante aún, la inclusión en la línea principal pone su código en +manos de un grupo mucho más grande de probadores. Incluso si ha contribuido +un driver para hardware que aún no está disponible, se sorprenderá de +cuántas personas construirán su código en sus kernels. Y, por supuesto, +donde hay probadores, habrá informes de errores. + +El peor tipo de informes de errores son las regresiones. Si su parche causa +una regresión, encontrará un número incómodo de ojos sobre usted; las +regresiones pueden dar lugar a mucho malestar en la comunidad y pueden +hacer que algunos desarrolladores comiencen a preguntarse si su parche +realmente debería haber sido fusionado en primer lugar. Así que esté atento +a los comentarios sobre problemas y, si es posible, corrija los errores de +inmediato. + +Después de haber abordado cualquier regresión, puede haber otros errores +ordinarios que resolver. El período de estabilización es su mejor +oportunidad para corregir estos errores y garantizar que el debut de su +código en una versión del kernel principal sea lo más sólido posible. Así +que, por favor, responda a los informes de errores y solucione los +problemas si es posible. Para eso es el período de estabilización; puede +comenzar a crear parches nuevos y geniales una vez que se hayan resuelto +los problemas de los antiguos. + +Y no olvide que hay otros hitos que también pueden generar informes de +errores: la próxima versión estable del kernel principal, cuando +distribuidores prominentes adopten una versión del kernel que contenga su +parche, etc. Continuar respondiendo a estos informes es una cuestión de +orgullo básico en su trabajo. Sin embargo, si eso no es suficiente +motivación, también vale la pena considerar que la comunidad de desarrollo +recuerda a los desarrolladores que pierden interés en su código después de +que se fusiona. La próxima vez que publique un parche, lo evaluarán con la +suposición de que no estará disponible para mantenerlo después. + +Otras cosas que pueden suceder +------------------------------- + +Un día, puede que abra su cliente de correo y vea que alguien le ha enviado +un parche para su código. Esa es una de las ventajas de tener su código +disponible públicamente, después de todo. Si está de acuerdo con el parche, puede reenviarlo al maintainer del subsistema (asegúrese de incluir una +línea From: adecuada para que la atribución sea correcta, y añada su propia +firma), o enviar una respuesta Acked-by: y dejar que el autor original lo +envíe hacia arriba. + +Si no está de acuerdo con el parche, envíe una respuesta educada explicando +por qué. Si es posible, dígale al autor qué cambios deben hacerse para que +considere el parche aceptable. Existe una cierta resistencia a incluir +parches que son rechazados por el autor y el maintainer del código, pero +esto tiene un límite. Si se interpreta que bloque buen trabajo, esos +parches eventualmente lo eludirán y se incorporarán al kernel de todos +modos. En el kernel de Linux, nadie tiene poder de veto absoluto sobre +ningún código. Excepto quizás Linus. + +En muy raras ocasiones, puede encontrar algo completamente diferente: otro +desarrollador publica una solución distinta a su problema. En ese punto, es +probable que uno de los dos parches no se incluya, y "el mío fue el +primero" no se considera un argumento técnico convincente. Si el parche de +otra persona desplaza al suyo y se incorpora al kernel, realmente solo hay +una manera de responder: alegrarse de que su problema se haya resuelto y +continuar con su trabajo. Que su trabajo sea desplazado de esta manera +puede ser doloroso y desalentador, pero la comunidad recordará su reacción +mucho después de que hayan olvidado de quién era el parche que realmente se +incluyó. diff --git a/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst b/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst index 553759857339..42cb8b866e11 100644 --- a/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst +++ b/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst @@ -1,11 +1,214 @@ .. include:: ../disclaimer-sp.rst :Original: Documentation/process/7.AdvancedTopics.rst +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com> .. _sp_development_advancedtopics: Temas avanzados =============== -.. warning:: - TODO aún no traducido +Llegados a este punto, con suerte, tiene una idea de cómo funciona el +proceso de desarrollo. Sin embargo, ¡todavía hay más que aprender! Esta +sección cubrirá varios temas que pueden ser útiles para los desarrolladores +que desean convertirse en una parte regular del proceso de desarrollo del +kernel Linux. + +Gestionar parches con git +------------------------- + +El uso del control de versiones distribuido para el kernel comenzó a +principios de 2002 cuando Linus comenzó a jugar con la aplicación +propietaria BitKeeper. Aunque BitKeeper fue controvertido, el enfoque de +la gestión de versiones de software que incorporó ciertamente no lo fue. +El control de versiones distribuido permitió una aceleración inmediata +del proyecto de desarrollo del kernel. En los tiempos actuales, existen +varias alternativas gratuitas a BitKeeper. Para bien o para mal, el +proyecto del kernel ha optado por git como su herramienta preferida. + +Administrar parches con git puede hacer la vida mucho más fácil para el +desarrollador, especialmente a medida que crece el volumen de esos +parches. Git también tiene sus asperezas y representa ciertos peligros; +es una herramienta joven y poderosa que aún está siendo civilizada por +sus desarrolladores. Este documento no intentará enseñar al lector cómo +usar git; eso sería material suficiente para un documento extenso por +derecho propio. En su lugar, el enfoque aquí será cómo git encaja en el +proceso de desarrollo del kernel en particular. Los desarrolladores que +deseen ponerse al día con git encontrarán más información en: + + https://git-scm.com/ + + https://www.kernel.org/pub/software/scm/git/docs/user-manual.html + +y en varios tutoriales que se encuentran en la web. + +El primer orden del negocio es leer los sitios mencionados anteriormente +y comprender cómo funciona git antes de intentar usarlo para poner +parches a disposición de otros. Un desarrollador que usa git debe ser +capaz de obtener una copia del repositorio mainline, explorar el historial +de revisiones, hacer commits en el árbol, usar ramas, etcétera. También es +útil entender las herramientas de git para rescribir la historia (como +rebase). Git viene con su propia terminología y conceptos; un nuevo +usuario de git debe conocer las referencias, las ramas remotas, el índice, +las fusiones fast-forward, los pushes y pulls, las cabezas separadas, +etcétera. Todo puede ser un poco intimidante al principio, pero los +conceptos no son tan difíciles de entender con un poco de estudio. + +Usar git para generar parches para enviarlos por correo electrónico puede +ser un buen ejercicio mientras te pones al día. + +Cuando esté listo para comenzar a publicar árboles de git para que otros +los vean, necesitará por supuesto, un servidor del que se pueda extraer. +Configurar un servidor de este tipo con git-daemon es relativamente +sencillo si tiene un sistema accesible a Internet. De lo contrario, los +sitios de alojamiento público y gratuitos (GitHub, por ejemplo) están +comenzando a aparecer en la red. Los desarrolladores establecidos pueden +obtener una cuenta en kernel.org, pero no son fáciles de conseguir; ver +https://kernel.org/faq/ para más información. + +El flujo de trabajo normal de git implica el uso de muchas ramas. Cada +línea de desarrollo puede separarse en una “rama temática” separada y +mantenerse de forma independiente. Las ramas en git son baratas, no hay +razón para no hacer uso gratuito de ellas. Y, en cualquier caso, no debe +desarrollarse en ninguna rama de la que tenga la intención de pedir a +otros que hagan un pull. Las ramas disponibles públicamente deben crearse +con cuidado; fusione los parches de las ramas de desarrollo cuando estén +en forma completa y listos para usar – no antes. + +Git proporciona herramientas poderosas que permiten reescribir su historia +de desarrollo. Un parche inconveniente (uno que rompe la bisección, por +ejemplo, o que tiene algún otro tipo de error obvio) se puede corregir en +su lugar o hacer que desaparezca de la historia por completo. Una serie de +parches se puede reescribir como si se hubiera escrito sobre el mainline +de hoy, aunque haya estado trabajando en ella durante meses. Los cambios +se pueden transferir de manera transparente de una rama a otra. Y así +sucesivamente. El uso juicioso de la capacidad de git para revisar el +historial puede ayudar en la creación de conjuntos de parches limpios con +menos problemas. + +El uso excesivo de esta capacidad puede llevar a otros problemas más allá +de una simple obsesión por crear la historia perfecta del proyecto. +Reescribir la historia rescribirá los cambios contenidos en esa historia, +convirtiendo un árbol del kernel probado (con suerte) en uno no probado. +Pero más allá de eso, los desarrolladores no pueden colaborar fácilmente +si no tienen una vista compartida del historial del proyecto; si reescribe +la historia que otros desarrolladores han introducido en sus repositorios, +les hará la vida mucho más difícil a esos desarrolladores. Por lo tanto, +aquí se aplica una regla simple general: la historia que se ha exportado +a otros generalmente debe considerarse inmutable a partir de entonces. + +Por lo tanto, una vez que envié un conjunto de cambios a su servidor +disponible públicamente, esos cambios no deben reescribirse. Git +intentará hacer cumplir esta regla si intenta enviar cambios que no +resulten en un “fast-forward merge” (es decir, cambios que no comparten +el mismo historial). Es posible anular esta comprobación, y puede haber +ocasiones en las que sea necesario reescribir un árbol exportado. Mover +conjuntos de cambios entre árboles para evitar conflictos en linux-next +es un ejemplo. Pero tales acciones deberían ser raras. Esta es una de las +razones por las que el desarrollo debe hacerse en ramas privadas (que se +pueden reescribir si es necesario) y solo trasladarse a ramas públicas +cuando esté en un estado razonablemente avanzado. + +A medida que el mainline (u otro árbol en el que se basa un conjunto de +cambios) avanza, es tentador fusionarse con ese árbol para permanecer a +la vanguardia. Para una rama privada, la rebase puede ser una manera fácil +de mantenerse al día con otro árbol, pero la rebase no es una opción una +vez que el árbol se exporta al mundo. Una vez que eso sucede, se debe +realizar una fusión completa. Fusionar ocasionalmente tiene sentido, pero +las fusiones demasiado frecuentes pueden desordenar el historial +innecesariamente. La técnica sugerida en este caso es fusionar con poca +frecuencia y, por lo general, solo en puntos de lanzamiento específicos +(como una versión -rc del mainline). Si está nervioso por cambios +específicos, siempre puede realizar fusiones de prueba en una rama +privada. La herramienta git “rerere” puede ser útil en tales situaciones; +recuerda cómo se resolvieron los conflictos de fusión para que no tenga +que hacer el mismo trabajo dos veces. + +Una de las mayores quejas recurrentes sobre herramientas como git es la +siguiente: el movimiento masivo de parches de un repositorio a otro hace +que sea fácil deslizar cambios más aconsejados que pasan al mainline +debajo del radar de revisión. Los desarrolladores del kernel tienden a +descontentarse cuando ven que suceden ese tipo de cosas; poner un árbol +de git con parches no revisados o fuera de tema puede afectar su capacidad +para hacer que los árboles sean integrados en el futuro. Citando a Linus: + +:: + + Puede enviarme parches, pero para que yo acepte un parche de git de + su parte, necesito saber que usted sabe lo que está haciendo, y + necesito poder confiar en las cosas *sin* tener que revisar + manualmente cada cambio individual. + +(https://lwn.net/Articles/224135/). + +Para evitar este tipo de situación, asegúrese de que todos los parches +dentro de una rama determinada se adhieran estrictamente al tema asociado; +una rama de “correcciones de drivers” no debería hacer cambios en el +código central de gestión de memoria. Y, lo más importante, no utilice un +árbol git para eludir el proceso de revisión. Publique un resumen +ocasional del árbol en la lista relevante y, cuando sea el momento +adecuado, solicite que el árbol se incluya en linux-next. + +Si y cuando otros comiencen a enviar parches para su inclusión en su +árbol, no olvide revisarlos. Además, asegúrese de mantener la información +de autoría correcta; la herramienta git “am” hace lo mejor que puede es +este sentido, pero es posible que tenga que agregar una línea “From:” al +parche si ha sido reenviado a través de un tercero. + +Al solicitar un pull, proporcione toda la información relevante: dónde +está su árbol, qué rama se debe pull, y que cambios resultarán del pull. +El comando git request-pull puede ser útil en este sentido; formateará la +solicitud como otros desarrolladores esperan, y también comprobará para +asegurarse de que ha recordado enviar esos cambios al servidor público. + +Revisión de parches +------------------- + +Algunos lectores seguramente se opondrán a incluir esta sección con +“temas avanzados” porque incluso los desarrolladores principiantes del +kernel deberían revisar los parches. Es cierto que no hay mejor manera de +aprender a programar en el entorno del kernel que mirando el código +publicado por otros. Además, los revisores siempre escasean; al revisar +código, puede contribuir significativamente al proceso en su conjunto. + +Revisar el código puede ser una perspectiva intimidante, especialmente +para un nuevo desarrollador de kernel que puede sentirse nervioso al +cuestionar el código – en público – publicado por aquellos con más +experiencia. Sin embargo, incluso el código escrito por los desarrolladores +más experimentados se puede mejorar. Quizás el mejor consejo para los +revisores (todos los revisores) es este: expresar los comentarios de +revisión como preguntas en lugar de críticas. Preguntar “¿cómo se libera +el bloqueo en este camino?” siempre funcionará mejor que decir “el +bloqueo aquí es incorrecto”. + +Otra técnica que es útil en caso de desacuerdo es pedir a otros que +intervengan. Si una discusión llega a un punto muerto después de algunos +intercambios, solicite las opiniones de otros revisores o maintainers. A +menudo, aquellos que están de acuerdo con un revisor permanecen en +silencio a menos que se les invite a participar. La opinión de varias +personas tiene exponencialmente más peso. + +Diferentes desarrolladores revisarán el código desde diferentes puntos de +vista. Algunos se preocupan principalmente por el estilo de codificación +y si las líneas de código tienen espacios en blanco al final. Otros se +enfocarán principalmente en si el cambio implementado por el parche en su +totalidad es beneficioso para el kernel o no. Sin embargo, otros +comprobarán si hay bloqueos problemáticos, uso excesivo de la pila, +posibles problemas de seguridad, duplicación de código encontrado en +otras partes, documentación adecuada, efectos adversos en el rendimiento, +cambios en la ABI del espacio de usuario, etcétera. Todos los tipos de +revisión, si conducen a un mejor código en el kernel, son bienvenidos y +valen la pena. + +No hay ningún requisito estricto para usar etiquetas específicas como +``Reviewed-by``. De hecho, las revisiones en Inglés sencillo son más +informativas y alentadas incluso cuando se proporciona una etiqueta, por +ejemplo, “Revisé los aspectos A, B y C de esta propuesta y me parece +bien”. +¡Alguna forma de mensaje de revisión o respuesta es obviamente necesaria, +de lo contrario, los maintainers no sabrán que el revisor ha revisado el +parche en absoluto! + +Por último, pero no menos importante, la revisión de parches puede +convertirse en un proceso negativo, centrado en señalar problemas. ¡Por +favor, dé un cumplido de vez en cuando, especialmente a los principiantes! diff --git a/Documentation/translations/sp_SP/process/8.Conclusion.rst b/Documentation/translations/sp_SP/process/8.Conclusion.rst index dd181cb8ec9a..d311a23d53df 100644 --- a/Documentation/translations/sp_SP/process/8.Conclusion.rst +++ b/Documentation/translations/sp_SP/process/8.Conclusion.rst @@ -1,11 +1,82 @@ .. include:: ../disclaimer-sp.rst :Original: Documentation/process/8.Conclusion.rst +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com> .. _sp_development_conclusion: Para más información ==================== -.. warning:: - TODO aún no traducido +Hay numerosas fuentes de información sobre el desarrollo del kernel de +Linux y temas relacionados. La primera de ellas será el directorio de +Documentación (Documentation) que se encuentra en la distribución del +código fuente del kernel. Comience con el nivel superior +:ref:`Documentation/translations/sp_SP/process/howto.rst <sp_process_howto>`; +también lea +:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`. +Muchas API internas del kernel están documentadas utilizando el mecanismo +de kerneldoc; “make htmldocs” o “make pdfdocs” se pueden usar para +generar esos documentos en formato HTML o PDF (aunque la versión de TeX +incluida en algunas distribuciones tiene límites internos y no procesa +los documentos correctamente). + +Varios sitios web discuten el desarrollo del kernel en todos los niveles +de detalle. A su autor le gustaría sugerir humildemente https://lwn.net/ +como fuente. La información sobre muchos temas específicos del kernel se +puede encontrar a través del índice del kernel de LWN en: + + https://lwn.net/Kernel/Index/ + +Más allá de eso, un recurso valioso para los desarrolladores del kernel +es: + + https://kernelnewbies.org/ + +Y, por supuesto, no se debe olvidar https://kernel.org/, la ubicación +definitiva para información de lanzamiento del kernel. + +Hay varios libros sobre el desarrollo del kernel: + + Linux Device Drivers, 3rd Edition (Jonathan Corbet, Alessandro + Rubini, and Greg Kroah-Hartman). En linea en + https://lwn.net/Kernel/LDD3/. + + Linux Kernel Development (Robert Love). + + Understanding the Linux Kernel (Daniel Bovet and Marco Cesati). + +Todos estos libros padecen un defecto común: suelen estar algo obsoletos +cuando llegan a las estanterías, y ya llevan un tiempo en las estanterías. +Aun así, hay bastante buena información que se puede encontrar allí. + +La documentación de git se puede encontrar en: + + https://www.kernel.org/pub/software/scm/git/docs/ + + https://www.kernel.org/pub/software/scm/git/docs/user-manual.html + +Conclusión +========== + +Felicitaciones a todos los que han logrado leer este extenso documento. +Con suerte, ha proporcionado una comprensión útil de cómo se desarrolla +el kernel Linux y cómo puede participar en ese proceso. + +Al final, lo que importa es la participación. Cualquier proyecto de +software de código abierto no es más que la suma de lo que sus +colaboradores aportan. El kernel Linux ha progresado tan rápido y tan como +lo ha hecho porque ha sido ayudado por un grupo impresionantemente grande +de desarrolladores, todos los cuales están trabajando para mejorarlo. El +kernel es un excelente ejemplo de lo que se puede lograr cuando miles de +personas trabajan juntas hacia un objetivo común. + +Sin embargo, el kernel siempre puede beneficiarse de una base de +desarrolladores más grande. Siempre hay más trabajo por hacer. Pero, lo +que es igual de importante, la mayoría de los demás participantes en el +ecosistema Linux pueden beneficiarse contribuyendo al kernel. Introducir +código en el mainline es la clave para una mayor calidad del código, +menores costes de mantenimiento y distribución, un mayor nivel de +influencia sobre la dirección del desarrollo del kernel y más. Es una +situación en la que todos los involucrados ganan. Encienda su editor y +únase a nosotros; será más que bienvenido. diff --git a/Documentation/translations/sp_SP/process/development-process.rst b/Documentation/translations/sp_SP/process/development-process.rst index 40d74086f22e..261bcdea3ffc 100644 --- a/Documentation/translations/sp_SP/process/development-process.rst +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: Documentation/process/development-process.rst -:Translator: Avadhut Naik <avadhut.naik@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com> .. _sp_development_process_main: @@ -9,14 +9,13 @@ Guía del proceso de desarrollo del kernel ========================================= El propósito de este documento es ayudar a los desarrolladores (y sus -gerentes) a trabajar con la comunidad de desarrollo con un mínimo de +jefes) a trabajar con la comunidad de desarrollo con el mínimo de frustración. Es un intento de documentar cómo funciona esta comunidad -de una manera accesible para aquellos que no están familiarizados -íntimamente con el desarrollo del kernel de Linux (o, de hecho, el -desarrollo de software libre en general). Si bien hay algo de material -técnico aquí, este es en gran medida una discusión orientada al proceso -que no requiere un conocimiento profundo de la programación del kernel -para entenderla. +de una manera accesible, para aquellos que no están familiarizados +íntimamente con el desarrollo del kernel Linux (o, de hecho, el desarrollo +de software libre en general). Si bien hay algo de material técnico aquí, +esto es en gran medida una discusión orientada al proceso que no requiere +un conocimiento profundo de la programación del kernel para entenderla. .. toctree:: :caption: Contenido @@ -25,3 +24,9 @@ para entenderla. 1.Intro 2.Process + 3.Early-stage + 4.Coding + 5.Posting + 6.Followthrough + 7.AdvancedTopics + 8.Conclusion diff --git a/Documentation/translations/sp_SP/process/email-clients.rst b/Documentation/translations/sp_SP/process/email-clients.rst index 55d5803daf41..f60b091ac9ca 100644 --- a/Documentation/translations/sp_SP/process/email-clients.rst +++ b/Documentation/translations/sp_SP/process/email-clients.rst @@ -96,7 +96,7 @@ En la sección :menuselection:`Sending Preferences`: - :menuselection:`Strip Whitespace Before Sending` debe estar ``disabled`` Al redactar el mensaje, el cursor debe colocarse donde el parche debería -aparecer, y luego presionando :kbd:`CTRL-R` se le permite especificar e +aparecer, y luego presionando `CTRL-R` se le permite especificar e archivo de parche a insertar en el mensaje. Claws Mail (GUI) @@ -104,7 +104,7 @@ Claws Mail (GUI) Funciona. Algunos usan esto con éxito para los parches. -Para insertar un parche haga :menuselection:`Message-->Insert File` (:kbd:`CTRL-I`) +Para insertar un parche haga :menuselection:`Message-->Insert File` (`CTRL-I`) o use un editor externo. Si el parche insertado debe editarse en la ventana de composición de Claws @@ -118,11 +118,11 @@ Evolution (GUI) Algunos usan esto con éxito para sus parches. Cuando escriba un correo seleccione: Preformat - desde :menuselection:`Format-->Paragraph Style-->Preformatted` (:kbd:`CTRL-7`) + desde :menuselection:`Format-->Paragraph Style-->Preformatted` (`CTRL-7`) o en la barra de herramientas Luego haga: -:menuselection:`Insert-->Text File...` (:kbd:`ALT-N x`) +:menuselection:`Insert-->Text File...` (`ALT-N x`) para insertar el parche. También puede hacer ``diff -Nru old.c new.c | xclip``, seleccione diff --git a/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst b/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst index 7d4d694967c7..9d444b9c46d3 100644 --- a/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst +++ b/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst @@ -287,7 +287,7 @@ revelada involucrada. La lista de embajadores actuales: Google Kees Cook <keescook@chromium.org> - LLVM Nick Desaulniers <ndesaulniers@google.com> + LLVM Nick Desaulniers <nick.desaulniers+lkml@gmail.com> ============= ======================================================== Si quiere que su organización se añada a la lista de embajadores, por diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst index adb2cc845928..cff972fe0084 100644 --- a/Documentation/translations/sp_SP/process/index.rst +++ b/Documentation/translations/sp_SP/process/index.rst @@ -10,6 +10,7 @@ .. toctree:: :maxdepth: 1 + development-process submitting-patches kernel-docs coding-style @@ -28,5 +29,4 @@ management-style submit-checklist howto - development-process maintainer-kvm-x86 diff --git a/Documentation/translations/sp_SP/process/submit-checklist.rst b/Documentation/translations/sp_SP/process/submit-checklist.rst index 0d6651f9d871..e7107cc97001 100644 --- a/Documentation/translations/sp_SP/process/submit-checklist.rst +++ b/Documentation/translations/sp_SP/process/submit-checklist.rst @@ -97,9 +97,10 @@ y en otros lugares con respecto al envío de parches del kernel de Linux. ``MODULE_PARM_DESC()``. 18) Todas las nuevas interfaces de espacio de usuario están documentadas - en ``Documentation/ABI/``. Consulte ``Documentation/ABI/README`` para - obtener más información. Los parches que cambian las interfaces del - espacio de usuario deben ser CCed a linux-api@vger.kernel.org. + en ``Documentation/ABI/``. Consulte Documentation/admin-guide/abi.rst + (o ``Documentation/ABI/README``) para obtener más información. + Los parches que cambian las interfaces del espacio de usuario deben + ser CCed a linux-api@vger.kernel.org. 19) Se ha comprobado con la inyección de al menos errores de asignación de slab y página. Consulte ``Documentation/fault-injection/``. diff --git a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst index dc728c739e28..b35d24464be9 100644 --- a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst +++ b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst @@ -112,7 +112,7 @@ CFS usa una granularidad de nanosegundos y no depende de ningún jiffy o detalles como HZ. De este modo, el gestor de tareas CFS no tiene noción de "ventanas de tiempo" de la forma en que tenía el gestor de tareas previo, y tampoco tiene heurísticos. Únicamente hay un parámetro -central ajustable (se ha de cambiar en CONFIG_SCHED_DEBUG): +central ajustable: /sys/kernel/debug/sched/base_slice_ns diff --git a/Documentation/translations/zh_CN/admin-guide/README.rst b/Documentation/translations/zh_CN/admin-guide/README.rst index e679cbc3c89d..1bdafdc4c8e2 100644 --- a/Documentation/translations/zh_CN/admin-guide/README.rst +++ b/Documentation/translations/zh_CN/admin-guide/README.rst @@ -146,7 +146,7 @@ Linux内核6.x版本 <http://kernel.org/> "make xconfig" 基于Qt的配置工具。 - "make gconfig" 基于GTK+的配置工具。 + "make gconfig" 基于GTK的配置工具。 "make oldconfig" 基于现有的 ./.config 文件选择所有选项，并询问 新配置选项。 diff --git a/Documentation/translations/zh_CN/admin-guide/bug-hunting.rst b/Documentation/translations/zh_CN/admin-guide/bug-hunting.rst index decb9b26d2f1..c3f6a83294dc 100644 --- a/Documentation/translations/zh_CN/admin-guide/bug-hunting.rst +++ b/Documentation/translations/zh_CN/admin-guide/bug-hunting.rst @@ -329,12 +329,3 @@ sysklogd发行版附带了一个补丁，它修改了 ``modules-2.0.0`` 包，� Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128] Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3 ---------------------------------------------------------------------------- - -:: - - Dr. G.W. Wettstein Oncology Research Div. Computing Facility - Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com - 820 4th St. N. - Fargo, ND 58122 - Phone: 701-234-7556 diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst index 50f6f0b6bf11..9d7cb51be493 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst @@ -26,12 +26,7 @@ DAMON 为不同的用户提供了下面这些接口。 使用它，用户可以通过读取和写入特殊的sysfs文件来使用DAMON的主要功能。因此，你可以编写和使 用你个性化的DAMON sysfs包装程序，代替你读/写sysfs文件。 `DAMON用户空间工具 <https://github.com/damonitor/damo>`_ 就是这种程序的一个例子 它同时支持虚拟和物理地址 - 空间的监测。注意，这个界面只提供简单的监测结果 :ref:`统计 <damos_stats>`。对于详细的监测 - 结果，DAMON提供了一个:ref:`跟踪点 <tracepoint>`。 -- *debugfs interface.* - :ref:`这 <debugfs_interface>` 几乎与:ref:`sysfs interface <sysfs_interface>` 接 - 口相同。这将在下一个LTS内核发布后被移除，所以用户应该转移到 - :ref:`sysfs interface <sysfs_interface>`。 + 空间的监测。 - *内核空间编程接口。* :doc:`这 </mm/damon/api>` 这是为内核空间程序员准备的。使用它，用户可以通过为你编写内 核空间的DAMON应用程序，最灵活有效地利用DAMON的每一个功能。你甚至可以为各种地址空间扩展DAMON。 @@ -335,247 +330,6 @@ tried_regions/<N>/ 请注意，我们强烈建议使用用户空间的工具，如 `damo <https://github.com/damonitor/damo>`_ ， 而不是像上面那样手动读写文件。以上只是一个例子。 -debugfs接口 -=========== - -.. note:: - - DAMON debugfs接口将在下一个LTS内核发布后被移除，所以用户应该转移到 - :ref:`sysfs接口<sysfs_interface>`。 - -DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``, -``schemes``, ``monitor_on_DEPRECATED``, ``kdamond_pid``, ``mk_contexts`` 和 -``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``. - - -属性 ----- - -用户可以通过读取和写入 ``attrs`` 文件获得和设置 ``采样间隔`` 、 ``聚集间隔`` 、 ``更新间隔`` -以及监测目标区域的最小/最大数量。要详细了解监测属性，请参考 `:doc:/mm/damon/design` 。例如， -下面的命令将这些值设置为5ms、100ms、1000ms、10和1000，然后再次检查:: - - # cd <debugfs>/damon - # echo 5000 100000 1000000 10 1000 > attrs - # cat attrs - 5000 100000 1000000 10 1000 - - -目标ID ------- - -一些类型的地址空间支持多个监测目标。例如，虚拟内存地址空间的监测可以有多个进程作为监测目标。用户 -可以通过写入目标的相关id值来设置目标，并通过读取 ``target_ids`` 文件来获得当前目标的id。在监 -测虚拟地址空间的情况下，这些值应该是监测目标进程的pid。例如，下面的命令将pid为42和4242的进程设 -为监测目标，并再次检查:: - - # cd <debugfs>/damon - # echo 42 4242 > target_ids - # cat target_ids - 42 4242 - -用户还可以通过在文件中写入一个特殊的关键字 "paddr\n" 来监测系统的物理内存地址空间。因为物理地 -址空间监测不支持多个目标，读取文件会显示一个假值，即 ``42`` ，如下图所示:: - - # cd <debugfs>/damon - # echo paddr > target_ids - # cat target_ids - 42 - -请注意，设置目标ID并不启动监测。 - - -初始监测目标区域 ----------------- - -在虚拟地址空间监测的情况下，DAMON自动设置和更新监测的目标区域，这样就可以覆盖目标进程的整个 -内存映射。然而，用户可能希望将监测区域限制在特定的地址范围内，如堆、栈或特定的文件映射区域。 -或者，一些用户可以知道他们工作负载的初始访问模式，因此希望为“自适应区域调整”设置最佳初始区域。 - -相比之下，DAMON在物理内存监测的情况下不会自动设置和更新监测目标区域。因此，用户应该自己设置 -监测目标区域。 - -在这种情况下，用户可以通过在 ``init_regions`` 文件中写入适当的值，明确地设置他们想要的初 -始监测目标区域。输入应该是一个由三个整数组成的队列，用空格隔开，代表一个区域的形式如下:: - - <target idx> <start address> <end address> - -目标idx应该是 ``target_ids`` 文件中目标的索引，从 ``0`` 开始，区域应该按照地址顺序传递。 -例如，下面的命令将设置几个地址范围， ``1-100`` 和 ``100-200`` 作为pid 42的初始监测目标 -区域，这是 ``target_ids`` 中的第一个（索引 ``0`` ），另外几个地址范围， ``20-40`` 和 -``50-100`` 作为pid 4242的地址，这是 ``target_ids`` 中的第二个（索引 ``1`` ）:: - - # cd <debugfs>/damon - # cat target_ids - 42 4242 - # echo "0 1 100 \ - 0 100 200 \ - 1 20 40 \ - 1 50 100" > init_regions - -请注意，这只是设置了初始的监测目标区域。在虚拟内存监测的情况下，DAMON会在一个 ``更新间隔`` -后自动更新区域的边界。因此，在这种情况下，如果用户不希望更新的话，应该把 ``更新间隔`` 设 -置得足够大。 - - -方案 ----- - -对于通常的基于DAMON的数据访问感知的内存管理优化，用户只是希望系统对特定访问模式的内存区域应用内 -存管理操作。DAMON从用户那里接收这种形式化的操作方案，并将这些方案应用到目标进程中。 - -用户可以通过读取和写入 ``scheme`` debugfs文件来获得和设置这些方案。读取该文件还可以显示每个 -方案的统计数据。在文件中，每一个方案都应该在每一行中以下列形式表示出来:: - - <target access pattern> <action> <quota> <watermarks> - -你可以通过简单地在文件中写入一个空字符串来禁用方案。 - -目标访问模式 -~~~~~~~~~~~~ - -``<目标访问模式>`` 是由三个范围构成的，形式如下:: - - min-size max-size min-acc max-acc min-age max-age - -具体来说，区域大小的字节数（ `min-size` 和 `max-size` ），访问频率的每聚合区间的监测访问次 -数（ `min-acc` 和 `max-acc` ），区域年龄的聚合区间数（ `min-age` 和 `max-age` ）都被指定。 -请注意，这些范围是封闭区间。 - -动作 -~~~~ - -``<action>`` 是一个预定义的内存管理动作的整数，DAMON将应用于具有目标访问模式的区域。支持 -的数字和它们的含义如下:: - - - 0: Call ``madvise()`` for the region with ``MADV_WILLNEED`` - - 1: Call ``madvise()`` for the region with ``MADV_COLD`` - - 2: Call ``madvise()`` for the region with ``MADV_PAGEOUT`` - - 3: Call ``madvise()`` for the region with ``MADV_HUGEPAGE`` - - 4: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE`` - - 5: Do nothing but count the statistics - -配额 -~~~~ - -每个 ``动作`` 的最佳 ``目标访问模式`` 取决于工作负载，所以不容易找到。更糟糕的是，将某个 -动作的方案设置得过于激进会导致严重的开销。为了避免这种开销，用户可以通过下面表格中的 ``<quota>`` -来限制方案的时间和大小配额:: - - <ms> <sz> <reset interval> <priority weights> - -这使得DAMON在 ``<reset interval>`` 毫秒内，尽量只用 ``<ms>`` 毫秒的时间对 ``目标访 -问模式`` 的内存区域应用动作，并在 ``<reset interval>`` 内只对最多<sz>字节的内存区域应 -用动作。将 ``<ms>`` 和 ``<sz>`` 都设置为零，可以禁用配额限制。 - -当预计超过配额限制时，DAMON会根据 ``目标访问模式`` 的大小、访问频率和年龄，对发现的内存 -区域进行优先排序。为了实现个性化的优先级，用户可以在 ``<优先级权重>`` 中设置这三个属性的 -权重，具体形式如下:: - - <size weight> <access frequency weight> <age weight> - -水位 -~~~~ - -有些方案需要根据系统特定指标的当前值来运行，如自由内存比率。对于这种情况，用户可以为该条 -件指定水位。:: - - <metric> <check interval> <high mark> <middle mark> <low mark> - -``<metric>`` 是一个预定义的整数，用于要检查的度量。支持的数字和它们的含义如下。 - - - 0: 忽视水位 - - 1: 系统空闲内存率 (千分比) - -每隔 ``<检查间隔>`` 微秒检查一次公制的值。 - -如果该值高于 ``<高标>`` 或低于 ``<低标>`` ，该方案被停用。如果该值低于 ``<中标>`` ， -该方案将被激活。 - -统计数据 -~~~~~~~~ - -它还统计每个方案被尝试应用的区域的总数量和字节数，每个方案被成功应用的区域的两个数量，以 -及超过配额限制的总数量。这些统计数据可用于在线分析或调整方案。 - -统计数据可以通过读取方案文件来显示。读取该文件将显示你在每一行中输入的每个 ``方案`` ， -统计的五个数字将被加在每一行的末尾。 - -例子 -~~~~ - -下面的命令应用了一个方案：”如果一个大小为[4KiB, 8KiB]的内存区域在[10, 20]的聚合时间 -间隔内显示出每一个聚合时间间隔[0, 5]的访问量，请分页出该区域。对于分页，每秒最多只能使 -用10ms，而且每秒分页不能超过1GiB。在这一限制下，首先分页出具有较长年龄的内存区域。另外， -每5秒钟检查一次系统的可用内存率，当可用内存率低于50%时开始监测和分页，但如果可用内存率 -大于60%，或低于30%，则停止监测“:: - - # cd <debugfs>/damon - # scheme="4096 8192 0 5 10 20 2" # target access pattern and action - # scheme+=" 10 $((1024*1024*1024)) 1000" # quotas - # scheme+=" 0 0 100" # prioritization weights - # scheme+=" 1 5000000 600 500 300" # watermarks - # echo "$scheme" > schemes - - -开关 ----- - -除非你明确地启动监测，否则如上所述的文件设置不会产生效果。你可以通过写入和读取 ``monitor_on_DEPRECATED`` -文件来启动、停止和检查监测的当前状态。写入 ``on`` 该文件可以启动对有属性的目标的监测。写入 -``off`` 该文件则停止这些目标。如果每个目标进程被终止，DAMON也会停止。下面的示例命令开启、关 -闭和检查DAMON的状态:: - - # cd <debugfs>/damon - # echo on > monitor_on_DEPRECATED - # echo off > monitor_on_DEPRECATED - # cat monitor_on_DEPRECATED - off - -请注意，当监测开启时，你不能写到上述的debugfs文件。如果你在DAMON运行时写到这些文件，将会返 -回一个错误代码，如 ``-EBUSY`` 。 - - -监测线程PID ------------ - -DAMON通过一个叫做kdamond的内核线程来进行请求监测。你可以通过读取 ``kdamond_pid`` 文件获 -得该线程的 ``pid`` 。当监测被 ``关闭`` 时，读取该文件不会返回任何信息:: - - # cd <debugfs>/damon - # cat monitor_on_DEPRECATED - off - # cat kdamond_pid - none - # echo on > monitor_on_DEPRECATED - # cat kdamond_pid - 18594 - - -使用多个监测线程 ----------------- - -每个监测上下文都会创建一个 ``kdamond`` 线程。你可以使用 ``mk_contexts`` 和 ``rm_contexts`` -文件为多个 ``kdamond`` 需要的用例创建和删除监测上下文。 - -将新上下文的名称写入 ``mk_contexts`` 文件，在 ``DAMON debugfs`` 目录上创建一个该名称的目录。 -该目录将有该上下文的 ``DAMON debugfs`` 文件:: - - # cd <debugfs>/damon - # ls foo - # ls: cannot access 'foo': No such file or directory - # echo foo > mk_contexts - # ls foo - # attrs init_regions kdamond_pid schemes target_ids - -如果不再需要上下文，你可以通过把上下文的名字放到 ``rm_contexts`` 文件中来删除它和相应的目录:: - - # echo foo > rm_contexts - # ls foo - # ls: cannot access 'foo': No such file or directory - -注意， ``mk_contexts`` 、 ``rm_contexts`` 和 ``monitor_on_DEPRECATED`` 文件只在根目录下。 - 监测结果的监测点 ================ diff --git a/Documentation/translations/zh_CN/admin-guide/sysrq.rst b/Documentation/translations/zh_CN/admin-guide/sysrq.rst index 8276d70f3b40..6b100acc4ed8 100644 --- a/Documentation/translations/zh_CN/admin-guide/sysrq.rst +++ b/Documentation/translations/zh_CN/admin-guide/sysrq.rst @@ -60,24 +60,24 @@ CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE 必须是以 16 进制数写入。 ~~~~~~~~~~~~~~~~~~~~~~~ 在 x86 架构上 - 你可以按下键盘组合键 :kbd:`ALT-SysRq-<command key>`。 + 你可以按下键盘组合键 `ALT-SysRq-<command key>`。 .. note:: 一些键盘可能没有标识 'SySRq' 键。'SySRq' 键也被当做 'Print Screen'键。 - 同时有些键盘无法处理同时按下这么多键，因此你可以先按下键盘 :kbd:`Alt` 键， - 然后按下键盘 :kbd:`SysRq` 键，再释放键盘 :kbd:`SysRq` 键，之后按下键盘上命令键 - :kbd:`<command key>`，最后释放所有键。 + 同时有些键盘无法处理同时按下这么多键，因此你可以先按下键盘 `Alt` 键， + 然后按下键盘 `SysRq` 键，再释放键盘 `SysRq` 键，之后按下键盘上命令键 + `<command key>`，最后释放所有键。 在 SPARC 架构上 - 你可以按下键盘组合键 :kbd:`ALT-STOP-<command key>` 。 + 你可以按下键盘组合键 `ALT-STOP-<command key>` 。 在串行控制台（只针对 PC 类型的标准串口） 你可以发一个 ``BREAK`` ，然后在 5 秒内发送一个命令键， 发送 ``BREAK`` 两次将被翻译为一个正常的 BREAK 操作。 在 PowerPC 架构上 - 按下键盘组合键 :kbd:`ALT - Print Screen` （或者 :kbd:`F13`） - :kbd:`<命令键>` 。 - :kbd:`Print Screen` （或者 :kbd:`F13`） - :kbd:`<命令键>` 或许也能实现。 + 按下键盘组合键 `ALT - Print Screen` （或者 `F13`） - `<命令键>` 。 + `Print Screen` （或者 `F13`） - `<命令键>` 或许也能实现。 在其他架构上 如果你知道其他架构的组合键，请告诉我，我可以把它们添加到这部分。 @@ -87,7 +87,7 @@ CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE 必须是以 16 进制数写入。 echo t > /proc/sysrq-trigger -这个命令键 :kbd:`<command key>` 是区分大小写的。 +这个命令键 `<command key>` 是区分大小写的。 什么是命令键？ ~~~~~~~~~~~~~~ @@ -203,8 +203,8 @@ syslogd/klogd 进程是运行的，它们仍将被记录。） ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 这也会发生在我这，我发现轻敲键盘两侧的 shift、alt 和 control 键，然后再次敲击 -一个无效的 SysRq 键序列可以解决问题。（比如，像键盘组合键 :kbd:`alt-sysrq-z` ） -切换到另一个虚拟控制台（键盘操作 :kbd:`ALT+Fn` ），然后再切回来应该也有帮助。 +一个无效的 SysRq 键序列可以解决问题。（比如，像键盘组合键 `alt-sysrq-z` ） +切换到另一个虚拟控制台（键盘操作 `ALT+Fn` ），然后再切回来应该也有帮助。 我敲击了 SysRq 键，但像是什么都没发生，发生了什么错误？ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -259,7 +259,7 @@ SysRq 键的输出和所有其他控制台输出一样，受制于控制台日� 文件的消费访问到。作为一个特例，来自 sysrq 命令的标题行将被传递给所有控制台 使用者，就好像当前日志级别是最大的一样。如果只发出标题头，则几乎可以肯定内核日志 级别太低。如果你需要控制台上的输出，那么你将需要临时提高控制台日志级别，通过使用 -键盘组合键 :kbd:`alt-sysrq-8` 或者:: +键盘组合键 `alt-sysrq-8` 或者:: echo 8 > /proc/sysrq-trigger diff --git a/Documentation/translations/zh_CN/dev-tools/ubsan.rst b/Documentation/translations/zh_CN/dev-tools/ubsan.rst index 2487696b3772..81ef6f77caeb 100644 --- a/Documentation/translations/zh_CN/dev-tools/ubsan.rst +++ b/Documentation/translations/zh_CN/dev-tools/ubsan.rst @@ -3,7 +3,14 @@ .. include:: ../disclaimer-zh_CN.rst :Original: Documentation/dev-tools/ubsan.rst -:Translator: Dongliang Mu <dzm91@hust.edu.cn> + +:翻译: + + 慕冬亮 Dongliang Mu <dzm91@hust.edu.cn> + +:校译: + + 王昱力 WangYuli <wangyuli@uniontech.com> 未定义行为消毒剂 - UBSAN ==================================== @@ -55,30 +62,20 @@ GCC自4.9.x [1_] （详见 ``-fsanitize=undefined`` 选项及其子选项）版� 使用如下内核配置启用UBSAN:: - CONFIG_UBSAN=y - -使用如下内核配置检查整个内核:: - - CONFIG_UBSAN_SANITIZE_ALL=y - -为了在特定文件或目录启动代码插桩，需要在相应的内核Makefile中添加一行类似内容: + CONFIG_UBSAN=y -- 单文件（如main.o）:: - - UBSAN_SANITIZE_main.o := y - -- 一个目录中的所有文件:: - - UBSAN_SANITIZE := y - -即使设置了``CONFIG_UBSAN_SANITIZE_ALL=y``，为了避免文件被插桩，可使用:: +排除要被检测的文件:: UBSAN_SANITIZE_main.o := n -与:: +排除一个目录中的所有文件:: UBSAN_SANITIZE := n +当全部文件都被禁用，可通过如下方式为特定文件启用:: + + UBSAN_SANITIZE_main.o := y + 未对齐的内存访问检测可通过开启独立选项 - CONFIG_UBSAN_ALIGNMENT 检测。 该选项在支持未对齐访问的架构上(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y) 默认为关闭。该选项仍可通过内核配置启用，但它将产生大量的UBSAN报告。 diff --git a/Documentation/translations/zh_CN/devicetree/of_unittest.rst b/Documentation/translations/zh_CN/devicetree/of_unittest.rst index 11eb08ca8866..5c1a8e0cfd16 100644 --- a/Documentation/translations/zh_CN/devicetree/of_unittest.rst +++ b/Documentation/translations/zh_CN/devicetree/of_unittest.rst @@ -40,7 +40,7 @@ OF Selftest被设计用来测试提供给设备驱动开发者的接口（includ drivers/of/unittest-data/tests-phandle.dtsi drivers/of/unittest-data/tests-match.dtsi -当内核在启用OF_SELFTEST的情况下被构建时，那么下面的make规则:: +当内核在启用CONFIG_OF_UNITTEST的情况下被构建时，那么下面的make规则:: $(obj)/%.dtb: $(src)/%.dts FORCE $(call if_changed_dep, dtc) diff --git a/Documentation/translations/zh_CN/disclaimer-zh_CN.rst b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst index 3c6db094a63c..37681c0b2a01 100644 --- a/Documentation/translations/zh_CN/disclaimer-zh_CN.rst +++ b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst @@ -1,9 +1,7 @@ :orphan: -.. warning:: +.. note:: 此文件的目的是为让中文读者更容易阅读和理解，而不是作为一个分支。 因此， 如果您对此文件有任何意见或更新，请先尝试更新原始英文文件。 - -.. note:: - 如果您发现本文档与原始文件有任何不同或者有翻译问题，请联系该文件的译者， - 或者请求时奎亮的帮助：<alexs@kernel.org>。 + 如果您发现本文档与原始文件有任何不同或者有翻译问题，请发建议或者补丁给 + 该文件的译者，或者请求中文文档维护者和审阅者的帮助。 diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 7574e1673180..cc512ca54172 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -26,7 +26,13 @@ 顺便说下，中文文档也需要遵守内核编码风格，风格中中文和英文的主要不同就是中文 的字符标点占用两个英文字符宽度，所以，当英文要求不要超过每行100个字符时， 中文就不要超过50个字符。另外，也要注意'-'，'='等符号与相关标题的对齐。在将 -补丁提交到社区之前，一定要进行必要的 ``checkpatch.pl`` 检查和编译测试。 +补丁提交到社区之前，一定要进行必要的 ``checkpatch.pl`` 检查和编译测试，确保 +在 ``make htmldocs/pdfdocs`` 中不增加新的告警，最后，安装检查你生成的 +html/pdf 文件，确认它们看起来是正常的。 + +提交之前请确认你的补丁可以正常提交到中文文档维护库: +https://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git/ +如果你的补丁依赖于其他人的补丁, 可以与其他人商量后由某一个人合并提交。 与Linux 内核社区一起工作 ------------------------ diff --git a/Documentation/translations/zh_CN/mm/balance.rst b/Documentation/translations/zh_CN/mm/balance.rst index 6fd79209c307..f877c0cfa39a 100644 --- a/Documentation/translations/zh_CN/mm/balance.rst +++ b/Documentation/translations/zh_CN/mm/balance.rst @@ -64,7 +64,7 @@ kswapd并不真正需要平衡高内存区，因为中断上下文并不请求� 如果从进程内存和shm中偷取页面可以减轻该页面节点中任何区的内存压力，而该区的内存压力 已经低于其水位，则会进行偷取。 -watemark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd： +watermark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd： 这些是每个区的字段，用于确定一个区何时需要平衡。当页面数低于水位[WMARK_MIN]时， hysteric 的字段low_on_memory被设置。这个字段会一直被设置，直到空闲页数变成水位 [WMARK_HIGH]。当low_on_memory被设置时，页面分配请求将尝试释放该区域的一些页面（如果 diff --git a/Documentation/translations/zh_CN/process/email-clients.rst b/Documentation/translations/zh_CN/process/email-clients.rst index a70393089df3..069c0460d20c 100644 --- a/Documentation/translations/zh_CN/process/email-clients.rst +++ b/Documentation/translations/zh_CN/process/email-clients.rst @@ -85,7 +85,7 @@ Alpine (TUI) - :menuselection:`Do Not Send Flowed Text` 必须开启 - :menuselection:`Strip Whitespace Before Sending` 必须关闭 -当写邮件时，光标应该放在补丁会出现的地方，然后按下 :kbd:`CTRL-R` 组合键，使指 +当写邮件时，光标应该放在补丁会出现的地方，然后按下 `CTRL-R` 组合键，使指 定的补丁文件嵌入到邮件中。 Claws Mail (GUI) @@ -93,7 +93,7 @@ Claws Mail (GUI) 可以用，有人用它成功地发过补丁。 -用 :menuselection:`Message-->Insert File` (:kbd:`CTRL-I`) 或外置编辑器插入补丁。 +用 :menuselection:`Message-->Insert File` (`CTRL-I`) 或外置编辑器插入补丁。 若要在Claws编辑窗口重修改插入的补丁，需关闭 :menuselection:`Configuration-->Preferences-->Compose-->Wrapping` @@ -105,11 +105,11 @@ Evolution (GUI) 一些开发者成功的使用它发送补丁。 撰写邮件时： -从 :menuselection:`格式-->段落样式-->预格式化` (:kbd:`CTRL-7`) +从 :menuselection:`格式-->段落样式-->预格式化` (`CTRL-7`) 或工具栏选择 :menuselection:`预格式化` ； 然后使用： -:menuselection:`插入-->文本文件...` (:kbd:`ALT-N x`) 插入补丁文件。 +:menuselection:`插入-->文本文件...` (`ALT-N x`) 插入补丁文件。 你还可以 ``diff -Nru old.c new.c | xclip`` ，选择 :menuselection:`预格式化` ， 然后使用鼠标中键进行粘帖。 diff --git a/Documentation/translations/zh_CN/process/submit-checklist.rst b/Documentation/translations/zh_CN/process/submit-checklist.rst index 10536b74aeec..0e524f1c1af5 100644 --- a/Documentation/translations/zh_CN/process/submit-checklist.rst +++ b/Documentation/translations/zh_CN/process/submit-checklist.rst @@ -82,8 +82,8 @@ Linux内核补丁提交检查单 17) 所有新的模块参数都记录在 ``MODULE_PARM_DESC()`` 18) 所有新的用户空间接口都记录在 ``Documentation/ABI/`` 中。有关详细信息， - 请参阅 ``Documentation/ABI/README`` 。更改用户空间接口的补丁应该抄送 - linux-api@vger.kernel.org。 + 请参阅 Documentation/admin-guide/abi.rst (或 ``Documentation/ABI/README``)。 + 更改用户空间接口的补丁应该抄送 linux-api@vger.kernel.org\ 。 19) 已通过至少注入slab和page分配失败进行检查。请参阅 ``Documentation/fault-injection/`` 。 如果新代码是实质性的，那么添加子系统特定的故障注入可能是合适的。 diff --git a/Documentation/translations/zh_CN/security/IMA-templates.rst b/Documentation/translations/zh_CN/security/IMA-templates.rst new file mode 100644 index 000000000000..b391c9d03882 --- /dev/null +++ b/Documentation/translations/zh_CN/security/IMA-templates.rst @@ -0,0 +1,97 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/IMA-templates.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +=============== +IMA模板管理机制 +=============== + + +介绍 +==== + +原始的 ``ima`` 模板是固定长度的，包含文件数据的哈希值和路径名。文件数据 +哈希值限制为20字节(md5/sha1)。路径名是一个以空字符终止的字符串，长度限 +制为255个字符内。 +为了克服这些限制并添加额外的文件元数据，通过定义额外的模板来扩展当前版本 +的IMA这是有必要的。例如，可能报告的信息包括索引节点的 UID/GID或索引节点 +及访问它进程的LSM标签。 + +然而，引入这个功能的主要问题是，每次定义一个新模板时，生成和显示度量列表 +的函数都需要包含处理新格式的代码，因此，这些函数的规模随着时间的推移会 +显著增长。 + +提出的解决方案通过将模板管理与其余IMA代码分离来解决这个问题。该解决方案 +的核心是定义两个新的数据结构：一个是模板描述符，用于确定度量列表中应包含 +哪些信息；另一个是模板字段，用于生成和显示给定类型的数据。 + +使用这些结构管理模板非常简单。为了支持一种新的数据类型，开发人员定义字段 +标识符，并实现两个函数，分别为init()和show()，用于生成和显示度量条目。 +定义一个新的模板描述符需要通过 ``ima_template_fmt`` 内核命令行参数指定 +模板格式(一个由 ``|`` 字符分隔的字段标识符字符串)。在启动时，IMA通过将格 +式转换从支持的模板字段集合中选取模板字段数组，来初始化所选的模板描述符。 + +在初始化步骤之后，IMA将调用 ``ima_alloc_init_template()`` (这是为新模板 +管理机制所打补丁中定义的新函数)，通过使用在内核配置选择的模板描述符或者新引 +入的 ``ima_template`` 和 ``ima_template_fmt`` 内核命令行参数，生成一个新 +的度量条目。在这一阶段，新架构的优势得以清晰展示：后一个函数将不会包含处理给 +定模板的特定代码，而是简单地调用与所选模板描述符关联的模板字段的 ``init()`` +方法，并将结果(指向已分配数据的指针和数据长度)存储在度量条目结构中。 + +相同的机制也用于显示度量条目。函数 ``ima[_ascii]_measurements_show()`` 会为 +每个条目检索用于生成该条目的模板描述符，并为模板字段结构数组中的每一项调用show() +方法。 + + + +支持的模板字段和描述符 +====================== + +下面是支持的模板字段列表 ``('<identifier>': description)`` ，可以通过将其标识符 +添加到格式字符串中用于定义新的模板描述符(后续将添加对更多数据类型的支持): + + - 'd'：事件的摘要(即测量文件的摘要)，通过SHA1或MD5哈希算法计算； + - 'n'：事件的名称(即文件名)，大小至多255字节； + - 'd-ng'：事件的摘要，通过任意哈希算法计算(字段格式：<hash algo>:digest)； + - 'd-ngv2'：与d-ng相同，但以"ima"或"verity"摘要类型为前缀 + (字段格式：<digest type>:<hash algo>:digest)； + - 'd-modsig'：不含附加modsig的事件摘要； + - 'n-ng'：事件的名称，没有大小限制； + - 'sig'：文件签名，基于文件的/文件系统验证的摘要[1]，或EVM便携式签名， + 如果'security.ima'包含文件哈希； + - 'modsig'：附加的文件签名； + - 'buf'：用于生成哈希的缓冲区数据，没有大小限制； + - 'evmsig'：EVM便携式签名； + - 'iuid'：索引节点的UID； + - 'igid'：索引节点的GID； + - 'imode'：索引节点的模式； + - 'xattrnames'：xattr名称的列表(由``|``分隔)，仅当xattr存在时； + - 'xattrlengths'：xattr长度的列表(u32)，仅当xattr存在时； + - 'xattrvalues'：xattr值的列表； + + +下面是已定义的模板描述符列表： + + - "ima"：其格式是 ``d|n`` ； + - "ima-ng"(默认)：其格式是 ``d-ng|n-ng`` ； + - "ima-ngv2"：其格式是 ``d-ngv2|n-ng`` ； + - "ima-sig"：其格式是 ``d-ng|n-ng|sig`` ； + - "ima-sigv2"：其格式是 ``d-ngv2|n-ng|sig`` ； + - "ima-buf"：其格式是 ``d-ng|n-ng|buf`` ； + - "ima-modsig"：其格式是 ``d-ng|n-ng|sig|d-modsig|modsig`` ； + - "evm-sig"：其格式是 ``d-ng|n-ng|evmsig|xattrnames|xattrlengths|xattrvalues|iuid|igid|imode`` ； + + + +使用 +==== + +要指定用于生成度量条目的模板描述符，目前支持以下方法: + + - 从内核配置所支持模板描述符中选择一个模板描述符( ``ima-ng`` 是默认选择)； + - 通过 ``ima_template=`` 参数从内核命令行指定模板描述符名称； + - 通过内核命令行参数 ``ima_template_fmt=`` 注册一个具有自定义格式的新模板描述符。 diff --git a/Documentation/translations/zh_CN/security/credentials.rst b/Documentation/translations/zh_CN/security/credentials.rst new file mode 100644 index 000000000000..91c353dfb622 --- /dev/null +++ b/Documentation/translations/zh_CN/security/credentials.rst @@ -0,0 +1,479 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/credentials.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +============= +Linux中的凭据 +============= + +作者: David Howells <dhowells@redhat.com> + +.. contents:: :local: + +概述 +==== + +当一个对象对另一个对象进行操作时，Linux执行的安全检查包含几个部分： + + 1. 对象 + + 对象是可以直接由用户空间程序操作的系统中的实体。Linux具有多种可操作 + 的对象，包括： + + - 任务 + - 文件/索引节点 + - 套接字 + - 消息队列 + - 共享内存段 + - 信号量 + - 密钥 + + 所有这些对象的描述的一部分是一组凭据。集合中的内容取决于对象的类型。 + + 2. 对象所有权 + + 大多数对象的凭据中会有一个子集用来表示该对象的所有权。 + 这用于资源核算和限制（如磁盘配额和任务资源限制）。 + + 例如，在标准的UNIX文件系统中，这将由标记在索引节点上的UID定义。 + + 3. 对象上下文 + + 此外在这些对象的凭据中，将有一个子集表示对象的“对象上下文”。 + 这可能与（2）中相同，也可能不同 —— 例如，在标准的UNIX文件中， + 这是由标记在索引节点上的UID和GID定义的。 + + 对象上下文是进行安全计算的一部分，当对象被操作时会用到。 + + 4. 主体 + + 主体是正在对其他对象执行操作的对象。 + + 系统中的大多数对象是不活动的：他们不会对系统中的其他对象起作用。 + 进程/任务是明显的例外：它们可以访问和操纵其他对象。 + + 任务之外的其他对象在某些情况下也可以是主体。例如，打开的文件可以使用 + 名为 ``fcntl(F_SETOWN)`` 的任务给它的UID和EUID向一个任务发送SIGIO + 信号。在这种情况下，文件结构也会有一个主体上下文。 + + 5. 主体上下文 + + 主体对其凭据有一个额外的解释。其凭据的一个子集形成了“主体上下文”。主体 + 上下文在主体执行操作时作为安全计算的一部分使用。 + + 例如，Linux任务在操作文件时会有FSUID、FSGID和附加组列表 —— 这些凭据 + 与通常构成任务的对象上下文的真实UID和GID是相互独立的。 + + 6. 操作 + + Linux提供许多操作，主体可以对对象执行这些操作。可用的操作集取决于主体 + 和对象的性质。 + + + 操作包括读取、写入、创建和删除文件，以及派生（forking）或发送 + 信号（signalling）和跟踪（tracing）任务等。 + + 7. 规则，访问控制列表和安全计算 + + 当主体对对象进行操作时，会进行安全计算。这涉及到使用主体上下文、对象 + 上下文和操作，并搜索一个或多个规则集，以确定在给定这些上下文的情况下， + 主体是否被授予或拒绝以所需方式对对象进行操作的权限。 + + 主要有两个规则来源： + + a. 自主访问控制（DAC）： + + 有时，对象的描述中会包含一组规则。这就是所谓的“访问控制列表”或‘ACL’。 + 一个Linux文件可以提供多个ACL。 + + 例如，传统的UNIX文件包括一个权限掩码，它是一个简化的ACL，具有三个固定的 + 主体类别（“用户”、“组”和“其他”），每一个都可以被授予一定的特权（如“读取”、 + “写入”和“执行” —— 无论这些映射对于对象意味着什么）。然而，UNIX文件权限不 + 允许任意指定主体，因此用途有限。 + + Linux文件还可以支持POSIX ACL。这是一个规则列表，为任意主体授予各种权限。 + + b. 强制访问控制（MAC）： + + 整个系统可能有一个或多个规则集，适用于所有主体和对象，不考虑它们的来源。 + SELinux和Smack就是这种情况的例子。 + + 在SELinux和Smack的情况下，每个对象在其凭据中都被赋予一个标签。当请求执 + 行操作时，它们使用主体标签、对象标签和操作，寻找一个规则，该规则表示此操 + 作是授予还是拒绝的。 + + +凭据类型 +======== + +Linux内核支持以下类型的凭据： + + 1. 传统的UNIX凭据。 + + - 真实用户ID + - 真实组ID + + UID和GID由大多数（如果不是全部）Linux对象携带，即使有时它们需要被虚构出 + 来（例如FAT或CIFS文件，这些文件来源于Windows）。这些（通常）定义了该对象 + 的对象上下文，但任务在某些情况下略有不同。 + + - 有效用户ID，保存用户ID和FS用户ID + - 有效组ID，保存组ID和FS组ID + - 补充组 + + 这些是仅由任务使用的额外凭据。通常，一个EUID/EGID/GROUPS 被用作主体上下文， + 而真实UID/GID 被用作对象上下文。对于任务，这并不总是正确的。 + + 2. 能力 + + - 允许的能力集合 + - 可继承的能力集合 + - 有效的能力集合 + - 能力边界集合 + + 这些仅由任务携带，表示授予任务的超出普通任务权限的能力。这些可以通过传统 + UNIX凭据的更改进行隐式操作，但也可以通过 ``capset()`` 系统调用直接操作。 + + 允许的能力是指进程可以通过 ``capset()`` 将其添加到其有效或允许集合中的 + 那些能力。这个可继承的集合也可能受到这样的限制。 + + 有效能力是任务本身实际可以使用的能力。 + + 可继承能力是那些可以通过 ``execve()`` 传递的能力。 + + 边界集限制了通过 ``execve()`` 继承的能力，特别是在以UID 0执行二进制文件时。 + + 3. 安全管理标记（securebits） + + 它们用于控制上述凭据在特定操作如execve()中的操作和继承方式。它们并不直接 + 用作对象或主体凭据使用。 + + 4. 密钥和密钥环 + + 这些仅由任务携带。它们用于携带和缓存不适合放入其他标准UNIX凭据中的安全令牌。 + 它们用诸如使网络文件系统密钥在进程执行的文件访问时可用，而无需让普通程序了解 + 涉及的安全细节。 + + 密钥环是一种特殊类型的密钥。它们携带一组其他密钥，并可以搜索来查找所需的密钥。 + 每个进程可以订阅多个密钥环： + + 每线程密钥 + 每进程密钥环 + 每会话密钥环 + + 当进程访问一个密钥时，若尚不存在，则通常会将其缓存在一个密钥环中，以便将来的 + 访问时找到该密钥。 + + 有关密钥的更多信息，请参见 ``Documentation/translations/zh_CN/security/keys/*`` 。 + + 5. LSM + + Linux安全模块允许在任务执行操作时施加额外的控制。目前，Linux支持几种LSM选项。 + + 一些工作通过标记系统中的对象，并应用一组规则（策略）说明某个标签的任务可以对 + 另一标签的对象执行哪些操作。 + + 6. AF_KEY + + 这是一种基于套接字网络协议栈中的凭据管理[RFC 2367]。本文档中没有讨论它,因为不 + 直接与任务和文件凭据进行交互，而是保留了系统级的凭据。 + + +当打开一个文件时，打开任务的主体上下文的一部分会记录在创建的文件结构中。 +这使得使用该文件结构的操作可以使用这些凭据，而不是发出操作的任务的主体上下文。 +一个例子是在网络文件系统上打开的文件，打开文件的凭据应该被呈现给服务器，而不管 +实际进行读取或写入操作的是谁。 + + +文件标记 +======== + +存储在磁盘上或通过网络获取的文件可能具有注释，构成该文件的对象安全上下文。 +根据文件系统的类型，这些注释可能包括以下一项或多项： + + * UNIX UID, GID, mode; + * Windows user ID; + * Access control list; + * LSM security label; + * UNIX exec privilege escalation bits (SUID/SGID); + * File capabilities exec privilege escalation bits. + +将这些与任务的主体安全上下文进行比较，并根据比较结果允许或禁止执行某些操作。 +在execve()的情况下，特权提升位起作用，并且可能允许由可执行文件的注释决定的 +进程获得额外的特权。 + + +任务凭据 +======== + +在Linux中，一个任务的所有凭据都保存在一个引用计数结构体‘struct cred’中， +通过(uid, gid)或(groups, keys, LSM security)进行访问。每个任务在其 +task_struct中通过一个名为‘cred’的指针指向其凭据。 + +一旦一组凭据已经准备好并提交，除非以下几种情况，否则不能更改： + + 1. 其引用计数可以更改； + + 2. 它所指向的 group_info 结构体的引用计数可以更改； + + 3. 它所指向的安全数据的引用计数可以更改； + + 4. 它所指向的任何密钥环的引用计数可以更改； + + 5. 它所指向的任何密钥环可以被撤销、过期或其安全属性可以更改； + + 6. 它所指向的任何密钥环的内容可以更改（密钥环的整个目的就是作为一组共享凭据， + 可由具有适当访问权限的任何人修改）。 + +要更改cred结构体中的任何内容，必须遵循复制和替换的原则。首先进行复制，然后修 +改副本，最后使用RCU（读-复制-更新）将任务指针更改为指向新的副本。有一些封装可 +用于帮助执行这个过程（见下文）。 + +一个任务只能修改自己的凭据；不再允许一个任务修改另一个任务的凭据。 +这意味着 ``capset()`` 系统调用不再允许使用除当前进程之外的任何PID。 +此外， ``keyctl_instantiate()`` 和 ``keyctl_negate()`` 函数也不再 +允许在请求进程中附加到特定于进程的密钥环，因为实例化进程可能需要创建它们。 + + +不可变凭据 +---------- + +一旦一组凭据已经被公开（例如通过调用 ``commit_creds()`` ），必须将其视为 +不可变的,除了两个例外情况： + + 1. 引用计数可以被修改。 + + 2. 虽然无法更改一组凭据的密钥环订阅，但订阅的密钥环的内容可以被更改。 + +为了在编译时捕获意外的凭据修改，struct task_struct具有_const_指针指向其凭据集， +struct file也是如此。此外，某些函数如 ``get_cred()`` 和 ``put_cred()`` 在 +const指针上操作，因此不需要进行类型转换，但需要临时放弃const限定，以便能够修改 +引用计数。 + + +访问任务凭据 +------------ + +任务只能修改自己的凭据，允许当前进程可以读取或替换自己的凭据，无需任何形式锁定的 +情况下 —— 这极大简化了事情。它可以调用:: + + const struct cred *current_cred() + +获取指向其凭据结构的指针，并且之后不必释放它。 + +有一些方便的封装用于检索任务凭据的特定方面（在每种情况下都只返回值）:: + + uid_t current_uid(void) Current's real UID + gid_t current_gid(void) Current's real GID + uid_t current_euid(void) Current's effective UID + gid_t current_egid(void) Current's effective GID + uid_t current_fsuid(void) Current's file access UID + gid_t current_fsgid(void) Current's file access GID + kernel_cap_t current_cap(void) Current's effective capabilities + struct user_struct *current_user(void) Current's user account + +还有一些方便的封装，用于检索任务凭据的特定关联对:: + + void current_uid_gid(uid_t *, gid_t *); + void current_euid_egid(uid_t *, gid_t *); + void current_fsuid_fsgid(uid_t *, gid_t *); + +在从当前任务的凭据中检索后，通过其参数返回这些值对。 + + +此外，还有一个函数用于获取当前进程的当前凭据集的引用:: + + const struct cred *get_current_cred(void); + +以及用于获取对一个实际上不存在于struct cred中的凭据的引用的函数:: + + struct user_struct *get_current_user(void); + struct group_info *get_current_groups(void); + +分别获得对当前进程的 user accounting structure 和补充组列表的引用。 + +一旦获得引用，就必须使用 ``put_cred（）``, ``free_uid（）`` 或 +``put_group_info（）`` 来适当释放它。 + + +访问其他任务的凭据 +------------------ + +虽然一个任务可以在不需要锁定的情况下访问自己的凭据，但想要访问另一个任务 +的凭据的任务并非如此。它必须使用RCU读锁和 ``rcu_dereference（）``。 + +``rcu_dereference()`` 是由:: + + const struct cred *__task_cred(struct task_struct *task); + +这应该在RCU读锁中使用，如下例所示:: + + void foo(struct task_struct *t, struct foo_data *f) + { + const struct cred *tcred; + ... + rcu_read_lock(); + tcred = __task_cred(t); + f->uid = tcred->uid; + f->gid = tcred->gid; + f->groups = get_group_info(tcred->groups); + rcu_read_unlock(); + ... + } + +如果需要长时间持有另一个任务的凭据，并且可能在此过程中休眠，则调用方 +应该使用以下函数来获取对这些凭据的引用:: + + const struct cred *get_task_cred(struct task_struct *task); + +这个函数内部完成了所有的RCU操作。当使用完这些凭据时，调用方必须调用put_cred() +函数释放它们。 + +.. note:: + ``__task_cred()`` 的结果不应直接传递给 ``get_cred()`` ， + 因为这可能与 ``commit_cred()`` 发生竞争条件。 + +还有一些方便的函数可以访问另一个任务凭据的特定部分，将RCU操作对调用方隐藏起来:: + + uid_t task_uid(task) Task's real UID + uid_t task_euid(task) Task's effective UID + +如果调用方在此时已经持有RCU读锁，则应使用:: + + __task_cred(task)->uid + __task_cred(task)->euid + +类似地，如果需要访问任务凭据的多个方面，应使用RCU读锁，调用 ``__task_cred()`` +函数，将结果存储在临时指针中，然后从临时指针中调用凭据的各个方面，最后释放锁。 +这样可以防止多次调用昂贵的RCU操作。 + +如果需要访问另一个任务凭据的其他单个方面，可以使用:: + + task_cred_xxx(task, member) + +这里的‘member’是cred结构体的非指针成员。例如:: + + uid_t task_cred_xxx(task, suid); + +将从任务中检索‘struct cred::suid’，并执行适当的RCU操作。对于指针成员， +不能使用这种形式，因为它们指向的内容可能在释放RCU读锁的瞬间消失。 + + +修改凭据 +-------- + +如先前提到的，一个任务只能修改自己的凭据，不能修改其他任务的凭据。这意味 +着它不需要使用任何锁来修改自己的凭据。 + +要修改当前进程的凭据，函数应首先调用:: + + struct cred *prepare_creds(void); + +这将锁定current->cred_replace_mutex，然后分配并构建当前进程凭据的副本。 +如果成功，函数返回时仍然保持互斥锁。如果不成功（内存不足），则返回NULL。 + +互斥锁防止 ``ptrace()`` 在进行凭据构建和更改的安全检查时更改进程的ptrace +状态，因为ptrace状态可能会改变结果，特别是在 ``execve()`` 的情况下。 + +新的凭据集应适当地进行修改，并进行任何安全检查和挂钩。在此时，当前和建议的 +凭据集都可用，因为current_cred()将返回当前的凭据集。 + +在替换组列表时，必须在将其添加到凭据之前对新列表进行排序，因为使用二分查找 +测试成员资格。实际上，这意味着在set_groups()或set_current_groups()之 +前应调用groups_sort()。groups_sort()不能在共享的 ``struct group_list`` +上调用，因为即使数组已经排序，它也可能作为排序过程的一部分对元素进行排列。 + +当凭据集准备好时，应通过调用以下函数将其提交给当前进程:: + + int commit_creds(struct cred *new); + +这将修改凭据和进程的各个方面，给LSM提供机会做同样的修改，然后使用 +``rcu_assign_pointer()`` 将新的凭据实际提交给 ``current->cred`` ， +释放 ``current->cred_replace_mutex`` 以允许 ``ptrace()`` 进行操 +作，并通知调度程序和其他组件有关更改的情况。 + +该函数保证返回0，以便可以在诸如 ``sys_setresuid()`` 函数的末尾进行尾调用。 + +请注意，该函数会消耗调用者对新凭据的引用。调用者在此之后不应调用 +``put_cred()`` 释放新凭据。 + +此外，一旦新的凭据上调用了该函数，就不能进一步更改这些凭据。 + + +如果在调用 ``prepare_creds()`` 之后安全检查失败或发生其他错误， +则应调用以下函数:: + + void abort_creds(struct cred *new); + +这将释放 ``prepare_creds()`` 获取的 ``current->cred_replace_mutex`` 的锁， +并释放新的凭据。 + +一个典型的凭据修改函数看起来像这样:: + + int alter_suid(uid_t suid) + { + struct cred *new; + int ret; + + new = prepare_creds(); + if (!new) + return -ENOMEM; + + new->suid = suid; + ret = security_alter_suid(new); + if (ret < 0) { + abort_creds(new); + return ret; + } + + return commit_creds(new); + } + + +管理凭据 +-------- + +有一些函数用来辅助凭据管理: + + - ``void put_cred(const struct cred *cred);`` + + 这将释放对给定凭据集的引用。如果引用计数为零，凭据集将由 + RCU系统安排进行销毁。 + + - ``const struct cred *get_cred(const struct cred *cred);`` + + 这将获取对活动凭据集的引用。返回指向凭据集的指针。 + + - ``struct cred *get_new_cred(struct cred *cred);`` + + 这将获取对当前正在构建且可变的凭据集的引用。返回指向凭据集的指针。 + +打开文件凭据 +============ + +当打开新文件时，会获取对打开任务凭据的引用，并将其附加到文件结构体的 +``f_cred`` 字段中，替代原来的 ``f_uid`` 和 ``f_gid`` 。原来访问 +``file->f_uid`` 和 ``file->f_gid`` 的代码现在应访问 ``file->f_cred->fsuid`` +和 ``file->f_cred->fsgid`` 。 + +安全访问 ``f_cred`` 的情况下可以不使用RCU或加锁，因为指向凭据的指针 +以及指向的凭据结构的内容在文件结构的整个生命周期中保持不变，除非是 +上述列出的例外情况（参阅任务凭据部分）。 + +为了避免“混淆代理”权限提升攻击，在打开的文件后续操作时，访问控制检查 +应该使用这些凭据，而不是使用“当前”的凭据，因为该文件可能已经被传递给 +一个更具特权的进程。 + +覆盖VFS对凭据的使用 +=================== + +在某些情况下，需要覆盖VFS使用的凭据，可以通过使用不同的凭据集调用 +如 ``vfs_mkdir()`` 来实现。以下是一些进行此操作的位置: + + * ``sys_faccessat()``. + * ``do_coredump()``. + * nfs4recover.c. diff --git a/Documentation/translations/zh_CN/security/digsig.rst b/Documentation/translations/zh_CN/security/digsig.rst new file mode 100644 index 000000000000..3e690b504ec5 --- /dev/null +++ b/Documentation/translations/zh_CN/security/digsig.rst @@ -0,0 +1,103 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/digsig.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +=============== +数字签名验证API +=============== + +:作者: Dmitry Kasatkin +:日期: 2011.06.10 + + +.. 内容 + + 1.介绍 + 2.API + 3.用户空间工具 + + +介绍 +==== + +数字签名验证API提供了一种验证数字签名的方法。 +目前，数字签名被IMA/EVM完整性保护子系统使用。 + +数字签名验证是通过精简的GnuPG多精度整数(MPI)库的内核移植来实现的。 +该内核版本提供了内存分配错误处理，已根据内核编码风格进行重构，并修复 +了checkpatch.pl报告的错误和警告。 + +公钥和签名由头部和MPIs组成:: + + struct pubkey_hdr { + uint8_t version; /* 密钥格式版本 */ + time_t timestamp; /* 密钥时间戳，目前为0 */ + uint8_t algo; + uint8_t nmpi; + char mpi[0]; + } __packed; + + struct signature_hdr { + uint8_t version; /* 签名格式版本 */ + time_t timestamp; /* 签名时间戳 */ + uint8_t algo; + uint8_t hash; + uint8_t keyid[8]; + uint8_t nmpi; + char mpi[0]; + } __packed; + +keyid等同对整个密钥的内容进行SHA1哈希运算后的第12到19字节。 +签名头部用于生成签名的输入。这种方法确保了密钥或签名头部无法更改。 +它保护时间戳不被更改，并可以用于回滚保护。 + +API +=== + +目前API仅包含一个函数:: + + digsig_verify() - 使用公钥进行数字签名验证 + + /** + * digsig_verify() - 使用公钥进行数字签名验证 + * @keyring: 查找密钥的密钥环 + * @sig: 数字签名 + * @sigen: 签名的长度 + * @data: 数据 + * @datalen: 数据的长度 + * @return: 成功时返回0，失败时返回 -EINVAL + * + * 验证数据相对于数字签名的完整性。 + * 目前仅支持RSA算法。 + * 通常将内容的哈希值作为此函数的数据。 + * + */ + int digsig_verify(struct key *keyring, const char *sig, int siglen, + const char *data, int datalen); + +用户空间工具 +============ + +签名和密钥管理实用工具evm-utils提供了生成签名、加载密钥到内核密钥环中的功能。 +密钥可以是PEM格式，或转换为内核格式。 +当把密钥添加到内核密钥环时，keyid定义该密钥的名称：下面的示例中为5D2B05FC633EE3E8。 + +以下是keyctl实用工具的示例输出:: + + $ keyctl show + Session Keyring + -3 --alswrv 0 0 keyring: _ses + 603976250 --alswrv 0 -1 \_ keyring: _uid.0 + 817777377 --alswrv 0 0 \_ user: kmk + 891974900 --alswrv 0 0 \_ encrypted: evm-key + 170323636 --alswrv 0 0 \_ keyring: _module + 548221616 --alswrv 0 0 \_ keyring: _ima + 128198054 --alswrv 0 0 \_ keyring: _evm + + $ keyctl list 128198054 + 1 key in keyring: + 620789745: --alswrv 0 0 user: 5D2B05FC633EE3E8 diff --git a/Documentation/translations/zh_CN/security/index.rst b/Documentation/translations/zh_CN/security/index.rst new file mode 100644 index 000000000000..78d9d4b36dca --- /dev/null +++ b/Documentation/translations/zh_CN/security/index.rst @@ -0,0 +1,34 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/index.rst + +:翻译: + + 赵岳辉 Yuehui Zhao <zhaoyuehui@cqsoftware.com.cn> + +======== +安全文档 +======== + +.. toctree:: + :maxdepth: 1 + + credentials + snp-tdx-threat-model + lsm + sak + self-protection + siphash + tpm/index + digsig + landlock + +TODOLIST: +* IMA-templates +* keys/index +* lsm-development +* SCTP +* secrets/index +* ipe diff --git a/Documentation/translations/zh_CN/security/keys/index.rst b/Documentation/translations/zh_CN/security/keys/index.rst new file mode 100644 index 000000000000..7c28d003fb0a --- /dev/null +++ b/Documentation/translations/zh_CN/security/keys/index.rst @@ -0,0 +1,22 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/keys/index.rst + +:翻译: + + +======== +内核密钥 +======== + +.. toctree:: + :maxdepth: 1 + + +TODOLIST: +* core +* ecryptfs +* request-key +* trusted-encrypted diff --git a/Documentation/translations/zh_CN/security/landlock.rst b/Documentation/translations/zh_CN/security/landlock.rst new file mode 100644 index 000000000000..53b449b637b2 --- /dev/null +++ b/Documentation/translations/zh_CN/security/landlock.rst @@ -0,0 +1,123 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. Copyright ? 2017-2020 Micka?l Salaün <mic@digikod.net> +.. Copyright ? 2019-2020 ANSSI +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/landlock.rst + +:翻译: + + 毛玉贤 Yuxian Mao <maoyuxian@cqsoftware.com.cn> + +====================== +Landlock LSM: 内核文档 +====================== + +:作者: Mickaël Salaün +:日期: 2022年12月 + +Landlock的目标是创建有范围的访问控制（即沙箱机制）。为了增强整个 +系统的安全性，此功能应适用于任何进程，包括非特权进程。因为这些进 +程可能被攻击或植入后门（即不可信任的），所以从内核和其他进程的角 +度来看，Landlock的功能必须安全可用。因此，Landlock 的接口设计应当 +尽量减少可能的攻击点。 + +Landlock 旨在为非特权进程使用，同时遵循由其他访问控制机制（例如 DAC、LSM） +强制执行的系统安全策略。Landlock 规则不应与系统上强制执行的其他访问 +控制相冲突，而只能添加额外的限制。 + +任何用户都可以在其进程上强制执行Landlock规则集。这些规则集会以一种 +确保只能添加更多约束的方式与继承的规则集合并和评估。 + + +用户空间文档如下： +Documentation/userspace-api/landlock.rst. + +安全访问控制机制指导原则 +======================== + +* Landlock规则应侧重于对内核对象的访问控制，而非系统调用过滤（即 + 系统调用参数），后者是seccomp-bpf要侧重的。 +* 为了避免多种侧信道攻击（例如安全策略泄露、基于CPU的攻击），Landlock + 规则不应与用户空间进行程序化通信。 +* 内核访问检查不应降低未沙盒化进程的访问请求速度。 +* 与 Landlock 操作相关的计算（例如强制执行规则集）应仅影响请求这些 + 操作的进程。 +* 由沙盒化进程直接从内核中获得的资源（例如文件描述符）在被任何进程 + 使用时，都应保留其获取时的作用域访问权限。 + Cf. `文件描述符访问权限`_. + +设计选择 +======== + +inode访问权限 +------------- + +所有访问权限都与inode以及通过inode所访问到的内容相关。读取目录的 +内容并不意味着有权读取该目录中列出的 inode 所对应文件的内容。实际 +上，文件名是相对于其父目录而言的 ，一个 inode 可以通过多个文件名 +（通过硬链接）来引用。删除文件链接这一操作仅直接影响对应目录，而 +对被移除链接的inode并无影响。这就是“LANDLOCK_ACCESS_FS_REMOVE_FILE” +（文件系统移除文件访问权限）或“LANDLOCK_ACCESS_FS_REFER” （文件系 +统引用访问权限）不能与文件绑定，而只能与目录绑定的原因。 + +文件描述符访问权限 +------------------ + +在打开文件时，会检查访问权限并将其与文件描述符绑定。其基本原则是， +当在相同的 Landlock 域下执行时，等效的操作序列会产生相同的结果。 +以LANDLOCK_ACCESS_FS_TRUNCATE权限为例，如果相关的文件层次结构没有 +授予该访问权限，那么可能允许打开一个文件进行写操作，但不允许使用 +ftruncate调用截断由此产生的文件描述符。 +以下操作序列具有相同的语义，因此会产生相同的结果： + +* ``truncate(path);`` +* ``int fd = open(path, O_WRONLY); ftruncate(fd); close(fd);`` + +与文件访问模式类似（例如O_RDWR），即使文件描述符在进程之间传递 +（例如通过Unix域套接字），文件描述符中的Landlock访问权限也会被保留。 +这些访问权限即使在接收进程未被 Landlock 沙盒化的情况下也会被强制执行。 +事实上，这是为了保持整个系统访问控制的一致性，避免通过文件描述符传递 +而无意中绕过安全限制（即“混淆代理攻击”）。 + +测试 +==== + +用户空间的向后兼容性测试、ptrace 限制测试和文件系统支持测试可以在这里 +找到：tools/testing/selftests/landlock/ + +内核结构 +======== + +对象 +---- + +该API在以下内核代码中： + +security/landlock/object.h + +文件系统 +-------- + +该API在以下内核代码中： + +security/landlock/fs.h + +规则集和域 +---------- + +域是与一组主体（即任务凭证）关联的只读规则集。每次在任务上执行规则集时， +都会复制当前域，并在新域中导入规则集作为新的规则层。 事实上，一旦进入 +一个域，每条规则都与一个层级绑定。要授予对对象的访问权限，每一层中至少 +有一条规则必须允许对该对象执行请求操作。然后，任务只能过渡到一个新的域， +该新域是当前域的约束和任务提供的规则集的约束的交集。任务自行沙盒化时， +主体的定义是隐式的，这使得推理变得更加简单，并有助于避免陷阱。 + +该API在以下内核代码中： + +security/landlock/ruleset.h + +.. Links +.. _tools/testing/selftests/landlock/: + +https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock/ diff --git a/Documentation/translations/zh_CN/security/lsm.rst b/Documentation/translations/zh_CN/security/lsm.rst new file mode 100644 index 000000000000..e0ec4c7831da --- /dev/null +++ b/Documentation/translations/zh_CN/security/lsm.rst @@ -0,0 +1,95 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/lsm.rst + +:翻译: + + 赵岳辉 Yuehui Zhao <zhaoyuehui@cqsoftware.com.cn> + +================================ +Linux安全模块：Linux通用安全钩子 +================================ + +:作者: Stephen Smalley +:作者: Timothy Fraser +:作者: Chris Vance + +.. note:: + + 本文中描述的api已经过时了。 + +介绍 +==== + +在2001年3月，美国国家安全局（NSA）在2.5 Linux内核峰会上做了一个关于安全 +增强Linux（SELinux）的报告。SELinux是Linux内核中一种实现灵活且细粒度的非 +自主访问控制，最初作为自己特定的内核补丁实现。其他一些安全项目（例如RSBAC、 +Medusa）也为Linux内核开发了灵活的访问控制架构，并且多个项目为Linux开发了 +特定的访问控制模型（例如LIDS、DTE、SubDomain）。每个项目都开发并维护了自 +己的内核补丁，以支持其安全需求。 + +针对美国国家安全局的报告，Linus Torvalds发表了一系列言论，描述了一个他愿 +意考虑纳入主流Linux内核的安全框架。他描述了一个通用的框架，该框架将提供 +一组安全钩子来控制对内核对象的操作，同时在内核数据结构中提供一组不透明的 +安全域来维护安全属性。这个框架可以被可加载的内核模块用来实现任何所需的安 +全模型。Linus还提出了将Linux权能代码迁移到这样一个模块中的可能性。 + +Linux安全模块（LSM）项目是由WireX发起开发的这样一个框架。LSM是几个安全 +项目共同开发的成果，包括immununix、SELinux、SGI和Janus，以及包括 +Greg Kroah-Hartman和James Morris在内的几个人，来开发一个实现这一框架的 +Linux内核补丁。这项工作在2003年12月被纳入主流内核。此技术报告概述了该框 +架和权能安全模块的内容。 + +LSM框架 +======= + +LSM框架提供了一个通用的内核框架来支持安全模块。特别地，LSM框架主要关注 +支持访问控制模块，尽管未来的开发可能会解决其他安全需求，比如沙箱。就其 +本身而言，框架不提供任何额外的安全；它仅提供了支持安全模块的基础架构。 +LSM框架是可选的，要求开启 `CONFIG_SECURITY` 配置。权能逻辑作为一个安全 +模块被实现。该权能模块将在 `LSM权能模块`_ 一节中进一步讨论。 + +LSM框架在内核数据结构中包含安全域，并在内核代码的关键点调用钩子函数来 +管理这些安全域并执行访问控制。它还增加了注册安全模块的函数。接口 +/sys/kernel/security/lsm记录了一个以逗号分隔的安全模块列表，这些模块在 +系统中是激活的。 + +LSM安全域只是 ``void*`` 指针。数据被称为blob，这些数据可以由框架或使用 +它的各个安全模块进行管理。多个安全模块共同使用的安全blob通常由框架管理。 +对于进程和程序执行的安全信息，安全域包含在 :c:type: +`struct task_struct <task_struct>` 和 :c:type: `struct cred <cred>` 中。 +对于文件系统的安全信息，安全域包含在 :c:type: +`struct super_block <super_block>` 中。对于管道、文件和套接字的安全信息， +安全域包含在 :c:type: `struct inode <inode>` 和 :c:type: `struct file <file>` +中。对于System V IPC的安全信息，安全域被添加到 :c:type: +`struct kern_ipc_perm <kern_ipc_perm>` 和 :c:type: `struct msg_msg <msg_msg>` +中；另外，:c:type: `struct msg_msg <msg_msg>` 、struct msg_queue和 +struct shmid_kernel的定义被移动到头文件中（ ``include/linux/msg.h`` 和 +``include/linux/shm.h`` 视情况而定），以允许安全模块使用这些定义。 + +对于数据包和网络设备的安全信息，安全域被添加到 :c:type: +`struct sk_buff <sk_buff>` 和 :c:type: `struct scm_cookie <scm_cookie>` 中。 +与其他安全模块数据不同，这里使用的数据是一个32位整数。安全模块需要将这些值 +进行映射或关联到真正的安全属性。 + +LSM钩子被维护在链表中。每个钩子函数都维护一个链表，这些钩子按照CONFIG_LSM中 +指定的顺序被调用。每个钩子的详细文档都包含在 `security/security.c` 源文件中。 + +LSM框架提供了一种近似通用的安全模块堆栈。它定义了security_add_hooks()，每个安 +全模块向它传递一个 :c:type: `struct security_hooks_list <security_hooks_list>` +，该结构会被添加到链表中。LSM框架没有提供移除已注册钩子的机制。SELinux安全 +模块已经实现了一种移除自身的方法，然而该特性已被弃用。 + +这些钩子可以分为两大类：用于管理安全域的钩子和用于执行访问控制的钩子。 +第一类钩子的示例包括security_inode_alloc()和security_inode_free()，这些 +钩子用于为inode对象分配和释放安全结构。第二类钩子的示例是 +security_inode_permission()钩子，该钩子在访问inode时检查权限。 + +LSM权能模块 +=========== + +POSIX.1e 权能逻辑作为一个安全模块维护，存储在文件 ``security/commoncap.c`` +中。权能模块使用 :c:type: `lsm_info` 描述中的order域来标识它为第一个注册 +的安全模块。与其他模块不同，权能安全模块不使用通用的安全blob。其原因是历史 +性的，主要基于开销、复杂性和性能的考虑。 diff --git a/Documentation/translations/zh_CN/security/sak.rst b/Documentation/translations/zh_CN/security/sak.rst new file mode 100644 index 000000000000..574fe076201b --- /dev/null +++ b/Documentation/translations/zh_CN/security/sak.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/sak.rst + +:翻译: + + 张巍 zhangwei <zhangwei@cqsoftware.com.cn> + +=========================== +Linux 安全注意键（SAK）处理 +=========================== + +:日期: 2001年3月18日 +:作者: Andrew Morton + +操作系统的安全注意键是一种安全工具，用于防止系统上存在特洛伊 +木马密码捕获程序。它提供了一种无法规避的方式，用于终止所有可 +能伪装成登录应用程序的程序。用户需要在登录系统之前输入这个安 +全键。 + +从键盘输入的方式生成安全注意键，Linux提供了两种相似但不同的 +方式。一种是按下ALT-SYSRQ-K组合键，但你不应该使用这种方式， +因为它只有在内核启用了SYSRQ支持的情况下才能使用。 + +正确生成SAK的方式是使用``loadkeys``来定义键序列。无论内核是否 +编译了sysrq支持，这种方式都能够正常工作。 + +当键盘处于原始模式时，SAK 能够正常工作。这意味着，一旦定义， +SAK 将终止正在运行的 X 服务器。如果系统处于运行级别 5，X 服 +务器将重新启动，这正是你希望发生的情况。 + +你应该使用什么键序列？ CTRL-ALT-DEL用于重启机器，CTRL-ALT- +BACKSPACE对X服务器有特殊作用。我们将选择CTRL-ALT-PAUSE。 + +在你的rc.sysinit（或rc.local）文件中，添加以下命令:: + + echo "Control Alt keycode 101 = SAK" | /bin/loadkeys + +就这样！只有超级用户才能重新编程SAK键。 + +.. note:: + + 1. Linux SAK据说并不是C2级安全性的系统所要求的"真正的SAK"。 + 该原因作者也不知道 + + 2. 在键盘输入的模式下，SAK会终止所有打开了/dev/console的应用 + 程序。 + + 但是不幸的是，这也包括一些你实际上不希望被终止的程序。原因是 + 这些程序错误的保持了/dev/console的打开状态。务必确保向你的 + Linux发行版提供商投诉这个问题。 + + 你可以用以下的命令来识别将被SAK终止的程序:: + + # ls -l /proc/[0-9]*/fd/* | grep console + l-wx------ 1 root root 64 Mar 18 00:46 /proc/579/fd/0 -> /dev/console + + 然后:: + + # ps aux|grep 579 + root 579 0.0 0.1 1088 436 ? S 00:43 0:00 gpm -t ps/2 + + 所以``gpm``会被SAK杀死。这应该gpm中的bug。它应该正在关闭标准输入， + 你可以通过查找initscript来启动gpm并更改它： + + 老的:: + + daemon gpm + + 新的:: + + daemon gpm < /dev/null + + Vixie cron似乎也有这个问题，并且需要采取相同的处理方式。 + + 此外，某个著名的Linux发行版在它的rc.sysinit和rc scripts的脚本中 + 包含了以下三行代码:: + + exec 3<&0 + exec 4>&1 + exec 5>&2 + + 这些代码会导致所有的守护进程将文件描述符3、4和5关联到/dev/console。 + 所以SAK会将他们所有都终止。一个简单的解决办法就是删掉这些代码，但是 + 这样做会导致系统管理应用程序出现异常 - 要对所有的情况进行充分测试。 diff --git a/Documentation/translations/zh_CN/security/secrets/index.rst b/Documentation/translations/zh_CN/security/secrets/index.rst new file mode 100644 index 000000000000..5ea78713f10e --- /dev/null +++ b/Documentation/translations/zh_CN/security/secrets/index.rst @@ -0,0 +1,17 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/secrets/index.rst + +:翻译: + +===================== +密钥文档 +===================== + +.. toctree:: + + +TODOLIST: + +* coco diff --git a/Documentation/translations/zh_CN/security/self-protection.rst b/Documentation/translations/zh_CN/security/self-protection.rst new file mode 100644 index 000000000000..3c8a68b1e1be --- /dev/null +++ b/Documentation/translations/zh_CN/security/self-protection.rst @@ -0,0 +1,271 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst +:Original: Documentation/security/self-protection.rst + +:翻译: + + 张巍 zhangwei <zhangwei@cqsoftware.com.cn> + +============ +内核自我保护 +============ + +内核自我保护是指在Linux内核中设计与实现的各种系统与结构 +以防止内核本身的安全漏洞问题。它涵盖了广泛问题，包括去除 +整个类的漏洞，阻止安全漏洞利用方法，以及主动检测攻击尝 +试。并非所有的话题都在本文中涉及，但它应该为了解内核自我 +保护提供一个合理的起点，并解答常见的问题。（当然，欢迎提 +交补丁！） + +在最坏的情况下，我们假设一个非特权的本地攻击者对内核内存 +有任意读写访问权限。虽然在许多情况下，漏洞被利用时并不会 +提供此级别的访问权限，但如果我们能防御最坏情况，也能应对 +权限较低的攻击。一个更高的标准，且需要牢记的是保护内核免 +受具有特权的本地攻击者的攻击，因为root用户可以有更多权限。 +（尤其是当他们能够加载任意内核模块时） + +成功的自我保护的目标是：有效、默认开启、不需要开发者主动 +选择、没有性能影响、不妨碍内核调试、并且没有测试。虽然很 +难满足所有的这些目标，但明确提到这些目标非常重要，因为这 +些方面需要被探索、解决或接受。 + +========== +攻击面缩减 +========== + +防止安全漏洞最基本的防御方式是减少可以被用来重定向执行的 +内核区域。这包括限制用户公开使用的API、使内核API更难被错 +误使用、最小化可写内核内存区域等。 + +严格的内核内存权限 +------------------- + +当所有内核内存都是可写的，攻击者可以轻松地重定向执行流。 +为了减少这种攻击目标的可用性，内核需要更严格的权限集来 +保护其内存。 + +可执行代码和只读数据必须不可写 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +任何具有可执行内存的区域必须不可写，显然这也包括内核文本 +本身。我们还必须考虑其他地方：内核模块、JIT内存等，（在 +某些情况下，为了支持像指令替代、断点、kprobes等功能，这些 +区域会暂时被设置为可写。如果这些功能必须存在于内核中，它 +们的实现方式是：在更新期间将内存临时设置可写，然后再恢复 +为原始权限。） + +为了支持这一点，CONFIG_STRICT_KERNEL_RWX 和 +CONFIG_STRICT_MODULE_RWX 的设计旨在确保代码不可写，数据不 +可执行，以及只读数据既不可写也不可执行。 + +大多数架构默认支持这些选项，且用户无法选择。对于一些像arm +这种希望能够选择这些选项的架构，可以在架构Kconfig中选择 +ARCH_OPTIONAL_KERNEL_RWX以启用Kconfig提示。 +CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT决定在启用 +ARCH_OPTIONAL_KERNEL_RWX时的默认设置。 + +函数指针和敏感变量必须不可写 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +内核内存中有大量的函数指针，这些指针被内核查找并用于继续执行 +（例如，描述符/向量表、文件/网络等操作结构等）。这些变量的数 +量必须减少到最低限度 + +许多像这样的变量可以通过设置为"const"来实现只读，从而使它们 +存放在内核的.rodata段而非.data段，从而获得内核严格内存权限的 +保护。 + +对于在_init是仅初始化一次的变量，可以使用_ro_after_init属性 +进行标记。 + +剩下的变量通常是那些更新频率较低的（例如GDT）。这些变量需要另 +一个机制（类似于上述提到的对内核代码所做的临时例外），以便在 +其余生命周期内保持只读状态。（例如，在进行更新时，只有执行 +更新的CPU线程会被授予对内存的不可中断写入访问权限。） + +将内核内存与用户空间内存分隔开 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +内核绝对不可以执行用户空间内存，同时，内核也不得在没有明确预 +期的情况下访问用户内存空间。这些规则可以通过一些硬件限制来支 +持（如x86的SMEP/SMAP，ARM的PXN/PAN）或通过仿真（如ARM的内存 +域）来强制执行。通过这种方式阻止用户空间内存的访问，攻击者就 +无法将执行和数据解析转移到易于控制的用户空间内存，从而迫使攻 +击完全在内核中进行。 + +减少对系统调用的访问 +-------------------- + +对于64位系统，一种消除许多系统调用最简单的方法是构建时不启用 +CONFIG_CONPAT。然而，这种情况通常不可行。 + +“seccomp”系统为用户空间提供了一种可选功能，提供了一种减少可供 +运行中进程使用内核入口点数量的方法。这限制了可以访问内核代码 +的范围，可能降低了某个特定漏洞被攻击者利用的可能性。 + +一个改进的方向是创建有效的方法，仅允许受信任的进程访问例如兼 +容模式、用户命名空间、BPF创建和性能分析等功能。这将把内核入口 +点范围限制在通常可以被非特权用户空间进程访问的较常见集合中 + +限制对内核模块的访问 +-------------------- + +内核绝不应允许非特权用户加载特定的内核模块，因为这可能为攻击者 +提供一个意外扩展的可用攻击面的方法。（通过已预定义子系统按需加 +载模块，如MODULE_ALIAS_*，被认为是“预期的”，但即便如此，也应对 +这些情况给予更多的关注。）例如，通过非特权的套接字API加载文件 +系统模块是没有意义的：只有root用户或物理本地用户应该触发文件系 +统模块的加载。（在某些情况下，这甚至可能存在争议。） + +为了防止特权用户的攻击，系统可能需要完全禁止模块加载（例如，通 +过单体内核构建或modules_disabled sysctl），或者使用签名模块（例 +如，CONFIG_MODULE_SIG_FORCE或通过LoadPin保护的dm-crypt），以防 +止root用户通过模块加载器加载任意内核代码。 + +内存完整性 +---------- + +内核中有许多内存结构在攻击过程中被定期泛滥用以获取执行控制，迄今 +为止，最常见的是堆栈缓冲区溢出，在这种攻击中，堆栈上存储的返回地 +址被覆盖。除此之外，还有许多其他类型的攻击，防护措施也应运而生。 + +堆栈缓冲区溢出 +-------------- + +经典的堆栈缓冲区溢出攻击是指超出栈上分配的变量预期大小，从而将一 +个受控值写入栈帧的返回地址。最常见的防御措施是堆栈保护 +（CONFIG_STACKPROTECTOR），它在函数返回前会验证栈上的“stack canary”。 +其他防御措施还包括影子堆栈等。 + +堆栈深度溢出 +------------ + +一个不太容易被理解的攻击方式是利用bug触发内核通过深度函数调用或 +大的堆栈分配来消耗堆栈内存。通过这种攻击，攻击者可以将数据写入内 +核预分配堆栈空间之外的敏感结构。为了更好的防护这种攻击，必须进行 +两项重要的更改：将敏感的线程信息结构转移到其他地方，并在堆栈底部 +添加一个故障内存洞，以捕获这些溢出 + +栈内存完整性 +------------ + +用于跟踪堆空闲列表的结构可以在分配和释放时进行完整性检查，以确保它 +们不会被用来操作其它内存区域。 + +计算器完整性 +------------ + +内核中的许多地方使用原子计数器来跟踪对象引用或执行类似的生命周期管 +理。当这些计数器可能发生溢出时（无论是上溢还是下溢），这通常会暴露 +出使用后释放（use-after-free）漏洞。通过捕捉原子计数器溢出，这类漏 +洞就可以消失。 + +大小计算溢出检测 +---------------- + +与计算器溢出类似，整数溢出（通常是大小计算）需要在运行时进行检测， +以防止这类在传统上会导致能够写入内核缓冲区末尾之外的漏洞。 + +概率性防御 +---------- + +尽管许多防御措施可以被认定是确定的（例如，只读内存不能写入），但 +有些确保措施仅提供统计防御，即攻击者必须收集足够的关于运行系统的 +信息才能突破防御。尽管这些防御并不完美，但它们确实提供了有意义的 +保护。 + +栈保护、迷惑技术和其他秘密 +-------------------------- + +值得注意的是，像之前讨论的栈保护这样的技术，从技术上来说是统计性防 +御，因为它们依赖于一个秘密值，而这样的值可能会通过信息泄露漏洞而被 +发现。 + +对于想JIT（及时翻译器）这样的情况，其中可执行内容可能部分由用户空间 +控制，也需要类似的秘密之来迷惑。 + +至关重要的是，所使用的秘密值必须是独立的（例如，每个栈使用不同的栈 +保护值），并且具有高熵（例如，随机数生成器（RNG）是否正常工作？）， +以最大限度地提高其成功率。 + +内核地址空间布局随机化（KASLR） +------------------------------- + +由于内核内存的位置几乎总是攻击成功的关键因素，因此使内核内存位置变 +得非确定性会增加攻击的难度。（请注意，这反过来提高了信息泄露的价 +值，因为泄露的信息可以用来发现目标内存位置。） + +文本和模块基址 +-------------- + +通过在启动时重新设定内核的物理基地址和虚拟基地址 +（CONFIG_RANDOMIZE_BASE）,那些需要利用内核代码的攻击将会受阻。此外 +通过偏移模块加载基地址，意味着即使系统每次启动时按相同顺序加载同一 +组模块，这些模块也不会与内核文本的其余部分公用一个基地址。 + +堆栈基地址 +---------- + +如果进程之间内核堆栈的基地址不相同，甚至在不同系统调用之间也不相同， +那么栈上或超出栈的目标位置就会变得更加难以确定。 + +动态内存基址 +------------ + +很多内核的动态内存（例如kmalloc，vmalloc等）由于早期启动初始化的顺 +序，最终布局是相对确定的。如果这些区域的基地址在启动之间不相同，攻 +击者就无法轻易定位它们，必须依赖于针对该区域的信息泄露才能成功。 + +结构布局 +-------- + +通过在每次构建时对敏感结构的布局进行随机化处理，攻击这必须将攻击调 +节到已知的内核版本，或者泄露足够的内核内存来确定结构布局，然后才能 +对其进行操作。 + +防止信息泄露 +------------ + +由于敏感结构的位置是攻击的主要目标，因此防止内核内存地址和内核内存 +内容泄露非常重要（因为它们可能包含内核地址或者其他敏感数据，例如 +栈保护值）。 + +内核地址 +-------- + +将内核地址打印到用户空间会泄露有关内核内存布局的敏感信息。在使用任 +何打印符号打印原始地址时，目前%px,%p[ad]（和在某些情况下的%p[sSb]） +时。使用这些格式符写入的文件需要限制为只有特权进程可读。 + +在4.14及以前的内核版本中，使用%p格式符打印的是原始地址。从4.15-rcl +版本开始，使用%p格式符打印的地址会在打印前进行哈希处理。 + +[*]如果启用KALLSYMS并且符号查找失败，则打印原始地址；如果没有启用 +KALLSYSM，则会直接打印原始地址。 + +唯一标识符 +---------- + +内核内存地址绝不可能用作向用户空间公开的标识符。相反，应该使用原子 +计数器，IDR（ID映射表）或类似的唯一标识符。 + +内存初始化 +---------- + +复制到用户空间的内存必须始终被完全初始化，如果没有显式地使用memset() +函数进行初始化，那就需要修改编译器，确保清除结构中的空洞。 + +内存清除 +-------- + +在释放内存时，最好对内存内容进行清除处理，以防止攻击者重用内存中以前 +的内容。例如，在系统调用返回时清除堆栈（CONFIG_GCC_PLUGIN_STACKLEAK）, +在释放堆内容是清除其内容。这有助于防止许多未初始化变量攻击、堆栈内容 +泄露、堆内容泄露以及使用后释放攻击（user-after-free）。 + +目标追踪 +-------- + +为了帮助消除导致内核地址被写入用户空间的各种错误，需要跟踪写入的目标。 +如果缓冲区的目标是用户空间（例如，基于seq_file的/proc文件），则应该自 +动审查敏感值。 diff --git a/Documentation/translations/zh_CN/security/siphash.rst b/Documentation/translations/zh_CN/security/siphash.rst new file mode 100644 index 000000000000..26dd8be699b3 --- /dev/null +++ b/Documentation/translations/zh_CN/security/siphash.rst @@ -0,0 +1,195 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst +:Original: Documentation/security/siphash.rst + +:翻译: + + 张巍 zhangwei <zhangwei@cqsoftware.com.cn> + +===================================== +SipHash - 一种短输入伪随机函数（PRF） +===================================== + +：作者: Jason A.Donenfeld <jason@zx2c4.com> + +SipHash是一种加密安全的伪随机函数，即一种用于生成伪随机密钥的哈 +希函数，因为其在处理短输入时表现出色，因此得名。其由密码学家 +Daniel J. Bernstein和Jean-Philippe Aumasson设计。目的主要是替 +代其他哈希函数，例如：jhash，md5_transform，sha1_transform等。 + +SipHash采用一个完全由随机数生成的密钥，以及一个输入缓冲区或者 +多个输入整数，它输出一个与随机数难以区分的整数，你可以将它作 +为安全序列、安全cookies的一部分，或者对其进行掩码处理，以便在 +哈希表中使用。 + +生成密钥 +======== + +密钥应来源于加密安全的随机数生成，要么使用get random bytes +要么使用get random once:: + + siphash_key_t key; + get_random_bytes(&key, sizeof(key)); + +如果你的密钥来源不是这两个，那么你的做法是错的。 + +使用函数 +======== + +这个函数有两个变种，一种是接受整数列表，另一种是接受缓冲区:: + + u64 siphash(const void *data, size_t len, const siphash_key_t *key); + +和:: + + u64 siphash_1u64(u64, const siphash_key_t *key); + u64 siphash_2u64(u64, u64, const siphash_key_t *key); + u64 siphash_3u64(u64, u64, u64, const siphash_key_t *key); + u64 siphash_4u64(u64, u64, u64, u64, const siphash_key_t *key); + u64 siphash_1u32(u32, const siphash_key_t *key); + u64 siphash_2u32(u32, u32, const siphash_key_t *key); + u64 siphash_3u32(u32, u32, u32, const siphash_key_t *key); + u64 siphash_4u32(u32, u32, u32, u32, const siphash_key_t *key); + +如果向一个通用的hsiphash函数传递一个恒定长度的常量，他将 +在编译的时候将常量折叠，并自动选择一个优化后的函数。 + +哈希表键函数的用法:: + + struct some_hashtable { + DECLARE_HASHTABLE(hashtable, 8); + siphash_key_t key; + }; + + void init_hashtable(struct some_hashtable *table) + { + get_random_bytes(&table->key, sizeof(table->key)); + } + + static inline hlist_head *some_hashtable_bucket(struct some_hashtable *table, struct interesting_input *input) + { + return &table->hashtable[siphash(input, sizeof(*input), &table->key) & (HASH_SIZE(table->hashtable) - 1)]; + } + +然后，你可以像往常一样对返回的哈希存储桶进行迭代。 + +安全性 +====== + +SipHash有着非常高的安全性,因为其有128位的密钥。只要密钥是保密的， +即使攻击者看到多个输出，也无法猜测出函数的正确输出，因为2^128次 +方个输出是非常庞大的。 + +Linux实现了SipHash的“2-4”变体 + +Struct-passing陷阱 +================== + +通常情况下，XuY函数的输出长度不够大，因此你可能需要传递一个预填充 +的结构体给SipHash，在这样做时，务必确保结构体没有填充空隙，最简单 +的方法就是将结构体的成员按照大小降序的方式排序，并且使用offsetofend() +函数代替sizeof()来获取结构体大小，出于性能的考虑，如果可以的话，最 +好将结构体按右边界对齐，示例如下:: + + const struct { + struct in6_addr saddr; + u32 counter; + u16 dport; + } __aligned(SIPHASH_ALIGNMENT) combined = { + .saddr = *(struct in6_addr *)saddr, + .counter = counter, + .dport = dport + }; + u64 h = siphash(&combined, offsetofend(typeof(combined), dport), &secret); + +资源 +==== + +如果你有兴趣了解更多信息，请阅读SipHash论文: +https://131002.net/siphash/siphash.pdf + +------------------------------------------------------------------------------- + +=========================================== +HalfSipHash 是 SipHash 的一个较不安全的变种 +=========================================== + +：作者: Jason A.Donenfeld <jason@zx2c4.com> + +如果你认为SipHash的速度不够快，无法满足你的需求，那么你可以 +使用HalfSipHash，这是一种令人担忧但是有用的选择。HalfSipHash +将SipHash的轮数从“2-4”降低到“1-3”，更令人担心的是，它使用一 +个容易被穷举攻击的64位密钥(输出为32位)，而不是SipHash的128位 +密钥，不过，这对于要求高性能“jhash”用户来说这是比较好的选择。 + +HalfSipHash是通过 "hsiphash" 系列函数提供的。 + +.. warning:: + 绝对不要在作为哈希表键函数之外使用hsiphash函数，只有在你 + 能完全能确定输出永远不会从内核传输出去的情况下才能使用， + 作为缓解哈希表泛洪拒绝服务攻击的一种手段，它仅在某些情况 + 下比jhash好用。 + +在64位的内核中，hsiphash函数实际上实现的是SipHash-1-3，这是一 +种减少轮数的SipHash变形，而不是HalfSipHash-1-3。这是因为在64位 +代码中SipHash-1-3的性能与HalfSipHash-1-3相当，甚至可能更快，请 +注意，这并不意味这在64位的内核中，hsihpash函数与siphash函数相 +同，也不意味着他们是安全的；hsihash函数仍然使用一种不太安全的 +减少轮数的算法，并将输出截断为32位。 + +生成哈希密钥 +============ + +密钥应始终来源于加密安全的随机数生成，要么使用get random bytes +要么使用get random once:: + + hsiphash_key_t key; + get_random_bytes(&key, sizeof(key)); + +如果你的钥匙来源不是这两个，那么你的做法是错的。 + +使用哈希函数 +============ + +这个函数有两种变体，一个是接受整数列表，另一种是接受缓冲区:: + + u32 hsiphash(const void *data, size_t len, const hsiphash_key_t *key); + +和:: + + u32 hsiphash_1u32(u32, const hsiphash_key_t *key); + u32 hsiphash_2u32(u32, u32, const hsiphash_key_t *key); + u32 hsiphash_3u32(u32, u32, u32, const hsiphash_key_t *key); + u32 hsiphash_4u32(u32, u32, u32, u32, const hsiphash_key_t *key); + +如果向一个通用的hsiphash函数传递一个恒定长度的常量，他将在编译 +的时候将常量折叠，并自动选择一个优化后的函数。 + +哈希表键函数的用法 +================== + +:: + + struct some_hashtable { + DECLARE_HASHTABLE(hashtable, 8); + hsiphash_key_t key; + }; + + void init_hashtable(struct some_hashtable *table) + { + get_random_bytes(&table->key, sizeof(table->key)); + } + + static inline hlist_head *some_hashtable_bucket(struct some_hashtable *table, struct interesting_input *input) + { + return &table->hashtable[hsiphash(input, sizeof(*input), &table->key) & (HASH_SIZE(table->hashtable) - 1)]; + } + +然后，你可以像往常一样对返回的哈希存储桶进行迭代。 + +性能 +==== + +hsiphash()大约比jhash()慢三倍，这是因为有许多替换，不过这些都不是问题， +因为哈希表查找不是瓶颈。而且，这些牺牲是为了hsiphash()的安全性和DoS抗 +性，这是值得的。 diff --git a/Documentation/translations/zh_CN/security/snp-tdx-threat-model.rst b/Documentation/translations/zh_CN/security/snp-tdx-threat-model.rst new file mode 100644 index 000000000000..b51eeaebab67 --- /dev/null +++ b/Documentation/translations/zh_CN/security/snp-tdx-threat-model.rst @@ -0,0 +1,209 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/snp-tdx-threat-model.rst + +:翻译: + + 毛玉贤 Yuxian Mao <maoyuxian@cqsoftware.com.cn> + +========================== +Linux中x86虚拟化的机密计算 +========================== + +.. contents:: :local: + +By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao.osdev@gmail.com> + +动机 +==== + +在x86虚拟环境中从事机密计算工作的内核开发人员，是基于一组与传统Linux内核 +威胁模型有所不同的假设条件下开展工作的。传统意义上，Linux威胁模型承认攻 +击者可以存在于用户空间，以及一小部分能够通过各种网络接口或有限的硬件特定 +暴露接口（如USB、Thunderbolt）与内核交互的外部攻击者。本文档的目的是解释 +在机密计算领域中出现的额外攻击向量，并讨论为 Linux 内核提出的保护机制。 + +概述与术语 +========== + +机密计算（Confidential Computing，简称CoCo）是一个广泛的术语，涵盖了多种 +旨在保护数据在使用过程中（与静态数据或传输数据相比）的机密性和完整性的安 +全技术。从本质上讲，机密计算（CoCo）解决方案提供了一个受信任执行环境（TEE）， +在该环境中可以进行安全的数据处理，因此，它们通常根据预期在TEE中运行的软件 +来进一步划分为不同的子类型。本文档专注于一类针对虚拟化环境的机密计算技术 +（Confidential Computing, CoCo），这些技术允许在可信执行环境 +（Trusted Execution Environment, TEE）中运行虚拟机（VM）。从现在起，本文档 +将把这一类机密计算（CoCo）技术称为“虚拟化环境（VE）中的机密计算（CoCo）”。 + +在虚拟化环境中，机密计算（CoCo）指的是一组硬件和/或软件技术，这些技术能够 +为在CoCo虚拟机（VM）内运行的软件提供更强的安全保障。具体来说，机密计算允许 +其用户确认所有软件组件的可信度，从而将其包含在精简的受信任计算基（TCB）中， +这是基于机密计算具备验证这些受信组件状态的能力。 + +虽然不同技术之间的具体实现细节有所不同，但所有现有机制都旨在为虚拟机的客户 +内存和执行状态（vCPU寄存器）提供更高的机密性和完整性，更严格地控制客户中断 +注入，并提供一些额外机制来控制客户与宿主机之间的页映射。有关x86特定解决方案 +的更多细节，可以参考 +:doc:`Intel Trust Domain Extensions (TDX) </arch/x86/tdx>` 和 +`AMD Memory Encryption <https://www.amd.com/system/files/techdocs/sev-snp-strengthening-vm-isolation-with-integrity-protection-and-more.pdf>`_. + +基本的机密计算（CoCo）客户布局包括宿主机、客户机、用于客户机与宿主机之间通信 +的接口、能够支持CoCo虚拟机（VM）的平台，以及一个在客户VM和底层平台之间充当安 +全管理员的可信中介。宿主机侧的虚拟机监视器（VMM）通常由传统VMM功能的一个子集 +组成，并仍然负责客户机生命周期的管理，即创建或销毁CoCo虚拟机、管理其对系统资 +源的访问等。然而，由于它通常不在CoCo VM的可信计算基（TCB）内，其访问权限受到 +限制，以确保实现安全目标。 + +在下图中，"<--->" 线表示机密计算（CoCo）安全管理员与其余组件之间的双向通信通 +道或接口，这些组件包括客户机、宿主机和硬件（数据流）:: + + +-------------------+ +-----------------------+ + | CoCo guest VM |<---->| | + +-------------------+ | | + | Interfaces | | CoCo security manager | + +-------------------+ | | + | Host VMM |<---->| | + +-------------------+ | | + | | + +--------------------+ | | + | CoCo platform |<--->| | + +--------------------+ +-----------------------+ + +机密计算（CoCo）安全管理器的具体细节在在不同技术之间存在显著差异。例如，在某 +些情况下，它可能通过硬件（HW）实现，而在其他情况下，它可能是纯软件（SW）实现。 + +现有的Linux内核威胁模型 +======================= + +当前Linux内核威胁模型的总体组件包括:: + + +-----------------------+ +-------------------+ + | |<---->| Userspace | + | | +-------------------+ + | External attack | | Interfaces | + | vectors | +-------------------+ + | |<---->| Linux Kernel | + | | +-------------------+ + +-----------------------+ +-------------------+ + | Bootloader/BIOS | + +-------------------+ + +-------------------+ + | HW platform | + +-------------------+ + +在启动过程中，引导加载程序（bootloader）和内核之间也存在通信，但本图并未明确 +表示这一点。“接口”框表示允许内核与用户空间之间通信的各种接口。 这包括系统调用、 +内核 API、设备驱动程序等。 + +现有的 Linux 内核威胁模型通常假设其在一个受信任的硬件平台上执行，并且所有固件 +和启动加载程序都包含在该平台的受信任计算基（TCB）中。主要攻击者驻留在用户空间 +中，来自用户空间的所有数据通常被认为是不可信的，除非用户空间具有足够的特权来 +执行受信任的操作。此外，通常还会考虑外部攻击者，包括那些能够访问启用的外部网络 +（例如以太网、无线网络、蓝牙）、暴露的硬件接口（例如 USB、Thunderbolt），以及 +能够离线修改磁盘内容的攻击者。 + +关于外部攻击途径，值得注意的是，在大多数情况下，外部攻击者会首先尝试利用用户空 +间的漏洞，但攻击者也可能直接针对内核，特别是在宿主机具有物理访问权限的情况下。直 +接攻击内核的例子包括漏洞 CVE-2019-19524、CVE-2022-0435 和 CVE-2020-24490。 + +机密计算威胁模型及其安全目标 +============================ + +机密计算在上述攻击者列表中增加了一种新的攻击者类型：可能存在行为不当的宿主机 +（这可能包括传统虚拟机监视器VMM的部分组件或全部），由于其较大的软件攻击面， +通常被置于CoCo VM TCB之外。需要注意的是，这并不意味着宿主机或VMM是故意恶意的， +而是强调拥有一个较小的CoCo VM TCB具有安全价值。这种新型的攻击者可以被视为一种 +更强大的外部攻击者，因为它位于同一物理机器上（与远程网络攻击者不同），并且对 +客户机内核与大部分硬件的通信具有控制权:: + + +------------------------+ + | CoCo guest VM | + +-----------------------+ | +-------------------+ | + | |<--->| | Userspace | | + | | | +-------------------+ | + | External attack | | | Interfaces | | + | vectors | | +-------------------+ | + | |<--->| | Linux Kernel | | + | | | +-------------------+ | + +-----------------------+ | +-------------------+ | + | | Bootloader/BIOS | | + +-----------------------+ | +-------------------+ | + | |<--->+------------------------+ + | | | Interfaces | + | | +------------------------+ + | CoCo security |<--->| Host/Host-side VMM | + | manager | +------------------------+ + | | +------------------------+ + | |<--->| CoCo platform | + +-----------------------+ +------------------------+ + +传统上，宿主机对客户机数据拥有无限访问权限，并可以利用这种访问权限来攻击客户虚 +拟机。然而，机密计算（CoCo）系统通过添加诸如客户数据保密性和完整性保护等安全 +特性来缓解此类攻击。该威胁模型假设这些安全特性是可用且完好的。 + +这个 **Linux内核机密计算虚拟机（CoCo VM）的安全目标** 可以总结如下： + +1. 保护CoCo客户机私有内存和寄存器的机密性和完整性。 + +2. 防止宿主机特权升级到CoCo客户机Linux内核。虽然宿主机（及主机端虚拟机管理程序） + 确实需要一定的特权来创建、销毁或暂停访客，但防止特权升级的部分目标是确保这些 + 操作不会为攻击者提供获取客户机内核访问权限的途径。 + +上述安全目标导致了两个主要的**Linux内核机密计算虚拟机（CoCo VM）资产**： + +1. 客户机内核执行上下文。 +2. 客户机内核私有内存。 + +宿主机对CoCo客户机资源具有完全控制权，并可以随时拒绝访问这些资源。资源的示例包 +括CPU时间、客户机可以消耗的内存、网络带宽等。因此，宿主机对CoCo客户机的拒绝服务 +（DoS）攻击超出了此威胁模型的范围。 + +Linux CoCo虚拟机攻击面是指从CoCo客户机Linux内核暴露到不受信任的主机的任何接口， +这些接口未被CoCo技术的软硬件保护所覆盖。这包括所有可能的侧信道攻击以及瞬态执 +行侧信道攻击。显式（非旁道）接口的示例包括访问端口I/O、内存映射I/O（MMIO）和 +直接内存访问（DMA）接口、访问PCI配置空间、特定于虚拟机管理程序（VMM）的超调用 +（指向主机端VMM）、访问共享内存页、主机允许注入到访客内核的中断，以及特定于 +CoCo技术的超调用（如果存在）。此外，在CoCo系统中，宿主机通常控制创建CoCo客户机 +的过程：它有方法将固件和引导程序镜像、内核镜像以及内核命令行加载到客户机中。所有 +这些数据在通过证明机制确认其完整性和真实性之前，都应视为不可信的。 + +下表显示了针对CoCo客户机Linux内核的威胁矩阵，但并未讨论潜在的缓解策略。该矩阵涉 +及的是CoCo特定版本的客户机、宿主机和平台。 + +.. list-table:: CoCo Linux客户机内核威胁矩阵 + :widths: auto + :align: center + :header-rows: 1 + + * - 威胁名称 + - 威胁描述 + + * - 客户机恶意配置 + - 一个行为不当的主机修改了以下其中一个客户机的配置： + + 1. 客户机固件或引导加载程序 + + 2. 客户机内核或模块二进制文件 + + 3. 客户机命令行参数 + + 这使得宿主机能够破坏在CoCo客户虚拟机内部运行代码的完整性，从而违反了机密计算 + （CoCo）的安全目标。 + + * - CoCo客户机数据攻击 + - 一个行为不当的宿主机对CoCo客户虚拟机与宿主机管理的物理或虚拟设备之间传输的数 + 据拥有完全控制权。这使得宿主机可以对这类数据的保密性、完整性和新鲜性进行任何攻击。 + + * - 格式错误的运行时输入 + - 一个行为不当的宿主机通过客户机内核代码使用的任意通信接口注入格式错误的输入。 + 如果代码没有正确处理这些输入，这可能导致从宿主机到客户机内核的特权提升。这包 + 括传统的侧信道攻击和/或瞬态执行攻击路径。 + + * - 恶意运行时输入 + - 一个行为不当的宿主机通过客户机内核代码使用的任意通信接口注入特定的输入值。与之前 + 的攻击向量（格式错误的运行时输入）不同，这个输入并非格式错误，而是其值被精心设 + 计以影响客户机内核的安全性。这类输入的例子包括向客户机提供恶意的时间或向客户机 + 的随机数生成器提供熵值。此外，如果它导致客户机内核执行特定操作（例如处理主机注 + 入的中断），此类事件的时序本身也可能成为一种攻击路径。这种攻击是对提供的宿主机输 + 入具有抵抗性的一种方式。 diff --git a/Documentation/translations/zh_CN/security/tpm/index.rst b/Documentation/translations/zh_CN/security/tpm/index.rst new file mode 100644 index 000000000000..707646590647 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/index.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +================ +可信平台模块文档 +================ + +.. toctree:: + + tpm_event_log + tpm-security + tpm_tis + tpm_vtpm_proxy + xen-tpmfront + tpm_ftpm_tee diff --git a/Documentation/translations/zh_CN/security/tpm/tpm-security.rst b/Documentation/translations/zh_CN/security/tpm/tpm-security.rst new file mode 100644 index 000000000000..26818d28c98f --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm-security.rst @@ -0,0 +1,151 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm-security.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +TPM安全 +======= + +本文档的目的是描述我们如何使内核使用TPM在面对外部窥探和数据包篡改 +攻击（文献中称为被动和主动中间人攻击）时保持合理的稳健性。当前的 +安全文档适用于TPM2.0。 + +介绍 +---- + +TPM通常是一个通过某种低带宽总线连接到PC的独立芯片。虽然有一些 +例外，例如Intel PTT，它是运行在靠近CPU的软件环境中的软件TPM， +容易受到不同类型的攻击，但目前大多数强化的安全环境要求使用独立 +硬件TPM，这是本文讨论的使用场景。 + +总线上的窥探和篡改攻击 +---------------------- + +当前的技术状态允许使用 `TPM Genie`_ 硬件中间人，这是一种简单的外部设备，可以在 +任何系统或笔记本电脑上几秒钟内安装。最近成功演示了针对 `Windows Bitlocker TPM`_ +系统的攻击。最近同样的攻击针对 `基于TPM的Linux磁盘加密`_ 方案也遭到了同样的攻击。 +下一阶段的研究似乎是入侵总线上现有的设备以充当中间人，因此攻击者需要物理访问几 +秒钟的要求可能不再存在。然而，本文档的目标是尽可能在这种环境下保护TPM的机密性和 +完整性，并尝试确保即使我们不能防止攻击，至少可以检测到它。 + +不幸的是，大多数TPM功能，包括硬件重置功能，都能被能够访问总线的攻击 +者控制，因此下面我们将讨论一些可能出现的干扰情况。 + +测量（PCR）完整性 +----------------- + +由于攻击者可以向TPM发送自己的命令，他们可以发送任意的PCR扩展，从而破 +坏测量系统，这将是一种烦人的拒绝服务攻击。然而，针对密封到信任测量中 +的实体，有两类更严重的攻击。 + +1. 攻击者可以拦截来自系统的所有PCR扩展，并完全替换为自己的值，产生 + 一个未篡改状态的重现，这会使PCR测量证明状态是可信的，并释放密钥。 + +2. 攻击者可能会在某个时刻重置TPM，清除PCR，然后发送自己的测量，从而 + 有效地覆盖TPM已经完成的启动时间测量。 + +第一种攻击可以通过始终对PCR扩展和读取命令进行HMAC保护来防止，这意味着 +如果没有在响应中产生可检测的HMAC失败，则测量值无法被替换。然而第二种 +攻击只能通过依赖某种机制来检测，这种机制会在TPM重置后发生变化。 + +秘密保护 +-------- + +某些进出TPM的信息,如密钥密封、私钥导入和随机数生成容易被拦截，而仅仅 +使用HMAC保护无法防止这种情况。因此，对于这些类型的命令，我们必须使用 +请求和响应加密来防止秘密信息的泄露。 + +与TPM建立初始信任 +----------------- + +为了从一开始就提供安全性，必须建立一个初始的共享或非对称秘密，并且该 +秘钥必须对攻击者不可知。最明显的途径是使用背书和存储种子，这些可以用 +来派生非对称密钥。然而，使用这些密钥很困难，因为将它们传递给内核的唯 +一方法是通过命令行，这需要在启动系统中进行广泛的支持，而且无法保证任 +何一个层次不会有任何形式的授权。 + +Linux内核选择的机制是从空种子使用标准的存储种子参数派生出主椭圆曲线 +密钥。空种子有两个优势：首先该层次物理上无法具有授权，因此我们始终可 +以使用它；其次空种子在TPM重置时会发生变化，这意味着如果我们在当天开始 +时基于空种子建立信任，如果TPM重置且种子变化，则所有派生的密钥进行加盐 +处理的会话都将失败。 + +显然，在没有任何其他共享秘密的情况下使用空种子，我们必须创建并读取初始 +公钥，这当然可能会被总线中间人拦截并替换。然而，TPM有一个密钥认证机制 +（使用EK背书证书，创建认证身份密钥，并用该密钥认证空种子主密钥），但由 +于它过于复杂，无法在内核中运行，因此我们保留空主密钥名称的副本，通过 +sysfs导出，以便用户空间在启动时进行完整的认证。这里的明确保证是，如果空 +主密钥认证成功，那么从当天开始的所有TPM交易都是安全的；如果认证失败，则 +说明系统上有中间人（并且任何在启动期间使用的秘密可能已被泄露）。 + +信任堆叠 +-------- + +在当前的空主密钥场景中，TPM必须在交给下一个使用者之前完全清除。然而， +内核将派生出的空种子密钥的名称传递给用户空间，用户空间可以通过认证来 +验证该名称。因此，这种名称传递链也可以用于各个启动组件之间（通过未指 +定的机制）。例如grub可以使用空种子方案来实现安全性，并将名称交给内核。 +内核可以派生出密钥和名称，并确定如果它们与交接的版本不同，则表示发生 +了篡改。因此可以通过名称传递将任意启动组件（从UEFI到grub到内核）串联 +起来，只要每个后续组件知道如何收集该名称,并根据其派生的密钥进行验证。 + +会话属性 +-------- + +所有内核使用的TPM命令都允许会话。HMAC会话可用于检查请求和响应的完整性， +而解密和加密标志可用于保护参数和响应。HMAC和加密密钥通常是从共享授权秘 +钥推导出来的，但对于许多内核操作来说，这些密钥是已知的（通常为空）。因 +此内核使用空主密钥作为盐密钥来创建每个HMAC会话，这样就为会话密钥的派生 +提供了加密输入。因此内核仅需创建一次空主密钥（作为一个易失的TPM句柄）， +并将其保存在tpm_chip中，用于每次在内核中使用TPM时。由于内核资源管理器缺 +乏去间隙化，当前每次操作都需要创建和销毁会话，但未来可能会将单个会话重用 +用于内核中的HMAC、加密和解密会话。 + +保护类型 +-------- + +对于每个内核操作，我们使用空主密钥加盐的HMAC来保护完整性。此外我们使用参数 +加密来保护密钥密封，并使用参数解密来保护密钥解封和随机数生成。 + +空主密钥认证在用户空间的实现 +============================ + +每个TPM都会附带几个X.509证书，通常用于主背书密钥。本文档假设存在椭圆曲线 +版本的证书，位于01C00002，但也同样适用于RSA证书(位于01C00001)。 + +认证的第一步是使用 `TCG EK Credential Profile`_ 模板进行主密钥的创建，该 +模板允许将生成的主密钥与证书中的主密钥进行比较（公钥必须匹配）。需要注意 +的是，生成EK主密钥需要EK层级密码，但EC主密钥的预生成版本应位于81010002， +并且可以无需密钥授权对其执行TPM2_ReadPublic()操作。接下来，证书本身必须 +经过验证，以确保其可以追溯到制造商根证书（该根证书应公开在制造商网站上）。 +完成此步骤后将在TPM内部生成一个认证密钥（AK），并使用TPM2_MakeCredential、 +AK的名称和EK公钥加密一个秘密。然后TPM执行TPM2_ActivateCredential，只有在 +TPM、EK和AK之间的绑定关系成立时，才能恢复秘密。现在，生成的AK可以用于对由 +内核导出的空主密钥进行认证。由于TPM2_MakeCredential/ActivateCredential操作 +相对复杂，下面将描述一种涉及外部生成私钥的简化过程。 + +这个过程是通常基于隐私CA认证过程的简化缩写。假设此时认证由TPM所有者进行， +所有者只能访问所有者层次。所有者创建一个外部公/私钥对（假设是椭圆曲线）， +并使用内部包装过程将私钥进行封装以便导入，该私钥被其父级由EC派生的存储主密 +钥保护。TPM2_Import()操作使用一个以EK主密钥为盐值的参数解密HMAC会话（这也不 +需要EK密钥授权），意味着内部封装密钥是加密参数，因此除非TPM拥有认证的EK，否 +则无法执行导入操作。如果该命令成功执行并且HMAC在返回时通过验证，我们就知道 +我们有一个只为认证TPM加载的私钥副本。现在该密钥已加载到TPM中，并且存储主密 +钥已被清除（以释放空间用于生成空密钥）。 + +现在根据 `TCG TPM v2.0 Provisioning Guidance`_ 中的存储配置生成空EC主密钥； +该密钥的名称（即公钥区域的哈希值）被计算出来并与内核在/sys/class/tpm/tpm0/null_name +中提供的空种子名称进行比较。如果名称不匹配，TPM就被认为是受损的。如果名称匹配， +用户执行TPM2_Certify()，使用空主密钥作为对象句柄，使用加载的私钥作为签名句柄， +并提供随机的合格数据。返回的certifyInfo的签名将与加载的私钥的公钥部分进行验证， +并检查合格数据以防止重放。如果所有测试都通过，用户就可以确信TPM的完整性和隐私 +性在整个内核启动过程中得到了保护。 + +.. _TPM Genie: https://www.nccgroup.trust/globalassets/about-us/us/documents/tpm-genie.pdf +.. _Windows Bitlocker TPM: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network +.. _基于TPM的Linux磁盘加密: https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets +.. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/ +.. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/ diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_event_log.rst b/Documentation/translations/zh_CN/security/tpm/tpm_event_log.rst new file mode 100644 index 000000000000..9c173291ac3e --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_event_log.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_event_log.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +=========== +TPM事件日志 +=========== + +本文档简要介绍了什么是TPM日志，以及它是如何从预启动固件移交到操作系统的。 + +介绍 +==== + +预启动固件维护一个事件日志，每当它将某些内容哈希到任何一个PCR寄存器时，该 +日志会添加新条目。这些事件按类型分类，并包含哈希后的PCR寄存器值。通常，预 +启动固件会哈希那些即将移交执行权或与启动过程相关的组件。 + +其主要应用是远程认证，而它之所以有用的原因在[1]中第一部分很好地阐述了： + +认证用于向挑战者提供有关平台状态的信息。然而，PCR的内容难以解读；因此，当 +PCR内容附有测量日志时，认证通常会更有用。尽管测量日志本身并不可信，但它们 +包含比PCR内容更为丰富的信息集。PCR内容用于对测量日志进行验证。 + +UEFI事件日志 +============ + +UEFI提供的事件日志有一些比较奇怪的特性。 + +在调用ExitBootServices()之前，Linux EFI引导加载程序会将事件日志复制到由 +引导加载程序自定义的配置表中。不幸的是，通过ExitBootServices()生成的事件 +并不会出现在这个表里。 + +固件提供了一个所谓的最终事件配置表排序来解决这个问题。事件会在第一次调用 +EFI_TCG2_PROTOCOL.GetEventLog()后被镜像到这个表中。 + +这引出了另一个问题：无法保证它不会在 Linux EFI stub 开始运行之前被调用。 +因此，在 stub 运行时，它需要计算并将最终事件表的大小保存到自定义配置表中， +以便TPM驱动程序可以在稍后连接来自自定义配置表和最终事件表的两个事件日志时 +跳过这些事件。 + +参考文献 +======== + +- [1] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/ +- [2] The final concatenation is done in drivers/char/tpm/eventlog/efi.c diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_ftpm_tee.rst b/Documentation/translations/zh_CN/security/tpm/tpm_ftpm_tee.rst new file mode 100644 index 000000000000..5901eee32563 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_ftpm_tee.rst @@ -0,0 +1,31 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_ftpm_tee.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +=========== +固件TPM驱动 +=========== + +本文档描述了固件可信平台模块（fTPM）设备驱动。 + +介绍 +==== + +该驱动程序是用于ARM的TrustZone环境中实现的固件的适配器。该驱动 +程序允许程序以与硬件TPM相同的方式与TPM进行交互。 + +设计 +==== + +该驱动程序充当一个薄层，传递命令到固件实现的TPM并接收其响应。驱动 +程序本身并不包含太多逻辑，更像是固件与内核/用户空间之间的一个管道。 + +固件本身基于以下论文： +https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/ftpm1.pdf + +当驱动程序被加载时，它会向用户空间暴露 ``/dev/tpmX`` 字符设备，允许 +用户空间通过该设备与固件TPM进行通信。 diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_tis.rst b/Documentation/translations/zh_CN/security/tpm/tpm_tis.rst new file mode 100644 index 000000000000..0fb009f93e10 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_tis.rst @@ -0,0 +1,43 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_tis.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +TPM FIFO接口驱动 +================ + +TCG PTP规范定义了两种接口类型：FIFO和CRB。前者基于顺序的读写操作， +后者基于包含完整命令或响应的缓冲区。 + +FIFO（先进先出）接口被tpm_tis_core依赖的驱动程序使用。最初，Linux只 +有一个名为tpm_tis的驱动，覆盖了内存映射（即 MMIO）接口，但后来它被 +扩展以支持TCG标准所支持的其他物理接口。 + +由于历史原因，最初的MMIO驱动被称为tpm_tis，而FIFO驱动的框架被命名为 +tpm_tis_core。在tpm_tis中的“tis”后缀来自TPM接口规范，这是针对TPM1.x +芯片的硬件接口规范。 + +通信基于一个由TPM芯片通过硬件总线或内存映射共享的20KiB 缓冲区，具体 +取决于物理接线。该缓冲区进一步分为五个相等大小的4KiB缓冲区，为CPU和 +TPM之间的通信提供等效的寄存器集。这些通信端点在TCG术语中称为localities。 + +当内核想要向TPM芯片发送命令时，它首先通过在TPM_ACCESS寄存器中设置 +requestUse位来保留locality0。当访问被授予时，该位由芯片清除。一旦完成 +通信，内核会写入TPM_ACCESS.activeLocality位。这告诉芯片该本地性已被 +释放。 + +待处理的本地性由芯片按优先级降序逐个服务，一次一个： + +- Locality0优先级最低。 +- Locality5优先级最高。 + +关于localities的更多信息和含义，请参阅TCG PC客户端平台TPM 配置文件规范的第3.2节。 + +参考文献 +======== + +TCG PC客户端平台TPM配置文件（PTP）规范 +https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/ diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_vtpm_proxy.rst b/Documentation/translations/zh_CN/security/tpm/tpm_vtpm_proxy.rst new file mode 100644 index 000000000000..bc92cfb684c3 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_vtpm_proxy.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_vtpm_proxy.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +========================== +Linux容器的虚拟TPM代理驱动 +========================== + +| 作者： +| Stefan Berger <stefanb@linux.vnet.ibm.com> + +本文档描述了用于Linux容器的虚拟可信平台模块（vTPM）代理设备驱动。 + +介绍 +==== + +这项工作的目标是为每个Linux容器提供TPM功能。这使得程序能够像与物理系统 +上的TPM交互一样，与容器中的TPM进行交互。每个容器都会获得一个唯一的、模 +拟的软件TPM。 + +设计 +==== + +为了使每个容器都能使用模拟的软件TPM，容器管理栈需要创建一对设备，其中 +包括一个客户端TPM字符设备 ``/dev/tpmX`` （X=0,1,2...）和一个‘服务器端’ +文件描述符。当文件描述符传被递给TPM模拟器时，前者通过创建具有适当主次 +设备号的字符设备被移入容器，然后，容器内的软件可以使用字符设备发送TPM +命令，模拟器将通过文件描述符接收这些命令，并用它来发送响应。 + +为了支持这一点，虚拟TPM代理驱动程序提供了一个设备 ``/dev/vtpmx`` ，该设备 +用于通过ioctl创建设备对。ioctl将其作为配置设备的输入标志，例如这些标志指示 +TPM模拟器是否支持TPM1.2或TPM2功能。ioctl的结果是返回‘服务器端’的文件描述符 +以及创建的字符设备的主次设备号。此外，还会返回TPM字符设备的编号。例如，如果 +创建了 ``/dev/tpm10`` ，则返回编号（ ``dev_num`` ）10。 + +一旦设备被创建，驱动程序将立即尝试与TPM进行通信。来自驱动程序的所有命令 +都可以从ioctl返回的文件描述符中读取。这些命令应该立即得到响应。 + +UAPI +==== + +该API在以下内核代码中： + +include/uapi/linux/vtpm_proxy.h +drivers/char/tpm/tpm_vtpm_proxy.c + +函数：vtpmx_ioc_new_dev diff --git a/Documentation/translations/zh_CN/security/tpm/xen-tpmfront.rst b/Documentation/translations/zh_CN/security/tpm/xen-tpmfront.rst new file mode 100644 index 000000000000..fa085d98a99b --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/xen-tpmfront.rst @@ -0,0 +1,114 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/xen-tpmfront.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +================ +Xen的虚拟TPM接口 +================ + +作者：Matthew Fioravante (JHUAPL), Daniel De Graaf (NSA) + +本文档描述了用于Xen的虚拟可信平台模块（vTPM）子系统。假定读者熟悉 +Xen和Linux的构建和安装，并对TPM和vTPM概念有基本的理解。 + +介绍 +---- + +这项工作的目标是为虚拟客户操作系统（在Xen中称为DomU）提供TPM功能。这使得 +程序能够像与物理系统上的TPM交互一样，与虚拟系统中的TPM进行交互。每个客户 +操作系统都会获得一个唯一的、模拟的软件TPM。然而，vTPM的所有秘密（如密钥、 +NVRAM 等）由vTPM管理域进行管理，该域将这些秘密封存到物理TPM中。如果创建这 +些域（管理域、vTPM域和客户域）的过程是可信的，vTPM子系统就能将根植于硬件 +TPM的信任链扩展到Xen中的虚拟机。vTPM的每个主要组件都作为一个独立的域实现， +从而通过虚拟机监控程序（hypervisor）提供安全隔离。 + +这个mini-os vTPM 子系统是建立在IBM和Intel公司之前的vTPM工作基础上的。 + + +设计概述 +-------- + +vTPM的架构描述如下:: + + +------------------+ + | Linux DomU | ... + | | ^ | + | v | | + | xen-tpmfront | + +------------------+ + | ^ + v | + +------------------+ + | mini-os/tpmback | + | | ^ | + | v | | + | vtpm-stubdom | ... + | | ^ | + | v | | + | mini-os/tpmfront | + +------------------+ + | ^ + v | + +------------------+ + | mini-os/tpmback | + | | ^ | + | v | | + | vtpmmgr-stubdom | + | | ^ | + | v | | + | mini-os/tpm_tis | + +------------------+ + | ^ + v | + +------------------+ + | Hardware TPM | + +------------------+ + +* Linux DomU: + 希望使用vTPM的基于Linux的客户机。可能有多个这样的实例。 + +* xen-tpmfront.ko: + Linux内核虚拟TPM前端驱动程序。该驱动程序为基于Linux的DomU提供 + vTPM访问。 + +* mini-os/tpmback: + Mini-os TPM后端驱动程序。Linux前端驱动程序通过该后端驱动程序连 + 接，以便在Linux DomU和其vTPM之间进行通信。该驱动程序还被 + vtpmmgr-stubdom用于与vtpm-stubdom通信。 + +* vtpm-stubdom: + 一个实现vTPM的mini-os存根域。每个正在运行的vtpm-stubdom实例与系统 + 上的逻辑vTPM之间有一一对应的关系。vTPM平台配置寄存器（PCRs）通常都 + 初始化为零。 + +* mini-os/tpmfront: + Mini-os TPM前端驱动程序。vTPM mini-os域vtpm-stubdom使用该驱动程序 + 与vtpmmgr-stubdom通信。此驱动程序还用于与vTPM域通信的mini-os域，例 + 如 pv-grub。 + +* vtpmmgr-stubdom: + 一个实现vTPM管理器的mini-os域。系统中只有一个vTPM管理器，并且在整个 + 机器生命周期内应一直运行。此域调节对系统中物理TPM的访问，并确保每个 + vTPM的持久状态。 + +* mini-os/tpm_tis: + Mini-osTPM1.2版本TPM 接口规范（TIS）驱动程序。该驱动程序由vtpmmgr-stubdom + 用于直接与硬件TPM通信。通信通过将硬件内存页映射到vtpmmgr-stubdom来实现。 + +* 硬件TPM: + 固定在主板上的物理 TPM。 + +与Xen的集成 +----------- + +vTPM驱动程序的支持已在Xen4.3中通过libxl工具堆栈添加。有关设置vTPM和vTPM +管理器存根域的详细信息，请参见Xen文档（docs/misc/vtpm.txt）。一旦存根域 +运行，与磁盘或网络设备相同，vTPM设备将在域的配置文件中进行设置 + +为了使用诸如IMA（完整性测量架构）等需要在initrd之前加载TPM的功能，必须将 +xen-tpmfront驱动程序编译到内核中。如果不使用这些功能，驱动程序可以作为 +模块编译，并像往常一样加载。 diff --git a/Documentation/translations/zh_CN/subsystem-apis.rst b/Documentation/translations/zh_CN/subsystem-apis.rst index 47780bb0772f..8b646c1010be 100644 --- a/Documentation/translations/zh_CN/subsystem-apis.rst +++ b/Documentation/translations/zh_CN/subsystem-apis.rst @@ -88,6 +88,7 @@ TODOList: cpu-freq/index iio/index virt/index + security/index PCI/index peci/index @@ -102,7 +103,6 @@ TODOList: * watchdog/index * hwmon/index * accel/index -* security/index * crypto/index * bpf/index * usb/index diff --git a/Documentation/translations/zh_TW/admin-guide/README.rst b/Documentation/translations/zh_TW/admin-guide/README.rst index a6e34c200ea3..0b038074d9d1 100644 --- a/Documentation/translations/zh_TW/admin-guide/README.rst +++ b/Documentation/translations/zh_TW/admin-guide/README.rst @@ -149,7 +149,7 @@ Linux內核6.x版本 <http://kernel.org/> "make xconfig" 基於Qt的配置工具。 - "make gconfig" 基於GTK+的配置工具。 + "make gconfig" 基於GTK的配置工具。 "make oldconfig" 基於現有的 ./.config 文件選擇所有選項，並詢問 新配置選項。 diff --git a/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst b/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst index c139ec99cab1..b25ecc44d735 100644 --- a/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst +++ b/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst @@ -332,13 +332,3 @@ sysklogd發行版附帶了一個補丁，它修改了 ``modules-2.0.0`` 包，� Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128] Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3 ---------------------------------------------------------------------------- - -:: - - Dr. G.W. Wettstein Oncology Research Div. Computing Facility - Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com - 820 4th St. N. - Fargo, ND 58122 - Phone: 701-234-7556 - diff --git a/Documentation/translations/zh_TW/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_TW/admin-guide/mm/damon/usage.rst index fbbbbad59ee4..d3fd4f850793 100644 --- a/Documentation/translations/zh_TW/admin-guide/mm/damon/usage.rst +++ b/Documentation/translations/zh_TW/admin-guide/mm/damon/usage.rst @@ -26,12 +26,7 @@ DAMON 爲不同的用戶提供了下面這些接口。 使用它，用戶可以通過讀取和寫入特殊的sysfs文件來使用DAMON的主要功能。因此，你可以編寫和使 用你個性化的DAMON sysfs包裝程序，代替你讀/寫sysfs文件。 `DAMON用戶空間工具 <https://github.com/damonitor/damo>`_ 就是這種程序的一個例子 它同時支持虛擬和物理地址 - 空間的監測。注意，這個界面只提供簡單的監測結果 :ref:`統計 <damos_stats>`。對於詳細的監測 - 結果，DAMON提供了一個:ref:`跟蹤點 <tracepoint>`。 -- *debugfs interface.* - :ref:`這 <debugfs_interface>` 幾乎與:ref:`sysfs interface <sysfs_interface>` 接 - 口相同。這將在下一個LTS內核發佈後被移除，所以用戶應該轉移到 - :ref:`sysfs interface <sysfs_interface>`。 + 空間的監測。 - *內核空間編程接口。* :doc:`這 </mm/damon/api>` 這是爲內核空間程序員準備的。使用它，用戶可以通過爲你編寫內 核空間的DAMON應用程序，最靈活有效地利用DAMON的每一個功能。你甚至可以爲各種地址空間擴展DAMON。 @@ -335,247 +330,6 @@ tried_regions/<N>/ 請注意，我們強烈建議使用用戶空間的工具，如 `damo <https://github.com/damonitor/damo>`_ ， 而不是像上面那樣手動讀寫文件。以上只是一個例子。 -debugfs接口 -=========== - -.. note:: - - DAMON debugfs接口將在下一個LTS內核發佈後被移除，所以用戶應該轉移到 - :ref:`sysfs接口<sysfs_interface>`。 - -DAMON導出了八個文件, ``attrs``, ``target_ids``, ``init_regions``, -``schemes``, ``monitor_on_DEPRECATED``, ``kdamond_pid``, ``mk_contexts`` 和 -``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``. - - -屬性 ----- - -用戶可以通過讀取和寫入 ``attrs`` 文件獲得和設置 ``採樣間隔`` 、 ``聚集間隔`` 、 ``更新間隔`` -以及監測目標區域的最小/最大數量。要詳細瞭解監測屬性，請參考 `:doc:/mm/damon/design` 。例如， -下面的命令將這些值設置爲5ms、100ms、1000ms、10和1000，然後再次檢查:: - - # cd <debugfs>/damon - # echo 5000 100000 1000000 10 1000 > attrs - # cat attrs - 5000 100000 1000000 10 1000 - - -目標ID ------- - -一些類型的地址空間支持多個監測目標。例如，虛擬內存地址空間的監測可以有多個進程作爲監測目標。用戶 -可以通過寫入目標的相關id值來設置目標，並通過讀取 ``target_ids`` 文件來獲得當前目標的id。在監 -測虛擬地址空間的情況下，這些值應該是監測目標進程的pid。例如，下面的命令將pid爲42和4242的進程設 -爲監測目標，並再次檢查:: - - # cd <debugfs>/damon - # echo 42 4242 > target_ids - # cat target_ids - 42 4242 - -用戶還可以通過在文件中寫入一個特殊的關鍵字 "paddr\n" 來監測系統的物理內存地址空間。因爲物理地 -址空間監測不支持多個目標，讀取文件會顯示一個假值，即 ``42`` ，如下圖所示:: - - # cd <debugfs>/damon - # echo paddr > target_ids - # cat target_ids - 42 - -請注意，設置目標ID並不啓動監測。 - - -初始監測目標區域 ----------------- - -在虛擬地址空間監測的情況下，DAMON自動設置和更新監測的目標區域，這樣就可以覆蓋目標進程的整個 -內存映射。然而，用戶可能希望將監測區域限制在特定的地址範圍內，如堆、棧或特定的文件映射區域。 -或者，一些用戶可以知道他們工作負載的初始訪問模式，因此希望爲“自適應區域調整”設置最佳初始區域。 - -相比之下，DAMON在物理內存監測的情況下不會自動設置和更新監測目標區域。因此，用戶應該自己設置 -監測目標區域。 - -在這種情況下，用戶可以通過在 ``init_regions`` 文件中寫入適當的值，明確地設置他們想要的初 -始監測目標區域。輸入應該是一個由三個整數組成的隊列，用空格隔開，代表一個區域的形式如下:: - - <target idx> <start address> <end address> - -目標idx應該是 ``target_ids`` 文件中目標的索引，從 ``0`` 開始，區域應該按照地址順序傳遞。 -例如，下面的命令將設置幾個地址範圍， ``1-100`` 和 ``100-200`` 作爲pid 42的初始監測目標 -區域，這是 ``target_ids`` 中的第一個（索引 ``0`` ），另外幾個地址範圍， ``20-40`` 和 -``50-100`` 作爲pid 4242的地址，這是 ``target_ids`` 中的第二個（索引 ``1`` ）:: - - # cd <debugfs>/damon - # cat target_ids - 42 4242 - # echo "0 1 100 \ - 0 100 200 \ - 1 20 40 \ - 1 50 100" > init_regions - -請注意，這只是設置了初始的監測目標區域。在虛擬內存監測的情況下，DAMON會在一個 ``更新間隔`` -後自動更新區域的邊界。因此，在這種情況下，如果用戶不希望更新的話，應該把 ``更新間隔`` 設 -置得足夠大。 - - -方案 ----- - -對於通常的基於DAMON的數據訪問感知的內存管理優化，用戶只是希望系統對特定訪問模式的內存區域應用內 -存管理操作。DAMON從用戶那裏接收這種形式化的操作方案，並將這些方案應用到目標進程中。 - -用戶可以通過讀取和寫入 ``scheme`` debugfs文件來獲得和設置這些方案。讀取該文件還可以顯示每個 -方案的統計數據。在文件中，每一個方案都應該在每一行中以下列形式表示出來:: - - <target access pattern> <action> <quota> <watermarks> - -你可以通過簡單地在文件中寫入一個空字符串來禁用方案。 - -目標訪問模式 -~~~~~~~~~~~~ - -``<目標訪問模式>`` 是由三個範圍構成的，形式如下:: - - min-size max-size min-acc max-acc min-age max-age - -具體來說，區域大小的字節數（ `min-size` 和 `max-size` ），訪問頻率的每聚合區間的監測訪問次 -數（ `min-acc` 和 `max-acc` ），區域年齡的聚合區間數（ `min-age` 和 `max-age` ）都被指定。 -請注意，這些範圍是封閉區間。 - -動作 -~~~~ - -``<action>`` 是一個預定義的內存管理動作的整數，DAMON將應用於具有目標訪問模式的區域。支持 -的數字和它們的含義如下:: - - - 0: Call ``madvise()`` for the region with ``MADV_WILLNEED`` - - 1: Call ``madvise()`` for the region with ``MADV_COLD`` - - 2: Call ``madvise()`` for the region with ``MADV_PAGEOUT`` - - 3: Call ``madvise()`` for the region with ``MADV_HUGEPAGE`` - - 4: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE`` - - 5: Do nothing but count the statistics - -配額 -~~~~ - -每個 ``動作`` 的最佳 ``目標訪問模式`` 取決於工作負載，所以不容易找到。更糟糕的是，將某個 -動作的方案設置得過於激進會導致嚴重的開銷。爲了避免這種開銷，用戶可以通過下面表格中的 ``<quota>`` -來限制方案的時間和大小配額:: - - <ms> <sz> <reset interval> <priority weights> - -這使得DAMON在 ``<reset interval>`` 毫秒內，儘量只用 ``<ms>`` 毫秒的時間對 ``目標訪 -問模式`` 的內存區域應用動作，並在 ``<reset interval>`` 內只對最多<sz>字節的內存區域應 -用動作。將 ``<ms>`` 和 ``<sz>`` 都設置爲零，可以禁用配額限制。 - -當預計超過配額限制時，DAMON會根據 ``目標訪問模式`` 的大小、訪問頻率和年齡，對發現的內存 -區域進行優先排序。爲了實現個性化的優先級，用戶可以在 ``<優先級權重>`` 中設置這三個屬性的 -權重，具體形式如下:: - - <size weight> <access frequency weight> <age weight> - -水位 -~~~~ - -有些方案需要根據系統特定指標的當前值來運行，如自由內存比率。對於這種情況，用戶可以爲該條 -件指定水位。:: - - <metric> <check interval> <high mark> <middle mark> <low mark> - -``<metric>`` 是一個預定義的整數，用於要檢查的度量。支持的數字和它們的含義如下。 - - - 0: 忽視水位 - - 1: 系統空閒內存率 (千分比) - -每隔 ``<檢查間隔>`` 微秒檢查一次公制的值。 - -如果該值高於 ``<高標>`` 或低於 ``<低標>`` ，該方案被停用。如果該值低於 ``<中標>`` ， -該方案將被激活。 - -統計數據 -~~~~~~~~ - -它還統計每個方案被嘗試應用的區域的總數量和字節數，每個方案被成功應用的區域的兩個數量，以 -及超過配額限制的總數量。這些統計數據可用於在線分析或調整方案。 - -統計數據可以通過讀取方案文件來顯示。讀取該文件將顯示你在每一行中輸入的每個 ``方案`` ， -統計的五個數字將被加在每一行的末尾。 - -例子 -~~~~ - -下面的命令應用了一個方案：”如果一個大小爲[4KiB, 8KiB]的內存區域在[10, 20]的聚合時間 -間隔內顯示出每一個聚合時間間隔[0, 5]的訪問量，請分頁出該區域。對於分頁，每秒最多隻能使 -用10ms，而且每秒分頁不能超過1GiB。在這一限制下，首先分頁出具有較長年齡的內存區域。另外， -每5秒鐘檢查一次系統的可用內存率，當可用內存率低於50%時開始監測和分頁，但如果可用內存率 -大於60%，或低於30%，則停止監測“:: - - # cd <debugfs>/damon - # scheme="4096 8192 0 5 10 20 2" # target access pattern and action - # scheme+=" 10 $((1024*1024*1024)) 1000" # quotas - # scheme+=" 0 0 100" # prioritization weights - # scheme+=" 1 5000000 600 500 300" # watermarks - # echo "$scheme" > schemes - - -開關 ----- - -除非你明確地啓動監測，否則如上所述的文件設置不會產生效果。你可以通過寫入和讀取 ``monitor_on_DEPRECATED`` -文件來啓動、停止和檢查監測的當前狀態。寫入 ``on`` 該文件可以啓動對有屬性的目標的監測。寫入 -``off`` 該文件則停止這些目標。如果每個目標進程被終止，DAMON也會停止。下面的示例命令開啓、關 -閉和檢查DAMON的狀態:: - - # cd <debugfs>/damon - # echo on > monitor_on_DEPRECATED - # echo off > monitor_on_DEPRECATED - # cat monitor_on_DEPRECATED - off - -請注意，當監測開啓時，你不能寫到上述的debugfs文件。如果你在DAMON運行時寫到這些文件，將會返 -回一個錯誤代碼，如 ``-EBUSY`` 。 - - -監測線程PID ------------ - -DAMON通過一個叫做kdamond的內核線程來進行請求監測。你可以通過讀取 ``kdamond_pid`` 文件獲 -得該線程的 ``pid`` 。當監測被 ``關閉`` 時，讀取該文件不會返回任何信息:: - - # cd <debugfs>/damon - # cat monitor_on_DEPRECATED - off - # cat kdamond_pid - none - # echo on > monitor_on_DEPRECATED - # cat kdamond_pid - 18594 - - -使用多個監測線程 ----------------- - -每個監測上下文都會創建一個 ``kdamond`` 線程。你可以使用 ``mk_contexts`` 和 ``rm_contexts`` -文件爲多個 ``kdamond`` 需要的用例創建和刪除監測上下文。 - -將新上下文的名稱寫入 ``mk_contexts`` 文件，在 ``DAMON debugfs`` 目錄上創建一個該名稱的目錄。 -該目錄將有該上下文的 ``DAMON debugfs`` 文件:: - - # cd <debugfs>/damon - # ls foo - # ls: cannot access 'foo': No such file or directory - # echo foo > mk_contexts - # ls foo - # attrs init_regions kdamond_pid schemes target_ids - -如果不再需要上下文，你可以通過把上下文的名字放到 ``rm_contexts`` 文件中來刪除它和相應的目錄:: - - # echo foo > rm_contexts - # ls foo - # ls: cannot access 'foo': No such file or directory - -注意， ``mk_contexts`` 、 ``rm_contexts`` 和 ``monitor_on_DEPRECATED`` 文件只在根目錄下。 - 監測結果的監測點 ================ diff --git a/Documentation/translations/zh_TW/admin-guide/sysrq.rst b/Documentation/translations/zh_TW/admin-guide/sysrq.rst index 4a08db00a495..4979e5d5405f 100644 --- a/Documentation/translations/zh_TW/admin-guide/sysrq.rst +++ b/Documentation/translations/zh_TW/admin-guide/sysrq.rst @@ -60,24 +60,24 @@ CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE 必須是以 16 進制數寫入。 ~~~~~~~~~~~~~~~~~~~~~~~ 在 x86 架構上 - 你可以按下鍵盤組合鍵 :kbd:`ALT-SysRq-<command key>`。 + 你可以按下鍵盤組合鍵 `ALT-SysRq-<command key>`。 .. note:: 一些鍵盤可能沒有標識 'SySRq' 鍵。'SySRq' 鍵也被當做 'Print Screen'鍵。 - 同時有些鍵盤無法處理同時按下這麼多鍵，因此你可以先按下鍵盤 :kbd:`Alt` 鍵， - 然後按下鍵盤 :kbd:`SysRq` 鍵，再釋放鍵盤 :kbd:`SysRq` 鍵，之後按下鍵盤上命令鍵 - :kbd:`<command key>`，最後釋放所有鍵。 + 同時有些鍵盤無法處理同時按下這麼多鍵，因此你可以先按下鍵盤 `Alt` 鍵， + 然後按下鍵盤 `SysRq` 鍵，再釋放鍵盤 `SysRq` 鍵，之後按下鍵盤上命令鍵 + `<command key>`，最後釋放所有鍵。 在 SPARC 架構上 - 你可以按下鍵盤組合鍵 :kbd:`ALT-STOP-<command key>` 。 + 你可以按下鍵盤組合鍵 `ALT-STOP-<command key>` 。 在串行控制檯（只針對 PC 類型的標準串口） 你可以發一個 ``BREAK`` ，然後在 5 秒內發送一個命令鍵， 發送 ``BREAK`` 兩次將被翻譯爲一個正常的 BREAK 操作。 在 PowerPC 架構上 - 按下鍵盤組合鍵 :kbd:`ALT - Print Screen` （或者 :kbd:`F13`） - :kbd:`<命令鍵>` 。 - :kbd:`Print Screen` （或者 :kbd:`F13`） - :kbd:`<命令鍵>` 或許也能實現。 + 按下鍵盤組合鍵 `ALT - Print Screen` （或者 `F13`） - `<命令鍵>` 。 + `Print Screen` （或者 `F13`） - `<命令鍵>` 或許也能實現。 在其他架構上 如果你知道其他架構的組合鍵，請告訴我，我可以把它們添加到這部分。 @@ -87,7 +87,7 @@ CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE 必須是以 16 進制數寫入。 echo t > /proc/sysrq-trigger -這個命令鍵 :kbd:`<command key>` 是區分大小寫的。 +這個命令鍵 `<command key>` 是區分大小寫的。 什麼是命令鍵？ ~~~~~~~~~~~~~~ @@ -203,8 +203,8 @@ syslogd/klogd 進程是運行的，它們仍將被記錄。） ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 這也會發生在我這，我發現輕敲鍵盤兩側的 shift、alt 和 control 鍵，然後再次敲擊 -一個無效的 SysRq 鍵序列可以解決問題。（比如，像鍵盤組合鍵 :kbd:`alt-sysrq-z` ） -切換到另一個虛擬控制檯（鍵盤操作 :kbd:`ALT+Fn` ），然後再切回來應該也有幫助。 +一個無效的 SysRq 鍵序列可以解決問題。（比如，像鍵盤組合鍵 `alt-sysrq-z` ） +切換到另一個虛擬控制檯（鍵盤操作 `ALT+Fn` ），然後再切回來應該也有幫助。 我敲擊了 SysRq 鍵，但像是什麼都沒發生，發生了什麼錯誤？ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -259,7 +259,7 @@ SysRq 鍵的輸出和所有其他控制檯輸出一樣，受制於控制檯日� 文件的消費訪問到。作爲一個特例，來自 sysrq 命令的標題行將被傳遞給所有控制檯 使用者，就好像當前日誌級別是最大的一樣。如果只發出標題頭，則幾乎可以肯定內核日誌 級別太低。如果你需要控制檯上的輸出，那麼你將需要臨時提高控制檯日誌級別，通過使用 -鍵盤組合鍵 :kbd:`alt-sysrq-8` 或者:: +鍵盤組合鍵 `alt-sysrq-8` 或者:: echo 8 > /proc/sysrq-trigger diff --git a/Documentation/translations/zh_TW/process/email-clients.rst b/Documentation/translations/zh_TW/process/email-clients.rst index a5ac9400a9f5..4543c447d797 100644 --- a/Documentation/translations/zh_TW/process/email-clients.rst +++ b/Documentation/translations/zh_TW/process/email-clients.rst @@ -86,7 +86,7 @@ Alpine (TUI) - :menuselection:`Do Not Send Flowed Text` 必須開啓 - :menuselection:`Strip Whitespace Before Sending` 必須關閉 -當寫郵件時，光標應該放在補丁會出現的地方，然後按下 :kbd:`CTRL-R` 組合鍵，使指 +當寫郵件時，光標應該放在補丁會出現的地方，然後按下 `CTRL-R` 組合鍵，使指 定的補丁文件嵌入到郵件中。 Claws Mail (GUI) @@ -94,7 +94,7 @@ Claws Mail (GUI) 可以用，有人用它成功地發過補丁。 -用 :menuselection:`Message-->Insert File` (:kbd:`CTRL-I`) 或外置編輯器插入補丁。 +用 :menuselection:`Message-->Insert File` (`CTRL-I`) 或外置編輯器插入補丁。 若要在Claws編輯窗口重修改插入的補丁，需關閉 :menuselection:`Configuration-->Preferences-->Compose-->Wrapping` @@ -106,11 +106,11 @@ Evolution (GUI) 一些開發者成功的使用它發送補丁。 撰寫郵件時： -從 :menuselection:`格式-->段落樣式-->預格式化` (:kbd:`CTRL-7`) +從 :menuselection:`格式-->段落樣式-->預格式化` (`CTRL-7`) 或工具欄選擇 :menuselection:`預格式化` ； 然後使用： -:menuselection:`插入-->文本文件...` (:kbd:`ALT-N x`) 插入補丁文件。 +:menuselection:`插入-->文本文件...` (`ALT-N x`) 插入補丁文件。 你還可以 ``diff -Nru old.c new.c | xclip`` ，選擇 :menuselection:`預格式化` ， 然後使用鼠標中鍵進行粘帖。 diff --git a/Documentation/translations/zh_TW/process/submit-checklist.rst b/Documentation/translations/zh_TW/process/submit-checklist.rst index 0ecb187753e4..a0cb91a6945f 100644 --- a/Documentation/translations/zh_TW/process/submit-checklist.rst +++ b/Documentation/translations/zh_TW/process/submit-checklist.rst @@ -85,8 +85,8 @@ Linux內核補丁提交檢查單 17) 所有新的模塊參數都記錄在 ``MODULE_PARM_DESC()`` 18) 所有新的用戶空間接口都記錄在 ``Documentation/ABI/`` 中。有關詳細信息， - 請參閱 ``Documentation/ABI/README`` 。更改用戶空間接口的補丁應該抄送 - linux-api@vger.kernel.org。 + 請參閱 Documentation/admin-guide/abi.rst (或 ``Documentation/ABI/README``)。 + 更改用戶空間接口的補丁應該抄送 linux-api@vger.kernel.org\ 。 19) 已通過至少注入slab和page分配失敗進行檢查。請參閱 ``Documentation/fault-injection/`` 。 如果新代碼是實質性的，那麼添加子系統特定的故障注入可能是合適的。 diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index bf555c2270f5..1998dc146c56 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -1050,7 +1050,7 @@ Its attributes are: midi1_num_groups The number of groups for MIDI 1.0 (0-16) ui_hint UI-hint of this FB 0: unknown, 1: receiver, 2: sender, 3: both - midi_ci_verison Supported MIDI-CI version number (8 bit) + midi_ci_version Supported MIDI-CI version number (8 bit) is_midi1 Legacy MIDI 1.0 device (0-2) 0: MIDI 2.0 device, 1: MIDI 1.0 without restriction, or diff --git a/Documentation/usb/usbip_protocol.rst b/Documentation/usb/usbip_protocol.rst index adc158967cc6..3da1df3d94f5 100644 --- a/Documentation/usb/usbip_protocol.rst +++ b/Documentation/usb/usbip_protocol.rst @@ -285,17 +285,17 @@ OP_REP_IMPORT: +-----------+--------+------------+---------------------------------------------------+ | 0x138 | 2 | | bcdDevice | +-----------+--------+------------+---------------------------------------------------+ -| 0x139 | 1 | | bDeviceClass | +| 0x13A | 1 | | bDeviceClass | +-----------+--------+------------+---------------------------------------------------+ -| 0x13A | 1 | | bDeviceSubClass | +| 0x13B | 1 | | bDeviceSubClass | +-----------+--------+------------+---------------------------------------------------+ -| 0x13B | 1 | | bDeviceProtocol | +| 0x13C | 1 | | bDeviceProtocol | +-----------+--------+------------+---------------------------------------------------+ -| 0x13C | 1 | | bConfigurationValue | +| 0x13D | 1 | | bConfigurationValue | +-----------+--------+------------+---------------------------------------------------+ -| 0x13D | 1 | | bNumConfigurations | +| 0x13E | 1 | | bNumConfigurations | +-----------+--------+------------+---------------------------------------------------+ -| 0x13E | 1 | | bNumInterfaces | +| 0x13F | 1 | | bNumInterfaces | +-----------+--------+------------+---------------------------------------------------+ The following four commands have a common basic header called diff --git a/Documentation/userspace-api/accelerators/ocxl.rst b/Documentation/userspace-api/accelerators/ocxl.rst index db7570d5e50d..4e213af70237 100644 --- a/Documentation/userspace-api/accelerators/ocxl.rst +++ b/Documentation/userspace-api/accelerators/ocxl.rst @@ -3,8 +3,11 @@ OpenCAPI (Open Coherent Accelerator Processor Interface) ======================================================== OpenCAPI is an interface between processors and accelerators. It aims -at being low-latency and high-bandwidth. The specification is -developed by the `OpenCAPI Consortium <http://opencapi.org/>`_. +at being low-latency and high-bandwidth. + +The specification was developed by the OpenCAPI Consortium, and is now +available from the `Compute Express Link Consortium +<https://computeexpresslink.org/resource/opencapi-specification-archive/>`_. It allows an accelerator (which could be an FPGA, ASICs, ...) to access the host memory coherently, using virtual addresses. An OpenCAPI diff --git a/Documentation/userspace-api/check_exec.rst b/Documentation/userspace-api/check_exec.rst new file mode 100644 index 000000000000..05dfe3b56f71 --- /dev/null +++ b/Documentation/userspace-api/check_exec.rst @@ -0,0 +1,144 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. Copyright © 2024 Microsoft Corporation + +=================== +Executability check +=================== + +The ``AT_EXECVE_CHECK`` :manpage:`execveat(2)` flag, and the +``SECBIT_EXEC_RESTRICT_FILE`` and ``SECBIT_EXEC_DENY_INTERACTIVE`` securebits +are intended for script interpreters and dynamic linkers to enforce a +consistent execution security policy handled by the kernel. See the +`samples/check-exec/inc.c`_ example. + +Whether an interpreter should check these securebits or not depends on the +security risk of running malicious scripts with respect to the execution +environment, and whether the kernel can check if a script is trustworthy or +not. For instance, Python scripts running on a server can use arbitrary +syscalls and access arbitrary files. Such interpreters should then be +enlighten to use these securebits and let users define their security policy. +However, a JavaScript engine running in a web browser should already be +sandboxed and then should not be able to harm the user's environment. + +Script interpreters or dynamic linkers built for tailored execution environments +(e.g. hardened Linux distributions or hermetic container images) could use +``AT_EXECVE_CHECK`` without checking the related securebits if backward +compatibility is handled by something else (e.g. atomic update ensuring that +all legitimate libraries are allowed to be executed). It is then recommended +for script interpreters and dynamic linkers to check the securebits at run time +by default, but also to provide the ability for custom builds to behave like if +``SECBIT_EXEC_RESTRICT_FILE`` or ``SECBIT_EXEC_DENY_INTERACTIVE`` were always +set to 1 (i.e. always enforce restrictions). + +AT_EXECVE_CHECK +=============== + +Passing the ``AT_EXECVE_CHECK`` flag to :manpage:`execveat(2)` only performs a +check on a regular file and returns 0 if execution of this file would be +allowed, ignoring the file format and then the related interpreter dependencies +(e.g. ELF libraries, script's shebang). + +Programs should always perform this check to apply kernel-level checks against +files that are not directly executed by the kernel but passed to a user space +interpreter instead. All files that contain executable code, from the point of +view of the interpreter, should be checked. However the result of this check +should only be enforced according to ``SECBIT_EXEC_RESTRICT_FILE`` or +``SECBIT_EXEC_DENY_INTERACTIVE.``. + +The main purpose of this flag is to improve the security and consistency of an +execution environment to ensure that direct file execution (e.g. +``./script.sh``) and indirect file execution (e.g. ``sh script.sh``) lead to +the same result. For instance, this can be used to check if a file is +trustworthy according to the caller's environment. + +In a secure environment, libraries and any executable dependencies should also +be checked. For instance, dynamic linking should make sure that all libraries +are allowed for execution to avoid trivial bypass (e.g. using ``LD_PRELOAD``). +For such secure execution environment to make sense, only trusted code should +be executable, which also requires integrity guarantees. + +To avoid race conditions leading to time-of-check to time-of-use issues, +``AT_EXECVE_CHECK`` should be used with ``AT_EMPTY_PATH`` to check against a +file descriptor instead of a path. + +SECBIT_EXEC_RESTRICT_FILE and SECBIT_EXEC_DENY_INTERACTIVE +========================================================== + +When ``SECBIT_EXEC_RESTRICT_FILE`` is set, a process should only interpret or +execute a file if a call to :manpage:`execveat(2)` with the related file +descriptor and the ``AT_EXECVE_CHECK`` flag succeed. + +This secure bit may be set by user session managers, service managers, +container runtimes, sandboxer tools... Except for test environments, the +related ``SECBIT_EXEC_RESTRICT_FILE_LOCKED`` bit should also be set. + +Programs should only enforce consistent restrictions according to the +securebits but without relying on any other user-controlled configuration. +Indeed, the use case for these securebits is to only trust executable code +vetted by the system configuration (through the kernel), so we should be +careful to not let untrusted users control this configuration. + +However, script interpreters may still use user configuration such as +environment variables as long as it is not a way to disable the securebits +checks. For instance, the ``PATH`` and ``LD_PRELOAD`` variables can be set by +a script's caller. Changing these variables may lead to unintended code +executions, but only from vetted executable programs, which is OK. For this to +make sense, the system should provide a consistent security policy to avoid +arbitrary code execution e.g., by enforcing a write xor execute policy. + +When ``SECBIT_EXEC_DENY_INTERACTIVE`` is set, a process should never interpret +interactive user commands (e.g. scripts). However, if such commands are passed +through a file descriptor (e.g. stdin), its content should be interpreted if a +call to :manpage:`execveat(2)` with the related file descriptor and the +``AT_EXECVE_CHECK`` flag succeed. + +For instance, script interpreters called with a script snippet as argument +should always deny such execution if ``SECBIT_EXEC_DENY_INTERACTIVE`` is set. + +This secure bit may be set by user session managers, service managers, +container runtimes, sandboxer tools... Except for test environments, the +related ``SECBIT_EXEC_DENY_INTERACTIVE_LOCKED`` bit should also be set. + +Here is the expected behavior for a script interpreter according to combination +of any exec securebits: + +1. ``SECBIT_EXEC_RESTRICT_FILE=0`` and ``SECBIT_EXEC_DENY_INTERACTIVE=0`` + + Always interpret scripts, and allow arbitrary user commands (default). + + No threat, everyone and everything is trusted, but we can get ahead of + potential issues thanks to the call to :manpage:`execveat(2)` with + ``AT_EXECVE_CHECK`` which should always be performed but ignored by the + script interpreter. Indeed, this check is still important to enable systems + administrators to verify requests (e.g. with audit) and prepare for + migration to a secure mode. + +2. ``SECBIT_EXEC_RESTRICT_FILE=1`` and ``SECBIT_EXEC_DENY_INTERACTIVE=0`` + + Deny script interpretation if they are not executable, but allow + arbitrary user commands. + + The threat is (potential) malicious scripts run by trusted (and not fooled) + users. That can protect against unintended script executions (e.g. ``sh + /tmp/*.sh``). This makes sense for (semi-restricted) user sessions. + +3. ``SECBIT_EXEC_RESTRICT_FILE=0`` and ``SECBIT_EXEC_DENY_INTERACTIVE=1`` + + Always interpret scripts, but deny arbitrary user commands. + + This use case may be useful for secure services (i.e. without interactive + user session) where scripts' integrity is verified (e.g. with IMA/EVM or + dm-verity/IPE) but where access rights might not be ready yet. Indeed, + arbitrary interactive commands would be much more difficult to check. + +4. ``SECBIT_EXEC_RESTRICT_FILE=1`` and ``SECBIT_EXEC_DENY_INTERACTIVE=1`` + + Deny script interpretation if they are not executable, and also deny + any arbitrary user commands. + + The threat is malicious scripts run by untrusted users (but trusted code). + This makes sense for system services that may only execute trusted scripts. + +.. Links +.. _samples/check-exec/inc.c: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/samples/check-exec/inc.c diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst new file mode 100644 index 000000000000..535f49047ce6 --- /dev/null +++ b/Documentation/userspace-api/dma-buf-heaps.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================== +Allocating dma-buf using heaps +============================== + +Dma-buf Heaps are a way for userspace to allocate dma-buf objects. They are +typically used to allocate buffers from a specific allocation pool, or to share +buffers across frameworks. + +Heaps +===== + +A heap represents a specific allocator. The Linux kernel currently supports the +following heaps: + + - The ``system`` heap allocates virtually contiguous, cacheable, buffers. + + - The ``cma`` heap allocates physically contiguous, cacheable, + buffers. Only present if a CMA region is present. Such a region is + usually created either through the kernel commandline through the + `cma` parameter, a memory region Device-Tree node with the + `linux,cma-default` property set, or through the `CMA_SIZE_MBYTES` or + `CMA_SIZE_PERCENTAGE` Kconfig options. Depending on the platform, it + might be called ``reserved``, ``linux,cma``, or ``default-pool``. diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index 274cc7546efc..9cbe4390c872 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -35,6 +35,7 @@ Security-related interfaces mfd_noexec spec_ctrl tee + check_exec Devices and I/O =============== @@ -43,6 +44,7 @@ Devices and I/O :maxdepth: 1 accelerators/ocxl + dma-buf-heaps dma-buf-alloc-exchange gpio/index iommufd @@ -63,6 +65,7 @@ Everything else vduse futex2 perf_ring_buffer + ntsync .. only:: subproject and html diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 243f1f1b554a..66dcfaae698b 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -283,6 +283,7 @@ Code Seq# Include File Comments 'p' 80-9F linux/ppdev.h user-space parport <mailto:tim@cyberelk.net> 'p' A1-A5 linux/pps.h LinuxPPS +'p' B1-B3 linux/pps_gen.h LinuxPPS <mailto:giometti@linux.it> 'q' 00-1F linux/serio.h 'q' 80-FF linux/telephony.h Internet PhoneJACK, Internet LineJACK @@ -311,6 +312,7 @@ Code Seq# Include File Comments <mailto:oe@port.de> 'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict! '|' 00-7F linux/media.h +'|' 80-9F samples/ Any sample and example drivers 0x80 00-1F linux/fb.h 0x81 00-1F linux/vduse.h 0x89 00-06 arch/x86/include/asm/sockios.h @@ -368,6 +370,8 @@ Code Seq# Include File Comments 0xB7 all uapi/linux/remoteproc_cdev.h <mailto:linux-remoteproc@vger.kernel.org> 0xB7 all uapi/linux/nsfs.h <mailto:Andrei Vagin <avagin@openvz.org>> 0xB8 01-02 uapi/misc/mrvl_cn10k_dpi.h Marvell CN10K DPI driver +0xB8 all uapi/linux/mshv.h Microsoft Hyper-V /dev/mshv driver + <mailto:linux-hyperv@vger.kernel.org> 0xC0 00-0F linux/usb/iowarrior.h 0xCA 00-0F uapi/misc/cxl.h 0xCA 10-2F uapi/misc/ocxl.h diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst index d639c61cb472..ad587f53fe41 100644 --- a/Documentation/userspace-api/landlock.rst +++ b/Documentation/userspace-api/landlock.rst @@ -8,7 +8,7 @@ Landlock: unprivileged access control ===================================== :Author: Mickaël Salaün -:Date: October 2024 +:Date: January 2025 The goal of Landlock is to enable restriction of ambient rights (e.g. global filesystem or network access) for a set of processes. Because Landlock @@ -329,11 +329,11 @@ non-sandboxed process, we can specify this restriction with A sandboxed process can connect to a non-sandboxed process when its domain is not scoped. If a process's domain is scoped, it can only connect to sockets created by processes in the same scope. -Moreover, If a process is scoped to send signal to a non-scoped process, it can +Moreover, if a process is scoped to send signal to a non-scoped process, it can only send signals to processes in the same scope. A connected datagram socket behaves like a stream socket when its domain is -scoped, meaning if the domain is scoped after the socket is connected , it can +scoped, meaning if the domain is scoped after the socket is connected, it can still :manpage:`send(2)` data just like a stream socket. However, in the same scenario, a non-connected datagram socket cannot send data (with :manpage:`sendto(2)`) outside its scope. diff --git a/Documentation/userspace-api/media/drivers/uvcvideo.rst b/Documentation/userspace-api/media/drivers/uvcvideo.rst index a290f9fadae9..dbb30ad389ae 100644 --- a/Documentation/userspace-api/media/drivers/uvcvideo.rst +++ b/Documentation/userspace-api/media/drivers/uvcvideo.rst @@ -181,6 +181,7 @@ Argument: struct uvc_xu_control_mapping UVC_CTRL_DATA_TYPE_BOOLEAN Boolean UVC_CTRL_DATA_TYPE_ENUM Enumeration UVC_CTRL_DATA_TYPE_BITMASK Bitmask + UVC_CTRL_DATA_TYPE_RECT Rectangular area UVCIOC_CTRL_QUERY - Query a UVC XU control @@ -255,3 +256,66 @@ Argument: struct uvc_xu_control_query __u8 query Request code to send to the device __u16 size Control data size (in bytes) __u8 *data Control value + + +Driver-specific V4L2 controls +----------------------------- + +The uvcvideo driver implements the following UVC-specific controls: + +``V4L2_CID_UVC_REGION_OF_INTEREST_RECT (struct)`` + This control determines the region of interest (ROI). ROI is a + rectangular area represented by a struct :c:type:`v4l2_rect`. The + rectangle is in global sensor coordinates using pixel units. It is + independent of the field of view, not impacted by any cropping or + scaling. + + Use ``V4L2_CTRL_WHICH_MIN_VAL`` and ``V4L2_CTRL_WHICH_MAX_VAL`` to query + the range of rectangle sizes. + + Setting a ROI allows the camera to optimize the capture for the region. + The value of ``V4L2_CID_REGION_OF_INTEREST_AUTO`` control determines + the detailed behavior. + + An example of use of this control, can be found in the: + `Chrome OS USB camera HAL. + <https://chromium.googlesource.com/chromiumos/platform2/+/refs/heads/release-R121-15699.B/camera/hal/usb/>` + + +``V4L2_CID_UVC_REGION_OF_INTEREST_AUTO (bitmask)`` + This determines which, if any, on-board features should track to the + Region of Interest specified by the current value of + ``V4L2_CID_UVD__REGION_OF_INTEREST_RECT``. + + Max value is a mask indicating all supported Auto Controls. + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_EXPOSURE`` + - Setting this bit causes automatic exposure to track the region of + interest instead of the whole image. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_IRIS`` + - Setting this bit causes automatic iris to track the region of interest + instead of the whole image. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_WHITE_BALANCE`` + - Setting this bit causes automatic white balance to track the region + of interest instead of the whole image. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_FOCUS`` + - Setting this bit causes automatic focus adjustment to track the region + of interest instead of the whole image. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_FACE_DETECT`` + - Setting this bit causes automatic face detection to track the region of + interest instead of the whole image. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_DETECT_AND_TRACK`` + - Setting this bit enables automatic face detection and tracking. The + current value of ``V4L2_CID_REGION_OF_INTEREST_RECT`` may be updated by + the driver. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_IMAGE_STABILIZATION`` + - Setting this bit enables automatic image stabilization. The + current value of ``V4L2_CID_REGION_OF_INTEREST_RECT`` may be updated by + the driver. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_HIGHER_QUALITY`` + - Setting this bit enables automatically capture the specified region + with higher quality if possible. diff --git a/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst b/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst index 34d6a0a1f4d3..70b5966aaff8 100644 --- a/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst +++ b/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst @@ -6,7 +6,7 @@ Remote Controller's sysfs nodes ******************************* -As defined at ``Documentation/ABI/testing/sysfs-class-rc``, those are +As defined at Documentation/ABI/testing/sysfs-class-rc, those are the sysfs nodes that control the Remote Controllers: diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst index 4d56c0528ad7..b8698b85bd80 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -199,6 +199,10 @@ still cause this situation. - ``p_area`` - A pointer to a struct :c:type:`v4l2_area`. Valid if this control is of type ``V4L2_CTRL_TYPE_AREA``. + * - struct :c:type:`v4l2_rect` * + - ``p_rect`` + - A pointer to a struct :c:type:`v4l2_rect`. Valid if this control is + of type ``V4L2_CTRL_TYPE_RECT``. * - struct :c:type:`v4l2_ctrl_h264_sps` * - ``p_h264_sps`` - A pointer to a struct :c:type:`v4l2_ctrl_h264_sps`. Valid if this control is @@ -334,14 +338,26 @@ still cause this situation. - Which value of the control to get/set/try. * - :cspan:`2` ``V4L2_CTRL_WHICH_CUR_VAL`` will return the current value of the control, ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default - value of the control and ``V4L2_CTRL_WHICH_REQUEST_VAL`` indicates that - these controls have to be retrieved from a request or tried/set for - a request. In the latter case the ``request_fd`` field contains the + value of the control, ``V4L2_CTRL_WHICH_MIN_VAL`` will return the minimum + value of the control, and ``V4L2_CTRL_WHICH_MAX_VAL`` will return the maximum + value of the control. ``V4L2_CTRL_WHICH_REQUEST_VAL`` indicates that + the control value has to be retrieved from a request or tried/set for + a request. In that case the ``request_fd`` field contains the file descriptor of the request that should be used. If the device does not support requests, then ``EACCES`` will be returned. - When using ``V4L2_CTRL_WHICH_DEF_VAL`` be aware that you can only - get the default value of the control, you cannot set or try it. + When using ``V4L2_CTRL_WHICH_DEF_VAL``, ``V4L2_CTRL_WHICH_MIN_VAL`` + or ``V4L2_CTRL_WHICH_MAX_VAL`` be aware that you can only get the + default/minimum/maximum value of the control, you cannot set or try it. + + Whether a control supports querying the minimum and maximum values using + ``V4L2_CTRL_WHICH_MIN_VAL`` and ``V4L2_CTRL_WHICH_MAX_VAL`` is indicated + by the ``V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX`` flag. Most non-compound + control types support this. For controls with compound types, the + definition of minimum/maximum values are provided by + the control documentation. If a compound control does not document the + meaning of minimum/maximum value, then querying the minimum or maximum + value will result in the error code -EINVAL. For backwards compatibility you can also use a control class here (see :ref:`ctrl-class`). In that case all controls have to diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index 4d38acafe8e1..3549417c7feb 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -441,6 +441,16 @@ See also the examples in :ref:`control`. - n/a - A struct :c:type:`v4l2_area`, containing the width and the height of a rectangular area. Units depend on the use case. + * - ``V4L2_CTRL_TYPE_RECT`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_rect`, containing a rectangle described by + the position of its top-left corner, the width and the height. Units + depend on the use case. Support for ``V4L2_CTRL_WHICH_MIN_VAL`` and + ``V4L2_CTRL_WHICH_MAX_VAL`` is optional and depends on the + ``V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX`` flag. See the documentation of + the specific control on how to interpret the minimum and maximum values. * - ``V4L2_CTRL_TYPE_H264_SPS`` - n/a - n/a @@ -657,6 +667,10 @@ See also the examples in :ref:`control`. ``dims[0]``. So setting the control with a differently sized array will change the ``elems`` field when the control is queried afterwards. + * - ``V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX`` + - 0x1000 + - This control supports getting minimum and maximum values using + vidioc_g_ext_ctrls with V4L2_CTRL_WHICH_MIN/MAX_VAL. Return Value ============ diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index 429b5cdf05c3..35d3456cc812 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -150,6 +150,7 @@ replace symbol V4L2_CTRL_TYPE_HEVC_SPS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_HEVC_PPS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_AREA :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_RECT :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_FWHT_PARAMS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_VP8_FRAME :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_VP9_COMPRESSED_HDR :c:type:`v4l2_ctrl_type` @@ -395,6 +396,7 @@ replace define V4L2_CTRL_FLAG_HAS_PAYLOAD control-flags replace define V4L2_CTRL_FLAG_EXECUTE_ON_WRITE control-flags replace define V4L2_CTRL_FLAG_MODIFY_LAYOUT control-flags replace define V4L2_CTRL_FLAG_DYNAMIC_ARRAY control-flags +replace define V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX control-flags replace define V4L2_CTRL_FLAG_NEXT_CTRL control replace define V4L2_CTRL_FLAG_NEXT_COMPOUND control @@ -569,6 +571,8 @@ ignore define V4L2_CTRL_DRIVER_PRIV ignore define V4L2_CTRL_MAX_DIMS ignore define V4L2_CTRL_WHICH_CUR_VAL ignore define V4L2_CTRL_WHICH_DEF_VAL +ignore define V4L2_CTRL_WHICH_MIN_VAL +ignore define V4L2_CTRL_WHICH_MAX_VAL ignore define V4L2_CTRL_WHICH_REQUEST_VAL ignore define V4L2_OUT_CAP_CUSTOM_TIMINGS ignore define V4L2_CID_MAX_CTRLS diff --git a/Documentation/userspace-api/netlink/c-code-gen.rst b/Documentation/userspace-api/netlink/c-code-gen.rst index 89de42c13350..46415e6d646d 100644 --- a/Documentation/userspace-api/netlink/c-code-gen.rst +++ b/Documentation/userspace-api/netlink/c-code-gen.rst @@ -56,7 +56,9 @@ If ``name-prefix`` is specified it replaces the ``$family-$enum`` portion of the entry name. Boolean ``render-max`` controls creation of the max values -(which are enabled by default for attribute enums). +(which are enabled by default for attribute enums). These max +values are named ``__$pfx-MAX`` and ``$pfx-MAX``. The name +of the first value can be overridden via ``enum-cnt-name`` property. Attributes ========== diff --git a/Documentation/userspace-api/netlink/intro-specs.rst b/Documentation/userspace-api/netlink/intro-specs.rst index bada89699455..a4435ae4628d 100644 --- a/Documentation/userspace-api/netlink/intro-specs.rst +++ b/Documentation/userspace-api/netlink/intro-specs.rst @@ -15,7 +15,7 @@ developing Netlink related code. The tool is implemented in Python and can use a YAML specification to issue Netlink requests to the kernel. Only Generic Netlink is supported. -The tool is located at ``tools/net/ynl/cli.py``. It accepts +The tool is located at ``tools/net/ynl/pyynl/cli.py``. It accepts a handul of arguments, the most important ones are: - ``--spec`` - point to the spec file @@ -27,7 +27,7 @@ YAML specs can be found under ``Documentation/netlink/specs/``. Example use:: - $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/ethtool.yaml \ + $ ./tools/net/ynl/pyynl/cli.py --spec Documentation/netlink/specs/ethtool.yaml \ --do rings-get \ --json '{"header":{"dev-index": 18}}' {'header': {'dev-index': 18, 'dev-name': 'eni1np1'}, @@ -75,7 +75,7 @@ the two marker lines like above to a file, add that file to git, and run the regeneration tool. Grep the tree for ``YNL-GEN`` to see other examples. -The code generation itself is performed by ``tools/net/ynl/ynl-gen-c.py`` +The code generation itself is performed by ``tools/net/ynl/pyynl/ynl_gen_c.py`` but it takes a few arguments so calling it directly for each file quickly becomes tedious. @@ -84,7 +84,7 @@ YNL lib ``tools/net/ynl/lib/`` contains an implementation of a C library (based on libmnl) which integrates with code generated by -``tools/net/ynl/ynl-gen-c.py`` to create easy to use netlink wrappers. +``tools/net/ynl/pyynl/ynl_gen_c.py`` to create easy to use netlink wrappers. YNL basics ---------- diff --git a/Documentation/userspace-api/ntsync.rst b/Documentation/userspace-api/ntsync.rst new file mode 100644 index 000000000000..25e7c4aef968 --- /dev/null +++ b/Documentation/userspace-api/ntsync.rst @@ -0,0 +1,385 @@ +=================================== +NT synchronization primitive driver +=================================== + +This page documents the user-space API for the ntsync driver. + +ntsync is a support driver for emulation of NT synchronization +primitives by user-space NT emulators. It exists because implementation +in user-space, using existing tools, cannot match Windows performance +while offering accurate semantics. It is implemented entirely in +software, and does not drive any hardware device. + +This interface is meant as a compatibility tool only, and should not +be used for general synchronization. Instead use generic, versatile +interfaces such as futex(2) and poll(2). + +Synchronization primitives +========================== + +The ntsync driver exposes three types of synchronization primitives: +semaphores, mutexes, and events. + +A semaphore holds a single volatile 32-bit counter, and a static 32-bit +integer denoting the maximum value. It is considered signaled (that is, +can be acquired without contention, or will wake up a waiting thread) +when the counter is nonzero. The counter is decremented by one when a +wait is satisfied. Both the initial and maximum count are established +when the semaphore is created. + +A mutex holds a volatile 32-bit recursion count, and a volatile 32-bit +identifier denoting its owner. A mutex is considered signaled when its +owner is zero (indicating that it is not owned). The recursion count is +incremented when a wait is satisfied, and ownership is set to the given +identifier. + +A mutex also holds an internal flag denoting whether its previous owner +has died; such a mutex is said to be abandoned. Owner death is not +tracked automatically based on thread death, but rather must be +communicated using ``NTSYNC_IOC_MUTEX_KILL``. An abandoned mutex is +inherently considered unowned. + +Except for the "unowned" semantics of zero, the actual value of the +owner identifier is not interpreted by the ntsync driver at all. The +intended use is to store a thread identifier; however, the ntsync +driver does not actually validate that a calling thread provides +consistent or unique identifiers. + +An event is similar to a semaphore with a maximum count of one. It holds +a volatile boolean state denoting whether it is signaled or not. There +are two types of events, auto-reset and manual-reset. An auto-reset +event is designaled when a wait is satisfied; a manual-reset event is +not. The event type is specified when the event is created. + +Unless specified otherwise, all operations on an object are atomic and +totally ordered with respect to other operations on the same object. + +Objects are represented by files. When all file descriptors to an +object are closed, that object is deleted. + +Char device +=========== + +The ntsync driver creates a single char device /dev/ntsync. Each file +description opened on the device represents a unique instance intended +to back an individual NT virtual machine. Objects created by one ntsync +instance may only be used with other objects created by the same +instance. + +ioctl reference +=============== + +All operations on the device are done through ioctls. There are four +structures used in ioctl calls:: + + struct ntsync_sem_args { + __u32 count; + __u32 max; + }; + + struct ntsync_mutex_args { + __u32 owner; + __u32 count; + }; + + struct ntsync_event_args { + __u32 signaled; + __u32 manual; + }; + + struct ntsync_wait_args { + __u64 timeout; + __u64 objs; + __u32 count; + __u32 owner; + __u32 index; + __u32 alert; + __u32 flags; + __u32 pad; + }; + +Depending on the ioctl, members of the structure may be used as input, +output, or not at all. + +The ioctls on the device file are as follows: + +.. c:macro:: NTSYNC_IOC_CREATE_SEM + + Create a semaphore object. Takes a pointer to struct + :c:type:`ntsync_sem_args`, which is used as follows: + + .. list-table:: + + * - ``count`` + - Initial count of the semaphore. + * - ``max`` + - Maximum count of the semaphore. + + Fails with ``EINVAL`` if ``count`` is greater than ``max``. + On success, returns a file descriptor the created semaphore. + +.. c:macro:: NTSYNC_IOC_CREATE_MUTEX + + Create a mutex object. Takes a pointer to struct + :c:type:`ntsync_mutex_args`, which is used as follows: + + .. list-table:: + + * - ``count`` + - Initial recursion count of the mutex. + * - ``owner`` + - Initial owner of the mutex. + + If ``owner`` is nonzero and ``count`` is zero, or if ``owner`` is + zero and ``count`` is nonzero, the function fails with ``EINVAL``. + On success, returns a file descriptor the created mutex. + +.. c:macro:: NTSYNC_IOC_CREATE_EVENT + + Create an event object. Takes a pointer to struct + :c:type:`ntsync_event_args`, which is used as follows: + + .. list-table:: + + * - ``signaled`` + - If nonzero, the event is initially signaled, otherwise + nonsignaled. + * - ``manual`` + - If nonzero, the event is a manual-reset event, otherwise + auto-reset. + + On success, returns a file descriptor the created event. + +The ioctls on the individual objects are as follows: + +.. c:macro:: NTSYNC_IOC_SEM_POST + + Post to a semaphore object. Takes a pointer to a 32-bit integer, + which on input holds the count to be added to the semaphore, and on + output contains its previous count. + + If adding to the semaphore's current count would raise the latter + past the semaphore's maximum count, the ioctl fails with + ``EOVERFLOW`` and the semaphore is not affected. If raising the + semaphore's count causes it to become signaled, eligible threads + waiting on this semaphore will be woken and the semaphore's count + decremented appropriately. + +.. c:macro:: NTSYNC_IOC_MUTEX_UNLOCK + + Release a mutex object. Takes a pointer to struct + :c:type:`ntsync_mutex_args`, which is used as follows: + + .. list-table:: + + * - ``owner`` + - Specifies the owner trying to release this mutex. + * - ``count`` + - On output, contains the previous recursion count. + + If ``owner`` is zero, the ioctl fails with ``EINVAL``. If ``owner`` + is not the current owner of the mutex, the ioctl fails with + ``EPERM``. + + The mutex's count will be decremented by one. If decrementing the + mutex's count causes it to become zero, the mutex is marked as + unowned and signaled, and eligible threads waiting on it will be + woken as appropriate. + +.. c:macro:: NTSYNC_IOC_SET_EVENT + + Signal an event object. Takes a pointer to a 32-bit integer, which on + output contains the previous state of the event. + + Eligible threads will be woken, and auto-reset events will be + designaled appropriately. + +.. c:macro:: NTSYNC_IOC_RESET_EVENT + + Designal an event object. Takes a pointer to a 32-bit integer, which + on output contains the previous state of the event. + +.. c:macro:: NTSYNC_IOC_PULSE_EVENT + + Wake threads waiting on an event object while leaving it in an + unsignaled state. Takes a pointer to a 32-bit integer, which on + output contains the previous state of the event. + + A pulse operation can be thought of as a set followed by a reset, + performed as a single atomic operation. If two threads are waiting on + an auto-reset event which is pulsed, only one will be woken. If two + threads are waiting a manual-reset event which is pulsed, both will + be woken. However, in both cases, the event will be unsignaled + afterwards, and a simultaneous read operation will always report the + event as unsignaled. + +.. c:macro:: NTSYNC_IOC_READ_SEM + + Read the current state of a semaphore object. Takes a pointer to + struct :c:type:`ntsync_sem_args`, which is used as follows: + + .. list-table:: + + * - ``count`` + - On output, contains the current count of the semaphore. + * - ``max`` + - On output, contains the maximum count of the semaphore. + +.. c:macro:: NTSYNC_IOC_READ_MUTEX + + Read the current state of a mutex object. Takes a pointer to struct + :c:type:`ntsync_mutex_args`, which is used as follows: + + .. list-table:: + + * - ``owner`` + - On output, contains the current owner of the mutex, or zero + if the mutex is not currently owned. + * - ``count`` + - On output, contains the current recursion count of the mutex. + + If the mutex is marked as abandoned, the function fails with + ``EOWNERDEAD``. In this case, ``count`` and ``owner`` are set to + zero. + +.. c:macro:: NTSYNC_IOC_READ_EVENT + + Read the current state of an event object. Takes a pointer to struct + :c:type:`ntsync_event_args`, which is used as follows: + + .. list-table:: + + * - ``signaled`` + - On output, contains the current state of the event. + * - ``manual`` + - On output, contains 1 if the event is a manual-reset event, + and 0 otherwise. + +.. c:macro:: NTSYNC_IOC_KILL_OWNER + + Mark a mutex as unowned and abandoned if it is owned by the given + owner. Takes an input-only pointer to a 32-bit integer denoting the + owner. If the owner is zero, the ioctl fails with ``EINVAL``. If the + owner does not own the mutex, the function fails with ``EPERM``. + + Eligible threads waiting on the mutex will be woken as appropriate + (and such waits will fail with ``EOWNERDEAD``, as described below). + +.. c:macro:: NTSYNC_IOC_WAIT_ANY + + Poll on any of a list of objects, atomically acquiring at most one. + Takes a pointer to struct :c:type:`ntsync_wait_args`, which is + used as follows: + + .. list-table:: + + * - ``timeout`` + - Absolute timeout in nanoseconds. If ``NTSYNC_WAIT_REALTIME`` + is set, the timeout is measured against the REALTIME clock; + otherwise it is measured against the MONOTONIC clock. If the + timeout is equal to or earlier than the current time, the + function returns immediately without sleeping. If ``timeout`` + is U64_MAX, the function will sleep until an object is + signaled, and will not fail with ``ETIMEDOUT``. + * - ``objs`` + - Pointer to an array of ``count`` file descriptors + (specified as an integer so that the structure has the same + size regardless of architecture). If any object is + invalid, the function fails with ``EINVAL``. + * - ``count`` + - Number of objects specified in the ``objs`` array. + If greater than ``NTSYNC_MAX_WAIT_COUNT``, the function fails + with ``EINVAL``. + * - ``owner`` + - Mutex owner identifier. If any object in ``objs`` is a mutex, + the ioctl will attempt to acquire that mutex on behalf of + ``owner``. If ``owner`` is zero, the ioctl fails with + ``EINVAL``. + * - ``index`` + - On success, contains the index (into ``objs``) of the object + which was signaled. If ``alert`` was signaled instead, + this contains ``count``. + * - ``alert`` + - Optional event object file descriptor. If nonzero, this + specifies an "alert" event object which, if signaled, will + terminate the wait. If nonzero, the identifier must point to a + valid event. + * - ``flags`` + - Zero or more flags. Currently the only flag is + ``NTSYNC_WAIT_REALTIME``, which causes the timeout to be + measured against the REALTIME clock instead of MONOTONIC. + * - ``pad`` + - Unused, must be set to zero. + + This function attempts to acquire one of the given objects. If unable + to do so, it sleeps until an object becomes signaled, subsequently + acquiring it, or the timeout expires. In the latter case the ioctl + fails with ``ETIMEDOUT``. The function only acquires one object, even + if multiple objects are signaled. + + A semaphore is considered to be signaled if its count is nonzero, and + is acquired by decrementing its count by one. A mutex is considered + to be signaled if it is unowned or if its owner matches the ``owner`` + argument, and is acquired by incrementing its recursion count by one + and setting its owner to the ``owner`` argument. An auto-reset event + is acquired by designaling it; a manual-reset event is not affected + by acquisition. + + Acquisition is atomic and totally ordered with respect to other + operations on the same object. If two wait operations (with different + ``owner`` identifiers) are queued on the same mutex, only one is + signaled. If two wait operations are queued on the same semaphore, + and a value of one is posted to it, only one is signaled. + + If an abandoned mutex is acquired, the ioctl fails with + ``EOWNERDEAD``. Although this is a failure return, the function may + otherwise be considered successful. The mutex is marked as owned by + the given owner (with a recursion count of 1) and as no longer + abandoned, and ``index`` is still set to the index of the mutex. + + The ``alert`` argument is an "extra" event which can terminate the + wait, independently of all other objects. + + It is valid to pass the same object more than once, including by + passing the same event in the ``objs`` array and in ``alert``. If a + wakeup occurs due to that object being signaled, ``index`` is set to + the lowest index corresponding to that object. + + The function may fail with ``EINTR`` if a signal is received. + +.. c:macro:: NTSYNC_IOC_WAIT_ALL + + Poll on a list of objects, atomically acquiring all of them. Takes a + pointer to struct :c:type:`ntsync_wait_args`, which is used + identically to ``NTSYNC_IOC_WAIT_ANY``, except that ``index`` is + always filled with zero on success if not woken via alert. + + This function attempts to simultaneously acquire all of the given + objects. If unable to do so, it sleeps until all objects become + simultaneously signaled, subsequently acquiring them, or the timeout + expires. In the latter case the ioctl fails with ``ETIMEDOUT`` and no + objects are modified. + + Objects may become signaled and subsequently designaled (through + acquisition by other threads) while this thread is sleeping. Only + once all objects are simultaneously signaled does the ioctl acquire + them and return. The entire acquisition is atomic and totally ordered + with respect to other operations on any of the given objects. + + If an abandoned mutex is acquired, the ioctl fails with + ``EOWNERDEAD``. Similarly to ``NTSYNC_IOC_WAIT_ANY``, all objects are + nevertheless marked as acquired. Note that if multiple mutex objects + are specified, there is no way to know which were marked as + abandoned. + + As with "any" waits, the ``alert`` argument is an "extra" event which + can terminate the wait. Critically, however, an "all" wait will + succeed if all members in ``objs`` are signaled, *or* if ``alert`` is + signaled. In the latter case ``index`` will be set to ``count``. As + with "any" waits, if both conditions are filled, the former takes + priority, and objects in ``objs`` will be acquired. + + Unlike ``NTSYNC_IOC_WAIT_ANY``, it is not valid to pass the same + object more than once, nor is it valid to pass the same object in + ``objs`` and in ``alert``. If this is attempted, the function fails + with ``EINVAL``. diff --git a/Documentation/userspace-api/sysfs-platform_profile.rst b/Documentation/userspace-api/sysfs-platform_profile.rst index 4fccde2e4563..7f013356118a 100644 --- a/Documentation/userspace-api/sysfs-platform_profile.rst +++ b/Documentation/userspace-api/sysfs-platform_profile.rst @@ -40,3 +40,41 @@ added. Drivers which wish to introduce new profile names must: 1. Explain why the existing profile names cannot be used. 2. Add the new profile name, along with a clear description of the expected behaviour, to the sysfs-platform_profile ABI documentation. + +"Custom" profile support +======================== +The platform_profile class also supports profiles advertising a "custom" +profile. This is intended to be set by drivers when the setttings in the +driver have been modified in a way that a standard profile doesn't represent +the current state. + +Multiple driver support +======================= +When multiple drivers on a system advertise a platform profile handler, the +platform profile handler core will only advertise the profiles that are +common between all drivers to the ``/sys/firmware/acpi`` interfaces. + +This is to ensure there is no ambiguity on what the profile names mean when +all handlers don't support a profile. + +Individual drivers will register a 'platform_profile' class device that has +similar semantics as the ``/sys/firmware/acpi/platform_profile`` interface. + +To discover which driver is associated with a platform profile handler the +user can read the ``name`` attribute of the class device. + +To discover available profiles from the class interface the user can read the +``choices`` attribute. + +If a user wants to select a profile for a specific driver, they can do so +by writing to the ``profile`` attribute of the driver's class device. + +This will allow users to set different profiles for different drivers on the +same system. If the selected profile by individual drivers differs the +platform profile handler core will display the profile 'custom' to indicate +that the profiles are not the same. + +While the ``platform_profile`` attribute has the value ``custom``, writing a +common profile from ``platform_profile_choices`` to the platform_profile +attribute of the platform profile handler core will set the profile for all +drivers. diff --git a/Documentation/virt/hyperv/hibernation.rst b/Documentation/virt/hyperv/hibernation.rst new file mode 100644 index 000000000000..4ff27f4a317a --- /dev/null +++ b/Documentation/virt/hyperv/hibernation.rst @@ -0,0 +1,336 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Hibernating Guest VMs +===================== + +Background +---------- +Linux supports the ability to hibernate itself in order to save power. +Hibernation is sometimes called suspend-to-disk, as it writes a memory +image to disk and puts the hardware into the lowest possible power +state. Upon resume from hibernation, the hardware is restarted and the +memory image is restored from disk so that it can resume execution +where it left off. See the "Hibernation" section of +Documentation/admin-guide/pm/sleep-states.rst. + +Hibernation is usually done on devices with a single user, such as a +personal laptop. For example, the laptop goes into hibernation when +the cover is closed, and resumes when the cover is opened again. +Hibernation and resume happen on the same hardware, and Linux kernel +code orchestrating the hibernation steps assumes that the hardware +configuration is not changed while in the hibernated state. + +Hibernation can be initiated within Linux by writing "disk" to +/sys/power/state or by invoking the reboot system call with the +appropriate arguments. This functionality may be wrapped by user space +commands such "systemctl hibernate" that are run directly from a +command line or in response to events such as the laptop lid closing. + +Considerations for Guest VM Hibernation +--------------------------------------- +Linux guests on Hyper-V can also be hibernated, in which case the +hardware is the virtual hardware provided by Hyper-V to the guest VM. +Only the targeted guest VM is hibernated, while other guest VMs and +the underlying Hyper-V host continue to run normally. While the +underlying Windows Hyper-V and physical hardware on which it is +running might also be hibernated using hibernation functionality in +the Windows host, host hibernation and its impact on guest VMs is not +in scope for this documentation. + +Resuming a hibernated guest VM can be more challenging than with +physical hardware because VMs make it very easy to change the hardware +configuration between the hibernation and resume. Even when the resume +is done on the same VM that hibernated, the memory size might be +changed, or virtual NICs or SCSI controllers might be added or +removed. Virtual PCI devices assigned to the VM might be added or +removed. Most such changes cause the resume steps to fail, though +adding a new virtual NIC, SCSI controller, or vPCI device should work. + +Additional complexity can ensue because the disks of the hibernated VM +can be moved to another newly created VM that otherwise has the same +virtual hardware configuration. While it is desirable for resume from +hibernation to succeed after such a move, there are challenges. See +details on this scenario and its limitations in the "Resuming on a +Different VM" section below. + +Hyper-V also provides ways to move a VM from one Hyper-V host to +another. Hyper-V tries to ensure processor model and Hyper-V version +compatibility using VM Configuration Versions, and prevents moves to +a host that isn't compatible. Linux adapts to host and processor +differences by detecting them at boot time, but such detection is not +done when resuming execution in the hibernation image. If a VM is +hibernated on one host, then resumed on a host with a different processor +model or Hyper-V version, settings recorded in the hibernation image +may not match the new host. Because Linux does not detect such +mismatches when resuming the hibernation image, undefined behavior +and failures could result. + + +Enabling Guest VM Hibernation +----------------------------- +Hibernation of a Hyper-V guest VM is disabled by default because +hibernation is incompatible with memory hot-add, as provided by the +Hyper-V balloon driver. If hot-add is used and the VM hibernates, it +hibernates with more memory than it started with. But when the VM +resumes from hibernation, Hyper-V gives the VM only the originally +assigned memory, and the memory size mismatch causes resume to fail. + +To enable a Hyper-V VM for hibernation, the Hyper-V administrator must +enable the ACPI virtual S4 sleep state in the ACPI configuration that +Hyper-V provides to the guest VM. Such enablement is accomplished by +modifying a WMI property of the VM, the steps for which are outside +the scope of this documentation but are available on the web. +Enablement is treated as the indicator that the administrator +prioritizes Linux hibernation in the VM over hot-add, so the Hyper-V +balloon driver in Linux disables hot-add. Enablement is indicated if +the contents of /sys/power/disk contains "platform" as an option. The +enablement is also visible in /sys/bus/vmbus/hibernation. See function +hv_is_hibernation_supported(). + +Linux supports ACPI sleep states on x86, but not on arm64. So Linux +guest VM hibernation is not available on Hyper-V for arm64. + +Initiating Guest VM Hibernation +------------------------------- +Guest VMs can self-initiate hibernation using the standard Linux +methods of writing "disk" to /sys/power/state or the reboot system +call. As an additional layer, Linux guests on Hyper-V support the +"Shutdown" integration service, via which a Hyper-V administrator can +tell a Linux VM to hibernate using a command outside the VM. The +command generates a request to the Hyper-V shutdown driver in Linux, +which sends the uevent "EVENT=hibernate". See kernel functions +shutdown_onchannelcallback() and send_hibernate_uevent(). A udev rule +must be provided in the VM that handles this event and initiates +hibernation. + +Handling VMBus Devices During Hibernation & Resume +-------------------------------------------------- +The VMBus bus driver, and the individual VMBus device drivers, +implement suspend and resume functions that are called as part of the +Linux orchestration of hibernation and of resuming from hibernation. +The overall approach is to leave in place the data structures for the +primary VMBus channels and their associated Linux devices, such as +SCSI controllers and others, so that they are captured in the +hibernation image. This approach allows any state associated with the +device to be persisted across the hibernation/resume. When the VM +resumes, the devices are re-offered by Hyper-V and are connected to +the data structures that already exist in the resumed hibernation +image. + +VMBus devices are identified by class and instance GUID. (See section +"VMBus device creation/deletion" in +Documentation/virt/hyperv/vmbus.rst.) Upon resume from hibernation, +the resume functions expect that the devices offered by Hyper-V have +the same class/instance GUIDs as the devices present at the time of +hibernation. Having the same class/instance GUIDs allows the offered +devices to be matched to the primary VMBus channel data structures in +the memory of the now resumed hibernation image. If any devices are +offered that don't match primary VMBus channel data structures that +already exist, they are processed normally as newly added devices. If +primary VMBus channels that exist in the resumed hibernation image are +not matched with a device offered in the resumed VM, the resume +sequence waits for 10 seconds, then proceeds. But the unmatched device +is likely to cause errors in the resumed VM. + +When resuming existing primary VMBus channels, the newly offered +relids might be different because relids can change on each VM boot, +even if the VM configuration hasn't changed. The VMBus bus driver +resume function matches the class/instance GUIDs, and updates the +relids in case they have changed. + +VMBus sub-channels are not persisted in the hibernation image. Each +VMBus device driver's suspend function must close any sub-channels +prior to hibernation. Closing a sub-channel causes Hyper-V to send a +RESCIND_CHANNELOFFER message, which Linux processes by freeing the +channel data structures so that all vestiges of the sub-channel are +removed. By contrast, primary channels are marked closed and their +ring buffers are freed, but Hyper-V does not send a rescind message, +so the channel data structure continues to exist. Upon resume, the +device driver's resume function re-allocates the ring buffer and +re-opens the existing channel. It then communicates with Hyper-V to +re-open sub-channels from scratch. + +The Linux ends of Hyper-V sockets are forced closed at the time of +hibernation. The guest can't force closing the host end of the socket, +but any host-side actions on the host end will produce an error. + +VMBus devices use the same suspend function for the "freeze" and the +"poweroff" phases, and the same resume function for the "thaw" and +"restore" phases. See the "Entering Hibernation" section of +Documentation/driver-api/pm/devices.rst for the sequencing of the +phases. + +Detailed Hibernation Sequence +----------------------------- +1. The Linux power management (PM) subsystem prepares for + hibernation by freezing user space processes and allocating + memory to hold the hibernation image. +2. As part of the "freeze" phase, Linux PM calls the "suspend" + function for each VMBus device in turn. As described above, this + function removes sub-channels, and leaves the primary channel in + a closed state. +3. Linux PM calls the "suspend" function for the VMBus bus, which + closes any Hyper-V socket channels and unloads the top-level + VMBus connection with the Hyper-V host. +4. Linux PM disables non-boot CPUs, creates the hibernation image in + the previously allocated memory, then re-enables non-boot CPUs. + The hibernation image contains the memory data structures for the + closed primary channels, but no sub-channels. +5. As part of the "thaw" phase, Linux PM calls the "resume" function + for the VMBus bus, which re-establishes the top-level VMBus + connection and requests that Hyper-V re-offer the VMBus devices. + As offers are received for the primary channels, the relids are + updated as previously described. +6. Linux PM calls the "resume" function for each VMBus device. Each + device re-opens its primary channel, and communicates with Hyper-V + to re-establish sub-channels if appropriate. The sub-channels + are re-created as new channels since they were previously removed + entirely in Step 2. +7. With VMBus devices now working again, Linux PM writes the + hibernation image from memory to disk. +8. Linux PM repeats Steps 2 and 3 above as part of the "poweroff" + phase. VMBus channels are closed and the top-level VMBus + connection is unloaded. +9. Linux PM disables non-boot CPUs, and then enters ACPI sleep state + S4. Hibernation is now complete. + +Detailed Resume Sequence +------------------------ +1. The guest VM boots into a fresh Linux OS instance. During boot, + the top-level VMBus connection is established, and synthetic + devices are enabled. This happens via the normal paths that don't + involve hibernation. +2. Linux PM hibernation code reads swap space is to find and read + the hibernation image into memory. If there is no hibernation + image, then this boot becomes a normal boot. +3. If this is a resume from hibernation, the "freeze" phase is used + to shutdown VMBus devices and unload the top-level VMBus + connection in the running fresh OS instance, just like Steps 2 + and 3 in the hibernation sequence. +4. Linux PM disables non-boot CPUs, and transfers control to the + read-in hibernation image. In the now-running hibernation image, + non-boot CPUs are restarted. +5. As part of the "resume" phase, Linux PM repeats Steps 5 and 6 + from the hibernation sequence. The top-level VMBus connection is + re-established, and offers are received and matched to primary + channels in the image. Relids are updated. VMBus device resume + functions re-open primary channels and re-create sub-channels. +6. Linux PM exits the hibernation resume sequence and the VM is now + running normally from the hibernation image. + +Key-Value Pair (KVP) Pseudo-Device Anomalies +-------------------------------------------- +The VMBus KVP device behaves differently from other pseudo-devices +offered by Hyper-V. When the KVP primary channel is closed, Hyper-V +sends a rescind message, which causes all vestiges of the device to be +removed. But Hyper-V then re-offers the device, causing it to be newly +re-created. The removal and re-creation occurs during the "freeze" +phase of hibernation, so the hibernation image contains the re-created +KVP device. Similar behavior occurs during the "freeze" phase of the +resume sequence while still in the fresh OS instance. But in both +cases, the top-level VMBus connection is subsequently unloaded, which +causes the device to be discarded on the Hyper-V side. So no harm is +done and everything still works. + +Virtual PCI devices +------------------- +Virtual PCI devices are physical PCI devices that are mapped directly +into the VM's physical address space so the VM can interact directly +with the hardware. vPCI devices include those accessed via what Hyper-V +calls "Discrete Device Assignment" (DDA), as well as SR-IOV NIC +Virtual Functions (VF) devices. See Documentation/virt/hyperv/vpci.rst. + +Hyper-V DDA devices are offered to guest VMs after the top-level VMBus +connection is established, just like VMBus synthetic devices. They are +statically assigned to the VM, and their instance GUIDs don't change +unless the Hyper-V administrator makes changes to the configuration. +DDA devices are represented in Linux as virtual PCI devices that have +a VMBus identity as well as a PCI identity. Consequently, Linux guest +hibernation first handles DDA devices as VMBus devices in order to +manage the VMBus channel. But then they are also handled as PCI +devices using the hibernation functions implemented by their native +PCI driver. + +SR-IOV NIC VFs also have a VMBus identity as well as a PCI +identity, and overall are processed similarly to DDA devices. A +difference is that VFs are not offered to the VM during initial boot +of the VM. Instead, the VMBus synthetic NIC driver first starts +operating and communicates to Hyper-V that it is prepared to accept a +VF, and then the VF offer is made. However, the VMBus connection +might later be unloaded and then re-established without the VM being +rebooted, as happens in Steps 3 and 5 in the Detailed Hibernation +Sequence above and in the Detailed Resume Sequence. In such a case, +the VFs likely became part of the VM during initial boot, so when the +VMBus connection is re-established, the VFs are offered on the +re-established connection without intervention by the synthetic NIC driver. + +UIO Devices +----------- +A VMBus device can be exposed to user space using the Hyper-V UIO +driver (uio_hv_generic.c) so that a user space driver can control and +operate the device. However, the VMBus UIO driver does not support the +suspend and resume operations needed for hibernation. If a VMBus +device is configured to use the UIO driver, hibernating the VM fails +and Linux continues to run normally. The most common use of the Hyper-V +UIO driver is for DPDK networking, but there are other uses as well. + +Resuming on a Different VM +-------------------------- +This scenario occurs in the Azure public cloud in that a hibernated +customer VM only exists as saved configuration and disks -- the VM no +longer exists on any Hyper-V host. When the customer VM is resumed, a +new Hyper-V VM with identical configuration is created, likely on a +different Hyper-V host. That new Hyper-V VM becomes the resumed +customer VM, and the steps the Linux kernel takes to resume from the +hibernation image must work in that new VM. + +While the disks and their contents are preserved from the original VM, +the Hyper-V-provided VMBus instance GUIDs of the disk controllers and +other synthetic devices would typically be different. The difference +would cause the resume from hibernation to fail, so several things are +done to solve this problem: + +* For VMBus synthetic devices that support only a single instance, + Hyper-V always assigns the same instance GUIDs. For example, the + Hyper-V mouse, the shutdown pseudo-device, the time sync pseudo + device, etc., always have the same instance GUID, both for local + Hyper-V installs as well as in the Azure cloud. + +* VMBus synthetic SCSI controllers may have multiple instances in a + VM, and in the general case instance GUIDs vary from VM to VM. + However, Azure VMs always have exactly two synthetic SCSI + controllers, and Azure code overrides the normal Hyper-V behavior + so these controllers are always assigned the same two instance + GUIDs. Consequently, when a customer VM is resumed on a newly + created VM, the instance GUIDs match. But this guarantee does not + hold for local Hyper-V installs. + +* Similarly, VMBus synthetic NICs may have multiple instances in a + VM, and the instance GUIDs vary from VM to VM. Again, Azure code + overrides the normal Hyper-V behavior so that the instance GUID + of a synthetic NIC in a customer VM does not change, even if the + customer VM is deallocated or hibernated, and then re-constituted + on a newly created VM. As with SCSI controllers, this behavior + does not hold for local Hyper-V installs. + +* vPCI devices do not have the same instance GUIDs when resuming + from hibernation on a newly created VM. Consequently, Azure does + not support hibernation for VMs that have DDA devices such as + NVMe controllers or GPUs. For SR-IOV NIC VFs, Azure removes the + VF from the VM before it hibernates so that the hibernation image + does not contain a VF device. When the VM is resumed it + instantiates a new VF, rather than trying to match against a VF + that is present in the hibernation image. Because Azure must + remove any VFs before initiating hibernation, Azure VM + hibernation must be initiated externally from the Azure Portal or + Azure CLI, which in turn uses the Shutdown integration service to + tell Linux to do the hibernation. If hibernation is self-initiated + within the Azure VM, VFs remain in the hibernation image, and are + not resumed properly. + +In summary, Azure takes special actions to remove VFs and to ensure +that VMBus device instance GUIDs match on a new/different VM, allowing +hibernation to work for most general-purpose Azure VMs sizes. While +similar special actions could be taken when resuming on a different VM +on a local Hyper-V install, orchestrating such actions is not provided +out-of-the-box by local Hyper-V and so requires custom scripting. diff --git a/Documentation/virt/hyperv/index.rst b/Documentation/virt/hyperv/index.rst index 79bc4080329e..c84c40fd61c9 100644 --- a/Documentation/virt/hyperv/index.rst +++ b/Documentation/virt/hyperv/index.rst @@ -11,4 +11,5 @@ Hyper-V Enlightenments vmbus clocks vpci + hibernation coco diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index f15b61317aad..1f8625b7646a 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -1000,6 +1000,10 @@ blobs in userspace. When the guest writes the MSR, kvm copies one page of a blob (32- or 64-bit, depending on the vcpu mode) to guest memory. +The MSR index must be in the range [0x40000000, 0x4fffffff], i.e. must reside +in the range that is unofficially reserved for use by hypervisors. The min/max +values are enumerated via KVM_XEN_MSR_MIN_INDEX and KVM_XEN_MSR_MAX_INDEX. + :: struct kvm_xen_hvm_config { @@ -1419,7 +1423,7 @@ fetch) is injected in the guest. S390: ^^^^^ -Returns -EINVAL if the VM has the KVM_VM_S390_UCONTROL flag set. +Returns -EINVAL or -EEXIST if the VM has the KVM_VM_S390_UCONTROL flag set. Returns -EINVAL if called on a protected VM. 4.36 KVM_SET_TSS_ADDR @@ -1825,15 +1829,18 @@ emulate them efficiently. The fields in each entry are defined as follows: the values returned by the cpuid instruction for this function/index combination -The TSC deadline timer feature (CPUID leaf 1, ecx[24]) is always returned -as false, since the feature depends on KVM_CREATE_IRQCHIP for local APIC -support. Instead it is reported via:: +x2APIC (CPUID leaf 1, ecx[21) and TSC deadline timer (CPUID leaf 1, ecx[24]) +may be returned as true, but they depend on KVM_CREATE_IRQCHIP for in-kernel +emulation of the local APIC. TSC deadline timer support is also reported via:: ioctl(KVM_CHECK_EXTENSION, KVM_CAP_TSC_DEADLINE_TIMER) if that returns true and you use KVM_CREATE_IRQCHIP, or if you emulate the feature in userspace, then you can enable the feature for KVM_SET_CPUID2. +Enabling x2APIC in KVM_SET_CPUID2 requires KVM_CREATE_IRQCHIP as KVM doesn't +support forwarding x2APIC MSR accesses to userspace, i.e. KVM does not support +emulating x2APIC in userspace. 4.47 KVM_PPC_GET_PVINFO ----------------------- @@ -5577,7 +5584,7 @@ KVM_XEN_ATTR_TYPE_SHARED_INFO_HVA in guest physical address space. This attribute should be used in preference to KVM_XEN_ATTR_TYPE_SHARED_INFO as it avoids unnecessary invalidation of an internal cache when the page is - re-mapped in guest physcial address space. + re-mapped in guest physical address space. Setting the hva to zero will disable the shared_info page. @@ -7673,6 +7680,7 @@ branch to guests' 0x200 interrupt vector. :Architectures: x86 :Parameters: args[0] defines which exits are disabled :Returns: 0 on success, -EINVAL when args[0] contains invalid exits + or if any vCPUs have already been created Valid bits in args[0] are:: @@ -8254,6 +8262,24 @@ KVM exits with the register state of either the L1 or L2 guest depending on which executed at the time of an exit. Userspace must take care to differentiate between these cases. +7.37 KVM_CAP_ARM_WRITABLE_IMP_ID_REGS +------------------------------------- + +:Architectures: arm64 +:Target: VM +:Parameters: None +:Returns: 0 on success, -EINVAL if vCPUs have been created before enabling this + capability. + +This capability changes the behavior of the registers that identify a PE +implementation of the Arm architecture: MIDR_EL1, REVIDR_EL1, and AIDR_EL1. +By default, these registers are visible to userspace but treated as invariant. + +When this capability is enabled, KVM allows userspace to change the +aforementioned registers before the first KVM_RUN. These registers are VM +scoped, meaning that the same set of values are presented on all vCPUs in a +given VM. + 8. Other capabilities. ====================== diff --git a/Documentation/virt/kvm/arm/fw-pseudo-registers.rst b/Documentation/virt/kvm/arm/fw-pseudo-registers.rst index b90fd0b0fa66..d78b53b05dfc 100644 --- a/Documentation/virt/kvm/arm/fw-pseudo-registers.rst +++ b/Documentation/virt/kvm/arm/fw-pseudo-registers.rst @@ -116,7 +116,7 @@ The pseudo-firmware bitmap register are as follows: ARM DEN0057A. * KVM_REG_ARM_VENDOR_HYP_BMAP: - Controls the bitmap of the Vendor specific Hypervisor Service Calls. + Controls the bitmap of the Vendor specific Hypervisor Service Calls[0-63]. The following bits are accepted: @@ -127,6 +127,19 @@ The pseudo-firmware bitmap register are as follows: Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_PTP: The bit represents the Precision Time Protocol KVM service. +* KVM_REG_ARM_VENDOR_HYP_BMAP_2: + Controls the bitmap of the Vendor specific Hypervisor Service Calls[64-127]. + + The following bits are accepted: + + Bit-0: KVM_REG_ARM_VENDOR_HYP_BIT_DISCOVER_IMPL_VER + This represents the ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_VER_FUNC_ID + function-id. This is reset to 0. + + Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_DISCOVER_IMPL_CPUS + This represents the ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_CPUS_FUNC_ID + function-id. This is reset to 0. + Errors: ======= ============================================================= diff --git a/Documentation/virt/kvm/arm/hypercalls.rst b/Documentation/virt/kvm/arm/hypercalls.rst index af7bc2c2e0cb..7400a89aabf8 100644 --- a/Documentation/virt/kvm/arm/hypercalls.rst +++ b/Documentation/virt/kvm/arm/hypercalls.rst @@ -142,3 +142,62 @@ region is equal to the memory protection granule advertised by | | | +---------------------------------------------+ | | | | ``INVALID_PARAMETER (-3)`` | +---------------------+----------+----+---------------------------------------------+ + +``ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_VER_FUNC_ID`` +------------------------------------------------------- +Request the target CPU implementation version information and the number of target +implementations for the Guest VM. + ++---------------------+-------------------------------------------------------------+ +| Presence: | Optional; KVM/ARM64 Guests only | ++---------------------+-------------------------------------------------------------+ +| Calling convention: | HVC64 | ++---------------------+----------+--------------------------------------------------+ +| Function ID: | (uint32) | 0xC6000040 | ++---------------------+----------+--------------------------------------------------+ +| Arguments: | None | ++---------------------+----------+----+---------------------------------------------+ +| Return Values: | (int64) | R0 | ``SUCCESS (0)`` | +| | | +---------------------------------------------+ +| | | | ``NOT_SUPPORTED (-1)`` | +| +----------+----+---------------------------------------------+ +| | (uint64) | R1 | Bits [63:32] Reserved/Must be zero | +| | | +---------------------------------------------+ +| | | | Bits [31:16] Major version | +| | | +---------------------------------------------+ +| | | | Bits [15:0] Minor version | +| +----------+----+---------------------------------------------+ +| | (uint64) | R2 | Number of target implementations | +| +----------+----+---------------------------------------------+ +| | (uint64) | R3 | Reserved / Must be zero | ++---------------------+----------+----+---------------------------------------------+ + +``ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_CPUS_FUNC_ID`` +------------------------------------------------------- + +Request the target CPU implementation information for the Guest VM. The Guest kernel +will use this information to enable the associated errata. + ++---------------------+-------------------------------------------------------------+ +| Presence: | Optional; KVM/ARM64 Guests only | ++---------------------+-------------------------------------------------------------+ +| Calling convention: | HVC64 | ++---------------------+----------+--------------------------------------------------+ +| Function ID: | (uint32) | 0xC6000041 | ++---------------------+----------+----+---------------------------------------------+ +| Arguments: | (uint64) | R1 | selected implementation index | +| +----------+----+---------------------------------------------+ +| | (uint64) | R2 | Reserved / Must be zero | +| +----------+----+---------------------------------------------+ +| | (uint64) | R3 | Reserved / Must be zero | ++---------------------+----------+----+---------------------------------------------+ +| Return Values: | (int64) | R0 | ``SUCCESS (0)`` | +| | | +---------------------------------------------+ +| | | | ``INVALID_PARAMETER (-3)`` | +| +----------+----+---------------------------------------------+ +| | (uint64) | R1 | MIDR_EL1 of the selected implementation | +| +----------+----+---------------------------------------------+ +| | (uint64) | R2 | REVIDR_EL1 of the selected implementation | +| +----------+----+---------------------------------------------+ +| | (uint64) | R3 | AIDR_EL1 of the selected implementation | ++---------------------+----------+----+---------------------------------------------+ diff --git a/Documentation/virt/kvm/devices/arm-vgic-its.rst b/Documentation/virt/kvm/devices/arm-vgic-its.rst index e053124f77c4..0f971f83205a 100644 --- a/Documentation/virt/kvm/devices/arm-vgic-its.rst +++ b/Documentation/virt/kvm/devices/arm-vgic-its.rst @@ -126,7 +126,8 @@ KVM_DEV_ARM_VGIC_GRP_ITS_REGS ITS Restore Sequence: --------------------- -The following ordering must be followed when restoring the GIC and the ITS: +The following ordering must be followed when restoring the GIC, ITS, and +KVM_IRQFD assignments: a) restore all guest memory and create vcpus b) restore all redistributors @@ -139,6 +140,8 @@ d) restore the ITS in the following order: 3. Load the ITS table data (KVM_DEV_ARM_ITS_RESTORE_TABLES) 4. Restore GITS_CTLR +e) restore KVM_IRQFD assignments for MSIs + Then vcpus can be started. ITS Table ABI REV0: diff --git a/Documentation/virt/kvm/devices/arm-vgic-v3.rst b/Documentation/virt/kvm/devices/arm-vgic-v3.rst index 5817edb4e046..e860498b1e35 100644 --- a/Documentation/virt/kvm/devices/arm-vgic-v3.rst +++ b/Documentation/virt/kvm/devices/arm-vgic-v3.rst @@ -291,8 +291,18 @@ Groups: | Aff3 | Aff2 | Aff1 | Aff0 | Errors: - ======= ============================================= -EINVAL vINTID is not multiple of 32 or info field is not VGIC_LEVEL_INFO_LINE_LEVEL ======= ============================================= + + KVM_DEV_ARM_VGIC_GRP_MAINT_IRQ + Attributes: + + The attr field of kvm_device_attr encodes the following values: + + bits: | 31 .... 5 | 4 .... 0 | + values: | RES0 | vINTID | + + The vINTID specifies which interrupt is generated when the vGIC + must generate a maintenance interrupt. This must be a PPI. diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst index 31f14ec4a65b..31a9576c07af 100644 --- a/Documentation/virt/kvm/devices/vcpu.rst +++ b/Documentation/virt/kvm/devices/vcpu.rst @@ -142,8 +142,8 @@ the cpu field to the processor id. :Architectures: ARM64 -2.1. ATTRIBUTES: KVM_ARM_VCPU_TIMER_IRQ_VTIMER, KVM_ARM_VCPU_TIMER_IRQ_PTIMER ------------------------------------------------------------------------------ +2.1. ATTRIBUTES: KVM_ARM_VCPU_TIMER_IRQ_{VTIMER,PTIMER,HVTIMER,HPTIMER} +----------------------------------------------------------------------- :Parameters: in kvm_device_attr.addr the address for the timer interrupt is a pointer to an int @@ -159,10 +159,12 @@ A value describing the architected timer interrupt number when connected to an in-kernel virtual GIC. These must be a PPI (16 <= intid < 32). Setting the attribute overrides the default values (see below). -============================= ========================================== -KVM_ARM_VCPU_TIMER_IRQ_VTIMER The EL1 virtual timer intid (default: 27) -KVM_ARM_VCPU_TIMER_IRQ_PTIMER The EL1 physical timer intid (default: 30) -============================= ========================================== +============================== ========================================== +KVM_ARM_VCPU_TIMER_IRQ_VTIMER The EL1 virtual timer intid (default: 27) +KVM_ARM_VCPU_TIMER_IRQ_PTIMER The EL1 physical timer intid (default: 30) +KVM_ARM_VCPU_TIMER_IRQ_HVTIMER The EL2 virtual timer intid (default: 28) +KVM_ARM_VCPU_TIMER_IRQ_HPTIMER The EL2 physical timer intid (default: 26) +============================== ========================================== Setting the same PPI for different timers will prevent the VCPUs from running. Setting the interrupt number on a VCPU configures all VCPUs created at that diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index c56d5f26c750..ae8bce7fecbe 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -196,7 +196,7 @@ writable between reading spte and updating spte. Like below case: The Dirty bit is lost in this case. In order to avoid this kind of issue, we always treat the spte as "volatile" -if it can be updated out of mmu-lock [see spte_has_volatile_bits()]; it means +if it can be updated out of mmu-lock [see spte_needs_atomic_update()]; it means the spte is always atomically updated in this case. 3) flush tlbs due to spte updated @@ -212,7 +212,7 @@ function to update spte (present -> present). Since the spte is "volatile" if it can be updated out of mmu-lock, we always atomically update the spte and the race caused by fast page fault can be avoided. -See the comments in spte_has_volatile_bits() and mmu_spte_update(). +See the comments in spte_needs_atomic_update() and mmu_spte_update(). Lockless Access Tracking: diff --git a/Documentation/wmi/acpi-interface.rst b/Documentation/wmi/acpi-interface.rst index 06fb7fcf4413..f1b28835d23c 100644 --- a/Documentation/wmi/acpi-interface.rst +++ b/Documentation/wmi/acpi-interface.rst @@ -89,6 +89,9 @@ Similar to the ``WExx`` ACPI methods, except that it controls data collection instead of events and thus the last two characters of the ACPI method name are the method ID of the data block to enable/disable. +Those ACPI methods are also called before setting data blocks to match the +behaviour of the Windows driver. + _WED ACPI method ---------------- diff --git a/Documentation/wmi/driver-development-guide.rst b/Documentation/wmi/driver-development-guide.rst index 676873c98680..99ef21fc1c1e 100644 --- a/Documentation/wmi/driver-development-guide.rst +++ b/Documentation/wmi/driver-development-guide.rst @@ -41,6 +41,10 @@ helps in understanding how the WMI device is supposed to work. The path of the A method associated with a given WMI device can be retrieved using the ``lswmi`` utility as mentioned above. +If you are attempting to port a driver to Linux and are working on a Windows +system, `WMIExplorer <https://github.com/vinaypamnani/wmie2>`_ can be useful +for inspecting available WMI methods and invoking them directly. + Basic WMI driver structure -------------------------- @@ -92,6 +96,10 @@ on a given machine. Because of this, WMI drivers should use the state container design pattern as described in Documentation/driver-api/driver-model/design-patterns.rst. +.. warning:: Using both GUID-based and non-GUID-based functions for querying WMI data blocks and + handling WMI events simultaneously on the same device is guaranteed to corrupt the + WMI device state and might lead to erratic behaviour. + WMI method drivers ------------------ |