diff options
Diffstat (limited to 'Documentation')
1847 files changed, 44631 insertions, 13337 deletions
diff --git a/Documentation/ABI/obsolete/o2cb b/Documentation/ABI/obsolete/o2cb index fe7e45e17bc7..8f39b596731d 100644 --- a/Documentation/ABI/obsolete/o2cb +++ b/Documentation/ABI/obsolete/o2cb @@ -1,11 +1,11 @@ What: /sys/o2cb Date: Dec 2005 KernelVersion: 2.6.16 -Contact: ocfs2-devel@oss.oracle.com +Contact: ocfs2-devel@lists.linux.dev Description: Ocfs2-tools looks at 'interface-revision' for versioning information. Each logmask/ file controls a set of debug prints and can be written into with the strings "allow", "deny", or "off". Reading the file returns the current state. Was renamed to /sys/fs/u2cb/ Users: ocfs2-tools. It's sufficient to mail proposed changes to - ocfs2-devel@oss.oracle.com. + ocfs2-devel@lists.linux.dev. diff --git a/Documentation/ABI/removed/o2cb b/Documentation/ABI/removed/o2cb index 20c91adca6d4..61cff238fbe8 100644 --- a/Documentation/ABI/removed/o2cb +++ b/Documentation/ABI/removed/o2cb @@ -1,10 +1,10 @@ What: /sys/o2cb symlink Date: May 2011 KernelVersion: 3.0 -Contact: ocfs2-devel@oss.oracle.com +Contact: ocfs2-devel@lists.linux.dev Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is removed when new versions of ocfs2-tools which know to look in /sys/fs/o2cb are sufficiently prevalent. Don't code new software to look here, it should try /sys/fs/o2cb instead. Users: ocfs2-tools. It's sufficient to mail proposed changes to - ocfs2-devel@oss.oracle.com. + ocfs2-devel@lists.linux.dev. diff --git a/Documentation/ABI/stable/o2cb b/Documentation/ABI/stable/o2cb index b62a967f01a0..3a83b5c54e93 100644 --- a/Documentation/ABI/stable/o2cb +++ b/Documentation/ABI/stable/o2cb @@ -1,10 +1,10 @@ What: /sys/fs/o2cb/ Date: Dec 2005 KernelVersion: 2.6.16 -Contact: ocfs2-devel@oss.oracle.com +Contact: ocfs2-devel@lists.linux.dev Description: Ocfs2-tools looks at 'interface-revision' for versioning information. Each logmask/ file controls a set of debug prints and can be written into with the strings "allow", "deny", or "off". Reading the file returns the current state. Users: ocfs2-tools. It's sufficient to mail proposed changes to - ocfs2-devel@oss.oracle.com. + ocfs2-devel@lists.linux.dev. diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block index c57e5b7cb532..1fe9a553c37b 100644 --- a/Documentation/ABI/stable/sysfs-block +++ b/Documentation/ABI/stable/sysfs-block @@ -295,7 +295,7 @@ Description: capable of executing requests targeting different sector ranges in parallel. For instance, single LUN multi-actuator hard-disks will have an independent_access_ranges directory if the device - correctly advertizes the sector ranges of its actuators. + correctly advertises the sector ranges of its actuators. The independent_access_ranges directory contains one directory per access range, with each range described using the sector diff --git a/Documentation/ABI/stable/sysfs-bus-mhi b/Documentation/ABI/stable/sysfs-bus-mhi index 96ccc3385a2b..1a47f9e0cc84 100644 --- a/Documentation/ABI/stable/sysfs-bus-mhi +++ b/Documentation/ABI/stable/sysfs-bus-mhi @@ -1,7 +1,7 @@ What: /sys/bus/mhi/devices/.../serialnumber Date: Sept 2020 KernelVersion: 5.10 -Contact: Bhaumik Bhatt <bbhatt@codeaurora.org> +Contact: mhi@lists.linux.dev Description: The file holds the serial number of the client device obtained using a BHI (Boot Host Interface) register read after at least one attempt to power up the device has been done. If read @@ -12,7 +12,7 @@ Users: Any userspace application or clients interested in device info. What: /sys/bus/mhi/devices/.../oem_pk_hash Date: Sept 2020 KernelVersion: 5.10 -Contact: Bhaumik Bhatt <bbhatt@codeaurora.org> +Contact: mhi@lists.linux.dev Description: The file holds the OEM PK Hash value of the endpoint device obtained using a BHI (Boot Host Interface) register read after at least one attempt to power up the device has been done. If diff --git a/Documentation/ABI/stable/sysfs-class-infiniband b/Documentation/ABI/stable/sysfs-class-infiniband index ebf08c604336..694f23a03a28 100644 --- a/Documentation/ABI/stable/sysfs-class-infiniband +++ b/Documentation/ABI/stable/sysfs-class-infiniband @@ -356,7 +356,7 @@ Description: pkeys/<n>: (RO) Displays the contents of the physical key table n = 0..126 - mcgs/: (RO) Muticast group table + mcgs/: (RO) Multicast group table <m>/gid_idx/0: (RO) Display the GID mapping m = 1..2 diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index 534b7a3d59fc..825e619250bf 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -84,7 +84,7 @@ What: /sys/bus/dsa/devices/dsa<m>/pasid_enabled Date: Oct 27, 2020 KernelVersion: 5.11.0 Contact: dmaengine@vger.kernel.org -Description: To indicate if PASID (process address space identifier) is +Description: To indicate if user PASID (process address space identifier) is enabled or not for this device. What: /sys/bus/dsa/devices/dsa<m>/state diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io index 60953903d007..2cdfd09123da 100644 --- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -662,3 +662,56 @@ Description: This file shows the system reset cause due to AC power failure. Value 1 in file means this is reset cause, 0 - otherwise. The file is read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_version +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_version_min +Date: August 2023 +KernelVersion: 6.6 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files show with which CPLD part numbers, version and minor + versions have been burned the 5-th CPLD device equipped on a + system. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/jtag_cap +Date: August 2023 +KernelVersion: 6.6 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: This file indicates the available method of CPLD/FPGA devices + field update through the JTAG chain: + + b00 - field update through LPC bus register memory space. + b01 - Reserved. + b10 - Reserved. + b11 - field update through CPU GPIOs bit-banging. + + The file is read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lid_open +Date: August 2023 +KernelVersion: 6.6 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: 1 - indicates that system lid is opened, otherwise 0. + + The file is read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_long_pwr_pb +Date: August 2023 +KernelVersion: 6.6 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: This file if set 1 indicates that system has been reset by + long press of power button. + + The file is read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_swb_dc_dc_pwr_fail +Date: August 2023 +KernelVersion: 6.6 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: This file shows 1 in case the system reset happened due to the + failure of any DC-DC power converter devices equipped on the + switch board. + + The file is read only. diff --git a/Documentation/ABI/stable/sysfs-platform-wmi-bmof b/Documentation/ABI/stable/sysfs-platform-wmi-bmof new file mode 100644 index 000000000000..2881244e3f09 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-platform-wmi-bmof @@ -0,0 +1,7 @@ +What: /sys/bus/wmi/devices/05901221-D566-11D1-B2F0-00A0C9062910[-X]/bmof +Date: Jun 2017 +KernelVersion: 4.13 +Description: + Binary MOF metadata used to describe the details of available ACPI WMI interfaces. + + See Documentation/wmi/devices/wmi-bmof.rst for details. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-midi2 b/Documentation/ABI/testing/configfs-usb-gadget-midi2 new file mode 100644 index 000000000000..0eac3aaba137 --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-midi2 @@ -0,0 +1,54 @@ +What: /config/usb-gadget/gadget/functions/midi2.name +Date: Jul 2023 +KernelVersion: 6.6 +Description: + The attributes: + + ============ =============================================== + process_ump Flag to process UMP Stream messages (0 or 1) + static_block Flag for static blocks (0 or 1) + iface_name MIDI interface name string + ============ =============================================== + +What: /config/usb-gadget/gadget/functions/midi2.name/ep.number +Date: Jul 2023 +KernelVersion: 6.6 +Description: + This group contains a UMP Endpoint configuration. + A new Endpoint starts from 0, and can be up to 3. + + The attributes: + + ============= =============================================== + protocol_caps MIDI protocol capabilities (1, 2 or 3 for both) + protocol Default MIDI protocol (1 or 2) + ep_name UMP Endpoint name string + product_id Product ID string + manufacturer Manufacture ID (24 bit) + family Device family ID (16 bit) + model Device model ID (16 bit) + sw_revision Software Revision (32 bit) + ============= =============================================== + +What: /config/usb-gadget/gadget/functions/midi2.name/ep.number/block.number +Date: Jul 2023 +KernelVersion: 6.6 +Description: + This group contains a UMP Function Block configuration. + A new block starts from 0, and can be up to 31. + + The attributes: + + ================= ============================================== + name Function Block name string + direction 1: input, 2: output, 3: bidirectional + first_group The first UMP Group number (0-15) + num_groups The number of groups in this FB (1-16) + 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) + 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/debugfs-dell-wmi-ddv b/Documentation/ABI/testing/debugfs-dell-wmi-ddv index fbcc5d6f7388..81cfc788be15 100644 --- a/Documentation/ABI/testing/debugfs-dell-wmi-ddv +++ b/Documentation/ABI/testing/debugfs-dell-wmi-ddv @@ -3,19 +3,32 @@ Date: September 2022 KernelVersion: 6.1 Contact: Armin Wolf <W_Armin@gmx.de> Description: - This file contains the contents of the fan sensor information buffer, - which contains fan sensor entries and a terminating character (0xFF). + This file contains the contents of the fan sensor information + buffer, which contains fan sensor entries and a terminating + character (0xFF). - Each fan sensor entry consists of three bytes with an unknown meaning, - interested people may use this file for reverse-engineering. + Each fan sensor entry contains: + + - fan type (single byte) + - fan speed in RPM (two bytes, little endian) + + See Documentation/wmi/devices/dell-wmi-ddv.rst for details. What: /sys/kernel/debug/dell-wmi-ddv-<wmi_device_name>/thermal_sensor_information Date: September 2022 KernelVersion: 6.1 Contact: Armin Wolf <W_Armin@gmx.de> Description: - This file contains the contents of the thermal sensor information buffer, - which contains thermal sensor entries and a terminating character (0xFF). + This file contains the contents of the thermal sensor information + buffer, which contains thermal sensor entries and a terminating + character (0xFF). + + Each thermal sensor entry contains: + + - thermal type (single byte) + - current temperature (single byte) + - min. temperature (single byte) + - max. temperature (single byte) + - unknown field (single byte) - Each thermal sensor entry consists of five bytes with an unknown meaning, - interested people may use this file for reverse-engineering. + See Documentation/wmi/devices/dell-wmi-ddv.rst for details. diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index 85f6d04f528b..df535780058b 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -95,7 +95,7 @@ What: /sys/kernel/debug/habanalabs/hl<n>/device_release_watchdog_timeo Date: Oct 2022 KernelVersion: 6.2 Contact: ttayar@habana.ai -Description: The watchdog timeout value in seconds for a device relese upon +Description: The watchdog timeout value in seconds for a device release upon certain error cases, after which the device is reset. What: /sys/kernel/debug/habanalabs/hl<n>/dma_size diff --git a/Documentation/ABI/testing/debugfs-driver-qat b/Documentation/ABI/testing/debugfs-driver-qat new file mode 100644 index 000000000000..6731ffacc5f0 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-driver-qat @@ -0,0 +1,61 @@ +What: /sys/kernel/debug/qat_<device>_<BDF>/qat/fw_counters +Date: November 2023 +KernelVersion: 6.6 +Contact: qat-linux@intel.com +Description: (RO) Read returns the number of requests sent to the FW and the number of responses + received from the FW for each Acceleration Engine + Reported firmware counters:: + + <N>: Number of requests sent from Acceleration Engine N to FW and responses + Acceleration Engine N received from FW + +What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/config +Date: November 2023 +KernelVersion: 6.6 +Contact: qat-linux@intel.com +Description: (RW) Read returns value of the Heartbeat update period. + Write to the file changes this period value. + + This period should reflect planned polling interval of device + health status. High frequency Heartbeat monitoring wastes CPU cycles + but minimizes the customer’s system downtime. Also, if there are + large service requests that take some time to complete, high frequency + Heartbeat monitoring could result in false reports of unresponsiveness + and in those cases, period needs to be increased. + + This parameter is effective only for c3xxx, c62x, dh895xcc devices. + 4xxx has this value internally fixed to 200ms. + + Default value is set to 500. Minimal allowed value is 200. + All values are expressed in milliseconds. + +What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/queries_failed +Date: November 2023 +KernelVersion: 6.6 +Contact: qat-linux@intel.com +Description: (RO) Read returns the number of times the device became unresponsive. + + Attribute returns value of the counter which is incremented when + status query results negative. + +What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/queries_sent +Date: November 2023 +KernelVersion: 6.6 +Contact: qat-linux@intel.com +Description: (RO) Read returns the number of times the control process checked + if the device is responsive. + + Attribute returns value of the counter which is incremented on + every status query. + +What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/status +Date: November 2023 +KernelVersion: 6.6 +Contact: qat-linux@intel.com +Description: (RO) Read returns the device health status. + + Returns 0 when device is healthy or -1 when is unresponsive + or the query failed to send. + + The driver does not monitor for Heartbeat. It is left for a user + to poll the status periodically. diff --git a/Documentation/ABI/testing/debugfs-tpmi b/Documentation/ABI/testing/debugfs-tpmi new file mode 100644 index 000000000000..597f0475fe6e --- /dev/null +++ b/Documentation/ABI/testing/debugfs-tpmi @@ -0,0 +1,31 @@ +What: /sys/kernel/debug/tpmi-<n>/pfs_dump +Date: November 2023 +KernelVersion: 6.6 +Contact: srinivas.pandruvada@linux.intel.com +Description: +The PFS (PM Feature Structure) table, shows details of each power +management feature. This includes: +tpmi_id, number of entries, entry size, offset, vsec offset, lock status +and disabled status. +Users: Debugging, any user space test suite + +What: /sys/kernel/debug/tpmi-<n>/tpmi-id-<n>/mem_dump +Date: November 2023 +KernelVersion: 6.6 +Contact: srinivas.pandruvada@linux.intel.com +Description: +Shows the memory dump of the MMIO region for a TPMI ID. +Users: Debugging, any user space test suite + +What: /sys/kernel/debug/tpmi-<n>/tpmi-id-<n>/mem_write +Date: November 2023 +KernelVersion: 6.6 +Contact: srinivas.pandruvada@linux.intel.com +Description: +Allows to write at any offset. It doesn't check for Read/Write access +as hardware will not allow to write at read-only memory. This write is +at offset multiples of 4. The format is instance,offset,contents. +Example: +echo 0,0x20,0xff > mem_write +echo 1,64,64 > mem_write +Users: Debugging, any user space test suite diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index 49db0ff288e5..c2385183826c 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -57,9 +57,9 @@ Description: stored in security.ima xattr. Requires specifying "digest_type=verity" first.) - appraise_flag:= [check_blacklist] - Currently, blacklist check is only for files signed with appended - signature. + appraise_flag:= [check_blacklist] (deprecated) + Setting the check_blacklist flag is no longer necessary. + All appraisal functions set it by default. digest_type:= verity Require fs-verity's file digest instead of the regular IMA file hash. diff --git a/Documentation/ABI/testing/procfs-diskstats b/Documentation/ABI/testing/procfs-diskstats index e58d641443d3..6a719cf2075c 100644 --- a/Documentation/ABI/testing/procfs-diskstats +++ b/Documentation/ABI/testing/procfs-diskstats @@ -8,7 +8,7 @@ Description: == =================================== 1 major number - 2 minor mumber + 2 minor number 3 device name 4 reads completed successfully 5 reads merged diff --git a/Documentation/ABI/testing/sysfs-block-device b/Documentation/ABI/testing/sysfs-block-device index 7ac7b19b2f72..2d543cfa4079 100644 --- a/Documentation/ABI/testing/sysfs-block-device +++ b/Documentation/ABI/testing/sysfs-block-device @@ -95,3 +95,25 @@ Description: This file does not exist if the HBA driver does not implement support for the SATA NCQ priority feature, regardless of the device support for this feature. + + +What: /sys/block/*/device/cdl_supported +Date: May, 2023 +KernelVersion: v6.5 +Contact: linux-scsi@vger.kernel.org +Description: + (RO) Indicates if the device supports the command duration + limits feature found in some ATA and SCSI devices. + + +What: /sys/block/*/device/cdl_enable +Date: May, 2023 +KernelVersion: v6.5 +Contact: linux-scsi@vger.kernel.org +Description: + (RW) For a device supporting the command duration limits + feature, write to the file to turn on or off the feature. + By default this feature is turned off. + Writing "1" to this file enables the use of command duration + limits for read and write commands in the kernel and turns on + the feature on the device. Writing "0" disables the feature. diff --git a/Documentation/ABI/testing/sysfs-bus-coreboot b/Documentation/ABI/testing/sysfs-bus-coreboot index 9c5accecc470..8e8d6af24a4c 100644 --- a/Documentation/ABI/testing/sysfs-bus-coreboot +++ b/Documentation/ABI/testing/sysfs-bus-coreboot @@ -21,7 +21,7 @@ What: /sys/bus/coreboot/devices/cbmem-<id>/address Date: August 2022 Contact: Jack Rosenthal <jrosenth@chromium.org> Description: - This is the pyhsical memory address that the CBMEM entry's data + This is the physical memory address that the CBMEM entry's data begins at, in hexadecimal (e.g., ``0x76ffe000``). What: /sys/bus/coreboot/devices/cbmem-<id>/size diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x index 234c33fbdb55..3acf7fc31659 100644 --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x @@ -31,7 +31,7 @@ Date: November 2014 KernelVersion: 3.19 Contact: Mathieu Poirier <mathieu.poirier@linaro.org> Description: (RW) Used in conjunction with @addr_idx. Specifies the range of - addresses to trigger on. Inclusion or exclusion is specificed + addresses to trigger on. Inclusion or exclusion is specified in the corresponding access type register. What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_single @@ -304,19 +304,19 @@ What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtsscr Date: September 2015 KernelVersion: 4.4 Contact: Mathieu Poirier <mathieu.poirier@linaro.org> -Description: (RO) Print the content of the ETM Trace Start/Stop Conrol +Description: (RO) Print the content of the ETM Trace Start/Stop Control register (0x018). The value is read directly from the HW. What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr1 Date: September 2015 KernelVersion: 4.4 Contact: Mathieu Poirier <mathieu.poirier@linaro.org> -Description: (RO) Print the content of the ETM Enable Conrol #1 +Description: (RO) Print the content of the ETM Enable Control #1 register (0x024). The value is read directly from the HW. What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr2 Date: September 2015 KernelVersion: 4.4 Contact: Mathieu Poirier <mathieu.poirier@linaro.org> -Description: (RO) Print the content of the ETM Enable Conrol #2 +Description: (RO) Print the content of the ETM Enable Control #2 register (0x01c). The value is read directly from the HW. diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x index 08b1964f27d3..a0425d70d009 100644 --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x @@ -446,7 +446,7 @@ Date: April 2015 KernelVersion: 4.01 Contact: Mathieu Poirier <mathieu.poirier@linaro.org> Description: (Read) Returns the maximum size of the data value, data address, - VMID, context ID and instuction address in the trace unit + VMID, context ID and instruction address in the trace unit (0x1E8). The value is taken directly from the HW. What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr3 diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter index 1417c4272c6c..73ac84c0bca7 100644 --- a/Documentation/ABI/testing/sysfs-bus-counter +++ b/Documentation/ABI/testing/sysfs-bus-counter @@ -22,11 +22,11 @@ Description: phase clock. What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_available -KernelVersion: 6.4 -Contact: linux-iio@vger.kernel.org +KernelVersion: 6.4 +Contact: linux-iio@vger.kernel.org Description: - Discrete set of available values for the respective device - configuration are listed in this file. + Discrete set of available values for the respective device + configuration are listed in this file. What: /sys/bus/counter/devices/counterX/countY/count KernelVersion: 5.2 @@ -90,6 +90,60 @@ Description: counter does not freeze at the boundary points, but counts continuously throughout. + interrupt on terminal count: + The output signal is initially low, and will remain low + until the counter reaches zero. The output signal then + goes high and remains high until a new preset value is + set. + + hardware retriggerable one-shot: + The output signal is initially high. The output signal + will go low by a trigger input signal, and will remain + low until the counter reaches zero. The output will then + go high and remain high until the next trigger. A + trigger results in loading the counter to the preset + value and setting the output signal low, thus starting + the one-shot pulse. + + rate generator: + The output signal is initially high. When the counter + has decremented to 1, the output signal goes low for one + clock pulse. The output signal then goes high again, the + counter is reloaded to the preset value, and the process + repeats in a periodic manner as such. + + square wave mode: + The output signal is initially high. + + If the initial count is even, the counter is decremented + by two on succeeding clock pulses. When the count + expires, the output signal changes value and the + counter is reloaded to the preset value. The process + repeats in periodic manner as such. + + If the initial count is odd, the initial count minus one + (an even number) is loaded and then is decremented by + two on succeeding clock pulses. One clock pulse after + the count expires, the output signal goes low and the + counter is reloaded to the preset value minus one. + Succeeding clock pulses decrement the count by two. When + the count expires, the output goes high again and the + counter is reloaded to the preset value minus one. The + process repeats in a periodic manner as such. + + software triggered strobe: + The output signal is initially high. When the count + expires, the output will go low for one clock pulse and + then go high again. The counting sequence is "triggered" + by setting the preset value. + + hardware triggered strobe: + The output signal is initially high. Counting is started + by a trigger input signal. When the count expires, the + output signal will go low for one clock pulse and then + go high again. A trigger results in loading the counter + to the preset value. + What: /sys/bus/counter/devices/counterX/countY/count_mode_available What: /sys/bus/counter/devices/counterX/countY/error_noise_available What: /sys/bus/counter/devices/counterX/countY/function_available diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 48ac0d911801..087f762ebfd5 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -58,6 +58,65 @@ Description: affinity for this device. +What: /sys/bus/cxl/devices/memX/security/state +Date: June, 2023 +KernelVersion: v6.5 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) Reading this file will display the CXL security state for + that device. Such states can be: 'disabled', 'sanitize', when + a sanitization is currently underway; or those available only + for persistent memory: 'locked', 'unlocked' or 'frozen'. This + sysfs entry is select/poll capable from userspace to notify + upon completion of a sanitize operation. + + +What: /sys/bus/cxl/devices/memX/security/sanitize +Date: June, 2023 +KernelVersion: v6.5 +Contact: linux-cxl@vger.kernel.org +Description: + (WO) Write a boolean 'true' string value to this attribute to + sanitize the device to securely re-purpose or decommission it. + This is done by ensuring that all user data and meta-data, + whether it resides in persistent capacity, volatile capacity, + or the LSA, is made permanently unavailable by whatever means + is appropriate for the media type. This functionality requires + the device to be disabled, that is, not actively decoding any + HPA ranges. This permits avoiding explicit global CPU cache + management, relying instead for it to be done when a region + transitions between software programmed and hardware committed + states. If this file is not present, then there is no hardware + support for the operation. + + +What /sys/bus/cxl/devices/memX/security/erase +Date: June, 2023 +KernelVersion: v6.5 +Contact: linux-cxl@vger.kernel.org +Description: + (WO) Write a boolean 'true' string value to this attribute to + secure erase user data by changing the media encryption keys for + all user data areas of the device. This functionality requires + the device to be disabled, that is, not actively decoding any + HPA ranges. This permits avoiding explicit global CPU cache + management, relying instead for it to be done when a region + transitions between software programmed and hardware committed + states. If this file is not present, then there is no hardware + support for the operation. + + +What: /sys/bus/cxl/devices/memX/firmware/ +Date: April, 2023 +KernelVersion: v6.5 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Firmware uploader mechanism. The different files under + this directory can be used to upload and activate new + firmware for CXL devices. The interfaces under this are + documented in sysfs-class-firmware. + + What: /sys/bus/cxl/devices/*/devtype Date: June, 2021 KernelVersion: v5.14 diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events index 505f080d20a1..77de58d03822 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events @@ -47,7 +47,7 @@ Description: Per-pmu performance monitoring events specific to the running syste If a <term> is specified alone (without an assigned value), it is implied that 0x1 is assigned to that <term>. - Examples (each of these lines would be in a seperate file): + Examples (each of these lines would be in a separate file): event=0x2abc event=0x423,inv,cmask=0x3 @@ -83,7 +83,7 @@ Description: Perf event scaling factors A string representing a floating point value expressed in scientific notation to be multiplied by the event count - recieved from the kernel to match the unit specified in the + received from the kernel to match the unit specified in the <event>.unit file. Example: diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci index 12e2bf92783f..40f7cd240591 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci @@ -80,3 +80,163 @@ Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> Description: read only This sysfs file exposes the cpumask which is designated to make HCALLs to retrieve hv-gpci pmu event counter data. + +What: /sys/devices/hv_gpci/interface/processor_bus_topology +Date: July 2023 +Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> +Description: admin read only + This sysfs file exposes the system topology information by making HCALL + H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value + PROCESSOR_BUS_TOPOLOGY(0xD0). + + * This sysfs file will be created only for power10 and above platforms. + + * User needs root privileges to read data from this sysfs file. + + * This sysfs file will be created, only when the HCALL returns "H_SUCCESS", + "H_AUTHORITY" or "H_PARAMETER" as the return type. + + HCALL with return error type "H_AUTHORITY" can be resolved during + runtime by setting "Enable Performance Information Collection" option. + + * The end user reading this sysfs file must decode the content as per + underlying platform/firmware. + + Possible error codes while reading this sysfs file: + + * "-EPERM" : Partition is not permitted to retrieve performance information, + required to set "Enable Performance Information Collection" option. + + * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address + or because of some hardware error. Refer to getPerfCountInfo documentation for + more information. + + * "-EFBIG" : System information exceeds PAGE_SIZE. + +What: /sys/devices/hv_gpci/interface/processor_config +Date: July 2023 +Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> +Description: admin read only + This sysfs file exposes the system topology information by making HCALL + H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value + PROCESSOR_CONFIG(0x90). + + * This sysfs file will be created only for power10 and above platforms. + + * User needs root privileges to read data from this sysfs file. + + * This sysfs file will be created, only when the HCALL returns "H_SUCCESS", + "H_AUTHORITY" or "H_PARAMETER" as the return type. + + HCALL with return error type "H_AUTHORITY" can be resolved during + runtime by setting "Enable Performance Information Collection" option. + + * The end user reading this sysfs file must decode the content as per + underlying platform/firmware. + + Possible error codes while reading this sysfs file: + + * "-EPERM" : Partition is not permitted to retrieve performance information, + required to set "Enable Performance Information Collection" option. + + * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address + or because of some hardware error. Refer to getPerfCountInfo documentation for + more information. + + * "-EFBIG" : System information exceeds PAGE_SIZE. + +What: /sys/devices/hv_gpci/interface/affinity_domain_via_virtual_processor +Date: July 2023 +Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> +Description: admin read only + This sysfs file exposes the system topology information by making HCALL + H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value + AFFINITY_DOMAIN_INFORMATION_BY_VIRTUAL_PROCESSOR(0xA0). + + * This sysfs file will be created only for power10 and above platforms. + + * User needs root privileges to read data from this sysfs file. + + * This sysfs file will be created, only when the HCALL returns "H_SUCCESS", + "H_AUTHORITY" or "H_PARAMETER" as the return type. + + HCALL with return error type "H_AUTHORITY" can be resolved during + runtime by setting "Enable Performance Information Collection" option. + + * The end user reading this sysfs file must decode the content as per + underlying platform/firmware. + + Possible error codes while reading this sysfs file: + + * "-EPERM" : Partition is not permitted to retrieve performance information, + required to set "Enable Performance Information Collection" option. + + * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address + or because of some hardware error. Refer to getPerfCountInfo documentation for + more information. + + * "-EFBIG" : System information exceeds PAGE_SIZE. + +What: /sys/devices/hv_gpci/interface/affinity_domain_via_domain +Date: July 2023 +Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> +Description: admin read only + This sysfs file exposes the system topology information by making HCALL + H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value + AFFINITY_DOMAIN_INFORMATION_BY_DOMAIN(0xB0). + + * This sysfs file will be created only for power10 and above platforms. + + * User needs root privileges to read data from this sysfs file. + + * This sysfs file will be created, only when the HCALL returns "H_SUCCESS", + "H_AUTHORITY" or "H_PARAMETER" as the return type. + + HCALL with return error type "H_AUTHORITY" can be resolved during + runtime by setting "Enable Performance Information Collection" option. + + * The end user reading this sysfs file must decode the content as per + underlying platform/firmware. + + Possible error codes while reading this sysfs file: + + * "-EPERM" : Partition is not permitted to retrieve performance information, + required to set "Enable Performance Information Collection" option. + + * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address + or because of some hardware error. Refer to getPerfCountInfo documentation for + more information. + + * "-EFBIG" : System information exceeds PAGE_SIZE. + +What: /sys/devices/hv_gpci/interface/affinity_domain_via_partition +Date: July 2023 +Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> +Description: admin read only + This sysfs file exposes the system topology information by making HCALL + H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value + AFFINITY_DOMAIN_INFORMATION_BY_PARTITION(0xB1). + + * This sysfs file will be created only for power10 and above platforms. + + * User needs root privileges to read data from this sysfs file. + + * This sysfs file will be created, only when the HCALL returns "H_SUCCESS", + "H_AUTHORITY" or "H_PARAMETER" as the return type. + + HCALL with return error type "H_AUTHORITY" can be resolved during + runtime by setting "Enable Performance Information Collection" option. + + * The end user reading this sysfs file must decode the content as per + underlying platform/firmware. + + Possible error codes while reading this sysfs file: + + * "-EPERM" : Partition is not permitted to retrieve performance information, + required to set "Enable Performance Information Collection" option. + + * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address + or because of some hardware error. Refer to getPerfCountInfo documentation for + more information. + + * "-EFBIG" : System information exceeds PAGE_SIZE. diff --git a/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo b/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo index 531fe9d6b40a..c7393b4dd2d8 100644 --- a/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo +++ b/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo @@ -5,6 +5,6 @@ Description: Indicates whether or not this SBE device has experienced a timeout; i.e. the SBE did not respond within the time allotted by the driver. A value of 1 indicates that a timeout has - ocurred and no transfers have completed since the timeout. A - value of 0 indicates that no timeout has ocurred, or if one - has, more recent transfers have completed successful. + occurred and no transfers have completed since the timeout. A + value of 0 indicates that no timeout has occurred, or if one + has, more recent transfers have completed successfully. diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480 b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480 index 42dfc9399d2d..288bc2fa9547 100644 --- a/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480 +++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480 @@ -8,7 +8,7 @@ Description: NONE no device USB USB device is attached UART UART is attached - CHARGER Charger is attaced + CHARGER Charger is attached JIG JIG is attached ======= ====================== diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 7140e8e7313f..a2854dc9a839 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -2163,3 +2163,19 @@ Contact: linux-iio@vger.kernel.org Description: An example format is 16-bytes, 2-digits-per-byte, HEX-string representing the sensor unique ID number. + +What: /sys/.../events/in_proximity_thresh_either_runningperiod +KernelVersion: 6.6 +Contact: linux-iio@vger.kernel.org +Description: + A running period of time (in seconds) for which + in_proximity_thresh_either_runningcount amount of conditions + must occur before an event is generated. If direction is not + specified then this period applies to both directions. + +What: /sys/.../events/in_proximity_thresh_either_runningcount +KernelVersion: 6.6 +Contact: linux-iio@vger.kernel.org +Description: + Number of conditions that must occur, during a running + period, before an event is generated. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 b/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 index f6c035752639..31dbb390573f 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 +++ b/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 @@ -7,6 +7,8 @@ Description: - auto -> Adjust bandpass filter to track changes in input clock rate. - manual -> disable/unregister the clock rate notifier / input clock tracking. + - bypass -> bypass low pass filter, high pass filter and disable/unregister + the clock rate notifier What: /sys/bus/iio/devices/iio:deviceX/filter_mode KernelVersion: diff --git a/Documentation/ABI/testing/sysfs-bus-nfit b/Documentation/ABI/testing/sysfs-bus-nfit index e7282d184a74..ed483a11c58c 100644 --- a/Documentation/ABI/testing/sysfs-bus-nfit +++ b/Documentation/ABI/testing/sysfs-bus-nfit @@ -121,7 +121,7 @@ KernelVersion: v4.7 Contact: nvdimm@lists.linux.dev Description: (RO) ACPI specification 6.2 section 5.2.25.9, defines an - identifier for an NVDIMM, which refelects the id attribute. + identifier for an NVDIMM, which reflects the id attribute. What: /sys/bus/nd/devices/nmemX/nfit/subsystem_vendor diff --git a/Documentation/ABI/testing/sysfs-bus-nvdimm b/Documentation/ABI/testing/sysfs-bus-nvdimm index de8c5a59c77f..64eb8f4c6a41 100644 --- a/Documentation/ABI/testing/sysfs-bus-nvdimm +++ b/Documentation/ABI/testing/sysfs-bus-nvdimm @@ -18,10 +18,12 @@ Description: (RO) Attribute group to describe the magic bits Each attribute under this group defines a bit range of the perf_event_attr.config. Supported attribute is listed below:: + event = "config:0-4" - event ID For example:: - ctl_res_cnt = "event=0x1" + + ctl_res_cnt = "event=0x1" What: /sys/bus/event_source/devices/nmemX/events Date: February 2022 diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem index 4ac0673901e7..46cfe02058fd 100644 --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem @@ -30,7 +30,7 @@ Description: Indicating that contents of the NVDIMM have been scrubbed. * "locked" - Indicating that NVDIMM contents cant + Indicating that NVDIMM contents can't be modified until next power cycle. What: /sys/bus/nd/devices/nmemX/papr/perf_stats diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index 76ab3e1fe374..221b6c75ed93 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -1,7 +1,7 @@ What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl Date: Jun 2018 KernelVersion: 4.17 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: Holds a comma separated list of device unique_ids that are allowed to be connected automatically during system startup (e.g boot devices). The list always contains @@ -33,7 +33,7 @@ Description: This attribute tells whether the system supports What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection Date: Mar 2019 KernelVersion: 4.21 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This attribute tells whether the system uses IOMMU for DMA protection. Value of 1 means IOMMU is used 0 means it is not (DMA protection is solely based on Thunderbolt @@ -42,7 +42,7 @@ Description: This attribute tells whether the system uses IOMMU What: /sys/bus/thunderbolt/devices/.../domainX/security Date: Sep 2017 KernelVersion: 4.13 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This attribute holds current Thunderbolt security level set by the system BIOS. Possible values are: @@ -64,7 +64,7 @@ Description: This attribute holds current Thunderbolt security level What: /sys/bus/thunderbolt/devices/.../authorized Date: Sep 2017 KernelVersion: 4.13 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This attribute is used to authorize Thunderbolt devices after they have been connected. If the device is not authorized, no PCIe devices are available to the system. @@ -98,7 +98,7 @@ Description: This attribute is used to authorize Thunderbolt devices What: /sys/bus/thunderbolt/devices/.../boot Date: Jun 2018 KernelVersion: 4.17 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This attribute contains 1 if Thunderbolt device was already authorized on boot and 0 otherwise. @@ -113,7 +113,7 @@ Description: This attribute contains the generation of the Thunderbolt What: /sys/bus/thunderbolt/devices/.../key Date: Sep 2017 KernelVersion: 4.13 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: When a devices supports Thunderbolt secure connect it will have this attribute. Writing 32 byte hex string changes authorization to use the secure connection method instead. @@ -123,14 +123,14 @@ Description: When a devices supports Thunderbolt secure connect it will What: /sys/bus/thunderbolt/devices/.../device Date: Sep 2017 KernelVersion: 4.13 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This attribute contains id of this device extracted from the device DROM. What: /sys/bus/thunderbolt/devices/.../device_name Date: Sep 2017 KernelVersion: 4.13 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This attribute contains name of this device extracted from the device DROM. @@ -172,21 +172,21 @@ Description: This attribute reports number of TX lanes the device is What: /sys/bus/thunderbolt/devices/.../vendor Date: Sep 2017 KernelVersion: 4.13 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This attribute contains vendor id of this device extracted from the device DROM. What: /sys/bus/thunderbolt/devices/.../vendor_name Date: Sep 2017 KernelVersion: 4.13 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This attribute contains vendor name of this device extracted from the device DROM. What: /sys/bus/thunderbolt/devices/.../unique_id Date: Sep 2017 KernelVersion: 4.13 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This attribute contains unique_id string of this device. This is either read from hardware registers (UUID on newer hardware) or based on UID from the device DROM. @@ -195,7 +195,7 @@ Description: This attribute contains unique_id string of this device. What: /sys/bus/thunderbolt/devices/.../nvm_version Date: Sep 2017 KernelVersion: 4.13 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: If the device has upgradeable firmware the version number is available here. Format: %x.%x, major.minor. If the device is in safe mode reading the file returns @@ -204,7 +204,7 @@ Description: If the device has upgradeable firmware the version What: /sys/bus/thunderbolt/devices/.../nvm_authenticate Date: Sep 2017 KernelVersion: 4.13 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: When new NVM image is written to the non-active NVM area (through non_activeX NVMem device), the authentication procedure is started by writing to @@ -246,7 +246,7 @@ Description: For supported devices, automatically authenticate the new Thunderbo What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/key Date: Jan 2018 KernelVersion: 4.15 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This contains name of the property directory the XDomain service exposes. This entry describes the protocol in question. Following directories are already reserved by @@ -261,35 +261,35 @@ Description: This contains name of the property directory the XDomain What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/modalias Date: Jan 2018 KernelVersion: 4.15 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: Stores the same MODALIAS value emitted by uevent for the XDomain service. Format: tbtsvc:kSpNvNrN What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcid Date: Jan 2018 KernelVersion: 4.15 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This contains XDomain protocol identifier the XDomain service supports. What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcvers Date: Jan 2018 KernelVersion: 4.15 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This contains XDomain protocol version the XDomain service supports. What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcrevs Date: Jan 2018 KernelVersion: 4.15 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This contains XDomain software version the XDomain service supports. What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcstns Date: Jan 2018 KernelVersion: 4.15 -Contact: thunderbolt-software@lists.01.org +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> Description: This contains XDomain service specific settings as bitmask. Format: %x diff --git a/Documentation/ABI/testing/sysfs-bus-umc b/Documentation/ABI/testing/sysfs-bus-umc deleted file mode 100644 index 948fec412446..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-umc +++ /dev/null @@ -1,28 +0,0 @@ -What: /sys/bus/umc/ -Date: July 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - The Wireless Host Controller Interface (WHCI) - specification describes a PCI-based device with - multiple capabilities; the UWB Multi-interface - Controller (UMC). - - The umc bus presents each of the individual - capabilties as a device. - -What: /sys/bus/umc/devices/.../capability_id -Date: July 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - The ID of this capability, with 0 being the radio - controller capability. - -What: /sys/bus/umc/devices/.../version -Date: July 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - The specification version this capability's hardware - interface complies with. diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index cb172db41b34..a44bfe020061 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -28,40 +28,6 @@ Description: drivers, non-authorized one are not. By default, wired USB devices are authorized. - Certified Wireless USB devices are not authorized - initially and should be (by writing 1) after the - device has been authenticated. - -What: /sys/bus/usb/device/.../wusb_cdid -Date: July 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - For Certified Wireless USB devices only. - - A devices's CDID, as 16 space-separated hex octets. - -What: /sys/bus/usb/device/.../wusb_ck -Date: July 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - For Certified Wireless USB devices only. - - Write the device's connection key (CK) to start the - authentication of the device. The CK is 16 - space-separated hex octets. - -What: /sys/bus/usb/device/.../wusb_disconnect -Date: July 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - For Certified Wireless USB devices only. - - Write a 1 to force the device to disconnect - (equivalent to unplugging a wired USB device). - What: /sys/bus/usb/drivers/.../new_id Date: October 2011 Contact: linux-usb@vger.kernel.org @@ -292,6 +258,16 @@ Description: which is marked with early_stop has failed to initialize, it will ignore all future connections until this attribute is clear. +What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/state +Date: June 2023 +Contact: Roy Luo <royluo@google.com> +Description: + Indicates current state of the USB device attached to the port. + Valid states are: 'not-attached', 'attached', 'powered', + 'reconnecting', 'unauthenticated', 'default', 'addressed', + 'configured', and 'suspended'. This file supports poll() to + monitor the state change from user space. + What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout Date: May 2013 Contact: Mathias Nyman <mathias.nyman@linux.intel.com> diff --git a/Documentation/ABI/testing/sysfs-class b/Documentation/ABI/testing/sysfs-class index 676530fcf747..906735faa1b8 100644 --- a/Documentation/ABI/testing/sysfs-class +++ b/Documentation/ABI/testing/sysfs-class @@ -1,5 +1,5 @@ What: /sys/class/ -Date: Febuary 2006 +Date: February 2006 Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Description: The /sys/class directory will consist of a group of diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl index 594fda254130..cfc48a87706b 100644 --- a/Documentation/ABI/testing/sysfs-class-cxl +++ b/Documentation/ABI/testing/sysfs-class-cxl @@ -42,7 +42,7 @@ What: /sys/class/cxl/<afu>/mmio_size Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read only - Decimal value of the size of the MMIO space that may be mmaped + Decimal value of the size of the MMIO space that may be mmapped by userspace. Users: https://github.com/ibm-capi/libcxl @@ -155,7 +155,7 @@ What: /sys/class/cxl/<afu>m/mmio_size Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read only - Decimal value of the size of the MMIO space that may be mmaped + Decimal value of the size of the MMIO space that may be mmapped by userspace. This includes all slave contexts space also. Users: https://github.com/ibm-capi/libcxl diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes index 4cdba3477176..f205d39409a3 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -22,6 +22,11 @@ Description: - integer: a range of numerical values - string + HP specific types + ----------------- + - ordered-list - a set of ordered list valid values + + All attribute types support the following values: current_value: @@ -126,6 +131,21 @@ Description: value will not be effective through sysfs until this rule is met. + HP specific class extensions + ------------------------------ + + On HP systems the following additional attributes are available: + + "ordered-list"-type specific properties: + + elements: + A file that can be read to obtain the possible + list of values of the <attr>. Values are separated using + semi-colon (``;``) and listed according to their priority. + An element listed first has the highest priority. Writing + the list in a different order to current_value alters + the priority order for the particular attribute. + What: /sys/class/firmware-attributes/*/authentication/ Date: February 2021 KernelVersion: 5.11 @@ -206,7 +226,7 @@ Description: Drivers may emit a CHANGE uevent when a password is set or unset userspace may check it again. - On Dell and Lenovo systems, if Admin password is set, then all BIOS attributes + On Dell, Lenovo and HP systems, if Admin password is set, then all BIOS attributes require password validation. On Lenovo systems if you change the Admin password the new password is not active until the next boot. @@ -243,8 +263,8 @@ Description: index: Used with HDD and NVME authentication to set the drive index - that is being referenced (e.g hdd0, hdd1 etc) - This attribute defaults to device 0. + that is being referenced (e.g hdd1, hdd2 etc) + This attribute defaults to device 1. certificate, signature, save_signature: These attributes are used for certificate based authentication. This is @@ -296,6 +316,15 @@ Description: echo "signature" > authentication/Admin/signature echo "password" > authentication/Admin/certificate_to_password + HP specific class extensions + -------------------------------- + + On HP systems the following additional settings are available: + + role: enhanced-bios-auth: + This role is specific to Secure Platform Management (SPM) attribute. + It requires configuring an endorsement (kek) and signing certificate (sk). + What: /sys/class/firmware-attributes/*/attributes/pending_reboot Date: February 2021 @@ -311,7 +340,7 @@ Description: == ========================================= 0 All BIOS attributes setting are current 1 A reboot is necessary to get pending BIOS - attribute changes applied + attribute changes applied == ========================================= Note, userspace applications need to follow below steps for efficient @@ -364,3 +393,71 @@ Description: use it to enable extra debug attributes or BIOS features for testing purposes. Note that any changes to this attribute requires a reboot for changes to take effect. + + + HP specific class extensions - Secure Platform Manager (SPM) + -------------------------------- + +What: /sys/class/firmware-attributes/*/authentication/SPM/kek +Date: March 2023 +KernelVersion: 5.18 +Contact: "Jorge Lopez" <jorge.lopez2@hp.com> +Description: + 'kek' Key-Encryption-Key is a write-only file that can be used to configure the + RSA public key that will be used by the BIOS to verify + signatures when setting the signing key. When written, + the bytes should correspond to the KEK certificate + (x509 .DER format containing an OU). The size of the + certificate must be less than or equal to 4095 bytes. + +What: /sys/class/firmware-attributes/*/authentication/SPM/sk +Date: March 2023 +KernelVersion: 5.18 +Contact: "Jorge Lopez" <jorge.lopez2@hp.com> +Description: + 'sk' Signature Key is a write-only file that can be used to configure the RSA + public key that will be used by the BIOS to verify signatures + when configuring BIOS settings and security features. When + written, the bytes should correspond to the modulus of the + public key. The exponent is assumed to be 0x10001. + +What: /sys/class/firmware-attributes/*/authentication/SPM/status +Date: March 2023 +KernelVersion: 5.18 +Contact: "Jorge Lopez" <jorge.lopez2@hp.com> +Description: + 'status' is a read-only file that returns ASCII text in JSON format reporting + the status information. + + "State": "not provisioned | provisioned | provisioning in progress", + "Version": "Major.Minor", + "Nonce": <16-bit unsigned number display in base 10>, + "FeaturesInUse": <16-bit unsigned number display in base 10>, + "EndorsementKeyMod": "<256 bytes in base64>", + "SigningKeyMod": "<256 bytes in base64>" + +What: /sys/class/firmware-attributes/*/attributes/Sure_Start/audit_log_entries +Date: March 2023 +KernelVersion: 5.18 +Contact: "Jorge Lopez" <jorge.lopez2@hp.com> +Description: + 'audit_log_entries' is a read-only file that returns the events in the log. + + Audit log entry format + + Byte 0-15: Requested Audit Log entry (Each Audit log is 16 bytes) + Byte 16-127: Unused + +What: /sys/class/firmware-attributes/*/attributes/Sure_Start/audit_log_entry_count +Date: March 2023 +KernelVersion: 5.18 +Contact: "Jorge Lopez" <jorge.lopez2@hp.com> +Description: + 'audit_log_entry_count' is a read-only file that returns the number of existing + audit log events available to be read. Values are separated using comma. (``,``) + + [No of entries],[log entry size],[Max number of entries supported] + + log entry size identifies audit log size for the current BIOS version. + The current size is 16 bytes but it can be up to 128 bytes long in future BIOS + versions. diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index 2e24ac3bd7ef..b2ff0012c0f2 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led @@ -59,6 +59,15 @@ Description: brightness. Reading this file when no hw brightness change event has happened will return an ENODATA error. +What: /sys/class/leds/<led>/color +Date: June 2023 +KernelVersion: 6.5 +Description: + Color of the LED. + + This is a read-only file. Reading this file returns the color + of the LED as a string (e.g: "red", "green", "multicolor"). + What: /sys/class/leds/<led>/trigger Date: March 2006 KernelVersion: 2.6.17 diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-aw200xx b/Documentation/ABI/testing/sysfs-class-led-driver-aw200xx new file mode 100644 index 000000000000..6d4449cf9d71 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-driver-aw200xx @@ -0,0 +1,5 @@ +What: /sys/class/leds/<led>/dim +Date: May 2023 +Description: 64-level DIM current. If you write a negative value or + "auto", the dim will be calculated according to the + brightness. diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev index 646540950e38..f6d9d72ce77b 100644 --- a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev @@ -13,6 +13,11 @@ Description: Specifies the duration of the LED blink in milliseconds. Defaults to 50 ms. + When offloaded is true, the interval value MUST be set to the + default value and cannot be changed. + Trying to set any value in this specific mode will return + an EINVAL error. + What: /sys/class/leds/<led>/link Date: Dec 2017 KernelVersion: 4.16 @@ -39,6 +44,9 @@ Description: If set to 1, the LED will blink for the milliseconds specified in interval to signal transmission. + When offloaded is true, the blink interval is controlled by + hardware and won't reflect the value set in interval. + What: /sys/class/leds/<led>/rx Date: Dec 2017 KernelVersion: 4.16 @@ -50,3 +58,84 @@ Description: If set to 1, the LED will blink for the milliseconds specified in interval to signal reception. + + When offloaded is true, the blink interval is controlled by + hardware and won't reflect the value set in interval. + +What: /sys/class/leds/<led>/offloaded +Date: Jun 2023 +KernelVersion: 6.5 +Contact: linux-leds@vger.kernel.org +Description: + Communicate whether the LED trigger modes are offloaded to + hardware or whether software fallback is used. + + If 0, the LED is using software fallback to blink. + + If 1, the LED blinking in requested mode is offloaded to + hardware. + +What: /sys/class/leds/<led>/link_10 +Date: Jun 2023 +KernelVersion: 6.5 +Contact: linux-leds@vger.kernel.org +Description: + Signal the link speed state of 10Mbps of the named network device. + + If set to 0 (default), the LED's normal state is off. + + If set to 1, the LED's normal state reflects the link state + speed of 10MBps of the named network device. + Setting this value also immediately changes the LED state. + +What: /sys/class/leds/<led>/link_100 +Date: Jun 2023 +KernelVersion: 6.5 +Contact: linux-leds@vger.kernel.org +Description: + Signal the link speed state of 100Mbps of the named network device. + + If set to 0 (default), the LED's normal state is off. + + If set to 1, the LED's normal state reflects the link state + speed of 100Mbps of the named network device. + Setting this value also immediately changes the LED state. + +What: /sys/class/leds/<led>/link_1000 +Date: Jun 2023 +KernelVersion: 6.5 +Contact: linux-leds@vger.kernel.org +Description: + Signal the link speed state of 1000Mbps of the named network device. + + If set to 0 (default), the LED's normal state is off. + + If set to 1, the LED's normal state reflects the link state + speed of 1000Mbps of the named network device. + Setting this value also immediately changes the LED state. + +What: /sys/class/leds/<led>/half_duplex +Date: Jun 2023 +KernelVersion: 6.5 +Contact: linux-leds@vger.kernel.org +Description: + Signal the link half duplex state of the named network device. + + If set to 0 (default), the LED's normal state is off. + + If set to 1, the LED's normal state reflects the link half + duplex state of the named network device. + Setting this value also immediately changes the LED state. + +What: /sys/class/leds/<led>/full_duplex +Date: Jun 2023 +KernelVersion: 6.5 +Contact: linux-leds@vger.kernel.org +Description: + Signal the link full duplex state of the named network device. + + If set to 0 (default), the LED's normal state is off. + + If set to 1, the LED's normal state reflects the link full + duplex state of the named network device. + Setting this value also immediately changes the LED state. diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd index 3bc7c0a95c92..f77fa4f6d465 100644 --- a/Documentation/ABI/testing/sysfs-class-mtd +++ b/Documentation/ABI/testing/sysfs-class-mtd @@ -39,7 +39,7 @@ KernelVersion: 2.6.29 Contact: linux-mtd@lists.infradead.org Description: Major and minor numbers of the character device corresponding - to the read-only variant of thie MTD device (in + to the read-only variant of the MTD device (in <major>:<minor> format). In this case <minor> will be odd. What: /sys/class/mtd/mtdX/erasesize diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net index 1419103d11f9..ebf21beba846 100644 --- a/Documentation/ABI/testing/sysfs-class-net +++ b/Documentation/ABI/testing/sysfs-class-net @@ -82,7 +82,7 @@ KernelVersion: 2.6.12 Contact: netdev@vger.kernel.org Description: Indicates the current physical link state of the interface. - Posssible values are: + Possible values are: == ===================== 0 physical link is down diff --git a/Documentation/ABI/testing/sysfs-class-net-qmi b/Documentation/ABI/testing/sysfs-class-net-qmi index 47e6b9732337..b028f5bc86db 100644 --- a/Documentation/ABI/testing/sysfs-class-net-qmi +++ b/Documentation/ABI/testing/sysfs-class-net-qmi @@ -62,7 +62,7 @@ Description: What: /sys/class/net/<iface>/qmi/pass_through Date: January 2021 KernelVersion: 5.12 -Contact: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> +Contact: Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com> Description: Boolean. Default: 'N' diff --git a/Documentation/ABI/testing/sysfs-class-net-queues b/Documentation/ABI/testing/sysfs-class-net-queues index 978b76358661..906ff3ca928a 100644 --- a/Documentation/ABI/testing/sysfs-class-net-queues +++ b/Documentation/ABI/testing/sysfs-class-net-queues @@ -39,7 +39,7 @@ Contact: netdev@vger.kernel.org Description: Mask of the CPU(s) currently enabled to participate into the Transmit Packet Steering packet processing flow for this - network device transmit queue. Possible vaules depend on the + network device transmit queue. Possible values depend on the number of available CPU(s) in the system. What: /sys/class/<iface>/queues/tx-<queue>/xps_rxqs diff --git a/Documentation/ABI/testing/sysfs-class-power-wilco b/Documentation/ABI/testing/sysfs-class-power-wilco index 82af180fcaab..083c4641b4c4 100644 --- a/Documentation/ABI/testing/sysfs-class-power-wilco +++ b/Documentation/ABI/testing/sysfs-class-power-wilco @@ -22,7 +22,7 @@ Description: Long Life: Customized charge rate for last longer battery life. On Wilco device this mode is pre-configured in the factory - through EC's private PID. Swiching to a different mode will + through EC's private PID. Switching to a different mode will be denied by Wilco EC when Long Life mode is enabled. What: /sys/class/power_supply/wilco-charger/charge_control_start_threshold diff --git a/Documentation/ABI/testing/sysfs-class-remoteproc b/Documentation/ABI/testing/sysfs-class-remoteproc index 0c9ee55098b8..b2b8e2db2503 100644 --- a/Documentation/ABI/testing/sysfs-class-remoteproc +++ b/Documentation/ABI/testing/sysfs-class-remoteproc @@ -81,7 +81,7 @@ Description: Remote processor coredump configuration collected userspace will directly read from the remote processor's device memory. Extra buffer will not be used to copy the dump. Also recovery process will not proceed until - all data is read by usersapce. + all data is read by userspace. What: /sys/class/remoteproc/.../recovery Date: July 2020 diff --git a/Documentation/ABI/testing/sysfs-class-thermal b/Documentation/ABI/testing/sysfs-class-thermal index 8eee37982b2a..968d89e15e8e 100644 --- a/Documentation/ABI/testing/sysfs-class-thermal +++ b/Documentation/ABI/testing/sysfs-class-thermal @@ -4,7 +4,7 @@ Description: This is given by thermal zone driver as part of registration. E.g: "acpitz" indicates it's an ACPI thermal device. In order to keep it consistent with hwmon sys attribute; this - shouldbe a short, lowercase string, not containing spaces nor + should be a short, lowercase string, not containing spaces nor dashes. RO, Required diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc b/Documentation/ABI/testing/sysfs-class-uwb_rc deleted file mode 100644 index a7ea169dc4eb..000000000000 --- a/Documentation/ABI/testing/sysfs-class-uwb_rc +++ /dev/null @@ -1,156 +0,0 @@ -What: /sys/class/uwb_rc -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - Interfaces for WiMedia Ultra Wideband Common Radio - Platform (UWB) radio controllers. - - Familiarity with the ECMA-368 'High Rate Ultra - Wideband MAC and PHY Specification' is assumed. - -What: /sys/class/uwb_rc/beacon_timeout_ms -Date: July 2008 -KernelVersion: 2.6.27 -Description: - If no beacons are received from a device for at least - this time, the device will be considered to have gone - and it will be removed. The default is 3 superframes - (~197 ms) as required by the specification. - -What: /sys/class/uwb_rc/uwb<N>/ -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - An individual UWB radio controller. - -What: /sys/class/uwb_rc/uwb<N>/beacon -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - Write: - - <channel> - - to force a specific channel to be used when beaconing, - or, if <channel> is -1, to prohibit beaconing. If - <channel> is 0, then the default channel selection - algorithm will be used. Valid channels depends on the - radio controller's supported band groups. - - Reading returns the currently active channel, or -1 if - the radio controller is not beaconing. - -What: /sys/class/uwb_rc/uwb<N>/ASIE -Date: August 2014 -KernelVersion: 3.18 -Contact: linux-usb@vger.kernel.org -Description: - - The application-specific information element (ASIE) - included in this device's beacon, in space separated - hex octets. - - Reading returns the current ASIE. Writing replaces - the current ASIE with the one written. - -What: /sys/class/uwb_rc/uwb<N>/scan -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - Write: - - <channel> <type> [<bpst offset>] - - to start (or stop) scanning on a channel. <type> is one of: - - == ======================================= - 0 scan - 1 scan outside BP - 2 scan while inactive - 3 scanning disabled - 4 scan (with start time of <bpst offset>) - == ======================================= - -What: /sys/class/uwb_rc/uwb<N>/mac_address -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - The EUI-48, in colon-separated hex octets, for this - radio controller. A write will change the radio - controller's EUI-48 but only do so while the device is - not beaconing or scanning. - -What: /sys/class/uwb_rc/uwb<N>/wusbhc -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - A symlink to the device (if any) of the WUSB Host - Controller PAL using this radio controller. - -What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/ -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - A neighbour UWB device that has either been detected - as part of a scan or is a member of the radio - controllers beacon group. - -What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/BPST -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - The time (using the radio controllers internal 1 ms - interval superframe timer) of the last beacon from - this device was received. - -What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/DevAddr -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - The current DevAddr of this device in colon separated - hex octets. - -What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/EUI_48 -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - - The EUI-48 of this device in colon separated hex - octets. - -What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/IEs -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - The latest IEs included in this device's beacon, in - space separated hex octets with one IE per line. - -What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/LQE -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - Link Quality Estimate - the Signal to Noise Ratio - (SNR) of all packets received from this device in dB. - This gives an estimate on a suitable PHY rate. Refer - to [ECMA-368] section 13.3 for more details. - -What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/RSSI -Date: July 2008 -KernelVersion: 2.6.27 -Contact: linux-usb@vger.kernel.org -Description: - Received Signal Strength Indication - the strength of - the received signal in dB. LQE is a more useful - measure of the radio link quality. diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc deleted file mode 100644 index 55eb55cac92e..000000000000 --- a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc +++ /dev/null @@ -1,57 +0,0 @@ -What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_chid -Date: July 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - Write the CHID (16 space-separated hex octets) for this host controller. - This starts the host controller, allowing it to accept connection from - WUSB devices. - - Set an all zero CHID to stop the host controller. - -What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_trust_timeout -Date: July 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - Devices that haven't sent a WUSB packet to the host - within 'wusb_trust_timeout' ms are considered to have - disconnected and are removed. The default value of - 4000 ms is the value required by the WUSB - specification. - - Since this relates to security (specifically, the - lifetime of PTKs and GTKs) it should not be changed - from the default. - -What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_phy_rate -Date: August 2009 -KernelVersion: 2.6.32 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - The maximum PHY rate to use for all connected devices. - This is only of limited use for testing and - development as the hardware's automatic rate - adaptation is better then this simple control. - - Refer to [ECMA-368] section 10.3.1.1 for the value to - use. - -What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_dnts -Date: June 2013 -KernelVersion: 3.11 -Contact: Thomas Pugliese <thomas.pugliese@gmail.com> -Description: - The device notification time slot (DNTS) count and inverval in - milliseconds that the WUSB host should use. This controls how - often the devices will have the opportunity to send - notifications to the host. - -What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_retry_count -Date: June 2013 -KernelVersion: 3.11 -Contact: Thomas Pugliese <thomas.pugliese@gmail.com> -Description: - The number of retries that the WUSB host should attempt - before reporting an error for a bus transaction. The range of - valid values is [0..15], where 0 indicates infinite retries. diff --git a/Documentation/ABI/testing/sysfs-devices-hisi_ptt b/Documentation/ABI/testing/sysfs-devices-hisi_ptt index 82de6d710266..d7e206b4901c 100644 --- a/Documentation/ABI/testing/sysfs-devices-hisi_ptt +++ b/Documentation/ABI/testing/sysfs-devices-hisi_ptt @@ -59,3 +59,55 @@ Description: (RW) Control the allocated buffer watermark of outbound packets. The available tune data is [0, 1, 2]. Writing a negative value will return an error, and out of range values will be converted to 2. The value indicates a probable level of the event. + +What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/root_port_filters +Date: May 2023 +KernelVersion: 6.5 +Contact: Yicong Yang <yangyicong@hisilicon.com> +Description: This directory contains the files providing the PCIe Root Port filters + information used for PTT trace. Each file is named after the supported + Root Port device name <domain>:<bus>:<device>.<function>. + + See the description of the "filter" in Documentation/trace/hisi-ptt.rst + for more information. + +What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/root_port_filters/multiselect +Date: May 2023 +KernelVersion: 6.5 +Contact: Yicong Yang <yangyicong@hisilicon.com> +Description: (Read) Indicates if this kind of filter can be selected at the same + time as others filters, or must be used on it's own. 1 indicates + the former case and 0 indicates the latter. + +What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/root_port_filters/<bdf> +Date: May 2023 +KernelVersion: 6.5 +Contact: Yicong Yang <yangyicong@hisilicon.com> +Description: (Read) Indicates the filter value of this Root Port filter, which + can be used to control the TLP headers to trace by the PTT trace. + +What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/requester_filters +Date: May 2023 +KernelVersion: 6.5 +Contact: Yicong Yang <yangyicong@hisilicon.com> +Description: This directory contains the files providing the PCIe Requester filters + information used for PTT trace. Each file is named after the supported + Endpoint device name <domain>:<bus>:<device>.<function>. + + See the description of the "filter" in Documentation/trace/hisi-ptt.rst + for more information. + +What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/requester_filters/multiselect +Date: May 2023 +KernelVersion: 6.5 +Contact: Yicong Yang <yangyicong@hisilicon.com> +Description: (Read) Indicates if this kind of filter can be selected at the same + time as others filters, or must be used on it's own. 1 indicates + the former case and 0 indicates the latter. + +What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/requester_filters/<bdf> +Date: May 2023 +KernelVersion: 6.5 +Contact: Yicong Yang <yangyicong@hisilicon.com> +Description: (Read) Indicates the filter value of this Requester filter, which + can be used to control the TLP headers to trace by the PTT trace. diff --git a/Documentation/ABI/testing/sysfs-devices-memory b/Documentation/ABI/testing/sysfs-devices-memory index d8b0f80b9e33..a95e0f17c35a 100644 --- a/Documentation/ABI/testing/sysfs-devices-memory +++ b/Documentation/ABI/testing/sysfs-devices-memory @@ -110,3 +110,11 @@ Description: link is created for memory section 9 on node0. /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 + +What: /sys/devices/system/memory/crash_hotplug +Date: Aug 2023 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: + (RO) indicates whether or not the kernel directly supports + modifying the crash elfcorehdr for memory hot un/plug and/or + on/offline changes. diff --git a/Documentation/ABI/testing/sysfs-devices-online b/Documentation/ABI/testing/sysfs-devices-online index f990026c0740..c3359fec2980 100644 --- a/Documentation/ABI/testing/sysfs-devices-online +++ b/Documentation/ABI/testing/sysfs-devices-online @@ -17,4 +17,4 @@ Description: After a successful execution of the bus type's .offline() callback the device cannot be used for any purpose until either it is removed (i.e. device_del() is called for it), or its bus - type's .online() is exeucted successfully. + type's .online() is executed successfully. diff --git a/Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs b/Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs new file mode 100644 index 000000000000..fdb4e36310fb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs @@ -0,0 +1,81 @@ +What: /sys/devices/platform/HISI04Bx:00/chipX/all_linked +What: /sys/devices/platform/HISI04Bx:00/chipX/linked_full_lane +What: /sys/devices/platform/HISI04Bx:00/chipX/crc_err_cnt +Date: November 2023 +KernelVersion: 6.6 +Contact: Huisong Li <lihuisong@huawei.org> +Description: + The /sys/devices/platform/HISI04Bx:00/chipX/ directory + contains read-only attributes exposing some summarization + information of all HCCS ports under a specified chip. + The X in 'chipX' indicates the Xth chip on platform. + + There are following attributes in this directory: + + ================= ==== ========================================= + all_linked: (RO) if all enabled ports on this chip are + linked (bool). + linked_full_lane: (RO) if all linked ports on this chip are full + lane (bool). + crc_err_cnt: (RO) total CRC err count for all ports on this + chip. + ================= ==== ========================================= + +What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/all_linked +What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/linked_full_lane +What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/crc_err_cnt +Date: November 2023 +KernelVersion: 6.6 +Contact: Huisong Li <lihuisong@huawei.org> +Description: + The /sys/devices/platform/HISI04Bx:00/chipX/dieY/ directory + contains read-only attributes exposing some summarization + information of all HCCS ports under a specified die. + The Y in 'dieY' indicates the hardware id of the die on chip who + has chip id X. + + There are following attributes in this directory: + + ================= ==== ========================================= + all_linked: (RO) if all enabled ports on this die are + linked (bool). + linked_full_lane: (RO) if all linked ports on this die are full + lane (bool). + crc_err_cnt: (RO) total CRC err count for all ports on this + die. + ================= ==== ========================================= + +What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/type +What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/lane_mode +What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/enable +What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/cur_lane_num +What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/link_fsm +What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/lane_mask +What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/crc_err_cnt +Date: November 2023 +KernelVersion: 6.6 +Contact: Huisong Li <lihuisong@huawei.org> +Description: + The /sys/devices/platform/HISI04Bx/chipX/dieX/hccsN/ directory + contains read-only attributes exposing information about + a HCCS port. The N value in 'hccsN' indicates this port id. + The X in 'chipX' indicates the ID of the chip to which the + HCCS port belongs. For example, X ranges from to 'n - 1' if the + chip number on platform is n. + The Y in 'dieY' indicates the hardware id of the die to which + the hccs port belongs. + Note: type, lane_mode and enable are fixed attributes on running + platform. + + The HCCS port have the following attributes: + + ============= ==== ============================================= + type: (RO) port type (string), e.g. HCCS-v1 -> H32 + lane_mode: (RO) the lane mode of this port (string), e.g. x8 + enable: (RO) indicate if this port is enabled (bool). + cur_lane_num: (RO) current lane number of this port. + link_fsm: (RO) link finite state machine of this port. + lane_mask: (RO) current lane mask of this port, every bit + indicates a lane. + crc_err_cnt: (RO) CRC err count on this port. + ============= ==== ============================================= diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index f54867cadb0f..7ecd5c8161a6 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -513,17 +513,18 @@ Description: information about CPUs heterogeneity. cpu_capacity: capacity of cpuX. What: /sys/devices/system/cpu/vulnerabilities + /sys/devices/system/cpu/vulnerabilities/gather_data_sampling + /sys/devices/system/cpu/vulnerabilities/itlb_multihit + /sys/devices/system/cpu/vulnerabilities/l1tf + /sys/devices/system/cpu/vulnerabilities/mds /sys/devices/system/cpu/vulnerabilities/meltdown + /sys/devices/system/cpu/vulnerabilities/mmio_stale_data + /sys/devices/system/cpu/vulnerabilities/retbleed + /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/spectre_v1 /sys/devices/system/cpu/vulnerabilities/spectre_v2 - /sys/devices/system/cpu/vulnerabilities/spec_store_bypass - /sys/devices/system/cpu/vulnerabilities/l1tf - /sys/devices/system/cpu/vulnerabilities/mds /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort - /sys/devices/system/cpu/vulnerabilities/itlb_multihit - /sys/devices/system/cpu/vulnerabilities/mmio_stale_data - /sys/devices/system/cpu/vulnerabilities/retbleed Date: January 2018 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> Description: Information about CPU vulnerabilities @@ -555,6 +556,7 @@ Description: Control Symmetric Multi Threading (SMT) ================ ========================================= "on" SMT is enabled "off" SMT is disabled + "<N>" SMT is enabled with N threads per core. "forceoff" SMT is force disabled. Cannot be changed. "notsupported" SMT is not supported by the CPU "notimplemented" SMT runtime toggling is not @@ -670,7 +672,7 @@ Description: Preferred MTE tag checking mode "async" Prefer asynchronous mode ================ ============================================== - See also: Documentation/arm64/memory-tagging-extension.rst + See also: Documentation/arch/arm64/memory-tagging-extension.rst What: /sys/devices/system/cpu/nohz_full Date: Apr 2015 @@ -686,3 +688,11 @@ Description: (RO) the list of CPUs that are isolated and don't participate in load balancing. These CPUs are set by boot parameter "isolcpus=". + +What: /sys/devices/system/cpu/crash_hotplug +Date: Aug 2023 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: + (RO) indicates whether or not the kernel directly supports + modifying the crash elfcorehdr for CPU hot un/plug and/or + on/offline changes. diff --git a/Documentation/ABI/testing/sysfs-driver-ccp b/Documentation/ABI/testing/sysfs-driver-ccp index 7aded9b75553..ee6b787eee7a 100644 --- a/Documentation/ABI/testing/sysfs-driver-ccp +++ b/Documentation/ABI/testing/sysfs-driver-ccp @@ -85,3 +85,21 @@ Description: Possible values: 0: Not enforced 1: Enforced + +What: /sys/bus/pci/devices/<BDF>/bootloader_version +Date: June 2023 +KernelVersion: 6.4 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices/<BDF>/bootloader_version + file reports the firmware version of the AMD AGESA + bootloader. + +What: /sys/bus/pci/devices/<BDF>/tee_version +Date: June 2023 +KernelVersion: 6.4 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices/<BDF>/tee_version + file reports the firmware version of the AMD Trusted + Execution Environment (TEE). diff --git a/Documentation/ABI/testing/sysfs-driver-chromeos-acpi b/Documentation/ABI/testing/sysfs-driver-chromeos-acpi index c308926e1568..d46b1c85840d 100644 --- a/Documentation/ABI/testing/sysfs-driver-chromeos-acpi +++ b/Documentation/ABI/testing/sysfs-driver-chromeos-acpi @@ -1,4 +1,5 @@ What: /sys/bus/platform/devices/GGL0001:*/BINF.2 + /sys/bus/platform/devices/GOOG0016:*/BINF.2 Date: May 2022 KernelVersion: 5.19 Description: @@ -10,6 +11,7 @@ Description: == =============================== What: /sys/bus/platform/devices/GGL0001:*/BINF.3 + /sys/bus/platform/devices/GOOG0016:*/BINF.3 Date: May 2022 KernelVersion: 5.19 Description: @@ -23,6 +25,7 @@ Description: == ===================================== What: /sys/bus/platform/devices/GGL0001:*/CHSW + /sys/bus/platform/devices/GOOG0016:*/CHSW Date: May 2022 KernelVersion: 5.19 Description: @@ -38,6 +41,7 @@ Description: ==== =========================================== What: /sys/bus/platform/devices/GGL0001:*/FMAP + /sys/bus/platform/devices/GOOG0016:*/FMAP Date: May 2022 KernelVersion: 5.19 Description: @@ -45,6 +49,7 @@ Description: processor firmware flashmap. What: /sys/bus/platform/devices/GGL0001:*/FRID + /sys/bus/platform/devices/GOOG0016:*/FRID Date: May 2022 KernelVersion: 5.19 Description: @@ -52,6 +57,7 @@ Description: main processor firmware. What: /sys/bus/platform/devices/GGL0001:*/FWID + /sys/bus/platform/devices/GOOG0016:*/FWID Date: May 2022 KernelVersion: 5.19 Description: @@ -59,6 +65,7 @@ Description: main processor firmware. What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.0 + /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.0 Date: May 2022 KernelVersion: 5.19 Description: @@ -73,6 +80,7 @@ Description: =========== ================================== What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.1 + /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.1 Date: May 2022 KernelVersion: 5.19 Description: @@ -84,6 +92,7 @@ Description: == ======================= What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.2 + /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.2 Date: May 2022 KernelVersion: 5.19 Description: @@ -91,18 +100,21 @@ Description: controller. What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.3 + /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.3 Date: May 2022 KernelVersion: 5.19 Description: Returns name of the GPIO controller. What: /sys/bus/platform/devices/GGL0001:*/HWID + /sys/bus/platform/devices/GOOG0016:*/HWID Date: May 2022 KernelVersion: 5.19 Description: Returns hardware ID for the Chromebook. What: /sys/bus/platform/devices/GGL0001:*/MECK + /sys/bus/platform/devices/GOOG0016:*/MECK Date: May 2022 KernelVersion: 5.19 Description: @@ -113,6 +125,7 @@ Description: present, or if the firmware was unable to read the extended registers, this buffer size can be zero. What: /sys/bus/platform/devices/GGL0001:*/VBNV.0 + /sys/bus/platform/devices/GOOG0016:*/VBNV.0 Date: May 2022 KernelVersion: 5.19 Description: @@ -122,6 +135,7 @@ Description: clock data). What: /sys/bus/platform/devices/GGL0001:*/VBNV.1 + /sys/bus/platform/devices/GOOG0016:*/VBNV.1 Date: May 2022 KernelVersion: 5.19 Description: @@ -129,9 +143,10 @@ Description: storage block. What: /sys/bus/platform/devices/GGL0001:*/VDAT + /sys/bus/platform/devices/GOOG0016:*/VDAT Date: May 2022 KernelVersion: 5.19 Description: Returns the verified boot data block shared between the firmware verification step and the kernel verification step - (binary). + (hex dump). diff --git a/Documentation/ABI/testing/sysfs-driver-eud b/Documentation/ABI/testing/sysfs-driver-eud index 83f3872182a4..2bab0db2d2f0 100644 --- a/Documentation/ABI/testing/sysfs-driver-eud +++ b/Documentation/ABI/testing/sysfs-driver-eud @@ -1,4 +1,4 @@ -What: /sys/bus/platform/drivers/eud/.../enable +What: /sys/bus/platform/drivers/qcom_eud/.../enable Date: February 2022 Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Description: diff --git a/Documentation/ABI/testing/sysfs-driver-ge-achc b/Documentation/ABI/testing/sysfs-driver-ge-achc index a9e7a079190c..c3e77def4b20 100644 --- a/Documentation/ABI/testing/sysfs-driver-ge-achc +++ b/Documentation/ABI/testing/sysfs-driver-ge-achc @@ -5,7 +5,7 @@ Description: Write 1 to this file to update the ACHC microcontroller firmware via the EzPort interface. For this the kernel will load "achc.bin" via the firmware API (so usually from /lib/firmware). The write will block until the FW - has either been flashed successfully or an error occured. + has either been flashed successfully or an error occurred. What: /sys/bus/spi/<dev>/reset Date: Jul 2021 diff --git a/Documentation/ABI/testing/sysfs-driver-qat b/Documentation/ABI/testing/sysfs-driver-qat index 087842b1969e..ef6d6c57105e 100644 --- a/Documentation/ABI/testing/sysfs-driver-qat +++ b/Documentation/ABI/testing/sysfs-driver-qat @@ -27,7 +27,18 @@ Description: (RW) Reports the current configuration of the QAT device. * sym;asym: the device is configured for running crypto services + * asym;sym: identical to sym;asym * dc: the device is configured for running compression services + * sym: the device is configured for running symmetric crypto + services + * asym: the device is configured for running asymmetric crypto + services + * asym;dc: the device is configured for running asymmetric + crypto services and compression services + * dc;asym: identical to asym;dc + * sym;dc: the device is configured for running symmetric crypto + services and compression services + * dc;sym: identical to sym;dc It is possible to set the configuration only if the device is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state) @@ -47,3 +58,38 @@ Description: (RW) Reports the current configuration of the QAT device. dc This attribute is only available for qat_4xxx devices. + +What: /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled +Date: June 2023 +KernelVersion: 6.5 +Contact: qat-linux@intel.com +Description: (RW) This configuration option provides a way to force the device into remaining in + the MAX power state. + If idle support is enabled the device will transition to the `MIN` power state when + idle, otherwise will stay in the MAX power state. + Write to the file to enable or disable idle support. + + The values are: + + * 0: idle support is disabled + * 1: idle support is enabled + + Default value is 1. + + It is possible to set the pm_idle_enabled value only if the device + is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state) + + The following example shows how to change the pm_idle_enabled of + a device:: + + # cat /sys/bus/pci/devices/<BDF>/qat/state + up + # cat /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled + 1 + # echo down > /sys/bus/pci/devices/<BDF>/qat/state + # echo 0 > /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled + # echo up > /sys/bus/pci/devices/<BDF>/qat/state + # cat /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled + 0 + + This attribute is only available for qat_4xxx devices. diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse b/Documentation/ABI/testing/sysfs-driver-tegra-fuse index 69f5af632657..b8936fad2ccf 100644 --- a/Documentation/ABI/testing/sysfs-driver-tegra-fuse +++ b/Documentation/ABI/testing/sysfs-driver-tegra-fuse @@ -3,7 +3,7 @@ Date: February 2014 Contact: Peter De Schrijver <pdeschrijver@nvidia.com> Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114 and Tegra124 SoC's from NVIDIA. The efuses contain write once - data programmed at the factory. The data is layed out in 32bit + data programmed at the factory. The data is laid out in 32bit words in LSB first format. Each bit represents a single value as decoded from the fuse registers. Bits order/assignment exactly matches the HW registers, including any unused bits. diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index 228aa43e14ed..0c7efaf62de0 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -994,7 +994,7 @@ Description: This file shows the amount of physical memory needed What: /sys/bus/platform/drivers/ufshcd/*/rpm_lvl What: /sys/bus/platform/devices/*.ufs/rpm_lvl Date: September 2014 -Contact: Subhash Jadavani <subhashj@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This entry could be used to set or show the UFS device runtime power management level. The current driver implementation supports 7 levels with next target states: @@ -1021,7 +1021,7 @@ Description: This entry could be used to set or show the UFS device What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_dev_state What: /sys/bus/platform/devices/*.ufs/rpm_target_dev_state Date: February 2018 -Contact: Subhash Jadavani <subhashj@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This entry shows the target power mode of an UFS device for the chosen runtime power management level. @@ -1030,7 +1030,7 @@ Description: This entry shows the target power mode of an UFS device What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_link_state What: /sys/bus/platform/devices/*.ufs/rpm_target_link_state Date: February 2018 -Contact: Subhash Jadavani <subhashj@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This entry shows the target state of an UFS UIC link for the chosen runtime power management level. @@ -1039,7 +1039,7 @@ Description: This entry shows the target state of an UFS UIC link What: /sys/bus/platform/drivers/ufshcd/*/spm_lvl What: /sys/bus/platform/devices/*.ufs/spm_lvl Date: September 2014 -Contact: Subhash Jadavani <subhashj@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This entry could be used to set or show the UFS device system power management level. The current driver implementation supports 7 levels with next target states: @@ -1066,7 +1066,7 @@ Description: This entry could be used to set or show the UFS device What: /sys/bus/platform/drivers/ufshcd/*/spm_target_dev_state What: /sys/bus/platform/devices/*.ufs/spm_target_dev_state Date: February 2018 -Contact: Subhash Jadavani <subhashj@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This entry shows the target power mode of an UFS device for the chosen system power management level. @@ -1075,7 +1075,7 @@ Description: This entry shows the target power mode of an UFS device What: /sys/bus/platform/drivers/ufshcd/*/spm_target_link_state What: /sys/bus/platform/devices/*.ufs/spm_target_link_state Date: February 2018 -Contact: Subhash Jadavani <subhashj@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This entry shows the target state of an UFS UIC link for the chosen system power management level. @@ -1084,7 +1084,7 @@ Description: This entry shows the target state of an UFS UIC link What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_enable What: /sys/bus/platform/devices/*.ufs/monitor/monitor_enable Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows the status of performance monitor enablement and it can be used to start/stop the monitor. When the monitor is stopped, the performance data collected is also cleared. @@ -1092,7 +1092,7 @@ Description: This file shows the status of performance monitor enablement What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_chunk_size What: /sys/bus/platform/devices/*.ufs/monitor/monitor_chunk_size Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file tells the monitor to focus on requests transferring data of specific chunk size (in Bytes). 0 means any chunk size. It can only be changed when monitor is disabled. @@ -1100,7 +1100,7 @@ Description: This file tells the monitor to focus on requests transferring What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_sectors What: /sys/bus/platform/devices/*.ufs/monitor/read_total_sectors Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows how many sectors (in 512 Bytes) have been sent from device to host after monitor gets started. @@ -1109,7 +1109,7 @@ Description: This file shows how many sectors (in 512 Bytes) have been What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_busy What: /sys/bus/platform/devices/*.ufs/monitor/read_total_busy Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows how long (in micro seconds) has been spent sending data from device to host after monitor gets started. @@ -1118,7 +1118,7 @@ Description: This file shows how long (in micro seconds) has been spent What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_nr_requests What: /sys/bus/platform/devices/*.ufs/monitor/read_nr_requests Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows how many read requests have been sent after monitor gets started. @@ -1127,7 +1127,7 @@ Description: This file shows how many read requests have been sent after What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_max What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_max Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows the maximum latency (in micro seconds) of read requests after monitor gets started. @@ -1136,7 +1136,7 @@ Description: This file shows the maximum latency (in micro seconds) of What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_min What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_min Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows the minimum latency (in micro seconds) of read requests after monitor gets started. @@ -1145,7 +1145,7 @@ Description: This file shows the minimum latency (in micro seconds) of What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_avg What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_avg Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows the average latency (in micro seconds) of read requests after monitor gets started. @@ -1154,7 +1154,7 @@ Description: This file shows the average latency (in micro seconds) of What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_sum What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_sum Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows the total latency (in micro seconds) of read requests sent after monitor gets started. @@ -1163,7 +1163,7 @@ Description: This file shows the total latency (in micro seconds) of What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_sectors What: /sys/bus/platform/devices/*.ufs/monitor/write_total_sectors Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows how many sectors (in 512 Bytes) have been sent from host to device after monitor gets started. @@ -1172,7 +1172,7 @@ Description: This file shows how many sectors (in 512 Bytes) have been sent What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_busy What: /sys/bus/platform/devices/*.ufs/monitor/write_total_busy Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows how long (in micro seconds) has been spent sending data from host to device after monitor gets started. @@ -1181,7 +1181,7 @@ Description: This file shows how long (in micro seconds) has been spent What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_nr_requests What: /sys/bus/platform/devices/*.ufs/monitor/write_nr_requests Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows how many write requests have been sent after monitor gets started. @@ -1190,7 +1190,7 @@ Description: This file shows how many write requests have been sent after What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_max What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_max Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows the maximum latency (in micro seconds) of write requests after monitor gets started. @@ -1199,7 +1199,7 @@ Description: This file shows the maximum latency (in micro seconds) of write What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_min What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_min Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows the minimum latency (in micro seconds) of write requests after monitor gets started. @@ -1208,7 +1208,7 @@ Description: This file shows the minimum latency (in micro seconds) of write What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_avg What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_avg Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows the average latency (in micro seconds) of write requests after monitor gets started. @@ -1217,7 +1217,7 @@ Description: This file shows the average latency (in micro seconds) of write What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_sum What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_sum Date: January 2021 -Contact: Can Guo <cang@codeaurora.org> +Contact: Can Guo <quic_cang@quicinc.com> Description: This file shows the total latency (in micro seconds) of write requests after monitor gets started. @@ -1226,7 +1226,7 @@ Description: This file shows the total latency (in micro seconds) of write What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_presv_us_en What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_presv_us_en Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows if preserve user-space was configured The file is read only. @@ -1234,7 +1234,7 @@ Description: This entry shows if preserve user-space was configured What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_shared_alloc_units What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_shared_alloc_units Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows the shared allocated units of WB buffer The file is read only. @@ -1242,7 +1242,7 @@ Description: This entry shows the shared allocated units of WB buffer What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_type What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_type Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows the configured WB type. 0x1 for shared buffer mode. 0x0 for dedicated buffer mode. @@ -1251,7 +1251,7 @@ Description: This entry shows the configured WB type. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_buff_cap_adj What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_buff_cap_adj Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows the total user-space decrease in shared buffer mode. The value of this parameter is 3 for TLC NAND when SLC mode @@ -1262,7 +1262,7 @@ Description: This entry shows the total user-space decrease in shared What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_alloc_units What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_max_alloc_units Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows the Maximum total WriteBooster Buffer size which is supported by the entire device. @@ -1271,7 +1271,7 @@ Description: This entry shows the Maximum total WriteBooster Buffer size What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_wb_luns What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_max_wb_luns Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows the maximum number of luns that can support WriteBooster. @@ -1280,7 +1280,7 @@ Description: This entry shows the maximum number of luns that can support What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_red_type What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_sup_red_type Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: The supportability of user space reduction mode and preserve user space mode. 00h: WriteBooster Buffer can be configured only in @@ -1295,7 +1295,7 @@ Description: The supportability of user space reduction mode What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_wb_type What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_sup_wb_type Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: The supportability of WriteBooster Buffer type. === ========================================================== @@ -1310,7 +1310,7 @@ Description: The supportability of WriteBooster Buffer type. What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_enable What: /sys/bus/platform/devices/*.ufs/flags/wb_enable Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows the status of WriteBooster. == ============================ @@ -1323,7 +1323,7 @@ Description: This entry shows the status of WriteBooster. What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_en What: /sys/bus/platform/devices/*.ufs/flags/wb_flush_en Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows if flush is enabled. == ================================= @@ -1336,7 +1336,7 @@ Description: This entry shows if flush is enabled. What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_during_h8 What: /sys/bus/platform/devices/*.ufs/flags/wb_flush_during_h8 Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: Flush WriteBooster Buffer during hibernate state. == ================================================= @@ -1351,7 +1351,7 @@ Description: Flush WriteBooster Buffer during hibernate state. What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_avail_buf What: /sys/bus/platform/devices/*.ufs/attributes/wb_avail_buf Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows the amount of unused WriteBooster buffer available. @@ -1360,7 +1360,7 @@ Description: This entry shows the amount of unused WriteBooster buffer What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_cur_buf What: /sys/bus/platform/devices/*.ufs/attributes/wb_cur_buf Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows the amount of unused current buffer. The file is read only. @@ -1368,7 +1368,7 @@ Description: This entry shows the amount of unused current buffer. What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_flush_status What: /sys/bus/platform/devices/*.ufs/attributes/wb_flush_status Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows the flush operation status. @@ -1385,7 +1385,7 @@ Description: This entry shows the flush operation status. What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_life_time_est What: /sys/bus/platform/devices/*.ufs/attributes/wb_life_time_est Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows an indication of the WriteBooster Buffer lifetime based on the amount of performed program/erase cycles @@ -1399,7 +1399,7 @@ Description: This entry shows an indication of the WriteBooster Buffer What: /sys/class/scsi_device/*/device/unit_descriptor/wb_buf_alloc_units Date: June 2020 -Contact: Asutosh Das <asutoshd@codeaurora.org> +Contact: Asutosh Das <quic_asutoshd@quicinc.com> Description: This entry shows the configured size of WriteBooster buffer. 0400h corresponds to 4GB. @@ -1426,179 +1426,16 @@ Description: This entry shows the status of WriteBooster buffer flushing If flushing is enabled, the device executes the flush operation when the command queue is empty. -What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version -What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_version -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the HPB specification version. - The full information about the descriptor can be found in the UFS - HPB (Host Performance Booster) Extension specifications. - Example: version 1.2.3 = 0123h - - The file is read only. - -What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_control -What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_control -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows an indication of the HPB control mode. - 00h: Host control mode - 01h: Device control mode - - The file is read only. - -What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_region_size -What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_region_size -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the bHPBRegionSize which can be calculated - as in the following (in bytes): - HPB Region size = 512B * 2^bHPBRegionSize - - The file is read only. - -What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu -What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_number_lu -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the maximum number of HPB LU supported by - the device. - 00h: HPB is not supported by the device. - 01h ~ 20h: Maximum number of HPB LU supported by the device - - The file is read only. - -What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_subregion_size -What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_subregion_size -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the bHPBSubRegionSize, which can be - calculated as in the following (in bytes) and shall be a multiple of - logical block size: - HPB Sub-Region size = 512B x 2^bHPBSubRegionSize - bHPBSubRegionSize shall not exceed bHPBRegionSize. - - The file is read only. - -What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_max_active_regions -What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_max_active_regions -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the maximum number of active HPB regions that - is supported by the device. - - The file is read only. - -What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_lu_max_active_regions -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the maximum number of HPB regions assigned to - the HPB logical unit. - - The file is read only. - -What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_pinned_region_start_offset -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the start offset of HPB pinned region. - - The file is read only. - -What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_number_pinned_regions -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the number of HPB pinned regions assigned to - the HPB logical unit. - - The file is read only. - -What: /sys/class/scsi_device/*/device/hpb_stats/hit_cnt -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the number of reads that changed to HPB read. - - The file is read only. - -What: /sys/class/scsi_device/*/device/hpb_stats/miss_cnt -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the number of reads that cannot be changed to - HPB read. - - The file is read only. - -What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_noti_cnt -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the number of response UPIUs that has - recommendations for activating sub-regions and/or inactivating region. - - The file is read only. - -What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_active_cnt -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: For the HPB device control mode, this entry shows the number of - active sub-regions recommended by response UPIUs. For the HPB host control - mode, this entry shows the number of active sub-regions recommended by the - HPB host control mode heuristic algorithm. - - The file is read only. - -What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_inactive_cnt -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: For the HPB device control mode, this entry shows the number of - inactive regions recommended by response UPIUs. For the HPB host control - mode, this entry shows the number of inactive regions recommended by the - HPB host control mode heuristic algorithm. - - The file is read only. - -What: /sys/class/scsi_device/*/device/hpb_stats/map_req_cnt -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the number of read buffer commands for - activating sub-regions recommended by response UPIUs. - - The file is read only. - -What: /sys/class/scsi_device/*/device/hpb_params/requeue_timeout_ms -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the requeue timeout threshold for write buffer - command in ms. The value can be changed by writing an integer to - this entry. - -What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_size_hpb_single_cmd -What: /sys/bus/platform/devices/*.ufs/attributes/max_data_size_hpb_single_cmd -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the maximum HPB data size for using a single HPB - command. - - === ======== - 00h 4KB - 01h 8KB - 02h 12KB - ... - FFh 1024KB - === ======== - - The file is read only. - -What: /sys/bus/platform/drivers/ufshcd/*/flags/hpb_enable -What: /sys/bus/platform/devices/*.ufs/flags/hpb_enable -Date: June 2021 -Contact: Daejun Park <daejun7.park@samsung.com> -Description: This entry shows the status of HPB. - - == ============================ - 0 HPB is not enabled. - 1 HPB is enabled - == ============================ - - The file is read only. +What: /sys/bus/platform/drivers/ufshcd/*/wb_flush_threshold +What: /sys/bus/platform/devices/*.ufs/wb_flush_threshold +Date: June 2023 +Contact: Lu Hongfei <luhongfei@vivo.com> +Description: + wb_flush_threshold represents the threshold for flushing WriteBooster buffer, + whose value expressed in unit of 10% granularity, such as '1' representing 10%, + '2' representing 20%, and so on. + If avail_wb_buff < wb_flush_threshold, it indicates that WriteBooster buffer needs to + be flushed, otherwise it is not necessary. Contact: Daniil Lunev <dlunev@chromium.org> What: /sys/bus/platform/drivers/ufshcd/*/capabilities/ @@ -1637,76 +1474,3 @@ Description: Indicates status of Write Booster. The file is read only. -What: /sys/class/scsi_device/*/device/hpb_param_sysfs/activation_thld -Date: February 2021 -Contact: Avri Altman <avri.altman@wdc.com> -Description: In host control mode, reads are the major source of activation - trials. Once this threshold hs met, the region is added to the - "to-be-activated" list. Since we reset the read counter upon - write, this include sending a rb command updating the region - ppn as well. - -What: /sys/class/scsi_device/*/device/hpb_param_sysfs/normalization_factor -Date: February 2021 -Contact: Avri Altman <avri.altman@wdc.com> -Description: In host control mode, we think of the regions as "buckets". - Those buckets are being filled with reads, and emptied on write. - We use entries_per_srgn - the amount of blocks in a subregion as - our bucket size. This applies because HPB1.0 only handles - single-block reads. Once the bucket size is crossed, we trigger - a normalization work - not only to avoid overflow, but mainly - because we want to keep those counters normalized, as we are - using those reads as a comparative score, to make various decisions. - The normalization is dividing (shift right) the read counter by - the normalization_factor. If during consecutive normalizations - an active region has exhausted its reads - inactivate it. - -What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_enter -Date: February 2021 -Contact: Avri Altman <avri.altman@wdc.com> -Description: Region deactivation is often due to the fact that eviction took - place: A region becomes active at the expense of another. This is - happening when the max-active-regions limit has been crossed. - In host mode, eviction is considered an extreme measure. We - want to verify that the entering region has enough reads, and - the exiting region has much fewer reads. eviction_thld_enter is - the min reads that a region must have in order to be considered - a candidate for evicting another region. - -What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_exit -Date: February 2021 -Contact: Avri Altman <avri.altman@wdc.com> -Description: Same as above for the exiting region. A region is considered to - be a candidate for eviction only if it has fewer reads than - eviction_thld_exit. - -What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_ms -Date: February 2021 -Contact: Avri Altman <avri.altman@wdc.com> -Description: In order not to hang on to "cold" regions, we inactivate - a region that has no READ access for a predefined amount of - time - read_timeout_ms. If read_timeout_ms has expired, and the - region is dirty, it is less likely that we can make any use of - HPB reading it so we inactivate it. Still, deactivation has - its overhead, and we may still benefit from HPB reading this - region if it is clean - see read_timeout_expiries. - -What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_expiries -Date: February 2021 -Contact: Avri Altman <avri.altman@wdc.com> -Description: If the region read timeout has expired, but the region is clean, - just re-wind its timer for another spin. Do that as long as it - is clean and did not exhaust its read_timeout_expiries threshold. - -What: /sys/class/scsi_device/*/device/hpb_param_sysfs/timeout_polling_interval_ms -Date: February 2021 -Contact: Avri Altman <avri.altman@wdc.com> -Description: The frequency with which the delayed worker that checks the - read_timeouts is awakened. - -What: /sys/class/scsi_device/*/device/hpb_param_sysfs/inflight_map_req -Date: February 2021 -Contact: Avri Altman <avri.altman@wdc.com> -Description: In host control mode the host is the originator of map requests. - To avoid flooding the device with map requests, use a simple throttling - mechanism that limits the number of inflight map requests. diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi index 819939d858c9..5249ad5a96d9 100644 --- a/Documentation/ABI/testing/sysfs-firmware-acpi +++ b/Documentation/ABI/testing/sysfs-firmware-acpi @@ -84,7 +84,7 @@ Description: hotplug events associated with the given class of devices and will allow those devices to be ejected with the help of the _EJ0 control method. Unsetting it - effectively disables hotplug for the correspoinding + effectively disables hotplug for the corresponding class of devices. ======== ======================================================= diff --git a/Documentation/ABI/testing/sysfs-firmware-sgi_uv b/Documentation/ABI/testing/sysfs-firmware-sgi_uv index 12ed843e1d3e..7fe9244b87bb 100644 --- a/Documentation/ABI/testing/sysfs-firmware-sgi_uv +++ b/Documentation/ABI/testing/sysfs-firmware-sgi_uv @@ -102,12 +102,12 @@ Description: conn_port The conn_hub entry contains a value representing the unique - oridinal value of the hub on the other end of the fabric + ordinal value of the hub on the other end of the fabric cable plugged into the port. If the port is disconnected, the value returned will be -1. The conn_port entry contains a value representing the unique - oridinal value of the port on the other end of the fabric cable + ordinal value of the port on the other end of the fabric cable plugged into the port. If the port is disconnected, the value returned will be -1. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 8140fc98f5ae..36c3cb547901 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -54,9 +54,9 @@ Description: Controls the in-place-update policy. 0x00 DISABLE disable IPU(=default option in LFS mode) 0x01 FORCE all the time 0x02 SSR if SSR mode is activated - 0x04 UTIL if FS utilization is over threashold + 0x04 UTIL if FS utilization is over threshold 0x08 SSR_UTIL if SSR mode is activated and FS utilization is over - threashold + threshold 0x10 FSYNC activated in fsync path only for high performance flash storages. IPU will be triggered only if the # of dirty pages over min_fsync_blocks. @@ -102,9 +102,9 @@ What: /sys/fs/f2fs/<disk>/max_small_discards Date: November 2013 Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> Description: Controls the issue rate of discard commands that consist of small - blocks less than 2MB. The candidates to be discarded are cached until - checkpoint is triggered, and issued during the checkpoint. - By default, it is disabled with 0. + blocks less than 2MB. The candidates to be discarded are cached during + checkpoint, and issued by issue_discard thread after checkpoint. + It is enabled by default. What: /sys/fs/f2fs/<disk>/max_ordered_discard Date: October 2022 @@ -117,7 +117,7 @@ Date: December 2021 Contact: "Konstantin Vyshetsky" <vkon@google.com> Description: Controls the number of discards a thread will issue at a time. Higher number will allow the discard thread to finish its work - faster, at the cost of higher latency for incomming I/O. + faster, at the cost of higher latency for incoming I/O. What: /sys/fs/f2fs/<disk>/min_discard_issue_time Date: December 2021 @@ -334,7 +334,7 @@ Description: This indicates how many GC can be failed for the pinned state. 2048 trials is set by default. What: /sys/fs/f2fs/<disk>/extension_list -Date: Feburary 2018 +Date: February 2018 Contact: "Chao Yu" <yuchao0@huawei.com> Description: Used to control configure extension list: - Query: cat /sys/fs/f2fs/<disk>/extension_list diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon index 2744f21b5a6b..420b30f09cf0 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-damon +++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon @@ -29,8 +29,10 @@ Description: Writing 'on' or 'off' to this file makes the kdamond starts or file updates contents of schemes stats files of the kdamond. Writing 'update_schemes_tried_regions' to the file updates contents of 'tried_regions' directory of every scheme directory - of this kdamond. Writing 'clear_schemes_tried_regions' to the - file removes contents of the 'tried_regions' directory. + of this kdamond. Writing 'update_schemes_tried_bytes' to the + file updates only '.../tried_regions/total_bytes' files of this + kdamond. Writing 'clear_schemes_tried_regions' to the file + removes contents of the 'tried_regions' directory. What: /sys/kernel/mm/damon/admin/kdamonds/<K>/pid Date: Mar 2022 @@ -152,7 +154,7 @@ Description: Writing to and reading from this file sets and gets the action What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/min Date: Mar 2022 Contact: SeongJae Park <sj@kernel.org> -Description: Writing to and reading from this file sets and gets the mimimum +Description: Writing to and reading from this file sets and gets the minimum size of the scheme's target regions in bytes. What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/max @@ -269,8 +271,10 @@ What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/ Date: Dec 2022 Contact: SeongJae Park <sj@kernel.org> Description: Writing to and reading from this file sets and gets the type of - the memory of the interest. 'anon' for anonymous pages, or - 'memcg' for specific memory cgroup can be written and read. + the memory of the interest. 'anon' for anonymous pages, + 'memcg' for specific memory cgroup, 'addr' for address range + (an open-ended interval), or 'target' for DAMON monitoring + target can be written and read. What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/memcg_path Date: Dec 2022 @@ -279,6 +283,27 @@ Description: If 'memcg' is written to the 'type' file, writing to and reading from this file sets and gets the path to the memory cgroup of the interest. +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/addr_start +Date: Jul 2023 +Contact: SeongJae Park <sj@kernel.org> +Description: If 'addr' is written to the 'type' file, writing to or reading + from this file sets or gets the start address of the address + range for the filter. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/addr_end +Date: Jul 2023 +Contact: SeongJae Park <sj@kernel.org> +Description: If 'addr' is written to the 'type' file, writing to or reading + from this file sets or gets the end address of the address + range for the filter. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/target_idx +Date: Dec 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: If 'target' is written to the 'type' file, writing to or + reading from this file sets or gets the index of the DAMON + monitoring target of the interest. + What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/matching Date: Dec 2022 Contact: SeongJae Park <sj@kernel.org> @@ -317,6 +342,13 @@ Contact: SeongJae Park <sj@kernel.org> Description: Reading this file returns the number of the exceed events of the scheme's quotas. +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/total_bytes +Date: Jul 2023 +Contact: SeongJae Park <sj@kernel.org> +Description: Reading this file returns the total amount of memory 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>/start Date: Oct 2022 Contact: SeongJae Park <sj@kernel.org> diff --git a/Documentation/ABI/testing/sysfs-memory-page-offline b/Documentation/ABI/testing/sysfs-memory-page-offline index e14703f12fdf..00f4e35f916f 100644 --- a/Documentation/ABI/testing/sysfs-memory-page-offline +++ b/Documentation/ABI/testing/sysfs-memory-page-offline @@ -10,7 +10,7 @@ Description: dropping it if possible. The kernel will then be placed on the bad page list and never be reused. - The offlining is done in kernel specific granuality. + The offlining is done in kernel specific granularity. Normally it's the base page size of the kernel, but this might change. @@ -35,7 +35,7 @@ Description: to access this page assuming it's poisoned by the hardware. - The offlining is done in kernel specific granuality. + The offlining is done in kernel specific granularity. Normally it's the base page size of the kernel, but this might change. diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module index 08886367d047..62addab47d0c 100644 --- a/Documentation/ABI/testing/sysfs-module +++ b/Documentation/ABI/testing/sysfs-module @@ -60,3 +60,14 @@ Description: Module taint flags: C staging driver module E unsigned module == ===================== + +What: /sys/module/grant_table/parameters/free_per_iteration +Date: July 2023 +KernelVersion: 6.5 but backported to all supported stable branches +Contact: Xen developer discussion <xen-devel@lists.xenproject.org> +Description: Read and write number of grant entries to attempt to free per iteration. + + Note: Future versions of Xen and Linux may provide a better + interface for controlling the rate of deferred grant reclaim + or may not need it at all. +Users: Qubes OS (https://www.qubes-os.org) diff --git a/Documentation/ABI/testing/sysfs-ocfs2 b/Documentation/ABI/testing/sysfs-ocfs2 index b7cc516a8a8a..494d7c1ac710 100644 --- a/Documentation/ABI/testing/sysfs-ocfs2 +++ b/Documentation/ABI/testing/sysfs-ocfs2 @@ -1,13 +1,13 @@ What: /sys/fs/ocfs2/ Date: April 2008 -Contact: ocfs2-devel@oss.oracle.com +Contact: ocfs2-devel@lists.linux.dev Description: The /sys/fs/ocfs2 directory contains knobs used by the ocfs2-tools to interact with the filesystem. What: /sys/fs/ocfs2/max_locking_protocol Date: April 2008 -Contact: ocfs2-devel@oss.oracle.com +Contact: ocfs2-devel@lists.linux.dev Description: The /sys/fs/ocfs2/max_locking_protocol file displays version of ocfs2 locking supported by the filesystem. This version @@ -28,7 +28,7 @@ Description: What: /sys/fs/ocfs2/loaded_cluster_plugins Date: April 2008 -Contact: ocfs2-devel@oss.oracle.com +Contact: ocfs2-devel@lists.linux.dev Description: The /sys/fs/ocfs2/loaded_cluster_plugins file describes the available plugins to support ocfs2 cluster operation. @@ -48,7 +48,7 @@ Description: What: /sys/fs/ocfs2/active_cluster_plugin Date: April 2008 -Contact: ocfs2-devel@oss.oracle.com +Contact: ocfs2-devel@lists.linux.dev Description: The /sys/fs/ocfs2/active_cluster_plugin displays which cluster plugin is currently in use by the filesystem. @@ -65,7 +65,7 @@ Description: What: /sys/fs/ocfs2/cluster_stack Date: April 2008 -Contact: ocfs2-devel@oss.oracle.com +Contact: ocfs2-devel@lists.linux.dev Description: The /sys/fs/ocfs2/cluster_stack file contains the name of current ocfs2 cluster stack. This value is set by @@ -86,4 +86,4 @@ Description: stack return an error. Users: - ocfs2-tools <ocfs2-tools-devel@oss.oracle.com> + ocfs2-tools <ocfs2-tools-devel@lists.linux.dev> diff --git a/Documentation/ABI/testing/sysfs-platform-asus-wmi b/Documentation/ABI/testing/sysfs-platform-asus-wmi index a77a004a1baa..8a7e25bde085 100644 --- a/Documentation/ABI/testing/sysfs-platform-asus-wmi +++ b/Documentation/ABI/testing/sysfs-platform-asus-wmi @@ -98,3 +98,91 @@ Description: Enable an LCD response-time boost to reduce or remove ghosting: * 0 - Disable, * 1 - Enable + +What: /sys/devices/platform/<platform>/charge_mode +Date: Jun 2023 +KernelVersion: 6.5 +Contact: "Luke Jones" <luke@ljones.dev> +Description: + Get the current charging mode being used: + * 1 - Barrel connected charger, + * 2 - USB-C charging + * 3 - Both connected, barrel used for charging + +What: /sys/devices/platform/<platform>/egpu_connected +Date: Jun 2023 +KernelVersion: 6.5 +Contact: "Luke Jones" <luke@ljones.dev> +Description: + Show if the egpu (XG Mobile) is correctly connected: + * 0 - False, + * 1 - True + +What: /sys/devices/platform/<platform>/mini_led_mode +Date: Jun 2023 +KernelVersion: 6.5 +Contact: "Luke Jones" <luke@ljones.dev> +Description: + Change the mini-LED mode: + * 0 - Single-zone, + * 1 - Multi-zone + +What: /sys/devices/platform/<platform>/ppt_pl1_spl +Date: Jun 2023 +KernelVersion: 6.5 +Contact: "Luke Jones" <luke@ljones.dev> +Description: + Set the Package Power Target total of CPU: PL1 on Intel, SPL on AMD. + Shown on Intel+Nvidia or AMD+Nvidia based systems: + + * min=5, max=250 + +What: /sys/devices/platform/<platform>/ppt_pl2_sppt +Date: Jun 2023 +KernelVersion: 6.5 +Contact: "Luke Jones" <luke@ljones.dev> +Description: + Set the Slow Package Power Tracking Limit of CPU: PL2 on Intel, SPPT, + on AMD. Shown on Intel+Nvidia or AMD+Nvidia based systems: + + * min=5, max=250 + +What: /sys/devices/platform/<platform>/ppt_fppt +Date: Jun 2023 +KernelVersion: 6.5 +Contact: "Luke Jones" <luke@ljones.dev> +Description: + Set the Fast Package Power Tracking Limit of CPU. AMD+Nvidia only: + * min=5, max=250 + +What: /sys/devices/platform/<platform>/ppt_apu_sppt +Date: Jun 2023 +KernelVersion: 6.5 +Contact: "Luke Jones" <luke@ljones.dev> +Description: + Set the APU SPPT limit. Shown on full AMD systems only: + * min=5, max=130 + +What: /sys/devices/platform/<platform>/ppt_platform_sppt +Date: Jun 2023 +KernelVersion: 6.5 +Contact: "Luke Jones" <luke@ljones.dev> +Description: + Set the platform SPPT limit. Shown on full AMD systems only: + * min=5, max=130 + +What: /sys/devices/platform/<platform>/nv_dynamic_boost +Date: Jun 2023 +KernelVersion: 6.5 +Contact: "Luke Jones" <luke@ljones.dev> +Description: + Set the dynamic boost limit of the Nvidia dGPU: + * min=5, max=25 + +What: /sys/devices/platform/<platform>/nv_temp_target +Date: Jun 2023 +KernelVersion: 6.5 +Contact: "Luke Jones" <luke@ljones.dev> +Description: + Set the target temperature limit of the Nvidia dGPU: + * min=75, max=87 diff --git a/Documentation/ABI/testing/sysfs-platform-dell-laptop b/Documentation/ABI/testing/sysfs-platform-dell-laptop index 82bcfe9df66e..701529653283 100644 --- a/Documentation/ABI/testing/sysfs-platform-dell-laptop +++ b/Documentation/ABI/testing/sysfs-platform-dell-laptop @@ -15,7 +15,7 @@ KernelVersion: 3.19 Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>, Pali Rohár <pali@kernel.org> Description: - This file allows to specifiy the on/off threshold value, + This file allows to specify the on/off threshold value, as reported by the ambient light sensor. What: /sys/class/leds/dell::kbd_backlight/start_triggers diff --git a/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv b/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv index 1d97ad615c66..a9d39d9e8865 100644 --- a/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv +++ b/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv @@ -3,5 +3,7 @@ Date: September 2022 KernelVersion: 6.1 Contact: Armin Wolf <W_Armin@gmx.de> Description: - Reports the Dell ePPID (electronic Dell Piece Part Identification) + Reports the Dell ePPID (electronic Piece Part Identification) of the ACPI battery. + + See Documentation/wmi/devices/dell-wmi-ddv.rst for details. diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme index d6ab34e81b9b..2d5b78d2cf51 100644 --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme @@ -90,7 +90,7 @@ KernelVersion: 5.4 Contact: Wu Hao <hao.wu@intel.com> Description: Read-Write. Read this file to get errors detected on FME. Write this file to clear errors logged in fme_errors. Write - fials with -EINVAL if input parsing fails or input error code + fails with -EINVAL if input parsing fails or input error code doesn't match. What: /sys/bus/platform/devices/dfl-fme.0/errors/first_error diff --git a/Documentation/ABI/testing/sysfs-platform-hidma b/Documentation/ABI/testing/sysfs-platform-hidma index fca40a54df59..a80aeda85ef6 100644 --- a/Documentation/ABI/testing/sysfs-platform-hidma +++ b/Documentation/ABI/testing/sysfs-platform-hidma @@ -2,7 +2,7 @@ What: /sys/devices/platform/hidma-*/chid /sys/devices/platform/QCOM8061:*/chid Date: Dec 2015 KernelVersion: 4.4 -Contact: "Sinan Kaya <okaya@codeaurora.org>" +Contact: "Sinan Kaya <okaya@kernel.org>" Description: Contains the ID of the channel within the HIDMA instance. It is used to associate a given HIDMA channel with the diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt index 3b6c5c9eabdc..0373745b4e18 100644 --- a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt +++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt @@ -2,7 +2,7 @@ What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority /sys/devices/platform/QCOM8060:*/chanops/chan*/priority Date: Nov 2015 KernelVersion: 4.4 -Contact: "Sinan Kaya <okaya@codeaurora.org>" +Contact: "Sinan Kaya <okaya@kernel.org>" Description: Contains either 0 or 1 and indicates if the DMA channel is a low priority (0) or high priority (1) channel. @@ -11,7 +11,7 @@ What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/weight /sys/devices/platform/QCOM8060:*/chanops/chan*/weight Date: Nov 2015 KernelVersion: 4.4 -Contact: "Sinan Kaya <okaya@codeaurora.org>" +Contact: "Sinan Kaya <okaya@kernel.org>" Description: Contains 0..15 and indicates the weight of the channel among equal priority channels during round robin scheduling. @@ -20,7 +20,7 @@ What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles Date: Nov 2015 KernelVersion: 4.4 -Contact: "Sinan Kaya <okaya@codeaurora.org>" +Contact: "Sinan Kaya <okaya@kernel.org>" Description: Contains the platform specific cycle value to wait after a reset command is issued. If the value is chosen too short, @@ -32,7 +32,7 @@ What: /sys/devices/platform/hidma-mgmt*/dma_channels /sys/devices/platform/QCOM8060:*/dma_channels Date: Nov 2015 KernelVersion: 4.4 -Contact: "Sinan Kaya <okaya@codeaurora.org>" +Contact: "Sinan Kaya <okaya@kernel.org>" Description: Contains the number of dma channels supported by one instance of HIDMA hardware. The value may change from chip to chip. @@ -41,7 +41,7 @@ What: /sys/devices/platform/hidma-mgmt*/hw_version_major /sys/devices/platform/QCOM8060:*/hw_version_major Date: Nov 2015 KernelVersion: 4.4 -Contact: "Sinan Kaya <okaya@codeaurora.org>" +Contact: "Sinan Kaya <okaya@kernel.org>" Description: Version number major for the hardware. @@ -49,7 +49,7 @@ What: /sys/devices/platform/hidma-mgmt*/hw_version_minor /sys/devices/platform/QCOM8060:*/hw_version_minor Date: Nov 2015 KernelVersion: 4.4 -Contact: "Sinan Kaya <okaya@codeaurora.org>" +Contact: "Sinan Kaya <okaya@kernel.org>" Description: Version number minor for the hardware. @@ -57,7 +57,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions /sys/devices/platform/QCOM8060:*/max_rd_xactions Date: Nov 2015 KernelVersion: 4.4 -Contact: "Sinan Kaya <okaya@codeaurora.org>" +Contact: "Sinan Kaya <okaya@kernel.org>" Description: Contains a value between 0 and 31. Maximum number of read transactions that can be issued back to back. @@ -69,7 +69,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_read_request /sys/devices/platform/QCOM8060:*/max_read_request Date: Nov 2015 KernelVersion: 4.4 -Contact: "Sinan Kaya <okaya@codeaurora.org>" +Contact: "Sinan Kaya <okaya@kernel.org>" Description: Size of each read request. The value needs to be a power of two and can be between 128 and 1024. @@ -78,7 +78,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_wr_xactions /sys/devices/platform/QCOM8060:*/max_wr_xactions Date: Nov 2015 KernelVersion: 4.4 -Contact: "Sinan Kaya <okaya@codeaurora.org>" +Contact: "Sinan Kaya <okaya@kernel.org>" Description: Contains a value between 0 and 31. Maximum number of write transactions that can be issued back to back. @@ -91,7 +91,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_write_request /sys/devices/platform/QCOM8060:*/max_write_request Date: Nov 2015 KernelVersion: 4.4 -Contact: "Sinan Kaya <okaya@codeaurora.org>" +Contact: "Sinan Kaya <okaya@kernel.org>" Description: Size of each write request. The value needs to be a power of two and can be between 128 and 1024. diff --git a/Documentation/ABI/testing/sysfs-platform-kim b/Documentation/ABI/testing/sysfs-platform-kim index 6a52d6d2b601..0a38caa62a32 100644 --- a/Documentation/ABI/testing/sysfs-platform-kim +++ b/Documentation/ABI/testing/sysfs-platform-kim @@ -9,7 +9,7 @@ Description: The device name flows down to architecture specific board initialization file from the ATAGS bootloader firmware. The name exposed is read from the user-space - dameon and opens the device when install is requested. + daemon and opens the device when install is requested. What: /sys/devices/platform/kim/baud_rate Date: January 2010 diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl index 9b99a81babb1..65ed3865da62 100644 --- a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl +++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl @@ -75,3 +75,78 @@ KernelVersion: 6.4 Contact: "Liming Sun <limings@nvidia.com>" Description: The file used to access the BlueField boot fifo. + +What: /sys/bus/platform/devices/MLNXBF04:00/rsh_log +Date: May 2023 +KernelVersion: 6.4 +Contact: "Liming Sun <limings@nvidia.com>" +Description: + The file used to write BlueField boot log with the format + "[INFO|WARN|ERR|ASSERT ]<msg>". Log level 'INFO' is used by + default if not specified. + +What: /sys/bus/platform/devices/MLNXBF04:00/oob_mac +Date: August 2023 +KernelVersion: 6.5 +Contact: "David Thompson <davthompson@nvidia.com>" +Description: + The "oob_mac" sysfs attribute holds the MAC address for + the out-of-band 1Gbps Ethernet port. This MAC address is + provided on a board-level label. + +What: /sys/bus/platform/devices/MLNXBF04:00/opn +Date: August 2023 +KernelVersion: 6.5 +Contact: "David Thompson <davthompson@nvidia.com>" +Description: + The "opn" sysfs attribute holds the board's part number. + This value is provided on a board-level label. + +What: /sys/bus/platform/devices/MLNXBF04:00/sku +Date: August 2023 +KernelVersion: 6.5 +Contact: "David Thompson <davthompson@nvidia.com>" +Description: + The "sku" sysfs attribute holds the board's SKU number. + This value is provided on a board-level label. + +What: /sys/bus/platform/devices/MLNXBF04:00/modl +Date: August 2023 +KernelVersion: 6.5 +Contact: "David Thompson <davthompson@nvidia.com>" +Description: + The "modl" sysfs attribute holds the board's model number. + This value is provided on a board-level label. + +What: /sys/bus/platform/devices/MLNXBF04:00/sn +Date: August 2023 +KernelVersion: 6.5 +Contact: "David Thompson <davthompson@nvidia.com>" +Description: + The "sn" sysfs attribute holds the board's serial number. + This value is provided on a board-level label. + +What: /sys/bus/platform/devices/MLNXBF04:00/uuid +Date: August 2023 +KernelVersion: 6.5 +Contact: "David Thompson <davthompson@nvidia.com>" +Description: + The "uuid" sysfs attribute holds the board's UUID. + This value is provided by the manufacturing team. + +What: /sys/bus/platform/devices/MLNXBF04:00/rev +Date: August 2023 +KernelVersion: 6.5 +Contact: "David Thompson <davthompson@nvidia.com>" +Description: + The "rev" sysfs attribute holds the board's revision. + This value is provided on a board-level label. + +What: /sys/bus/platform/devices/MLNXBF04:00/mfg_lock +Date: August 2023 +KernelVersion: 6.5 +Contact: "David Thompson <davthompson@nvidia.com>" +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. diff --git a/Documentation/ABI/testing/sysfs-platform-power-on-reason b/Documentation/ABI/testing/sysfs-platform-power-on-reason new file mode 100644 index 000000000000..c3b29dbc64bf --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-power-on-reason @@ -0,0 +1,12 @@ +What: /sys/devices/platform/.../power_on_reason +Date: June 2023 +KernelVersion: 6.5 +Contact: Kamel Bouhara <kamel.bouhara@bootlin.com> +Description: Shows system power on reason. The following strings/reasons can + be read (the list can be extended): + "regular power-up", "RTC wakeup", "watchdog timeout", + "software reset", "reset button action", "CPU clock failure", + "crystal oscillator failure", "brown-out reset", + "unknown reason". + + The file is read only. diff --git a/Documentation/ABI/testing/sysfs-platform-sst-atom b/Documentation/ABI/testing/sysfs-platform-sst-atom index 0154b0fba759..4bb2e6135c2e 100644 --- a/Documentation/ABI/testing/sysfs-platform-sst-atom +++ b/Documentation/ABI/testing/sysfs-platform-sst-atom @@ -4,7 +4,7 @@ KernelVersion: 4.10 Contact: "Sebastien Guiriec" <sebastien.guiriec@intel.com> Description: LPE Firmware version for SST driver on all atom - plaforms (BYT/CHT/Merrifield/BSW). + platforms (BYT/CHT/Merrifield/BSW). If the FW has never been loaded it will display:: "FW not yet loaded" diff --git a/Documentation/ABI/testing/sysfs-wusb_cbaf b/Documentation/ABI/testing/sysfs-wusb_cbaf deleted file mode 100644 index 2969d3694ec0..000000000000 --- a/Documentation/ABI/testing/sysfs-wusb_cbaf +++ /dev/null @@ -1,101 +0,0 @@ -What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_* -Date: August 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - Various files for managing Cable Based Association of - (wireless) USB devices. - - The sequence of operations should be: - - 1. Device is plugged in. - - 2. The connection manager (CM) sees a device with CBA capability. - (the wusb_chid etc. files in /sys/devices/blah/OURDEVICE). - - 3. The CM writes the host name, supported band groups, - and the CHID (host ID) into the wusb_host_name, - wusb_host_band_groups and wusb_chid files. These - get sent to the device and the CDID (if any) for - this host is requested. - - 4. The CM can verify that the device's supported band - groups (wusb_device_band_groups) are compatible - with the host. - - 5. The CM reads the wusb_cdid file. - - 6. The CM looks it up its database. - - - If it has a matching CHID,CDID entry, the device - has been authorized before and nothing further - needs to be done. - - - If the CDID is zero (or the CM doesn't find a - matching CDID in its database), the device is - assumed to be not known. The CM may associate - the host with device by: writing a randomly - generated CDID to wusb_cdid and then a random CK - to wusb_ck (this uploads the new CC to the - device). - - CMD may choose to prompt the user before - associating with a new device. - - 7. Device is unplugged. - - References: - [WUSB-AM] - Association Models Supplement to the - Certified Wireless Universal Serial Bus - Specification, version 1.0. - -What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_chid -Date: August 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - The CHID of the host formatted as 16 space-separated - hex octets. - - Writes fetches device's supported band groups and the - the CDID for any existing association with this host. - -What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_host_name -Date: August 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - A friendly name for the host as a UTF-8 encoded string. - -What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_host_band_groups -Date: August 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - The band groups supported by the host, in the format - defined in [WUSB-AM]. - -What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_device_band_groups -Date: August 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - The band groups supported by the device, in the format - defined in [WUSB-AM]. - -What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_cdid -Date: August 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - The device's CDID formatted as 16 space-separated hex - octets. - -What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_ck -Date: August 2008 -KernelVersion: 2.6.27 -Contact: David Vrabel <david.vrabel@csr.com> -Description: - Write 16 space-separated random, hex octets to - associate with the device. diff --git a/Documentation/Makefile b/Documentation/Makefile index 023fa658a0a8..2f35793acd2a 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -59,6 +59,12 @@ PAPEROPT_letter = -D latex_paper_size=letter KERNELDOC = $(srctree)/scripts/kernel-doc KERNELDOC_CONF = -D kerneldoc_srctree=$(srctree) -D kerneldoc_bin=$(KERNELDOC) ALLSPHINXOPTS = $(KERNELDOC_CONF) $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) +ifneq ($(wildcard $(srctree)/.config),) +ifeq ($(CONFIG_RUST),y) + # Let Sphinx know we will include rustdoc + ALLSPHINXOPTS += -t rustdoc +endif +endif # the i18n builder cannot share the environment and doctrees with the others I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . @@ -95,6 +101,16 @@ htmldocs: @$(srctree)/scripts/sphinx-pre-install --version-check @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,html,$(var),,$(var))) +# If Rust support is available and .config exists, add rustdoc generated contents. +# If there are any, the errors from this make rustdoc will be displayed but +# won't stop the execution of htmldocs + +ifneq ($(wildcard $(srctree)/.config),) +ifeq ($(CONFIG_RUST),y) + $(Q)$(MAKE) rustdoc || true +endif +endif + texinfodocs: @$(srctree)/scripts/sphinx-pre-install --version-check @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,texinfo,$(var),texinfo,$(var))) diff --git a/Documentation/PCI/endpoint/pci-ntb-howto.rst b/Documentation/PCI/endpoint/pci-ntb-howto.rst index 1884bf29caba..4261e7157ef1 100644 --- a/Documentation/PCI/endpoint/pci-ntb-howto.rst +++ b/Documentation/PCI/endpoint/pci-ntb-howto.rst @@ -88,13 +88,10 @@ commands can be used:: # echo 0x104c > functions/pci_epf_ntb/func1/vendorid # echo 0xb00d > functions/pci_epf_ntb/func1/deviceid -In order to configure NTB specific attributes, a new sub-directory to func1 -should be created:: - - # mkdir functions/pci_epf_ntb/func1/pci_epf_ntb.0/ - -The NTB function driver will populate this directory with various attributes -that can be configured by the user:: +The PCI endpoint framework also automatically creates a sub-directory in the +function attribute directory. This sub-directory has the same name as the name +of the function device and is populated with the following NTB specific +attributes that can be configured by the user:: # ls functions/pci_epf_ntb/func1/pci_epf_ntb.0/ db_count mw1 mw2 mw3 mw4 num_mws diff --git a/Documentation/PCI/endpoint/pci-vntb-howto.rst b/Documentation/PCI/endpoint/pci-vntb-howto.rst index 4ab8e4a26d4b..70d3bc90893f 100644 --- a/Documentation/PCI/endpoint/pci-vntb-howto.rst +++ b/Documentation/PCI/endpoint/pci-vntb-howto.rst @@ -84,13 +84,10 @@ commands can be used:: # echo 0x1957 > functions/pci_epf_vntb/func1/vendorid # echo 0x0809 > functions/pci_epf_vntb/func1/deviceid -In order to configure NTB specific attributes, a new sub-directory to func1 -should be created:: - - # mkdir functions/pci_epf_vntb/func1/pci_epf_vntb.0/ - -The NTB function driver will populate this directory with various attributes -that can be configured by the user:: +The PCI endpoint framework also automatically creates a sub-directory in the +function attribute directory. This sub-directory has the same name as the name +of the function device and is populated with the following NTB specific +attributes that can be configured by the user:: # ls functions/pci_epf_vntb/func1/pci_epf_vntb.0/ db_count mw1 mw2 mw3 mw4 num_mws @@ -103,7 +100,7 @@ A sample configuration for NTB function is given below:: # echo 1 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/num_mws # echo 0x100000 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/mw1 -A sample configuration for virtual NTB driver for virutal PCI bus:: +A sample configuration for virtual NTB driver for virtual PCI bus:: # echo 0x1957 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_vid # echo 0x080A > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_pid diff --git a/Documentation/PCI/msi-howto.rst b/Documentation/PCI/msi-howto.rst index 8ae461e97c54..c9400f02333b 100644 --- a/Documentation/PCI/msi-howto.rst +++ b/Documentation/PCI/msi-howto.rst @@ -290,7 +290,7 @@ PCI_IRQ_MSI or PCI_IRQ_MSIX flags. List of device drivers MSI(-X) APIs =================================== -The PCI/MSI subystem has a dedicated C file for its exported device driver +The PCI/MSI subsystem has a dedicated C file for its exported device driver APIs — `drivers/pci/msi/api.c`. The following functions are exported: .. kernel-doc:: drivers/pci/msi/api.c diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst index 9981d330da8f..0c7552a00c8c 100644 --- a/Documentation/PCI/pci-error-recovery.rst +++ b/Documentation/PCI/pci-error-recovery.rst @@ -17,7 +17,7 @@ chipsets are able to deal with these errors; these include PCI-E chipsets, and the PCI-host bridges found on IBM Power4, Power5 and Power6-based pSeries boxes. A typical action taken is to disconnect the affected device, halting all I/O to it. The goal of a disconnection is to avoid system -corruption; for example, to halt system memory corruption due to DMA's +corruption; for example, to halt system memory corruption due to DMAs to "wild" addresses. Typically, a reconnection mechanism is also offered, so that the affected PCI device(s) are reset and put back into working condition. The reset phase requires coordination @@ -178,9 +178,9 @@ is STEP 6 (Permanent Failure). complex and not worth implementing. The current powerpc implementation doesn't much care if the device - attempts I/O at this point, or not. I/O's will fail, returning + attempts I/O at this point, or not. I/Os will fail, returning a value of 0xff on read, and writes will be dropped. If more than - EEH_MAX_FAILS I/O's are attempted to a frozen adapter, EEH + EEH_MAX_FAILS I/Os are attempted to a frozen adapter, EEH assumes that the device driver has gone into an infinite loop and prints an error to syslog. A reboot is then required to get the device working again. @@ -204,7 +204,7 @@ instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset) .. note:: The following is proposed; no platform implements this yet: - Proposal: All I/O's should be done _synchronously_ from within + Proposal: All I/Os should be done _synchronously_ from within this callback, errors triggered by them will be returned via the normal pci_check_whatever() API, no new error_detected() callback will be issued due to an error happening here. However, @@ -258,7 +258,7 @@ Powerpc platforms implement two levels of slot reset: soft reset(default) and fundamental(optional) reset. Powerpc soft reset consists of asserting the adapter #RST line and then -restoring the PCI BAR's and PCI configuration header to a state +restoring the PCI BARs and PCI configuration header to a state that is equivalent to what it would be after a fresh system power-on followed by power-on BIOS/system firmware initialization. Soft reset is also known as hot-reset. @@ -362,9 +362,9 @@ permanent failure in some way. If the device is hotplug-capable, the operator will probably want to remove and replace the device. Note, however, not all failures are truly "permanent". Some are caused by over-heating, some by a poorly seated card. Many -PCI error events are caused by software bugs, e.g. DMA's to +PCI error events are caused by software bugs, e.g. DMAs to wild addresses or bogus split transactions due to programming -errors. See the discussion in powerpc/eeh-pci-error-recovery.txt +errors. See the discussion in Documentation/powerpc/eeh-pci-error-recovery.rst for additional detail on real-life experience of the causes of software errors. diff --git a/Documentation/PCI/pcieaer-howto.rst b/Documentation/PCI/pcieaer-howto.rst index 0b36b9ebfa4b..e00d63971695 100644 --- a/Documentation/PCI/pcieaer-howto.rst +++ b/Documentation/PCI/pcieaer-howto.rst @@ -16,62 +16,61 @@ Overview About this guide ---------------- -This guide describes the basics of the PCI Express Advanced Error +This guide describes the basics of the PCI Express (PCIe) Advanced Error Reporting (AER) driver and provides information on how to use it, as -well as how to enable the drivers of endpoint devices to conform with -PCI Express AER driver. +well as how to enable the drivers of Endpoint devices to conform with +the PCIe AER driver. -What is the PCI Express AER Driver? ------------------------------------ +What is the PCIe AER Driver? +---------------------------- -PCI Express error signaling can occur on the PCI Express link itself -or on behalf of transactions initiated on the link. PCI Express +PCIe error signaling can occur on the PCIe link itself +or on behalf of transactions initiated on the link. PCIe defines two error reporting paradigms: the baseline capability and the Advanced Error Reporting capability. The baseline capability is -required of all PCI Express components providing a minimum defined +required of all PCIe components providing a minimum defined set of error reporting requirements. Advanced Error Reporting -capability is implemented with a PCI Express advanced error reporting +capability is implemented with a PCIe Advanced Error Reporting extended capability structure providing more robust error reporting. -The PCI Express AER driver provides the infrastructure to support PCI -Express Advanced Error Reporting capability. The PCI Express AER -driver provides three basic functions: +The PCIe AER driver provides the infrastructure to support PCIe Advanced +Error Reporting capability. The PCIe AER driver provides three basic +functions: - Gathers the comprehensive error information if errors occurred. - Reports error to the users. - Performs error recovery actions. -AER driver only attaches root ports which support PCI-Express AER -capability. +The AER driver only attaches to Root Ports and RCECs that support the PCIe +AER capability. User Guide ========== -Include the PCI Express AER Root Driver into the Linux Kernel -------------------------------------------------------------- +Include the PCIe AER Root Driver into the Linux Kernel +------------------------------------------------------ -The PCI Express AER Root driver is a Root Port service driver attached -to the PCI Express Port Bus driver. If a user wants to use it, the driver -has to be compiled. Option CONFIG_PCIEAER supports this capability. It -depends on CONFIG_PCIEPORTBUS, so pls. set CONFIG_PCIEPORTBUS=y and -CONFIG_PCIEAER = y. +The PCIe AER driver is a Root Port service driver attached +via the PCIe Port Bus driver. If a user wants to use it, the driver +must be compiled. It is enabled with CONFIG_PCIEAER, which +depends on CONFIG_PCIEPORTBUS. -Load PCI Express AER Root Driver --------------------------------- +Load PCIe AER Root Driver +------------------------- Some systems have AER support in firmware. Enabling Linux AER support at -the same time the firmware handles AER may result in unpredictable +the same time the firmware handles AER would result in unpredictable behavior. Therefore, Linux does not handle AER events unless the firmware -grants AER control to the OS via the ACPI _OSC method. See the PCI FW 3.0 +grants AER control to the OS via the ACPI _OSC method. See the PCI Firmware Specification for details regarding _OSC usage. AER error output ---------------- When a PCIe AER error is captured, an error message will be output to -console. If it's a correctable error, it is output as a warning. +console. If it's a correctable error, it is output as an info message. Otherwise, it is printed as an error. So users could choose different log level to filter out correctable error messages. @@ -82,9 +81,9 @@ Below shows an example:: 0000:50:00.0: [20] Unsupported Request (First) 0000:50:00.0: TLP Header: 04000001 00200a03 05010000 00050100 -In the example, 'Requester ID' means the ID of the device who sends -the error message to root port. Pls. refer to pci express specs for -other fields. +In the example, 'Requester ID' means the ID of the device that sent +the error message to the Root Port. Please refer to PCIe specs for other +fields. AER Statistics / Counters ------------------------- @@ -96,65 +95,56 @@ Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats Developer Guide =============== -To enable AER aware support requires a software driver to configure -the AER capability structure within its device and to provide callbacks. +To enable error recovery, a software driver must provide callbacks. -To support AER better, developers need understand how AER does work -firstly. +To support AER better, developers need to understand how AER works. -PCI Express errors are classified into two types: correctable errors -and uncorrectable errors. This classification is based on the impacts +PCIe errors are classified into two types: correctable errors +and uncorrectable errors. This classification is based on the impact of those errors, which may result in degraded performance or function failure. Correctable errors pose no impacts on the functionality of the -interface. The PCI Express protocol can recover without any software +interface. The PCIe protocol can recover without any software intervention or any loss of data. These errors are detected and -corrected by hardware. Unlike correctable errors, uncorrectable +corrected by hardware. + +Unlike correctable errors, uncorrectable errors impact functionality of the interface. Uncorrectable errors -can cause a particular transaction or a particular PCI Express link +can cause a particular transaction or a particular PCIe link to be unreliable. Depending on those error conditions, uncorrectable errors are further classified into non-fatal errors and fatal errors. Non-fatal errors cause the particular transaction to be unreliable, -but the PCI Express link itself is fully functional. Fatal errors, on +but the PCIe link itself is fully functional. Fatal errors, on the other hand, cause the link to be unreliable. -When AER is enabled, a PCI Express device will automatically send an -error message to the PCIe root port above it when the device captures +When PCIe error reporting is enabled, a device will automatically send an +error message to the Root Port above it when it captures an error. The Root Port, upon receiving an error reporting message, -internally processes and logs the error message in its PCI Express -capability structure. Error information being logged includes storing +internally processes and logs the error message in its AER +Capability structure. Error information being logged includes storing the error reporting agent's requestor ID into the Error Source Identification Registers and setting the error bits of the Root Error -Status Register accordingly. If AER error reporting is enabled in Root -Error Command Register, the Root Port generates an interrupt if an +Status Register accordingly. If AER error reporting is enabled in the Root +Error Command Register, the Root Port generates an interrupt when an error is detected. -Note that the errors as described above are related to the PCI Express +Note that the errors as described above are related to the PCIe hierarchy and links. These errors do not include any device specific errors because device specific errors will still get sent directly to the device driver. -Configure the AER capability structure --------------------------------------- - -AER aware drivers of PCI Express component need change the device -control registers to enable AER. They also could change AER registers, -including mask and severity registers. Helper function -pci_enable_pcie_error_reporting could be used to enable AER. See -section 3.3. - Provide callbacks ----------------- -callback reset_link to reset pci express link -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +callback reset_link to reset PCIe link +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This callback is used to reset the pci express physical link when a -fatal error happens. The root port aer service driver provides a -default reset_link function, but different upstream ports might -have different specifications to reset pci express link, so all -upstream ports should provide their own reset_link functions. +This callback is used to reset the PCIe physical link when a +fatal error happens. The Root Port AER service driver provides a +default reset_link function, but different Upstream Ports might +have different specifications to reset the PCIe link, so +Upstream Port drivers may provide their own reset_link functions. Section 3.2.2.2 provides more detailed info on when to call reset_link. @@ -162,24 +152,24 @@ reset_link. PCI error-recovery callbacks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The PCI Express AER Root driver uses error callbacks to coordinate +The PCIe AER Root driver uses error callbacks to coordinate with downstream device drivers associated with a hierarchy in question when performing error recovery actions. Data struct pci_driver has a pointer, err_handler, to point to pci_error_handlers who consists of a couple of callback function -pointers. AER driver follows the rules defined in -pci-error-recovery.txt except pci express specific parts (e.g. -reset_link). Pls. refer to pci-error-recovery.txt for detailed +pointers. The AER driver follows the rules defined in +pci-error-recovery.rst except PCIe-specific parts (e.g. +reset_link). Please refer to pci-error-recovery.rst for detailed definitions of the callbacks. -Below sections specify when to call the error callback functions. +The sections below specify when to call the error callback functions. Correctable errors ~~~~~~~~~~~~~~~~~~ Correctable errors pose no impacts on the functionality of -the interface. The PCI Express protocol can recover without any +the interface. The PCIe protocol can recover without any software intervention or any loss of data. These errors do not require any recovery actions. The AER driver clears the device's correctable error status register accordingly and logs these errors. @@ -190,12 +180,12 @@ Non-correctable (non-fatal and fatal) errors If an error message indicates a non-fatal error, performing link reset at upstream is not required. The AER driver calls error_detected(dev, pci_channel_io_normal) to all drivers associated within a hierarchy in -question. for example:: +question. For example:: - EndPoint<==>DownstreamPort B<==>UpstreamPort A<==>RootPort + Endpoint <==> Downstream Port B <==> Upstream Port A <==> Root Port -If Upstream port A captures an AER error, the hierarchy consists of -Downstream port B and EndPoint. +If Upstream Port A captures an AER error, the hierarchy consists of +Downstream Port B and Endpoint. A driver may return PCI_ERS_RESULT_CAN_RECOVER, PCI_ERS_RESULT_DISCONNECT, or PCI_ERS_RESULT_NEED_RESET, depending on @@ -212,36 +202,11 @@ to reset the link. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER and reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes to mmio_enabled. -helper functions ----------------- -:: - - int pci_enable_pcie_error_reporting(struct pci_dev *dev); - -pci_enable_pcie_error_reporting enables the device to send error -messages to root port when an error is detected. Note that devices -don't enable the error reporting by default, so device drivers need -call this function to enable it. - -:: - - int pci_disable_pcie_error_reporting(struct pci_dev *dev); - -pci_disable_pcie_error_reporting disables the device to send error -messages to root port when an error is detected. - -:: - - int pci_aer_clear_nonfatal_status(struct pci_dev *dev);` - -pci_aer_clear_nonfatal_status clears non-fatal errors in the uncorrectable -error status register. - Frequent Asked Questions ------------------------ Q: - What happens if a PCI Express device driver does not provide an + What happens if a PCIe device driver does not provide an error recovery handler (pci_driver->err_handler is equal to NULL)? A: @@ -257,24 +222,6 @@ A: Fatal error recovery will fail if the errors are reported by the upstream ports who are attached by the service driver. -Q: - How does this infrastructure deal with driver that is not PCI - Express aware? - -A: - This infrastructure calls the error callback functions of the - driver when an error happens. But if the driver is not aware of - PCI Express, the device might not report its own errors to root - port. - -Q: - What modifications will that driver need to make it compatible - with the PCI Express AER Root driver? - -A: - It could call the helper functions to enable AER in devices and - cleanup uncorrectable status register. Pls. refer to section 3.3. - Software error injection ======================== @@ -296,5 +243,5 @@ from: https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/ -More information about aer-inject can be found in the document comes -with its source code. +More information about aer-inject can be found in the document in +its source code. diff --git a/Documentation/PCI/pciebus-howto.rst b/Documentation/PCI/pciebus-howto.rst index f882ff62c51f..a0027e8fb0d0 100644 --- a/Documentation/PCI/pciebus-howto.rst +++ b/Documentation/PCI/pciebus-howto.rst @@ -213,8 +213,12 @@ PCI Config Registers -------------------- Each service driver runs its PCI config operations on its own -capability structure except the PCI Express capability structure, in -which Root Control register and Device Control register are shared -between PME and AER. This patch assumes that all service drivers -will be well behaved and not overwrite other service driver's -configuration settings. +capability structure except the PCI Express capability structure, +that is shared between many drivers including the service drivers. +RMW Capability accessors (pcie_capability_clear_and_set_word(), +pcie_capability_set_word(), and pcie_capability_clear_word()) protect +a selected set of PCI Express Capability Registers (Link Control +Register and Root Control Register). Any change to those registers +should be performed using RMW accessors to avoid problems due to +concurrent updates. For the up-to-date list of protected registers, +see pcie_capability_clear_and_set_word(). diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 49387d823619..f3b605285a87 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -2071,41 +2071,7 @@ call. Because RCU avoids interrupting idle CPUs, it is illegal to execute an RCU read-side critical section on an idle CPU. (Kernels built with -``CONFIG_PROVE_RCU=y`` will splat if you try it.) The RCU_NONIDLE() -macro and ``_rcuidle`` event tracing is provided to work around this -restriction. In addition, rcu_is_watching() may be used to test -whether or not it is currently legal to run RCU read-side critical -sections on this CPU. I learned of the need for diagnostics on the one -hand and RCU_NONIDLE() on the other while inspecting idle-loop code. -Steven Rostedt supplied ``_rcuidle`` event tracing, which is used quite -heavily in the idle loop. However, there are some restrictions on the -code placed within RCU_NONIDLE(): - -#. Blocking is prohibited. In practice, this is not a serious - restriction given that idle tasks are prohibited from blocking to - begin with. -#. Although nesting RCU_NONIDLE() is permitted, they cannot nest - indefinitely deeply. However, given that they can be nested on the - order of a million deep, even on 32-bit systems, this should not be a - serious restriction. This nesting limit would probably be reached - long after the compiler OOMed or the stack overflowed. -#. Any code path that enters RCU_NONIDLE() must sequence out of that - same RCU_NONIDLE(). For example, the following is grossly - illegal: - - :: - - 1 RCU_NONIDLE({ - 2 do_something(); - 3 goto bad_idea; /* BUG!!! */ - 4 do_something_else();}); - 5 bad_idea: - - - It is just as illegal to transfer control into the middle of - RCU_NONIDLE()'s argument. Yes, in theory, you could transfer in - as long as you also transferred out, but in practice you could also - expect to get sharply worded review comments. +``CONFIG_PROVE_RCU=y`` will splat if you try it.) It is similarly socially unacceptable to interrupt an ``nohz_full`` CPU running in userspace. RCU must therefore track ``nohz_full`` userspace diff --git a/Documentation/RCU/lockdep-splat.rst b/Documentation/RCU/lockdep-splat.rst index 2a5c79db57dc..bcbc4b3c88d7 100644 --- a/Documentation/RCU/lockdep-splat.rst +++ b/Documentation/RCU/lockdep-splat.rst @@ -10,7 +10,7 @@ misuses of the RCU API, most notably using one of the rcu_dereference() family to access an RCU-protected pointer without the proper protection. When such misuse is detected, an lockdep-RCU splat is emitted. -The usual cause of a lockdep-RCU slat is someone accessing an +The usual cause of a lockdep-RCU splat is someone accessing an RCU-protected data structure without either (1) being in the right kind of RCU read-side critical section or (2) holding the right update-side lock. This problem can therefore be serious: it might result in random memory diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst index 9a734bf54b76..21e40fcc08de 100644 --- a/Documentation/RCU/rculist_nulls.rst +++ b/Documentation/RCU/rculist_nulls.rst @@ -18,7 +18,16 @@ to solve following problem. Without 'nulls', a typical RCU linked list managing objects which are allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can use the following -algorithms: +algorithms. Following examples assume 'obj' is a pointer to such +objects, which is having below type. + +:: + + struct object { + struct hlist_node obj_node; + atomic_t refcnt; + unsigned int key; + }; 1) Lookup algorithm ------------------- @@ -26,11 +35,13 @@ algorithms: :: begin: - rcu_read_lock() + rcu_read_lock(); obj = lockless_lookup(key); if (obj) { - if (!try_get_ref(obj)) // might fail for free objects + if (!try_get_ref(obj)) { // might fail for free objects + rcu_read_unlock(); goto begin; + } /* * Because a writer could delete object, and a writer could * reuse these object before the RCU grace period, we @@ -54,7 +65,7 @@ but a version with an additional memory barrier (smp_rmb()) struct hlist_node *node, *next; for (pos = rcu_dereference((head)->first); pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) && - ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; }); + ({ obj = hlist_entry(pos, typeof(*obj), obj_node); 1; }); pos = rcu_dereference(next)) if (obj->key == key) return obj; @@ -66,10 +77,10 @@ And note the traditional hlist_for_each_entry_rcu() misses this smp_rmb():: struct hlist_node *node; for (pos = rcu_dereference((head)->first); pos && ({ prefetch(pos->next); 1; }) && - ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; }); + ({ obj = hlist_entry(pos, typeof(*obj), obj_node); 1; }); pos = rcu_dereference(pos->next)) - if (obj->key == key) - return obj; + if (obj->key == key) + return obj; return NULL; Quoting Corey Minyard:: @@ -86,7 +97,7 @@ Quoting Corey Minyard:: 2) Insertion algorithm ---------------------- -We need to make sure a reader cannot read the new 'obj->obj_next' value +We need to make sure a reader cannot read the new 'obj->obj_node.next' value and previous value of 'obj->key'. Otherwise, an item could be deleted from a chain, and inserted into another chain. If new chain was empty before the move, 'next' pointer is NULL, and lockless reader can not @@ -129,8 +140,7 @@ very very fast (before the end of RCU grace period) Avoiding extra smp_rmb() ======================== -With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup() -and extra _release() in insert function. +With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup(). For example, if we choose to store the slot number as the 'nulls' end-of-list marker for each slot of the hash table, we can detect @@ -142,6 +152,9 @@ the beginning. If the object was moved to the same chain, then the reader doesn't care: It might occasionally scan the list again without harm. +Note that using hlist_nulls means the type of 'obj_node' field of +'struct object' becomes 'struct hlist_nulls_node'. + 1) lookup algorithm ------------------- @@ -151,7 +164,7 @@ scan the list again without harm. head = &table[slot]; begin: rcu_read_lock(); - hlist_nulls_for_each_entry_rcu(obj, node, head, member) { + hlist_nulls_for_each_entry_rcu(obj, node, head, obj_node) { if (obj->key == key) { if (!try_get_ref(obj)) { // might fail for free objects rcu_read_unlock(); @@ -182,6 +195,9 @@ scan the list again without harm. 2) Insert algorithm ------------------- +Same to the above one, but uses hlist_nulls_add_head_rcu() instead of +hlist_add_head_rcu(). + :: /* diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst index 8eddef28d3a1..e488c8e557a9 100644 --- a/Documentation/RCU/whatisRCU.rst +++ b/Documentation/RCU/whatisRCU.rst @@ -1117,7 +1117,6 @@ All: lockdep-checked RCU utility APIs:: RCU_LOCKDEP_WARN rcu_sleep_check - RCU_NONIDLE All: Unchecked RCU-protected pointer access:: diff --git a/Documentation/accounting/psi.rst b/Documentation/accounting/psi.rst index df6062eb3abb..d455db3e5808 100644 --- a/Documentation/accounting/psi.rst +++ b/Documentation/accounting/psi.rst @@ -178,7 +178,7 @@ Userspace monitor usage example Cgroup2 interface ================= -In a system with a CONFIG_CGROUP=y kernel and the cgroup2 filesystem +In a system with a CONFIG_CGROUPS=y kernel and the cgroup2 filesystem mounted, pressure stall information is also tracked for tasks grouped into cgroups. Each subdirectory in the cgroupfs mountpoint contains cpu.pressure, memory.pressure, and io.pressure files; the format is diff --git a/Documentation/admin-guide/acpi/ssdt-overlays.rst b/Documentation/admin-guide/acpi/ssdt-overlays.rst index b5fbf54dca19..5ea9f4a3b76e 100644 --- a/Documentation/admin-guide/acpi/ssdt-overlays.rst +++ b/Documentation/admin-guide/acpi/ssdt-overlays.rst @@ -103,7 +103,7 @@ allows a persistent, OS independent way of storing the user defined SSDTs. There is also work underway to implement EFI support for loading user defined SSDTs and using this method will make it easier to convert to the EFI loading mechanism when that will arrive. To enable it, the -CONFIG_EFI_CUSTOM_SSDT_OVERLAYS shoyld be chosen to y. +CONFIG_EFI_CUSTOM_SSDT_OVERLAYS should be chosen to y. In order to load SSDTs from an EFI variable the ``"efivar_ssdt=..."`` kernel command line parameter can be used (the name has a limitation of 16 characters). diff --git a/Documentation/admin-guide/bcache.rst b/Documentation/admin-guide/bcache.rst index bb5032a99234..6fdb495ac466 100644 --- a/Documentation/admin-guide/bcache.rst +++ b/Documentation/admin-guide/bcache.rst @@ -508,9 +508,6 @@ cache_miss_collisions cache miss, but raced with a write and data was already present (usually 0 since the synchronization for cache misses was rewritten) -cache_readaheads - Count of times readahead occurred. - Sysfs - cache set ~~~~~~~~~~~~~~~~~ diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst index a402359abb99..1f128458ddea 100644 --- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst +++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst @@ -62,7 +62,7 @@ Please note that implementation details can be changed. At cancel(), simply usage -= PAGE_SIZE. -Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. +Under below explanation, we assume CONFIG_SWAP=y. 4. Anonymous ============ diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 47d1d7d932a8..5f502bf68fbc 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -92,8 +92,6 @@ Brief summary of control files. memory.oom_control set/show oom controls. memory.numa_stat show the number of memory usage per numa node - memory.kmem.limit_in_bytes This knob is deprecated and writing to - it will return -ENOTSUPP. memory.kmem.usage_in_bytes show current kernel memory allocation memory.kmem.failcnt show the number of kernel memory usage hits limits @@ -197,11 +195,11 @@ are not accounted. We just account pages under usual VM management. RSS pages are accounted at page_fault unless they've already been accounted for earlier. A file page will be accounted for as Page Cache when it's -inserted into inode (radix-tree). While it's mapped into the page tables of +inserted into inode (xarray). While it's mapped into the page tables of processes, duplicate accounting is carefully avoided. An RSS page is unaccounted when it's fully unmapped. A PageCache page is -unaccounted when it's removed from radix-tree. Even if RSS pages are fully +unaccounted when it's removed from xarray. Even if RSS pages are fully unmapped (by kswapd), they may exist as SwapCache in the system until they are really freed. Such SwapCaches are also accounted. A swapped-in page is accounted after adding into swapcache. @@ -297,7 +295,7 @@ Lock order is as follows:: Page lock (PG_locked bit of page->flags) mm->page_table_lock or split pte_lock - lock_page_memcg (memcg->move_lock) + folio_memcg_lock (memcg->move_lock) mapping->i_pages lock lruvec->lru_lock. @@ -909,7 +907,7 @@ experiences some pressure. In this situation, only group C will receive the notification, i.e. groups A and B will not receive it. This is done to avoid excessive "broadcasting" of messages, which disturbs the system and which is especially bad if we are low on memory or thrashing. Group B, will receive -notification only if there are no event listers for group C. +notification only if there are no event listeners for group C. There are three optional modes that specify different propagation behavior: diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index e592a9364473..b26b5274eaaf 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1045,7 +1045,7 @@ All time durations are in microseconds. - user_usec - system_usec - and the following three when the controller is enabled: + and the following five when the controller is enabled: - nr_periods - nr_throttled @@ -1580,6 +1580,13 @@ PAGE_SIZE multiple when read back. Healthy workloads are not expected to reach this limit. + memory.swap.peak + A read-only single value file which exists on non-root + cgroups. + + The max swap usage recorded for the cgroup and its + descendants since the creation of the cgroup. + memory.swap.max A read-write single value file which exists on non-root cgroups. The default is "max". @@ -2022,31 +2029,33 @@ that attribute: no-change Do not modify the I/O priority class. - none-to-rt - For requests that do not have an I/O priority class (NONE), - change the I/O priority class into RT. Do not modify - the I/O priority class of other requests. + promote-to-rt + For requests that have a non-RT I/O priority class, change it into RT. + Also change the priority level of these requests to 4. Do not modify + the I/O priority of requests that have priority class RT. restrict-to-be For requests that do not have an I/O priority class or that have I/O - priority class RT, change it into BE. Do not modify the I/O priority - class of requests that have priority class IDLE. + priority class RT, change it into BE. Also change the priority level + of these requests to 0. Do not modify the I/O priority class of + requests that have priority class IDLE. idle Change the I/O priority class of all requests into IDLE, the lowest I/O priority class. + none-to-rt + Deprecated. Just an alias for promote-to-rt. + The following numerical values are associated with the I/O priority policies: -+-------------+---+ -| no-change | 0 | -+-------------+---+ -| none-to-rt | 1 | -+-------------+---+ -| rt-to-be | 2 | -+-------------+---+ -| all-to-idle | 3 | -+-------------+---+ ++----------------+---+ +| no-change | 0 | ++----------------+---+ +| rt-to-be | 2 | ++----------------+---+ +| all-to-idle | 3 | ++----------------+---+ The numerical value that corresponds to each I/O priority class is as follows: @@ -2062,9 +2071,13 @@ The numerical value that corresponds to each I/O priority class is as follows: The algorithm to set the I/O priority class for a request is as follows: -- Translate the I/O priority class policy into a number. -- Change the request I/O priority class into the maximum of the I/O priority - class policy number and the numerical I/O priority class. +- If I/O priority class policy is promote-to-rt, change the request I/O + priority class to IOPRIO_CLASS_RT and change the request I/O priority + level to 4. +- If I/O priorityt class is not promote-to-rt, translate the I/O priority + class policy into a number, then change the request I/O priority class + into the maximum of the I/O priority class policy number and the numerical + I/O priority class. PID --- @@ -2437,7 +2450,7 @@ Miscellaneous controller provides 3 interface files. If two misc resources (res_ res_b 10 misc.current - A read-only flat-keyed file shown in the non-root cgroups. It shows + A read-only flat-keyed file shown in the all cgroups. It shows the current usage of the resources in the cgroup and its children.:: $ cat misc.current diff --git a/Documentation/admin-guide/device-mapper/dm-flakey.rst b/Documentation/admin-guide/device-mapper/dm-flakey.rst index f7104c01b0f7..f967c5fea219 100644 --- a/Documentation/admin-guide/device-mapper/dm-flakey.rst +++ b/Documentation/admin-guide/device-mapper/dm-flakey.rst @@ -67,6 +67,16 @@ Optional feature parameters: Perform the replacement only if bio->bi_opf has all the selected flags set. + random_read_corrupt <probability> + During <down interval>, replace random byte in a read bio + with a random value. probability is an integer between + 0 and 1000000000 meaning 0% to 100% probability of corruption. + + random_write_corrupt <probability> + During <down interval>, replace random byte in a write bio + with a random value. probability is an integer between + 0 and 1000000000 meaning 0% to 100% probability of corruption. + Examples: Replaces the 32nd byte of READ bios with the value 1:: diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst b/Documentation/admin-guide/device-mapper/dm-integrity.rst index 8db172efa272..d8a5f14d0e3c 100644 --- a/Documentation/admin-guide/device-mapper/dm-integrity.rst +++ b/Documentation/admin-guide/device-mapper/dm-integrity.rst @@ -25,7 +25,7 @@ mode it calculates and verifies the integrity tag internally. In this mode, the dm-integrity target can be used to detect silent data corruption on the disk or in the I/O path. -There's an alternate mode of operation where dm-integrity uses bitmap +There's an alternate mode of operation where dm-integrity uses a bitmap instead of a journal. If a bit in the bitmap is 1, the corresponding region's data and integrity tags are not synchronized - if the machine crashes, the unsynchronized regions will be recalculated. The bitmap mode @@ -38,6 +38,15 @@ the device. But it will only format the device if the superblock contains zeroes. If the superblock is neither valid nor zeroed, the dm-integrity target can't be loaded. +Accesses to the on-disk metadata area containing checksums (aka tags) are +buffered using dm-bufio. When an access to any given metadata area +occurs, each unique metadata area gets its own buffer(s). The buffer size +is capped at the size of the metadata area, but may be smaller, thereby +requiring multiple buffers to represent the full metadata area. A smaller +buffer size will produce a smaller resulting read/write operation to the +metadata area for small reads/writes. The metadata is still read even in +a full write to the data covered by a single buffer. + To use the target for the first time: 1. overwrite the superblock with zeroes @@ -93,7 +102,7 @@ journal_sectors:number device. If the device is already formatted, the value from the superblock is used. -interleave_sectors:number +interleave_sectors:number (default 32768) The number of interleaved sectors. This values is rounded down to a power of two. If the device is already formatted, the value from the superblock is used. @@ -102,20 +111,16 @@ meta_device:device Don't interleave the data and metadata on the device. Use a separate device for metadata. -buffer_sectors:number - The number of sectors in one buffer. The value is rounded down to - a power of two. - - The tag area is accessed using buffers, the buffer size is - configurable. The large buffer size means that the I/O size will - be larger, but there could be less I/Os issued. +buffer_sectors:number (default 128) + The number of sectors in one metadata buffer. The value is rounded + down to a power of two. -journal_watermark:number +journal_watermark:number (default 50) The journal watermark in percents. When the size of the journal exceeds this watermark, the thread that flushes the journal will be started. -commit_time:number +commit_time:number (default 10000) Commit time in milliseconds. When this time passes, the journal is written. The journal is also written immediately if the FLUSH request is received. @@ -163,11 +168,10 @@ journal_mac:algorithm(:key) (the key is optional) the journal. Thus, modified sector number would be detected at this stage. -block_size:number - The size of a data block in bytes. The larger the block size the +block_size:number (default 512) + The size of a data block in bytes. The larger the block size the less overhead there is for per-block integrity metadata. - Supported values are 512, 1024, 2048 and 4096 bytes. If not - specified the default block size is 512 bytes. + Supported values are 512, 1024, 2048 and 4096 bytes. sectors_per_bit:number In the bitmap mode, this parameter specifies the number of @@ -209,6 +213,12 @@ table and swap the tables with suspend and resume). The other arguments should not be changed when reloading the target because the layout of disk data depend on them and the reloaded target would be non-functional. +For example, on a device using the default interleave_sectors of 32768, a +block_size of 512, and an internal_hash of crc32c with a tag size of 4 +bytes, it will take 128 KiB of tags to track a full data area, requiring +256 sectors of metadata per data area. With the default buffer_sectors of +128, that means there will be 2 buffers per metadata area, or 2 buffers +per 16 MiB of data. Status line: @@ -286,7 +296,8 @@ The layout of the formatted block device: Each run contains: * tag area - it contains integrity tags. There is one tag for each - sector in the data area + sector in the data area. The size of this area is always 4KiB or + greater. * data area - it contains data sectors. The number of data sectors in one run must be a power of two. log2 of this value is stored in the superblock. diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt index 06c525e01ea5..839054923530 100644 --- a/Documentation/admin-guide/devices.txt +++ b/Documentation/admin-guide/devices.txt @@ -2691,18 +2691,9 @@ 45 = /dev/ttyMM1 Marvell MPSC - port 1 (obsolete unused) 46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0 ... - 47 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5 - 50 = /dev/ttyIOC0 Altix serial card - ... - 81 = /dev/ttyIOC31 Altix serial card + 51 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5 82 = /dev/ttyVR0 NEC VR4100 series SIU 83 = /dev/ttyVR1 NEC VR4100 series DSIU - 84 = /dev/ttyIOC84 Altix ioc4 serial card - ... - 115 = /dev/ttyIOC115 Altix ioc4 serial card - 116 = /dev/ttySIOC0 Altix ioc3 serial card - ... - 147 = /dev/ttySIOC31 Altix ioc3 serial card 148 = /dev/ttyPSC0 PPC PSC - port 0 ... 153 = /dev/ttyPSC5 PPC PSC - port 5 @@ -2761,10 +2752,7 @@ 43 = /dev/ttycusmx2 Callout device for ttySMX2 46 = /dev/cucpm0 Callout device for ttyCPM0 ... - 49 = /dev/cucpm5 Callout device for ttyCPM5 - 50 = /dev/cuioc40 Callout device for ttyIOC40 - ... - 81 = /dev/cuioc431 Callout device for ttyIOC431 + 51 = /dev/cucpm5 Callout device for ttyCPM5 82 = /dev/cuvr0 Callout device for ttyVR0 83 = /dev/cuvr1 Callout device for ttyVR1 diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 8dc668cc1216..0b3d39c610d9 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -216,13 +216,14 @@ The flags are:: t Include thread ID, or <intr> m Include module name f Include the function name + s Include the source file name l Include line number For ``print_hex_dump_debug()`` and ``print_hex_dump_bytes()``, only the ``p`` flag has meaning, other flags are ignored. -Note the regexp ``^[-+=][flmpt_]+$`` matches a flags specification. -To clear all flags at once, use ``=_`` or ``-flmpt``. +Note the regexp ``^[-+=][fslmpt_]+$`` matches a flags specification. +To clear all flags at once, use ``=_`` or ``-fslmpt``. Debug messages during Boot Process diff --git a/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst new file mode 100644 index 000000000000..264bfa937f7d --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst @@ -0,0 +1,109 @@ +.. SPDX-License-Identifier: GPL-2.0 + +GDS - Gather Data Sampling +========================== + +Gather Data Sampling is a hardware vulnerability which allows unprivileged +speculative access to data which was previously stored in vector registers. + +Problem +------- +When a gather instruction performs loads from memory, different data elements +are merged into the destination vector register. However, when a gather +instruction that is transiently executed encounters a fault, stale data from +architectural or internal vector registers may get transiently forwarded to the +destination vector register instead. This will allow a malicious attacker to +infer stale data using typical side channel techniques like cache timing +attacks. GDS is a purely sampling-based attack. + +The attacker uses gather instructions to infer the stale vector register data. +The victim does not need to do anything special other than use the vector +registers. The victim does not need to use gather instructions to be +vulnerable. + +Because the buffers are shared between Hyper-Threads cross Hyper-Thread attacks +are possible. + +Attack scenarios +---------------- +Without mitigation, GDS can infer stale data across virtually all +permission boundaries: + + Non-enclaves can infer SGX enclave data + Userspace can infer kernel data + Guests can infer data from hosts + Guest can infer guest from other guests + Users can infer data from other users + +Because of this, it is important to ensure that the mitigation stays enabled in +lower-privilege contexts like guests and when running outside SGX enclaves. + +The hardware enforces the mitigation for SGX. Likewise, VMMs should ensure +that guests are not allowed to disable the GDS mitigation. If a host erred and +allowed this, a guest could theoretically disable GDS mitigation, mount an +attack, and re-enable it. + +Mitigation mechanism +-------------------- +This issue is mitigated in microcode. The microcode defines the following new +bits: + + ================================ === ============================ + IA32_ARCH_CAPABILITIES[GDS_CTRL] R/O Enumerates GDS vulnerability + and mitigation support. + IA32_ARCH_CAPABILITIES[GDS_NO] R/O Processor is not vulnerable. + IA32_MCU_OPT_CTRL[GDS_MITG_DIS] R/W Disables the mitigation + 0 by default. + IA32_MCU_OPT_CTRL[GDS_MITG_LOCK] R/W Locks GDS_MITG_DIS=0. Writes + to GDS_MITG_DIS are ignored + Can't be cleared once set. + ================================ === ============================ + +GDS can also be mitigated on systems that don't have updated microcode by +disabling AVX. This can be done by setting gather_data_sampling="force" or +"clearcpuid=avx" on the kernel command-line. + +If used, these options will disable AVX use by turning off XSAVE YMM support. +However, the processor will still enumerate AVX support. Userspace that +does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM +support will break. + +Mitigation control on the kernel command line +--------------------------------------------- +The mitigation can be disabled by setting "gather_data_sampling=off" or +"mitigations=off" on the kernel command line. Not specifying either will default +to the mitigation being enabled. Specifying "gather_data_sampling=force" will +use the microcode mitigation when available or disable AVX on affected systems +where the microcode hasn't been updated to include the mitigation. + +GDS System Information +------------------------ +The kernel provides vulnerability status information through sysfs. For +GDS this can be accessed by the following sysfs file: + +/sys/devices/system/cpu/vulnerabilities/gather_data_sampling + +The possible values contained in this file are: + + ============================== ============================================= + Not affected Processor not vulnerable. + Vulnerable Processor vulnerable and mitigation disabled. + Vulnerable: No microcode Processor vulnerable and microcode is missing + mitigation. + Mitigation: AVX disabled, + no microcode Processor is vulnerable and microcode is missing + mitigation. AVX disabled as mitigation. + Mitigation: Microcode Processor is vulnerable and mitigation is in + effect. + Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in + effect and cannot be disabled. + Unknown: Dependent on + hypervisor status Running on a virtual guest processor that is + affected but with no way to know if host + processor is mitigated or vulnerable. + ============================== ============================================= + +GDS Default mitigation +---------------------- +The updated microcode will enable the mitigation by default. The kernel's +default action is to leave the mitigation enabled. diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index e0614760a99e..de99caabf65a 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -13,9 +13,11 @@ are configurable at compile, boot or run time. l1tf mds tsx_async_abort - multihit.rst - special-register-buffer-data-sampling.rst - core-scheduling.rst - l1d_flush.rst - processor_mmio_stale_data.rst - cross-thread-rsb.rst + multihit + special-register-buffer-data-sampling + core-scheduling + l1d_flush + processor_mmio_stale_data + cross-thread-rsb + srso + gather_data_sampling diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index 4d186f599d90..32a8893e5617 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -484,11 +484,14 @@ Spectre variant 2 Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at boot, by setting the IBRS bit, and they're automatically protected against - Spectre v2 variant attacks, including cross-thread branch target injections - on SMT systems (STIBP). In other words, eIBRS enables STIBP too. + Spectre v2 variant attacks. - Legacy IBRS systems clear the IBRS bit on exit to userspace and - therefore explicitly enable STIBP for that + On Intel's enhanced IBRS systems, this includes cross-thread branch target + injections on SMT systems (STIBP). In other words, Intel eIBRS enables + STIBP, too. + + AMD Automatic IBRS does not protect userspace, and Legacy IBRS systems clear + the IBRS bit on exit to userspace, therefore both explicitly enable STIBP. The retpoline mitigation is turned on by default on vulnerable CPUs. It can be forced on or off by the administrator diff --git a/Documentation/admin-guide/hw-vuln/srso.rst b/Documentation/admin-guide/hw-vuln/srso.rst new file mode 100644 index 000000000000..b6cfb51cb0b4 --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/srso.rst @@ -0,0 +1,150 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Speculative Return Stack Overflow (SRSO) +======================================== + +This is a mitigation for the speculative return stack overflow (SRSO) +vulnerability found on AMD processors. The mechanism is by now the well +known scenario of poisoning CPU functional units - the Branch Target +Buffer (BTB) and Return Address Predictor (RAP) in this case - and then +tricking the elevated privilege domain (the kernel) into leaking +sensitive data. + +AMD CPUs predict RET instructions using a Return Address Predictor (aka +Return Address Stack/Return Stack Buffer). In some cases, a non-architectural +CALL instruction (i.e., an instruction predicted to be a CALL but is +not actually a CALL) can create an entry in the RAP which may be used +to predict the target of a subsequent RET instruction. + +The specific circumstances that lead to this varies by microarchitecture +but the concern is that an attacker can mis-train the CPU BTB to predict +non-architectural CALL instructions in kernel space and use this to +control the speculative target of a subsequent kernel RET, potentially +leading to information disclosure via a speculative side-channel. + +The issue is tracked under CVE-2023-20569. + +Affected processors +------------------- + +AMD Zen, generations 1-4. That is, all families 0x17 and 0x19. Older +processors have not been investigated. + +System information and options +------------------------------ + +First of all, it is required that the latest microcode be loaded for +mitigations to be effective. + +The sysfs file showing SRSO mitigation status is: + + /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow + +The possible values in this file are: + + * 'Not affected': + + The processor is not vulnerable + + * 'Vulnerable: no microcode': + + The processor is vulnerable, no microcode extending IBPB + functionality to address the vulnerability has been applied. + + * 'Mitigation: microcode': + + Extended IBPB functionality microcode patch has been applied. It does + not address User->Kernel and Guest->Host transitions protection but it + does address User->User and VM->VM attack vectors. + + Note that User->User mitigation is controlled by how the IBPB aspect in + the Spectre v2 mitigation is selected: + + * conditional IBPB: + + where each process can select whether it needs an IBPB issued + around it PR_SPEC_DISABLE/_ENABLE etc, see :doc:`spectre` + + * strict: + + i.e., always on - by supplying spectre_v2_user=on on the kernel + command line + + (spec_rstack_overflow=microcode) + + * 'Mitigation: safe RET': + + Software-only mitigation. It complements the extended IBPB microcode + patch functionality by addressing User->Kernel and Guest->Host + transitions protection. + + Selected by default or by spec_rstack_overflow=safe-ret + + * 'Mitigation: IBPB': + + Similar protection as "safe RET" above but employs an IBPB barrier on + privilege domain crossings (User->Kernel, Guest->Host). + + (spec_rstack_overflow=ibpb) + + * 'Mitigation: IBPB on VMEXIT': + + Mitigation addressing the cloud provider scenario - the Guest->Host + transitions only. + + (spec_rstack_overflow=ibpb-vmexit) + + + +In order to exploit vulnerability, an attacker needs to: + + - gain local access on the machine + + - break kASLR + + - find gadgets in the running kernel in order to use them in the exploit + + - potentially create and pin an additional workload on the sibling + thread, depending on the microarchitecture (not necessary on fam 0x19) + + - run the exploit + +Considering the performance implications of each mitigation type, the +default one is 'Mitigation: safe RET' which should take care of most +attack vectors, including the local User->Kernel one. + +As always, the user is advised to keep her/his system up-to-date by +applying software updates regularly. + +The default setting will be reevaluated when needed and especially when +new attack vectors appear. + +As one can surmise, 'Mitigation: safe RET' does come at the cost of some +performance depending on the workload. If one trusts her/his userspace +and does not want to suffer the performance impact, one can always +disable the mitigation with spec_rstack_overflow=off. + +Similarly, 'Mitigation: IBPB' is another full mitigation type employing +an indrect branch prediction barrier after having applied the required +microcode patch for one's system. This mitigation comes also at +a performance cost. + +Mitigation: safe RET +-------------------- + +The mitigation works by ensuring all RET instructions speculate to +a controlled location, similar to how speculation is controlled in the +retpoline sequence. To accomplish this, the __x86_return_thunk forces +the CPU to mispredict every function return using a 'safe return' +sequence. + +To ensure the safety of this mitigation, the kernel must ensure that the +safe return sequence is itself free from attacker interference. In Zen3 +and Zen4, this is accomplished by creating a BTB alias between the +untraining function srso_alias_untrain_ret() and the safe return +function srso_alias_safe_ret() which results in evicting a potentially +poisoned BTB entry and using that safe one for all function returns. + +In older Zen1 and Zen2, this is accomplished using a reinterpretation +technique similar to Retbleed one: srso_untrain_ret() and +srso_safe_ret(). diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index c18d94fa6470..599e8d3bcbc3 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -141,8 +141,8 @@ nodemask_t The size of a nodemask_t type. Used to compute the number of online nodes. -(page, flags|_refcount|mapping|lru|_mapcount|private|compound_dtor|compound_order|compound_head) -------------------------------------------------------------------------------------------------- +(page, flags|_refcount|mapping|lru|_mapcount|private|compound_order|compound_head) +---------------------------------------------------------------------------------- User-space tools compute their values based on the offset of these variables. The variables are used when excluding unnecessary pages. @@ -325,8 +325,8 @@ NR_FREE_PAGES On linux-2.6.21 or later, the number of free pages is in vm_stat[NR_FREE_PAGES]. Used to get the number of free pages. -PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision|PG_head_mask ------------------------------------------------------------------------------- +PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision|PG_head_mask|PG_hugetlb +----------------------------------------------------------------------------------------- Page attributes. These flags are used to filter various unnecessary for dumping pages. @@ -338,12 +338,6 @@ More page attributes. These flags are used to filter various unnecessary for dumping pages. -HUGETLB_PAGE_DTOR ------------------ - -The HUGETLB_PAGE_DTOR flag denotes hugetlbfs pages. Makedumpfile -excludes these pages. - x86_64 ====== @@ -624,3 +618,9 @@ Used to get the correct ranges: * VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space. * VMEMMAP_START ~ VMEMMAP_END : vmemmap space, used for struct page array. * KERNEL_LINK_ADDR : start address of Kernel link and BPF + +va_kernel_pa_offset +------------------- + +Indicates the offset between the kernel virtual and physical mappings. +Used to translate virtual to physical addresses. diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 1ba8f2a44aac..102937bc8443 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -80,7 +80,7 @@ The special case-tolerant group name "all" has a meaning of selecting all CPUs, so that "nohz_full=all" is the equivalent of "nohz_full=0-N". The semantics of "N" and "all" is supported on a level of bitmaps and holds for -all users of bitmap_parse(). +all users of bitmap_parselist(). This document may not be entirely up to date and comprehensive. The command "modinfo -p ${modulename}" shows a current list of all parameters of a loadable @@ -89,10 +89,11 @@ reveal their parameters in /sys/module/${modulename}/parameters/. Some of these parameters may be changed at runtime by the command ``echo -n ${value} > /sys/module/${modulename}/parameters/${parm}``. -The parameters listed below are only valid if certain kernel build options were -enabled and if respective hardware is present. The text in square brackets at -the beginning of each description states the restrictions within which a -parameter is applicable:: +The parameters listed below are only valid if certain kernel build options +were enabled and if respective hardware is present. This list should be kept +in alphabetical order. The text in square brackets at the beginning +of each description states the restrictions within which a parameter +is applicable:: ACPI ACPI support is enabled. AGP AGP (Accelerated Graphics Port) is enabled. @@ -127,9 +128,9 @@ parameter is applicable:: KGDB Kernel debugger support is enabled. KVM Kernel Virtual Machine support is enabled. LIBATA Libata driver is enabled - LP Printer support is enabled. LOONGARCH LoongArch architecture is enabled. LOOP Loopback device support is enabled. + LP Printer support is enabled. M68k M68k architecture is enabled. These options have more detailed description inside of Documentation/arch/m68k/kernel-options.rst. @@ -139,10 +140,9 @@ parameter is applicable:: MSI Message Signaled Interrupts (PCI). MTD MTD (Memory Technology Device) support is enabled. NET Appropriate network support is enabled. - NUMA NUMA support is enabled. NFS Appropriate NFS support is enabled. + NUMA NUMA support is enabled. OF Devicetree is enabled. - PV_OPS A paravirtualized kernel is enabled. PARISC The PA-RISC architecture is enabled. PCI PCI bus support is enabled. PCIE PCI Express support is enabled. @@ -151,9 +151,10 @@ parameter is applicable:: PPC PowerPC architecture is enabled. PPT Parallel port support is enabled. PS2 Appropriate PS/2 support is enabled. + PV_OPS A paravirtualized kernel is enabled. RAM RAM disk support is enabled. - RISCV RISCV architecture is enabled. RDT Intel Resource Director Technology. + RISCV RISCV architecture is enabled. S390 S390 architecture is enabled. SCSI Appropriate SCSI support is enabled. A lot of drivers have their options described inside @@ -164,15 +165,15 @@ parameter is applicable:: SH SuperH architecture is enabled. SMP The kernel is an SMP kernel. SPARC Sparc architecture is enabled. - SWSUSP Software suspend (hibernation) is enabled. SUSPEND System suspend states are enabled. + SWSUSP Software suspend (hibernation) is enabled. TPM TPM drivers are enabled. UMS USB Mass Storage support is enabled. USB USB support is enabled. USBHID USB Human Interface Device support is enabled. V4L Video For Linux support is enabled. - VMMIO Driver for memory mapped virtio devices is enabled. VGA The VGA console has been enabled. + VMMIO Driver for memory mapped virtio devices is enabled. VT Virtual terminal support is enabled. WDT Watchdog support is enabled. X86-32 X86-32, aka i386 architecture is enabled. @@ -186,9 +187,9 @@ parameter is applicable:: In addition, the following text indicates that the option:: + BOOT Is a boot loader parameter. BUGS= Relates to possible processor bugs on the said processor. KNL Is a kernel start-up parameter. - BOOT Is a boot loader parameter. Parameters denoted with BOOT are actually interpreted by the boot loader, and have no meaning to the kernel directly. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 9e5bab29685f..0a1731a0f0ef 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1,17 +1,17 @@ - acpi= [HW,ACPI,X86,ARM64] + acpi= [HW,ACPI,X86,ARM64,RISCV64] Advanced Configuration and Power Interface Format: { force | on | off | strict | noirq | rsdt | copy_dsdt } force -- enable ACPI if default was off - on -- enable ACPI but allow fallback to DT [arm64] + on -- enable ACPI but allow fallback to DT [arm64,riscv64] off -- disable ACPI if default was on noirq -- do not use ACPI for IRQ routing strict -- Be less tolerant of platforms that are not strictly ACPI specification compliant. rsdt -- prefer RSDT over (default) XSDT copy_dsdt -- copy DSDT to memory - For ARM64, ONLY "acpi=off", "acpi=on" or "acpi=force" - are available + For ARM64 and RISCV64, ONLY "acpi=off", "acpi=on" or + "acpi=force" are available See also Documentation/power/runtime_pm.rst, pci=noacpi @@ -304,7 +304,7 @@ EL0 is indicated by /sys/devices/system/cpu/aarch32_el0 and hot-unplug operations may be restricted. - See Documentation/arm64/asymmetric-32bit.rst for more + See Documentation/arch/arm64/asymmetric-32bit.rst for more information. amd_iommu= [HW,X86-64] @@ -323,6 +323,7 @@ option with care. pgtbl_v1 - Use v1 page table for DMA-API (Default). pgtbl_v2 - Use v2 page table for DMA-API. + irtcachedis - Disable Interrupt Remapping Table (IRT) caching. amd_iommu_dump= [HW,X86-64] Enable AMD IOMMU driver option to dump the ACPI table @@ -417,18 +418,21 @@ arm64.nobti [ARM64] Unconditionally disable Branch Target Identification support - arm64.nopauth [ARM64] Unconditionally disable Pointer Authentication - support + arm64.nomops [ARM64] Unconditionally disable Memory Copy and Memory + Set instructions support arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension support - arm64.nosve [ARM64] Unconditionally disable Scalable Vector - Extension support + arm64.nopauth [ARM64] Unconditionally disable Pointer Authentication + support arm64.nosme [ARM64] Unconditionally disable Scalable Matrix Extension support + arm64.nosve [ARM64] Unconditionally disable Scalable Vector + Extension support + ataflop= [HW,M68k] atarimouse= [HW,MOUSE] Atari Mouse @@ -549,7 +553,7 @@ others). ccw_timeout_log [S390] - See Documentation/s390/common_io.rst for details. + See Documentation/arch/s390/common_io.rst for details. cgroup_disable= [KNL] Disable a particular controller or optional feature Format: {name of the controller(s) or feature(s) to disable} @@ -594,7 +598,7 @@ Setting checkreqprot to 1 is deprecated. cio_ignore= [S390] - See Documentation/s390/common_io.rst for details. + See Documentation/arch/s390/common_io.rst for details. clearcpuid=X[,X...] [X86] Disable CPUID feature X for the kernel. See @@ -692,7 +696,7 @@ kernel/dma/contiguous.c cma_pernuma=nn[MG] - [ARM64,KNL,CMA] + [KNL,CMA] Sets the size of kernel per-numa memory area for contiguous memory allocations. A value of 0 disables per-numa CMA altogether. And If this option is not @@ -702,6 +706,17 @@ which is located in node nid, if the allocation fails, they will fallback to the global default memory area. + numa_cma=<node>:nn[MG][,<node>:nn[MG]] + [KNL,CMA] + Sets the size of kernel numa memory area for + contiguous memory allocations. It will reserve CMA + area for the specified node. + + With numa CMA enabled, DMA users on node nid will + first try to allocate buffer from the numa area + which is located in node nid, if the allocation fails, + they will fallback to the global default memory area. + cmo_free_hint= [PPC] Format: { yes | no } Specify whether pages are marked as being inactive when they are freed. This is used in CMO environments @@ -818,20 +833,6 @@ Format: <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>] - cpu0_hotplug [X86] Turn on CPU0 hotplug feature when - CONFIG_BOOTPARAM_HOTPLUG_CPU0 is off. - Some features depend on CPU0. Known dependencies are: - 1. Resume from suspend/hibernate depends on CPU0. - Suspend/hibernate will fail if CPU0 is offline and you - need to online CPU0 before suspend/hibernate. - 2. PIC interrupts also depend on CPU0. CPU0 can't be - removed if a PIC interrupt is detected. - It's said poweroff/reboot may depend on CPU0 on some - machines although I haven't seen such issues so far - after CPU0 is offline on a few tested machines. - If the dependencies are under your control, you can - turn on cpu0_hotplug. - cpuidle.off=1 [CPU_IDLE] disable the cpuidle sub-system @@ -852,6 +853,12 @@ on every CPU online, such as boot, and resume from suspend. Default: 10000 + cpuhp.parallel= + [SMP] Enable/disable parallel bringup of secondary CPUs + Format: <bool> + Default is enabled if CONFIG_HOTPLUG_PARALLEL=y. Otherwise + the parameter has no effect. + crash_kexec_post_notifiers Run kdump after running panic-notifiers and dumping kmsg. This only for the users who doubt kdump always @@ -866,7 +873,7 @@ memory region [offset, offset + size] for that kernel image. If '@offset' is omitted, then a suitable offset is selected automatically. - [KNL, X86-64, ARM64] Select a region under 4G first, and + [KNL, X86-64, ARM64, RISCV] Select a region under 4G first, and fall back to reserve region above 4G when '@offset' hasn't been specified. See Documentation/admin-guide/kdump/kdump.rst for further details. @@ -879,14 +886,14 @@ Documentation/admin-guide/kdump/kdump.rst for an example. crashkernel=size[KMG],high - [KNL, X86-64, ARM64] range could be above 4G. Allow kernel - to allocate physical memory region from top, so could - be above 4G if system have more than 4G ram installed. - Otherwise memory region will be allocated below 4G, if - available. + [KNL, X86-64, ARM64, RISCV] range could be above 4G. + Allow kernel to allocate physical memory region from top, + so could be above 4G if system have more than 4G ram + installed. Otherwise memory region will be allocated + below 4G, if available. It will be ignored if crashkernel=X is specified. crashkernel=size[KMG],low - [KNL, X86-64, ARM64] range under 4G. When crashkernel=X,high + [KNL, X86-64, ARM64, RISCV] range under 4G. When crashkernel=X,high is passed, kernel could allocate physical memory region above 4G, that cause second kernel crash on system that require some amount of low memory, e.g. swiotlb @@ -897,6 +904,7 @@ size is platform dependent. --> x86: max(swiotlb_size_or_default() + 8MiB, 256MiB) --> arm64: 128MiB + --> riscv: 128MiB This one lets the user specify own low range under 4G for second kernel instead. 0: to disable low allocation. @@ -1627,6 +1635,26 @@ Format: off | on default: on + gather_data_sampling= + [X86,INTEL] Control the Gather Data Sampling (GDS) + mitigation. + + Gather Data Sampling is a hardware vulnerability which + allows unprivileged speculative access to data which was + previously stored in vector registers. + + This issue is mitigated by default in updated microcode. + The mitigation may have a performance impact but can be + disabled. On systems without the microcode mitigation + disabling AVX serves as a mitigation. + + force: Disable AVX to mitigate systems without + microcode mitigation. No effect if the microcode + mitigation is present. Known to cause crashes in + userspace with buggy AVX enumeration. + + off: Disable GDS mitigation. + 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. @@ -2117,6 +2145,16 @@ disable Do not enable intel_pstate as the default scaling driver for the supported processors + active + Use intel_pstate driver to bypass the scaling + governors layer of cpufreq and provides it own + algorithms for p-state selection. There are two + P-state selection algorithms provided by + intel_pstate in the active mode: powersave and + performance. The way they both operate depends + on whether or not the hardware managed P-states + (HWP) feature has been enabled in the processor + and possibly on the processor model. passive Use intel_pstate as a scaling driver, but configure it to work with generic cpufreq governors (instead of @@ -2551,12 +2589,13 @@ If the value is 0 (the default), KVM will pick a period based on the ratio, such that a page is zapped after 1 hour on average. - kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM. - Default is 1 (enabled) + kvm-amd.nested= [KVM,AMD] Control nested virtualization feature in + KVM/SVM. Default is 1 (enabled). - kvm-amd.npt= [KVM,AMD] Disable nested paging (virtualized MMU) - for all guests. - Default is 1 (enabled) if in 64-bit or 32-bit PAE mode. + kvm-amd.npt= [KVM,AMD] Control KVM's use of Nested Page Tables, + a.k.a. Two-Dimensional Page Tables. Default is 1 + (enabled). Disable by KVM if hardware lacks support + for NPT. kvm-arm.mode= [KVM,ARM] Select one of KVM/arm64's modes of operation. @@ -2602,30 +2641,33 @@ Format: <integer> Default: 5 - kvm-intel.ept= [KVM,Intel] Disable extended page tables - (virtualized MMU) support on capable Intel chips. - Default is 1 (enabled) + kvm-intel.ept= [KVM,Intel] Control KVM's use of Extended Page Tables, + a.k.a. Two-Dimensional Page Tables. Default is 1 + (enabled). Disable by KVM if hardware lacks support + for EPT. kvm-intel.emulate_invalid_guest_state= - [KVM,Intel] Disable emulation of invalid guest state. - Ignored if kvm-intel.enable_unrestricted_guest=1, as - guest state is never invalid for unrestricted guests. - This param doesn't apply to nested guests (L2), as KVM - never emulates invalid L2 guest state. - Default is 1 (enabled) + [KVM,Intel] Control whether to emulate invalid guest + state. Ignored if kvm-intel.enable_unrestricted_guest=1, + as guest state is never invalid for unrestricted + guests. This param doesn't apply to nested guests (L2), + as KVM never emulates invalid L2 guest state. + Default is 1 (enabled). kvm-intel.flexpriority= - [KVM,Intel] Disable FlexPriority feature (TPR shadow). - Default is 1 (enabled) + [KVM,Intel] Control KVM's use of FlexPriority feature + (TPR shadow). Default is 1 (enabled). Disable by KVM if + hardware lacks support for it. kvm-intel.nested= - [KVM,Intel] Enable VMX nesting (nVMX). - Default is 0 (disabled) + [KVM,Intel] Control nested virtualization feature in + KVM/VMX. Default is 1 (enabled). kvm-intel.unrestricted_guest= - [KVM,Intel] Disable unrestricted guest feature - (virtualized real and unpaged mode) on capable - Intel chips. Default is 1 (enabled) + [KVM,Intel] Control KVM's use of unrestricted guest + feature (virtualized real and unpaged mode). Default + is 1 (enabled). Disable by KVM if EPT is disabled or + hardware lacks support for it. kvm-intel.vmentry_l1d_flush=[KVM,Intel] Mitigation for L1 Terminal Fault CVE-2018-3620. @@ -2639,9 +2681,10 @@ Default is cond (do L1 cache flush in specific instances) - kvm-intel.vpid= [KVM,Intel] Disable Virtual Processor Identification - feature (tagged TLBs) on capable Intel chips. - Default is 1 (enabled) + kvm-intel.vpid= [KVM,Intel] Control KVM's use of Virtual Processor + Identification feature (tagged TLBs). Default is 1 + (enabled). Disable by KVM if hardware lacks support + for it. l1d_flush= [X86,INTEL] Control mitigation for L1D based snooping vulnerability. @@ -2907,6 +2950,10 @@ locktorture.torture_type= [KNL] Specify the locking implementation to test. + locktorture.writer_fifo= [KNL] + Run the write-side locktorture kthreads at + sched_set_fifo() real-time priority. + locktorture.verbose= [KNL] Enable additional printk() statements. @@ -3094,7 +3141,7 @@ [KNL,SH] Allow user to override the default size for per-device physically contiguous DMA buffers. - memhp_default_state=online/offline + memhp_default_state=online/offline/online_kernel/online_movable [KNL] Set the initial state for the memory hotplug onlining policy. If not specified, the default value is set according to the @@ -3262,24 +3309,25 @@ Disable all optional CPU mitigations. This improves system performance, but it may also expose users to several CPU vulnerabilities. - Equivalent to: nopti [X86,PPC] - if nokaslr then kpti=0 [ARM64] - nospectre_v1 [X86,PPC] - nobp=0 [S390] - nospectre_v2 [X86,PPC,S390,ARM64] - spectre_v2_user=off [X86] - spec_store_bypass_disable=off [X86,PPC] - ssbd=force-off [ARM64] - nospectre_bhb [ARM64] + Equivalent to: if nokaslr then kpti=0 [ARM64] + gather_data_sampling=off [X86] + kvm.nx_huge_pages=off [X86] l1tf=off [X86] mds=off [X86] - tsx_async_abort=off [X86] - kvm.nx_huge_pages=off [X86] - srbds=off [X86,INTEL] + mmio_stale_data=off [X86] no_entry_flush [PPC] no_uaccess_flush [PPC] - mmio_stale_data=off [X86] + nobp=0 [S390] + nopti [X86,PPC] + nospectre_bhb [ARM64] + nospectre_v1 [X86,PPC] + nospectre_v2 [X86,PPC,S390,ARM64] retbleed=off [X86] + spec_store_bypass_disable=off [X86,PPC] + spectre_v2_user=off [X86] + srbds=off [X86,INTEL] + ssbd=force-off [ARM64] + tsx_async_abort=off [X86] Exceptions: This does not have any effect on @@ -3423,6 +3471,10 @@ [HW] Make the MicroTouch USB driver use raw coordinates ('y', default) or cooked coordinates ('n') + mtrr=debug [X86] + Enable printing debug information related to MTRR + registers at boot time. + mtrr_chunk_size=nn[KMG] [X86] used for mtrr cleanup. It is largest continuous chunk that could hold holes aka. UC entries. @@ -3702,8 +3754,8 @@ nohibernate [HIBERNATION] Disable hibernation and resume. - nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait - in do_idle() and not use the arch_cpu_idle() + nohlt [ARM,ARM64,MICROBLAZE,MIPS,PPC,SH] Forces the kernel to + busy wait in do_idle() and not use the arch_cpu_idle() implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP to be effective. This is useful on platforms where the sleep(SH) or wfi(ARM,ARM64) instructions do not work @@ -3838,10 +3890,10 @@ nosmp [SMP] Tells an SMP kernel to act as a UP kernel, and disable the IO APIC. legacy for "maxcpus=0". - nosmt [KNL,S390] Disable symmetric multithreading (SMT). + nosmt [KNL,MIPS,PPC,S390] Disable symmetric multithreading (SMT). Equivalent to smt=1. - [KNL,X86] Disable symmetric multithreading (SMT). + [KNL,X86,PPC] Disable symmetric multithreading (SMT). nosmt=force: Force disable SMT, cannot be undone via the sysfs control file. @@ -4022,20 +4074,6 @@ timeout < 0: reboot immediately Format: <timeout> - panic_print= Bitmask for printing system info when panic happens. - User can chose combination of the following bits: - bit 0: print all tasks info - bit 1: print system memory info - bit 2: print timer info - bit 3: print locks info if CONFIG_LOCKDEP is on - bit 4: print ftrace buffer - bit 5: print all printk messages in buffer - bit 6: print all CPUs backtrace (if available in the arch) - *Be aware* that this option may print a _lot_ of lines, - so there are risks of losing older messages in the log. - Use this option carefully, maybe worth to setup a - bigger log buffer with "log_buf_len" along with this. - panic_on_taint= Bitmask for conditionally calling panic() in add_taint() Format: <hex>[,nousertaint] Hexadecimal bitmask representing the set of TAINT flags @@ -4049,9 +4087,23 @@ extra details on the taint flags that users can pick to compose the bitmask to assign to panic_on_taint. - panic_on_warn panic() instead of WARN(). Useful to cause kdump + panic_on_warn=1 panic() instead of WARN(). Useful to cause kdump on a WARN(). + panic_print= Bitmask for printing system info when panic happens. + User can chose combination of the following bits: + bit 0: print all tasks info + bit 1: print system memory info + bit 2: print timer info + bit 3: print locks info if CONFIG_LOCKDEP is on + bit 4: print ftrace buffer + bit 5: print all printk messages in buffer + bit 6: print all CPUs backtrace (if available in the arch) + *Be aware* that this option may print a _lot_ of lines, + so there are risks of losing older messages in the log. + Use this option carefully, maybe worth to setup a + bigger log buffer with "log_buf_len" along with this. + parkbd.port= [HW] Parallel port number the keyboard adapter is connected to, default is 0. Format: <parport#> @@ -4171,7 +4223,7 @@ mode 0, bit 1 is for mode 1, and so on. Mode 0 only allowed by default. - pause_on_oops= + pause_on_oops=<int> Halt all CPUs after the first oops has been printed for the specified number of seconds. This is to be used if your oopses keep scrolling off the screen. @@ -4736,43 +4788,6 @@ the propagation of recent CPU-hotplug changes up the rcu_node combining tree. - rcutree.use_softirq= [KNL] - If set to zero, move all RCU_SOFTIRQ processing to - per-CPU rcuc kthreads. Defaults to a non-zero - value, meaning that RCU_SOFTIRQ is used by default. - Specify rcutree.use_softirq=0 to use rcuc kthreads. - - But note that CONFIG_PREEMPT_RT=y kernels disable - this kernel boot parameter, forcibly setting it - to zero. - - rcutree.rcu_fanout_exact= [KNL] - Disable autobalancing of the rcu_node combining - tree. This is used by rcutorture, and might - possibly be useful for architectures having high - cache-to-cache transfer latencies. - - rcutree.rcu_fanout_leaf= [KNL] - Change the number of CPUs assigned to each - leaf rcu_node structure. Useful for very - large systems, which will choose the value 64, - and for NUMA systems with large remote-access - latencies, which will choose a value aligned - with the appropriate hardware boundaries. - - rcutree.rcu_min_cached_objs= [KNL] - Minimum number of objects which are cached and - maintained per one CPU. Object size is equal - to PAGE_SIZE. The cache allows to reduce the - pressure to page allocator, also it makes the - whole algorithm to behave better in low memory - condition. - - rcutree.rcu_delay_page_cache_fill_msec= [KNL] - Set the page-cache refill delay (in milliseconds) - in response to low-memory conditions. The range - of permitted values is in the range 0:100000. - rcutree.jiffies_till_first_fqs= [KNL] Set delay from grace-period initialization to first attempt to force quiescent states. @@ -4811,21 +4826,6 @@ When RCU_NOCB_CPU is set, also adjust the priority of NOCB callback kthreads. - rcutree.rcu_divisor= [KNL] - Set the shift-right count to use to compute - the callback-invocation batch limit bl from - the number of callbacks queued on this CPU. - The result will be bounded below by the value of - the rcutree.blimit kernel parameter. Every bl - callbacks, the softirq handler will exit in - order to allow the CPU to do other work. - - Please note that this callback-invocation batch - limit applies only to non-offloaded callback - invocation. Offloaded callbacks are instead - invoked in the context of an rcuoc kthread, which - scheduler will preempt as it does any other task. - rcutree.nocb_nobypass_lim_per_jiffy= [KNL] On callback-offloaded (rcu_nocbs) CPUs, RCU reduces the lock contention that would @@ -4839,14 +4839,6 @@ the ->nocb_bypass queue. The definition of "too many" is supplied by this kernel boot parameter. - rcutree.rcu_nocb_gp_stride= [KNL] - Set the number of NOCB callback kthreads in - each group, which defaults to the square root - of the number of CPUs. Larger numbers reduce - the wakeup overhead on the global grace-period - kthread, but increases that same overhead on - each group's NOCB grace-period kthread. - rcutree.qhimark= [KNL] Set threshold of queued RCU callbacks beyond which batch limiting is disabled. @@ -4864,6 +4856,56 @@ on rcutree.qhimark at boot time and to zero to disable more aggressive help enlistment. + rcutree.rcu_delay_page_cache_fill_msec= [KNL] + Set the page-cache refill delay (in milliseconds) + in response to low-memory conditions. The range + of permitted values is in the range 0:100000. + + rcutree.rcu_divisor= [KNL] + Set the shift-right count to use to compute + the callback-invocation batch limit bl from + the number of callbacks queued on this CPU. + The result will be bounded below by the value of + the rcutree.blimit kernel parameter. Every bl + callbacks, the softirq handler will exit in + order to allow the CPU to do other work. + + Please note that this callback-invocation batch + limit applies only to non-offloaded callback + invocation. Offloaded callbacks are instead + invoked in the context of an rcuoc kthread, which + scheduler will preempt as it does any other task. + + rcutree.rcu_fanout_exact= [KNL] + Disable autobalancing of the rcu_node combining + tree. This is used by rcutorture, and might + possibly be useful for architectures having high + cache-to-cache transfer latencies. + + rcutree.rcu_fanout_leaf= [KNL] + Change the number of CPUs assigned to each + leaf rcu_node structure. Useful for very + large systems, which will choose the value 64, + and for NUMA systems with large remote-access + latencies, which will choose a value aligned + with the appropriate hardware boundaries. + + rcutree.rcu_min_cached_objs= [KNL] + Minimum number of objects which are cached and + maintained per one CPU. Object size is equal + to PAGE_SIZE. The cache allows to reduce the + pressure to page allocator, also it makes the + whole algorithm to behave better in low memory + condition. + + rcutree.rcu_nocb_gp_stride= [KNL] + Set the number of NOCB callback kthreads in + each group, which defaults to the square root + of the number of CPUs. Larger numbers reduce + the wakeup overhead on the global grace-period + kthread, but increases that same overhead on + each group's NOCB grace-period kthread. + rcutree.rcu_kick_kthreads= [KNL] Cause the grace-period kthread to get an extra wake_up() if it sleeps three times longer than @@ -4871,6 +4913,13 @@ This wake_up() will be accompanied by a WARN_ONCE() splat and an ftrace_dump(). + rcutree.rcu_resched_ns= [KNL] + Limit the time spend invoking a batch of RCU + callbacks to the specified number of nanoseconds. + By default, this limit is checked only once + every 32 callbacks in order to limit the pain + inflicted by local_clock() overhead. + rcutree.rcu_unlock_delay= [KNL] In CONFIG_RCU_STRICT_GRACE_PERIOD=y kernels, this specifies an rcu_read_unlock()-time delay @@ -4885,6 +4934,16 @@ rcu_node tree with an eye towards determining why a new grace period has not yet started. + rcutree.use_softirq= [KNL] + If set to zero, move all RCU_SOFTIRQ processing to + per-CPU rcuc kthreads. Defaults to a non-zero + value, meaning that RCU_SOFTIRQ is used by default. + Specify rcutree.use_softirq=0 to use rcuc kthreads. + + But note that CONFIG_PREEMPT_RT=y kernels disable + this kernel boot parameter, forcibly setting it + to zero. + rcuscale.gp_async= [KNL] Measure performance of asynchronous grace-period primitives such as call_rcu(). @@ -4906,6 +4965,15 @@ test until boot completes in order to avoid interference. + rcuscale.kfree_by_call_rcu= [KNL] + In kernels built with CONFIG_RCU_LAZY=y, test + call_rcu() instead of kfree_rcu(). + + rcuscale.kfree_mult= [KNL] + Instead of allocating an object of size kfree_obj, + allocate one of kfree_mult * sizeof(kfree_obj). + Defaults to 1. + rcuscale.kfree_rcu_test= [KNL] Set to measure performance of kfree_rcu() flooding. @@ -4931,6 +4999,12 @@ Number of loops doing rcuscale.kfree_alloc_num number of allocations and frees. + rcuscale.minruntime= [KNL] + Set the minimum test run time in seconds. This + does not affect the data-collection interval, + but instead allows better measurement of things + like CPU consumption. + rcuscale.nreaders= [KNL] Set number of RCU readers. The value -1 selects N, where N is the number of CPUs. A value @@ -4945,7 +5019,7 @@ the same as for rcuscale.nreaders. N, where N is the number of CPUs - rcuscale.perf_type= [KNL] + rcuscale.scale_type= [KNL] Specify the RCU implementation to test. rcuscale.shutdown= [KNL] @@ -4961,6 +5035,11 @@ in microseconds. The default of zero says no holdoff. + rcuscale.writer_holdoff_jiffies= [KNL] + Additional write-side holdoff between grace + periods, but in jiffies. The default of zero + says no holdoff. + rcutorture.fqs_duration= [KNL] Set duration of force_quiescent_state bursts in microseconds. @@ -5087,8 +5166,17 @@ rcutorture.stall_cpu_block= [KNL] Sleep while stalling if set. This will result - in warnings from preemptible RCU in addition - to any other stall-related activity. + in warnings from preemptible RCU in addition to + any other stall-related activity. Note that + in kernels built with CONFIG_PREEMPTION=n and + CONFIG_PREEMPT_COUNT=y, this parameter will + cause the CPU to pass through a quiescent state. + Given CONFIG_PREEMPTION=n, this will suppress + RCU CPU stall warnings, but will instead result + in scheduling-while-atomic splats. + + Use of this module parameter results in splats. + rcutorture.stall_cpu_holdoff= [KNL] Time to wait (s) after boot before inducing stall. @@ -5233,6 +5321,13 @@ number avoids disturbing real-time workloads, but lengthens grace periods. + rcupdate.rcu_task_lazy_lim= [KNL] + Number of callbacks on a given CPU that will + cancel laziness on that CPU. Use -1 to disable + cancellation of laziness, but be advised that + doing so increases the danger of OOM due to + callback flooding. + rcupdate.rcu_task_stall_info= [KNL] Set initial timeout in jiffies for RCU task stall informational messages, which give some indication @@ -5262,6 +5357,29 @@ A change in value does not take effect until the beginning of the next grace period. + rcupdate.rcu_tasks_lazy_ms= [KNL] + Set timeout in milliseconds RCU Tasks asynchronous + callback batching for call_rcu_tasks(). + A negative value will take the default. A value + of zero will disable batching. Batching is + always disabled for synchronize_rcu_tasks(). + + rcupdate.rcu_tasks_rude_lazy_ms= [KNL] + Set timeout in milliseconds RCU Tasks + Rude asynchronous callback batching for + call_rcu_tasks_rude(). A negative value + will take the default. A value of zero will + disable batching. Batching is always disabled + for synchronize_rcu_tasks_rude(). + + rcupdate.rcu_tasks_trace_lazy_ms= [KNL] + Set timeout in milliseconds RCU Tasks + Trace asynchronous callback batching for + call_rcu_tasks_trace(). A negative value + will take the default. A value of zero will + disable batching. Batching is always disabled + for synchronize_rcu_tasks_trace(). + rcupdate.rcu_self_test= [KNL] Run the RCU early boot self tests @@ -5437,6 +5555,13 @@ [KNL] Disable ring 3 MONITOR/MWAIT feature on supported CPUs. + riscv_isa_fallback [RISCV] + When CONFIG_RISCV_ISA_FALLBACK is not enabled, permit + falling back to detecting extension support by parsing + "riscv,isa" property on devicetree systems when the + replacement properties are not found. See the Kconfig + entry for RISCV_ISA_FALLBACK. + ro [KNL] Mount root device read-only on boot rodata= [KNL] @@ -5452,7 +5577,12 @@ port and the regular usb controller gets disabled. root= [KNL] Root filesystem - See name_to_dev_t comment in init/do_mounts.c. + Usually this a a block device specifier of some kind, + see the early_lookup_bdev comment in + block/early-lookup.c for details. + Alternatively this can be "ram" for the legacy initial + ramdisk, "nfs" and "cifs" for root on a network file + system, or "mtd" and "ubi" for mounting from raw flash. rootdelay= [KNL] Delay (in seconds) to pause before attempting to mount the root filesystem @@ -5465,6 +5595,10 @@ Useful for devices that are detected asynchronously (e.g. USB and MMC devices). + rootwait= [KNL] Maximum time (in seconds) to wait for root device + to show up before attempting to mount the root + filesystem. + rproc_mem=nn[KMG][@address] [KNL,ARM,CMA] Remoteproc physical memory block. Memory area to be used by remote processor image, @@ -5735,7 +5869,7 @@ 1: Fast pin select (default) 2: ATC IRMode - smt= [KNL,S390] Set the maximum number of threads (logical + smt= [KNL,MIPS,S390] Set the maximum number of threads (logical CPUs) to use per physical CPU on systems capable of symmetric multithreading (SMT). Will be capped to the actual hardware limit. @@ -5839,6 +5973,17 @@ Not specifying this option is equivalent to spectre_v2_user=auto. + spec_rstack_overflow= + [X86] Control RAS overflow mitigation on AMD Zen CPUs + + off - Disable mitigation + microcode - Enable microcode mitigation only + safe-ret - Enable sw-only safe RET mitigation (default) + ibpb - Enable mitigation by issuing IBPB on + kernel entry + ibpb-vmexit - Issue IBPB only on VMEXIT + (cloud-specific mitigation) + spec_store_bypass_disable= [HW] Control Speculative Store Bypass (SSB) Disable mitigation (Speculative Store Bypass vulnerability) @@ -6207,10 +6352,6 @@ -1: disable all critical trip points in all thermal zones <degrees C>: override all critical trip points - thermal.nocrt= [HW,ACPI] - Set to disable actions on ACPI thermal zone - critical and hot trip points. - thermal.off= [HW,ACPI] 1: disable ACPI thermal control @@ -6272,6 +6413,13 @@ This will guarantee that all the other pcrs are saved. + tpm_tis.interrupts= [HW,TPM] + Enable interrupts for the MMIO based physical layer + for the FIFO interface. By default it is set to false + (0). For more information about TPM hardware interfaces + defined by Trusted Computing Group (TCG) see + https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/ + tp_printk [FTRACE] Have the tracepoints sent to printk as well as the tracing ring buffer. This is useful for early boot up @@ -6563,9 +6711,15 @@ unknown_nmi_panic [X86] Cause panic on unknown NMI. + unwind_debug [X86-64] + Enable unwinder debug output. This can be + useful for debugging certain unwinder error + conditions, including corrupt stacks and + bad/missing unwinder metadata. + usbcore.authorized_default= [USB] Default USB device authorization: - (default -1 = authorized except for wireless USB, + (default -1 = authorized (same as 1), 0 = not authorized, 1 = authorized, 2 = authorized if device connected to internal port) @@ -6922,6 +7076,13 @@ disables both lockup detectors. Default is 10 seconds. + workqueue.unbound_cpus= + [KNL,SMP] Specify to constrain one or some CPUs + to use in unbound workqueues. + Format: <cpu-list> + By default, all online CPUs are available for + unbound workqueues. + workqueue.watchdog_thresh= If CONFIG_WQ_WATCHDOG is configured, workqueue can warn stall conditions and dump internal state to @@ -6931,14 +7092,17 @@ it can be updated at runtime by writing to the corresponding sysfs file. - workqueue.disable_numa - By default, all work items queued to unbound - workqueues are affine to the NUMA nodes they're - issued on, which results in better behavior in - general. If NUMA affinity needs to be disabled for - whatever reason, this option can be used. Note - that this also can be controlled per-workqueue for - workqueues visible under /sys/bus/workqueue/. + workqueue.cpu_intensive_thresh_us= + Per-cpu work items which run for longer than this + threshold are automatically considered CPU intensive + and excluded from concurrency management to prevent + them from noticeably delaying other per-cpu work + items. Default is 10000 (10ms). + + If CONFIG_WQ_CPU_INTENSIVE_REPORT is set, the kernel + will report the work functions which violate this + threshold repeatedly. They are likely good + candidates for using WQ_UNBOUND workqueues instead. workqueue.power_efficient Per-cpu workqueues are generally preferred because @@ -6955,6 +7119,18 @@ The default value of this parameter is determined by the config option CONFIG_WQ_POWER_EFFICIENT_DEFAULT. + workqueue.default_affinity_scope= + Select the default affinity scope to use for unbound + workqueues. Can be one of "cpu", "smt", "cache", + "numa" and "system". Default is "cache". For more + information, see the Affinity Scopes section in + Documentation/core-api/workqueue.rst. + + This can be changed after boot by writing to the + matching /sys/module/workqueue/parameters file. All + workqueues with the "default" affinity scope will be + updated accordignly. + workqueue.debug_force_rr_cpu Workqueue used to implicitly guarantee that work items queued without explicit CPU specified are put diff --git a/Documentation/admin-guide/media/qcom_camss.rst b/Documentation/admin-guide/media/qcom_camss.rst index a72e17d09cb7..8a8f3ff40105 100644 --- a/Documentation/admin-guide/media/qcom_camss.rst +++ b/Documentation/admin-guide/media/qcom_camss.rst @@ -18,7 +18,7 @@ The driver implements V4L2, Media controller and V4L2 subdev interfaces. Camera sensor using V4L2 subdev interface in the kernel is supported. The driver is implemented using as a reference the Qualcomm Camera Subsystem -driver for Android as found in Code Aurora [#f1]_ [#f2]_. +driver for Android as found in Code Linaro [#f1]_ [#f2]_. Qualcomm Camera Subsystem hardware @@ -181,5 +181,5 @@ Referenced 2018-06-22. References ---------- -.. [#f1] https://source.codeaurora.org/quic/la/kernel/msm-3.10/ -.. [#f2] https://source.codeaurora.org/quic/la/kernel/msm-3.18/ +.. [#f1] https://git.codelinaro.org/clo/la/kernel/msm-3.10/ +.. [#f2] https://git.codelinaro.org/clo/la/kernel/msm-3.18/ diff --git a/Documentation/admin-guide/media/rkisp1.rst b/Documentation/admin-guide/media/rkisp1.rst index ccf418713623..6f14d9561fa5 100644 --- a/Documentation/admin-guide/media/rkisp1.rst +++ b/Documentation/admin-guide/media/rkisp1.rst @@ -10,8 +10,8 @@ Introduction ============ This file documents the driver for the Rockchip ISP1 that is part of RK3288 -and RK3399 SoCs. The driver is located under drivers/staging/media/rkisp1 -and uses the Media-Controller API. +and RK3399 SoCs. The driver is located under drivers/media/platform/rockchip/ +rkisp1 and uses the Media-Controller API. Revisions ========= diff --git a/Documentation/admin-guide/mm/damon/start.rst b/Documentation/admin-guide/mm/damon/start.rst index 9f88afc734da..7aa0071ff1c3 100644 --- a/Documentation/admin-guide/mm/damon/start.rst +++ b/Documentation/admin-guide/mm/damon/start.rst @@ -119,9 +119,9 @@ set size has chronologically changed.:: Data Access Pattern Aware Memory Management =========================================== -Below three commands make every memory region of size >=4K that doesn't -accessed for >=60 seconds in your workload to be swapped out. :: +Below command makes every memory region of size >=4K that has not accessed for +>=60 seconds in your workload to be swapped out. :: - $ echo "#min-size max-size min-acc max-acc min-age max-age action" > test_scheme - $ echo "4K max 0 0 60s max pageout" >> test_scheme - $ damo schemes -c test_scheme <pid of your workload> + $ sudo damo schemes --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 9b823fec974d..8da1b7281827 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -10,9 +10,8 @@ DAMON provides below interfaces for different users. `This <https://github.com/awslabs/damo>`_ is for privileged people such as system administrators who want a just-working human-friendly interface. Using this, users can use the DAMON’s major features in a human-friendly way. - It may not be highly tuned for special cases, though. It supports both - virtual and physical address spaces monitoring. For more detail, please - refer to its `usage document + It may not be highly tuned for special cases, though. For more detail, + please refer to its `usage document <https://github.com/awslabs/damo/blob/next/USAGE.md>`_. - *sysfs interface.* :ref:`This <sysfs_interface>` is for privileged user space programmers who @@ -20,11 +19,7 @@ DAMON provides below interfaces for different users. features by reading from and writing to special sysfs files. Therefore, you can write and use your personalized DAMON sysfs wrapper programs that reads/writes the sysfs files instead of you. The `DAMON user space tool - <https://github.com/awslabs/damo>`_ is one example of such programs. It - supports both virtual and physical address spaces monitoring. Note that this - interface provides only simple :ref:`statistics <damos_stats>` for the - monitoring results. For detailed monitoring results, DAMON provides a - :ref:`tracepoint <tracepoint>`. + <https://github.com/awslabs/damo>`_ is one example of such programs. - *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 @@ -92,7 +87,7 @@ comma (","). :: │ │ │ │ │ │ │ filters/nr_filters │ │ │ │ │ │ │ │ 0/type,matching,memcg_id │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds - │ │ │ │ │ │ │ tried_regions/ + │ │ │ │ │ │ │ tried_regions/total_bytes │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age │ │ │ │ │ │ │ │ ... │ │ │ │ │ │ ... @@ -104,7 +99,7 @@ Root The root of the DAMON sysfs interface is ``<sysfs>/kernel/mm/damon/``, and it has one directory named ``admin``. The directory contains the files for -privileged user space programs' control of DAMON. User space tools or deamons +privileged user space programs' control of DAMON. User space tools or daemons having the root permission could use this directory. kdamonds/ @@ -132,14 +127,18 @@ in the state. Writing ``commit`` to the ``state`` file makes kdamond reads the user inputs in the sysfs files except ``state`` file again. Writing ``update_schemes_stats`` to ``state`` file updates the contents of stats files for each DAMON-based operation scheme of the kdamond. For details of the -stats, please refer to :ref:`stats section <sysfs_schemes_stats>`. Writing -``update_schemes_tried_regions`` to ``state`` file updates the DAMON-based -operation scheme action tried regions directory for each DAMON-based operation -scheme of the kdamond. Writing ``clear_schemes_tried_regions`` to ``state`` -file clears the DAMON-based operating scheme action tried regions directory for -each DAMON-based operation scheme of the kdamond. For details of the -DAMON-based operation scheme action tried regions directory, please refer to -:ref:tried_regions section <sysfs_schemes_tried_regions>`. +stats, please refer to :ref:`stats section <sysfs_schemes_stats>`. + +Writing ``update_schemes_tried_regions`` to ``state`` file updates the +DAMON-based operation scheme action tried regions directory for each +DAMON-based operation scheme of the kdamond. Writing +``update_schemes_tried_bytes`` to ``state`` file updates only +``.../tried_regions/total_bytes`` files. Writing +``clear_schemes_tried_regions`` to ``state`` file clears the DAMON-based +operating scheme action tried regions directory for each DAMON-based operation +scheme of the kdamond. For details of the DAMON-based operation scheme action +tried regions directory, please refer to :ref:`tried_regions section +<sysfs_schemes_tried_regions>`. If the state is ``on``, reading ``pid`` shows the pid of the kdamond thread. @@ -259,12 +258,9 @@ be equal or smaller than ``start`` of directory ``N+1``. contexts/<N>/schemes/ --------------------- -For usual DAMON-based data access aware memory management optimizations, users -would normally want the system to apply a memory management action to a memory -region of a specific access pattern. DAMON receives such formalized operation -schemes from the user and applies those to the target memory regions. Users -can get and set the schemes by reading from and writing to files under this -directory. +The directory for DAMON-based Operation Schemes (:ref:`DAMOS +<damon_design_damos>`). Users can get and set the schemes by reading from and +writing to files under this directory. In the beginning, this directory has only one file, ``nr_schemes``. Writing a number (``N``) to the file creates the number of child directories named ``0`` @@ -277,12 +273,12 @@ In each scheme directory, five directories (``access_pattern``, ``quotas``, ``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and one file (``action``) exist. -The ``action`` file is for setting and getting what action you want to apply to -memory regions having specific access pattern of the interest. The keywords -that can be written to and read from the file and their meaning are as below. +The ``action`` file is for setting and getting the scheme's :ref:`action +<damon_design_damos_action>`. The keywords that can be written to and read +from the file and their meaning are as below. Note that support of each action depends on the running DAMON operations set -`implementation <sysfs_contexts>`. +:ref:`implementation <sysfs_contexts>`. - ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED``. Supported by ``vaddr`` and ``fvaddr`` operations set. @@ -304,32 +300,21 @@ Note that support of each action depends on the running DAMON operations set schemes/<N>/access_pattern/ --------------------------- -The target access pattern of each DAMON-based operation scheme is constructed -with three ranges including the size of the region in bytes, number of -monitored accesses per aggregate interval, and number of aggregated intervals -for the age of the region. +The directory for the target access :ref:`pattern +<damon_design_damos_access_pattern>` of the given DAMON-based operation scheme. Under the ``access_pattern`` directory, three directories (``sz``, ``nr_accesses``, and ``age``) each having two files (``min`` and ``max``) exist. You can set and get the access pattern for the given scheme by writing to and reading from the ``min`` and ``max`` files under ``sz``, -``nr_accesses``, and ``age`` directories, respectively. +``nr_accesses``, and ``age`` directories, respectively. Note that the ``min`` +and the ``max`` form a closed interval. schemes/<N>/quotas/ ------------------- -Optimal ``target access pattern`` for each ``action`` is workload dependent, so -not easy to find. Worse yet, setting a scheme of some action too aggressive -can cause severe overhead. To avoid such overhead, users can limit time and -size quota for each scheme. In detail, users can ask DAMON to try to use only -up to specific time (``time quota``) for applying the action, and to apply the -action to only up to specific amount (``size quota``) of memory regions having -the target access pattern within a given time interval (``reset interval``). - -When the quota limit is expected to be exceeded, DAMON prioritizes found memory -regions of the ``target access pattern`` based on their size, access frequency, -and age. For personalized prioritization, users can set the weights for the -three properties. +The directory for the :ref:`quotas <damon_design_damos_quotas>` of the given +DAMON-based operation scheme. Under ``quotas`` directory, three files (``ms``, ``bytes``, ``reset_interval_ms``) and one directory (``weights``) having three files @@ -337,23 +322,26 @@ Under ``quotas`` directory, three files (``ms``, ``bytes``, You can set the ``time quota`` in milliseconds, ``size quota`` in bytes, and ``reset interval`` in milliseconds by writing the values to the three files, -respectively. You can also set the prioritization weights for size, access -frequency, and age in per-thousand unit by writing the values to the three -files under the ``weights`` directory. +respectively. Then, DAMON tries to use only up to ``time quota`` milliseconds +for applying the ``action`` to memory regions of the ``access_pattern``, and to +apply the action to only up to ``bytes`` bytes of memory regions within the +``reset_interval_ms``. Setting both ``ms`` and ``bytes`` zero disables the +quota limits. + +You can also set the :ref:`prioritization weights +<damon_design_damos_quotas_prioritization>` for size, access frequency, and age +in per-thousand unit by writing the values to the three files under the +``weights`` directory. schemes/<N>/watermarks/ ----------------------- -To allow easy activation and deactivation of each scheme based on system -status, DAMON provides a feature called watermarks. The feature receives five -values called ``metric``, ``interval``, ``high``, ``mid``, and ``low``. The -``metric`` is the system metric such as free memory ratio that can be measured. -If the metric value of the system is higher than the value in ``high`` or lower -than ``low`` at the memoent, the scheme is deactivated. If the value is lower -than ``mid``, the scheme is activated. +The directory for the :ref:`watermarks <damon_design_damos_watermarks>` of the +given DAMON-based operation scheme. Under the watermarks directory, five files (``metric``, ``interval_us``, -``high``, ``mid``, and ``low``) for setting each value exist. You can set and +``high``, ``mid``, and ``low``) for setting the metric, the time interval +between check of the metric, and the three watermarks exist. You can set and get the five values by writing to the files, respectively. Keywords and meanings of those that can be written to the ``metric`` file are @@ -367,27 +355,29 @@ The ``interval`` should written in microseconds unit. schemes/<N>/filters/ -------------------- -Users could know something more than the kernel for specific types of memory. -In the case, users could do their own management for the memory and hence -doesn't want DAMOS bothers that. Users could limit DAMOS by setting the access -pattern of the scheme and/or the monitoring regions for the purpose, but that -can be inefficient in some cases. In such cases, users could set non-access -pattern driven filters using files in this directory. +The directory for the :ref:`filters <damon_design_damos_filters>` of the given +DAMON-based operation scheme. In the beginning, this directory has only one file, ``nr_filters``. Writing a 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 three files, namely ``type``, ``matcing``, and -``memcg_path``. You can write one of two special keywords, ``anon`` for -anonymous pages, or ``memcg`` for specific memory cgroup 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. 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 six files, namely ``type``, ``matcing``, +``memcg_path``, ``addr_start``, ``addr_end``, and ``target_idx``. To ``type`` +file, you can write one of four special keywords: ``anon`` for anonymous pages, +``memcg`` for specific memory cgroup, ``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. For example, below restricts a DAMOS action to be applied to only non-anonymous pages of all memory cgroups except ``/having_care_already``.:: @@ -401,8 +391,14 @@ pages of all memory cgroups except ``/having_care_already``.:: echo /having_care_already > 1/memcg_path echo N > 1/matching -Note that filters are currently supported only when ``paddr`` -`implementation <sysfs_contexts>` is being used. +Note that ``anon`` and ``memcg`` filters are currently supported only when +``paddr`` `implementation <sysfs_contexts>` 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>`. .. _sysfs_schemes_stats: @@ -417,7 +413,7 @@ be used for online analysis or tuning of the schemes. 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 updte the content of the files for the +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. @@ -426,19 +422,31 @@ stats by writing a special keyword, ``update_schemes_stats`` to the relevant schemes/<N>/tried_regions/ -------------------------- +This directory initially has one file, ``total_bytes``. + When a special keyword, ``update_schemes_tried_regions``, is written to the -relevant ``kdamonds/<N>/state`` file, DAMON creates directories named integer -starting from ``0`` under this directory. Each directory contains files -exposing detailed information about each of the memory region that the -corresponding scheme's ``action`` has tried to be applied under this directory, -during next :ref:`aggregation interval <sysfs_monitoring_attrs>`. The -information includes address range, ``nr_accesses``, , and ``age`` of the -region. +relevant ``kdamonds/<N>/state`` file, DAMON updates the ``total_bytes`` file so +that reading it returns the total size of the scheme tried regions, and creates +directories named integer starting from ``0`` under this directory. Each +directory contains files exposing detailed information about each of the memory +region that the corresponding scheme's ``action`` has tried to be applied under +this directory, during next :ref:`aggregation interval +<sysfs_monitoring_attrs>`. The information includes address range, +``nr_accesses``, and ``age`` of the region. + +Writing ``update_schemes_tried_bytes`` to the relevant ``kdamonds/<N>/state`` +file will only update the ``total_bytes`` file, and will not create the +subdirectories. The directories will be removed when another special keyword, ``clear_schemes_tried_regions``, is written to the relevant ``kdamonds/<N>/state`` file. +The expected usage of this directory is investigations of schemes' behaviors, +and query-like efficient data access monitoring results retrievals. For the +latter use case, in particular, users can set the ``action`` as ``stat`` and +set the ``access pattern`` as their interested pattern that they want to query. + tried_regions/<N>/ ------------------ @@ -600,15 +608,10 @@ update. Schemes ------- -For usual DAMON-based data access aware memory management optimizations, users -would simply want the system to apply a memory management action to a memory -region of a specific access pattern. DAMON receives such formalized operation -schemes from the user and applies those to the target processes. - -Users can get and set the schemes 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:: +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> @@ -617,8 +620,9 @@ You can disable schemes by simply writing an empty string to the file. Target Access Pattern ~~~~~~~~~~~~~~~~~~~~~ -The ``<target access pattern>`` is constructed with three ranges in below -form:: +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 @@ -631,9 +635,9 @@ closed interval. Action ~~~~~~ -The ``<action>`` is a predefined integer for memory management actions, which -DAMON will apply to the regions having the target access pattern. The -supported numbers and their meanings are as below. +The ``<action>`` is a predefined integer for memory management :ref:`actions +<damon_design_damos_action>`. The supported numbers and their meanings are as +below. - 0: Call ``madvise()`` for the region with ``MADV_WILLNEED``. Ignored if ``target`` is ``paddr``. @@ -649,10 +653,8 @@ supported numbers and their meanings are as below. Quota ~~~~~ -Optimal ``target access pattern`` for each ``action`` is workload dependent, so -not easy to find. Worse yet, setting a scheme of some action too aggressive -can cause severe overhead. To avoid such overhead, users can limit time and -size quota for the scheme via the ``<quota>`` in below form:: +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> @@ -662,19 +664,17 @@ the action to memory regions of the ``target access pattern`` within the ``<sz>`` bytes of memory regions within the ``<reset interval>``. Setting both ``<ms>`` and ``<sz>`` zero disables the quota limits. -When the quota limit is expected to be exceeded, DAMON prioritizes found memory -regions of the ``target access pattern`` based on their size, access frequency, -and age. For personalized prioritization, users can set the weights for the -three properties in ``<priority weights>`` in below form:: +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 ~~~~~~~~~~ -Some schemes would need to run based on current value of the system's specific -metrics like free memory ratio. For such cases, users can specify watermarks -for the condition.:: +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> @@ -797,10 +797,12 @@ root directory only. Tracepoint for Monitoring Results ================================= -DAMON provides the monitoring results via a tracepoint, -``damon:damon_aggregated``. While the monitoring is turned on, you could -record the tracepoint events and show results using tracepoint supporting tools -like ``perf``. For example:: +Users can get the monitoring results via the :ref:`tried_regions +<sysfs_schemes_tried_regions>` or a tracepoint, ``damon:damon_aggregated``. +While the tried regions directory is useful for getting a snapshot, the +tracepoint is useful for getting a full record of the results. While the +monitoring is turned on, you could record the tracepoint events and show +results using tracepoint supporting tools like ``perf``. For example:: # echo on > monitor_on # perf record -e damon:damon_aggregated & diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst index 7626392fe82c..776f244bdae4 100644 --- a/Documentation/admin-guide/mm/ksm.rst +++ b/Documentation/admin-guide/mm/ksm.rst @@ -159,6 +159,8 @@ The effectiveness of KSM and MADV_MERGEABLE is shown in ``/sys/kernel/mm/ksm/``: general_profit how effective is KSM. The calculation is explained below. +pages_scanned + how many pages are being scanned for ksm pages_shared how many shared pages are being used pages_sharing @@ -173,6 +175,13 @@ stable_node_chains the number of KSM pages that hit the ``max_page_sharing`` limit stable_node_dups number of duplicated KSM pages +ksm_zero_pages + how many zero pages that are still mapped into processes were mapped by + KSM when deduplicating. + +When ``use_zero_pages`` is/was enabled, the sum of ``pages_sharing`` + +``ksm_zero_pages`` represents the actual number of pages saved by KSM. +if ``use_zero_pages`` has never been enabled, ``ksm_zero_pages`` is 0. A high ratio of ``pages_sharing`` to ``pages_shared`` indicates good sharing, but a high ratio of ``pages_unshared`` to ``pages_sharing`` @@ -196,21 +205,25 @@ several times, which are unprofitable memory consumed. 1) How to determine whether KSM save memory or consume memory in system-wide range? Here is a simple approximate calculation for reference:: - general_profit =~ pages_sharing * sizeof(page) - (all_rmap_items) * + general_profit =~ ksm_saved_pages * sizeof(page) - (all_rmap_items) * sizeof(rmap_item); - where all_rmap_items can be easily obtained by summing ``pages_sharing``, - ``pages_shared``, ``pages_unshared`` and ``pages_volatile``. + where ksm_saved_pages equals to the sum of ``pages_sharing`` + + ``ksm_zero_pages`` of the system, and all_rmap_items can be easily + obtained by summing ``pages_sharing``, ``pages_shared``, ``pages_unshared`` + and ``pages_volatile``. 2) The KSM profit inner a single process can be similarly obtained by the following approximate calculation:: - process_profit =~ ksm_merging_pages * sizeof(page) - + process_profit =~ ksm_saved_pages * sizeof(page) - ksm_rmap_items * sizeof(rmap_item). - where ksm_merging_pages is shown under the directory ``/proc/<pid>/``, - and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``. The process profit - is also shown in ``/proc/<pid>/ksm_stat`` as ksm_process_profit. + where ksm_saved_pages equals to the sum of ``ksm_merging_pages`` and + ``ksm_zero_pages``, both of which are shown under the directory + ``/proc/<pid>/ksm_stat``, and ksm_rmap_items is also shown in + ``/proc/<pid>/ksm_stat``. The process profit is also shown in + ``/proc/<pid>/ksm_stat`` as ksm_process_profit. From the perspective of application, a high ratio of ``ksm_rmap_items`` to ``ksm_merging_pages`` means a bad madvise-applied policy, so developers or diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index 1b02fe5807cc..cfe034cf1e87 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -291,6 +291,14 @@ The following files are currently defined: Availability depends on the CONFIG_ARCH_MEMORY_PROBE kernel configuration option. ``uevent`` read-write: generic udev file for device subsystems. +``crash_hotplug`` read-only: when changes to the system memory map + occur due to hot un/plug of memory, this file contains + '1' if the kernel updates the kdump capture kernel memory + map itself (via elfcorehdr), or '0' if userspace must update + the kdump capture kernel memory map. + + Availability depends on the CONFIG_MEMORY_HOTPLUG kernel + configuration option. ====================== ========================================================= .. note:: @@ -433,6 +441,18 @@ The following module parameters are currently defined: memory in a way that huge pages in bigger granularity cannot be formed on hotplugged memory. + + With value "force" it could result in memory + wastage due to memmap size limitations. For + example, if the memmap for a memory block + requires 1 MiB, but the pageblock size is 2 + MiB, 1 MiB of hotplugged memory will be wasted. + Note that there are still cases where the + feature cannot be enforced: for example, if the + memmap is smaller than a single page, or if the + architecture does not support the forced mode + in all configurations. + ``online_policy`` read-write: Set the basic policy used for automatic zone selection when onlining memory blocks without specifying a target zone. @@ -669,7 +689,7 @@ when still encountering permanently unmovable pages within ZONE_MOVABLE (-> BUG), memory offlining will keep retrying until it eventually succeeds. When offlining is triggered from user space, the offlining context can be -terminated by sending a fatal signal. A timeout based offlining can easily be +terminated by sending a signal. A timeout based offlining can easily be implemented via:: % timeout $TIMEOUT offline_block | failure_handling diff --git a/Documentation/admin-guide/mm/numa_memory_policy.rst b/Documentation/admin-guide/mm/numa_memory_policy.rst index 46515ad2337f..eca38fa81e0f 100644 --- a/Documentation/admin-guide/mm/numa_memory_policy.rst +++ b/Documentation/admin-guide/mm/numa_memory_policy.rst @@ -109,7 +109,7 @@ VMA Policy * A task may install a new VMA policy on a sub-range of a previously mmap()ed region. When this happens, Linux splits the existing virtual memory area into 2 or 3 VMAs, each with - it's own policy. + its own policy. * By default, VMA policy applies only to pages allocated after the policy is installed. Any pages already faulted into the diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst index 7c304e432205..4349a8c2b978 100644 --- a/Documentation/admin-guide/mm/userfaultfd.rst +++ b/Documentation/admin-guide/mm/userfaultfd.rst @@ -244,6 +244,21 @@ write-protected (so future writes will also result in a WP fault). These ioctls support a mode flag (``UFFDIO_COPY_MODE_WP`` or ``UFFDIO_CONTINUE_MODE_WP`` respectively) to configure the mapping this way. +Memory Poisioning Emulation +--------------------------- + +In response to a fault (either missing or minor), an action userspace can +take to "resolve" it is to issue a ``UFFDIO_POISON``. This will cause any +future faulters to either get a SIGBUS, or in KVM's case the guest will +receive an MCE as if there were hardware memory poisoning. + +This is used to emulate hardware memory poisoning. Imagine a VM running on a +machine which experiences a real hardware memory error. Later, we live migrate +the VM to another physical machine. Since we want the migration to be +transparent to the guest, we want that same address range to act as if it was +still poisoned, even though it's on a new physical host which ostensibly +doesn't have a memory error in the exact same spot. + QEMU/KVM ======== diff --git a/Documentation/admin-guide/mm/zswap.rst b/Documentation/admin-guide/mm/zswap.rst index c5c2c7dbb155..45b98390e938 100644 --- a/Documentation/admin-guide/mm/zswap.rst +++ b/Documentation/admin-guide/mm/zswap.rst @@ -49,7 +49,7 @@ compressed pool. Design ====== -Zswap receives pages for compression through the Frontswap API and is able to +Zswap receives pages for compression from the swap subsystem and is able to evict pages from its own compressed pool on an LRU basis and write them back to the backing swap device in the case that the compressed pool is full. @@ -70,19 +70,19 @@ means the compression ratio will always be 2:1 or worse (because of half-full zbud pages). The zsmalloc type zpool has a more complex compressed page storage method, and it can achieve greater storage densities. -When a swap page is passed from frontswap to zswap, zswap maintains a mapping +When a swap page is passed from swapout to zswap, zswap maintains a mapping of the swap entry, a combination of the swap type and swap offset, to the zpool handle that references that compressed swap page. This mapping is achieved with a red-black tree per swap type. The swap offset is the search key for the tree nodes. -During a page fault on a PTE that is a swap entry, frontswap calls the zswap -load function to decompress the page into the page allocated by the page fault -handler. +During a page fault on a PTE that is a swap entry, the swapin code calls the +zswap load function to decompress the page into the page allocated by the page +fault handler. Once there are no PTEs referencing a swap page stored in zswap (i.e. the count -in the swap_map goes to 0) the swap code calls the zswap invalidate function, -via frontswap, to free the compressed entry. +in the swap_map goes to 0) the swap code calls the zswap invalidate function +to free the compressed entry. Zswap seeks to be simple in its policies. Sysfs attributes allow for one user controlled policy: diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 7d7c7c8a545c..2898b2703297 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -266,7 +266,7 @@ for which it has a public key. Otherwise, it will also load modules that are unsigned. Any module for which the kernel has a key, but which proves to have a signature mismatch will not be permitted to load. -Any module that has an unparseable signature will be rejected. +Any module that has an unparsable signature will be rejected. ========================================= diff --git a/Documentation/admin-guide/perf/cxl.rst b/Documentation/admin-guide/perf/cxl.rst new file mode 100644 index 000000000000..9233ea0d0b10 --- /dev/null +++ b/Documentation/admin-guide/perf/cxl.rst @@ -0,0 +1,68 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +CXL Performance Monitoring Unit (CPMU) +====================================== + +The CXL rev 3.0 specification provides a definition of CXL Performance +Monitoring Unit in section 13.2: Performance Monitoring. + +CXL components (e.g. Root Port, Switch Upstream Port, End Point) may have +any number of CPMU instances. CPMU capabilities are fully discoverable from +the devices. The specification provides event definitions for all CXL protocol +message types and a set of additional events for things commonly counted on +CXL devices (e.g. DRAM events). + +CPMU driver +=========== + +The CPMU driver registers a perf PMU with the name pmu_mem<X>.<Y> on the CXL bus +representing the Yth CPMU for memX. + + /sys/bus/cxl/device/pmu_mem<X>.<Y> + +The associated PMU is registered as + + /sys/bus/event_sources/devices/cxl_pmu_mem<X>.<Y> + +In common with other CXL bus devices, the id has no specific meaning and the +relationship to specific CXL device should be established via the device parent +of the device on the CXL bus. + +PMU driver provides description of available events and filter options in sysfs. + +The "format" directory describes all formats of the config (event vendor id, +group id and mask) config1 (threshold, filter enables) and config2 (filter +parameters) fields of the perf_event_attr structure. The "events" directory +describes all documented events show in perf list. + +The events shown in perf list are the most fine grained events with a single +bit of the event mask set. More general events may be enable by setting +multiple mask bits in config. For example, all Device to Host Read Requests +may be captured on a single counter by setting the bits for all of + +* d2h_req_rdcurr +* d2h_req_rdown +* d2h_req_rdshared +* d2h_req_rdany +* d2h_req_rdownnodata + +Example of usage:: + + $#perf list + cxl_pmu_mem0.0/clock_ticks/ [Kernel PMU event] + cxl_pmu_mem0.0/d2h_req_rdshared/ [Kernel PMU event] + cxl_pmu_mem0.0/h2d_req_snpcur/ [Kernel PMU event] + cxl_pmu_mem0.0/h2d_req_snpdata/ [Kernel PMU event] + cxl_pmu_mem0.0/h2d_req_snpinv/ [Kernel PMU event] + ----------------------------------------------------------- + + $# perf stat -a -e cxl_pmu_mem0.0/clock_ticks/ -e cxl_pmu_mem0.0/d2h_req_rdshared/ + +Vendor specific events may also be available and if so can be used via + + $# perf stat -a -e cxl_pmu_mem0.0/vid=VID,gid=GID,mask=MASK/ + +The driver does not support sampling so "perf record" is unsupported. +It only supports system-wide counting so attaching to a task is +unsupported. diff --git a/Documentation/admin-guide/perf/hisi-pmu.rst b/Documentation/admin-guide/perf/hisi-pmu.rst index 546979360513..e0174d20809a 100644 --- a/Documentation/admin-guide/perf/hisi-pmu.rst +++ b/Documentation/admin-guide/perf/hisi-pmu.rst @@ -56,14 +56,14 @@ Example usage of perf:: For HiSilicon uncore PMU v2 whose identifier is 0x30, the topology is the same as PMU v1, but some new functions are added to the hardware. -(a) L3C PMU supports filtering by core/thread within the cluster which can be +1. L3C PMU supports filtering by core/thread within the cluster which can be specified as a bitmap:: $# perf stat -a -e hisi_sccl3_l3c0/config=0x02,tt_core=0x3/ sleep 5 This will only count the operations from core/thread 0 and 1 in this cluster. -(b) Tracetag allow the user to chose to count only read, write or atomic +2. Tracetag allow the user to chose to count only read, write or atomic operations via the tt_req parameeter in perf. The default value counts all operations. tt_req is 3bits, 3'b100 represents read operations, 3'b101 represents write operations, 3'b110 represents atomic store operations and @@ -73,14 +73,16 @@ represents write operations, 3'b110 represents atomic store operations and This will only count the read operations in this cluster. -(c) Datasrc allows the user to check where the data comes from. It is 5 bits. +3. Datasrc allows the user to check where the data comes from. It is 5 bits. Some important codes are as follows: -5'b00001: comes from L3C in this die; -5'b01000: comes from L3C in the cross-die; -5'b01001: comes from L3C which is in another socket; -5'b01110: comes from the local DDR; -5'b01111: comes from the cross-die DDR; -5'b10000: comes from cross-socket DDR; + +- 5'b00001: comes from L3C in this die; +- 5'b01000: comes from L3C in the cross-die; +- 5'b01001: comes from L3C which is in another socket; +- 5'b01110: comes from the local DDR; +- 5'b01111: comes from the cross-die DDR; +- 5'b10000: comes from cross-socket DDR; + etc, it is mainly helpful to find that the data source is nearest from the CPU cores. If datasrc_cfg is used in the multi-chips, the datasrc_skt shall be configured in perf command:: @@ -88,15 +90,25 @@ configured in perf command:: $# perf stat -a -e hisi_sccl3_l3c0/config=0xb9,datasrc_cfg=0xE/, hisi_sccl3_l3c0/config=0xb9,datasrc_cfg=0xF/ sleep 5 -(d)Some HiSilicon SoCs encapsulate multiple CPU and IO dies. Each CPU die +4. Some HiSilicon SoCs encapsulate multiple CPU and IO dies. Each CPU die contains several Compute Clusters (CCLs). The I/O dies are called Super I/O clusters (SICL) containing multiple I/O clusters (ICLs). Each CCL/ICL in the SoC has a unique ID. Each ID is 11bits, include a 6-bit SCCL-ID and 5-bit CCL/ICL-ID. For I/O die, the ICL-ID is followed by: -5'b00000: I/O_MGMT_ICL; -5'b00001: Network_ICL; -5'b00011: HAC_ICL; -5'b10000: PCIe_ICL; + +- 5'b00000: I/O_MGMT_ICL; +- 5'b00001: Network_ICL; +- 5'b00011: HAC_ICL; +- 5'b10000: PCIe_ICL; + +5. uring_channel: UC PMU events 0x47~0x59 supports filtering by tx request +uring channel. It is 2 bits. Some important codes are as follows: + +- 2'b11: count the events which sent to the uring_ext (MATA) channel; +- 2'b01: is the same as 2'b11; +- 2'b10: count the events which sent to the uring (non-MATA) channel; +- 2'b00: default value, count the events which sent to the both uring and + uring_ext channel; Users could configure IDs to count data come from specific CCL/ICL, by setting srcid_cmd & srcid_msk, and data desitined for specific CCL/ICL by setting diff --git a/Documentation/admin-guide/perf/index.rst b/Documentation/admin-guide/perf/index.rst index 9de64a40adab..f60be04e4e33 100644 --- a/Documentation/admin-guide/perf/index.rst +++ b/Documentation/admin-guide/perf/index.rst @@ -21,3 +21,4 @@ Performance monitor support alibaba_pmu nvidia-pmu meson-ddr-pmu + cxl diff --git a/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst index 09169d935835..5ab3440e6cee 100644 --- a/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst +++ b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst @@ -5,7 +5,7 @@ Intel Uncore Frequency Scaling ============================== -:Copyright: |copy| 2022 Intel Corporation +:Copyright: |copy| 2022-2023 Intel Corporation :Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> @@ -58,3 +58,58 @@ Each package_*_die_* contains the following attributes: ``current_freq_khz`` This attribute is used to get the current uncore frequency. + +SoCs with TPMI (Topology Aware Register and PM Capsule Interface) +----------------------------------------------------------------- + +An SoC can contain multiple power domains with individual or collection +of mesh partitions. This partition is called fabric cluster. + +Certain type of meshes will need to run at the same frequency, they will +be placed in the same fabric cluster. Benefit of fabric cluster is that it +offers a scalable mechanism to deal with partitioned fabrics in a SoC. + +The current sysfs interface supports controls at package and die level. +This interface is not enough to support more granular control at +fabric cluster level. + +SoCs with the support of TPMI (Topology Aware Register and PM Capsule +Interface), can have multiple power domains. Each power domain can +contain one or more fabric clusters. + +To represent controls at fabric cluster level in addition to the +controls at package and die level (like systems without TPMI +support), sysfs is enhanced. This granular interface is presented in the +sysfs with directories names prefixed with "uncore". For example: +uncore00, uncore01 etc. + +The scope of control is specified by attributes "package_id", "domain_id" +and "fabric_cluster_id" in the directory. + +Attributes in each directory: + +``domain_id`` + This attribute is used to get the power domain id of this instance. + +``fabric_cluster_id`` + This attribute is used to get the fabric cluster id of this instance. + +``package_id`` + This attribute is used to get the package id of this instance. + +The other attributes are same as presented at package_*_die_* level. + +In most of current use cases, the "max_freq_khz" and "min_freq_khz" +is updated at "package_*_die_*" level. This model will be still supported +with the following approach: + +When user uses controls at "package_*_die_*" level, then every fabric +cluster is affected in that package and die. For example: user changes +"max_freq_khz" in the package_00_die_00, then "max_freq_khz" for uncore* +directory with the same package id will be updated. In this case user can +still update "max_freq_khz" at each uncore* level, which is more restrictive. +Similarly, user can update "min_freq_khz" at "package_*_die_*" level +to apply at each uncore* level. + +Support for "current_freq_khz" is available only at each fabric cluster +level (i.e., in uncore* directory). diff --git a/Documentation/admin-guide/serial-console.rst b/Documentation/admin-guide/serial-console.rst index 8c8b94e54e26..a3dfc2c66e01 100644 --- a/Documentation/admin-guide/serial-console.rst +++ b/Documentation/admin-guide/serial-console.rst @@ -59,7 +59,7 @@ times. In this case, there are the following two rules: the hardware is not available. The result might be surprising. For example, the following two command -lines have the same result: +lines have the same result:: console=ttyS1,9600 console=tty0 console=tty1 console=tty0 console=ttyS1,9600 console=tty1 diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index d85d90f5d000..8019103aac10 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -941,16 +941,35 @@ enabled, otherwise writing to this file will return ``-EBUSY``. The default value is 8. -perf_user_access (arm64 only) -================================= +perf_user_access (arm64 and riscv only) +======================================= + +Controls user space access for reading perf event counters. -Controls user space access for reading perf event counters. When set to 1, -user space can read performance monitor counter registers directly. +arm64 +===== The default value is 0 (access disabled). -See Documentation/arm64/perf.rst for more information. +When set to 1, user space can read performance monitor counter registers +directly. + +See Documentation/arch/arm64/perf.rst for more information. + +riscv +===== + +When set to 0, user space access is disabled. + +The default value is 1, user space can read performance monitor counter +registers through perf, any direct access without perf intervention will trigger +an illegal instruction. + +When set to 2, which enables legacy mode (user space has direct access to cycle +and insret CSRs only). Note that this legacy value is deprecated and will be +removed once all user space applications are fixed. +Note that the time CSR is always directly accessible to all modes. pid_max ======= diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst index 466c560b0c30..4877563241f3 100644 --- a/Documentation/admin-guide/sysctl/net.rst +++ b/Documentation/admin-guide/sysctl/net.rst @@ -386,8 +386,8 @@ Default : 0 (for compatibility reasons) txrehash -------- -Controls default hash rethink behaviour on listening socket when SO_TXREHASH -option is set to SOCK_TXREHASH_DEFAULT (i. e. not overridden by setsockopt). +Controls default hash rethink behaviour on socket when SO_TXREHASH option is set +to SOCK_TXREHASH_DEFAULT (i. e. not overridden by setsockopt). If set to 1 (default), hash rethink is performed on listening socket. If set to 0, hash rethink is not performed. diff --git a/Documentation/admin-guide/xfs.rst b/Documentation/admin-guide/xfs.rst index 3a9c041d7f6c..b67772cf36d6 100644 --- a/Documentation/admin-guide/xfs.rst +++ b/Documentation/admin-guide/xfs.rst @@ -192,7 +192,7 @@ When mounting an XFS filesystem, the following options are accepted. are any integer multiple of a valid ``sunit`` value. Typically the only time these mount options are necessary if - after an underlying RAID device has had it's geometry + after an underlying RAID device has had its geometry modified, such as adding a new disk to a RAID5 lun and reshaping it. diff --git a/Documentation/arm/arm.rst b/Documentation/arch/arm/arm.rst index 99d660fdf73f..7b41b89dd9bd 100644 --- a/Documentation/arm/arm.rst +++ b/Documentation/arch/arm/arm.rst @@ -141,7 +141,7 @@ ST506 hard drives `*configure` harddrive set to 2). I've got an internal 20MB and a great big external 5.25" FH 64MB drive (who could ever want more :-) ). - I've just got 240K/s off it (a dd with bs=128k); thats about half of what + I've just got 240K/s off it (a dd with bs=128k); that's about half of what RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting last week :-) diff --git a/Documentation/arm/booting.rst b/Documentation/arch/arm/booting.rst index 5974e37b3d20..5974e37b3d20 100644 --- a/Documentation/arm/booting.rst +++ b/Documentation/arch/arm/booting.rst diff --git a/Documentation/arm/cluster-pm-race-avoidance.rst b/Documentation/arch/arm/cluster-pm-race-avoidance.rst index aa58603d3f28..aa58603d3f28 100644 --- a/Documentation/arm/cluster-pm-race-avoidance.rst +++ b/Documentation/arch/arm/cluster-pm-race-avoidance.rst diff --git a/Documentation/arm/features.rst b/Documentation/arch/arm/features.rst index 7414ec03dd15..7414ec03dd15 100644 --- a/Documentation/arm/features.rst +++ b/Documentation/arch/arm/features.rst diff --git a/Documentation/arm/firmware.rst b/Documentation/arch/arm/firmware.rst index efd844baec1d..efd844baec1d 100644 --- a/Documentation/arm/firmware.rst +++ b/Documentation/arch/arm/firmware.rst diff --git a/Documentation/arm/google/chromebook-boot-flow.rst b/Documentation/arch/arm/google/chromebook-boot-flow.rst index 36da77684bba..36da77684bba 100644 --- a/Documentation/arm/google/chromebook-boot-flow.rst +++ b/Documentation/arch/arm/google/chromebook-boot-flow.rst diff --git a/Documentation/arm/index.rst b/Documentation/arch/arm/index.rst index fd43502ae924..fd43502ae924 100644 --- a/Documentation/arm/index.rst +++ b/Documentation/arch/arm/index.rst diff --git a/Documentation/arm/interrupts.rst b/Documentation/arch/arm/interrupts.rst index 2ae70e0e9732..2ae70e0e9732 100644 --- a/Documentation/arm/interrupts.rst +++ b/Documentation/arch/arm/interrupts.rst diff --git a/Documentation/arm/ixp4xx.rst b/Documentation/arch/arm/ixp4xx.rst index a57235616294..17aafc610908 100644 --- a/Documentation/arm/ixp4xx.rst +++ b/Documentation/arch/arm/ixp4xx.rst @@ -78,9 +78,9 @@ IXP4xx provides two methods of accessing PCI memory space: 1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB). To access PCI via this space, we simply ioremap() the BAR into the kernel and we can use the standard read[bwl]/write[bwl] - macros. This is the preffered method due to speed but it + macros. This is the preferred method due to speed but it limits the system to just 64MB of PCI memory. This can be - problamatic if using video cards and other memory-heavy devices. + problematic if using video cards and other memory-heavy devices. 2) If > 64MB of memory space is required, the IXP4xx can be configured to use indirect registers to access PCI This allows diff --git a/Documentation/arm/kernel_mode_neon.rst b/Documentation/arch/arm/kernel_mode_neon.rst index 9bfb71a2a9b9..9bfb71a2a9b9 100644 --- a/Documentation/arm/kernel_mode_neon.rst +++ b/Documentation/arch/arm/kernel_mode_neon.rst diff --git a/Documentation/arm/kernel_user_helpers.rst b/Documentation/arch/arm/kernel_user_helpers.rst index eb6f3d916622..eb6f3d916622 100644 --- a/Documentation/arm/kernel_user_helpers.rst +++ b/Documentation/arch/arm/kernel_user_helpers.rst diff --git a/Documentation/arm/keystone/knav-qmss.rst b/Documentation/arch/arm/keystone/knav-qmss.rst index 7f7638d80b42..7f7638d80b42 100644 --- a/Documentation/arm/keystone/knav-qmss.rst +++ b/Documentation/arch/arm/keystone/knav-qmss.rst diff --git a/Documentation/arm/keystone/overview.rst b/Documentation/arch/arm/keystone/overview.rst index cd90298c493c..cd90298c493c 100644 --- a/Documentation/arm/keystone/overview.rst +++ b/Documentation/arch/arm/keystone/overview.rst diff --git a/Documentation/arm/marvell.rst b/Documentation/arch/arm/marvell.rst index 3d369a566038..3d369a566038 100644 --- a/Documentation/arm/marvell.rst +++ b/Documentation/arch/arm/marvell.rst diff --git a/Documentation/arm/mem_alignment.rst b/Documentation/arch/arm/mem_alignment.rst index aa22893b62bc..aa22893b62bc 100644 --- a/Documentation/arm/mem_alignment.rst +++ b/Documentation/arch/arm/mem_alignment.rst diff --git a/Documentation/arm/memory.rst b/Documentation/arch/arm/memory.rst index 0cb1e2938823..0cb1e2938823 100644 --- a/Documentation/arm/memory.rst +++ b/Documentation/arch/arm/memory.rst diff --git a/Documentation/arm/microchip.rst b/Documentation/arch/arm/microchip.rst index e721d855f2c9..e721d855f2c9 100644 --- a/Documentation/arm/microchip.rst +++ b/Documentation/arch/arm/microchip.rst diff --git a/Documentation/arm/netwinder.rst b/Documentation/arch/arm/netwinder.rst index 8eab66caa2ac..8eab66caa2ac 100644 --- a/Documentation/arm/netwinder.rst +++ b/Documentation/arch/arm/netwinder.rst diff --git a/Documentation/arm/nwfpe/index.rst b/Documentation/arch/arm/nwfpe/index.rst index 3c4d2f9aa10e..3c4d2f9aa10e 100644 --- a/Documentation/arm/nwfpe/index.rst +++ b/Documentation/arch/arm/nwfpe/index.rst diff --git a/Documentation/arm/nwfpe/netwinder-fpe.rst b/Documentation/arch/arm/nwfpe/netwinder-fpe.rst index cbb320960fc4..cbb320960fc4 100644 --- a/Documentation/arm/nwfpe/netwinder-fpe.rst +++ b/Documentation/arch/arm/nwfpe/netwinder-fpe.rst diff --git a/Documentation/arm/nwfpe/notes.rst b/Documentation/arch/arm/nwfpe/notes.rst index 102e55af8439..102e55af8439 100644 --- a/Documentation/arm/nwfpe/notes.rst +++ b/Documentation/arch/arm/nwfpe/notes.rst diff --git a/Documentation/arm/nwfpe/nwfpe.rst b/Documentation/arch/arm/nwfpe/nwfpe.rst index 35cd90dacbff..35cd90dacbff 100644 --- a/Documentation/arm/nwfpe/nwfpe.rst +++ b/Documentation/arch/arm/nwfpe/nwfpe.rst diff --git a/Documentation/arm/nwfpe/todo.rst b/Documentation/arch/arm/nwfpe/todo.rst index 393f11b14540..393f11b14540 100644 --- a/Documentation/arm/nwfpe/todo.rst +++ b/Documentation/arch/arm/nwfpe/todo.rst diff --git a/Documentation/arm/omap/dss.rst b/Documentation/arch/arm/omap/dss.rst index a40c4d9c717a..a40c4d9c717a 100644 --- a/Documentation/arm/omap/dss.rst +++ b/Documentation/arch/arm/omap/dss.rst diff --git a/Documentation/arm/omap/index.rst b/Documentation/arch/arm/omap/index.rst index 8b365b212e49..8b365b212e49 100644 --- a/Documentation/arm/omap/index.rst +++ b/Documentation/arch/arm/omap/index.rst diff --git a/Documentation/arm/omap/omap.rst b/Documentation/arch/arm/omap/omap.rst index f440c0f4613f..f440c0f4613f 100644 --- a/Documentation/arm/omap/omap.rst +++ b/Documentation/arch/arm/omap/omap.rst diff --git a/Documentation/arm/omap/omap_pm.rst b/Documentation/arch/arm/omap/omap_pm.rst index a335e4c8ce2c..a335e4c8ce2c 100644 --- a/Documentation/arm/omap/omap_pm.rst +++ b/Documentation/arch/arm/omap/omap_pm.rst diff --git a/Documentation/arm/porting.rst b/Documentation/arch/arm/porting.rst index bd21958bdb2d..bd21958bdb2d 100644 --- a/Documentation/arm/porting.rst +++ b/Documentation/arch/arm/porting.rst diff --git a/Documentation/arm/pxa/mfp.rst b/Documentation/arch/arm/pxa/mfp.rst index ac34e5d7ee44..ac34e5d7ee44 100644 --- a/Documentation/arm/pxa/mfp.rst +++ b/Documentation/arch/arm/pxa/mfp.rst diff --git a/Documentation/arm/sa1100/assabet.rst b/Documentation/arch/arm/sa1100/assabet.rst index a761e128fb08..a761e128fb08 100644 --- a/Documentation/arm/sa1100/assabet.rst +++ b/Documentation/arch/arm/sa1100/assabet.rst diff --git a/Documentation/arm/sa1100/cerf.rst b/Documentation/arch/arm/sa1100/cerf.rst index 7fa71b609bf9..7fa71b609bf9 100644 --- a/Documentation/arm/sa1100/cerf.rst +++ b/Documentation/arch/arm/sa1100/cerf.rst diff --git a/Documentation/arm/sa1100/index.rst b/Documentation/arch/arm/sa1100/index.rst index c9aed43280ff..c9aed43280ff 100644 --- a/Documentation/arm/sa1100/index.rst +++ b/Documentation/arch/arm/sa1100/index.rst diff --git a/Documentation/arm/sa1100/lart.rst b/Documentation/arch/arm/sa1100/lart.rst index 94c0568d1095..94c0568d1095 100644 --- a/Documentation/arm/sa1100/lart.rst +++ b/Documentation/arch/arm/sa1100/lart.rst diff --git a/Documentation/arm/sa1100/serial_uart.rst b/Documentation/arch/arm/sa1100/serial_uart.rst index ea983642b9be..ea983642b9be 100644 --- a/Documentation/arm/sa1100/serial_uart.rst +++ b/Documentation/arch/arm/sa1100/serial_uart.rst diff --git a/Documentation/arm/samsung/bootloader-interface.rst b/Documentation/arch/arm/samsung/bootloader-interface.rst index a56f325dae78..a56f325dae78 100644 --- a/Documentation/arm/samsung/bootloader-interface.rst +++ b/Documentation/arch/arm/samsung/bootloader-interface.rst diff --git a/Documentation/arm/samsung/clksrc-change-registers.awk b/Documentation/arch/arm/samsung/clksrc-change-registers.awk index 7be1b8aa7cd9..7be1b8aa7cd9 100755 --- a/Documentation/arm/samsung/clksrc-change-registers.awk +++ b/Documentation/arch/arm/samsung/clksrc-change-registers.awk diff --git a/Documentation/arm/samsung/gpio.rst b/Documentation/arch/arm/samsung/gpio.rst index 27fae0d50361..27fae0d50361 100644 --- a/Documentation/arm/samsung/gpio.rst +++ b/Documentation/arch/arm/samsung/gpio.rst diff --git a/Documentation/arm/samsung/index.rst b/Documentation/arch/arm/samsung/index.rst index 8142cce3d23e..8142cce3d23e 100644 --- a/Documentation/arm/samsung/index.rst +++ b/Documentation/arch/arm/samsung/index.rst diff --git a/Documentation/arm/samsung/overview.rst b/Documentation/arch/arm/samsung/overview.rst index 8b15a190169b..8b15a190169b 100644 --- a/Documentation/arm/samsung/overview.rst +++ b/Documentation/arch/arm/samsung/overview.rst diff --git a/Documentation/arm/setup.rst b/Documentation/arch/arm/setup.rst index 8e12ef3fb9a7..8e12ef3fb9a7 100644 --- a/Documentation/arm/setup.rst +++ b/Documentation/arch/arm/setup.rst diff --git a/Documentation/arm/spear/overview.rst b/Documentation/arch/arm/spear/overview.rst index 1a77f6b213b6..1a77f6b213b6 100644 --- a/Documentation/arm/spear/overview.rst +++ b/Documentation/arch/arm/spear/overview.rst diff --git a/Documentation/arm/sti/overview.rst b/Documentation/arch/arm/sti/overview.rst index ae16aced800f..ae16aced800f 100644 --- a/Documentation/arm/sti/overview.rst +++ b/Documentation/arch/arm/sti/overview.rst diff --git a/Documentation/arm/sti/stih407-overview.rst b/Documentation/arch/arm/sti/stih407-overview.rst index 027e75bc7b7c..027e75bc7b7c 100644 --- a/Documentation/arm/sti/stih407-overview.rst +++ b/Documentation/arch/arm/sti/stih407-overview.rst diff --git a/Documentation/arm/sti/stih418-overview.rst b/Documentation/arch/arm/sti/stih418-overview.rst index b563c1f4fe5a..b563c1f4fe5a 100644 --- a/Documentation/arm/sti/stih418-overview.rst +++ b/Documentation/arch/arm/sti/stih418-overview.rst diff --git a/Documentation/arm/stm32/overview.rst b/Documentation/arch/arm/stm32/overview.rst index 85cfc8410798..85cfc8410798 100644 --- a/Documentation/arm/stm32/overview.rst +++ b/Documentation/arch/arm/stm32/overview.rst diff --git a/Documentation/arm/stm32/stm32-dma-mdma-chaining.rst b/Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst index 2945e0e33104..2945e0e33104 100644 --- a/Documentation/arm/stm32/stm32-dma-mdma-chaining.rst +++ b/Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst diff --git a/Documentation/arm/stm32/stm32f429-overview.rst b/Documentation/arch/arm/stm32/stm32f429-overview.rst index a7ebe8ea6697..a7ebe8ea6697 100644 --- a/Documentation/arm/stm32/stm32f429-overview.rst +++ b/Documentation/arch/arm/stm32/stm32f429-overview.rst diff --git a/Documentation/arm/stm32/stm32f746-overview.rst b/Documentation/arch/arm/stm32/stm32f746-overview.rst index 78befddc7740..78befddc7740 100644 --- a/Documentation/arm/stm32/stm32f746-overview.rst +++ b/Documentation/arch/arm/stm32/stm32f746-overview.rst diff --git a/Documentation/arm/stm32/stm32f769-overview.rst b/Documentation/arch/arm/stm32/stm32f769-overview.rst index e482980ddf21..e482980ddf21 100644 --- a/Documentation/arm/stm32/stm32f769-overview.rst +++ b/Documentation/arch/arm/stm32/stm32f769-overview.rst diff --git a/Documentation/arm/stm32/stm32h743-overview.rst b/Documentation/arch/arm/stm32/stm32h743-overview.rst index 4e15f1a42730..4e15f1a42730 100644 --- a/Documentation/arm/stm32/stm32h743-overview.rst +++ b/Documentation/arch/arm/stm32/stm32h743-overview.rst diff --git a/Documentation/arm/stm32/stm32h750-overview.rst b/Documentation/arch/arm/stm32/stm32h750-overview.rst index 0e51235c9547..0e51235c9547 100644 --- a/Documentation/arm/stm32/stm32h750-overview.rst +++ b/Documentation/arch/arm/stm32/stm32h750-overview.rst diff --git a/Documentation/arm/stm32/stm32mp13-overview.rst b/Documentation/arch/arm/stm32/stm32mp13-overview.rst index 3bb9492dad49..3bb9492dad49 100644 --- a/Documentation/arm/stm32/stm32mp13-overview.rst +++ b/Documentation/arch/arm/stm32/stm32mp13-overview.rst diff --git a/Documentation/arm/stm32/stm32mp151-overview.rst b/Documentation/arch/arm/stm32/stm32mp151-overview.rst index f42a2ac309c0..f42a2ac309c0 100644 --- a/Documentation/arm/stm32/stm32mp151-overview.rst +++ b/Documentation/arch/arm/stm32/stm32mp151-overview.rst diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arch/arm/stm32/stm32mp157-overview.rst index f62fdc8e7d8d..f62fdc8e7d8d 100644 --- a/Documentation/arm/stm32/stm32mp157-overview.rst +++ b/Documentation/arch/arm/stm32/stm32mp157-overview.rst diff --git a/Documentation/arm/sunxi.rst b/Documentation/arch/arm/sunxi.rst index b85d1e2f2d47..b85d1e2f2d47 100644 --- a/Documentation/arm/sunxi.rst +++ b/Documentation/arch/arm/sunxi.rst diff --git a/Documentation/arm/sunxi/clocks.rst b/Documentation/arch/arm/sunxi/clocks.rst index 23bd03f3e21f..dfe6d4887210 100644 --- a/Documentation/arm/sunxi/clocks.rst +++ b/Documentation/arch/arm/sunxi/clocks.rst @@ -5,7 +5,7 @@ Frequently asked questions about the sunxi clock system This document contains useful bits of information that people tend to ask about the sunxi clock system, as well as accompanying ASCII art when adequate. -Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the +Q: Why is the main 24MHz oscillator gateable? Wouldn't that break the system? A: The 24MHz oscillator allows gating to save power. Indeed, if gated diff --git a/Documentation/arm/swp_emulation.rst b/Documentation/arch/arm/swp_emulation.rst index 6a608a9c3715..bf205e3de36e 100644 --- a/Documentation/arm/swp_emulation.rst +++ b/Documentation/arch/arm/swp_emulation.rst @@ -1,7 +1,7 @@ Software emulation of deprecated SWP instruction (CONFIG_SWP_EMULATE) --------------------------------------------------------------------- -ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommeds +ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommends moving to the load-locked/store-conditional instructions LDREX and STREX. ARMv7 multiprocessing extensions introduce the ability to disable these diff --git a/Documentation/arm/tcm.rst b/Documentation/arch/arm/tcm.rst index 1dc6c39220f9..7ce17a248af9 100644 --- a/Documentation/arm/tcm.rst +++ b/Documentation/arch/arm/tcm.rst @@ -71,7 +71,7 @@ in <asm/tcm.h>. Using this interface it is possible to: - Have the remaining TCM RAM added to a special allocation pool with gen_pool_create() and gen_pool_add() - and provice tcm_alloc() and tcm_free() for this + and provide tcm_alloc() and tcm_free() for this memory. Such a heap is great for things like saving device state when shutting off device power domains. diff --git a/Documentation/arm/uefi.rst b/Documentation/arch/arm/uefi.rst index baebe688a006..2b7ad9bd7cd2 100644 --- a/Documentation/arm/uefi.rst +++ b/Documentation/arch/arm/uefi.rst @@ -50,7 +50,7 @@ The stub populates the FDT /chosen node with (and the kernel scans for) the following parameters: ========================== ====== =========================================== -Name Size Description +Name Type Description ========================== ====== =========================================== linux,uefi-system-table 64-bit Physical address of the UEFI System Table. @@ -67,4 +67,6 @@ linux,uefi-mmap-desc-ver 32-bit Version of the mmap descriptor format. kaslr-seed 64-bit Entropy used to randomize the kernel image base address location. + +bootargs String Kernel command line ========================== ====== =========================================== diff --git a/Documentation/arm/vfp/release-notes.rst b/Documentation/arch/arm/vfp/release-notes.rst index c6b04937cee3..c6b04937cee3 100644 --- a/Documentation/arm/vfp/release-notes.rst +++ b/Documentation/arch/arm/vfp/release-notes.rst diff --git a/Documentation/arm/vlocks.rst b/Documentation/arch/arm/vlocks.rst index a40a1742110b..737aa8661a21 100644 --- a/Documentation/arm/vlocks.rst +++ b/Documentation/arch/arm/vlocks.rst @@ -155,7 +155,7 @@ the basic algorithm: optimisation. If there are too many CPUs to read the currently_voting array in - one transaction then multiple transations are still required. The + one transaction then multiple transactions are still required. The implementation uses a simple loop of word-sized loads for this case. The number of transactions is still fewer than would be required if bytes were loaded individually. diff --git a/Documentation/arm64/acpi_object_usage.rst b/Documentation/arch/arm64/acpi_object_usage.rst index 484ef9676653..06d8a87971ef 100644 --- a/Documentation/arm64/acpi_object_usage.rst +++ b/Documentation/arch/arm64/acpi_object_usage.rst @@ -17,16 +17,37 @@ For ACPI on arm64, tables also fall into the following categories: - Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT - - Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, IBFT, - IORT, MCHI, MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, - STAO, TCPA, TPM2, UEFI, XENV + - Optional: AGDI, BGRT, CEDT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, + HMAT, IBFT, IORT, MCHI, MPAM, MPST, MSCT, NFIT, PMTT, PPTT, RASF, SBST, + SDEI, SLIT, SPMI, SRAT, STAO, TCPA, TPM2, UEFI, XENV - - Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT, MSDM, OEMx, - PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT + - Not supported: AEST, APMT, BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT, + MSDM, OEMx, PDTT, PSDT, RAS2, RSDT, SLIC, WAET, WDAT, WDRT, WPBT ====== ======================================================================== Table Usage for ARMv8 Linux ====== ======================================================================== +AEST Signature Reserved (signature == "AEST") + + **Arm Error Source Table** + + This table informs the OS of any error nodes in the system that are + compliant with the Arm RAS architecture. + +AGDI Signature Reserved (signature == "AGDI") + + **Arm Generic diagnostic Dump and Reset Device Interface Table** + + This table describes a non-maskable event, that is used by the platform + firmware, to request the OS to generate a diagnostic dump and reset the device. + +APMT Signature Reserved (signature == "APMT") + + **Arm Performance Monitoring Table** + + This table describes the properties of PMU support implemented by + components in the system. + BERT Section 18.3 (signature == "BERT") **Boot Error Record Table** @@ -47,6 +68,13 @@ BGRT Section 5.2.22 (signature == "BGRT") Optional, not currently supported, with no real use-case for an ARM server. +CEDT Signature Reserved (signature == "CEDT") + + **CXL Early Discovery Table** + + This table allows the OS to discover any CXL Host Bridges and the Host + Bridge registers. + CPEP Section 5.2.18 (signature == "CPEP") **Corrected Platform Error Polling table** @@ -184,6 +212,15 @@ HEST Section 18.3.2 (signature == "HEST") Must be supplied if RAS support is provided by the platform. It is recommended this table be supplied. +HMAT Section 5.2.28 (signature == "HMAT") + + **Heterogeneous Memory Attribute Table** + + This table describes the memory attributes, such as memory side cache + attributes and bandwidth and latency details, related to Memory Proximity + Domains. The OS uses this information to optimize the system memory + configuration. + HPET Signature Reserved (signature == "HPET") **High Precision Event timer Table** @@ -241,6 +278,13 @@ MCHI Signature Reserved (signature == "MCHI") Optional, not currently supported. +MPAM Signature Reserved (signature == "MPAM") + + **Memory Partitioning And Monitoring table** + + This table allows the OS to discover the MPAM controls implemented by + the subsystems. + MPST Section 5.2.21 (signature == "MPST") **Memory Power State Table** @@ -281,18 +325,39 @@ PCCT Section 14.1 (signature == "PCCT) Recommend for use on arm64; use of PCC is recommended when using CPPC to control performance and power for platform processors. +PDTT Section 5.2.29 (signature == "PDTT") + + **Platform Debug Trigger Table** + + This table describes PCC channels used to gather debug logs of + non-architectural features. + + PMTT Section 5.2.21.12 (signature == "PMTT") **Platform Memory Topology Table** Optional, not currently supported. +PPTT Section 5.2.30 (signature == "PPTT") + + **Processor Properties Topology Table** + + This table provides the processor and cache topology. + PSDT Section 5.2.11.3 (signature == "PSDT") **Persistent System Description Table** Obsolete table, will not be supported. +RAS2 Section 5.2.21 (signature == "RAS2") + + **RAS Features 2 table** + + This table provides interfaces for the RAS capabilities implemented in + the platform. + RASF Section 5.2.20 (signature == "RASF") **RAS Feature table** @@ -318,6 +383,12 @@ SBST Section 5.2.14 (signature == "SBST") Optional, not currently supported. +SDEI Signature Reserved (signature == "SDEI") + + **Software Delegated Exception Interface table** + + This table advertises the presence of the SDEI interface. + SLIC Signature Reserved (signature == "SLIC") **Software LIcensing table** diff --git a/Documentation/arm64/amu.rst b/Documentation/arch/arm64/amu.rst index 01f2de2b0450..01f2de2b0450 100644 --- a/Documentation/arm64/amu.rst +++ b/Documentation/arch/arm64/amu.rst diff --git a/Documentation/arm64/arm-acpi.rst b/Documentation/arch/arm64/arm-acpi.rst index 47ecb9930dde..a46c34fa9604 100644 --- a/Documentation/arm64/arm-acpi.rst +++ b/Documentation/arch/arm64/arm-acpi.rst @@ -1,40 +1,41 @@ -===================== -ACPI on ARMv8 Servers -===================== - -ACPI can be used for ARMv8 general purpose servers designed to follow -the ARM SBSA (Server Base System Architecture) [0] and SBBR (Server -Base Boot Requirements) [1] specifications. Please note that the SBBR -can be retrieved simply by visiting [1], but the SBSA is currently only -available to those with an ARM login due to ARM IP licensing concerns. - -The ARMv8 kernel implements the reduced hardware model of ACPI version +=================== +ACPI on Arm systems +=================== + +ACPI can be used for Armv8 and Armv9 systems designed to follow +the BSA (Arm Base System Architecture) [0] and BBR (Arm +Base Boot Requirements) [1] specifications. Both BSA and BBR are publicly +accessible documents. +Arm Servers, in addition to being BSA compliant, comply with a set +of rules defined in SBSA (Server Base System Architecture) [2]. + +The Arm kernel implements the reduced hardware model of ACPI version 5.1 or later. Links to the specification and all external documents it refers to are managed by the UEFI Forum. The specification is available at http://www.uefi.org/specifications and documents referenced by the specification can be found via http://www.uefi.org/acpi. -If an ARMv8 system does not meet the requirements of the SBSA and SBBR, +If an Arm system does not meet the requirements of the BSA and BBR, or cannot be described using the mechanisms defined in the required ACPI specifications, then ACPI may not be a good fit for the hardware. While the documents mentioned above set out the requirements for building -industry-standard ARMv8 servers, they also apply to more than one operating +industry-standard Arm systems, they also apply to more than one operating system. The purpose of this document is to describe the interaction between -ACPI and Linux only, on an ARMv8 system -- that is, what Linux expects of +ACPI and Linux only, on an Arm system -- that is, what Linux expects of ACPI and what ACPI can expect of Linux. -Why ACPI on ARM? +Why ACPI on Arm? ---------------- Before examining the details of the interface between ACPI and Linux, it is useful to understand why ACPI is being used. Several technologies already exist in Linux for describing non-enumerable hardware, after all. In this -section we summarize a blog post [2] from Grant Likely that outlines the -reasoning behind ACPI on ARMv8 servers. Actually, we snitch a good portion +section we summarize a blog post [3] from Grant Likely that outlines the +reasoning behind ACPI on Arm systems. Actually, we snitch a good portion of the summary text almost directly, to be honest. -The short form of the rationale for ACPI on ARM is: +The short form of the rationale for ACPI on Arm is: - ACPI’s byte code (AML) allows the platform to encode hardware behavior, while DT explicitly does not support this. For hardware vendors, being @@ -47,7 +48,7 @@ The short form of the rationale for ACPI on ARM is: - In the enterprise server environment, ACPI has established bindings (such as for RAS) which are currently used in production systems. DT does not. - Such bindings could be defined in DT at some point, but doing so means ARM + Such bindings could be defined in DT at some point, but doing so means Arm and x86 would end up using completely different code paths in both firmware and the kernel. @@ -98,7 +99,7 @@ to replace the kernel. When a Linux driver or subsystem is first implemented using ACPI, it by definition ends up requiring a specific version of the ACPI specification --- it's baseline. ACPI firmware must continue to work, even though it may +-- its baseline. ACPI firmware must continue to work, even though it may not be optimal, with the earliest kernel version that first provides support for that baseline version of ACPI. There may be a need for additional drivers, but adding new functionality (e.g., CPU power management) should not break @@ -108,7 +109,7 @@ recent version of the kernel. Relationship with Device Tree ----------------------------- -ACPI support in drivers and subsystems for ARMv8 should never be mutually +ACPI support in drivers and subsystems for Arm should never be mutually exclusive with DT support at compile time. At boot time the kernel will only use one description method depending on @@ -121,11 +122,11 @@ time). Booting using ACPI tables ------------------------- -The only defined method for passing ACPI tables to the kernel on ARMv8 +The only defined method for passing ACPI tables to the kernel on Arm is via the UEFI system configuration table. Just so it is explicit, this means that ACPI is only supported on platforms that boot via UEFI. -When an ARMv8 system boots, it can either have DT information, ACPI tables, +When an Arm system boots, it can either have DT information, ACPI tables, or in some very unusual cases, both. If no command line parameters are used, the kernel will try to use DT for device enumeration; if there is no DT present, the kernel will try to use ACPI tables, but only if they are present. @@ -169,7 +170,7 @@ hardware reduced mode must be set to zero. For the ACPI core to operate properly, and in turn provide the information the kernel needs to configure devices, it expects to find the following -tables (all section numbers refer to the ACPI 6.1 specification): +tables (all section numbers refer to the ACPI 6.5 specification): - RSDP (Root System Description Pointer), section 5.2.5 @@ -184,20 +185,76 @@ tables (all section numbers refer to the ACPI 6.1 specification): - GTDT (Generic Timer Description Table), section 5.2.24 + - PPTT (Processor Properties Topology Table), section 5.2.30 + + - DBG2 (DeBuG port table 2), section 5.2.6, specifically Table 5-6. + + - APMT (Arm Performance Monitoring unit Table), section 5.2.6, specifically Table 5-6. + + - AGDI (Arm Generic diagnostic Dump and Reset Device Interface Table), section 5.2.6, specifically Table 5-6. + - If PCI is supported, the MCFG (Memory mapped ConFiGuration - Table), section 5.2.6, specifically Table 5-31. + Table), section 5.2.6, specifically Table 5-6. - If booting without a console=<device> kernel parameter is supported, the SPCR (Serial Port Console Redirection table), - section 5.2.6, specifically Table 5-31. + section 5.2.6, specifically Table 5-6. - If necessary to describe the I/O topology, SMMUs and GIC ITSs, the IORT (Input Output Remapping Table, section 5.2.6, specifically - Table 5-31). + Table 5-6). + + - If NUMA is supported, the following tables are required: + + - SRAT (System Resource Affinity Table), section 5.2.16 + + - SLIT (System Locality distance Information Table), section 5.2.17 + + - If NUMA is supported, and the system contains heterogeneous memory, + the HMAT (Heterogeneous Memory Attribute Table), section 5.2.28. + + - If the ACPI Platform Error Interfaces are required, the following + tables are conditionally required: + + - BERT (Boot Error Record Table, section 18.3.1) + + - EINJ (Error INJection table, section 18.6.1) + + - ERST (Error Record Serialization Table, section 18.5) + + - HEST (Hardware Error Source Table, section 18.3.2) + + - SDEI (Software Delegated Exception Interface table, section 5.2.6, + specifically Table 5-6) + + - AEST (Arm Error Source Table, section 5.2.6, + specifically Table 5-6) + + - RAS2 (ACPI RAS2 feature table, section 5.2.21) + + - If the system contains controllers using PCC channel, the + PCCT (Platform Communications Channel Table), section 14.1 + + - If the system contains a controller to capture board-level system state, + and communicates with the host via PCC, the PDTT (Platform Debug Trigger + Table), section 5.2.29. + + - If NVDIMM is supported, the NFIT (NVDIMM Firmware Interface Table), section 5.2.26 + + - If video framebuffer is present, the BGRT (Boot Graphics Resource Table), section 5.2.23 + + - If IPMI is implemented, the SPMI (Server Platform Management Interface), + section 5.2.6, specifically Table 5-6. + + - If the system contains a CXL Host Bridge, the CEDT (CXL Early Discovery + Table), section 5.2.6, specifically Table 5-6. + + - If the system supports MPAM, the MPAM (Memory Partitioning And Monitoring table), section 5.2.6, + specifically Table 5-6. + + - If the system lacks persistent storage, the IBFT (ISCSI Boot Firmware + Table), section 5.2.6, specifically Table 5-6. - - If NUMA is supported, the SRAT (System Resource Affinity Table) - and SLIT (System Locality distance Information Table), sections - 5.2.16 and 5.2.17, respectively. If the above tables are not all present, the kernel may or may not be able to boot properly since it may not be able to configure all of the @@ -269,16 +326,14 @@ Drivers should look for device properties in the _DSD object ONLY; the _DSD object is described in the ACPI specification section 6.2.5, but this only describes how to define the structure of an object returned via _DSD, and how specific data structures are defined by specific UUIDs. Linux should -only use the _DSD Device Properties UUID [5]: +only use the _DSD Device Properties UUID [4]: - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 - - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf - -The UEFI Forum provides a mechanism for registering device properties [4] -so that they may be used across all operating systems supporting ACPI. -Device properties that have not been registered with the UEFI Forum should -not be used. +Common device properties can be registered by creating a pull request to [4] so +that they may be used across all operating systems supporting ACPI. +Device properties that have not been registered with the UEFI Forum can be used +but not as "uefi-" common properties. Before creating new device properties, check to be sure that they have not been defined before and either registered in the Linux kernel documentation @@ -306,7 +361,7 @@ process. Once registration and review have been completed, the kernel provides an interface for looking up device properties in a manner independent of -whether DT or ACPI is being used. This API should be used [6]; it can +whether DT or ACPI is being used. This API should be used [5]; it can eliminate some duplication of code paths in driver probing functions and discourage divergence between DT bindings and ACPI device properties. @@ -448,15 +503,15 @@ ASWG ---- The ACPI specification changes regularly. During the year 2014, for instance, version 5.1 was released and version 6.0 substantially completed, with most of -the changes being driven by ARM-specific requirements. Proposed changes are +the changes being driven by Arm-specific requirements. Proposed changes are presented and discussed in the ASWG (ACPI Specification Working Group) which is a part of the UEFI Forum. The current version of the ACPI specification -is 6.1 release in January 2016. +is 6.5 release in August 2022. Participation in this group is open to all UEFI members. Please see http://www.uefi.org/workinggroup for details on group membership. -It is the intent of the ARMv8 ACPI kernel code to follow the ACPI specification +It is the intent of the Arm ACPI kernel code to follow the ACPI specification as closely as possible, and to only implement functionality that complies with the released standards from UEFI ASWG. As a practical matter, there will be vendors that provide bad ACPI tables or violate the standards in some way. @@ -470,12 +525,12 @@ likely be willing to assist in submitting ECRs. Linux Code ---------- -Individual items specific to Linux on ARM, contained in the Linux +Individual items specific to Linux on Arm, contained in the Linux source code, are in the list that follows: ACPI_OS_NAME This macro defines the string to be returned when - an ACPI method invokes the _OS method. On ARM64 + an ACPI method invokes the _OS method. On Arm systems, this macro will be "Linux" by default. The command line parameter acpi_os=<string> can be used to set it to some other value. The @@ -485,36 +540,28 @@ ACPI_OS_NAME ACPI Objects ------------ Detailed expectations for ACPI tables and object are listed in the file -Documentation/arm64/acpi_object_usage.rst. +Documentation/arch/arm64/acpi_object_usage.rst. References ---------- -[0] http://silver.arm.com - document ARM-DEN-0029, or newer: - "Server Base System Architecture", version 2.3, dated 27 Mar 2014 +[0] https://developer.arm.com/documentation/den0094/latest + document Arm-DEN-0094: "Arm Base System Architecture", version 1.0C, dated 6 Oct 2022 + +[1] https://developer.arm.com/documentation/den0044/latest + Document Arm-DEN-0044: "Arm Base Boot Requirements", version 2.0G, dated 15 Apr 2022 -[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0044a/Server_Base_Boot_Requirements.pdf - Document ARM-DEN-0044A, or newer: "Server Base Boot Requirements, System - Software on ARM Platforms", dated 16 Aug 2014 +[2] https://developer.arm.com/documentation/den0029/latest + Document Arm-DEN-0029: "Arm Server Base System Architecture", version 7.1, dated 06 Oct 2022 -[2] http://www.secretlab.ca/archives/151, +[3] http://www.secretlab.ca/archives/151, 10 Jan 2015, Copyright (c) 2015, Linaro Ltd., written by Grant Likely. -[3] AMD ACPI for Seattle platform documentation - http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Seattle_ACPI_Guide.pdf - - -[4] http://www.uefi.org/acpi - please see the link for the "ACPI _DSD Device - Property Registry Instructions" - -[5] http://www.uefi.org/acpi - please see the link for the "_DSD (Device - Specific Data) Implementation Guide" +[4] _DSD (Device Specific Data) Implementation Guide + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf -[6] Kernel code for the unified device +[5] Kernel code for the unified device property interface can be found in include/linux/property.h and drivers/base/property.c. diff --git a/Documentation/arm64/asymmetric-32bit.rst b/Documentation/arch/arm64/asymmetric-32bit.rst index 64a0b505da7d..64a0b505da7d 100644 --- a/Documentation/arm64/asymmetric-32bit.rst +++ b/Documentation/arch/arm64/asymmetric-32bit.rst diff --git a/Documentation/arm64/booting.rst b/Documentation/arch/arm64/booting.rst index ffeccdd6bdac..b57776a68f15 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arch/arm64/booting.rst @@ -379,6 +379,38 @@ Before jumping into the kernel, the following conditions must be met: - SMCR_EL2.EZT0 (bit 30) 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: + + - HCRX_EL2.MSCEn (bit 11) must be initialised to 0b1. + + For CPUs with the Extended Translation Control Register feature (FEAT_TCR2): + + - If EL3 is present: + + - SCR_EL3.TCR2En (bit 43) must be initialised to 0b1. + + - If the kernel is entered at EL1 and EL2 is present: + + - HCRX_EL2.TCR2En (bit 14) must be initialised to 0b1. + + For CPUs with the Stage 1 Permission Indirection Extension feature (FEAT_S1PIE): + + - If EL3 is present: + + - SCR_EL3.PIEn (bit 45) must be initialised to 0b1. + + - If the kernel is entered at EL1 and EL2 is present: + + - HFGRTR_EL2.nPIR_EL1 (bit 58) must be initialised to 0b1. + + - HFGWTR_EL2.nPIR_EL1 (bit 58) must be initialised to 0b1. + + - HFGRTR_EL2.nPIRE0_EL1 (bit 57) must be initialised to 0b1. + + - HFGRWR_EL2.nPIRE0_EL1 (bit 57) must be initialised to 0b1. + The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must enter the kernel in the same exception level. Where the values documented diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arch/arm64/cpu-feature-registers.rst index c7adc7897df6..4e4625f2455f 100644 --- a/Documentation/arm64/cpu-feature-registers.rst +++ b/Documentation/arch/arm64/cpu-feature-registers.rst @@ -288,6 +288,8 @@ infrastructure: +------------------------------+---------+---------+ | Name | bits | visible | +------------------------------+---------+---------+ + | MOPS | [19-16] | y | + +------------------------------+---------+---------+ | RPRES | [7-4] | y | +------------------------------+---------+---------+ | WFXT | [3-0] | y | diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arch/arm64/elf_hwcaps.rst index 83e57e4d38e2..8c8addb4194c 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arch/arm64/elf_hwcaps.rst @@ -102,7 +102,7 @@ HWCAP_ASIMDHP HWCAP_CPUID EL0 access to certain ID registers is available, to the extent - described by Documentation/arm64/cpu-feature-registers.rst. + described by Documentation/arch/arm64/cpu-feature-registers.rst. These ID registers may imply the availability of features. @@ -163,12 +163,12 @@ HWCAP_SB HWCAP_PACA Functionality implied by ID_AA64ISAR1_EL1.APA == 0b0001 or ID_AA64ISAR1_EL1.API == 0b0001, as described by - Documentation/arm64/pointer-authentication.rst. + Documentation/arch/arm64/pointer-authentication.rst. HWCAP_PACG Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or ID_AA64ISAR1_EL1.GPI == 0b0001, as described by - Documentation/arm64/pointer-authentication.rst. + Documentation/arch/arm64/pointer-authentication.rst. HWCAP2_DCPODP Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010. @@ -226,7 +226,7 @@ HWCAP2_BTI HWCAP2_MTE Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described - by Documentation/arm64/memory-tagging-extension.rst. + by Documentation/arch/arm64/memory-tagging-extension.rst. HWCAP2_ECV Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001. @@ -239,11 +239,11 @@ HWCAP2_RPRES HWCAP2_MTE3 Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described - by Documentation/arm64/memory-tagging-extension.rst. + by Documentation/arch/arm64/memory-tagging-extension.rst. HWCAP2_SME Functionality implied by ID_AA64PFR1_EL1.SME == 0b0001, as described - by Documentation/arm64/sme.rst. + by Documentation/arch/arm64/sme.rst. HWCAP2_SME_I16I64 Functionality implied by ID_AA64SMFR0_EL1.I16I64 == 0b1111. @@ -302,6 +302,9 @@ HWCAP2_SMEB16B16 HWCAP2_SMEF16F16 Functionality implied by ID_AA64SMFR0_EL1.F16F16 == 0b1 +HWCAP2_MOPS + Functionality implied by ID_AA64ISAR2_EL1.MOPS == 0b0001. + 4. Unused AT_HWCAP bits ----------------------- diff --git a/Documentation/arm64/features.rst b/Documentation/arch/arm64/features.rst index dfa4cb3cd3ef..dfa4cb3cd3ef 100644 --- a/Documentation/arm64/features.rst +++ b/Documentation/arch/arm64/features.rst diff --git a/Documentation/arm64/hugetlbpage.rst b/Documentation/arch/arm64/hugetlbpage.rst index a110124c11e3..a110124c11e3 100644 --- a/Documentation/arm64/hugetlbpage.rst +++ b/Documentation/arch/arm64/hugetlbpage.rst diff --git a/Documentation/arm64/index.rst b/Documentation/arch/arm64/index.rst index ae21f8118830..d08e924204bf 100644 --- a/Documentation/arm64/index.rst +++ b/Documentation/arch/arm64/index.rst @@ -15,11 +15,13 @@ ARM64 Architecture cpu-feature-registers elf_hwcaps hugetlbpage + kdump legacy_instructions memory memory-tagging-extension perf pointer-authentication + ptdump silicon-errata sme sve diff --git a/Documentation/arm64/kasan-offsets.sh b/Documentation/arch/arm64/kasan-offsets.sh index 2dc5f9e18039..2dc5f9e18039 100644 --- a/Documentation/arm64/kasan-offsets.sh +++ b/Documentation/arch/arm64/kasan-offsets.sh diff --git a/Documentation/arch/arm64/kdump.rst b/Documentation/arch/arm64/kdump.rst new file mode 100644 index 000000000000..56a89f45df28 --- /dev/null +++ b/Documentation/arch/arm64/kdump.rst @@ -0,0 +1,92 @@ +======================================= +crashkernel memory reservation on arm64 +======================================= + +Author: Baoquan He <bhe@redhat.com> + +Kdump mechanism is used to capture a corrupted kernel vmcore so that +it can be subsequently analyzed. In order to do this, a preliminarily +reserved memory is needed to pre-load the kdump kernel and boot such +kernel if corruption happens. + +That reserved memory for kdump is adapted to be able to minimally +accommodate the kdump kernel and the user space programs needed for the +vmcore collection. + +Kernel parameter +================ + +Through the kernel parameters below, memory can be reserved accordingly +during the early stage of the first kernel booting so that a continuous +large chunk of memomy can be found. The low memory reservation needs to +be considered if the crashkernel is reserved from the high memory area. + +- crashkernel=size@offset +- crashkernel=size +- crashkernel=size,high crashkernel=size,low + +Low memory and high memory +========================== + +For kdump reservations, low memory is the memory area under a specific +limit, usually decided by the accessible address bits of the DMA-capable +devices needed by the kdump kernel to run. Those devices not related to +vmcore dumping can be ignored. On arm64, the low memory upper bound is +not fixed: it is 1G on the RPi4 platform but 4G on most other systems. +On special kernels built with CONFIG_ZONE_(DMA|DMA32) disabled, the +whole system RAM is low memory. Outside of the low memory described +above, the rest of system RAM is considered high memory. + +Implementation +============== + +1) crashkernel=size@offset +-------------------------- + +The crashkernel memory must be reserved at the user-specified region or +fail if already occupied. + + +2) crashkernel=size +------------------- + +The crashkernel memory region will be reserved in any available position +according to the search order: + +Firstly, the kernel searches the low memory area for an available region +with the specified size. + +If searching for low memory fails, the kernel falls back to searching +the high memory area for an available region of the specified size. If +the reservation in high memory succeeds, a default size reservation in +the low memory will be done. Currently the default size is 128M, +sufficient for the low memory needs of the kdump kernel. + +Note: crashkernel=size is the recommended option for crashkernel kernel +reservations. The user would not need to know the system memory layout +for a specific platform. + +3) crashkernel=size,high crashkernel=size,low +--------------------------------------------- + +crashkernel=size,(high|low) are an important supplement to +crashkernel=size. They allows the user to specify how much memory needs +to be allocated from the high memory and low memory respectively. On +many systems the low memory is precious and crashkernel reservations +from this area should be kept to a minimum. + +To reserve memory for crashkernel=size,high, searching is first +attempted from the high memory region. If the reservation succeeds, the +low memory reservation will be done subsequently. + +If reservation from the high memory failed, the kernel falls back to +searching the low memory with the specified size in crashkernel=,high. +If it succeeds, no further reservation for low memory is needed. + +Notes: + +- If crashkernel=,low is not specified, the default low memory + reservation will be done automatically. + +- if crashkernel=0,low is specified, it means that the low memory + reservation is omitted intentionally. diff --git a/Documentation/arm64/legacy_instructions.rst b/Documentation/arch/arm64/legacy_instructions.rst index 54401b22cb8f..54401b22cb8f 100644 --- a/Documentation/arm64/legacy_instructions.rst +++ b/Documentation/arch/arm64/legacy_instructions.rst diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arch/arm64/memory-tagging-extension.rst index dbae47bba25e..679725030731 100644 --- a/Documentation/arm64/memory-tagging-extension.rst +++ b/Documentation/arch/arm64/memory-tagging-extension.rst @@ -221,7 +221,7 @@ programs should not retry in case of a non-zero system call return. ``NT_ARM_TAGGED_ADDR_CTRL`` allow ``ptrace()`` access to the tagged address ABI control and MTE configuration of a process as per the ``prctl()`` options described in -Documentation/arm64/tagged-address-abi.rst and above. The corresponding +Documentation/arch/arm64/tagged-address-abi.rst and above. The corresponding ``regset`` is 1 element of 8 bytes (``sizeof(long))``). Core dump support diff --git a/Documentation/arm64/memory.rst b/Documentation/arch/arm64/memory.rst index 2a641ba7be3b..55a55f30eed8 100644 --- a/Documentation/arm64/memory.rst +++ b/Documentation/arch/arm64/memory.rst @@ -33,8 +33,8 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit):: 0000000000000000 0000ffffffffffff 256TB user ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map [ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region] - ffff800000000000 ffff800007ffffff 128MB modules - ffff800008000000 fffffbffefffffff 124TB vmalloc + ffff800000000000 ffff80007fffffff 2GB modules + ffff800080000000 fffffbffefffffff 124TB vmalloc fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down) fffffbfffe000000 fffffbfffe7fffff 8MB [guard region] fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space @@ -50,8 +50,8 @@ AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support): 0000000000000000 000fffffffffffff 4PB user fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map [fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region] - ffff800000000000 ffff800007ffffff 128MB modules - ffff800008000000 fffffbffefffffff 124TB vmalloc + ffff800000000000 ffff80007fffffff 2GB modules + ffff800080000000 fffffbffefffffff 124TB vmalloc fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down) fffffbfffe000000 fffffbfffe7fffff 8MB [guard region] fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space diff --git a/Documentation/arm64/perf.rst b/Documentation/arch/arm64/perf.rst index 1f87b57c2332..1f87b57c2332 100644 --- a/Documentation/arm64/perf.rst +++ b/Documentation/arch/arm64/perf.rst diff --git a/Documentation/arm64/pointer-authentication.rst b/Documentation/arch/arm64/pointer-authentication.rst index e5dad2e40aa8..e5dad2e40aa8 100644 --- a/Documentation/arm64/pointer-authentication.rst +++ b/Documentation/arch/arm64/pointer-authentication.rst diff --git a/Documentation/arch/arm64/ptdump.rst b/Documentation/arch/arm64/ptdump.rst new file mode 100644 index 000000000000..5dcfc5d7cddf --- /dev/null +++ b/Documentation/arch/arm64/ptdump.rst @@ -0,0 +1,96 @@ +====================== +Kernel page table dump +====================== + +ptdump is a debugfs interface that provides a detailed dump of the +kernel page tables. It offers a comprehensive overview of the kernel +virtual memory layout as well as the attributes associated with the +various regions in a human-readable format. It is useful to dump the +kernel page tables to verify permissions and memory types. Examining the +page table entries and permissions helps identify potential security +vulnerabilities such as mappings with overly permissive access rights or +improper memory protections. + +Memory hotplug allows dynamic expansion or contraction of available +memory without requiring a system reboot. To maintain the consistency +and integrity of the memory management data structures, arm64 makes use +of the ``mem_hotplug_lock`` semaphore in write mode. Additionally, in +read mode, ``mem_hotplug_lock`` supports an efficient implementation of +``get_online_mems()`` and ``put_online_mems()``. These protect the +offlining of memory being accessed by the ptdump code. + +In order to dump the kernel page tables, enable the following +configurations and mount debugfs:: + + CONFIG_GENERIC_PTDUMP=y + CONFIG_PTDUMP_CORE=y + CONFIG_PTDUMP_DEBUGFS=y + + mount -t debugfs nodev /sys/kernel/debug + cat /sys/kernel/debug/kernel_page_tables + +On analysing the output of ``cat /sys/kernel/debug/kernel_page_tables`` +one can derive information about the virtual address range of the entry, +followed by size of the memory region covered by this entry, the +hierarchical structure of the page tables and finally the attributes +associated with each page. The page attributes provide information about +access permissions, execution capability, type of mapping such as leaf +level PTE or block level PGD, PMD and PUD, and access status of a page +within the kernel memory. Assessing these attributes can assist in +understanding the memory layout, access patterns and security +characteristics of the kernel pages. + +Kernel virtual memory layout example:: + + start address end address size attributes + +---------------------------------------------------------------------------------------+ + | ---[ Linear Mapping start ]---------------------------------------------------------- | + | .................. | + | 0xfff0000000000000-0xfff0000000210000 2112K PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED | + | 0xfff0000000210000-0xfff0000001c00000 26560K PTE ro NX SHD AF UXN MEM/NORMAL | + | .................. | + | ---[ Linear Mapping end ]------------------------------------------------------------ | + +---------------------------------------------------------------------------------------+ + | ---[ Modules start ]----------------------------------------------------------------- | + | .................. | + | 0xffff800000000000-0xffff800008000000 128M PTE | + | .................. | + | ---[ Modules end ]------------------------------------------------------------------- | + +---------------------------------------------------------------------------------------+ + | ---[ vmalloc() area ]---------------------------------------------------------------- | + | .................. | + | 0xffff800008010000-0xffff800008200000 1984K PTE ro x SHD AF UXN MEM/NORMAL | + | 0xffff800008200000-0xffff800008e00000 12M PTE ro x SHD AF CON UXN MEM/NORMAL | + | .................. | + | ---[ vmalloc() end ]----------------------------------------------------------------- | + +---------------------------------------------------------------------------------------+ + | ---[ Fixmap start ]------------------------------------------------------------------ | + | .................. | + | 0xfffffbfffdb80000-0xfffffbfffdb90000 64K PTE ro x SHD AF UXN MEM/NORMAL | + | 0xfffffbfffdb90000-0xfffffbfffdba0000 64K PTE ro NX SHD AF UXN MEM/NORMAL | + | .................. | + | ---[ Fixmap end ]-------------------------------------------------------------------- | + +---------------------------------------------------------------------------------------+ + | ---[ PCI I/O start ]----------------------------------------------------------------- | + | .................. | + | 0xfffffbfffe800000-0xfffffbffff800000 16M PTE | + | .................. | + | ---[ PCI I/O end ]------------------------------------------------------------------- | + +---------------------------------------------------------------------------------------+ + | ---[ vmemmap start ]----------------------------------------------------------------- | + | .................. | + | 0xfffffc0002000000-0xfffffc0002200000 2M PTE RW NX SHD AF UXN MEM/NORMAL | + | 0xfffffc0002200000-0xfffffc0020000000 478M PTE | + | .................. | + | ---[ vmemmap end ]------------------------------------------------------------------- | + +---------------------------------------------------------------------------------------+ + +``cat /sys/kernel/debug/kernel_page_tables`` output:: + + 0xfff0000001c00000-0xfff0000080000000 2020M PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED + 0xfff0000080000000-0xfff0000800000000 30G PMD + 0xfff0000800000000-0xfff0000800700000 7M PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED + 0xfff0000800700000-0xfff0000800710000 64K PTE ro NX SHD AF UXN MEM/NORMAL-TAGGED + 0xfff0000800710000-0xfff0000880000000 2089920K PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED + 0xfff0000880000000-0xfff0040000000000 4062G PMD + 0xfff0040000000000-0xffff800000000000 3964T PGD diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst index 9e311bc43e05..e96f057ea2a0 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arch/arm64/silicon-errata.rst @@ -52,6 +52,9 @@ stable kernels. | Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ +| Ampere | AmpereOne | AC03_CPU_38 | AMPERE_ERRATUM_AC03_CPU_38 | ++----------------+-----------------+-----------------+-----------------------------+ ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 | @@ -60,6 +63,14 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | @@ -106,14 +117,6 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 | +----------------+-----------------+-----------------+-----------------------------+ -| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 | -+----------------+-----------------+-----------------+-----------------------------+ -| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 | -+----------------+-----------------+-----------------+-----------------------------+ -| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 | -+----------------+-----------------+-----------------+-----------------------------+ -| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 | -+----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 | @@ -140,6 +143,13 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-500 | #841119,826419 | N/A | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | MMU-600 | #1076982,1209401| N/A | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | MMU-700 | #2268618,2812531| N/A | ++----------------+-----------------+-----------------+-----------------------------+ ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | GIC-700 | #2941627 | ARM64_ERRATUM_2941627 | ++----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ | Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_845719 | +----------------+-----------------+-----------------+-----------------------------+ @@ -188,6 +198,9 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A | +----------------+-----------------+-----------------+-----------------------------+ +| Hisilicon | Hip08 SMMU PMCG | #162001900 | N/A | +| | Hip09 SMMU PMCG | | | ++----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ | Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 | +----------------+-----------------+-----------------+-----------------------------+ @@ -214,3 +227,7 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 | +----------------+-----------------+-----------------+-----------------------------+ + ++----------------+-----------------+-----------------+-----------------------------+ +| ASR | ASR8601 | #8601001 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/arm64/sme.rst b/Documentation/arch/arm64/sme.rst index 1c43ea12eb4f..3d0e53ecac4f 100644 --- a/Documentation/arm64/sme.rst +++ b/Documentation/arch/arm64/sme.rst @@ -322,7 +322,7 @@ The regset data starts with struct user_za_header, containing: VL is supported. * The size and layout of the payload depends on the header fields. The - SME_PT_ZA_*() macros are provided to facilitate access to the data. + ZA_PT_ZA*() macros are provided to facilitate access to the data. * In either case, for SETREGSET it is permissible to omit the payload, in which case the vector length and flags are changed and PSTATE.ZA is set to 0 @@ -465,4 +465,4 @@ References [2] arch/arm64/include/uapi/asm/ptrace.h AArch64 Linux ptrace ABI definitions -[3] Documentation/arm64/cpu-feature-registers.rst +[3] Documentation/arch/arm64/cpu-feature-registers.rst diff --git a/Documentation/arm64/sve.rst b/Documentation/arch/arm64/sve.rst index 1b90a30382ac..0d9a426e9f85 100644 --- a/Documentation/arm64/sve.rst +++ b/Documentation/arch/arm64/sve.rst @@ -606,7 +606,7 @@ References [2] arch/arm64/include/uapi/asm/ptrace.h AArch64 Linux ptrace ABI definitions -[3] Documentation/arm64/cpu-feature-registers.rst +[3] Documentation/arch/arm64/cpu-feature-registers.rst [4] ARM IHI0055C http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arch/arm64/tagged-address-abi.rst index 540a1d4fc6c9..fe24a3f158c5 100644 --- a/Documentation/arm64/tagged-address-abi.rst +++ b/Documentation/arch/arm64/tagged-address-abi.rst @@ -107,7 +107,7 @@ following behaviours are guaranteed: A definition of the meaning of tagged pointers on AArch64 can be found -in Documentation/arm64/tagged-pointers.rst. +in Documentation/arch/arm64/tagged-pointers.rst. 3. AArch64 Tagged Address ABI Exceptions ----------------------------------------- diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arch/arm64/tagged-pointers.rst index 19d284b70384..81b6c2a770dd 100644 --- a/Documentation/arm64/tagged-pointers.rst +++ b/Documentation/arch/arm64/tagged-pointers.rst @@ -22,7 +22,7 @@ Passing tagged addresses to the kernel All interpretation of userspace memory addresses by the kernel assumes an address tag of 0x00, unless the application enables the AArch64 Tagged Address ABI explicitly -(Documentation/arm64/tagged-address-abi.rst). +(Documentation/arch/arm64/tagged-address-abi.rst). This includes, but is not limited to, addresses found in: diff --git a/Documentation/arch/index.rst b/Documentation/arch/index.rst index 80ee31016584..84b80255b851 100644 --- a/Documentation/arch/index.rst +++ b/Documentation/arch/index.rst @@ -10,18 +10,18 @@ implementation. :maxdepth: 2 arc/index - ../arm/index - ../arm64/index + arm/index + arm64/index ia64/index - ../loongarch/index + loongarch/index m68k/index - ../mips/index + mips/index nios2/index openrisc/index parisc/index ../powerpc/index ../riscv/index - ../s390/index + s390/index sh/index sparc/index x86/index diff --git a/Documentation/loongarch/booting.rst b/Documentation/arch/loongarch/booting.rst index 91eccd410478..91eccd410478 100644 --- a/Documentation/loongarch/booting.rst +++ b/Documentation/arch/loongarch/booting.rst diff --git a/Documentation/loongarch/features.rst b/Documentation/arch/loongarch/features.rst index ebacade3ea45..ebacade3ea45 100644 --- a/Documentation/loongarch/features.rst +++ b/Documentation/arch/loongarch/features.rst diff --git a/Documentation/loongarch/index.rst b/Documentation/arch/loongarch/index.rst index c779bfa00c05..c779bfa00c05 100644 --- a/Documentation/loongarch/index.rst +++ b/Documentation/arch/loongarch/index.rst diff --git a/Documentation/loongarch/introduction.rst b/Documentation/arch/loongarch/introduction.rst index 49135d451ced..49135d451ced 100644 --- a/Documentation/loongarch/introduction.rst +++ b/Documentation/arch/loongarch/introduction.rst diff --git a/Documentation/loongarch/irq-chip-model.rst b/Documentation/arch/loongarch/irq-chip-model.rst index 7988f4192363..7988f4192363 100644 --- a/Documentation/loongarch/irq-chip-model.rst +++ b/Documentation/arch/loongarch/irq-chip-model.rst diff --git a/Documentation/mips/booting.rst b/Documentation/arch/mips/booting.rst index 7c18a4eab48b..7c18a4eab48b 100644 --- a/Documentation/mips/booting.rst +++ b/Documentation/arch/mips/booting.rst diff --git a/Documentation/mips/features.rst b/Documentation/arch/mips/features.rst index 1973d729b29a..1973d729b29a 100644 --- a/Documentation/mips/features.rst +++ b/Documentation/arch/mips/features.rst diff --git a/Documentation/mips/index.rst b/Documentation/arch/mips/index.rst index 037f85a08fe3..037f85a08fe3 100644 --- a/Documentation/mips/index.rst +++ b/Documentation/arch/mips/index.rst diff --git a/Documentation/mips/ingenic-tcu.rst b/Documentation/arch/mips/ingenic-tcu.rst index 2ce4cb1314dc..2ce4cb1314dc 100644 --- a/Documentation/mips/ingenic-tcu.rst +++ b/Documentation/arch/mips/ingenic-tcu.rst diff --git a/Documentation/arch/openrisc/openrisc_port.rst b/Documentation/arch/openrisc/openrisc_port.rst index 657ac4af7be6..1565b9546e38 100644 --- a/Documentation/arch/openrisc/openrisc_port.rst +++ b/Documentation/arch/openrisc/openrisc_port.rst @@ -106,7 +106,7 @@ History a much improved version with changes all around. 10-04-2004 Matjaz Breskvar (phoenix@bsemi.com) - alot of bugfixes all over. + a lot of bugfixes all over. ethernet support, functional http and telnet servers. running many standard linux apps. @@ -114,7 +114,7 @@ History port to 2.6.x 30-11-2004 Matjaz Breskvar (phoenix@bsemi.com) - lots of bugfixes and enhancments. + lots of bugfixes and enhancements. added opencores framebuffer driver. 09-10-2010 Jonas Bonn (jonas@southpole.se) diff --git a/Documentation/s390/3270.ChangeLog b/Documentation/arch/s390/3270.ChangeLog index ecaf60b6c381..ecaf60b6c381 100644 --- a/Documentation/s390/3270.ChangeLog +++ b/Documentation/arch/s390/3270.ChangeLog diff --git a/Documentation/s390/3270.rst b/Documentation/arch/s390/3270.rst index e09e77954238..467eace91473 100644 --- a/Documentation/s390/3270.rst +++ b/Documentation/arch/s390/3270.rst @@ -116,7 +116,7 @@ Here are the installation steps in detail: as a 3270, not a 3215. 5. Run the 3270 configuration script config3270. It is - distributed in this same directory, Documentation/s390, as + distributed in this same directory, Documentation/arch/s390, as config3270.sh. Inspect the output script it produces, /tmp/mkdev3270, and then run that script. This will create the necessary character special device files and make the necessary @@ -125,7 +125,7 @@ Here are the installation steps in detail: Then notify /sbin/init that /etc/inittab has changed, by issuing the telinit command with the q operand:: - cd Documentation/s390 + cd Documentation/arch/s390 sh config3270.sh sh /tmp/mkdev3270 telinit q diff --git a/Documentation/s390/cds.rst b/Documentation/arch/s390/cds.rst index 7006d8209d2e..bcad2a14244a 100644 --- a/Documentation/s390/cds.rst +++ b/Documentation/arch/s390/cds.rst @@ -39,7 +39,7 @@ some of them are ESA/390 platform specific. Note: In order to write a driver for S/390, you also need to look into the interface - described in Documentation/s390/driver-model.rst. + described in Documentation/arch/s390/driver-model.rst. Note for porting drivers from 2.4: diff --git a/Documentation/s390/common_io.rst b/Documentation/arch/s390/common_io.rst index 846485681ce7..6dcb40cb7145 100644 --- a/Documentation/s390/common_io.rst +++ b/Documentation/arch/s390/common_io.rst @@ -136,5 +136,5 @@ debugfs entries The level of logging can be changed to be more or less verbose by piping to /sys/kernel/debug/s390dbf/cio_*/level a number between 0 and 6; see the - documentation on the S/390 debug feature (Documentation/s390/s390dbf.rst) + documentation on the S/390 debug feature (Documentation/arch/s390/s390dbf.rst) for details. diff --git a/Documentation/s390/config3270.sh b/Documentation/arch/s390/config3270.sh index 515e2f431487..515e2f431487 100644 --- a/Documentation/s390/config3270.sh +++ b/Documentation/arch/s390/config3270.sh diff --git a/Documentation/s390/driver-model.rst b/Documentation/arch/s390/driver-model.rst index ad4bc2dbea43..ad4bc2dbea43 100644 --- a/Documentation/s390/driver-model.rst +++ b/Documentation/arch/s390/driver-model.rst diff --git a/Documentation/s390/features.rst b/Documentation/arch/s390/features.rst index 57c296a9d8f3..57c296a9d8f3 100644 --- a/Documentation/s390/features.rst +++ b/Documentation/arch/s390/features.rst diff --git a/Documentation/s390/index.rst b/Documentation/arch/s390/index.rst index 73c79bf586fd..73c79bf586fd 100644 --- a/Documentation/s390/index.rst +++ b/Documentation/arch/s390/index.rst diff --git a/Documentation/s390/monreader.rst b/Documentation/arch/s390/monreader.rst index 21cdfb699b49..21cdfb699b49 100644 --- a/Documentation/s390/monreader.rst +++ b/Documentation/arch/s390/monreader.rst diff --git a/Documentation/s390/pci.rst b/Documentation/arch/s390/pci.rst index a1a72a47dc96..d5755484d8e7 100644 --- a/Documentation/s390/pci.rst +++ b/Documentation/arch/s390/pci.rst @@ -40,7 +40,7 @@ For example: Change the level of logging to be more or less verbose by piping a number between 0 and 6 to /sys/kernel/debug/s390dbf/pci_*/level. For details, see the documentation on the S/390 debug feature at - Documentation/s390/s390dbf.rst. + Documentation/arch/s390/s390dbf.rst. Sysfs entries ============= diff --git a/Documentation/s390/qeth.rst b/Documentation/arch/s390/qeth.rst index f02fdaa68de0..f02fdaa68de0 100644 --- a/Documentation/s390/qeth.rst +++ b/Documentation/arch/s390/qeth.rst diff --git a/Documentation/s390/s390dbf.rst b/Documentation/arch/s390/s390dbf.rst index af8bdc3629e7..af8bdc3629e7 100644 --- a/Documentation/s390/s390dbf.rst +++ b/Documentation/arch/s390/s390dbf.rst diff --git a/Documentation/s390/text_files.rst b/Documentation/arch/s390/text_files.rst index c94d05d4fa17..c94d05d4fa17 100644 --- a/Documentation/s390/text_files.rst +++ b/Documentation/arch/s390/text_files.rst diff --git a/Documentation/s390/vfio-ap-locking.rst b/Documentation/arch/s390/vfio-ap-locking.rst index 0dfcdb562e21..0dfcdb562e21 100644 --- a/Documentation/s390/vfio-ap-locking.rst +++ b/Documentation/arch/s390/vfio-ap-locking.rst diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/arch/s390/vfio-ap.rst index bb3f4c4e2885..929ee1c1c940 100644 --- a/Documentation/s390/vfio-ap.rst +++ b/Documentation/arch/s390/vfio-ap.rst @@ -422,7 +422,7 @@ Configure the guest's AP resources Configuring the AP resources for a KVM guest will be performed when the VFIO_GROUP_NOTIFY_SET_KVM notifier callback is invoked. The notifier function is called when userspace connects to KVM. The guest's AP resources are -configured via it's APCB by: +configured via its APCB by: * Setting the bits in the APM corresponding to the APIDs assigned to the vfio_ap mediated device via its 'assign_adapter' interface. diff --git a/Documentation/s390/vfio-ccw.rst b/Documentation/arch/s390/vfio-ccw.rst index 37026fa18179..42960b7b0d70 100644 --- a/Documentation/s390/vfio-ccw.rst +++ b/Documentation/arch/s390/vfio-ccw.rst @@ -440,6 +440,6 @@ Reference 1. ESA/s390 Principles of Operation manual (IBM Form. No. SA22-7832) 2. ESA/390 Common I/O Device Commands manual (IBM Form. No. SA22-7204) 3. https://en.wikipedia.org/wiki/Channel_I/O -4. Documentation/s390/cds.rst +4. Documentation/arch/s390/cds.rst 5. Documentation/driver-api/vfio.rst 6. Documentation/driver-api/vfio-mediated-device.rst diff --git a/Documentation/s390/zfcpdump.rst b/Documentation/arch/s390/zfcpdump.rst index a61de7aa8778..a61de7aa8778 100644 --- a/Documentation/s390/zfcpdump.rst +++ b/Documentation/arch/s390/zfcpdump.rst diff --git a/Documentation/arch/x86/boot.rst b/Documentation/arch/x86/boot.rst index 33520ecdb37a..f5d2f2414de8 100644 --- a/Documentation/arch/x86/boot.rst +++ b/Documentation/arch/x86/boot.rst @@ -1105,7 +1105,7 @@ The kernel command line should not be located below the real-mode code, nor should it be located in high memory. -Sample Boot Configuartion +Sample Boot Configuration ========================= As a sample configuration, assume the following layout of the real @@ -1417,7 +1417,7 @@ execution context provided by the EFI firmware. The function prototype for the handover entry point looks like this:: - efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp) + 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 diff --git a/Documentation/arch/x86/buslock.rst b/Documentation/arch/x86/buslock.rst index 31ec0ef78086..4c5a4822eeb7 100644 --- a/Documentation/arch/x86/buslock.rst +++ b/Documentation/arch/x86/buslock.rst @@ -32,7 +32,7 @@ mechanisms to detect split locks and bus locks. -------------------------------------- Beginning with the Tremont Atom CPU split lock operations may raise an -Alignment Check (#AC) exception when a split lock operation is attemped. +Alignment Check (#AC) exception when a split lock operation is attempted. #DB exception for bus lock detection ------------------------------------ diff --git a/Documentation/arch/x86/index.rst b/Documentation/arch/x86/index.rst index c73d133fd37c..8ac64d7de4dc 100644 --- a/Documentation/arch/x86/index.rst +++ b/Documentation/arch/x86/index.rst @@ -22,6 +22,7 @@ x86-specific Documentation mtrr pat intel-hfi + shstk iommu intel_txt amd-memory-encryption diff --git a/Documentation/arch/x86/mds.rst b/Documentation/arch/x86/mds.rst index 5d4330be200f..e73fdff62c0a 100644 --- a/Documentation/arch/x86/mds.rst +++ b/Documentation/arch/x86/mds.rst @@ -60,7 +60,7 @@ needed for exploiting MDS requires: data The existence of such a construct in the kernel cannot be excluded with -100% certainty, but the complexity involved makes it extremly unlikely. +100% certainty, but the complexity involved makes it extremely unlikely. There is one exception, which is untrusted BPF. The functionality of untrusted BPF is limited, but it needs to be thoroughly investigated diff --git a/Documentation/arch/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst index 387ccbcb558f..cb05d90111b4 100644 --- a/Documentation/arch/x86/resctrl.rst +++ b/Documentation/arch/x86/resctrl.rst @@ -287,6 +287,13 @@ Removing a directory will move all tasks and cpus owned by the group it represents to the parent. Removing one of the created CTRL_MON groups will automatically remove all MON groups below it. +Moving MON group directories to a new parent CTRL_MON group is supported +for the purpose of changing the resource allocations of a MON group +without impacting its monitoring data or assigned tasks. This operation +is not allowed for MON groups which monitor CPUs. No other move +operation is currently allowed other than simply renaming a CTRL_MON or +MON group. + All groups contain the following files: "tasks": diff --git a/Documentation/arch/x86/sgx.rst b/Documentation/arch/x86/sgx.rst index 2bcbffacbed5..d90796adc2ec 100644 --- a/Documentation/arch/x86/sgx.rst +++ b/Documentation/arch/x86/sgx.rst @@ -245,7 +245,7 @@ SGX will likely become unusable because the memory available to SGX is limited. However, while this may be fatal to SGX, the rest of the kernel is unlikely to be impacted and should continue to work. -As a result, when this happpens, user should stop running any new +As a result, when this happens, user should stop running any new SGX workloads, (or just any new workloads), and migrate all valuable workloads. Although a machine reboot can recover all EPC memory, the bug should be reported to Linux developers. diff --git a/Documentation/arch/x86/shstk.rst b/Documentation/arch/x86/shstk.rst new file mode 100644 index 000000000000..60260e809baf --- /dev/null +++ b/Documentation/arch/x86/shstk.rst @@ -0,0 +1,179 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================================== +Control-flow Enforcement Technology (CET) Shadow Stack +====================================================== + +CET Background +============== + +Control-flow Enforcement Technology (CET) covers several related x86 processor +features that provide protection against control flow hijacking attacks. CET +can protect both applications and the kernel. + +CET introduces shadow stack and indirect branch tracking (IBT). A shadow stack +is a secondary stack allocated from memory which cannot be directly modified by +applications. When executing a CALL instruction, the processor pushes the +return address to both the normal stack and the shadow stack. Upon +function return, the processor pops the shadow stack copy and compares it +to the normal stack copy. If the two differ, the processor raises a +control-protection fault. IBT verifies indirect CALL/JMP targets are intended +as marked by the compiler with 'ENDBR' opcodes. Not all CPU's have both Shadow +Stack and Indirect Branch Tracking. Today in the 64-bit kernel, only userspace +shadow stack and kernel IBT are supported. + +Requirements to use Shadow Stack +================================ + +To use userspace shadow stack you need HW that supports it, a kernel +configured with it and userspace libraries compiled with it. + +The kernel Kconfig option is X86_USER_SHADOW_STACK. When compiled in, shadow +stacks can be disabled at runtime with the kernel parameter: nousershstk. + +To build a user shadow stack enabled kernel, Binutils v2.29 or LLVM v6 or later +are required. + +At run time, /proc/cpuinfo shows CET features if the processor supports +CET. "user_shstk" means that userspace shadow stack is supported on the current +kernel and HW. + +Application Enabling +==================== + +An application's CET capability is marked in its ELF note and can be verified +from readelf/llvm-readelf output:: + + readelf -n <application> | grep -a SHSTK + properties: x86 feature: SHSTK + +The kernel does not process these applications markers directly. Applications +or loaders must enable CET features using the interface described in section 4. +Typically this would be done in dynamic loader or static runtime objects, as is +the case in GLIBC. + +Enabling arch_prctl()'s +======================= + +Elf features should be enabled by the loader using the below arch_prctl's. They +are only supported in 64 bit user applications. These operate on the features +on a per-thread basis. The enablement status is inherited on clone, so if the +feature is enabled on the first thread, it will propagate to all the thread's +in an app. + +arch_prctl(ARCH_SHSTK_ENABLE, unsigned long feature) + Enable a single feature specified in 'feature'. Can only operate on + one feature at a time. + +arch_prctl(ARCH_SHSTK_DISABLE, unsigned long feature) + Disable a single feature specified in 'feature'. Can only operate on + one feature at a time. + +arch_prctl(ARCH_SHSTK_LOCK, unsigned long features) + Lock in features at their current enabled or disabled status. 'features' + is a mask of all features to lock. All bits set are processed, unset bits + are ignored. The mask is ORed with the existing value. So any feature bits + set here cannot be enabled or disabled afterwards. + +arch_prctl(ARCH_SHSTK_UNLOCK, unsigned long features) + Unlock features. 'features' is a mask of all features to unlock. All + bits set are processed, unset bits are ignored. Only works via ptrace. + +arch_prctl(ARCH_SHSTK_STATUS, unsigned long addr) + Copy the currently enabled features to the address passed in addr. The + features are described using the bits passed into the others in + 'features'. + +The return values are as follows. On success, return 0. On error, errno can +be:: + + -EPERM if any of the passed feature are locked. + -ENOTSUPP if the feature is not supported by the hardware or + kernel. + -EINVAL arguments (non existing feature, etc) + -EFAULT if could not copy information back to userspace + +The feature's bits supported are:: + + ARCH_SHSTK_SHSTK - Shadow stack + ARCH_SHSTK_WRSS - WRSS + +Currently shadow stack and WRSS are supported via this interface. WRSS +can only be enabled with shadow stack, and is automatically disabled +if shadow stack is disabled. + +Proc Status +=========== +To check if an application is actually running with shadow stack, the +user can read the /proc/$PID/status. It will report "wrss" or "shstk" +depending on what is enabled. The lines look like this:: + + x86_Thread_features: shstk wrss + x86_Thread_features_locked: shstk wrss + +Implementation of the Shadow Stack +================================== + +Shadow Stack Size +----------------- + +A task's shadow stack is allocated from memory to a fixed size of +MIN(RLIMIT_STACK, 4 GB). In other words, the shadow stack is allocated to +the maximum size of the normal stack, but capped to 4 GB. In the case +of the clone3 syscall, there is a stack size passed in and shadow stack +uses this instead of the rlimit. + +Signal +------ + +The main program and its signal handlers use the same shadow stack. Because +the shadow stack stores only return addresses, a large shadow stack covers +the condition that both the program stack and the signal alternate stack run +out. + +When a signal happens, the old pre-signal state is pushed on the stack. When +shadow stack is enabled, the shadow stack specific state is pushed onto the +shadow stack. Today this is only the old SSP (shadow stack pointer), pushed +in a special format with bit 63 set. On sigreturn this old SSP token is +verified and restored by the kernel. The kernel will also push the normal +restorer address to the shadow stack to help userspace avoid a shadow stack +violation on the sigreturn path that goes through the restorer. + +So the shadow stack signal frame format is as follows:: + + |1...old SSP| - Pointer to old pre-signal ssp in sigframe token format + (bit 63 set to 1) + | ...| - Other state may be added in the future + + +32 bit ABI signals are not supported in shadow stack processes. Linux prevents +32 bit execution while shadow stack is enabled by the allocating shadow stacks +outside of the 32 bit address space. When execution enters 32 bit mode, either +via far call or returning to userspace, a #GP is generated by the hardware +which, will be delivered to the process as a segfault. When transitioning to +userspace the register's state will be as if the userspace ip being returned to +caused the segfault. + +Fork +---- + +The shadow stack's vma has VM_SHADOW_STACK flag set; its PTEs are required +to be read-only and dirty. When a shadow stack PTE is not RO and dirty, a +shadow access triggers a page fault with the shadow stack access bit set +in the page fault error code. + +When a task forks a child, its shadow stack PTEs are copied and both the +parent's and the child's shadow stack PTEs are cleared of the dirty bit. +Upon the next shadow stack access, the resulting shadow stack page fault +is handled by page copy/re-use. + +When a pthread child is created, the kernel allocates a new shadow stack +for the new thread. New shadow stack creation behaves like mmap() with respect +to ASLR behavior. Similarly, on thread exit the thread's shadow stack is +disabled. + +Exec +---- + +On exec, shadow stack features are disabled by the kernel. At which point, +userspace can choose to re-enable, or lock them. diff --git a/Documentation/arch/xtensa/atomctl.rst b/Documentation/arch/xtensa/atomctl.rst index 1ecbd0ba9a2e..75d174169430 100644 --- a/Documentation/arch/xtensa/atomctl.rst +++ b/Documentation/arch/xtensa/atomctl.rst @@ -23,7 +23,7 @@ doing a Cached (WB) transaction and use the Memory RCW for un-cached operations. For systems without an coherent cache controller, non-MX, we always -use the memory controllers RCW, thought non-MX controlers likely +use the memory controllers RCW, though non-MX controllers likely support the Internal Operation. CUSTOMER-WARNING: diff --git a/Documentation/block/biovecs.rst b/Documentation/block/biovecs.rst index ddb867e0185b..b9dc0c9dbee4 100644 --- a/Documentation/block/biovecs.rst +++ b/Documentation/block/biovecs.rst @@ -134,6 +134,7 @@ Usage of helpers: bio_for_each_bvec_all() bio_first_bvec_all() bio_first_page_all() + bio_first_folio_all() bio_last_bvec_all() * The following helpers iterate over single-page segment. The passed 'struct diff --git a/Documentation/block/data-integrity.rst b/Documentation/block/data-integrity.rst index 07a97aa26668..6a760c0eb192 100644 --- a/Documentation/block/data-integrity.rst +++ b/Documentation/block/data-integrity.rst @@ -209,7 +209,7 @@ will require extra work due to the application tag. sector must be set, and the bio should have all data pages added. It is up to the caller to ensure that the bio does not change while I/O is in progress. - Complete bio with error if prepare failed for some reson. + Complete bio with error if prepare failed for some reason. 5.3 Passing Existing Integrity Metadata diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst index 1713b2890abb..ff74b3ec4a98 100644 --- a/Documentation/block/ublk.rst +++ b/Documentation/block/ublk.rst @@ -238,7 +238,7 @@ The's IO is assigned by a unique tag, which is 1:1 mapping with IO request of ``/dev/ublkb*``. UAPI structure of ``ublksrv_io_desc`` is defined for describing each IO from -the driver. A fixed mmaped area (array) on ``/dev/ublkc*`` is provided for +the driver. A fixed mmapped area (array) on ``/dev/ublkc*`` is provided for exporting IO info to the server; such as IO offset, length, OP/flags and buffer address. Each ``ublksrv_io_desc`` instance can be indexed via queue id and IO tag directly. diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst index 38372a956d65..eb19c945f4d5 100644 --- a/Documentation/bpf/bpf_design_QA.rst +++ b/Documentation/bpf/bpf_design_QA.rst @@ -140,11 +140,6 @@ A: Because if we picked one-to-one relationship to x64 it would have made it more complicated to support on arm64 and other archs. Also it needs div-by-zero runtime check. -Q: Why there is no BPF_SDIV for signed divide operation? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A: Because it would be rarely used. llvm errors in such case and -prints a suggestion to use unsigned divide instead. - Q: Why BPF has implicit prologue and epilogue? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A: Because architectures like sparc have register windows and in general diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst index 609b71f5747d..de27e1620821 100644 --- a/Documentation/bpf/bpf_devel_QA.rst +++ b/Documentation/bpf/bpf_devel_QA.rst @@ -635,12 +635,12 @@ test coverage. Q: clang flag for target bpf? ----------------------------- -Q: In some cases clang flag ``-target bpf`` is used but in other cases the +Q: In some cases clang flag ``--target=bpf`` is used but in other cases the default clang target, which matches the underlying architecture, is used. What is the difference and when I should use which? A: Although LLVM IR generation and optimization try to stay architecture -independent, ``-target <arch>`` still has some impact on generated code: +independent, ``--target=<arch>`` still has some impact on generated code: - BPF program may recursively include header file(s) with file scope inline assembly codes. The default target can handle this well, @@ -658,7 +658,7 @@ independent, ``-target <arch>`` still has some impact on generated code: The clang option ``-fno-jump-tables`` can be used to disable switch table generation. -- For clang ``-target bpf``, it is guaranteed that pointer or long / +- For clang ``--target=bpf``, it is guaranteed that pointer or long / unsigned long types will always have a width of 64 bit, no matter whether underlying clang binary or default target (or kernel) is 32 bit. However, when native clang target is used, then it will @@ -668,7 +668,7 @@ independent, ``-target <arch>`` still has some impact on generated code: while the BPF LLVM back end still operates in 64 bit. The native target is mostly needed in tracing for the case of walking ``pt_regs`` or other kernel structures where CPU's register width matters. - Otherwise, ``clang -target bpf`` is generally recommended. + Otherwise, ``clang --target=bpf`` is generally recommended. You should use default target when: @@ -685,7 +685,7 @@ when: into these structures is verified by the BPF verifier and may result in verification failures if the native architecture is not aligned with the BPF architecture, e.g. 64-bit. An example of this is - BPF_PROG_TYPE_SK_MSG require ``-target bpf`` + BPF_PROG_TYPE_SK_MSG require ``--target=bpf`` .. Links diff --git a/Documentation/bpf/bpf_iterators.rst b/Documentation/bpf/bpf_iterators.rst index 6d7770793fab..07433915aa41 100644 --- a/Documentation/bpf/bpf_iterators.rst +++ b/Documentation/bpf/bpf_iterators.rst @@ -238,11 +238,8 @@ The following is the breakdown for each field in struct ``bpf_iter_reg``. that the kernel function cond_resched() is called to avoid other kernel subsystem (e.g., rcu) misbehaving. * - seq_info - - Specifies certain action requests in the kernel BPF iterator - infrastructure. Currently, only BPF_ITER_RESCHED is supported. This means - that the kernel function cond_resched() is called to avoid other kernel - subsystem (e.g., rcu) misbehaving. - + - Specifies the set of seq operations for the BPF iterator and helpers to + initialize/free the private data for the corresponding ``seq_file``. `Click here <https://lore.kernel.org/bpf/20210212183107.50963-2-songliubraving@fb.com/>`_ diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst index 7cd7c5415a99..f32db1f44ae9 100644 --- a/Documentation/bpf/btf.rst +++ b/Documentation/bpf/btf.rst @@ -990,7 +990,7 @@ format.:: } g2; int main() { return 0; } int test() { return 0; } - -bash-4.4$ clang -c -g -O2 -target bpf t2.c + -bash-4.4$ clang -c -g -O2 --target=bpf t2.c -bash-4.4$ readelf -S t2.o ...... [ 8] .BTF PROGBITS 0000000000000000 00000247 @@ -1000,7 +1000,7 @@ format.:: [10] .rel.BTF.ext REL 0000000000000000 000007e0 0000000000000040 0000000000000010 16 9 8 ...... - -bash-4.4$ clang -S -g -O2 -target bpf t2.c + -bash-4.4$ clang -S -g -O2 --target=bpf t2.c -bash-4.4$ cat t2.s ...... .section .BTF,"",@progbits diff --git a/Documentation/bpf/cpumasks.rst b/Documentation/bpf/cpumasks.rst index 41efd8874eeb..a22b6ad105fb 100644 --- a/Documentation/bpf/cpumasks.rst +++ b/Documentation/bpf/cpumasks.rst @@ -351,19 +351,20 @@ In addition to the above kfuncs, there is also a set of read-only kfuncs that can be used to query the contents of cpumasks. .. kernel-doc:: kernel/bpf/cpumask.c - :identifiers: bpf_cpumask_first bpf_cpumask_first_zero bpf_cpumask_test_cpu + :identifiers: bpf_cpumask_first bpf_cpumask_first_zero bpf_cpumask_first_and + bpf_cpumask_test_cpu .. kernel-doc:: kernel/bpf/cpumask.c :identifiers: bpf_cpumask_equal bpf_cpumask_intersects bpf_cpumask_subset bpf_cpumask_empty bpf_cpumask_full .. kernel-doc:: kernel/bpf/cpumask.c - :identifiers: bpf_cpumask_any bpf_cpumask_any_and + :identifiers: bpf_cpumask_any_distribute bpf_cpumask_any_and_distribute ---- Some example usages of these querying kfuncs were shown above. We will not -replicate those exmaples here. Note, however, that all of the aforementioned +replicate those examples here. Note, however, that all of the aforementioned kfuncs are tested in `tools/testing/selftests/bpf/progs/cpumask_success.c`_, so please take a look there if you're looking for more examples of how they can be used. diff --git a/Documentation/bpf/graph_ds_impl.rst b/Documentation/bpf/graph_ds_impl.rst index 61274622b71d..06288cc719b3 100644 --- a/Documentation/bpf/graph_ds_impl.rst +++ b/Documentation/bpf/graph_ds_impl.rst @@ -23,7 +23,7 @@ Introduction The BPF map API has historically been the main way to expose data structures of various types for use within BPF programs. Some data structures fit naturally -with the map API (HASH, ARRAY), others less so. Consequentially, programs +with the map API (HASH, ARRAY), others less so. Consequently, programs interacting with the latter group of data structures can be hard to parse for kernel programmers without previous BPF experience. diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index dbb39e8f9889..1ff177b89d66 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -12,9 +12,9 @@ that goes into great technical depth about the BPF Architecture. .. toctree:: :maxdepth: 1 - instruction-set verifier libbpf/index + standardization/index btf faq syscall_api @@ -29,7 +29,6 @@ that goes into great technical depth about the BPF Architecture. bpf_licensing test_debug clang-notes - linux-notes other redirect diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst index ea2516374d92..0d2647fb358d 100644 --- a/Documentation/bpf/kfuncs.rst +++ b/Documentation/bpf/kfuncs.rst @@ -100,7 +100,7 @@ Hence, whenever a constant scalar argument is accepted by a kfunc which is not a size parameter, and the value of the constant matters for program safety, __k suffix should be used. -2.2.2 __uninit Annotation +2.2.3 __uninit Annotation ------------------------- This annotation is used to indicate that the argument will be treated as @@ -117,6 +117,27 @@ Here, the dynptr will be treated as an uninitialized dynptr. Without this annotation, the verifier will reject the program if the dynptr passed in is not initialized. +2.2.4 __opt Annotation +------------------------- + +This annotation is used to indicate that the buffer associated with an __sz or __szk +argument may be null. If the function is passed a nullptr in place of the buffer, +the verifier will not check that length is appropriate for the buffer. The kfunc is +responsible for checking if this buffer is null before using it. + +An example is given below:: + + __bpf_kfunc void *bpf_dynptr_slice(..., void *buffer__opt, u32 buffer__szk) + { + ... + } + +Here, the buffer may be null. If buffer is not null, it at least of size buffer_szk. +Either way, the returned buffer is either NULL, or of size buffer_szk. Without this +annotation, the verifier will reject the program if a null pointer is passed in with +a nonzero size. + + .. _BPF_kfunc_nodef: 2.3 Using an existing kernel function @@ -206,23 +227,49 @@ absolutely no ABI stability guarantees. As mentioned above, a nested pointer obtained from walking a trusted pointer is no longer trusted, with one exception. If a struct type has a field that is -guaranteed to be valid as long as its parent pointer is trusted, the -``BTF_TYPE_SAFE_NESTED`` macro can be used to express that to the verifier as -follows: +guaranteed to be valid (trusted or rcu, as in KF_RCU description below) as long +as its parent pointer is valid, the following macros can be used to express +that to the verifier: + +* ``BTF_TYPE_SAFE_TRUSTED`` +* ``BTF_TYPE_SAFE_RCU`` +* ``BTF_TYPE_SAFE_RCU_OR_NULL`` + +For example, + +.. code-block:: c + + BTF_TYPE_SAFE_TRUSTED(struct socket) { + struct sock *sk; + }; + +or .. code-block:: c - BTF_TYPE_SAFE_NESTED(struct task_struct) { + BTF_TYPE_SAFE_RCU(struct task_struct) { const cpumask_t *cpus_ptr; + struct css_set __rcu *cgroups; + struct task_struct __rcu *real_parent; + struct task_struct *group_leader; }; In other words, you must: -1. Wrap the trusted pointer type in the ``BTF_TYPE_SAFE_NESTED`` macro. +1. Wrap the valid pointer type in a ``BTF_TYPE_SAFE_*`` macro. -2. Specify the type and name of the trusted nested field. This field must match +2. Specify the type and name of the valid nested field. This field must match the field in the original type definition exactly. +A new type declared by a ``BTF_TYPE_SAFE_*`` macro also needs to be emitted so +that it appears in BTF. For example, ``BTF_TYPE_SAFE_TRUSTED(struct socket)`` +is emitted in the ``type_is_trusted()`` function as follows: + +.. code-block:: c + + BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct socket)); + + 2.4.5 KF_SLEEPABLE flag ----------------------- diff --git a/Documentation/bpf/llvm_reloc.rst b/Documentation/bpf/llvm_reloc.rst index ca8957d5b671..450e6403fe3d 100644 --- a/Documentation/bpf/llvm_reloc.rst +++ b/Documentation/bpf/llvm_reloc.rst @@ -28,7 +28,7 @@ For example, for the following code:: return g1 + g2 + l1 + l2; } -Compiled with ``clang -target bpf -O2 -c test.c``, the following is +Compiled with ``clang --target=bpf -O2 -c test.c``, the following is the code with ``llvm-objdump -dr test.o``:: 0: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll @@ -48,7 +48,7 @@ the code with ``llvm-objdump -dr test.o``:: 14: 0f 10 00 00 00 00 00 00 r0 += r1 15: 95 00 00 00 00 00 00 00 exit -There are four relations in the above for four ``LD_imm64`` instructions. +There are four relocations in the above for four ``LD_imm64`` instructions. The following ``llvm-readelf -r test.o`` shows the binary values of the four relocations:: @@ -79,14 +79,16 @@ The following is the symbol table with ``llvm-readelf -s test.o``:: The 6th entry is global variable ``g1`` with value 0. Similarly, the second relocation is at ``.text`` offset ``0x18``, instruction 3, -for global variable ``g2`` which has a symbol value 4, the offset -from the start of ``.data`` section. - -The third and fourth relocations refers to static variables ``l1`` -and ``l2``. From ``.rel.text`` section above, it is not clear -which symbols they really refers to as they both refers to +has a type of ``R_BPF_64_64`` and refers to entry 7 in the symbol table. +The second relocation resolves to global variable ``g2`` which has a symbol +value 4. The symbol value represents the offset from the start of ``.data`` +section where the initial value of the global variable ``g2`` is stored. + +The third and fourth relocations refer to static variables ``l1`` +and ``l2``. From the ``.rel.text`` section above, it is not clear +to which symbols they really refer as they both refer to symbol table entry 4, symbol ``sec``, which has ``STT_SECTION`` type -and represents a section. So for static variable or function, +and represents a section. So for a static variable or function, the section offset is written to the original insn buffer, which is called ``A`` (addend). Looking at above insn ``7`` and ``11``, they have section offset ``8`` and ``12``. @@ -155,7 +157,7 @@ and ``call`` instructions. For example:: return gfunc(a, b) + lfunc(a, b) + global; } -Compiled with ``clang -target bpf -O2 -c test.c``, we will have +Compiled with ``clang --target=bpf -O2 -c test.c``, we will have following code with `llvm-objdump -dr test.o``:: Disassembly of section .text: @@ -201,7 +203,7 @@ The following is an example to show how R_BPF_64_ABS64 could be generated:: int global() { return 0; } struct t { void *g; } gbl = { global }; -Compiled with ``clang -target bpf -O2 -g -c test.c``, we will see a +Compiled with ``clang --target=bpf -O2 -g -c test.c``, we will see a relocation below in ``.data`` section with command ``llvm-readelf -r test.o``:: diff --git a/Documentation/bpf/map_hash.rst b/Documentation/bpf/map_hash.rst index 8669426264c6..d2343952f2cb 100644 --- a/Documentation/bpf/map_hash.rst +++ b/Documentation/bpf/map_hash.rst @@ -1,5 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0-only .. Copyright (C) 2022 Red Hat, Inc. +.. Copyright (C) 2022-2023 Isovalent, Inc. =============================================== BPF_MAP_TYPE_HASH, with PERCPU and LRU Variants @@ -29,7 +30,16 @@ will automatically evict the least recently used entries when the hash table reaches capacity. An LRU hash maintains an internal LRU list that is used to select elements for eviction. This internal LRU list is shared across CPUs but it is possible to request a per CPU LRU list with -the ``BPF_F_NO_COMMON_LRU`` flag when calling ``bpf_map_create``. +the ``BPF_F_NO_COMMON_LRU`` flag when calling ``bpf_map_create``. The +following table outlines the properties of LRU maps depending on the a +map type and the flags used to create the map. + +======================== ========================= ================================ +Flag ``BPF_MAP_TYPE_LRU_HASH`` ``BPF_MAP_TYPE_LRU_PERCPU_HASH`` +======================== ========================= ================================ +**BPF_F_NO_COMMON_LRU** Per-CPU LRU, global map Per-CPU LRU, per-cpu map +**!BPF_F_NO_COMMON_LRU** Global LRU, global map Global LRU, per-cpu map +======================== ========================= ================================ Usage ===== @@ -206,3 +216,44 @@ Userspace walking the map elements from the map declared above: cur_key = &next_key; } } + +Internals +========= + +This section of the document is targeted at Linux developers and describes +aspects of the map implementations that are not considered stable ABI. The +following details are subject to change in future versions of the kernel. + +``BPF_MAP_TYPE_LRU_HASH`` and variants +-------------------------------------- + +Updating elements in LRU maps may trigger eviction behaviour when the capacity +of the map is reached. There are various steps that the update algorithm +attempts in order to enforce the LRU property which have increasing impacts on +other CPUs involved in the following operation attempts: + +- Attempt to use CPU-local state to batch operations +- Attempt to fetch free nodes from global lists +- Attempt to pull any node from a global list and remove it from the hashmap +- Attempt to pull any node from any CPU's list and remove it from the hashmap + +This algorithm is described visually in the following diagram. See the +description in commit 3a08c2fd7634 ("bpf: LRU List") for a full explanation of +the corresponding operations: + +.. kernel-figure:: map_lru_hash_update.dot + :alt: Diagram outlining the LRU eviction steps taken during map update. + + LRU hash eviction during map update for ``BPF_MAP_TYPE_LRU_HASH`` and + variants. See the dot file source for kernel function name code references. + +Map updates start from the oval in the top right "begin ``bpf_map_update()``" +and progress through the graph towards the bottom where the result may be +either a successful update or a failure with various error codes. The key in +the top right provides indicators for which locks may be involved in specific +operations. This is intended as a visual hint for reasoning about how map +contention may impact update operations, though the map type and flags may +impact the actual contention on those locks, based on the logic described in +the table above. For instance, if the map is created with type +``BPF_MAP_TYPE_LRU_PERCPU_HASH`` and flags ``BPF_F_NO_COMMON_LRU`` then all map +properties would be per-cpu. diff --git a/Documentation/bpf/map_lru_hash_update.dot b/Documentation/bpf/map_lru_hash_update.dot new file mode 100644 index 000000000000..a0fee349d29c --- /dev/null +++ b/Documentation/bpf/map_lru_hash_update.dot @@ -0,0 +1,172 @@ +// SPDX-License-Identifier: GPL-2.0-only +// Copyright (C) 2022-2023 Isovalent, Inc. +digraph { + node [colorscheme=accent4,style=filled] # Apply colorscheme to all nodes + graph [splines=ortho, nodesep=1] + + subgraph cluster_key { + label = "Key\n(locks held during operation)"; + rankdir = TB; + + remote_lock [shape=rectangle,fillcolor=4,label="remote CPU LRU lock"] + hash_lock [shape=rectangle,fillcolor=3,label="hashtab lock"] + lru_lock [shape=rectangle,fillcolor=2,label="LRU lock"] + local_lock [shape=rectangle,fillcolor=1,label="local CPU LRU lock"] + no_lock [shape=rectangle,label="no locks held"] + } + + begin [shape=oval,label="begin\nbpf_map_update()"] + + // Nodes below with an 'fn_' prefix are roughly labeled by the C function + // names that initiate the corresponding logic in kernel/bpf/bpf_lru_list.c. + // Number suffixes and errno suffixes handle subsections of the corresponding + // logic in the function as of the writing of this dot. + + // cf. __local_list_pop_free() / bpf_percpu_lru_pop_free() + local_freelist_check [shape=diamond,fillcolor=1, + label="Local freelist\nnode available?"]; + use_local_node [shape=rectangle, + label="Use node owned\nby this CPU"] + + // cf. bpf_lru_pop_free() + common_lru_check [shape=diamond, + label="Map created with\ncommon LRU?\n(!BPF_F_NO_COMMON_LRU)"]; + + fn_bpf_lru_list_pop_free_to_local [shape=rectangle,fillcolor=2, + label="Flush local pending, + Rotate Global list, move + LOCAL_FREE_TARGET + from global -> local"] + // Also corresponds to: + // fn__local_list_flush() + // fn_bpf_lru_list_rotate() + fn___bpf_lru_node_move_to_free[shape=diamond,fillcolor=2, + label="Able to free\nLOCAL_FREE_TARGET\nnodes?"] + + fn___bpf_lru_list_shrink_inactive [shape=rectangle,fillcolor=3, + label="Shrink inactive list + up to remaining + LOCAL_FREE_TARGET + (global LRU -> local)"] + fn___bpf_lru_list_shrink [shape=diamond,fillcolor=2, + label="> 0 entries in\nlocal free list?"] + fn___bpf_lru_list_shrink2 [shape=rectangle,fillcolor=2, + label="Steal one node from + inactive, or if empty, + from active global list"] + fn___bpf_lru_list_shrink3 [shape=rectangle,fillcolor=3, + label="Try to remove\nnode from hashtab"] + + local_freelist_check2 [shape=diamond,label="Htab removal\nsuccessful?"] + common_lru_check2 [shape=diamond, + label="Map created with\ncommon LRU?\n(!BPF_F_NO_COMMON_LRU)"]; + + subgraph cluster_remote_lock { + label = "Iterate through CPUs\n(start from current)"; + style = dashed; + rankdir=LR; + + local_freelist_check5 [shape=diamond,fillcolor=4, + label="Steal a node from\nper-cpu freelist?"] + local_freelist_check6 [shape=rectangle,fillcolor=4, + label="Steal a node from + (1) Unreferenced pending, or + (2) Any pending node"] + local_freelist_check7 [shape=rectangle,fillcolor=3, + label="Try to remove\nnode from hashtab"] + fn_htab_lru_map_update_elem [shape=diamond, + label="Stole node\nfrom remote\nCPU?"] + fn_htab_lru_map_update_elem2 [shape=diamond,label="Iterated\nall CPUs?"] + // Also corresponds to: + // use_local_node() + // fn__local_list_pop_pending() + } + + fn_bpf_lru_list_pop_free_to_local2 [shape=rectangle, + label="Use node that was\nnot recently referenced"] + local_freelist_check4 [shape=rectangle, + label="Use node that was\nactively referenced\nin global list"] + fn_htab_lru_map_update_elem_ENOMEM [shape=oval,label="return -ENOMEM"] + fn_htab_lru_map_update_elem3 [shape=rectangle, + label="Use node that was\nactively referenced\nin (another?) CPU's cache"] + fn_htab_lru_map_update_elem4 [shape=rectangle,fillcolor=3, + label="Update hashmap\nwith new element"] + fn_htab_lru_map_update_elem5 [shape=oval,label="return 0"] + fn_htab_lru_map_update_elem_EBUSY [shape=oval,label="return -EBUSY"] + fn_htab_lru_map_update_elem_EEXIST [shape=oval,label="return -EEXIST"] + fn_htab_lru_map_update_elem_ENOENT [shape=oval,label="return -ENOENT"] + + begin -> local_freelist_check + local_freelist_check -> use_local_node [xlabel="Y"] + local_freelist_check -> common_lru_check [xlabel="N"] + common_lru_check -> fn_bpf_lru_list_pop_free_to_local [xlabel="Y"] + common_lru_check -> fn___bpf_lru_list_shrink_inactive [xlabel="N"] + fn_bpf_lru_list_pop_free_to_local -> fn___bpf_lru_node_move_to_free + fn___bpf_lru_node_move_to_free -> + fn_bpf_lru_list_pop_free_to_local2 [xlabel="Y"] + fn___bpf_lru_node_move_to_free -> + fn___bpf_lru_list_shrink_inactive [xlabel="N"] + fn___bpf_lru_list_shrink_inactive -> fn___bpf_lru_list_shrink + fn___bpf_lru_list_shrink -> fn_bpf_lru_list_pop_free_to_local2 [xlabel = "Y"] + fn___bpf_lru_list_shrink -> fn___bpf_lru_list_shrink2 [xlabel="N"] + fn___bpf_lru_list_shrink2 -> fn___bpf_lru_list_shrink3 + fn___bpf_lru_list_shrink3 -> local_freelist_check2 + local_freelist_check2 -> local_freelist_check4 [xlabel = "Y"] + local_freelist_check2 -> common_lru_check2 [xlabel = "N"] + common_lru_check2 -> local_freelist_check5 [xlabel = "Y"] + common_lru_check2 -> fn_htab_lru_map_update_elem_ENOMEM [xlabel = "N"] + local_freelist_check5 -> fn_htab_lru_map_update_elem [xlabel = "Y"] + local_freelist_check5 -> local_freelist_check6 [xlabel = "N"] + local_freelist_check6 -> local_freelist_check7 + local_freelist_check7 -> fn_htab_lru_map_update_elem + + fn_htab_lru_map_update_elem -> fn_htab_lru_map_update_elem3 [xlabel = "Y"] + fn_htab_lru_map_update_elem -> fn_htab_lru_map_update_elem2 [xlabel = "N"] + fn_htab_lru_map_update_elem2 -> + fn_htab_lru_map_update_elem_ENOMEM [xlabel = "Y"] + fn_htab_lru_map_update_elem2 -> local_freelist_check5 [xlabel = "N"] + fn_htab_lru_map_update_elem3 -> fn_htab_lru_map_update_elem4 + + use_local_node -> fn_htab_lru_map_update_elem4 + fn_bpf_lru_list_pop_free_to_local2 -> fn_htab_lru_map_update_elem4 + local_freelist_check4 -> fn_htab_lru_map_update_elem4 + + fn_htab_lru_map_update_elem4 -> fn_htab_lru_map_update_elem5 [headlabel="Success"] + fn_htab_lru_map_update_elem4 -> + fn_htab_lru_map_update_elem_EBUSY [xlabel="Hashtab lock failed"] + fn_htab_lru_map_update_elem4 -> + fn_htab_lru_map_update_elem_EEXIST [xlabel="BPF_EXIST set and\nkey already exists"] + fn_htab_lru_map_update_elem4 -> + fn_htab_lru_map_update_elem_ENOENT [headlabel="BPF_NOEXIST set\nand no such entry"] + + // Create invisible pad nodes to line up various nodes + pad0 [style=invis] + pad1 [style=invis] + pad2 [style=invis] + pad3 [style=invis] + pad4 [style=invis] + + // Line up the key with the top of the graph + no_lock -> local_lock [style=invis] + local_lock -> lru_lock [style=invis] + lru_lock -> hash_lock [style=invis] + hash_lock -> remote_lock [style=invis] + remote_lock -> local_freelist_check5 [style=invis] + remote_lock -> fn___bpf_lru_list_shrink [style=invis] + + // Line up return code nodes at the bottom of the graph + fn_htab_lru_map_update_elem -> pad0 [style=invis] + pad0 -> pad1 [style=invis] + pad1 -> pad2 [style=invis] + //pad2-> fn_htab_lru_map_update_elem_ENOMEM [style=invis] + fn_htab_lru_map_update_elem4 -> pad3 [style=invis] + pad3 -> fn_htab_lru_map_update_elem5 [style=invis] + pad3 -> fn_htab_lru_map_update_elem_EBUSY [style=invis] + pad3 -> fn_htab_lru_map_update_elem_EEXIST [style=invis] + pad3 -> fn_htab_lru_map_update_elem_ENOENT [style=invis] + + // Reduce diagram width by forcing some nodes to appear above others + local_freelist_check4 -> fn_htab_lru_map_update_elem3 [style=invis] + common_lru_check2 -> pad4 [style=invis] + pad4 -> local_freelist_check5 [style=invis] +} diff --git a/Documentation/bpf/map_sockmap.rst b/Documentation/bpf/map_sockmap.rst index cc92047c6630..2d630686a00b 100644 --- a/Documentation/bpf/map_sockmap.rst +++ b/Documentation/bpf/map_sockmap.rst @@ -240,11 +240,11 @@ offsets into ``msg``, respectively. If a program of type ``BPF_PROG_TYPE_SK_MSG`` is run on a ``msg`` it can only parse data that the (``data``, ``data_end``) pointers have already consumed. For ``sendmsg()`` hooks this is likely the first scatterlist element. But for -calls relying on the ``sendpage`` handler (e.g., ``sendfile()``) this will be -the range (**0**, **0**) because the data is shared with user space and by -default the objective is to avoid allowing user space to modify data while (or -after) BPF verdict is being decided. This helper can be used to pull in data -and to set the start and end pointers to given values. Data will be copied if +calls relying on MSG_SPLICE_PAGES (e.g., ``sendfile()``) this will be the +range (**0**, **0**) because the data is shared with user space and by default +the objective is to avoid allowing user space to modify data while (or after) +BPF verdict is being decided. This helper can be used to pull in data and to +set the start and end pointers to given values. Data will be copied if necessary (i.e., if data was not linear and if start and end pointers do not point to the same chunk). diff --git a/Documentation/bpf/prog_cgroup_sockopt.rst b/Documentation/bpf/prog_cgroup_sockopt.rst index 172f957204bf..1226a94af07a 100644 --- a/Documentation/bpf/prog_cgroup_sockopt.rst +++ b/Documentation/bpf/prog_cgroup_sockopt.rst @@ -98,10 +98,65 @@ can access only the first ``PAGE_SIZE`` of that data. So it has to options: indicates that the kernel should use BPF's trimmed ``optval``. When the BPF program returns with the ``optlen`` greater than -``PAGE_SIZE``, the userspace will receive ``EFAULT`` errno. +``PAGE_SIZE``, the userspace will receive original kernel +buffers without any modifications that the BPF program might have +applied. Example ======= +Recommended way to handle BPF programs is as follows: + +.. code-block:: c + + SEC("cgroup/getsockopt") + int getsockopt(struct bpf_sockopt *ctx) + { + /* Custom socket option. */ + if (ctx->level == MY_SOL && ctx->optname == MY_OPTNAME) { + ctx->retval = 0; + optval[0] = ...; + ctx->optlen = 1; + return 1; + } + + /* Modify kernel's socket option. */ + if (ctx->level == SOL_IP && ctx->optname == IP_FREEBIND) { + ctx->retval = 0; + optval[0] = ...; + ctx->optlen = 1; + return 1; + } + + /* optval larger than PAGE_SIZE use kernel's buffer. */ + if (ctx->optlen > PAGE_SIZE) + ctx->optlen = 0; + + return 1; + } + + SEC("cgroup/setsockopt") + int setsockopt(struct bpf_sockopt *ctx) + { + /* Custom socket option. */ + if (ctx->level == MY_SOL && ctx->optname == MY_OPTNAME) { + /* do something */ + ctx->optlen = -1; + return 1; + } + + /* Modify kernel's socket option. */ + if (ctx->level == SOL_IP && ctx->optname == IP_FREEBIND) { + optval[0] = ...; + return 1; + } + + /* optval larger than PAGE_SIZE use kernel's buffer. */ + if (ctx->optlen > PAGE_SIZE) + ctx->optlen = 0; + + return 1; + } + See ``tools/testing/selftests/bpf/progs/sockopt_sk.c`` for an example of BPF program that handles socket options. diff --git a/Documentation/bpf/standardization/index.rst b/Documentation/bpf/standardization/index.rst new file mode 100644 index 000000000000..09c6ba055fd7 --- /dev/null +++ b/Documentation/bpf/standardization/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +=================== +BPF Standardization +=================== + +This directory contains documents that are being iterated on as part of the BPF +standardization effort with the IETF. See the `IETF BPF Working Group`_ page +for the working group charter, documents, and more. + +.. toctree:: + :maxdepth: 1 + + instruction-set + linux-notes + +.. Links: +.. _IETF BPF Working Group: https://datatracker.ietf.org/wg/bpf/about/ diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst index 492980ece1ab..4f73e9dc8d9e 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -10,9 +10,92 @@ This document specifies version 1.0 of the eBPF instruction set. Documentation conventions ========================= -For brevity, this document uses the type notion "u64", "u32", etc. -to mean an unsigned integer whose width is the specified number of bits, -and "s32", etc. to mean a signed integer of the specified number of bits. +For brevity and consistency, this document refers to families +of types using a shorthand syntax and refers to several expository, +mnemonic functions when describing the semantics of instructions. +The range of valid values for those types and the semantics of those +functions are defined in the following subsections. + +Types +----- +This document refers to integer types with the notation `SN` to specify +a type's signedness (`S`) and bit width (`N`), respectively. + +.. table:: Meaning of signedness notation. + + ==== ========= + `S` Meaning + ==== ========= + `u` unsigned + `s` signed + ==== ========= + +.. table:: Meaning of bit-width notation. + + ===== ========= + `N` Bit width + ===== ========= + `8` 8 bits + `16` 16 bits + `32` 32 bits + `64` 64 bits + `128` 128 bits + ===== ========= + +For example, `u32` is a type whose valid values are all the 32-bit unsigned +numbers and `s16` is a types whose valid values are all the 16-bit signed +numbers. + +Functions +--------- +* `htobe16`: Takes an unsigned 16-bit number in host-endian format and + returns the equivalent number as an unsigned 16-bit number in big-endian + format. +* `htobe32`: Takes an unsigned 32-bit number in host-endian format and + returns the equivalent number as an unsigned 32-bit number in big-endian + format. +* `htobe64`: Takes an unsigned 64-bit number in host-endian format and + returns the equivalent number as an unsigned 64-bit number in big-endian + format. +* `htole16`: Takes an unsigned 16-bit number in host-endian format and + returns the equivalent number as an unsigned 16-bit number in little-endian + format. +* `htole32`: Takes an unsigned 32-bit number in host-endian format and + returns the equivalent number as an unsigned 32-bit number in little-endian + format. +* `htole64`: Takes an unsigned 64-bit number in host-endian format and + returns the equivalent number as an unsigned 64-bit number in little-endian + format. +* `bswap16`: Takes an unsigned 16-bit number in either big- or little-endian + format and returns the equivalent number with the same bit width but + opposite endianness. +* `bswap32`: Takes an unsigned 32-bit number in either big- or little-endian + format and returns the equivalent number with the same bit width but + opposite endianness. +* `bswap64`: Takes an unsigned 64-bit number in either big- or little-endian + format and returns the equivalent number with the same bit width but + opposite endianness. + + +Definitions +----------- + +.. glossary:: + + Sign Extend + To `sign extend an` ``X`` `-bit number, A, to a` ``Y`` `-bit number, B ,` means to + + #. Copy all ``X`` bits from `A` to the lower ``X`` bits of `B`. + #. Set the value of the remaining ``Y`` - ``X`` bits of `B` to the value of + the most-significant bit of `A`. + +.. admonition:: Example + + Sign extend an 8-bit number ``A`` to a 16-bit number ``B`` on a big-endian platform: + :: + + A: 10000110 + B: 11111111 10000110 Registers and calling convention ================================ @@ -154,24 +237,27 @@ otherwise identical operations. The 'code' field encodes the operation as below, where 'src' and 'dst' refer to the values of the source and destination registers, respectively. -======== ===== ========================================================== -code value description -======== ===== ========================================================== -BPF_ADD 0x00 dst += src -BPF_SUB 0x10 dst -= src -BPF_MUL 0x20 dst \*= src -BPF_DIV 0x30 dst = (src != 0) ? (dst / src) : 0 -BPF_OR 0x40 dst \|= src -BPF_AND 0x50 dst &= src -BPF_LSH 0x60 dst <<= src -BPF_RSH 0x70 dst >>= src -BPF_NEG 0x80 dst = ~src -BPF_MOD 0x90 dst = (src != 0) ? (dst % src) : dst -BPF_XOR 0xa0 dst ^= src -BPF_MOV 0xb0 dst = src -BPF_ARSH 0xc0 sign extending shift right -BPF_END 0xd0 byte swap operations (see `Byte swap instructions`_ below) -======== ===== ========================================================== +========= ===== ======= ========================================================== +code value offset description +========= ===== ======= ========================================================== +BPF_ADD 0x00 0 dst += src +BPF_SUB 0x10 0 dst -= src +BPF_MUL 0x20 0 dst \*= src +BPF_DIV 0x30 0 dst = (src != 0) ? (dst / src) : 0 +BPF_SDIV 0x30 1 dst = (src != 0) ? (dst s/ src) : 0 +BPF_OR 0x40 0 dst \|= src +BPF_AND 0x50 0 dst &= src +BPF_LSH 0x60 0 dst <<= (src & mask) +BPF_RSH 0x70 0 dst >>= (src & mask) +BPF_NEG 0x80 0 dst = -dst +BPF_MOD 0x90 0 dst = (src != 0) ? (dst % src) : dst +BPF_SMOD 0x90 1 dst = (src != 0) ? (dst s% src) : dst +BPF_XOR 0xa0 0 dst ^= src +BPF_MOV 0xb0 0 dst = src +BPF_MOVSX 0xb0 8/16/32 dst = (s8,s16,s32)src +BPF_ARSH 0xc0 0 :term:`sign extending<Sign Extend>` dst >>= (src & mask) +BPF_END 0xd0 0 byte swap operations (see `Byte swap instructions`_ below) +========= ===== ======= ========================================================== Underflow and overflow are allowed during arithmetic operations, meaning the 64-bit or 32-bit value will wrap. If eBPF program execution would @@ -198,44 +284,75 @@ where '(u32)' indicates that the upper 32 bits are zeroed. dst = dst ^ imm32 -Also note that the division and modulo operations are unsigned. Thus, for -``BPF_ALU``, 'imm' is first interpreted as an unsigned 32-bit value, whereas -for ``BPF_ALU64``, 'imm' is first sign extended to 64 bits and the result -interpreted as an unsigned 64-bit value. There are no instructions for -signed division or modulo. +Note that most instructions have instruction offset of 0. Only three instructions +(``BPF_SDIV``, ``BPF_SMOD``, ``BPF_MOVSX``) have a non-zero offset. + +The division and modulo operations support both unsigned and signed flavors. + +For unsigned operations (``BPF_DIV`` and ``BPF_MOD``), for ``BPF_ALU``, +'imm' is interpreted as a 32-bit unsigned value. For ``BPF_ALU64``, +'imm' is first :term:`sign extended<Sign Extend>` from 32 to 64 bits, and then +interpreted as a 64-bit unsigned value. + +For signed operations (``BPF_SDIV`` and ``BPF_SMOD``), for ``BPF_ALU``, +'imm' is interpreted as a 32-bit signed value. For ``BPF_ALU64``, 'imm' +is first :term:`sign extended<Sign Extend>` from 32 to 64 bits, and then +interpreted as a 64-bit signed value. + +The ``BPF_MOVSX`` instruction does a move operation with sign extension. +``BPF_ALU | BPF_MOVSX`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into 32 +bit operands, and zeroes the remaining upper 32 bits. +``BPF_ALU64 | BPF_MOVSX`` :term:`sign extends<Sign Extend>` 8-bit, 16-bit, and 32-bit +operands into 64 bit operands. + +Shift operations use a mask of 0x3F (63) for 64-bit operations and 0x1F (31) +for 32-bit operations. Byte swap instructions -~~~~~~~~~~~~~~~~~~~~~~ +---------------------- -The byte swap instructions use an instruction class of ``BPF_ALU`` and a 4-bit -'code' field of ``BPF_END``. +The byte swap instructions use instruction classes of ``BPF_ALU`` and ``BPF_ALU64`` +and a 4-bit 'code' field of ``BPF_END``. The byte swap instructions operate on the destination register only and do not use a separate source register or immediate value. -The 1-bit source operand field in the opcode is used to select what byte -order the operation convert from or to: +For ``BPF_ALU``, the 1-bit source operand field in the opcode is used to +select what byte order the operation converts from or to. For +``BPF_ALU64``, the 1-bit source operand field in the opcode is reserved +and must be set to 0. -========= ===== ================================================= -source value description -========= ===== ================================================= -BPF_TO_LE 0x00 convert between host byte order and little endian -BPF_TO_BE 0x08 convert between host byte order and big endian -========= ===== ================================================= +========= ========= ===== ================================================= +class source value description +========= ========= ===== ================================================= +BPF_ALU BPF_TO_LE 0x00 convert between host byte order and little endian +BPF_ALU BPF_TO_BE 0x08 convert between host byte order and big endian +BPF_ALU64 Reserved 0x00 do byte swap unconditionally +========= ========= ===== ================================================= The 'imm' field encodes the width of the swap operations. The following widths are supported: 16, 32 and 64. Examples: -``BPF_ALU | BPF_TO_LE | BPF_END`` with imm = 16 means:: +``BPF_ALU | BPF_TO_LE | BPF_END`` with imm = 16/32/64 means:: dst = htole16(dst) + dst = htole32(dst) + dst = htole64(dst) -``BPF_ALU | BPF_TO_BE | BPF_END`` with imm = 64 means:: +``BPF_ALU | BPF_TO_BE | BPF_END`` with imm = 16/32/64 means:: + dst = htobe16(dst) + dst = htobe32(dst) dst = htobe64(dst) +``BPF_ALU64 | BPF_TO_LE | BPF_END`` with imm = 16/32/64 means:: + + dst = bswap16(dst) + dst = bswap32(dst) + dst = bswap64(dst) + Jump instructions ----------------- @@ -246,7 +363,8 @@ The 'code' field encodes the operation as below: ======== ===== === =========================================== ========================================= code value src description notes ======== ===== === =========================================== ========================================= -BPF_JA 0x0 0x0 PC += offset BPF_JMP only +BPF_JA 0x0 0x0 PC += offset BPF_JMP class +BPF_JA 0x0 0x0 PC += imm BPF_JMP32 class BPF_JEQ 0x1 any PC += offset if dst == src BPF_JGT 0x2 any PC += offset if dst > src unsigned BPF_JGE 0x3 any PC += offset if dst >= src unsigned @@ -275,6 +393,19 @@ Example: where 's>=' indicates a signed '>=' comparison. +``BPF_JA | BPF_K | BPF_JMP32`` (0x06) means:: + + gotol +imm + +where 'imm' means the branch offset comes from insn 'imm' field. + +Note that there are two flavors of ``BPF_JA`` instructions. The +``BPF_JMP`` class permits a 16-bit jump offset specified by the 'offset' +field, whereas the ``BPF_JMP32`` class permits a 32-bit jump offset +specified by the 'imm' field. A > 16-bit conditional jump may be +converted to a < 16-bit conditional jump plus a 32-bit unconditional +jump. + Helper functions ~~~~~~~~~~~~~~~~ @@ -317,6 +448,7 @@ The mode modifier is one of: BPF_ABS 0x20 legacy BPF packet access (absolute) `Legacy BPF Packet access instructions`_ BPF_IND 0x40 legacy BPF packet access (indirect) `Legacy BPF Packet access instructions`_ BPF_MEM 0x60 regular load and store operations `Regular load and store operations`_ + BPF_MEMSX 0x80 sign-extension load operations `Sign-extension load operations`_ BPF_ATOMIC 0xc0 atomic operations `Atomic operations`_ ============= ===== ==================================== ============= @@ -347,9 +479,23 @@ instructions that transfer data between a register and memory. ``BPF_MEM | <size> | BPF_LDX`` means:: - dst = *(size *) (src + offset) + dst = *(unsigned size *) (src + offset) + +Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW`` and +'unsigned size' is one of u8, u16, u32 or u64. + +Sign-extension load operations +------------------------------ + +The ``BPF_MEMSX`` mode modifier is used to encode :term:`sign-extension<Sign Extend>` load +instructions that transfer data between a register and memory. + +``BPF_MEMSX | <size> | BPF_LDX`` means:: + + dst = *(signed size *) (src + offset) -Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW``. +Where size is one of: ``BPF_B``, ``BPF_H`` or ``BPF_W``, and +'signed size' is one of s8, s16 or s32. Atomic operations ----------------- diff --git a/Documentation/bpf/linux-notes.rst b/Documentation/bpf/standardization/linux-notes.rst index 508d009d3bed..00d2693de025 100644 --- a/Documentation/bpf/linux-notes.rst +++ b/Documentation/bpf/standardization/linux-notes.rst @@ -45,7 +45,8 @@ On Linux, this integer is a BTF ID. Legacy BPF Packet access instructions ===================================== -As mentioned in the `ISA standard documentation <instruction-set.rst#legacy-bpf-packet-access-instructions>`_, +As mentioned in the `ISA standard documentation +<instruction-set.html#legacy-bpf-packet-access-instructions>`_, Linux has special eBPF instructions for access to packet data that have been carried over from classic BPF to retain the performance of legacy socket filters running in the eBPF interpreter. diff --git a/Documentation/conf.py b/Documentation/conf.py index 37314afd1ac8..d4fdf6a3875a 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -74,6 +74,7 @@ if major >= 3: "__percpu", "__rcu", "__user", + "__force", # include/linux/compiler_attributes.h: "__alias", diff --git a/Documentation/core-api/cachetlb.rst b/Documentation/core-api/cachetlb.rst index 5c0552e78c58..889fc84ccd1b 100644 --- a/Documentation/core-api/cachetlb.rst +++ b/Documentation/core-api/cachetlb.rst @@ -88,13 +88,17 @@ changes occur: This is used primarily during fault processing. -5) ``void update_mmu_cache(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep)`` +5) ``void update_mmu_cache_range(struct vm_fault *vmf, + struct vm_area_struct *vma, unsigned long address, pte_t *ptep, + unsigned int nr)`` - At the end of every page fault, this routine is invoked to - tell the architecture specific code that a translation - now exists at virtual address "address" for address space - "vma->vm_mm", in the software page tables. + At the end of every page fault, this routine is invoked to tell + the architecture specific code that translations now exists + in the software page tables for address space "vma->vm_mm" + at virtual address "address" for "nr" consecutive pages. + + This routine is also invoked in various other places which pass + a NULL "vmf". A port may use this information in any way it so chooses. For example, it could use this event to pre-load TLB @@ -269,7 +273,7 @@ maps this page at its virtual address. If D-cache aliasing is not an issue, these two routines may simply call memcpy/memset directly and do nothing more. - ``void flush_dcache_page(struct page *page)`` + ``void flush_dcache_folio(struct folio *folio)`` This routines must be called when: @@ -277,7 +281,7 @@ maps this page at its virtual address. and / or in high memory b) the kernel is about to read from a page cache page and user space shared/writable mappings of this page potentially exist. Note - that {get,pin}_user_pages{_fast} already call flush_dcache_page + that {get,pin}_user_pages{_fast} already call flush_dcache_folio on any page found in the user address space and thus driver code rarely needs to take this into account. @@ -291,7 +295,7 @@ maps this page at its virtual address. The phrase "kernel writes to a page cache page" means, specifically, that the kernel executes store instructions that dirty data in that - page at the page->virtual mapping of that page. It is important to + page at the kernel virtual mapping of that page. It is important to flush here to handle D-cache aliasing, to make sure these kernel stores are visible to user space mappings of that page. @@ -302,21 +306,22 @@ maps this page at its virtual address. If D-cache aliasing is not an issue, this routine may simply be defined as a nop on that architecture. - There is a bit set aside in page->flags (PG_arch_1) as "architecture + There is a bit set aside in folio->flags (PG_arch_1) as "architecture private". The kernel guarantees that, for pagecache pages, it will clear this bit when such a page first enters the pagecache. - This allows these interfaces to be implemented much more efficiently. - It allows one to "defer" (perhaps indefinitely) the actual flush if - there are currently no user processes mapping this page. See sparc64's - flush_dcache_page and update_mmu_cache implementations for an example - of how to go about doing this. + This allows these interfaces to be implemented much more + efficiently. It allows one to "defer" (perhaps indefinitely) the + actual flush if there are currently no user processes mapping this + page. See sparc64's flush_dcache_folio and update_mmu_cache_range + implementations for an example of how to go about doing this. - The idea is, first at flush_dcache_page() time, if page_file_mapping() - returns a mapping, and mapping_mapped on that mapping returns %false, - just mark the architecture private page flag bit. Later, in - update_mmu_cache(), a check is made of this flag bit, and if set the - flush is done and the flag bit is cleared. + The idea is, first at flush_dcache_folio() time, if + folio_flush_mapping() returns a mapping, and mapping_mapped() on that + mapping returns %false, just mark the architecture private page + flag bit. Later, in update_mmu_cache_range(), a check is made + of this flag bit, and if set the flush is done and the flag bit + is cleared. .. important:: @@ -326,12 +331,6 @@ maps this page at its virtual address. dirty. Again, see sparc64 for examples of how to deal with this. - ``void flush_dcache_folio(struct folio *folio)`` - This function is called under the same circumstances as - flush_dcache_page(). It allows the architecture to - optimise for flushing the entire folio of pages instead - of flushing one page at a time. - ``void copy_to_user_page(struct vm_area_struct *vma, struct page *page, unsigned long user_vaddr, void *dst, void *src, int len)`` ``void copy_from_user_page(struct vm_area_struct *vma, struct page *page, @@ -352,7 +351,7 @@ maps this page at its virtual address. When the kernel needs to access the contents of an anonymous page, it calls this function (currently only - get_user_pages()). Note: flush_dcache_page() deliberately + get_user_pages()). Note: flush_dcache_folio() deliberately doesn't work for an anonymous page. The default implementation is a nop (and should remain so for all coherent architectures). For incoherent architectures, it should flush @@ -369,7 +368,7 @@ maps this page at its virtual address. ``void flush_icache_page(struct vm_area_struct *vma, struct page *page)`` All the functionality of flush_icache_page can be implemented in - flush_dcache_page and update_mmu_cache. In the future, the hope + flush_dcache_folio and update_mmu_cache_range. In the future, the hope is to remove this interface completely. The final category of APIs is for I/O to deliberately aliased address diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst index f75778d37488..9511e405aabd 100644 --- a/Documentation/core-api/cpu_hotplug.rst +++ b/Documentation/core-api/cpu_hotplug.rst @@ -127,17 +127,8 @@ bring CPU4 back online:: $ echo 1 > /sys/devices/system/cpu/cpu4/online smpboot: Booting Node 0 Processor 4 APIC 0x1 -The CPU is usable again. This should work on all CPUs. CPU0 is often special -and excluded from CPU hotplug. On X86 the kernel option -*CONFIG_BOOTPARAM_HOTPLUG_CPU0* has to be enabled in order to be able to -shutdown CPU0. Alternatively the kernel command option *cpu0_hotplug* can be -used. Some known dependencies of CPU0: - -* Resume from hibernate/suspend. Hibernate/suspend will fail if CPU0 is offline. -* PIC interrupts. CPU0 can't be removed if a PIC interrupt is detected. - -Please let Fenghua Yu <fenghua.yu@intel.com> know if you find any dependencies -on CPU0. +The CPU is usable again. This should work on all CPUs, but CPU0 is often special +and excluded from CPU hotplug. The CPU hotplug coordination ============================ @@ -404,8 +395,8 @@ multi-instance state the following function is available: * cpuhp_setup_state_multi(state, name, startup, teardown) The @state argument is either a statically allocated state or one of the -constants for dynamically allocated states - CPUHP_PREPARE_DYN, -CPUHP_ONLINE_DYN - depending on the state section (PREPARE, ONLINE) for +constants for dynamically allocated states - CPUHP_BP_PREPARE_DYN, +CPUHP_AP_ONLINE_DYN - depending on the state section (PREPARE, ONLINE) for which a dynamic state should be allocated. The @name argument is used for sysfs output and for instrumentation. The @@ -597,7 +588,7 @@ notifications on online and offline operations:: Setup and teardown a dynamically allocated state in the ONLINE section for notifications on offline operations:: - state = cpuhp_setup_state(CPUHP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline); + state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline); if (state < 0) return state; .... @@ -606,7 +597,7 @@ for notifications on offline operations:: Setup and teardown a dynamically allocated state in the ONLINE section for notifications on online operations without invoking the callbacks:: - state = cpuhp_setup_state_nocalls(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL); + state = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL); if (state < 0) return state; .... @@ -615,7 +606,7 @@ for notifications on online operations without invoking the callbacks:: Setup, use and teardown a dynamically allocated multi-instance state in the ONLINE section for notifications on online and offline operation:: - state = cpuhp_setup_state_multi(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline); + state = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline); if (state < 0) return state; .... @@ -750,6 +741,24 @@ will receive all events. A script like:: can process the event further. +When changes to the CPUs in the system occur, the sysfs file +/sys/devices/system/cpu/crash_hotplug contains '1' if the kernel +updates the kdump capture kernel list of CPUs itself (via elfcorehdr), +or '0' if userspace must update the kdump capture kernel list of CPUs. + +The availability depends on the CONFIG_HOTPLUG_CPU kernel configuration +option. + +To skip userspace processing of CPU hot un/plug events for kdump +(i.e. the unload-then-reload to obtain a current list of CPUs), this sysfs +file can be used in a udev rule as follows: + + SUBSYSTEM=="cpu", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end" + +For a CPU hot un/plug event, if the architecture supports kernel updates +of the elfcorehdr (which contains the list of CPUs), then the rule skips +the unload-then-reload of the kdump capture kernel. + Kernel Inline Documentations Reference ====================================== diff --git a/Documentation/core-api/genericirq.rst b/Documentation/core-api/genericirq.rst index f959c9b53f61..4a460639ab1c 100644 --- a/Documentation/core-api/genericirq.rst +++ b/Documentation/core-api/genericirq.rst @@ -264,7 +264,7 @@ The following control flow is implemented (simplified excerpt):: desc->irq_data.chip->irq_unmask(); desc->status &= ~pending; handle_irq_event(desc->action); - } while (status & pending); + } while (desc->status & pending); desc->status &= ~running; diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 9b3f3e5f5a95..ae92a2571388 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -96,6 +96,12 @@ Command-line Parsing .. kernel-doc:: lib/cmdline.c :export: +Error Pointers +-------------- + +.. kernel-doc:: include/linux/err.h + :internal: + Sorting ------- @@ -156,8 +162,10 @@ Base 2 log and power Functions .. kernel-doc:: include/linux/log2.h :internal: -Integer power Functions ------------------------ +Integer log and power Functions +------------------------------- + +.. kernel-doc:: include/linux/int_log.h .. kernel-doc:: lib/math/int_pow.c :export: @@ -412,3 +420,15 @@ Read-Copy Update (RCU) .. kernel-doc:: include/linux/rcu_sync.h .. kernel-doc:: kernel/rcu/sync.c + +.. kernel-doc:: kernel/rcu/tasks.h + +.. kernel-doc:: kernel/rcu/tree_stall.h + +.. kernel-doc:: include/linux/rcupdate_trace.h + +.. kernel-doc:: include/linux/rcupdate_wait.h + +.. kernel-doc:: include/linux/rcuref.h + +.. kernel-doc:: include/linux/rcutree.h diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst index f5dde5bceaea..2d091c873d1e 100644 --- a/Documentation/core-api/mm-api.rst +++ b/Documentation/core-api/mm-api.rst @@ -115,3 +115,28 @@ More Memory Management Functions .. kernel-doc:: include/linux/mmzone.h .. kernel-doc:: mm/util.c :functions: folio_mapping + +.. kernel-doc:: mm/rmap.c +.. kernel-doc:: mm/migrate.c +.. kernel-doc:: mm/mmap.c +.. kernel-doc:: mm/kmemleak.c +.. #kernel-doc:: mm/hmm.c (build warnings) +.. kernel-doc:: mm/memremap.c +.. kernel-doc:: mm/hugetlb.c +.. kernel-doc:: mm/swap.c +.. kernel-doc:: mm/zpool.c +.. kernel-doc:: mm/memcontrol.c +.. #kernel-doc:: mm/memory-tiers.c (build warnings) +.. kernel-doc:: mm/shmem.c +.. kernel-doc:: mm/migrate_device.c +.. #kernel-doc:: mm/nommu.c (duplicates kernel-doc from other files) +.. kernel-doc:: mm/mapping_dirty_helpers.c +.. #kernel-doc:: mm/memory-failure.c (build warnings) +.. kernel-doc:: mm/percpu.c +.. kernel-doc:: mm/maccess.c +.. kernel-doc:: mm/vmscan.c +.. kernel-doc:: mm/memory_hotplug.c +.. kernel-doc:: mm/mmu_notifier.c +.. kernel-doc:: mm/balloon_compaction.c +.. kernel-doc:: mm/huge_memory.c +.. kernel-doc:: mm/io-mapping.c diff --git a/Documentation/core-api/netlink.rst b/Documentation/core-api/netlink.rst index e4a938a05cc9..9f692b02bfe6 100644 --- a/Documentation/core-api/netlink.rst +++ b/Documentation/core-api/netlink.rst @@ -67,10 +67,11 @@ Globals kernel-policy ~~~~~~~~~~~~~ -Defines if the kernel validation policy is per operation (``per-op``) -or for the entire family (``global``). New families should use ``per-op`` -(default) to be able to narrow down the attributes accepted by a specific -command. +Defines whether the kernel validation policy is ``global`` i.e. the same for all +operations of the family, defined for each operation individually - ``per-op``, +or separately for each operation and operation type (do vs dump) - ``split``. +New families should use ``per-op`` (default) to be able to narrow down the +attributes accepted by a specific command. checks ------ diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst index 9fb0b1080d3b..d3c1f6d8c0e0 100644 --- a/Documentation/core-api/pin_user_pages.rst +++ b/Documentation/core-api/pin_user_pages.rst @@ -112,6 +112,12 @@ pages: This also leads to limitations: there are only 31-10==21 bits available for a counter that increments 10 bits at a time. +* Because of that limitation, special handling is applied to the zero pages + when using FOLL_PIN. We only pretend to pin a zero page - we don't alter its + refcount or pincount at all (it is permanent, so there's no need). The + unpinning functions also don't do anything to a zero page. This is + transparent to the caller. + * Callers must specifically request "dma-pinned tracking of pages". In other words, just calling get_user_pages() will not suffice; a new set of functions, pin_user_page() and related, must be used. diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index dfe7e75a71de..4451ef501936 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -15,9 +15,10 @@ Integer types If variable is of Type, use printk format specifier: ------------------------------------------------------------ - char %d or %x + signed char %d or %hhx unsigned char %u or %x - short int %d or %x + char %u or %x + short int %d or %hx unsigned short int %u or %x int %d or %x unsigned int %u or %x @@ -27,9 +28,9 @@ Integer types unsigned long long %llu or %llx size_t %zu or %zx ssize_t %zd or %zx - s8 %d or %x + s8 %d or %hhx u8 %u or %x - s16 %d or %x + s16 %d or %hx u16 %u or %x s32 %d or %x u32 %u or %x diff --git a/Documentation/core-api/this_cpu_ops.rst b/Documentation/core-api/this_cpu_ops.rst index 5cb8b883ae83..91acbcf30e9b 100644 --- a/Documentation/core-api/this_cpu_ops.rst +++ b/Documentation/core-api/this_cpu_ops.rst @@ -53,7 +53,6 @@ preemption and interrupts:: this_cpu_add_return(pcp, val) this_cpu_xchg(pcp, nval) this_cpu_cmpxchg(pcp, oval, nval) - this_cpu_cmpxchg_double(pcp1, pcp2, oval1, oval2, nval1, nval2) this_cpu_sub(pcp, val) this_cpu_inc(pcp) this_cpu_dec(pcp) @@ -242,7 +241,6 @@ safe:: __this_cpu_add_return(pcp, val) __this_cpu_xchg(pcp, nval) __this_cpu_cmpxchg(pcp, oval, nval) - __this_cpu_cmpxchg_double(pcp1, pcp2, oval1, oval2, nval1, nval2) __this_cpu_sub(pcp, val) __this_cpu_inc(pcp) __this_cpu_dec(pcp) diff --git a/Documentation/core-api/workqueue.rst b/Documentation/core-api/workqueue.rst index 8ec4d6270b24..5d7b01aed1fe 100644 --- a/Documentation/core-api/workqueue.rst +++ b/Documentation/core-api/workqueue.rst @@ -1,6 +1,6 @@ -==================================== -Concurrency Managed Workqueue (cmwq) -==================================== +========= +Workqueue +========= :Date: September, 2010 :Author: Tejun Heo <tj@kernel.org> @@ -25,8 +25,8 @@ there is no work item left on the workqueue the worker becomes idle. When a new work item gets queued, the worker begins executing again. -Why cmwq? -========= +Why Concurrency Managed Workqueue? +================================== In the original wq implementation, a multi threaded (MT) wq had one worker thread per CPU and a single threaded (ST) wq had one worker @@ -220,17 +220,16 @@ resources, scheduled and executed. ``max_active`` -------------- -``@max_active`` determines the maximum number of execution contexts -per CPU which can be assigned to the work items of a wq. For example, -with ``@max_active`` of 16, at most 16 work items of the wq can be -executing at the same time per CPU. +``@max_active`` determines the maximum number of execution contexts per +CPU which can be assigned to the work items of a wq. For example, with +``@max_active`` of 16, at most 16 work items of the wq can be executing +at the same time per CPU. This is always a per-CPU attribute, even for +unbound workqueues. -Currently, for a bound wq, the maximum limit for ``@max_active`` is -512 and the default value used when 0 is specified is 256. For an -unbound wq, the limit is higher of 512 and 4 * -``num_possible_cpus()``. These values are chosen sufficiently high -such that they are not the limiting factor while providing protection -in runaway cases. +The maximum limit for ``@max_active`` is 512 and the default value used +when 0 is specified is 256. These values are chosen sufficiently high +such that they are not the limiting factor while providing protection in +runaway cases. The number of active work items of a wq is usually regulated by the users of the wq, more specifically, by how many work items the users @@ -348,6 +347,356 @@ Guidelines level of locality in wq operations and work item execution. +Affinity Scopes +=============== + +An unbound workqueue groups CPUs according to its affinity scope to improve +cache locality. For example, if a workqueue is using the default affinity +scope of "cache", it will group CPUs according to last level cache +boundaries. A work item queued on the workqueue will be assigned to a worker +on one of the CPUs which share the last level cache with the issuing CPU. +Once started, the worker may or may not be allowed to move outside the scope +depending on the ``affinity_strict`` setting of the scope. + +Workqueue currently supports the following affinity scopes. + +``default`` + Use the scope in module parameter ``workqueue.default_affinity_scope`` + which is always set to one of the scopes below. + +``cpu`` + CPUs are not grouped. A work item issued on one CPU is processed by a + worker on the same CPU. This makes unbound workqueues behave as per-cpu + workqueues without concurrency management. + +``smt`` + CPUs are grouped according to SMT boundaries. This usually means that the + logical threads of each physical CPU core are grouped together. + +``cache`` + CPUs are grouped according to cache boundaries. Which specific cache + boundary is used is determined by the arch code. L3 is used in a lot of + cases. This is the default affinity scope. + +``numa`` + CPUs are grouped according to NUMA bounaries. + +``system`` + All CPUs are put in the same group. Workqueue makes no effort to process a + work item on a CPU close to the issuing CPU. + +The default affinity scope can be changed with the module parameter +``workqueue.default_affinity_scope`` and a specific workqueue's affinity +scope can be changed using ``apply_workqueue_attrs()``. + +If ``WQ_SYSFS`` is set, the workqueue will have the following affinity scope +related interface files under its ``/sys/devices/virtual/WQ_NAME/`` +directory. + +``affinity_scope`` + Read to see the current affinity scope. Write to change. + + When default is the current scope, reading this file will also show the + current effective scope in parentheses, for example, ``default (cache)``. + +``affinity_strict`` + 0 by default indicating that affinity scopes are not strict. When a work + item starts execution, workqueue makes a best-effort attempt to ensure + that the worker is inside its affinity scope, which is called + repatriation. Once started, the scheduler is free to move the worker + anywhere in the system as it sees fit. This enables benefiting from scope + locality while still being able to utilize other CPUs if necessary and + available. + + If set to 1, all workers of the scope are guaranteed always to be in the + scope. This may be useful when crossing affinity scopes has other + implications, for example, in terms of power consumption or workload + isolation. Strict NUMA scope can also be used to match the workqueue + behavior of older kernels. + + +Affinity Scopes and Performance +=============================== + +It'd be ideal if an unbound workqueue's behavior is optimal for vast +majority of use cases without further tuning. Unfortunately, in the current +kernel, there exists a pronounced trade-off between locality and utilization +necessitating explicit configurations when workqueues are heavily used. + +Higher locality leads to higher efficiency where more work is performed for +the same number of consumed CPU cycles. However, higher locality may also +cause lower overall system utilization if the work items are not spread +enough across the affinity scopes by the issuers. The following performance +testing with dm-crypt clearly illustrates this trade-off. + +The tests are run on a CPU with 12-cores/24-threads split across four L3 +caches (AMD Ryzen 9 3900x). CPU clock boost is turned off for consistency. +``/dev/dm-0`` is a dm-crypt device created on NVME SSD (Samsung 990 PRO) and +opened with ``cryptsetup`` with default settings. + + +Scenario 1: Enough issuers and work spread across the machine +------------------------------------------------------------- + +The command used: :: + + $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k --ioengine=libaio \ + --iodepth=64 --runtime=60 --numjobs=24 --time_based --group_reporting \ + --name=iops-test-job --verify=sha512 + +There are 24 issuers, each issuing 64 IOs concurrently. ``--verify=sha512`` +makes ``fio`` generate and read back the content each time which makes +execution locality matter between the issuer and ``kcryptd``. The followings +are the read bandwidths and CPU utilizations depending on different affinity +scope settings on ``kcryptd`` measured over five runs. Bandwidths are in +MiBps, and CPU util in percents. + +.. list-table:: + :widths: 16 20 20 + :header-rows: 1 + + * - Affinity + - Bandwidth (MiBps) + - CPU util (%) + + * - system + - 1159.40 ±1.34 + - 99.31 ±0.02 + + * - cache + - 1166.40 ±0.89 + - 99.34 ±0.01 + + * - cache (strict) + - 1166.00 ±0.71 + - 99.35 ±0.01 + +With enough issuers spread across the system, there is no downside to +"cache", strict or otherwise. All three configurations saturate the whole +machine but the cache-affine ones outperform by 0.6% thanks to improved +locality. + + +Scenario 2: Fewer issuers, enough work for saturation +----------------------------------------------------- + +The command used: :: + + $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \ + --ioengine=libaio --iodepth=64 --runtime=60 --numjobs=8 \ + --time_based --group_reporting --name=iops-test-job --verify=sha512 + +The only difference from the previous scenario is ``--numjobs=8``. There are +a third of the issuers but is still enough total work to saturate the +system. + +.. list-table:: + :widths: 16 20 20 + :header-rows: 1 + + * - Affinity + - Bandwidth (MiBps) + - CPU util (%) + + * - system + - 1155.40 ±0.89 + - 97.41 ±0.05 + + * - cache + - 1154.40 ±1.14 + - 96.15 ±0.09 + + * - cache (strict) + - 1112.00 ±4.64 + - 93.26 ±0.35 + +This is more than enough work to saturate the system. Both "system" and +"cache" are nearly saturating the machine but not fully. "cache" is using +less CPU but the better efficiency puts it at the same bandwidth as +"system". + +Eight issuers moving around over four L3 cache scope still allow "cache +(strict)" to mostly saturate the machine but the loss of work conservation +is now starting to hurt with 3.7% bandwidth loss. + + +Scenario 3: Even fewer issuers, not enough work to saturate +----------------------------------------------------------- + +The command used: :: + + $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \ + --ioengine=libaio --iodepth=64 --runtime=60 --numjobs=4 \ + --time_based --group_reporting --name=iops-test-job --verify=sha512 + +Again, the only difference is ``--numjobs=4``. With the number of issuers +reduced to four, there now isn't enough work to saturate the whole system +and the bandwidth becomes dependent on completion latencies. + +.. list-table:: + :widths: 16 20 20 + :header-rows: 1 + + * - Affinity + - Bandwidth (MiBps) + - CPU util (%) + + * - system + - 993.60 ±1.82 + - 75.49 ±0.06 + + * - cache + - 973.40 ±1.52 + - 74.90 ±0.07 + + * - cache (strict) + - 828.20 ±4.49 + - 66.84 ±0.29 + +Now, the tradeoff between locality and utilization is clearer. "cache" shows +2% bandwidth loss compared to "system" and "cache (struct)" whopping 20%. + + +Conclusion and Recommendations +------------------------------ + +In the above experiments, the efficiency advantage of the "cache" affinity +scope over "system" is, while consistent and noticeable, small. However, the +impact is dependent on the distances between the scopes and may be more +pronounced in processors with more complex topologies. + +While the loss of work-conservation in certain scenarios hurts, it is a lot +better than "cache (strict)" and maximizing workqueue utilization is +unlikely to be the common case anyway. As such, "cache" is the default +affinity scope for unbound pools. + +* As there is no one option which is great for most cases, workqueue usages + that may consume a significant amount of CPU are recommended to configure + the workqueues using ``apply_workqueue_attrs()`` and/or enable + ``WQ_SYSFS``. + +* An unbound workqueue with strict "cpu" affinity scope behaves the same as + ``WQ_CPU_INTENSIVE`` per-cpu workqueue. There is no real advanage to the + latter and an unbound workqueue provides a lot more flexibility. + +* Affinity scopes are introduced in Linux v6.5. To emulate the previous + behavior, use strict "numa" affinity scope. + +* The loss of work-conservation in non-strict affinity scopes is likely + originating from the scheduler. There is no theoretical reason why the + kernel wouldn't be able to do the right thing and maintain + work-conservation in most cases. As such, it is possible that future + scheduler improvements may make most of these tunables unnecessary. + + +Examining Configuration +======================= + +Use tools/workqueue/wq_dump.py to examine unbound CPU affinity +configuration, worker pools and how workqueues map to the pools: :: + + $ tools/workqueue/wq_dump.py + Affinity Scopes + =============== + wq_unbound_cpumask=0000000f + + CPU + nr_pods 4 + pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008 + pod_node [0]=0 [1]=0 [2]=1 [3]=1 + cpu_pod [0]=0 [1]=1 [2]=2 [3]=3 + + SMT + nr_pods 4 + pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008 + pod_node [0]=0 [1]=0 [2]=1 [3]=1 + cpu_pod [0]=0 [1]=1 [2]=2 [3]=3 + + CACHE (default) + nr_pods 2 + pod_cpus [0]=00000003 [1]=0000000c + pod_node [0]=0 [1]=1 + cpu_pod [0]=0 [1]=0 [2]=1 [3]=1 + + NUMA + nr_pods 2 + pod_cpus [0]=00000003 [1]=0000000c + pod_node [0]=0 [1]=1 + cpu_pod [0]=0 [1]=0 [2]=1 [3]=1 + + SYSTEM + nr_pods 1 + pod_cpus [0]=0000000f + pod_node [0]=-1 + cpu_pod [0]=0 [1]=0 [2]=0 [3]=0 + + Worker Pools + ============ + pool[00] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 0 + pool[01] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 0 + pool[02] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 1 + pool[03] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 1 + pool[04] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 2 + pool[05] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 2 + pool[06] ref= 1 nice= 0 idle/workers= 3/ 3 cpu= 3 + pool[07] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 3 + pool[08] ref=42 nice= 0 idle/workers= 6/ 6 cpus=0000000f + pool[09] ref=28 nice= 0 idle/workers= 3/ 3 cpus=00000003 + pool[10] ref=28 nice= 0 idle/workers= 17/ 17 cpus=0000000c + pool[11] ref= 1 nice=-20 idle/workers= 1/ 1 cpus=0000000f + pool[12] ref= 2 nice=-20 idle/workers= 1/ 1 cpus=00000003 + pool[13] ref= 2 nice=-20 idle/workers= 1/ 1 cpus=0000000c + + Workqueue CPU -> pool + ===================== + [ workqueue \ CPU 0 1 2 3 dfl] + events percpu 0 2 4 6 + events_highpri percpu 1 3 5 7 + events_long percpu 0 2 4 6 + events_unbound unbound 9 9 10 10 8 + events_freezable percpu 0 2 4 6 + events_power_efficient percpu 0 2 4 6 + events_freezable_power_ percpu 0 2 4 6 + rcu_gp percpu 0 2 4 6 + rcu_par_gp percpu 0 2 4 6 + slub_flushwq percpu 0 2 4 6 + netns ordered 8 8 8 8 8 + ... + +See the command's help message for more info. + + +Monitoring +========== + +Use tools/workqueue/wq_monitor.py to monitor workqueue operations: :: + + $ tools/workqueue/wq_monitor.py events + total infl CPUtime CPUhog CMW/RPR mayday rescued + events 18545 0 6.1 0 5 - - + events_highpri 8 0 0.0 0 0 - - + events_long 3 0 0.0 0 0 - - + events_unbound 38306 0 0.1 - 7 - - + events_freezable 0 0 0.0 0 0 - - + events_power_efficient 29598 0 0.2 0 0 - - + events_freezable_power_ 10 0 0.0 0 0 - - + sock_diag_events 0 0 0.0 0 0 - - + + total infl CPUtime CPUhog CMW/RPR mayday rescued + events 18548 0 6.1 0 5 - - + events_highpri 8 0 0.0 0 0 - - + events_long 3 0 0.0 0 0 - - + events_unbound 38322 0 0.1 - 7 - - + events_freezable 0 0 0.0 0 0 - - + events_power_efficient 29603 0 0.2 0 0 - - + events_freezable_power_ 10 0 0.0 0 0 - - + sock_diag_events 0 0 0.0 0 0 - - + + ... + +See the command's help message for more info. + + Debugging ========= @@ -387,6 +736,7 @@ the stack trace of the offending worker thread. :: The work item's function should be trivially visible in the stack trace. + Non-reentrance Conditions ========================= diff --git a/Documentation/crypto/async-tx-api.rst b/Documentation/crypto/async-tx-api.rst index bfc773991bdc..27c146b54d71 100644 --- a/Documentation/crypto/async-tx-api.rst +++ b/Documentation/crypto/async-tx-api.rst @@ -66,7 +66,7 @@ features surfaced as a result: :: struct dma_async_tx_descriptor * - async_<operation>(<op specific parameters>, struct async_submit ctl *submit) + async_<operation>(<op specific parameters>, struct async_submit_ctl *submit) 3.2 Supported operations ------------------------ diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index e66916a483cd..f4acf9c2e90f 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -107,9 +107,12 @@ effectively disables ``panic_on_warn`` for KASAN reports. Alternatively, independent of ``panic_on_warn``, the ``kasan.fault=`` boot parameter can be used to control panic and reporting behaviour: -- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN - report or also panic the kernel (default: ``report``). The panic happens even - if ``kasan_multi_shot`` is enabled. +- ``kasan.fault=report``, ``=panic``, or ``=panic_on_write`` controls whether + to only print a KASAN report, panic the kernel, or panic the kernel on + invalid writes only (default: ``report``). The panic happens even if + ``kasan_multi_shot`` is enabled. Note that when using asynchronous mode of + Hardware Tag-Based KASAN, ``kasan.fault=panic_on_write`` always panics on + asynchronously checked accesses (including reads). Software and Hardware Tag-Based KASAN modes (see the section about various modes below) support altering stack trace collection behavior: diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst index 12b575b76b20..deede972f254 100644 --- a/Documentation/dev-tools/kselftest.rst +++ b/Documentation/dev-tools/kselftest.rst @@ -36,6 +36,7 @@ Running the selftests (hotplug tests are run in limited mode) To build the tests:: + $ make headers $ make -C tools/testing/selftests To run the tests:: @@ -168,6 +169,28 @@ the `-t` option for specific single tests. Either can be used multiple times:: For other features see the script usage output, seen with the `-h` option. +Timeout for selftests +===================== + +Selftests are designed to be quick and so a default timeout is used of 45 +seconds for each test. Tests can override the default timeout by adding +a settings file in their directory and set a timeout variable there to the +configured a desired upper timeout for the test. Only a few tests override +the timeout with a value higher than 45 seconds, selftests strives to keep +it that way. Timeouts in selftests are not considered fatal because the +system under which a test runs may change and this can also modify the +expected time it takes to run a test. If you have control over the systems +which will run the tests you can configure a test runner on those systems to +use a greater or lower timeout on the command line as with the `-o` or +the `--override-timeout` argument. For example to use 165 seconds instead +one would use: + + $ ./run_kselftest.sh --override-timeout 165 + +You can look at the TAP output to see if you ran into the timeout. Test +runners which know a test must run under a specific time can then optionally +treat these timeouts then as fatal. + Packaging selftests =================== diff --git a/Documentation/dev-tools/kunit/architecture.rst b/Documentation/dev-tools/kunit/architecture.rst index e95ab05342bb..f335f883f8f6 100644 --- a/Documentation/dev-tools/kunit/architecture.rst +++ b/Documentation/dev-tools/kunit/architecture.rst @@ -119,9 +119,9 @@ All expectations/assertions are formatted as: terminated immediately. - Assertions call the function: - ``void __noreturn kunit_abort(struct kunit *)``. + ``void __noreturn __kunit_abort(struct kunit *)``. - - ``kunit_abort`` calls the function: + - ``__kunit_abort`` calls the function: ``void __noreturn kunit_try_catch_throw(struct kunit_try_catch *try_catch)``. - ``kunit_try_catch_throw`` calls the function: diff --git a/Documentation/dev-tools/kunit/run_wrapper.rst b/Documentation/dev-tools/kunit/run_wrapper.rst index dafe8eb28d30..19ddf5e07013 100644 --- a/Documentation/dev-tools/kunit/run_wrapper.rst +++ b/Documentation/dev-tools/kunit/run_wrapper.rst @@ -321,3 +321,15 @@ command line arguments: - ``--json``: If set, stores the test results in a JSON format and prints to `stdout` or saves to a file if a filename is specified. + +- ``--filter``: Specifies filters on test attributes, for example, ``speed!=slow``. + Multiple filters can be used by wrapping input in quotes and separating filters + by commas. Example: ``--filter "speed>slow, module=example"``. + +- ``--filter_action``: If set to ``skip``, filtered tests will be shown as skipped + in the output rather than showing no output. + +- ``--list_tests``: If set, lists all tests that will be run. + +- ``--list_tests_attr``: If set, lists all tests that will be run and all of their + attributes. diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst index 8e8c493f17d1..766f9cdea0fa 100644 --- a/Documentation/dev-tools/kunit/running_tips.rst +++ b/Documentation/dev-tools/kunit/running_tips.rst @@ -262,3 +262,169 @@ other code executed during boot, e.g. # Reset coverage counters before running the test. $ echo 0 > /sys/kernel/debug/gcov/reset $ modprobe kunit-example-test + + +Test Attributes and Filtering +============================= + +Test suites and cases can be marked with test attributes, such as speed of +test. These attributes will later be printed in test output and can be used to +filter test execution. + +Marking Test Attributes +----------------------- + +Tests are marked with an attribute by including a ``kunit_attributes`` object +in the test definition. + +Test cases can be marked using the ``KUNIT_CASE_ATTR(test_name, attributes)`` +macro to define the test case instead of ``KUNIT_CASE(test_name)``. + +.. code-block:: c + + static const struct kunit_attributes example_attr = { + .speed = KUNIT_VERY_SLOW, + }; + + static struct kunit_case example_test_cases[] = { + KUNIT_CASE_ATTR(example_test, example_attr), + }; + +.. note:: + To mark a test case as slow, you can also use ``KUNIT_CASE_SLOW(test_name)``. + This is a helpful macro as the slow attribute is the most commonly used. + +Test suites can be marked with an attribute by setting the "attr" field in the +suite definition. + +.. code-block:: c + + static const struct kunit_attributes example_attr = { + .speed = KUNIT_VERY_SLOW, + }; + + static struct kunit_suite example_test_suite = { + ..., + .attr = example_attr, + }; + +.. note:: + Not all attributes need to be set in a ``kunit_attributes`` object. Unset + attributes will remain uninitialized and act as though the attribute is set + to 0 or NULL. Thus, if an attribute is set to 0, it is treated as unset. + These unset attributes will not be reported and may act as a default value + for filtering purposes. + +Reporting Attributes +-------------------- + +When a user runs tests, attributes will be present in the raw kernel output (in +KTAP format). Note that attributes will be hidden by default in kunit.py output +for all passing tests but the raw kernel output can be accessed using the +``--raw_output`` flag. This is an example of how test attributes for test cases +will be formatted in kernel output: + +.. code-block:: none + + # example_test.speed: slow + ok 1 example_test + +This is an example of how test attributes for test suites will be formatted in +kernel output: + +.. code-block:: none + + KTAP version 2 + # Subtest: example_suite + # module: kunit_example_test + 1..3 + ... + ok 1 example_suite + +Additionally, users can output a full attribute report of tests with their +attributes, using the command line flag ``--list_tests_attr``: + +.. code-block:: bash + + kunit.py run "example" --list_tests_attr + +.. note:: + This report can be accessed when running KUnit manually by passing in the + module_param ``kunit.action=list_attr``. + +Filtering +--------- + +Users can filter tests using the ``--filter`` command line flag when running +tests. As an example: + +.. code-block:: bash + + kunit.py run --filter speed=slow + + +You can also use the following operations on filters: "<", ">", "<=", ">=", +"!=", and "=". Example: + +.. code-block:: bash + + kunit.py run --filter "speed>slow" + +This example will run all tests with speeds faster than slow. Note that the +characters < and > are often interpreted by the shell, so they may need to be +quoted or escaped, as above. + +Additionally, you can use multiple filters at once. Simply separate filters +using commas. Example: + +.. code-block:: bash + + kunit.py run --filter "speed>slow, module=kunit_example_test" + +.. note:: + You can use this filtering feature when running KUnit manually by passing + the filter as a module param: ``kunit.filter="speed>slow, speed<=normal"``. + +Filtered tests will not run or show up in the test output. You can use the +``--filter_action=skip`` flag to skip filtered tests instead. These tests will be +shown in the test output in the test but will not run. To use this feature when +running KUnit manually, use the module param ``kunit.filter_action=skip``. + +Rules of Filtering Procedure +---------------------------- + +Since both suites and test cases can have attributes, there may be conflicts +between attributes during filtering. The process of filtering follows these +rules: + +- Filtering always operates at a per-test level. + +- If a test has an attribute set, then the test's value is filtered on. + +- Otherwise, the value falls back to the suite's value. + +- If neither are set, the attribute has a global "default" value, which is used. + +List of Current Attributes +-------------------------- + +``speed`` + +This attribute indicates the speed of a test's execution (how slow or fast the +test is). + +This attribute is saved as an enum with the following categories: "normal", +"slow", or "very_slow". The assumed default speed for tests is "normal". This +indicates that the test takes a relatively trivial amount of time (less than +1 second), regardless of the machine it is running on. Any test slower than +this could be marked as "slow" or "very_slow". + +The macro ``KUNIT_CASE_SLOW(test_name)`` can be easily used to set the speed +of a test case to "slow". + +``module`` + +This attribute indicates the name of the module associated with the test. + +This attribute is automatically saved as a string and is printed for each suite. +Tests can also be filtered using this attribute. diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index c736613c9b19..a98235326bab 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -250,15 +250,20 @@ Now we are ready to write the test cases. }; kunit_test_suite(misc_example_test_suite); + MODULE_LICENSE("GPL"); + 2. Add the following lines to ``drivers/misc/Kconfig``: .. code-block:: kconfig config MISC_EXAMPLE_TEST tristate "Test for my example" if !KUNIT_ALL_TESTS - depends on MISC_EXAMPLE && KUNIT=y + depends on MISC_EXAMPLE && KUNIT default KUNIT_ALL_TESTS +Note: If your test does not support being built as a loadable module (which is +discouraged), replace tristate by bool, and depend on KUNIT=y instead of KUNIT. + 3. Add the following lines to ``drivers/misc/Makefile``: .. code-block:: make diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 9faf2b4153fc..c27e1646ecd9 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -121,6 +121,12 @@ there's an allocation error. ``return`` so they only work from the test function. In KUnit, we stop the current kthread on failure, so you can call them from anywhere. +.. note:: + Warning: There is an exception to the above rule. You shouldn't use assertions + in the suite's exit() function, or in the free function for a resource. These + run when a test is shutting down, and an assertion here prevents further + cleanup code from running, potentially leading to a memory leak. + Customizing error messages -------------------------- @@ -160,7 +166,12 @@ many similar tests. In order to reduce duplication in these closely related tests, most unit testing frameworks (including KUnit) provide the concept of a *test suite*. A test suite is a collection of test cases for a unit of code with optional setup and teardown functions that run before/after the whole -suite and/or every test case. For example: +suite and/or every test case. + +.. note:: + A test case will only run if it is associated with a test suite. + +For example: .. code-block:: c @@ -190,7 +201,10 @@ after everything else. ``kunit_test_suite(example_test_suite)`` registers the test suite with the KUnit test framework. .. note:: - A test case will only run if it is associated with a test suite. + The ``exit`` and ``suite_exit`` functions will run even if ``init`` or + ``suite_init`` fail. Make sure that they can handle any inconsistent + state which may result from ``init`` or ``suite_init`` encountering errors + or exiting early. ``kunit_test_suite(...)`` is a macro which tells the linker to put the specified test suite in a special linker section so that it can be run by KUnit @@ -601,6 +615,57 @@ For example: KUNIT_ASSERT_STREQ(test, buffer, ""); } +Registering Cleanup Actions +--------------------------- + +If you need to perform some cleanup beyond simple use of ``kunit_kzalloc``, +you can register a custom "deferred action", which is a cleanup function +run when the test exits (whether cleanly, or via a failed assertion). + +Actions are simple functions with no return value, and a single ``void*`` +context argument, and fulfill the same role as "cleanup" functions in Python +and Go tests, "defer" statements in languages which support them, and +(in some cases) destructors in RAII languages. + +These are very useful for unregistering things from global lists, closing +files or other resources, or freeing resources. + +For example: + +.. code-block:: C + + static void cleanup_device(void *ctx) + { + struct device *dev = (struct device *)ctx; + + device_unregister(dev); + } + + void example_device_test(struct kunit *test) + { + struct my_device dev; + + device_register(&dev); + + kunit_add_action(test, &cleanup_device, &dev); + } + +Note that, for functions like device_unregister which only accept a single +pointer-sized argument, it's possible to directly cast that function to +a ``kunit_action_t`` rather than writing a wrapper function, for example: + +.. code-block:: C + + kunit_add_action(test, (kunit_action_t *)&device_unregister, &dev); + +``kunit_add_action`` can fail if, for example, the system is out of memory. +You can use ``kunit_add_action_or_reset`` instead which runs the action +immediately if it cannot be deferred. + +If you need more control over when the cleanup function is called, you +can trigger it early using ``kunit_release_action``, or cancel it entirely +with ``kunit_remove_action``. + Testing Static Functions ------------------------ diff --git a/Documentation/devicetree/bindings/.yamllint b/Documentation/devicetree/bindings/.yamllint index 4abe9f0a1d46..fea5231e1320 100644 --- a/Documentation/devicetree/bindings/.yamllint +++ b/Documentation/devicetree/bindings/.yamllint @@ -1,6 +1,11 @@ extends: relaxed rules: + quoted-strings: + required: only-when-needed + extra-allowed: + - '[$^,[]' + - '^/$' line-length: # 80 chars should be enough, but don't fail if a line is longer max: 110 diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 274ee0890312..1c1094cd6b77 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/arm/amlogic.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Amlogic MesonX +title: Amlogic SoC based Platforms maintainers: - Kevin Hilman <khilman@baylibre.com> @@ -205,12 +205,27 @@ properties: - amlogic,ad401 - const: amlogic,a1 + - description: Boards with the Amlogic C3 C302X/C308L SoC + items: + - enum: + - amlogic,aw409 + - amlogic,aw419 + - const: amlogic,c3 + - description: Boards with the Amlogic Meson S4 S805X2 SoC items: - enum: - amlogic,aq222 - const: amlogic,s4 + - description: Boards with the Amlogic T7 A311D2 SoC + items: + - enum: + - amlogic,an400 + - khadas,vim4 + - const: amlogic,a311d2 + - const: amlogic,t7 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml index 0c5b875cb654..6216cfb0a188 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause # Copyright 2019 Linaro Ltd. %YAML 1.2 --- @@ -287,7 +287,7 @@ examples: arm,trig-in-sigs = <0 1>; arm,trig-in-types = <PE_DBGTRIGGER PE_PMUIRQ>; - arm,trig-out-sigs=<0 1 2 >; + arm,trig-out-sigs = <0 1 2 >; arm,trig-out-types = <PE_EDBGREQ PE_DBGRESTART PE_CTIIRQ>; @@ -309,24 +309,24 @@ examples: trig-conns@0 { reg = <0>; - arm,trig-in-sigs=<0>; - arm,trig-in-types=<GEN_INTREQ>; - arm,trig-out-sigs=<0>; - arm,trig-out-types=<GEN_HALTREQ>; + arm,trig-in-sigs = <0>; + arm,trig-in-types = <GEN_INTREQ>; + arm,trig-out-sigs = <0>; + arm,trig-out-types = <GEN_HALTREQ>; arm,trig-conn-name = "sys_profiler"; }; trig-conns@1 { reg = <1>; - arm,trig-out-sigs=<2 3>; - arm,trig-out-types=<GEN_HALTREQ GEN_RESTARTREQ>; + arm,trig-out-sigs = <2 3>; + arm,trig-out-types = <GEN_HALTREQ GEN_RESTARTREQ>; arm,trig-conn-name = "watchdog"; }; trig-conns@2 { reg = <2>; - arm,trig-in-sigs=<1 6>; - arm,trig-in-types=<GEN_HALTREQ GEN_RESTARTREQ>; + arm,trig-in-sigs = <1 6>; + arm,trig-in-types = <GEN_HALTREQ GEN_RESTARTREQ>; arm,trig-conn-name = "g_counter"; }; }; diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml new file mode 100644 index 000000000000..c960c8e0a9a5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-dummy-sink.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Coresight Dummy sink component + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + The Coresight dummy sink component is for the specific coresight sink devices + kernel don't have permission to access or configure, e.g., CoreSight EUD on + Qualcomm platforms. It is a mini-USB hub implemented to support the USB-based + debug and trace capabilities. For this device, a dummy driver is needed to + register it as Coresight sink device in kernel side, so that path can be + created in the driver. Then the trace flow would be transferred to EUD via + coresight link of AP processor. It provides Coresight API for operations on + dummy source devices, such as enabling and disabling them. It also provides + the Coresight dummy source paths for debugging. + + The primary use case of the coresight dummy sink is to build path in kernel + side for dummy sink component. + +maintainers: + - Mike Leach <mike.leach@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + - James Clark <james.clark@arm.com> + - Mao Jinlong <quic_jinlmao@quicinc.com> + - Hao Zhang <quic_hazha@quicinc.com> + +properties: + compatible: + enum: + - arm,coresight-dummy-sink + + in-ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port: + description: Input connection from the Coresight Trace bus to + dummy sink, such as Embedded USB debugger(EUD). + + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - in-ports + +additionalProperties: false + +examples: + # Minimum dummy sink definition. Dummy sink connect to coresight replicator. + - | + sink { + compatible = "arm,coresight-dummy-sink"; + + in-ports { + port { + eud_in_replicator_swao: endpoint { + remote-endpoint = <&replicator_swao_out_eud>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml new file mode 100644 index 000000000000..6745b4cc8f1c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-dummy-source.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Coresight Dummy source component + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + The Coresight dummy source component is for the specific coresight source + devices kernel don't have permission to access or configure. For some SOCs, + there would be Coresight source trace components on sub-processor which + are conneted to AP processor via debug bus. For these devices, a dummy driver + is needed to register them as Coresight source devices, so that paths can be + created in the driver. It provides Coresight API for operations on dummy + source devices, such as enabling and disabling them. It also provides the + Coresight dummy source paths for debugging. + + The primary use case of the coresight dummy source is to build path in kernel + side for dummy source component. + +maintainers: + - Mike Leach <mike.leach@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + - James Clark <james.clark@arm.com> + - Mao Jinlong <quic_jinlmao@quicinc.com> + - Hao Zhang <quic_hazha@quicinc.com> + +properties: + compatible: + enum: + - arm,coresight-dummy-source + + out-ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port: + description: Output connection from the source to Coresight + Trace bus. + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - out-ports + +additionalProperties: false + +examples: + # Minimum dummy source definition. Dummy source connect to coresight funnel. + - | + source { + compatible = "arm,coresight-dummy-source"; + + out-ports { + port { + dummy_riscv_out_funnel_swao: endpoint { + remote-endpoint = <&funnel_swao_in_dummy_riscv>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml index 108460627d9a..f725e6940993 100644 --- a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml +++ b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml @@ -1,9 +1,9 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause # Copyright 2021, Arm Ltd %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/arm,embedded-trace-extension.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/arm,embedded-trace-extension.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: ARM Embedded Trace Extensions diff --git a/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml b/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml index b1322658063a..87128e7b7d28 100644 --- a/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml +++ b/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml @@ -1,9 +1,9 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause # Copyright 2021, Arm Ltd %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/arm,trace-buffer-extension.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/arm,trace-buffer-extension.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: ARM Trace Buffer Extensions @@ -19,7 +19,8 @@ description: | properties: $nodename: - const: "trbe" + const: trbe + compatible: items: - const: arm,trace-buffer-extension diff --git a/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml b/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml index 491eef1e1b10..3b060c36b90c 100644 --- a/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml +++ b/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/arm/arm,versatile-sysreg.yaml# diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml index 09c319f803ba..8dd6b6446394 100644 --- a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml +++ b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml @@ -122,14 +122,14 @@ properties: arm,vexpress,position: description: When daughterboards are stacked on one site, their position in the stack be be described this attribute. - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3 arm,vexpress,dcc: description: When describing tiles consisting of more than one DCC, its number can be specified with this attribute. - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3 @@ -143,7 +143,7 @@ patternProperties: "simple-bus". If the compatible is placed in the "motherboard-bus" node, it is stricter and always has two compatibles. type: object - $ref: '/schemas/simple-bus.yaml' + $ref: /schemas/simple-bus.yaml unevaluatedProperties: false properties: @@ -180,13 +180,13 @@ patternProperties: - const: simple-bus arm,v2m-memory-map: description: This describes the memory map type. - $ref: '/schemas/types.yaml#/definitions/string' + $ref: /schemas/types.yaml#/definitions/string enum: - rs1 - rs2 arm,hbi: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: This indicates the ARM HBI (Hardware Board ID), this is ARM's unique board model ID, visible on the PCB's silkscreen. @@ -197,7 +197,7 @@ patternProperties: property, describing the physical location of the children nodes. 0 means motherboard site, while 1 and 2 are daughterboard sites, and 0xf means "sisterboard" which is the site containing the main CPU tile. - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 15 diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml index c72aab706484..b8c5cacb09bd 100644 --- a/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml @@ -2,8 +2,8 @@ # Copyright 2021 Joel Stanley, IBM Corp. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/aspeed/aspeed,sbc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/aspeed/aspeed,sbc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: ASPEED Secure Boot Controller diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml index e0eff4c05879..68f717670f78 100644 --- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/arm/aspeed/aspeed.yaml# @@ -79,9 +79,11 @@ properties: - facebook,elbert-bmc - facebook,fuji-bmc - facebook,greatlakes-bmc + - facebook,yosemite4-bmc - ibm,everest-bmc - ibm,rainier-bmc - ibm,tacoma-bmc + - inventec,starscream-bmc - inventec,transformer-bmc - jabil,rbp-bmc - qcom,dc-scm-v1-bmc diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index ab1b352344ae..67a66bf74895 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -52,100 +52,6 @@ Example: reg = <0xe3804000 0x1000>; }; -SHDWC Shutdown Controller - -required properties: -- compatible: Should be "atmel,<chip>-shdwc". - <chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5". -- reg: Should contain registers location and length -- clocks: phandle to input clock. - -optional properties: -- atmel,wakeup-mode: String, operation mode of the wakeup mode. - Supported values are: "none", "high", "low", "any". -- atmel,wakeup-counter: Counter on Wake-up 0 (between 0x0 and 0xf). - -optional at91sam9260 properties: -- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up. - -optional at91sam9rl properties: -- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up. -- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up. - -optional at91sam9x5 properties: -- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up. - -Example: - - shdwc@fffffd10 { - compatible = "atmel,at91sam9260-shdwc"; - reg = <0xfffffd10 0x10>; - clocks = <&clk32k>; - }; - -SHDWC SAMA5D2-Compatible Shutdown Controller - -1) shdwc node - -required properties: -- compatible: should be "atmel,sama5d2-shdwc", "microchip,sam9x60-shdwc" or - "microchip,sama7g5-shdwc" -- reg: should contain registers location and length -- clocks: phandle to input clock. -- #address-cells: should be one. The cell is the wake-up input index. -- #size-cells: should be zero. - -optional properties: - -- debounce-delay-us: minimum wake-up inputs debouncer period in - microseconds. It's usually a board-related property. -- atmel,wakeup-rtc-timer: boolean to enable Real-Time Clock wake-up. - -optional microchip,sam9x60-shdwc or microchip,sama7g5-shdwc properties: -- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up. - -The node contains child nodes for each wake-up input that the platform uses. - -2) input nodes - -Wake-up input nodes are usually described in the "board" part of the Device -Tree. Note also that input 0 is linked to the wake-up pin and is frequently -used. - -Required properties: -- reg: should contain the wake-up input index [0 - 15]. - -Optional properties: -- atmel,wakeup-active-high: boolean, the corresponding wake-up input described - by the child, forces the wake-up of the core power supply on a high level. - The default is to be active low. - -Example: - -On the SoC side: - shdwc@f8048010 { - compatible = "atmel,sama5d2-shdwc"; - reg = <0xf8048010 0x10>; - clocks = <&clk32k>; - #address-cells = <1>; - #size-cells = <0>; - atmel,wakeup-rtc-timer; - }; - -On the board side: - shdwc@f8048010 { - debounce-delay-us = <976>; - - input@0 { - reg = <0>; - }; - - input@1 { - reg = <1>; - atmel,wakeup-active-high; - }; - }; - Special Function Registers (SFR) Special Function Registers (SFR) manage specific aspects of the integrated diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml index 454b0e93245d..4cc4e6754681 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml @@ -25,13 +25,15 @@ properties: - enum: - asus,rt-ac56u - asus,rt-ac68u + - buffalo,wzr-1166dhp + - buffalo,wzr-1166dhp2 - buffalo,wzr-1750dhp - linksys,ea6300-v1 - linksys,ea6500-v2 - - luxul,xap-1510v1 + - luxul,xap-1510-v1 - luxul,xwc-1000 - - netgear,r6250v1 - - netgear,r6300v2 + - netgear,r6250-v1 + - netgear,r6300-v2 - smartrg,sr400ac - brcm,bcm94708 - const: brcm,bcm4708 @@ -42,8 +44,8 @@ properties: - asus,rt-n18u - buffalo,wzr-600dhp2 - buffalo,wzr-900dhp - - luxul,xap-1410v1 - - luxul,xwr-1200v1 + - luxul,xap-1410-v1 + - luxul,xwr-1200-v1 - tplink,archer-c5-v2 - const: brcm,bcm47081 - const: brcm,bcm4708 @@ -64,6 +66,7 @@ properties: - description: BCM47094 based boards items: - enum: + - asus,rt-ac3100 - asus,rt-ac88u - dlink,dir-885l - dlink,dir-890l @@ -72,7 +75,7 @@ properties: - luxul,xap-1610-v1 - luxul,xbr-4500-v1 - luxul,xwc-2000-v1 - - luxul,xwr-3100v1 + - luxul,xwr-3100-v1 - luxul,xwr-3150-v1 - netgear,r8500 - phicomm,k3 diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm53573.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm53573.yaml new file mode 100644 index 000000000000..81b9a4a641c1 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm53573.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm53573.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM53573 SoCs family + +description: + Broadcom BCM53573 / BCM47189 Wi-Fi SoCs derived from Northstar. + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: BCM53573 based boards + items: + - enum: + - tenda,ac6-v1 + - tenda,w15e-v1 + - const: brcm,bcm53573 + + - description: BCM47189 based boards + items: + - enum: + - brcm,bcm947189acdbmr + - luxul,xap-810-v1 + - luxul,xap-1440-v1 + - tenda,ac9 + - const: brcm,bcm47189 + - const: brcm,bcm53573 + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index ff272e517d57..0d17cbad9778 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -143,8 +143,10 @@ properties: - arm,cortex-a78ae - arm,cortex-a78c - arm,cortex-a510 + - arm,cortex-a520 - arm,cortex-a710 - arm,cortex-a715 + - arm,cortex-a720 - arm,cortex-m0 - arm,cortex-m0+ - arm,cortex-m1 @@ -153,10 +155,12 @@ properties: - arm,cortex-r4 - arm,cortex-r5 - arm,cortex-r7 + - arm,cortex-r52 - arm,cortex-x1 - arm,cortex-x1c - arm,cortex-x2 - arm,cortex-x3 + - arm,cortex-x4 - arm,neoverse-e1 - arm,neoverse-n1 - arm,neoverse-n2 @@ -196,7 +200,7 @@ properties: - qcom,scorpion enable-method: - $ref: '/schemas/types.yaml#/definitions/string' + $ref: /schemas/types.yaml#/definitions/string oneOf: # On ARM v8 64-bit this property is required - enum: @@ -245,8 +249,8 @@ properties: cpu-release-addr: oneOf: - - $ref: '/schemas/types.yaml#/definitions/uint32' - - $ref: '/schemas/types.yaml#/definitions/uint64' + - $ref: /schemas/types.yaml#/definitions/uint32 + - $ref: /schemas/types.yaml#/definitions/uint64 description: The DT specification defines this as 64-bit always, but some 32-bit Arm systems have used a 32-bit value which must be supported. @@ -254,7 +258,7 @@ properties: property value of "spin-table". cpu-idle-states: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: maxItems: 1 description: | @@ -270,7 +274,7 @@ properties: cci-control-port: true dynamic-power-coefficient: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: A u32 value that represents the running time dynamic power coefficient in units of uW/MHz/V^2. The @@ -307,7 +311,7 @@ properties: PM domain provider, must be "psci". qcom,saw: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | Specifies the SAW* node associated with this CPU. @@ -317,7 +321,7 @@ properties: * arm/msm/qcom,saw2.txt qcom,acc: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | Specifies the ACC* node associated with this CPU. @@ -328,7 +332,7 @@ properties: * arm/msm/qcom,kpss-acc.txt rockchip,pmu: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | Specifies the syscon node controlling the cpu core power domains. @@ -338,7 +342,7 @@ properties: the cpu-core power-domains. secondary-boot-reg: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: | Required for systems that have an "enable-method" property value of "brcm,bcm11351-cpu-method", "brcm,bcm23550" or "brcm,bcm-nsp-smp". diff --git a/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml index 9d1857c0aa07..e3980b659f63 100644 --- a/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml +++ b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/firmware/tlm,trusted-foundations.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/firmware/tlm,trusted-foundations.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Trusted Foundations diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 15d411084065..9450b2c8a678 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -726,6 +726,12 @@ properties: - const: dh,imx6ull-dhcor-som - const: fsl,imx6ull + - description: i.MX6ULL DHCOR SoM based Boards + items: + - const: marantec,imx6ull-dhcor-maveo-box + - const: dh,imx6ull-dhcor-som + - const: fsl,imx6ull + - description: i.MX6ULL PHYTEC phyBOARD-Segin items: - enum: @@ -901,7 +907,9 @@ properties: - emtrion,emcon-mx8mm-avari # emCON-MX8MM SoM on Avari Base - fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board - fsl,imx8mm-evk # i.MX8MM EVK Board + - fsl,imx8mm-evkb # i.MX8MM EVKB Board - gateworks,imx8mm-gw7904 + - gateworks,imx8mm-gw7905-0x # i.MX8MM Gateworks Board - gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw73xx-0x # i.MX8MM Gateworks Development Kit @@ -918,6 +926,12 @@ properties: - prt,prt8mm # i.MX8MM Protonic PRT8MM Board - const: fsl,imx8mm + - description: Emtop i.MX8MM based Boards + items: + - const: ees,imx8mm-emtop-baseboard # i.MX8MM Emtop SoM on i.MX8M Mini Baseboard V1 + - const: ees,imx8mm-emtop-som # i.MX8MM Emtop SOM-IMX8MMLPD4 module + - const: fsl,imx8mm + - description: Engicam i.Core MX8M Mini SoM based boards items: - enum: @@ -1018,9 +1032,11 @@ properties: - beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit - dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC - fsl,imx8mp-evk # i.MX8MP EVK 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 - gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board - - polyhex,imx8mp-debix # Polyhex Debix boards - - polyhex,imx8mp-debix-model-a # Polyhex Debix Model A Board + - gateworks,imx8mp-gw7905-2x # i.MX8MP Gateworks Board - toradex,verdin-imx8mp # Verdin iMX8M Plus Modules - toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Modules without Wi-Fi / BT - toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Modules @@ -1054,6 +1070,20 @@ properties: - const: phytec,imx8mp-phycore-som # phyCORE-i.MX8MP SoM - const: fsl,imx8mp + - description: Polyhex DEBIX i.MX8MP based SBCs + items: + - enum: + - polyhex,imx8mp-debix-model-a # Polyhex Debix Model A Board + - const: polyhex,imx8mp-debix # Polyhex i.MX8MP Debix SBCs + - const: fsl,imx8mp + + - description: Polyhex DEBIX i.MX8MP SOM A based boards + items: + - enum: + - polyhex,imx8mp-debix-som-a-bmb-08 # Polyhex Debix SOM A on SOM A I/O board + - const: polyhex,imx8mp-debix-som-a # Polyhex Debix SOM A + - const: fsl,imx8mp + - description: Toradex Boards with Verdin iMX8M Plus Modules items: - enum: @@ -1206,11 +1236,30 @@ properties: - const: fsl,imxrt1170 - description: + TQMa93xxLA and TQMa93xxCA are two series of feature compatible SOM + using NXP i.MX93 SOC in 11x11 mm package. + TQMa93xxLA is designed to be soldered on different carrier boards. + TQMa93xxCA is a compatible variant using board to board connectors. + All SOM and CPU variants use the same device tree hence only one + compatible is needed. Bootloader disables all features not present + in the assembled SOC. + MBa93xxCA mainboard can be used as starterkit for the SOM + soldered on an adapter board or for the connector variant + MBa93xxLA mainboard is a single board computer using the solderable + SOM variant + items: + - enum: + - tq,imx93-tqma9352-mba93xxca # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM on MBa93xxCA + - tq,imx93-tqma9352-mba93xxla # TQ-Systems GmbH i.MX93 TQMa93xxLA SOM on MBa93xxLA SBC + - const: tq,imx93-tqma9352 # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM + - const: fsl,imx93 + + - description: Freescale Vybrid Platform Device Tree Bindings - For the Vybrid SoC familiy all variants with DDR controller are supported, + For the Vybrid SoC family all variants with DDR controller are supported, which is the VF5xx and VF6xx series. Out of historical reasons, in most - places the kernel uses vf610 to refer to the whole familiy. + places the kernel uses vf610 to refer to the whole family. The compatible string "fsl,vf610m4" is used for the secondary Cortex-M4 core support. items: @@ -1275,6 +1324,16 @@ properties: - fsl,ls1021a-twr - const: fsl,ls1021a + - description: + TQ-Systems TQMLS102xA is a series of socketable SOM featuring + LS102x system-on-chip variants. MBLS102xA mainboard can be used as + starterkit. + items: + - enum: + - tq,ls1021a-tqmls1021a-mbls102xa + - const: tq,ls1021a-tqmls1021a + - const: fsl,ls1021a + - description: LS1028A based Boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml b/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml index 528dad4cde3c..4fc208d3995e 100644 --- a/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml +++ b/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml @@ -29,6 +29,26 @@ properties: ranges: true +patternProperties: + "^clock@[0-9a-f]+$": + type: object + additionalProperties: false + + properties: + compatible: + const: hisilicon,hix5hd2-clock + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + required: + - compatible + - reg + - "#clock-cells" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/arm/intel,socfpga.yaml b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml index 4b4dcf551eb6..2ee0c740eb56 100644 --- a/Documentation/devicetree/bindings/arm/intel,socfpga.yaml +++ b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml @@ -21,6 +21,11 @@ properties: - intel,socfpga-agilex-n6000 - intel,socfpga-agilex-socdk - const: intel,socfpga-agilex + - description: Agilex5 boards + items: + - enum: + - intel,socfpga-agilex5-socdk + - const: intel,socfpga-agilex5 additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml index ff378d5cbd32..4a323e8c785d 100644 --- a/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml +++ b/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/arm/keystone/ti,k3-sci-common.yaml# diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml index 91b96065f7df..c24ad0968f3e 100644 --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml# @@ -96,8 +96,8 @@ examples: compatible = "ti,k2g-sci"; ti,system-reboot-controller; mbox-names = "rx", "tx"; - mboxes= <&msgmgr 5 2>, - <&msgmgr 0 0>; + mboxes = <&msgmgr 5 2>, + <&msgmgr 0 0>; reg-names = "debug_messages"; reg = <0x02921800 0x800>; }; @@ -107,8 +107,8 @@ examples: compatible = "ti,k2g-sci"; ti,host-id = <12>; mbox-names = "rx", "tx"; - mboxes= <&secure_proxy_main 11>, - <&secure_proxy_main 13>; + mboxes = <&secure_proxy_main 11>, + <&secure_proxy_main 13>; reg-names = "debug_messages"; reg = <0x44083000 0x1000>; diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt index d84105c7c935..9d5d70c98058 100644 --- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt @@ -21,13 +21,13 @@ The Device Tree node representing this System Controller 0 provides a number of clocks: - a set of core clocks - - a set of gatable clocks + - a set of gateable clocks Those clocks can be referenced by other Device Tree nodes using two cells: - The first cell must be 0 or 1. 0 for the core clocks and 1 for the - gatable clocks. - - The second cell identifies the particular core clock or gatable + gateable clocks. + - The second cell identifies the particular core clock or gateable clocks. The following clocks are available: @@ -38,7 +38,7 @@ The following clocks are available: - 0 3 Core - 0 4 NAND core - 0 5 SDIO core - - Gatable clocks + - Gateable clocks - 1 0 Audio - 1 1 Comm Unit - 1 2 NAND diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt index 8be5978f388d..1c671943ce4d 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt @@ -16,7 +16,7 @@ The available clocks are defined in dt-bindings/clock/mt*-clk.h. The mipi0a controller also uses the common power domain from Documentation/devicetree/bindings/soc/mediatek/scpsys.txt -The available power doamins are defined in dt-bindings/power/mt*-power.h. +The available power domains are defined in dt-bindings/power/mt*-power.h. Example: diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt index c877bcc1a5c5..f090147b7f1e 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt @@ -15,7 +15,7 @@ The available clocks are defined in dt-bindings/clock/mt*-clk.h. The vcodecsys controller also uses the common power domain from Documentation/devicetree/bindings/soc/mediatek/scpsys.txt -The available power doamins are defined in dt-bindings/power/mt*-power.h. +The available power domains are defined in dt-bindings/power/mt*-power.h. Example: diff --git a/Documentation/devicetree/bindings/arm/msm/ssbi.txt b/Documentation/devicetree/bindings/arm/msm/ssbi.txt deleted file mode 100644 index 54fd5ced3401..000000000000 --- a/Documentation/devicetree/bindings/arm/msm/ssbi.txt +++ /dev/null @@ -1,18 +0,0 @@ -* Qualcomm SSBI - -Some Qualcomm MSM devices contain a point-to-point serial bus used to -communicate with a limited range of devices (mostly power management -chips). - -These require the following properties: - -- compatible: "qcom,ssbi" - -- qcom,controller-type - indicates the SSBI bus variant the controller should use to talk - with the slave device. This should be one of "ssbi", "ssbi2", or - "pmic-arbiter". The type chosen is determined by the attached - slave. - -The slave device should be the single child node of the ssbi device -with a compatible field. diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml index 6816bd68f9cf..a8ac4a2d672d 100644 --- a/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml +++ b/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml @@ -2,8 +2,8 @@ # Copyright 2020 thingy.jp. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mstar/mstar,l3bridge.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mstar/mstar,l3bridge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MStar/SigmaStar Armv7 SoC l3bridge diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml index 599c65980f5d..5739848000b1 100644 --- a/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml +++ b/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml @@ -2,8 +2,8 @@ # Copyright 2020 thingy.jp. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mstar/mstar,smpctrl.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mstar/mstar,smpctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MStar/SigmaStar Armv7 SoC SMP control registers diff --git a/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,ma35d1.yaml b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,ma35d1.yaml new file mode 100644 index 000000000000..fb190db61525 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,ma35d1.yaml @@ -0,0 +1,30 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/nuvoton/nuvoton,ma35d1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton MA35 series SoC based platforms + +maintainers: + - Jacky Huang <ychuang3@nuvoton.com> + +description: | + Boards with an ARMv8 based Nuvoton MA35 series SoC shall have + the following properties. + +properties: + $nodename: + const: '/' + compatible: + oneOf: + + - description: MA35D1 based boards + items: + - enum: + - nuvoton,ma35d1-iot + - nuvoton,ma35d1-som + - const: nuvoton,ma35d1 + +additionalProperties: true +... diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,npcm.yaml index 6871483947c5..d386744c8815 100644 --- a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml +++ b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,npcm.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/arm/npcm/npcm.yaml# +$id: http://devicetree.org/schemas/arm/nuvoton/nuvoton,npcm.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: NPCM Platforms diff --git a/Documentation/devicetree/bindings/arm/omap/ctrl.txt b/Documentation/devicetree/bindings/arm/omap/ctrl.txt index f35b77920786..0ce6665df4a2 100644 --- a/Documentation/devicetree/bindings/arm/omap/ctrl.txt +++ b/Documentation/devicetree/bindings/arm/omap/ctrl.txt @@ -8,7 +8,7 @@ control module driver itself. See [2] for documentation about clock/clockdomain nodes. -[1] Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt +[1] Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml [2] Documentation/devicetree/bindings/clock/ti/* Required properties: diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index fa8b31660cad..c863ec07cbbb 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -41,14 +41,6 @@ SoC Type (optional): SoC Families: -- OMAP2 generic - defaults to OMAP2420 - compatible = "ti,omap2" -- OMAP3 generic - compatible = "ti,omap3" -- OMAP4 generic - defaults to OMAP4430 - compatible = "ti,omap4" -- OMAP5 generic - defaults to OMAP5430 - compatible = "ti,omap5" - DRA7 generic - defaults to DRA742 compatible = "ti,dra7" - AM33x generic @@ -58,32 +50,6 @@ SoC Families: SoCs: -- OMAP2420 - compatible = "ti,omap2420", "ti,omap2" -- OMAP2430 - compatible = "ti,omap2430", "ti,omap2" - -- OMAP3430 - compatible = "ti,omap3430", "ti,omap3" - legacy: "ti,omap34xx" - please do not use any more -- AM3517 - compatible = "ti,am3517", "ti,omap3" -- OMAP3630 - compatible = "ti,omap3630", "ti,omap3" - legacy: "ti,omap36xx" - please do not use any more -- AM335x - compatible = "ti,am33xx" - -- OMAP4430 - compatible = "ti,omap4430", "ti,omap4" -- OMAP4460 - compatible = "ti,omap4460", "ti,omap4" - -- OMAP5430 - compatible = "ti,omap5430", "ti,omap5" -- OMAP5432 - compatible = "ti,omap5432", "ti,omap5" - - DRA762 compatible = "ti,dra762", "ti,dra7" @@ -116,65 +82,6 @@ SoCs: Boards (incomplete list of examples): -- OMAP3 BeagleBoard : Low cost community board - compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3" - -- OMAP3 BeagleBoard A to B4 : Early BeagleBoard revisions A to B4 with a timer quirk - compatible = "ti,omap3-beagle-ab4", "ti,omap3-beagle", "ti,omap3430", "ti,omap3" - -- OMAP3 Tobi with Overo : Commercial expansion board with daughter board - compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3" - -- OMAP4 SDP : Software Development Board - compatible = "ti,omap4-sdp", "ti,omap4430", "ti,omap4" - -- OMAP4 PandaBoard : Low cost community board - compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4" - -- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board - compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4"; - -- OMAP4 VAR-STK-OM44 : Commercial dev kit with VAR-OM44CustomBoard and VAR-SOM-OM44 w/WLAN - compatible = "variscite,var-stk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4"; - -- OMAP4 VAR-DVK-OM44 : Commercial dev kit with VAR-OM44CustomBoard, VAR-SOM-OM44 w/WLAN and LCD touchscreen - compatible = "variscite,var-dvk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4"; - -- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x - compatible = "ti,omap3-evm", "ti,omap3630", "ti,omap3" - -- AM335X EVM : Software Development Board for AM335x - compatible = "ti,am335x-evm", "ti,am33xx" - -- AM335X Bone : Low cost community board - compatible = "ti,am335x-bone", "ti,am33xx" - -- AM3359 ICEv2 : Low cost Industrial Communication Engine EVM. - compatible = "ti,am3359-icev2", "ti,am33xx" - -- AM335X OrionLXm : Substation Automation Platform - compatible = "novatech,am335x-lxm", "ti,am33xx" - -- AM335X phyBOARD-WEGA: Single Board Computer dev kit - compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx" - -- AM335X CM-T335 : System On Module, built around the Sitara AM3352/4 - compatible = "compulab,cm-t335", "ti,am33xx" - -- AM335X SBC-T335 : single board computer, built around the Sitara AM3352/4 - compatible = "compulab,sbc-t335", "compulab,cm-t335", "ti,am33xx" - -- AM335X phyCORE-AM335x: Development kit - compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som", "ti,am33xx" - -- AM335x phyBOARD-REGOR: Single Board Computer - compatible = "phytec,am335x-regor", "phytec,am335x-phycore-som", "ti,am33xx" - -- AM335X UC-8100-ME-T: Communication-centric industrial computing platform - compatible = "moxa,uc-8100-me-t", "ti,am33xx"; - -- OMAP5 EVM : Evaluation Module - compatible = "ti,omap5-evm", "ti,omap5" - AM437x CM-T43 compatible = "compulab,am437x-cm-t43", "ti,am4372", "ti,am43" @@ -217,9 +124,3 @@ Boards (incomplete list of examples): - DRA718 EVM: Software Development Board for DRA718 compatible = "ti,dra718-evm", "ti,dra718", "ti,dra722", "ti,dra72", "ti,dra7" - -- DM3730 Logic PD Torpedo + Wireless: Commercial System on Module with WiFi and Bluetooth - compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3630", "ti,omap3" - -- DM3730 Logic PD SOM-LV: Commercial System on Module with WiFi and Bluetooth - compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3630", "ti,omap3" diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml index e14358bf0b9c..99b5e9530707 100644 --- a/Documentation/devicetree/bindings/arm/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/pmu.yaml @@ -49,9 +49,14 @@ properties: - arm,cortex-a77-pmu - arm,cortex-a78-pmu - arm,cortex-a510-pmu + - arm,cortex-a520-pmu - arm,cortex-a710-pmu + - arm,cortex-a715-pmu + - arm,cortex-a720-pmu - arm,cortex-x1-pmu - arm,cortex-x2-pmu + - arm,cortex-x3-pmu + - arm,cortex-x4-pmu - arm,neoverse-e1-pmu - arm,neoverse-n1-pmu - arm,neoverse-n2-pmu diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml index 3a2c908ff282..0c5381e081bd 100644 --- a/Documentation/devicetree/bindings/arm/psci.yaml +++ b/Documentation/devicetree/bindings/arm/psci.yaml @@ -100,7 +100,7 @@ properties: patternProperties: "^power-domain-": - $ref: "../power/power-domain.yaml#" + $ref: /schemas/power/power-domain.yaml# type: object description: | diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml index 2ec9b5b24d73..ea3c5db6b52d 100644 --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause # Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. %YAML 1.2 --- diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml index 5c08342664ea..3bad47b7b02b 100644 --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause # Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. %YAML 1.2 --- diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml index e333ec4a9c5f..97621c92a1ab 100644 --- a/Documentation/devicetree/bindings/arm/qcom-soc.yaml +++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml @@ -31,7 +31,7 @@ properties: compatible: oneOf: # Preferred naming style for compatibles of SoC components: - - pattern: "^qcom,(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+-.*$" + - pattern: "^qcom,(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+(pro)?-.*$" - pattern: "^qcom,(sa|sc)8[0-9]+[a-z][a-z]?-.*$" # Legacy namings - variations of existing patterns/compatibles are OK, diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index d9dd25695c3d..adbfaea32343 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -30,6 +30,7 @@ description: | apq8084 apq8096 ipq4018 + ipq5018 ipq5332 ipq6018 ipq8074 @@ -40,6 +41,7 @@ description: | msm8939 msm8953 msm8956 + msm8960 msm8974 msm8976 msm8992 @@ -69,7 +71,9 @@ description: | sdm845 sdx55 sdx65 + sdx75 sm4250 + sm4450 sm6115 sm6115p sm6125 @@ -85,9 +89,15 @@ description: | The 'board' element must be one of the following strings: adp + ap-al02-c2 + ap-al02-c6 ap-al02-c7 + ap-al02-c8 + ap-al02-c9 ap-mi01.2 + ap-mi01.3 ap-mi01.6 + ap-mi01.9 cdp cp01-c1 dragonboard @@ -96,6 +106,7 @@ description: | hk10-c2 idp liquid + rdp432-c2 mtp qrd rb2 @@ -178,6 +189,7 @@ properties: - items: - enum: + - samsung,a7 - sony,kanuti-tulip - square,apq8039-t2 - const: qcom,msm8939 @@ -191,6 +203,7 @@ properties: - items: - enum: - qcom,msm8960-cdp + - samsung,expressatt - const: qcom,msm8960 - items: @@ -332,8 +345,15 @@ properties: - items: - enum: + - qcom,ipq5018-rdp432-c2 + - const: qcom,ipq5018 + + - items: + - enum: - qcom,ipq5332-ap-mi01.2 + - qcom,ipq5332-ap-mi01.3 - qcom,ipq5332-ap-mi01.6 + - qcom,ipq5332-ap-mi01.9 - const: qcom,ipq5332 - items: @@ -351,7 +371,11 @@ properties: - items: - enum: + - qcom,ipq9574-ap-al02-c2 + - qcom,ipq9574-ap-al02-c6 - qcom,ipq9574-ap-al02-c7 + - qcom,ipq9574-ap-al02-c8 + - qcom,ipq9574-ap-al02-c9 - const: qcom,ipq9574 - description: Sierra Wireless MangOH Green with WP8548 Module @@ -380,9 +404,9 @@ properties: - qcom,qru1000-idp - const: qcom,qru1000 - - description: Qualcomm Technologies, Inc. SC7180 IDP - items: + - items: - enum: + - acer,aspire1 - qcom,sc7180-idp - const: qcom,sc7180 @@ -821,6 +845,11 @@ properties: - items: - enum: + - qcom,sdx75-idp + - const: qcom,sdx75 + + - items: + - enum: - qcom,ipq6018-cp01 - qcom,ipq6018-cp01-c1 - const: qcom,ipq6018 @@ -884,6 +913,16 @@ properties: - items: - enum: + - qcom,sm4450-qrd + - const: qcom,sm4450 + + - items: + - enum: + - fxtec,pro1x + - const: qcom,sm6115 + + - items: + - enum: - lenovo,j606f - const: qcom,sm6115p - const: qcom,sm6115 @@ -1042,6 +1081,7 @@ allOf: - qcom,sdm845 - qcom,sdx55 - qcom,sdx65 + - qcom,sdx75 - qcom,sm4250 - qcom,sm6115 - qcom,sm6125 diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index ec141c937b8b..ca5389862887 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -40,6 +40,11 @@ properties: - const: anbernic,rg353p - const: rockchip,rk3566 + - description: Anbernic RG353PS + items: + - const: anbernic,rg353ps + - const: rockchip,rk3566 + - description: Anbernic RG353V items: - const: anbernic,rg353v @@ -102,6 +107,12 @@ properties: - const: edgeble,neural-compute-module-6a # Edgeble Neural Compute Module 6A SoM - const: rockchip,rk3588 + - description: Edgeble Neural Compute Module 6(Neu6) Model B SoM based boards + items: + - const: edgeble,neural-compute-module-6b-io # Edgeble Neural Compute Module 6B IO Board + - const: edgeble,neural-compute-module-6b # Edgeble Neural Compute Module 6B SoM + - const: rockchip,rk3588 + - description: Elgin RV1108 R1 items: - const: elgin,rv1108-r1 @@ -185,10 +196,16 @@ properties: - const: firefly,rk3566-roc-pc - const: rockchip,rk3566 + - description: Firefly Station P2 + items: + - const: firefly,rk3568-roc-pc + - const: rockchip,rk3568 + - description: FriendlyElec NanoPi R2 series boards items: - enum: - friendlyarm,nanopi-r2c + - friendlyarm,nanopi-r2c-plus - friendlyarm,nanopi-r2s - const: rockchip,rk3328 @@ -210,6 +227,11 @@ properties: - friendlyarm,nanopi-r5s - const: rockchip,rk3568 + - description: FriendlyElec NanoPC T6 + items: + - const: friendlyarm,nanopc-t6 + - const: rockchip,rk3588 + - description: GeekBuying GeekBox items: - const: geekbuying,geekbox @@ -534,6 +556,11 @@ properties: - const: hugsun,x99 - const: rockchip,rk3399 + - description: Indiedroid Nova SBC + items: + - const: indiedroid,nova + - const: rockchip,rk3588s + - description: Khadas Edge series boards items: - enum: @@ -562,6 +589,13 @@ properties: - const: leez,p710 - const: rockchip,rk3399 + - description: Lunzn FastRhino R66S / R68S + items: + - enum: + - lunzn,fastrhino-r66s + - lunzn,fastrhino-r68s + - const: rockchip,rk3568 + - description: mqmaker MiQi items: - const: mqmaker,miqi @@ -670,6 +704,11 @@ properties: - const: radxa,rock-4c-plus - const: rockchip,rk3399 + - description: Radxa ROCK 4SE + items: + - const: radxa,rock-4se + - const: rockchip,rk3399 + - description: Radxa ROCK Pi E items: - const: radxa,rockpi-e diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml index deb2cf971871..e3ffd8159ab6 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml @@ -72,6 +72,16 @@ properties: - const: samsung,exynos4210 - const: samsung,exynos4 + - description: Samsung Galaxy Tab3 family boards + items: + - enum: + - samsung,t310 # Samsung Galaxy Tab 3 8.0 WiFi (SM-T310) + - samsung,t311 # Samsung Galaxy Tab 3 8.0 3G (SM-T311) + - samsung,t315 # Samsung Galaxy Tab 3 8.0 LTE (SM-T315) + - const: samsung,tab3 + - const: samsung,exynos4212 + - const: samsung,exynos4 + - description: Exynos4412 based boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml new file mode 100644 index 000000000000..72554a4f1c92 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/socionext/synquacer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext Synquacer platform + +maintainers: + - Masahisa Kojima <masahisa.kojima@linaro.org> + - Jassi Brar <jaswinder.singh@linaro.org> + +description: + Socionext SC2A11B (Synquacer) SoC based boards + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - items: + - enum: + - socionext,developer-box + - const: socionext,synquacer + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml b/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml index 2297ad3f4774..d2dce238ff5d 100644 --- a/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/stm32/st,mlahb.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/stm32/st,mlahb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 ML-AHB interconnect diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml index ad8e51aa01b0..d083d8ad48b7 100644 --- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/stm32/st,stm32-syscon.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/stm32/st,stm32-syscon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 Platforms System Controller @@ -15,12 +15,13 @@ properties: oneOf: - items: - enum: - - st,stm32mp157-syscfg - - st,stm32mp151-pwr-mcu - - st,stm32-syscfg - st,stm32-power-config + - st,stm32-syscfg - st,stm32-tamp - st,stm32f4-gcan + - st,stm32mp151-pwr-mcu + - st,stm32mp157-syscfg + - st,stm32mp25-syscfg - const: syscon - items: - const: st,stm32-tamp diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 13e34241145b..4bf28e717a56 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -143,7 +143,9 @@ properties: - description: Octavo OSD32MP15x System-in-Package based boards items: - enum: - - lxa,stm32mp157c-mc1 # Linux Automation MC-1 + - lxa,stm32mp157c-mc1 # Linux Automation MC-1 + - lxa,stm32mp157c-tac-gen1 # Linux Automation TAC (Generation 1) + - lxa,stm32mp157c-tac-gen2 # Linux Automation TAC (Generation 2) - const: oct,stm32mp15xx-osd32 - enum: - st,stm32mp157 @@ -155,6 +157,18 @@ properties: - const: seeed,stm32mp157c-odyssey-som - const: st,stm32mp157 + - description: Phytec STM32MP1 SoM based Boards + items: + - const: phytec,phycore-stm32mp1-3 + - const: phytec,phycore-stm32mp157c-som + - const: st,stm32mp157 + + - description: ST STM32MP257 based Boards + items: + - enum: + - st,stm32mp257f-ev1 + - const: st,stm32mp257 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 013821f4a7b8..e4dd678f4212 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -305,6 +305,12 @@ properties: - const: allwinner,i12-tvbox - const: allwinner,sun7i-a20 + - description: ICnova A20 ADB4006 + items: + - const: incircuit,icnova-a20-adb4006 + - const: incircuit,icnova-a20 + - const: allwinner,sun7i-a20 + - description: ICNova A20 SWAC items: - const: incircuit,icnova-a20-swac @@ -535,13 +541,13 @@ properties: - const: msi,primo81 - const: allwinner,sun6i-a31s - - description: Emlid Neutis N5 Developper Board + - description: Emlid Neutis N5 Developer Board items: - const: emlid,neutis-n5-devboard - const: emlid,neutis-n5 - const: allwinner,sun50i-h5 - - description: Emlid Neutis N5H3 Developper Board + - description: Emlid Neutis N5H3 Developer Board items: - const: emlid,neutis-n5h3-devboard - const: emlid,neutis-n5h3 @@ -991,4 +997,9 @@ properties: - const: xunlong,orangepi-zero2 - const: allwinner,sun50i-h616 + - description: Xunlong OrangePi Zero 3 + items: + - const: xunlong,orangepi-zero3 + - const: allwinner,sun50i-h618 + additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index 0df41f5b7e2a..fcf956406168 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -167,6 +167,11 @@ properties: - const: nvidia,p3737-0000+p3701-0000 - const: nvidia,p3701-0000 - const: nvidia,tegra234 + - description: NVIDIA IGX Orin Development Kit + items: + - const: nvidia,p3740-0002+p3701-0008 + - const: nvidia,p3701-0008 + - const: nvidia,tegra234 - description: Jetson Orin NX items: - const: nvidia,p3767-0000 @@ -176,5 +181,14 @@ properties: - const: nvidia,p3768-0000+p3767-0000 - const: nvidia,p3767-0000 - const: nvidia,tegra234 + - description: Jetson Orin Nano + items: + - const: nvidia,p3767-0005 + - const: nvidia,tegra234 + - description: Jetson Orin Nano Developer Kit + items: + - const: nvidia,p3768-0000+p3767-0005 + - const: nvidia,p3767-0005 + - const: nvidia,tegra234 additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt deleted file mode 100644 index 5ae601e7f51f..000000000000 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt +++ /dev/null @@ -1,21 +0,0 @@ -NVIDIA compliant embedded controller - -Required properties: -- compatible : should be "nvidia,nvec". -- reg : the iomem of the i2c slave controller -- interrupts : the interrupt line of the i2c slave controller -- clock-frequency : the frequency of the i2c bus -- gpios : the gpio used for ec request -- slave-addr: the i2c address of the slave controller -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - Tegra20/Tegra30: - - div-clk - - fast-clk - Tegra114: - - div-clk -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - i2c diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt deleted file mode 100644 index 9a4295b54539..000000000000 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt +++ /dev/null @@ -1,17 +0,0 @@ -NVIDIA Tegra AHB - -Required properties: -- compatible : For Tegra20, must contain "nvidia,tegra20-ahb". For - Tegra30, must contain "nvidia,tegra30-ahb". Otherwise, must contain - '"nvidia,<chip>-ahb", "nvidia,tegra30-ahb"' where <chip> is tegra124, - tegra132, or tegra210. -- reg : Should contain 1 register ranges(address and length). For - Tegra20, Tegra30, and Tegra114 chips, the value must be <0x6000c004 - 0x10c>. For Tegra124, Tegra132 and Tegra210 chips, the value should - be be <0x6000c000 0x150>. - -Example (for a Tegra20 chip): - ahb: ahb@6000c004 { - compatible = "nvidia,tegra20-ahb"; - reg = <0x6000c004 0x10c>; /* AHB Arbitration + Gizmo Controller */ - }; diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt deleted file mode 100644 index a855c1bffc0f..000000000000 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt +++ /dev/null @@ -1,18 +0,0 @@ -NVIDIA Tegra Flow Controller - -Required properties: -- compatible: Should contain one of the following: - - "nvidia,tegra20-flowctrl": for Tegra20 - - "nvidia,tegra30-flowctrl": for Tegra30 - - "nvidia,tegra114-flowctrl": for Tegra114 - - "nvidia,tegra124-flowctrl": for Tegra124 - - "nvidia,tegra132-flowctrl", "nvidia,tegra124-flowctrl": for Tegra132 - - "nvidia,tegra210-flowctrl": for Tegra210 -- reg: Should contain one register range (address and length) - -Example: - - flow-controller@60007000 { - compatible = "nvidia,tegra20-flowctrl"; - reg = <0x60007000 0x1000>; - }; diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index e1183f90bb06..03d2a0d79fb0 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -25,6 +25,18 @@ properties: - ti,am62a7-sk - const: ti,am62a7 + - description: K3 AM62P5 SoC and Boards + items: + - enum: + - ti,am62p5-sk + - const: ti,am62p5 + + - description: K3 AM625 SoC PHYTEC phyBOARD-Lyra + items: + - const: phytec,am625-phyboard-lyra-rdk + - const: phytec,am62-phycore-som + - const: ti,am625 + - description: K3 AM625 SoC items: - enum: @@ -33,6 +45,26 @@ properties: - ti,am62-lp-sk - const: ti,am625 + - description: K3 AM62x SoC Toradex Verdin Modules and Carrier Boards + items: + - enum: + - toradex,verdin-am62-nonwifi-dahlia # Verdin AM62 Module on Dahlia + - toradex,verdin-am62-nonwifi-dev # Verdin AM62 Module on Verdin Development Board + - toradex,verdin-am62-nonwifi-yavia # Verdin AM62 Module on Yavia + - const: toradex,verdin-am62-nonwifi # Verdin AM62 Module without Wi-Fi / BT + - const: toradex,verdin-am62 # Verdin AM62 Module + - const: ti,am625 + + - description: K3 AM62x SoC Toradex Verdin Modules and Carrier Boards with Wi-Fi / BT + items: + - enum: + - toradex,verdin-am62-wifi-dahlia # Verdin AM62 Wi-Fi / BT Module on Dahlia + - toradex,verdin-am62-wifi-dev # Verdin AM62 Wi-Fi / BT M. on Verdin Development B. + - toradex,verdin-am62-wifi-yavia # Verdin AM62 Wi-Fi / BT Module on Yavia + - const: toradex,verdin-am62-wifi # Verdin AM62 Wi-Fi / BT Module + - const: toradex,verdin-am62 # Verdin AM62 Module + - const: ti,am625 + - description: K3 AM642 SoC items: - enum: @@ -46,6 +78,13 @@ properties: - const: phytec,am64-phycore-som - const: ti,am642 + - description: K3 AM642 SoC on TQ-Systems TQMaX4XxL SoM + items: + - enum: + - tq,am642-tqma6442l-mbax4xxl # MBaX4XxL base board + - const: tq,am642-tqma6442l + - const: ti,am642 + - description: K3 AM654 SoC items: - enum: diff --git a/Documentation/devicetree/bindings/arm/ti/omap.yaml b/Documentation/devicetree/bindings/arm/ti/omap.yaml new file mode 100644 index 000000000000..b18fc046390a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/ti/omap.yaml @@ -0,0 +1,176 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/ti/omap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments OMAP SoC architecture + +maintainers: + - Tony Lindgren <tony@atomide.com> + +description: Platforms based on Texas Instruments OMAP SoC architecture. + +properties: + $nodename: + const: '/' + compatible: + oneOf: + + - description: TI OMAP2420 SoC based platforms + items: + - enum: + - nokia,n800 + - nokia,n810 + - nokia,n810-wimax + - ti,omap2420-h4 + - const: ti,omap2420 + - const: ti,omap2 + + - description: TI OMAP2430 SoC based platforms + items: + - enum: + - ti,omap2430-sdp # TI OMAP2430 SDP + - const: ti,omap2430 + - const: ti,omap2 + + - description: TI OMAP3430 SoC based platforms + items: + - enum: + - compulab,omap3-cm-t3530 + - logicpd,dm3730-som-lv-devkit # LogicPD Zoom OMAP35xx SOM-LV Development Kit + - logicpd,dm3730-torpedo-devkit # LogicPD Zoom OMAP35xx Torpedo Development Kit + - nokia,omap3-n900 + - openpandora,omap3-pandora-600mhz + - ti,omap3430-sdp + - ti,omap3-beagle + - ti,omap3-evm # TI OMAP35XX EVM (TMDSEVM3530) + - ti,omap3-ldp # TI OMAP3430 LDP (Zoom1 Labrador) + - timll,omap3-devkit8000 + - const: ti,omap3430 + - const: ti,omap3 + + - description: Early BeagleBoard revisions A to B4 with a timer quirk + items: + - const: ti,omap3-beagle-ab4 + - const: ti,omap3-beagle + - const: ti,omap3430 + - const: ti,omap3 + + - description: Gumstix Overo TI OMAP 3430/3630 boards + expansion boards + items: + - enum: + - gumstix,omap3-overo-alto35 + - gumstix,omap3-overo-chestnut43 + - gumstix,omap3-overo-gallop43 + - gumstix,omap3-overo-palo35 + - gumstix,omap3-overo-palo43 + - gumstix,omap3-overo-summit + - gumstix,omap3-overo-tobi + - gumstix,omap3-overo-tobiduo + - const: gumstix,omap3-overo + - enum: + - ti,omap3430 + - ti,omap3630 + + - description: TI OMAP3630 SoC based platforms + items: + - enum: + - amazon,omap3-echo # Amazon Echo (first generation) + - compulab,omap3-cm-t3730 + - goldelico,gta04 + - lg,omap3-sniper # LG Optimus Black + - logicpd,dm3730-som-lv-devkit # LogicPD Zoom DM3730 SOM-LV Development Kit + - logicpd,dm3730-torpedo-devkit # LogicPD Zoom DM3730 Torpedo + Wireless Development Kit + - nokia,omap3-n9 + - nokia,omap3-n950 + - openpandora,omap3-pandora-1ghz + - ti,omap3-beagle-xm + - ti,omap3-evm-37xx # TI OMAP37XX EVM (TMDSEVM3730) + - ti,omap3-zoom3 + - const: ti,omap3630 + - const: ti,omap3 + + - description: TI AM35 SoC based platforms + items: + - enum: + - compulab,omap3-sbc-t3517 # CompuLab SBC-T3517 with CM-T3517 + - teejet,mt_ventoux + - ti,am3517-craneboard # TI AM3517 CraneBoard (TMDSEVM3517) + - ti,am3517-evm # TI AM3517 EVM (AM3517/05 TMDSEVM3517) + - const: ti,am3517 + - const: ti,omap3 + + - description: TI AM33 based platform + items: + - enum: + - compulab,cm-t335 + - moxa,uc-8100-me-t + - novatech,am335x-lxm + - ti,am335x-bone + - ti,am335x-evm + - ti,am3359-icev2 + - const: ti,am33xx + + - description: Compulab board variants based on TI AM33 + items: + - enum: + - compulab,sbc-t335 + - const: compulab,cm-t335 + - const: ti,am33xx + + - description: Phytec boards based on TI AM33 + items: + - enum: + - phytec,am335x-wega + - phytec,am335x-pcm-953 + - phytec,am335x-regor + - const: phytec,am335x-phycore-som + - const: ti,am33xx + + - description: TI OMAP4430 SoC based platforms + items: + - enum: + - amazon,omap4-kc1 # Amazon Kindle Fire (first generation) + - motorola,droid4 # Motorola Droid 4 XT894 + - motorola,droid-bionic # Motorola Droid Bionic XT875 + - ti,omap4-panda + - ti,omap4-sdp + - const: ti,omap4430 + - const: ti,omap4 + + - description: OMAP4 DuoVero with Parlor expansion board/daughter board + items: + - const: gumstix,omap4-duovero-parlor + - const: gumstix,omap4-duovero + - const: ti,omap4430 + - const: ti,omap4 + + - description: TI OMAP4460 SoC based platforms + items: + - enum: + - epson,embt2ws # Epson Moverio BT-200 + - ti,omap4-panda-es + - const: ti,omap4460 + - const: ti,omap4 + + - description: VAR-OM44 boards + items: + - enum: + - variscite,var-dvk-om44 + - variscite,var-stk-om44 + - const: variscite,var-som-om44 + - const: ti,omap4460 + - const: ti,omap4 + + - description: TI OMAP5 SoC based platforms + items: + - enum: + - compulab,omap5-cm-t54 + - isee,omap5-igep0050 + - ti,omap5-uevm + - const: ti,omap5 + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt index 61d77acbeb5e..f925290d4641 100644 --- a/Documentation/devicetree/bindings/arm/xen.txt +++ b/Documentation/devicetree/bindings/arm/xen.txt @@ -56,7 +56,7 @@ hypervisor { }; The format and meaning of the "xen,uefi-*" parameters are similar to those in -Documentation/arm/uefi.rst, which are provided by the regular UEFI stub. However +Documentation/arch/arm/uefi.rst, which are provided by the regular UEFI stub. However they differ because they are provided by the Xen hypervisor, together with a set of UEFI runtime services implemented via hypercalls, see http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html. diff --git a/Documentation/devicetree/bindings/arm/xilinx.yaml b/Documentation/devicetree/bindings/arm/xilinx.yaml index 969cfe6dc434..f57ed0347894 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.yaml +++ b/Documentation/devicetree/bindings/arm/xilinx.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx Zynq Platforms maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> description: | Xilinx boards with Zynq-7000 SOC or Zynq UltraScale+ MPSoC @@ -61,10 +61,10 @@ properties: - const: xlnx,zynqmp-zc1254 - const: xlnx,zynqmp - - description: Xilinx internal board zc1275 + - description: Xilinx evaluation board zcu1275 items: - - const: xlnx,zynqmp-zc1275-revA - - const: xlnx,zynqmp-zc1275 + - const: xlnx,zynqmp-zcu1275-revA + - const: xlnx,zynqmp-zcu1275 - const: xlnx,zynqmp - description: Xilinx 96boards compatible board zcu100 diff --git a/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml b/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml index 71364c6081ff..b29ce598f9aa 100644 --- a/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml +++ b/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Ceva AHCI SATA Controller maintainers: - - Piyush Mehta <piyush.mehta@xilinx.com> + - Piyush Mehta <piyush.mehta@amd.com> description: | The Ceva SATA controller mostly conforms to the AHCI interface with some diff --git a/Documentation/devicetree/bindings/ata/pata-common.yaml b/Documentation/devicetree/bindings/ata/pata-common.yaml index 2412894a255d..337ddf1113c4 100644 --- a/Documentation/devicetree/bindings/ata/pata-common.yaml +++ b/Documentation/devicetree/bindings/ata/pata-common.yaml @@ -12,7 +12,7 @@ maintainers: description: | This document defines device tree properties common to most Parallel ATA (PATA, also known as IDE) AT attachment storage devices. - It doesn't constitue a device tree binding specification by itself but is + It doesn't constitute a device tree binding specification by itself but is meant to be referenced by device tree bindings. The PATA (IDE) controller-specific device tree bindings are responsible for diff --git a/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml b/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml new file mode 100644 index 000000000000..b5e5767d8698 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/rockchip,dwc-ahci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DWC AHCI SATA controller for Rockchip devices + +maintainers: + - Serge Semin <fancer.lancer@gmail.com> + +description: + This document defines device tree bindings for the Synopsys DWC + implementation of the AHCI SATA controller found in Rockchip + devices. + +select: + properties: + compatible: + contains: + enum: + - rockchip,rk3568-dwc-ahci + - rockchip,rk3588-dwc-ahci + required: + - compatible + +properties: + compatible: + items: + - enum: + - rockchip,rk3568-dwc-ahci + - rockchip,rk3588-dwc-ahci + - const: snps,dwc-ahci + + ports-implemented: + const: 1 + + sata-port@0: + $ref: /schemas/ata/snps,dwc-ahci-common.yaml#/$defs/dwc-ahci-port + + properties: + reg: + const: 0 + + unevaluatedProperties: false + +patternProperties: + "^sata-port@[1-9a-e]$": false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - ports-implemented + +allOf: + - $ref: snps,dwc-ahci-common.yaml# + - if: + properties: + compatible: + contains: + enum: + - rockchip,rk3588-dwc-ahci + then: + properties: + clocks: + maxItems: 5 + clock-names: + items: + - const: sata + - const: pmalive + - const: rxoob + - const: ref + - const: asic + - if: + properties: + compatible: + contains: + enum: + - rockchip,rk3568-dwc-ahci + then: + properties: + clocks: + maxItems: 3 + clock-names: + items: + - const: sata + - const: pmalive + - const: rxoob + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/rockchip,rk3588-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/ata/ahci.h> + #include <dt-bindings/phy/phy.h> + + sata@fe210000 { + compatible = "rockchip,rk3588-dwc-ahci", "snps,dwc-ahci"; + reg = <0xfe210000 0x1000>; + clocks = <&cru ACLK_SATA0>, <&cru CLK_PMALIVE0>, + <&cru CLK_RXOOB0>, <&cru CLK_PIPEPHY0_REF>, + <&cru CLK_PIPEPHY0_PIPE_ASIC_G>; + clock-names = "sata", "pmalive", "rxoob", "ref", "asic"; + interrupts = <GIC_SPI 273 IRQ_TYPE_LEVEL_HIGH 0>; + ports-implemented = <0x1>; + #address-cells = <1>; + #size-cells = <0>; + + sata-port@0 { + reg = <0>; + hba-port-cap = <HBA_PORT_FBSCP>; + phys = <&combphy0_ps PHY_TYPE_SATA>; + phy-names = "sata-phy"; + snps,rx-ts-max = <32>; + snps,tx-ts-max = <32>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml b/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml index c1457910520b..34c5bf65b02d 100644 --- a/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml +++ b/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml @@ -31,11 +31,11 @@ properties: PM-alive clock, RxOOB detection clock, embedded PHYs reference (Rx/Tx) clock, etc. minItems: 1 - maxItems: 4 + maxItems: 6 clock-names: minItems: 1 - maxItems: 4 + maxItems: 6 items: oneOf: - description: Application APB/AHB/AXI BIU clock @@ -48,6 +48,10 @@ properties: const: pmalive - description: RxOOB detection clock const: rxoob + - description: PHY Transmit Clock + const: asic + - description: PHY Receive Clock + const: rbc - description: SATA Ports reference clock const: ref diff --git a/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml index 5afa4b57ce20..4c848fcb5a5d 100644 --- a/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml +++ b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml @@ -13,6 +13,15 @@ description: This document defines device tree bindings for the generic Synopsys DWC implementation of the AHCI SATA controller. +select: + properties: + compatible: + enum: + - snps,dwc-ahci + - snps,spear-ahci + required: + - compatible + allOf: - $ref: snps,dwc-ahci-common.yaml# @@ -23,10 +32,6 @@ properties: const: snps,dwc-ahci - description: SPEAr1340 AHCI SATA device const: snps,spear-ahci - - description: Rockhip RK3568 AHCI controller - items: - - const: rockchip,rk3568-dwc-ahci - - const: snps,dwc-ahci patternProperties: "^sata-port@[0-9a-e]$": diff --git a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml index 49304a1476ab..be95f6b97b41 100644 --- a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml +++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml @@ -40,6 +40,7 @@ properties: linux,keymap: true linux,no-autorepeat: + type: boolean description: Disable keyrepeat default-brightness-level: diff --git a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml index b23c3001991e..3aaefdbe361e 100644 --- a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml +++ b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml @@ -43,7 +43,7 @@ properties: brcm,gisb-arb-master-names: $ref: /schemas/types.yaml#/definitions/string-array description: > - String list of the litteral name of the GISB masters. Should match the + String list of the literal name of the GISB masters. Should match the number of bits set in brcm,gisb-master-mask and the order in which they appear from MSB to LSB. diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml index 4157e885c6e7..26362c9006e2 100644 --- a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml @@ -7,10 +7,10 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra ACONNECT Bus description: | - The Tegra ACONNECT bus is an AXI switch which is used to connnect various + The Tegra ACONNECT bus is an AXI switch which is used to connect various components inside the Audio Processing Engine (APE). All CPU accesses to the APE subsystem go through the ACONNECT via an APB to AXI wrapper. All - devices accessed via the ACONNNECT are described by child-nodes. + devices accessed via the ACONNECT are described by child-nodes. maintainers: - Jon Hunter <jonathanh@nvidia.com> diff --git a/Documentation/devicetree/bindings/bus/qcom,ssbi.yaml b/Documentation/devicetree/bindings/bus/qcom,ssbi.yaml new file mode 100644 index 000000000000..693cfa9696b5 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/qcom,ssbi.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/qcom,ssbi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Single-wire Serial Bus Interface (SSBI) + +description: + Some Qualcomm MSM devices contain a point-to-point serial bus used to + communicate with a limited range of devices (mostly power management + chips). + +maintainers: + - Andy Gross <agross@kernel.org> + - Bjorn Andersson <andersson@kernel.org> + +properties: + compatible: + const: qcom,ssbi + + reg: + maxItems: 1 + + qcom,controller-type: + description: + Indicates the SSBI bus variant the controller should use to talk + with the slave device. The type chosen is determined by the attached + slave. + enum: + - ssbi + - ssbi2 + - pmic-arbiter + + pmic: + $ref: /schemas/mfd/qcom-pm8xxx.yaml# + +required: + - compatible + - reg + - qcom,controller-type + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + ssbi@c00000 { + compatible = "qcom,ssbi"; + reg = <0x00c00000 0x1000>; + qcom,controller-type = "pmic-arbiter"; + + pmic { + compatible = "qcom,pm8821"; + interrupt-parent = <&msmgpio>; + interrupts = <76 IRQ_TYPE_LEVEL_LOW>; + #interrupt-cells = <2>; + interrupt-controller; + #address-cells = <1>; + #size-cells = <0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.yaml b/Documentation/devicetree/bindings/bus/ti-sysc.yaml index f089634f9466..6d7bca6c138e 100644 --- a/Documentation/devicetree/bindings/bus/ti-sysc.yaml +++ b/Documentation/devicetree/bindings/bus/ti-sysc.yaml @@ -97,7 +97,7 @@ properties: - enum: [ ick, fck, sys_clk ] - items: - const: fck - - enum: [ ick. dbclk, osc, sys_clk, dss_clk, ahclkx ] + - enum: [ ick, dbclk, osc, sys_clk, dss_clk, ahclkx ] - items: - const: fck - const: phy-clk diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml index 3b0548c34791..9f9816fbecbc 100644 --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml @@ -29,10 +29,8 @@ properties: patternProperties: '^connector@[0-9a-f]+$': $ref: /schemas/connector/usb-connector.yaml# - unevaluatedProperties: false - properties: - reg: - maxItems: 1 + required: + - reg required: - compatible diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml index 52a7b6e7124c..0052bf1e8a6b 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-osc-clk.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Allwinner A10 Gatable Oscillator Clock +title: Allwinner A10 Gateable Oscillator Clock maintainers: - Chen-Yu Tsai <wens@csie.org> diff --git a/Documentation/devicetree/bindings/clock/alphascale,acc.txt b/Documentation/devicetree/bindings/clock/alphascale,acc.txt index b3205b21c9d0..c9fb9324c634 100644 --- a/Documentation/devicetree/bindings/clock/alphascale,acc.txt +++ b/Documentation/devicetree/bindings/clock/alphascale,acc.txt @@ -1,7 +1,7 @@ Alphascale Clock Controller -The ACC (Alphascale Clock Controller) is responsible of choising proper -clock source, setting deviders and clock gates. +The ACC (Alphascale Clock Controller) is responsible for choosing proper +clock source, setting dividers and clock gates. Required properties for the ACC node: - compatible: must be "alphascale,asm9260-clock-controller" diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml new file mode 100644 index 000000000000..6d84cee1bd75 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/amlogic,a1-peripherals-clkc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic A1 Peripherals Clock Control Unit + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + - Jerome Brunet <jbrunet@baylibre.com> + - Jian Hu <jian.hu@jian.hu.com> + - Dmitry Rokosov <ddrokosov@sberdevices.ru> + +properties: + compatible: + const: amlogic,a1-peripherals-clkc + + '#clock-cells': + const: 1 + + reg: + maxItems: 1 + + clocks: + items: + - description: input fixed pll div2 + - description: input fixed pll div3 + - description: input fixed pll div5 + - description: input fixed pll div7 + - description: input hifi pll + - description: input oscillator (usually at 24MHz) + + clock-names: + items: + - const: fclk_div2 + - const: fclk_div3 + - const: fclk_div5 + - const: fclk_div7 + - const: hifi_pll + - const: xtal + +required: + - compatible + - '#clock-cells' + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/amlogic,a1-pll-clkc.h> + apb { + #address-cells = <2>; + #size-cells = <2>; + + clock-controller@800 { + compatible = "amlogic,a1-peripherals-clkc"; + reg = <0 0x800 0 0x104>; + #clock-cells = <1>; + clocks = <&clkc_pll CLKID_FCLK_DIV2>, + <&clkc_pll CLKID_FCLK_DIV3>, + <&clkc_pll CLKID_FCLK_DIV5>, + <&clkc_pll CLKID_FCLK_DIV7>, + <&clkc_pll CLKID_HIFI_PLL>, + <&xtal>; + clock-names = "fclk_div2", "fclk_div3", + "fclk_div5", "fclk_div7", + "hifi_pll", "xtal"; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml new file mode 100644 index 000000000000..a59b188a8bf5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.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/amlogic,a1-pll-clkc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic A1 PLL Clock Control Unit + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + - Jerome Brunet <jbrunet@baylibre.com> + - Jian Hu <jian.hu@jian.hu.com> + - Dmitry Rokosov <ddrokosov@sberdevices.ru> + +properties: + compatible: + const: amlogic,a1-pll-clkc + + '#clock-cells': + const: 1 + + reg: + maxItems: 1 + + clocks: + items: + - description: input fixpll_in + - description: input hifipll_in + + clock-names: + items: + - const: fixpll_in + - const: hifipll_in + +required: + - compatible + - '#clock-cells' + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/amlogic,a1-peripherals-clkc.h> + apb { + #address-cells = <2>; + #size-cells = <2>; + + clock-controller@7c80 { + compatible = "amlogic,a1-pll-clkc"; + reg = <0 0x7c80 0 0x18c>; + #clock-cells = <1>; + clocks = <&clkc_periphs CLKID_FIXPLL_IN>, + <&clkc_periphs CLKID_HIFIPLL_IN>; + clock-names = "fixpll_in", "hifipll_in"; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt b/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt deleted file mode 100644 index c41f0be5d438..000000000000 --- a/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt +++ /dev/null @@ -1,64 +0,0 @@ -* Amlogic GXBB AO Clock and Reset Unit - -The Amlogic GXBB AO clock controller generates and supplies clock to various -controllers within the Always-On part of the SoC. - -Required Properties: - -- compatible: value should be different for each SoC family as : - - GXBB (S905) : "amlogic,meson-gxbb-aoclkc" - - GXL (S905X, S905D) : "amlogic,meson-gxl-aoclkc" - - GXM (S912) : "amlogic,meson-gxm-aoclkc" - - AXG (A113D, A113X) : "amlogic,meson-axg-aoclkc" - - G12A (S905X2, S905D2, S905Y2) : "amlogic,meson-g12a-aoclkc" - followed by the common "amlogic,meson-gx-aoclkc" -- clocks: list of clock phandle, one for each entry clock-names. -- clock-names: should contain the following: - * "xtal" : the platform xtal - * "mpeg-clk" : the main clock controller mother clock (aka clk81) - * "ext-32k-0" : external 32kHz reference #0 if any (optional) - * "ext-32k-1" : external 32kHz reference #1 if any (optional - gx only) - * "ext-32k-2" : external 32kHz reference #2 if any (optional - gx only) - -- #clock-cells: should be 1. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/gxbb-aoclkc.h header and can be -used in device tree sources. - -- #reset-cells: should be 1. - -Each reset is assigned an identifier and client nodes can use this identifier -to specify the reset which they consume. All available resets are defined as -preprocessor macros in the dt-bindings/reset/gxbb-aoclkc.h header and can be -used in device tree sources. - -Parent node should have the following properties : -- compatible: "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd" -- reg: base address and size of the AO system control register space. - -Example: AO Clock controller node: - -ao_sysctrl: sys-ctrl@0 { - compatible = "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd"; - reg = <0x0 0x0 0x0 0x100>; - - clkc_AO: clock-controller { - compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc"; - #clock-cells = <1>; - #reset-cells = <1>; - clocks = <&xtal>, <&clkc CLKID_CLK81>; - clock-names = "xtal", "mpeg-clk"; - }; - -Example: UART controller node that consumes the clock and reset generated - by the clock controller: - - uart_AO: serial@4c0 { - compatible = "amlogic,meson-uart"; - reg = <0x4c0 0x14>; - interrupts = <0 90 1>; - clocks = <&clkc_AO CLKID_AO_UART1>; - resets = <&clkc_AO RESET_AO_UART1>; - }; diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.yaml new file mode 100644 index 000000000000..628e5dd33dd4 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/amlogic,gxbb-aoclkc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Always-On Clock Controller + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +properties: + compatible: + oneOf: + - items: + - enum: + - amlogic,meson-gxbb-aoclkc + - amlogic,meson-gxl-aoclkc + - amlogic,meson-gxm-aoclkc + - amlogic,meson-axg-aoclkc + - const: amlogic,meson-gx-aoclkc + - enum: + - amlogic,meson-axg-aoclkc + - amlogic,meson-g12a-aoclkc + + clocks: + minItems: 2 + maxItems: 5 + + clock-names: + minItems: 2 + items: + - const: xtal + - const: mpeg-clk + - const: ext-32k-0 + - const: ext-32k-1 + - const: ext-32k-2 + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + +required: + - compatible + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + +allOf: + - if: + properties: + compatible: + enum: + - amlogic,meson-g12a-aoclkc + + then: + properties: + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + maxItems: 3 + + - if: + properties: + compatible: + enum: + - amlogic,meson-gxl-aoclkc + - amlogic,meson-gxm-aoclkc + - amlogic,meson-axg-aoclkc + + then: + properties: + clocks: + maxItems: 2 + + clock-names: + maxItems: 2 + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt deleted file mode 100644 index 7ccecd5c02c1..000000000000 --- a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt +++ /dev/null @@ -1,53 +0,0 @@ -* Amlogic GXBB Clock and Reset Unit - -The Amlogic GXBB clock controller generates and supplies clock to various -controllers within the SoC. - -Required Properties: - -- compatible: should be: - "amlogic,gxbb-clkc" for GXBB SoC, - "amlogic,gxl-clkc" for GXL and GXM SoC, - "amlogic,axg-clkc" for AXG SoC. - "amlogic,g12a-clkc" for G12A SoC. - "amlogic,g12b-clkc" for G12B SoC. - "amlogic,sm1-clkc" for SM1 SoC. -- clocks : list of clock phandle, one for each entry clock-names. -- clock-names : should contain the following: - * "xtal": the platform xtal - -- #clock-cells: should be 1. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/gxbb-clkc.h header and can be -used in device tree sources. - -Parent node should have the following properties : -- compatible: "syscon", "simple-mfd, and "amlogic,meson-gx-hhi-sysctrl" or - "amlogic,meson-axg-hhi-sysctrl" -- reg: base address and size of the HHI system control register space. - -Example: Clock controller node: - -sysctrl: system-controller@0 { - compatible = "amlogic,meson-gx-hhi-sysctrl", "syscon", "simple-mfd"; - reg = <0 0 0 0x400>; - - clkc: clock-controller { - #clock-cells = <1>; - compatible = "amlogic,gxbb-clkc"; - clocks = <&xtal>; - clock-names = "xtal"; - }; -}; - -Example: UART controller node that consumes the clock generated by the clock - controller: - - uart_AO: serial@c81004c0 { - compatible = "amlogic,meson-uart"; - reg = <0xc81004c0 0x14>; - interrupts = <0 90 1>; - clocks = <&clkc CLKID_CLK81>; - }; diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.yaml new file mode 100644 index 000000000000..63246f1cb539 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/amlogic,gxbb-clkc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Clock Controller + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +properties: + compatible: + enum: + - amlogic,gxbb-clkc + - amlogic,gxl-clkc + - amlogic,axg-clkc + - amlogic,g12a-clkc + - amlogic,g12b-clkc + - amlogic,sm1-clkc + + clocks: + maxItems: 1 + + clock-names: + const: xtal + + '#clock-cells': + const: 1 + +required: + - compatible + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt deleted file mode 100644 index 13f45db3b66d..000000000000 --- a/Documentation/devicetree/bindings/clock/at91-clock.txt +++ /dev/null @@ -1,58 +0,0 @@ -Device Tree Clock bindings for arch-at91 - -This binding uses the common clock binding[1]. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt - -Slow Clock controller: - -Required properties: -- compatible : shall be one of the following: - "atmel,at91sam9x5-sckc", - "atmel,sama5d3-sckc", - "atmel,sama5d4-sckc" or - "microchip,sam9x60-sckc": - at91 SCKC (Slow Clock Controller) -- #clock-cells : shall be 1 for "microchip,sam9x60-sckc" otherwise shall be 0. -- clocks : shall be the input parent clock phandle for the clock. - -Optional properties: -- atmel,osc-bypass : boolean property. Set this when a clock signal is directly - provided on XIN. - -For example: - sckc@fffffe50 { - compatible = "atmel,at91sam9x5-sckc"; - reg = <0xfffffe50 0x4>; - clocks = <&slow_xtal>; - #clock-cells = <0>; - }; - -Power Management Controller (PMC): - -Required properties: -- compatible : shall be "atmel,<chip>-pmc", "syscon" or - "microchip,sam9x60-pmc" - <chip> can be: at91rm9200, at91sam9260, at91sam9261, - at91sam9263, at91sam9g45, at91sam9n12, at91sam9rl, at91sam9g15, - at91sam9g25, at91sam9g35, at91sam9x25, at91sam9x35, at91sam9x5, - sama5d2, sama5d3 or sama5d4. -- #clock-cells : from common clock binding; shall be set to 2. The first entry - is the type of the clock (core, system, peripheral or generated) and the - second entry its index as provided by the datasheet -- clocks : Must contain an entry for each entry in clock-names. -- clock-names: Must include the following entries: "slow_clk", "main_xtal" - -Optional properties: -- atmel,osc-bypass : boolean property. Set this when a clock signal is directly - provided on XIN. - -For example: - pmc: pmc@f0018000 { - compatible = "atmel,sama5d4-pmc", "syscon"; - reg = <0xf0018000 0x120>; - interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; - #clock-cells = <2>; - clocks = <&clk32k>, <&main_xtal>; - clock-names = "slow_clk", "main_xtal"; - }; diff --git a/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml b/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml new file mode 100644 index 000000000000..c1bdcd9058ed --- /dev/null +++ b/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml @@ -0,0 +1,154 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/atmel,at91rm9200-pmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Power Management Controller (PMC) + +maintainers: + - Claudiu Beznea <claudiu.beznea@microchip.com> + +description: + The power management controller optimizes power consumption by controlling all + system and user peripheral clocks. The PMC enables/disables the clock inputs + to many of the peripherals and to the processor. + +properties: + compatible: + oneOf: + - items: + - const: atmel,at91sam9g20-pmc + - const: atmel,at91sam9260-pmc + - const: syscon + - items: + - enum: + - atmel,at91sam9g15-pmc + - atmel,at91sam9g25-pmc + - atmel,at91sam9g35-pmc + - atmel,at91sam9x25-pmc + - atmel,at91sam9x35-pmc + - const: atmel,at91sam9x5-pmc + - const: syscon + - items: + - enum: + - atmel,at91rm9200-pmc + - atmel,at91sam9260-pmc + - atmel,at91sam9g45-pmc + - atmel,at91sam9n12-pmc + - atmel,at91sam9rl-pmc + - atmel,at91sam9x5-pmc + - atmel,sama5d2-pmc + - atmel,sama5d3-pmc + - atmel,sama5d4-pmc + - microchip,sam9x60-pmc + - microchip,sama7g5-pmc + - const: syscon + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#clock-cells": + description: | + - 1st cell is the clock type, one of PMC_TYPE_CORE, PMC_TYPE_SYSTEM, + PMC_TYPE_PERIPHERAL, PMC_TYPE_GCK, PMC_TYPE_PROGRAMMABLE (as defined + in <dt-bindings/clock/at91.h>) + - 2nd cell is the clock identifier as defined in <dt-bindings/clock/at91.h + (for core clocks) or as defined in datasheet (for system, peripheral, + gck and programmable clocks). + const: 2 + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + maxItems: 3 + + atmel,osc-bypass: + description: set when a clock signal is directly provided on XIN + type: boolean + +required: + - compatible + - reg + - interrupts + - "#clock-cells" + - clocks + - clock-names + +allOf: + - if: + properties: + compatible: + contains: + enum: + - microchip,sam9x60-pmc + - microchip,sama7g5-pmc + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: td_slck + - const: md_slck + - const: main_xtal + + - if: + properties: + compatible: + contains: + enum: + - atmel,at91rm9200-pmc + - atmel,at91sam9260-pmc + - atmel,at91sam9g20-pmc + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: slow_xtal + - const: main_xtal + + - if: + properties: + compatible: + contains: + enum: + - atmel,sama5d2-pmc + - atmel,sama5d3-pmc + - atmel,sama5d4-pmc + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: slow_clk + - const: main_xtal + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + pmc: clock-controller@f0018000 { + compatible = "atmel,sama5d4-pmc", "syscon"; + reg = <0xf0018000 0x120>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; + #clock-cells = <2>; + clocks = <&clk32k>, <&main_xtal>; + clock-names = "slow_clk", "main_xtal"; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml b/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml new file mode 100644 index 000000000000..7be29877e6d2 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/atmel,at91sam9x5-sckc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Slow Clock Controller (SCKC) + +maintainers: + - Claudiu Beznea <claudiu.beznea@microchip.com> + +properties: + compatible: + oneOf: + - enum: + - atmel,at91sam9x5-sckc + - atmel,sama5d3-sckc + - atmel,sama5d4-sckc + - microchip,sam9x60-sckc + - items: + - const: microchip,sama7g5-sckc + - const: microchip,sam9x60-sckc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#clock-cells": + enum: [0, 1] + + atmel,osc-bypass: + type: boolean + description: set when a clock signal is directly provided on XIN + +required: + - compatible + - reg + - clocks + - "#clock-cells" + +allOf: + - if: + properties: + compatible: + contains: + enum: + - microchip,sam9x60-sckc + then: + properties: + "#clock-cells": + const: 1 + else: + properties: + "#clock-cells": + const: 0 + +additionalProperties: false + +examples: + - | + clk32k: clock-controller@fffffe50 { + compatible = "microchip,sam9x60-sckc"; + reg = <0xfffffe50 0x4>; + clocks = <&slow_xtal>; + #clock-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml b/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml index 199818b2fb6d..cd0d763ce2f3 100644 --- a/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml +++ b/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/clock/brcm,bcm63268-timer-clocks.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Broadcom BCM63268 Timer Clock and Reset Device Tree Bindings +title: Broadcom BCM63268 Timer Clock and Reset maintainers: - Álvaro Fernández Rojas <noltari@gmail.com> diff --git a/Documentation/devicetree/bindings/clock/fsl,imx8-acm.yaml b/Documentation/devicetree/bindings/clock/fsl,imx8-acm.yaml new file mode 100644 index 000000000000..07b9d21719c4 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/fsl,imx8-acm.yaml @@ -0,0 +1,282 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/fsl,imx8-acm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8 Audio Clock Mux + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + +description: | + NXP i.MX8 Audio Clock Mux is dedicated clock muxing IP + used to control Audio related clock on the SoC. + +properties: + compatible: + enum: + - fsl,imx8dxl-acm + - fsl,imx8qm-acm + - fsl,imx8qxp-acm + + reg: + maxItems: 1 + + power-domains: + minItems: 13 + maxItems: 21 + + '#clock-cells': + const: 1 + description: + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8-clock.h + for the full list of i.MX8 ACM clock IDs. + + clocks: + minItems: 13 + maxItems: 27 + + clock-names: + minItems: 13 + maxItems: 27 + +required: + - compatible + - reg + - power-domains + - '#clock-cells' + - clocks + - clock-names + +allOf: + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8qxp-acm + then: + properties: + power-domains: + items: + - description: power domain of IMX_SC_R_AUDIO_CLK_0 + - description: power domain of IMX_SC_R_AUDIO_CLK_1 + - description: power domain of IMX_SC_R_MCLK_OUT_0 + - description: power domain of IMX_SC_R_MCLK_OUT_1 + - description: power domain of IMX_SC_R_AUDIO_PLL_0 + - description: power domain of IMX_SC_R_AUDIO_PLL_1 + - description: power domain of IMX_SC_R_ASRC_0 + - description: power domain of IMX_SC_R_ASRC_1 + - description: power domain of IMX_SC_R_ESAI_0 + - description: power domain of IMX_SC_R_SAI_0 + - description: power domain of IMX_SC_R_SAI_1 + - description: power domain of IMX_SC_R_SAI_2 + - description: power domain of IMX_SC_R_SAI_3 + - description: power domain of IMX_SC_R_SAI_4 + - description: power domain of IMX_SC_R_SAI_5 + - description: power domain of IMX_SC_R_SPDIF_0 + - description: power domain of IMX_SC_R_MQS_0 + + clocks: + minItems: 18 + maxItems: 18 + + clock-names: + items: + - const: aud_rec_clk0_lpcg_clk + - const: aud_rec_clk1_lpcg_clk + - const: aud_pll_div_clk0_lpcg_clk + - const: aud_pll_div_clk1_lpcg_clk + - const: ext_aud_mclk0 + - const: ext_aud_mclk1 + - const: esai0_rx_clk + - const: esai0_rx_hf_clk + - const: esai0_tx_clk + - const: esai0_tx_hf_clk + - const: spdif0_rx + - const: sai0_rx_bclk + - const: sai0_tx_bclk + - const: sai1_rx_bclk + - const: sai1_tx_bclk + - const: sai2_rx_bclk + - const: sai3_rx_bclk + - const: sai4_rx_bclk + + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8qm-acm + then: + properties: + power-domains: + items: + - description: power domain of IMX_SC_R_AUDIO_CLK_0 + - description: power domain of IMX_SC_R_AUDIO_CLK_1 + - description: power domain of IMX_SC_R_MCLK_OUT_0 + - description: power domain of IMX_SC_R_MCLK_OUT_1 + - description: power domain of IMX_SC_R_AUDIO_PLL_0 + - description: power domain of IMX_SC_R_AUDIO_PLL_1 + - description: power domain of IMX_SC_R_ASRC_0 + - description: power domain of IMX_SC_R_ASRC_1 + - description: power domain of IMX_SC_R_ESAI_0 + - description: power domain of IMX_SC_R_ESAI_1 + - description: power domain of IMX_SC_R_SAI_0 + - description: power domain of IMX_SC_R_SAI_1 + - description: power domain of IMX_SC_R_SAI_2 + - description: power domain of IMX_SC_R_SAI_3 + - description: power domain of IMX_SC_R_SAI_4 + - description: power domain of IMX_SC_R_SAI_5 + - description: power domain of IMX_SC_R_SAI_6 + - description: power domain of IMX_SC_R_SAI_7 + - description: power domain of IMX_SC_R_SPDIF_0 + - description: power domain of IMX_SC_R_SPDIF_1 + - description: power domain of IMX_SC_R_MQS_0 + + clocks: + minItems: 27 + maxItems: 27 + + clock-names: + items: + - const: aud_rec_clk0_lpcg_clk + - const: aud_rec_clk1_lpcg_clk + - const: aud_pll_div_clk0_lpcg_clk + - const: aud_pll_div_clk1_lpcg_clk + - const: mlb_clk + - const: hdmi_rx_mclk + - const: ext_aud_mclk0 + - const: ext_aud_mclk1 + - const: esai0_rx_clk + - const: esai0_rx_hf_clk + - const: esai0_tx_clk + - const: esai0_tx_hf_clk + - const: esai1_rx_clk + - const: esai1_rx_hf_clk + - const: esai1_tx_clk + - const: esai1_tx_hf_clk + - const: spdif0_rx + - const: spdif1_rx + - const: sai0_rx_bclk + - const: sai0_tx_bclk + - const: sai1_rx_bclk + - const: sai1_tx_bclk + - const: sai2_rx_bclk + - const: sai3_rx_bclk + - const: sai4_rx_bclk + - const: sai5_tx_bclk + - const: sai6_rx_bclk + + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8dxl-acm + then: + properties: + power-domains: + items: + - description: power domain of IMX_SC_R_AUDIO_CLK_0 + - description: power domain of IMX_SC_R_AUDIO_CLK_1 + - description: power domain of IMX_SC_R_MCLK_OUT_0 + - description: power domain of IMX_SC_R_MCLK_OUT_1 + - description: power domain of IMX_SC_R_AUDIO_PLL_0 + - description: power domain of IMX_SC_R_AUDIO_PLL_1 + - description: power domain of IMX_SC_R_ASRC_0 + - description: power domain of IMX_SC_R_SAI_0 + - description: power domain of IMX_SC_R_SAI_1 + - description: power domain of IMX_SC_R_SAI_2 + - description: power domain of IMX_SC_R_SAI_3 + - description: power domain of IMX_SC_R_SPDIF_0 + - description: power domain of IMX_SC_R_MQS_0 + + clocks: + minItems: 13 + maxItems: 13 + + clock-names: + items: + - const: aud_rec_clk0_lpcg_clk + - const: aud_rec_clk1_lpcg_clk + - const: aud_pll_div_clk0_lpcg_clk + - const: aud_pll_div_clk1_lpcg_clk + - const: ext_aud_mclk0 + - const: ext_aud_mclk1 + - const: spdif0_rx + - const: sai0_rx_bclk + - const: sai0_tx_bclk + - const: sai1_rx_bclk + - const: sai1_tx_bclk + - const: sai2_rx_bclk + - const: sai3_rx_bclk + +additionalProperties: false + +examples: + # Clock Control Module node: + - | + #include <dt-bindings/clock/imx8-lpcg.h> + #include <dt-bindings/firmware/imx/rsrc.h> + + clock-controller@59e00000 { + compatible = "fsl,imx8qxp-acm"; + reg = <0x59e00000 0x1d0000>; + #clock-cells = <1>; + power-domains = <&pd IMX_SC_R_AUDIO_CLK_0>, + <&pd IMX_SC_R_AUDIO_CLK_1>, + <&pd IMX_SC_R_MCLK_OUT_0>, + <&pd IMX_SC_R_MCLK_OUT_1>, + <&pd IMX_SC_R_AUDIO_PLL_0>, + <&pd IMX_SC_R_AUDIO_PLL_1>, + <&pd IMX_SC_R_ASRC_0>, + <&pd IMX_SC_R_ASRC_1>, + <&pd IMX_SC_R_ESAI_0>, + <&pd IMX_SC_R_SAI_0>, + <&pd IMX_SC_R_SAI_1>, + <&pd IMX_SC_R_SAI_2>, + <&pd IMX_SC_R_SAI_3>, + <&pd IMX_SC_R_SAI_4>, + <&pd IMX_SC_R_SAI_5>, + <&pd IMX_SC_R_SPDIF_0>, + <&pd IMX_SC_R_MQS_0>; + clocks = <&aud_rec0_lpcg IMX_LPCG_CLK_0>, + <&aud_rec1_lpcg IMX_LPCG_CLK_0>, + <&aud_pll_div0_lpcg IMX_LPCG_CLK_0>, + <&aud_pll_div1_lpcg IMX_LPCG_CLK_0>, + <&clk_ext_aud_mclk0>, + <&clk_ext_aud_mclk1>, + <&clk_esai0_rx_clk>, + <&clk_esai0_rx_hf_clk>, + <&clk_esai0_tx_clk>, + <&clk_esai0_tx_hf_clk>, + <&clk_spdif0_rx>, + <&clk_sai0_rx_bclk>, + <&clk_sai0_tx_bclk>, + <&clk_sai1_rx_bclk>, + <&clk_sai1_tx_bclk>, + <&clk_sai2_rx_bclk>, + <&clk_sai3_rx_bclk>, + <&clk_sai4_rx_bclk>; + clock-names = "aud_rec_clk0_lpcg_clk", + "aud_rec_clk1_lpcg_clk", + "aud_pll_div_clk0_lpcg_clk", + "aud_pll_div_clk1_lpcg_clk", + "ext_aud_mclk0", + "ext_aud_mclk1", + "esai0_rx_clk", + "esai0_rx_hf_clk", + "esai0_tx_clk", + "esai0_tx_hf_clk", + "spdif0_rx", + "sai0_rx_bclk", + "sai0_tx_bclk", + "sai1_rx_bclk", + "sai1_tx_bclk", + "sai2_rx_bclk", + "sai3_rx_bclk", + "sai4_rx_bclk"; + }; diff --git a/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt b/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt deleted file mode 100644 index 4733e58e491b..000000000000 --- a/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt +++ /dev/null @@ -1,30 +0,0 @@ -* Hisilicon Hix5hd2 Clock Controller - -The hix5hd2 clock controller generates and supplies clock to various -controllers within the hix5hd2 SoC. - -Required Properties: - -- compatible: should be "hisilicon,hix5hd2-clock" -- reg: Address and length of the register set -- #clock-cells: Should be <1> - -Each clock is assigned an identifier and client nodes use this identifier -to specify the clock which they consume. - -All these identifier could be found in <dt-bindings/clock/hix5hd2-clock.h>. - -Examples: - clock: clock@f8a22000 { - compatible = "hisilicon,hix5hd2-clock"; - reg = <0xf8a22000 0x1000>; - #clock-cells = <1>; - }; - - uart0: uart@f8b00000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0xf8b00000 0x1000>; - interrupts = <0 49 4>; - clocks = <&clock HIX5HD2_FIXED_83M>; - clock-names = "apb_pclk"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml index 0dbc1433fede..80539f88bc27 100644 --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml @@ -24,6 +24,9 @@ properties: reg: maxItems: 1 + interrupts: + maxItems: 2 + clocks: minItems: 6 maxItems: 7 diff --git a/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml index ff9600474df2..0a6dc1a6e122 100644 --- a/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml +++ b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/clock/imx8mp-audiomix.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: NXP i.MX8MP AudioMIX Block Control Binding +title: NXP i.MX8MP AudioMIX Block Control maintainers: - Marek Vasut <marex@denx.de> diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml index 9e733b10c392..509df06b9c9d 100644 --- a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml +++ b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml @@ -98,9 +98,9 @@ required: patternProperties: "^usb-phy@[a-f0-9]+$": - allOf: [ $ref: "../phy/ingenic,phy-usb.yaml#" ] + $ref: /schemas/phy/ingenic,phy-usb.yaml# "^mac-phy-ctrl@[a-f0-9]+$": - allOf: [ $ref: "../net/ingenic,mac.yaml#" ] + $ref: /schemas/net/ingenic,mac.yaml# additionalProperties: false diff --git a/Documentation/devicetree/bindings/clock/intel,agilex5-clkmgr.yaml b/Documentation/devicetree/bindings/clock/intel,agilex5-clkmgr.yaml new file mode 100644 index 000000000000..d120b0da7f3d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/intel,agilex5-clkmgr.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/intel,agilex5-clkmgr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel SoCFPGA Agilex5 clock manager + +maintainers: + - Dinh Nguyen <dinguyen@kernel.org> + +description: + The Intel Agilex5 Clock Manager is an integrated clock controller, which + generates and supplies clock to all the modules. + +properties: + compatible: + const: intel,agilex5-clkmgr + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clkmgr: clock-controller@10d10000 { + compatible = "intel,agilex5-clkmgr"; + reg = <0x10d10000 0x1000>; + #clock-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/keystone-pll.txt b/Documentation/devicetree/bindings/clock/keystone-pll.txt index 47570d207215..9a3fbc665606 100644 --- a/Documentation/devicetree/bindings/clock/keystone-pll.txt +++ b/Documentation/devicetree/bindings/clock/keystone-pll.txt @@ -14,7 +14,7 @@ Required properties: - #clock-cells : from common clock binding; shall be set to 0. - compatible : shall be "ti,keystone,main-pll-clock" or "ti,keystone,pll-clock" - clocks : parent clock phandle -- reg - pll control0 and pll multipler registers +- reg - pll control0 and pll multiplier registers - reg-names : control, multiplier and post-divider. The multiplier and post-divider registers are applicable only for main pll clock - fixed-postdiv : fixed post divider value. If absent, use clkod register bits diff --git a/Documentation/devicetree/bindings/clock/lpc1850-ccu.txt b/Documentation/devicetree/bindings/clock/lpc1850-ccu.txt index fa97c12014ac..8cf8f0ecdd16 100644 --- a/Documentation/devicetree/bindings/clock/lpc1850-ccu.txt +++ b/Documentation/devicetree/bindings/clock/lpc1850-ccu.txt @@ -68,7 +68,7 @@ soc { "base_ssp0_clk", "base_sdio_clk"; }; - /* A user of CCU brach clocks */ + /* A user of CCU branch clocks */ uart1: serial@40082000 { ... clocks = <&ccu2 CLK_APB0_UART1>, <&ccu1 CLK_CPU_UART1>; diff --git a/Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt b/Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt index 6f1c7b4e4d2c..b6b2547a3d17 100644 --- a/Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt +++ b/Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt @@ -5,8 +5,8 @@ control registers for two low speed clocks. One of the clocks is a 32 kHz oscillator driver with power up/down and clock gating. Next is a fixed divider that creates a 1 kHz clock from the 32 kHz osc. -These clocks are used by the RTC and the Event Router peripherials. -The 32 kHz can also be routed to other peripherials to enable low +These clocks are used by the RTC and the Event Router peripherals. +The 32 kHz can also be routed to other peripherals to enable low power modes. This binding uses the common clock binding: diff --git a/Documentation/devicetree/bindings/clock/maxim,max9485.txt b/Documentation/devicetree/bindings/clock/maxim,max9485.txt index 61bec1100a94..b8f5c3bbf12b 100644 --- a/Documentation/devicetree/bindings/clock/maxim,max9485.txt +++ b/Documentation/devicetree/bindings/clock/maxim,max9485.txt @@ -12,7 +12,7 @@ requests. Required properties: - compatible: "maxim,max9485" -- clocks: Input clock, must provice 27.000 MHz +- clocks: Input clock, must provide 27.000 MHz - clock-names: Must be set to "xclk" - #clock-cells: From common clock binding; shall be set to 1 diff --git a/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml b/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml new file mode 100644 index 000000000000..ba7ffc5b16a0 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/mediatek,mtmips-sysc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MTMIPS SoCs System Controller + +maintainers: + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: | + MediaTek MIPS and Ralink SoCs provides a system controller to allow + to access to system control registers. These registers include clock + and reset related ones so this node is both clock and reset provider + for the rest of the world. + + These SoCs have an XTAL from where the cpu clock is + provided as well as derived clocks for the bus and the peripherals. + +properties: + compatible: + items: + - enum: + - ralink,mt7620-sysc + - ralink,mt7628-sysc + - ralink,mt7688-sysc + - ralink,rt2880-sysc + - ralink,rt3050-sysc + - ralink,rt3052-sysc + - ralink,rt3352-sysc + - ralink,rt3883-sysc + - ralink,rt5350-sysc + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + description: + The first cell indicates the clock number. + const: 1 + + '#reset-cells': + description: + The first cell indicates the reset bit within the register. + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + - | + syscon@0 { + compatible = "ralink,rt5350-sysc", "syscon"; + reg = <0x0 0x100>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/nuvoton,ma35d1-clk.yaml b/Documentation/devicetree/bindings/clock/nuvoton,ma35d1-clk.yaml new file mode 100644 index 000000000000..8f0c43683729 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/nuvoton,ma35d1-clk.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/nuvoton,ma35d1-clk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton MA35D1 Clock Controller Module + +maintainers: + - Chi-Fang Li <cfli0@nuvoton.com> + - Jacky Huang <ychuang3@nuvoton.com> + +description: | + The MA35D1 clock controller generates clocks for the whole chip, + including system clocks and all peripheral clocks. + + See also: + include/dt-bindings/clock/ma35d1-clk.h + +properties: + compatible: + items: + - const: nuvoton,ma35d1-clk + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + clocks: + maxItems: 1 + + nuvoton,pll-mode: + description: + A list of PLL operation mode corresponding to CAPLL, DDRPLL, APLL, + EPLL, and VPLL in sequential. + maxItems: 5 + items: + enum: + - integer + - fractional + - spread-spectrum + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + +required: + - compatible + - reg + - "#clock-cells" + - clocks + +additionalProperties: false + +examples: + - | + + clock-controller@40460200 { + compatible = "nuvoton,ma35d1-clk"; + reg = <0x40460200 0x100>; + #clock-cells = <1>; + clocks = <&clk_hxt>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml index 1b2181f6d440..a9ba21144a56 100644 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml @@ -27,7 +27,9 @@ description: | properties: compatible: - const: nvidia,tegra124-car + enum: + - nvidia,tegra124-car + - nvidia,tegra132-car reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt b/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt deleted file mode 100644 index b652f3fb7796..000000000000 --- a/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt +++ /dev/null @@ -1,28 +0,0 @@ -Oxford Semiconductor OXNAS SoC Family Standard Clocks -================================================ - -Please also refer to clock-bindings.txt in this directory for common clock -bindings usage. - -Required properties: -- compatible: For OX810SE, should be "oxsemi,ox810se-stdclk" - For OX820, should be "oxsemi,ox820-stdclk" -- #clock-cells: 1, see below - -Parent node should have the following properties : -- compatible: For OX810SE, should be - "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd" - For OX820, should be - "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd" - -example: - -sys: sys-ctrl@000000 { - compatible = "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"; - reg = <0x000000 0x100000>; - - stdclk: stdclk { - compatible = "oxsemi,ox810se-stdclk"; - #clock-cells = <1>; - }; -}; diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml index 659669bf224b..9436266828af 100644 --- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml @@ -19,6 +19,7 @@ properties: - qcom,ipq5332-a53pll - qcom,ipq6018-a53pll - qcom,ipq8074-a53pll + - qcom,ipq9574-a73pll - qcom,msm8916-a53pll - qcom,msm8939-a53pll diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml index 8a210c4c5f82..0a3ef7fd03fa 100644 --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml @@ -29,6 +29,7 @@ properties: - description: Link clock from DP PHY - description: VCO DIV clock from DP PHY - description: AHB config clock from GCC + - description: GPLL0 div source from GCC clock-names: items: @@ -39,6 +40,7 @@ properties: - const: dp_phy_pll_link_clk - const: dp_phy_pll_vco_div_clk - const: cfg_ahb_clk + - const: gcc_disp_gpll0_div_clk_src '#clock-cells': const: 1 @@ -46,6 +48,16 @@ properties: '#power-domain-cells': const: 1 + power-domains: + description: + A phandle and PM domain specifier for the CX power domain. + maxItems: 1 + + required-opps: + description: + A phandle to an OPP node describing the power domain's performance point. + maxItems: 1 + reg: maxItems: 1 @@ -63,23 +75,31 @@ examples: - | #include <dt-bindings/clock/qcom,rpmcc.h> #include <dt-bindings/clock/qcom,gcc-sm6125.h> + #include <dt-bindings/power/qcom-rpmpd.h> clock-controller@5f00000 { compatible = "qcom,sm6125-dispcc"; reg = <0x5f00000 0x20000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&dsi0_phy 0>, <&dsi0_phy 1>, <&dsi1_phy 1>, <&dp_phy 0>, <&dp_phy 1>, - <&gcc GCC_DISP_AHB_CLK>; + <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>; clock-names = "bi_tcxo", "dsi0_phy_pll_out_byteclk", "dsi0_phy_pll_out_dsiclk", "dsi1_phy_pll_out_dsiclk", "dp_phy_pll_link_clk", "dp_phy_pll_vco_div_clk", - "cfg_ahb_clk"; + "cfg_ahb_clk", + "gcc_disp_gpll0_div_clk_src"; + + required-opps = <&rpmhpd_opp_ret>; + power-domains = <&rpmpd SM6125_VDDCX>; + #clock-cells = <1>; #power-domain-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml index d6774db257f0..59cc88a52f6b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml @@ -82,7 +82,7 @@ additionalProperties: false examples: - | #include <dt-bindings/clock/qcom,rpmh.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> clock-controller@af00000 { compatible = "qcom,sm8250-dispcc"; reg = <0x0af00000 0x10000>; @@ -103,7 +103,7 @@ examples: #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; - power-domains = <&rpmhpd SM8250_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; required-opps = <&rpmhpd_opp_low_svs>; }; ... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml index 09cd7a786871..19211176ee0b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller on APQ8064/MSM8960 maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml index 6ebaef2288fa..fb3957d485f9 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller on IPQ4019 maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> - Robert Marko <robert.markoo@sartura.hr> description: | diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml index deef398a9872..52e7831a8d6d 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller on IPQ8074 maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml new file mode 100644 index 000000000000..fe9fd4cb185f --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8953.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on MSM8953 + +maintainers: + - Adam Skladowski <a_skl39@protonmail.com> + - Sireesh Kodali <sireeshkodali@protonmail.com> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on MSM8953. + + See also: include/dt-bindings/clock/qcom,gcc-msm8953.h + +properties: + compatible: + const: qcom,gcc-msm8953 + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + - description: Byte clock from DSI PHY0 + - description: Pixel clock from DSI PHY0 + - description: Byte clock from DSI PHY1 + - description: Pixel clock from DSI PHY1 + + clock-names: + items: + - const: xo + - const: sleep + - const: dsi0pll + - const: dsi0pllbyte + - const: dsi1pll + - const: dsi1pllbyte + +required: + - compatible + - clocks + - clock-names + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmcc.h> + + clock-controller@1800000 { + compatible = "qcom,gcc-msm8953"; + reg = <0x01800000 0x80000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&sleep_clk>, + <&dsi0_phy 1>, + <&dsi0_phy 0>, + <&dsi1_phy 1>, + <&dsi1_phy 0>; + clock-names = "xo", + "sleep", + "dsi0pll", + "dsi0pllbyte", + "dsi1pll", + "dsi1pllbyte"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml index d2186e25f55f..62d6f1fe1228 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller on MSM8976 maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml index f77036ace31b..97523cc1ecfb 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller on MSM8996 maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module which provides the clocks, resets and diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml index 3c9729050d6f..58f7fb22c5c4 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller on MSM8998 maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml index ae01e7749534..559fc21435c8 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module provides the clocks, resets and power @@ -19,8 +19,6 @@ description: | include/dt-bindings/reset/qcom,gcc-ipq6018.h include/dt-bindings/clock/qcom,gcc-msm8953.h include/dt-bindings/clock/qcom,gcc-mdm9607.h - include/dt-bindings/clock/qcom,gcc-mdm9615.h - include/dt-bindings/reset/qcom,gcc-mdm9615.h allOf: - $ref: qcom,gcc.yaml# @@ -30,8 +28,6 @@ properties: enum: - qcom,gcc-ipq6018 - qcom,gcc-mdm9607 - - qcom,gcc-msm8953 - - qcom,gcc-mdm9615 required: - compatible diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml index b2256f81b265..7bc6c57e4d11 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller on QCS404 maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml index 06dce0c6b7d0..7aae21a76690 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller on SC7180 maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module provides the clocks, resets and power @@ -32,6 +32,10 @@ properties: - const: bi_tcxo_ao - const: sleep_clk + power-domains: + items: + - description: CX domain + required: - compatible - clocks @@ -45,6 +49,8 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/power/qcom-rpmpd.h> + clock-controller@100000 { compatible = "qcom,gcc-sc7180"; reg = <0x00100000 0x1f0000>; @@ -52,6 +58,7 @@ examples: <&rpmhcc RPMH_CXO_CLK_A>, <&sleep_clk>; clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk"; + power-domains = <&rpmhpd SC7180_CX>; #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml index 947b47168cec..c4ca08d9ad5a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Global Clock & Reset Controller on SC7280 maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module provides the clocks, resets and power @@ -43,6 +43,10 @@ properties: - const: ufs_phy_tx_symbol_0_clk - const: usb3_phy_wrapper_gcc_usb30_pipe_clk + power-domains: + items: + - description: CX domain + required: - compatible - clocks @@ -56,6 +60,8 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/power/qcom-rpmpd.h> + clock-controller@100000 { compatible = "qcom,gcc-sc7280"; reg = <0x00100000 0x1f0000>; @@ -71,6 +77,7 @@ examples: "pcie_1_pipe_clk", "ufs_phy_rx_symbol_0_clk", "ufs_phy_rx_symbol_1_clk", "ufs_phy_tx_symbol_0_clk", "usb3_phy_wrapper_gcc_usb30_pipe_clk"; + power-domains = <&rpmhpd SC7280_CX>; #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml index 68e1b7822fe0..0595da0e8a42 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller on SDM670 and SDM845 maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml index 3ea0ff37a4cb..58ccb7df847c 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller on SM8150 maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml index b752542ee20c..5d77c092be5b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller on SM8250 maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm global clock control module provides the clocks, resets and power @@ -23,11 +23,13 @@ properties: 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: @@ -47,8 +49,9 @@ examples: compatible = "qcom,gcc-sm8250"; reg = <0x00100000 0x1f0000>; clocks = <&rpmhcc RPMH_CXO_CLK>, + <&rpmhcc RPMH_CXO_CLK_A>, <&sleep_clk>; - clock-names = "bi_tcxo", "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,gcc-sm8450.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml index 9a31981fbeb2..75259f468d54 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml @@ -25,7 +25,7 @@ properties: - description: Sleep clock source - description: PCIE 0 Pipe clock source (Optional clock) - description: PCIE 1 Pipe clock source (Optional clock) - - description: PCIE 1 Phy Auxillary clock source (Optional clock) + - description: PCIE 1 Phy Auxiliary clock source (Optional clock) - description: UFS Phy Rx symbol 0 clock source (Optional clock) - description: UFS Phy Rx symbol 1 clock source (Optional clock) - description: UFS Phy Tx symbol 0 clock source (Optional clock) diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index 7129fbcf2b6c..788825105f24 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -8,7 +8,7 @@ title: Qualcomm Global Clock & Reset Controller Common Properties maintainers: - Stephen Boyd <sboyd@kernel.org> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Common bindings for Qualcomm global clock control module providing the diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml index 1e3dc9deded9..f369fa34e00c 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Graphics Clock & Reset Controller maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm graphics clock control module provides the clocks, resets and power @@ -50,6 +50,9 @@ properties: - const: gcc_gpu_gpll0_clk_src - const: gcc_gpu_gpll0_div_clk_src + power-domains: + maxItems: 1 + '#clock-cells': const: 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml new file mode 100644 index 000000000000..ef84a0c95f7e --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,ipq5018-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on IPQ5018 + +maintainers: + - Sricharan Ramabadhran <quic_srichara@quicinc.com> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on IPQ5018 + + See also:: + include/dt-bindings/clock/qcom,ipq5018-gcc.h + include/dt-bindings/reset/qcom,ipq5018-gcc.h + +properties: + compatible: + const: qcom,gcc-ipq5018 + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + - description: PCIE20 PHY0 pipe clock source + - description: PCIE20 PHY1 pipe clock source + - description: USB3 PHY pipe clock source + - description: GEPHY RX clock source + - description: GEPHY TX clock source + - description: UNIPHY RX clock source + - description: UNIPHY TX clk source + +required: + - compatible + - clocks + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + clock-controller@1800000 { + compatible = "qcom,gcc-ipq5018"; + reg = <0x01800000 0x80000>; + clocks = <&xo_board_clk>, + <&sleep_clk>, + <&pcie20_phy0_pipe_clk>, + <&pcie20_phy1_pipe_clk>, + <&usb3_phy0_pipe_clk>, + <&gephy_rx_clk>, + <&gephy_tx_clk>, + <&uniphy_rx_clk>, + <&uniphy_tx_clk>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml index afc68eb9d7cc..944a0ea79cd6 100644 --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml @@ -7,6 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Global Clock & Reset Controller on IPQ9574 maintainers: + - Bjorn Andersson <andersson@kernel.org> - Anusha Rao <quic_anusha@quicinc.com> description: | diff --git a/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml b/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml index a466e4e8aacd..57632757d4e6 100644 --- a/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml @@ -14,7 +14,7 @@ description: There is one ACC register region per CPU within the KPSS remapped region as well as an alias register region that remaps accesses to the ACC associated with the CPU accessing the region. ACC v1 is currently used as a - clock-controller for enabling the cpu and hanling the aux clocks. + clock-controller for enabling the cpu and handling the aux clocks. properties: compatible: diff --git a/Documentation/devicetree/bindings/clock/qcom,lcc.yaml b/Documentation/devicetree/bindings/clock/qcom,lcc.yaml index 8c783823e93c..55985e562a34 100644 --- a/Documentation/devicetree/bindings/clock/qcom,lcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,lcc.yaml @@ -76,6 +76,40 @@ allOf: - clocks - clock-names + - if: + properties: + compatible: + contains: + enum: + - qcom,lcc-mdm9615 + then: + properties: + clocks: + items: + - description: Board CXO source + - description: PLL 4 Vote clock + - description: MI2S codec clock + - description: Mic I2S codec clock + - description: Mic I2S spare clock + - description: Speaker I2S codec clock + - description: Speaker I2S spare clock + - description: PCM codec clock + + clock-names: + items: + - const: cxo + - const: pll4_vote + - const: mi2s_codec_clk + - const: codec_i2s_mic_codec_clk + - const: spare_i2s_mic_codec_clk + - const: codec_i2s_spkr_codec_clk + - const: spare_i2s_spkr_codec_clk + - const: pcm_codec_clk + + required: + - clocks + - clock-names + examples: - | clock-controller@28000000 { diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml index acf0c923c24f..aa35a40648ba 100644 --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml @@ -8,7 +8,7 @@ title: Qualcomm Multimedia Clock & Reset Controller maintainers: - Jeffrey Hugo <quic_jhugo@quicinc.com> - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm multimedia clock control module provides the clocks, resets and @@ -31,11 +31,11 @@ properties: - qcom,mmcc-sdm660 clocks: - minItems: 8 + minItems: 7 maxItems: 13 clock-names: - minItems: 8 + minItems: 7 maxItems: 13 '#clock-cells': @@ -104,6 +104,34 @@ allOf: compatible: contains: enum: + - qcom,mmcc-msm8226 + then: + properties: + clocks: + items: + - description: Board XO source + - description: MMSS GPLL0 voted clock + - description: GPLL0 voted clock + - description: GPLL1 voted clock + - description: GFX3D clock source + - description: DSI phy instance 0 dsi clock + - description: DSI phy instance 0 byte clock + + clock-names: + items: + - const: xo + - const: mmss_gpll0_vote + - const: gpll0_vote + - const: gpll1_vote + - const: gfx3d_clk_src + - const: dsi0pll + - const: dsi0pllbyte + + - if: + properties: + compatible: + contains: + enum: - qcom,mmcc-msm8974 then: properties: @@ -269,6 +297,7 @@ allOf: - description: HDMI phy PLL clock - description: DisplayPort phy PLL link clock - description: DisplayPort phy PLL vco clock + - description: Global PLL 0 DIV clock clock-names: items: @@ -281,6 +310,7 @@ allOf: - const: hdmipll - const: dplink - const: dpvco + - const: gpll0_div - if: properties: diff --git a/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml b/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml index 3ffe69d8cdd5..0dfbd8c4d465 100644 --- a/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml @@ -15,7 +15,9 @@ description: > properties: compatible: - const: qcom,msm8996-cbf + enum: + - qcom,msm8996-cbf + - qcom,msm8996pro-cbf reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml index 2d8897991663..7b271ae210a3 100644 --- a/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Graphics Clock & Reset Controller on MSM8998 maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm graphics clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml index 767a9d03aa32..d712b1a87e25 100644 --- a/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml @@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Global Clock & Reset Controller for QDU1000 and QRU1000 maintainers: - - Melody Olvera <quic_molvera@quicinc.com> + - Taniya Das <quic_tdas@quicinc.com> + - Imran Shaik <quic_imrashai@quicinc.com> description: | Qualcomm global clock control module which supports the clocks, resets and diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml index d5a250b7c2af..fd14d18309a8 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies, Inc. RPMh Clocks maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Resource Power Manager Hardened (RPMh) manages shared resources on @@ -27,6 +27,7 @@ properties: - qcom,sdm845-rpmh-clk - qcom,sdx55-rpmh-clk - qcom,sdx65-rpmh-clk + - qcom,sdx75-rpmh-clk - qcom,sm6350-rpmh-clk - qcom,sm8150-rpmh-clk - qcom,sm8250-rpmh-clk diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml index 098c8acf4bad..2dfc2a4f1918 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Camera Clock & Reset Controller on SC7180 maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm camera clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml index 95ad16d0abc3..1c9ce300a435 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Display Clock & Reset Controller on SC7180 maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm display clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml index f297694ef8b8..fdfb389083c1 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm LPASS Core Clock Controller on SC7180 maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm LPASS core clock control module provides the clocks and power diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml index 1e856a8a996e..873a2f918bac 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Modem Clock Controller on SC7180 maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm modem clock control module provides the clocks on SC7180. diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml index b60adbad4590..01feef1cab0a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Camera Clock & Reset Controller on SC7280 maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm camera clock control module provides the clocks, resets and diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml index cfe6594a0a6b..c42b0ef61385 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Display Clock & Reset Controller on SC7280 maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm display clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml index 97c6bd96e0cb..f44c5c130d2d 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm LPASS Core Clock Controller on SC7280 maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm LPASS core clock control module provides the clocks and power diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml index 447cdc447a0c..deee5423d66e 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm LPASS Core & Audio Clock Controller on SC7280 maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm LPASS core and audio clock control module provides the clocks and diff --git a/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml new file mode 100644 index 000000000000..3326dcd6766c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sc8280xp-lpasscc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm LPASS Core & Audio Clock Controller on SC8280XP + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + Qualcomm LPASS core and audio clock control module provides the clocks, + and reset on SC8280XP. + + See also:: + include/dt-bindings/clock/qcom,lpasscc-sc8280xp.h + +properties: + compatible: + enum: + - qcom,sc8280xp-lpassaudiocc + - qcom,sc8280xp-lpasscc + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sc8280xp-lpasscc.h> + lpass_audiocc: clock-controller@32a9000 { + compatible = "qcom,sc8280xp-lpassaudiocc"; + reg = <0x032a9000 0x1000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + + - | + #include <dt-bindings/clock/qcom,sc8280xp-lpasscc.h> + lpasscc: clock-controller@33e0000 { + compatible = "qcom,sc8280xp-lpasscc"; + reg = <0x033e0000 0x12000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml index 76b53ce64e40..719844d7ea11 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Display Clock & Reset Controller on SDM845 maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm display clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,sdx75-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdx75-gcc.yaml new file mode 100644 index 000000000000..98921fa236b1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sdx75-gcc.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sdx75-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on SDX75 + +maintainers: + - Imran Shaik <quic_imrashai@quicinc.com> + - Taniya Das <quic_tdas@quicinc.com> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on SDX75 + + See also:: include/dt-bindings/clock/qcom,sdx75-gcc.h + +properties: + compatible: + const: qcom,sdx75-gcc + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + - description: EMAC0 sgmiiphy mac rclk source + - description: EMAC0 sgmiiphy mac tclk source + - description: EMAC0 sgmiiphy rclk source + - description: EMAC0 sgmiiphy tclk source + - description: EMAC1 sgmiiphy mac rclk source + - description: EMAC1 sgmiiphy mac tclk source + - description: EMAC1 sgmiiphy rclk source + - description: EMAC1 sgmiiphy tclk source + - description: PCIE20 phy aux clock source + - description: PCIE_1 Pipe clock source + - description: PCIE_2 Pipe clock source + - description: PCIE Pipe clock source + - description: USB3 phy wrapper pipe clock source + +required: + - compatible + - clocks + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@80000 { + compatible = "qcom,sdx75-gcc"; + reg = <0x80000 0x1f7400>; + clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>, <&emac0_sgmiiphy_mac_rclk>, + <&emac0_sgmiiphy_mac_tclk>, <&emac0_sgmiiphy_rclk>, <&emac0_sgmiiphy_tclk>, + <&emac1_sgmiiphy_mac_rclk>, <&emac1_sgmiiphy_mac_tclk>, <&emac1_sgmiiphy_rclk>, + <&emac1_sgmiiphy_tclk>, <&pcie20_phy_aux_clk>, <&pcie_1_pipe_clk>, + <&pcie_2_pipe_clk>, <&pcie_pipe_clk>, <&usb3_phy_wrapper_gcc_usb30_pipe_clk>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml index b480ead5bd69..cf4cad76f6c9 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml @@ -27,9 +27,21 @@ properties: - description: GPLL0 div branch source - description: SNoC DVM GFX source + power-domains: + description: + A phandle and PM domain specifier for the VDD_GX power rail + maxItems: 1 + + required-opps: + description: + A phandle to an OPP node describing required VDD_GX performance point. + maxItems: 1 + required: - compatible - clocks + - power-domains + - required-opps allOf: - $ref: qcom,gcc.yaml# @@ -40,6 +52,7 @@ examples: - | #include <dt-bindings/clock/qcom,sm6375-gcc.h> #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/power/qcom-rpmpd.h> soc { #address-cells = <2>; @@ -52,6 +65,8 @@ examples: <&gcc GCC_GPU_GPLL0_CLK_SRC>, <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>, <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>; + power-domains = <&rpmpd SM6375_VDDGX>; + required-opps = <&rpmpd_opp_low_svs>; #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml new file mode 100644 index 000000000000..46d1d91e3a01 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sm8350-videocc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM8350 Video Clock & Reset Controller + +maintainers: + - Konrad Dybcio <konrad.dybcio@linaro.org> + +description: | + Qualcomm video clock control module provides the clocks, resets and power + domains on Qualcomm SoCs. + + See also:: + include/dt-bindings/clock/qcom,videocc-sm8350.h + include/dt-bindings/reset/qcom,videocc-sm8350.h + +properties: + compatible: + enum: + - qcom,sc8280xp-videocc + - qcom,sm8350-videocc + + clocks: + items: + - description: Board XO source + - description: Board active XO source + - description: Board sleep clock + + power-domains: + description: + A phandle and PM domain specifier for the MMCX power domain. + maxItems: 1 + + required-opps: + description: + A phandle to an OPP node describing required MMCX performance point. + maxItems: 1 + +required: + - compatible + - clocks + - power-domains + - required-opps + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/power/qcom,rpmhpd.h> + + clock-controller@abf0000 { + compatible = "qcom,sm8350-videocc"; + reg = <0x0abf0000 0x10000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&rpmhcc RPMH_CXO_CLK_A>, + <&sleep_clk>; + power-domains = <&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,sm8450-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml index 87ae74166807..8178c35bc348 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml @@ -64,7 +64,7 @@ examples: - | #include <dt-bindings/clock/qcom,gcc-sm8450.h> #include <dt-bindings/clock/qcom,rpmh.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> clock-controller@ade0000 { compatible = "qcom,sm8450-camcc"; reg = <0xade0000 0x20000>; @@ -72,7 +72,7 @@ examples: <&rpmhcc RPMH_CXO_CLK>, <&rpmhcc RPMH_CXO_CLK_A>, <&sleep_clk>; - power-domains = <&rpmhpd SM8450_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; required-opps = <&rpmhpd_opp_low_svs>; #clock-cells = <1>; #reset-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml index 1dd1f696dcd3..2f22310b08a9 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml @@ -76,7 +76,7 @@ examples: - | #include <dt-bindings/clock/qcom,gcc-sm8450.h> #include <dt-bindings/clock/qcom,rpmh.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> clock-controller@af00000 { compatible = "qcom,sm8450-dispcc"; reg = <0x0af00000 0x10000>; @@ -91,7 +91,7 @@ examples: #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; - power-domains = <&rpmhpd SM8450_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; required-opps = <&rpmhpd_opp_low_svs>; }; ... diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml new file mode 100644 index 000000000000..2320be920a5f --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sm8450-gpucc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Graphics Clock & Reset Controller on SM8450 + +maintainers: + - Konrad Dybcio <konrad.dybcio@linaro.org> + +description: | + Qualcomm graphics clock control module provides the clocks, resets and power + domains on Qualcomm SoCs. + + See also:: + include/dt-bindings/clock/qcom,sm8450-gpucc.h + include/dt-bindings/clock/qcom,sm8550-gpucc.h + include/dt-bindings/reset/qcom,sm8450-gpucc.h + +properties: + compatible: + enum: + - qcom,sm8450-gpucc + - qcom,sm8550-gpucc + + clocks: + items: + - description: Board XO source + - description: GPLL0 main branch source + - description: GPLL0 div branch source + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sm8450.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + clock-controller@3d90000 { + compatible = "qcom,sm8450-gpucc"; + reg = <0 0x03d90000 0 0xa000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_GPU_GPLL0_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml new file mode 100644 index 000000000000..bad8f019a8d3 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sm8450-videocc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Video Clock & Reset Controller on SM8450 + +maintainers: + - Taniya Das <quic_tdas@quicinc.com> + +description: | + Qualcomm video clock control module provides the clocks, resets and power + domains on SM8450. + + See also:: include/dt-bindings/clock/qcom,videocc-sm8450.h + +properties: + compatible: + enum: + - qcom,sm8450-videocc + - qcom,sm8550-videocc + + reg: + maxItems: 1 + + clocks: + items: + - description: Board XO source + - description: Video AHB clock from GCC + + power-domains: + maxItems: 1 + description: + MMCX power domain. + + required-opps: + maxItems: 1 + description: + A phandle to an OPP node describing required MMCX performance point. + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + +required: + - compatible + - reg + - clocks + - power-domains + - required-opps + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sm8450.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/power/qcom,rpmhpd.h> + videocc: clock-controller@aaf0000 { + compatible = "qcom,sm8450-videocc"; + reg = <0x0aaf0000 0x10000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_VIDEO_AHB_CLK>; + power-domains = <&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,sm8550-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml index ab25f7cbaa2e..c129f8c16b50 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml @@ -76,7 +76,7 @@ examples: - | #include <dt-bindings/clock/qcom,sm8550-gcc.h> #include <dt-bindings/clock/qcom,rpmh.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> clock-controller@af00000 { compatible = "qcom,sm8550-dispcc"; reg = <0x0af00000 0x10000>; @@ -99,7 +99,7 @@ examples: #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; - power-domains = <&rpmhpd SM8550_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; required-opps = <&rpmhpd_opp_low_svs>; }; ... diff --git a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml index 2b07146161b4..6999e36ace1b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Video Clock & Reset Controller maintainers: - - Taniya Das <tdas@codeaurora.org> + - Taniya Das <quic_tdas@quicinc.com> description: | Qualcomm video clock control module provides the clocks, resets and power @@ -124,7 +124,7 @@ additionalProperties: false examples: - | #include <dt-bindings/clock/qcom,rpmh.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> clock-controller@ab00000 { compatible = "qcom,sdm845-videocc"; reg = <0x0ab00000 0x10000>; @@ -133,7 +133,7 @@ examples: #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; - power-domains = <&rpmhpd SM8250_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; required-opps = <&rpmhpd_opp_low_svs>; }; ... diff --git a/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml b/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml new file mode 100644 index 000000000000..839648e753d4 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/renesas,5p35023.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas 5p35023 VersaClock 3 programmable I2C clock generator + +maintainers: + - Biju Das <biju.das.jz@bp.renesas.com> + +description: | + The 5P35023 is a VersaClock programmable clock generator and + is designed for low-power, consumer, and high-performance PCI + express applications. The 5P35023 device is a three PLL + architecture design, and each PLL is individually programmable + and allowing for up to 6 unique frequency outputs. + + An internal OTP memory allows the user to store the configuration + in the device. After power up, the user can change the device register + settings through the I2C interface when I2C mode is selected. + + The driver can read a full register map from the DT, and will use that + register map to initialize the attached part (via I2C) when the system + boots. Any configuration not supported by the common clock framework + must be done via the full register map, including optimized settings. + + Link to datasheet: + https://www.renesas.com/us/en/products/clocks-timing/clock-generation/programmable-clocks/5p35023-versaclock-3s-programmable-clock-generator + +properties: + compatible: + enum: + - renesas,5p35023 + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + clocks: + maxItems: 1 + + renesas,settings: + description: Optional, complete register map of the device. + Optimized settings for the device must be provided in full + and are written during initialization. + $ref: /schemas/types.yaml#/definitions/uint8-array + maxItems: 37 + +required: + - compatible + - reg + - '#clock-cells' + - clocks + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + versa3: clock-generator@68 { + compatible = "renesas,5p35023"; + reg = <0x68>; + #clock-cells = <1>; + + clocks = <&x1_x2>; + + renesas,settings = [ + 80 00 11 19 4c 02 23 7f 83 19 08 a9 5f 25 24 bf + 00 14 7a e1 00 00 00 00 01 55 59 bb 3f 30 90 b6 + 80 b0 45 c4 95 + ]; + + assigned-clocks = <&versa3 0>, <&versa3 1>, + <&versa3 2>, <&versa3 3>, + <&versa3 4>, <&versa3 5>; + assigned-clock-rates = <12288000>, <25000000>, + <12000000>, <11289600>, + <11289600>, <24000000>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml index 99686085f751..26d94cedc871 100644 --- a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml @@ -48,7 +48,7 @@ properties: patternProperties: "^dma-router@[a-f0-9]+$": type: object - $ref: "../dma/renesas,rzn1-dmamux.yaml#" + $ref: /schemas/dma/renesas,rzn1-dmamux.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml index 0589a63e273a..a36781a455b6 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml @@ -24,6 +24,7 @@ properties: - samsung,exynos3250-cmu-dmc - samsung,exynos3250-cmu-isp - samsung,exynos4210-clock + - samsung,exynos4212-clock - samsung,exynos4412-clock - samsung,exynos5250-clock - items: diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml index 1703e305e6d8..a0658056c330 100644 --- a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml +++ b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml @@ -66,7 +66,7 @@ then: else: description: | Other SC9863a clock nodes should be the child of a syscon node in - which compatible string shoule be: + which compatible string should be: "sprd,sc9863a-glbregs", "syscon", "simple-mfd" The 'reg' property for the clock node is also required if there is a sub diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-ispcrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-ispcrg.yaml new file mode 100644 index 000000000000..3b8b85be5cd0 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-ispcrg.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/starfive,jh7110-ispcrg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 Image-Signal-Process Clock and Reset Generator + +maintainers: + - Xingyu Wu <xingyu.wu@starfivetech.com> + +properties: + compatible: + const: starfive,jh7110-ispcrg + + reg: + maxItems: 1 + + clocks: + items: + - description: ISP Top core + - description: ISP Top Axi + - description: NOC ISP Bus + - description: external DVP + + clock-names: + items: + - const: isp_top_core + - const: isp_top_axi + - const: noc_bus_isp_axi + - const: dvp_clk + + resets: + items: + - description: ISP Top core + - description: ISP Top Axi + - description: NOC ISP Bus + + '#clock-cells': + const: 1 + description: + See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices. + + '#reset-cells': + const: 1 + description: + See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices. + + power-domains: + maxItems: 1 + description: + ISP domain power + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - '#clock-cells' + - '#reset-cells' + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/starfive,jh7110-crg.h> + #include <dt-bindings/power/starfive,jh7110-pmu.h> + #include <dt-bindings/reset/starfive,jh7110-crg.h> + + ispcrg: clock-controller@19810000 { + compatible = "starfive,jh7110-ispcrg"; + reg = <0x19810000 0x10000>; + clocks = <&syscrg JH7110_SYSCLK_ISP_TOP_CORE>, + <&syscrg JH7110_SYSCLK_ISP_TOP_AXI>, + <&syscrg JH7110_SYSCLK_NOC_BUS_ISP_AXI>, + <&dvp_clk>; + clock-names = "isp_top_core", "isp_top_axi", + "noc_bus_isp_axi", "dvp_clk"; + resets = <&syscrg JH7110_SYSRST_ISP_TOP>, + <&syscrg JH7110_SYSRST_ISP_TOP_AXI>, + <&syscrg JH7110_SYSRST_NOC_BUS_ISP_AXI>; + #clock-cells = <1>; + #reset-cells = <1>; + power-domains = <&pwrc JH7110_PD_ISP>; + }; diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-pll.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-pll.yaml new file mode 100644 index 000000000000..be8300ce86d0 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-pll.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/starfive,jh7110-pll.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 PLL Clock Generator + +description: + These PLLs are high speed, low jitter frequency synthesizers in the JH7110. + Each PLL works in integer mode or fraction mode, with configuration + registers in the sys syscon. So the PLLs node should be a child of + SYS-SYSCON node. + The formula for calculating frequency is + Fvco = Fref * (NI + NF) / M / Q1 + +maintainers: + - Xingyu Wu <xingyu.wu@starfivetech.com> + +properties: + compatible: + const: starfive,jh7110-pll + + clocks: + maxItems: 1 + description: Main Oscillator (24 MHz) + + '#clock-cells': + const: 1 + description: + See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices. + +required: + - compatible + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller { + compatible = "starfive,jh7110-pll"; + clocks = <&osc>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-stgcrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-stgcrg.yaml new file mode 100644 index 000000000000..b64ccd84200a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-stgcrg.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/starfive,jh7110-stgcrg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 System-Top-Group Clock and Reset Generator + +maintainers: + - Xingyu Wu <xingyu.wu@starfivetech.com> + +properties: + compatible: + const: starfive,jh7110-stgcrg + + reg: + maxItems: 1 + + clocks: + items: + - description: Main Oscillator (24 MHz) + - description: HIFI4 core + - description: STG AXI/AHB + - description: USB (125 MHz) + - description: CPU Bus + - description: HIFI4 Axi + - description: NOC STG Bus + - description: APB Bus + + clock-names: + items: + - const: osc + - const: hifi4_core + - const: stg_axiahb + - const: usb_125m + - const: cpu_bus + - const: hifi4_axi + - const: nocstg_bus + - const: apb_bus + + '#clock-cells': + const: 1 + description: + See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices. + + '#reset-cells': + const: 1 + description: + See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices. + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/starfive,jh7110-crg.h> + + stgcrg: clock-controller@10230000 { + compatible = "starfive,jh7110-stgcrg"; + reg = <0x10230000 0x10000>; + clocks = <&osc>, + <&syscrg JH7110_SYSCLK_HIFI4_CORE>, + <&syscrg JH7110_SYSCLK_STG_AXIAHB>, + <&syscrg JH7110_SYSCLK_USB_125M>, + <&syscrg JH7110_SYSCLK_CPU_BUS>, + <&syscrg JH7110_SYSCLK_HIFI4_AXI>, + <&syscrg JH7110_SYSCLK_NOCSTG_BUS>, + <&syscrg JH7110_SYSCLK_APB_BUS>; + clock-names = "osc", "hifi4_core", + "stg_axiahb", "usb_125m", + "cpu_bus", "hifi4_axi", + "nocstg_bus", "apb_bus"; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml index 84373ae31644..5ba0a885aa80 100644 --- a/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml +++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml @@ -27,6 +27,9 @@ properties: - description: External I2S RX left/right channel clock - description: External TDM clock - description: External audio master clock + - description: PLL0 + - description: PLL1 + - description: PLL2 - items: - description: Main Oscillator (24 MHz) @@ -38,6 +41,9 @@ properties: - description: External I2S RX left/right channel clock - description: External TDM clock - description: External audio master clock + - description: PLL0 + - description: PLL1 + - description: PLL2 clock-names: oneOf: @@ -52,6 +58,9 @@ properties: - const: i2srx_lrck_ext - const: tdm_ext - const: mclk_ext + - const: pll0_out + - const: pll1_out + - const: pll2_out - items: - const: osc @@ -63,6 +72,9 @@ properties: - const: i2srx_lrck_ext - const: tdm_ext - const: mclk_ext + - const: pll0_out + - const: pll1_out + - const: pll2_out '#clock-cells': const: 1 @@ -93,12 +105,14 @@ examples: <&gmac1_rgmii_rxin>, <&i2stx_bclk_ext>, <&i2stx_lrck_ext>, <&i2srx_bclk_ext>, <&i2srx_lrck_ext>, - <&tdm_ext>, <&mclk_ext>; + <&tdm_ext>, <&mclk_ext>, + <&pllclk 0>, <&pllclk 1>, <&pllclk 2>; clock-names = "osc", "gmac1_rmii_refin", "gmac1_rgmii_rxin", "i2stx_bclk_ext", "i2stx_lrck_ext", "i2srx_bclk_ext", "i2srx_lrck_ext", - "tdm_ext", "mclk_ext"; + "tdm_ext", "mclk_ext", + "pll0_out", "pll1_out", "pll2_out"; #clock-cells = <1>; #reset-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-voutcrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-voutcrg.yaml new file mode 100644 index 000000000000..af77bd8c86b1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-voutcrg.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/starfive,jh7110-voutcrg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 Video-Output Clock and Reset Generator + +maintainers: + - Xingyu Wu <xingyu.wu@starfivetech.com> + +properties: + compatible: + const: starfive,jh7110-voutcrg + + reg: + maxItems: 1 + + clocks: + items: + - description: Vout Top core + - description: Vout Top Ahb + - description: Vout Top Axi + - description: Vout Top HDMI MCLK + - description: I2STX0 BCLK + - description: external HDMI pixel + + clock-names: + items: + - const: vout_src + - const: vout_top_ahb + - const: vout_top_axi + - const: vout_top_hdmitx0_mclk + - const: i2stx0_bclk + - const: hdmitx0_pixelclk + + resets: + maxItems: 1 + description: Vout Top core + + '#clock-cells': + const: 1 + description: + See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices. + + '#reset-cells': + const: 1 + description: + See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices. + + power-domains: + maxItems: 1 + description: + Vout domain power + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - '#clock-cells' + - '#reset-cells' + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/starfive,jh7110-crg.h> + #include <dt-bindings/power/starfive,jh7110-pmu.h> + #include <dt-bindings/reset/starfive,jh7110-crg.h> + + voutcrg: clock-controller@295C0000 { + compatible = "starfive,jh7110-voutcrg"; + reg = <0x295C0000 0x10000>; + clocks = <&syscrg JH7110_SYSCLK_VOUT_SRC>, + <&syscrg JH7110_SYSCLK_VOUT_TOP_AHB>, + <&syscrg JH7110_SYSCLK_VOUT_TOP_AXI>, + <&syscrg JH7110_SYSCLK_VOUT_TOP_HDMITX0_MCLK>, + <&syscrg JH7110_SYSCLK_I2STX0_BCLK>, + <&hdmitx0_pixelclk>; + clock-names = "vout_src", "vout_top_ahb", + "vout_top_axi", "vout_top_hdmitx0_mclk", + "i2stx0_bclk", "hdmitx0_pixelclk"; + resets = <&syscrg JH7110_SYSRST_VOUT_TOP_SRC>; + #clock-cells = <1>; + #reset-cells = <1>; + power-domains = <&pwrc JH7110_PD_VOUT>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml b/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml new file mode 100644 index 000000000000..b2e40bd39a3a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/ti,am62-audio-refclk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI Audio Reference Clock + +maintainers: + - Jai Luthra <j-luthra@ti.com> + +properties: + compatible: + items: + - const: ti,am62-audio-refclk + + reg: + maxItems: 1 + + "#clock-cells": + const: 0 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - "#clock-cells" + - clocks + +additionalProperties: false + +examples: + - | + audio_refclk0: clock@82e0 { + compatible = "ti,am62-audio-refclk"; + reg = <0x82e0 0x4>; + clocks = <&k3_clks 157 0>; + assigned-clocks = <&k3_clks 157 0>; + assigned-clock-parents = <&k3_clks 157 8>; + #clock-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml index 66765116aff5..64b8bce5962c 100644 --- a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml +++ b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml @@ -16,7 +16,6 @@ properties: - ti,am654-ehrpwm-tbclk - ti,am64-epwm-tbclk - ti,am62-epwm-tbclk - - const: syscon "#clock-cells": const: 1 @@ -33,8 +32,8 @@ additionalProperties: false examples: - | - ehrpwm_tbclk: syscon@4140 { - compatible = "ti,am654-ehrpwm-tbclk", "syscon"; + ehrpwm_tbclk: clock@4140 { + compatible = "ti,am654-ehrpwm-tbclk"; reg = <0x4140 0x18>; #clock-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/clock/ti,cdce925.yaml b/Documentation/devicetree/bindings/clock/ti,cdce925.yaml index a4ec8dd5ddf1..95c1c6f8b755 100644 --- a/Documentation/devicetree/bindings/clock/ti,cdce925.yaml +++ b/Documentation/devicetree/bindings/clock/ti,cdce925.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/clock/ti,cdce925.yaml# diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml index 63d976341696..0a9d6a4c4b66 100644 --- a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml# diff --git a/Documentation/devicetree/bindings/clock/ti/mux.txt b/Documentation/devicetree/bindings/clock/ti/mux.txt index e17425a58621..b33f641f1043 100644 --- a/Documentation/devicetree/bindings/clock/ti/mux.txt +++ b/Documentation/devicetree/bindings/clock/ti/mux.txt @@ -8,7 +8,7 @@ parents, one of which can be selected as output. This clock does not gate or adjust the parent rate via a divider or multiplier. By default the "clocks" property lists the parents in the same order -as they are programmed into the regster. E.g: +as they are programmed into the register. E.g: clocks = <&foo_clock>, <&bar_clock>, <&baz_clock>; diff --git a/Documentation/devicetree/bindings/clock/vf610-clock.txt b/Documentation/devicetree/bindings/clock/vf610-clock.txt index 63f9f1ac3439..109ffa3a5b66 100644 --- a/Documentation/devicetree/bindings/clock/vf610-clock.txt +++ b/Documentation/devicetree/bindings/clock/vf610-clock.txt @@ -9,7 +9,7 @@ Optional properties: - clocks: list of clock identifiers which are external input clocks to the given clock controller. Please refer the next section to find the input clocks for a given controller. -- clock-names: list of names of clocks which are exteral input clocks to the +- clock-names: list of names of clocks which are external input clocks to the given clock controller. Input clocks for top clock controller: diff --git a/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml index c1f04830a832..02bd556bd91a 100644 --- a/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml +++ b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx clocking wizard maintainers: - - Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> + - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> description: The clocking wizard is a soft ip clocking block of Xilinx versal. It diff --git a/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml index 229af98b1d30..1ba687d433b1 100644 --- a/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml +++ b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml @@ -7,20 +7,23 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx Versal clock controller maintainers: - - Michal Simek <michal.simek@xilinx.com> - - Jolly Shah <jolly.shah@xilinx.com> - - Rajan Vaja <rajan.vaja@xilinx.com> + - Michal Simek <michal.simek@amd.com> description: | The clock controller is a hardware block of Xilinx versal clock tree. It reads required input clock frequencies from the devicetree and acts as clock provider for all clock consumers of PS clocks. -select: false - properties: compatible: - const: xlnx,versal-clk + oneOf: + - enum: + - xlnx,versal-clk + - xlnx,zynqmp-clk + - items: + - enum: + - xlnx,versal-net-clk + - const: xlnx,versal-clk "#clock-cells": const: 1 @@ -28,16 +31,12 @@ properties: clocks: description: List of clock specifiers which are external input clocks to the given clock controller. - items: - - description: reference clock - - description: alternate reference clock - - description: alternate reference clock for programmable logic + minItems: 3 + maxItems: 8 clock-names: - items: - - const: ref - - const: alt_ref - - const: pl_alt_ref + minItems: 3 + maxItems: 8 required: - compatible @@ -47,6 +46,61 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - xlnx,versal-clk + + then: + properties: + clocks: + items: + - description: reference clock + - description: alternate reference clock + - description: alternate reference clock for programmable logic + + clock-names: + items: + - const: ref + - const: alt_ref + - const: pl_alt_ref + + - if: + properties: + compatible: + contains: + enum: + - xlnx,zynqmp-clk + + then: + properties: + clocks: + minItems: 5 + items: + - description: PS reference clock + - description: reference clock for video system + - description: alternative PS reference clock + - description: auxiliary reference clock + - description: transceiver reference clock + - description: (E)MIO clock source (Optional clock) + - description: GEM emio clock (Optional clock) + - description: Watchdog external clock (Optional clock) + + clock-names: + minItems: 5 + items: + - const: pss_ref_clk + - const: video_clk + - const: pss_alt_ref_clk + - const: aux_ref_clk + - const: gt_crx_ref_clk + - pattern: "^mio_clk[00-77]+.*$" + - pattern: "gem[0-3]+_emio_clk.*$" + - pattern: "swdt[0-1]+_ext_clk.*$" + examples: - | firmware { @@ -61,4 +115,13 @@ examples: }; }; }; + + clock-controller { + #clock-cells = <1>; + compatible = "xlnx,zynqmp-clk"; + clocks = <&pss_ref_clk>, <&video_clk>, <&pss_alt_ref_clk>, + <&aux_ref_clk>, <>_crx_ref_clk>; + clock-names = "pss_ref_clk", "video_clk", "pss_alt_ref_clk", + "aux_ref_clk", "gt_crx_ref_clk"; + }; ... diff --git a/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt b/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt deleted file mode 100644 index 391ee1a60bed..000000000000 --- a/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt +++ /dev/null @@ -1,63 +0,0 @@ --------------------------------------------------------------------------- -Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using -Zynq MPSoC firmware interface --------------------------------------------------------------------------- -The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock -tree. It reads required input clock frequencies from the devicetree and acts -as clock provider for all clock consumers of PS clocks. - -See clock_bindings.txt for more information on the generic clock bindings. - -Required properties: - - #clock-cells: Must be 1 - - compatible: Must contain: "xlnx,zynqmp-clk" - - clocks: List of clock specifiers which are external input - clocks to the given clock controller. Please refer - the next section to find the input clocks for a - given controller. - - clock-names: List of clock names which are exteral input clocks - to the given clock controller. Please refer to the - clock bindings for more details. - -Input clocks for zynqmp Ultrascale+ clock controller: - -The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock -inputs. These required clock inputs are: - - pss_ref_clk (PS reference clock) - - video_clk (reference clock for video system ) - - pss_alt_ref_clk (alternative PS reference clock) - - aux_ref_clk - - gt_crx_ref_clk (transceiver reference clock) - -The following strings are optional parameters to the 'clock-names' property in -order to provide an optional (E)MIO clock source: - - swdt0_ext_clk - - swdt1_ext_clk - - gem0_emio_clk - - gem1_emio_clk - - gem2_emio_clk - - gem3_emio_clk - - mio_clk_XX # with XX = 00..77 - - mio_clk_50_or_51 #for the mux clock to gem tsu from 50 or 51 - - -Output clocks are registered based on clock information received -from firmware. Output clocks indexes are mentioned in -include/dt-bindings/clock/xlnx-zynqmp-clk.h. - -------- -Example -------- - -firmware { - zynqmp_firmware: zynqmp-firmware { - compatible = "xlnx,zynqmp-firmware"; - method = "smc"; - zynqmp_clk: clock-controller { - #clock-cells = <1>; - compatible = "xlnx,zynqmp-clk"; - clocks = <&pss_ref_clk>, <&video_clk>, <&pss_alt_ref_clk>, <&aux_ref_clk>, <>_crx_ref_clk>; - clock-names = "pss_ref_clk", "video_clk", "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk"; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index ae515651fc6b..7c8a3e8430d3 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -30,6 +30,9 @@ properties: - const: samsung,usb-connector-11pin - const: usb-b-connector + reg: + maxItems: 1 + label: description: Symbolic name for the connector. @@ -168,6 +171,13 @@ properties: offer the power, Capability Mismatch is set. Required for power sink and power dual role. + port: + $ref: /schemas/graph.yaml#/properties/port + description: OF graph bindings modeling a data bus to the connector, e.g. + there is a single High Speed (HS) port present in this connector. If there + is more than one bus (several port, with 'reg' property), they can be grouped + under 'ports'. + ports: $ref: /schemas/graph.yaml#/properties/ports description: OF graph bindings modeling any data bus to the connector @@ -217,13 +227,13 @@ properties: state as defined in 7.4.2 Sink Electrical Parameters of USB Power Delivery Specification Revision 3.0, Version 1.2. When the property is set, the port requests pSnkStby(2.5W - 5V@500mA) upon entering SNK_DISCOVERY(instead of 3A or the 1.5A, Rp current advertised, during - SNK_DISCOVERY) and the actual currrent limit after reception of PS_Ready for PD link or during + SNK_DISCOVERY) and the actual current limit after reception of PS_Ready for PD link or during SNK_READY for non-pd link. type: boolean dependencies: - sink-vdos-v1: [ 'sink-vdos' ] - sink-vdos: [ 'sink-vdos-v1' ] + sink-vdos-v1: [ sink-vdos ] + sink-vdos: [ sink-vdos-v1 ] required: - compatible @@ -257,7 +267,7 @@ anyOf: - typec-power-opmode - new-source-frs-typec-current -additionalProperties: true +additionalProperties: false examples: # Micro-USB connector with HS lines routed via controller (MUIC). @@ -322,6 +332,19 @@ examples: }; }; + # USB-C connector attached to SoC with a single High-Speed controller + - | + connector { + compatible = "usb-c-connector"; + label = "USB-C"; + + port { + high_speed_ep: endpoint { + remote-endpoint = <&usb_hs_ep>; + }; + }; + }; + # USB-C connector attached to SoC and USB3 typec port controller(hd3ss3220) # with SS 2:1 MUX. HS lines routed to SoC, SS lines routed to the MUX and # the output of MUX is connected to the SoC. diff --git a/Documentation/devicetree/bindings/cpu/idle-states.yaml b/Documentation/devicetree/bindings/cpu/idle-states.yaml index b8cc826c9501..b3a5356f9916 100644 --- a/Documentation/devicetree/bindings/cpu/idle-states.yaml +++ b/Documentation/devicetree/bindings/cpu/idle-states.yaml @@ -259,7 +259,7 @@ description: |+ http://infocenter.arm.com/help/index.jsp [5] ARM Linux Kernel documentation - Booting AArch64 Linux - Documentation/arm64/booting.rst + Documentation/arch/arm64/booting.rst [6] RISC-V Linux Kernel documentation - CPUs bindings Documentation/devicetree/bindings/riscv/cpus.yaml diff --git a/Documentation/devicetree/bindings/cpu/nvidia,tegra186-ccplex-cluster.yaml b/Documentation/devicetree/bindings/cpu/nvidia,tegra186-ccplex-cluster.yaml new file mode 100644 index 000000000000..16a448974561 --- /dev/null +++ b/Documentation/devicetree/bindings/cpu/nvidia,tegra186-ccplex-cluster.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cpu/nvidia,tegra186-ccplex-cluster.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra186 CCPLEX Cluster + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,tegra186-ccplex-cluster + + reg: + maxItems: 1 + + nvidia,bpmp: + description: phandle to the BPMP used to query CPU frequency tables + $ref: /schemas/types.yaml#/definitions/phandle + +additionalProperties: false + +required: + - compatible + - reg + - nvidia,bpmp + +examples: + - | + ccplex@e000000 { + compatible = "nvidia,tegra186-ccplex-cluster"; + reg = <0x0e000000 0x400000>; + nvidia,bpmp = <&bpmp>; + }; diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml index a6b3bb8fdf33..c1d225fcf2d5 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -49,6 +49,7 @@ properties: - description: Frequency domain 0 register region - description: Frequency domain 1 register region - description: Frequency domain 2 register region + - description: Frequency domain 3 register region reg-names: minItems: 1 @@ -56,6 +57,7 @@ properties: - const: freq-domain0 - const: freq-domain1 - const: freq-domain2 + - const: freq-domain3 clocks: items: @@ -69,7 +71,7 @@ properties: interrupts: minItems: 1 - maxItems: 3 + maxItems: 4 interrupt-names: minItems: 1 @@ -77,6 +79,7 @@ properties: - const: dcvsh-irq-0 - const: dcvsh-irq-1 - const: dcvsh-irq-2 + - const: dcvsh-irq-3 '#freq-domain-cells': const: 1 diff --git a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml index 6f5e7904181f..7e1bb992ce90 100644 --- a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml +++ b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml @@ -28,6 +28,7 @@ select: - qcom,apq8064 - qcom,apq8096 - qcom,ipq8064 + - qcom,ipq8074 - qcom,msm8939 - qcom,msm8960 - qcom,msm8974 diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt deleted file mode 100644 index 1758051798fe..000000000000 --- a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt +++ /dev/null @@ -1,132 +0,0 @@ -TI CPUFreq and OPP bindings -================================ - -Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx -families support different OPPs depending on the silicon variant in use. -The ti-cpufreq driver can use revision and an efuse value from the SoC to -provide the OPP framework with supported hardware information. This is -used to determine which OPPs from the operating-points-v2 table get enabled -when it is parsed by the OPP framework. - -Required properties: --------------------- -In 'cpus' nodes: -- operating-points-v2: Phandle to the operating-points-v2 table to use. - -In 'operating-points-v2' table: -- compatible: Should be - - 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx, - omap34xx, omap36xx and am3517 SoCs -- syscon: A phandle pointing to a syscon node representing the control module - register space of the SoC. - -Optional properties: --------------------- -- "vdd-supply", "vbb-supply": to define two regulators for dra7xx -- "cpu0-supply", "vbb-supply": to define two regulators for omap36xx - -For each opp entry in 'operating-points-v2' table: -- opp-supported-hw: Two bitfields indicating: - 1. Which revision of the SoC the OPP is supported by - 2. Which eFuse bits indicate this OPP is available - - A bitwise AND is performed against these values and if any bit - matches, the OPP gets enabled. - -Example: --------- - -/* From arch/arm/boot/dts/am33xx.dtsi */ -cpus { - #address-cells = <1>; - #size-cells = <0>; - cpu@0 { - compatible = "arm,cortex-a8"; - device_type = "cpu"; - reg = <0>; - - operating-points-v2 = <&cpu0_opp_table>; - - clocks = <&dpll_mpu_ck>; - clock-names = "cpu"; - - clock-latency = <300000>; /* From omap-cpufreq driver */ - }; -}; - -/* - * cpu0 has different OPPs depending on SoC revision and some on revisions - * 0x2 and 0x4 have eFuse bits that indicate if they are available or not - */ -cpu0_opp_table: opp-table { - compatible = "operating-points-v2-ti-cpu"; - syscon = <&scm_conf>; - - /* - * The three following nodes are marked with opp-suspend - * because they can not be enabled simultaneously on a - * single SoC. - */ - opp50-300000000 { - opp-hz = /bits/ 64 <300000000>; - opp-microvolt = <950000 931000 969000>; - opp-supported-hw = <0x06 0x0010>; - opp-suspend; - }; - - opp100-275000000 { - opp-hz = /bits/ 64 <275000000>; - opp-microvolt = <1100000 1078000 1122000>; - opp-supported-hw = <0x01 0x00FF>; - opp-suspend; - }; - - opp100-300000000 { - opp-hz = /bits/ 64 <300000000>; - opp-microvolt = <1100000 1078000 1122000>; - opp-supported-hw = <0x06 0x0020>; - opp-suspend; - }; - - opp100-500000000 { - opp-hz = /bits/ 64 <500000000>; - opp-microvolt = <1100000 1078000 1122000>; - opp-supported-hw = <0x01 0xFFFF>; - }; - - opp100-600000000 { - opp-hz = /bits/ 64 <600000000>; - opp-microvolt = <1100000 1078000 1122000>; - opp-supported-hw = <0x06 0x0040>; - }; - - opp120-600000000 { - opp-hz = /bits/ 64 <600000000>; - opp-microvolt = <1200000 1176000 1224000>; - opp-supported-hw = <0x01 0xFFFF>; - }; - - opp120-720000000 { - opp-hz = /bits/ 64 <720000000>; - opp-microvolt = <1200000 1176000 1224000>; - opp-supported-hw = <0x06 0x0080>; - }; - - oppturbo-720000000 { - opp-hz = /bits/ 64 <720000000>; - opp-microvolt = <1260000 1234800 1285200>; - opp-supported-hw = <0x01 0xFFFF>; - }; - - oppturbo-800000000 { - opp-hz = /bits/ 64 <800000000>; - opp-microvolt = <1260000 1234800 1285200>; - opp-supported-hw = <0x06 0x0100>; - }; - - oppnitro-1000000000 { - opp-hz = /bits/ 64 <1000000000>; - opp-microvolt = <1325000 1298500 1351500>; - opp-supported-hw = <0x04 0x0200>; - }; -}; diff --git a/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml b/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml index ecf98a9e72b2..948e11ebe4ee 100644 --- a/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml +++ b/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml @@ -19,8 +19,8 @@ properties: interrupts: items: - - description: "Interrupt for flow 0" - - description: "Interrupt for flow 1" + - description: Interrupt for flow 0 + - description: Interrupt for flow 1 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml index 286dffa0671b..e879bc0be8e2 100644 --- a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml +++ b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml @@ -103,6 +103,12 @@ properties: wakeup-source: true linux,keycode: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 116 + deprecated: true + + linux,keycodes: + maxItems: 1 default: 116 required: diff --git a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml index 99be01539fcd..8dd36c2f76fd 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml +++ b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml @@ -11,9 +11,15 @@ maintainers: properties: compatible: - enum: - - fsl,imx23-dcp - - fsl,imx28-dcp + oneOf: + - enum: + - fsl,imx23-dcp + - fsl,imx28-dcp + - items: + - enum: + - fsl,imx6sl-dcp + - fsl,imx6ull-dcp + - const: fsl,imx28-dcp reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml index e0fe63957888..a4006237aa89 100644 --- a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml +++ b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml @@ -2,8 +2,8 @@ # Copyright 2018 Linaro Ltd. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/crypto/intel,ixp4xx-crypto.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/crypto/intel,ixp4xx-crypto.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel IXP4xx cryptographic engine @@ -21,7 +21,7 @@ properties: const: intel,ixp4xx-crypto intel,npe-handle: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to the NPE this crypto engine diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml index 92e1d76e29ee..7da9aa82d837 100644 --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml @@ -13,6 +13,7 @@ properties: compatible: items: - enum: + - qcom,sm8450-inline-crypto-engine - qcom,sm8550-inline-crypto-engine - const: qcom,inline-crypto-engine diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml index e375bd981300..8e665d910e6e 100644 --- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml @@ -26,10 +26,19 @@ properties: - items: - enum: + - qcom,ipq4019-qce + - qcom,sm8150-qce + - const: qcom,qce + + - items: + - enum: - qcom,ipq6018-qce - qcom,ipq8074-qce + - qcom,ipq9574-qce - qcom,msm8996-qce + - qcom,qcm2290-qce - qcom,sdm845-qce + - qcom,sm6115-qce - const: qcom,ipq4019-qce - const: qcom,qce @@ -46,16 +55,12 @@ properties: maxItems: 1 clocks: - items: - - description: iface clocks register interface. - - description: bus clocks data transfer interface. - - description: core clocks rest of the crypto block. + minItems: 1 + maxItems: 3 clock-names: - items: - - const: iface - - const: bus - - const: core + minItems: 1 + maxItems: 3 iommus: minItems: 1 @@ -89,9 +94,37 @@ allOf: enum: - qcom,crypto-v5.1 - qcom,crypto-v5.4 - - qcom,ipq4019-qce + - qcom,ipq6018-qce + - qcom,ipq8074-qce + - qcom,msm8996-qce + - qcom,sdm845-qce + then: + properties: + clocks: + maxItems: 3 + clock-names: + items: + - const: iface + - const: bus + - const: core + required: + - clocks + - clock-names + - if: + properties: + compatible: + contains: + enum: + - qcom,qcm2290-qce + - qcom,sm6115-qce then: + properties: + clocks: + maxItems: 1 + clock-names: + items: + - const: core required: - clocks - clock-names diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml index b767ec72a999..ac480765cde0 100644 --- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml +++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml @@ -20,6 +20,7 @@ properties: - stericsson,ux500-hash - st,stm32f456-hash - st,stm32f756-hash + - st,stm32mp13-hash reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml b/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml new file mode 100644 index 000000000000..71a2876bd6e4 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/starfive,jh7110-crypto.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive Cryptographic Module + +maintainers: + - Jia Jie Ho <jiajie.ho@starfivetech.com> + - William Qiu <william.qiu@starfivetech.com> + +properties: + compatible: + const: starfive,jh7110-crypto + + reg: + maxItems: 1 + + clocks: + items: + - description: Hardware reference clock + - description: AHB reference clock + + clock-names: + items: + - const: hclk + - const: ahb + + interrupts: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + items: + - description: TX DMA channel + - description: RX DMA channel + + dma-names: + items: + - const: tx + - const: rx + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + crypto: crypto@16000000 { + compatible = "starfive,jh7110-crypto"; + reg = <0x16000000 0x4000>; + clocks = <&clk 15>, <&clk 16>; + clock-names = "hclk", "ahb"; + interrupts = <28>; + resets = <&reset 3>; + dmas = <&dma 1 2>, + <&dma 0 2>; + dma-names = "tx", "rx"; + }; +... diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml index 77ec8bc70bf7..ff10a0838ad6 100644 --- a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml +++ b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/crypto/ti,sa2ul.yaml# @@ -66,10 +66,22 @@ patternProperties: required: - compatible - reg - - power-domains - dmas - dma-names +allOf: + - if: + properties: + compatible: + contains: + const: ti,am62-sa3ul + then: + properties: + power-domains: false + else: + required: + - power-domains + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml b/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml index 9e8fbd02b150..8aead97a585b 100644 --- a/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml +++ b/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml @@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx ZynqMP AES-GCM Hardware Accelerator maintainers: - - Kalyani Akula <kalyani.akula@xilinx.com> - - Michal Simek <michal.simek@xilinx.com> + - Kalyani Akula <kalyani.akula@amd.com> + - Michal Simek <michal.simek@amd.com> description: | The ZynqMP AES-GCM hardened cryptographic accelerator is used to diff --git a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml index e300df4b47f3..d27dcb2fef12 100644 --- a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml +++ b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml @@ -18,7 +18,7 @@ description: | each IP (DMC, CPU, RIGHTBUS, LEFTBUS, CAM interface, LCD, G3D, MFC). The Exynos PPMU driver uses the devfreq-event class to provide event data to various devfreq devices. The devfreq devices would use the event data when - derterming the current state of each IP. + determining the current state of each IP. properties: compatible: diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-g12a-dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-g12a-dw-mipi-dsi.yaml new file mode 100644 index 000000000000..a3428f012005 --- /dev/null +++ b/Documentation/devicetree/bindings/display/amlogic,meson-g12a-dw-mipi-dsi.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020 BayLibre, SAS +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/amlogic,meson-g12a-dw-mipi-dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic specific extensions to the Synopsys Designware MIPI DSI Host Controller + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +description: | + The Amlogic Meson Synopsys Designware Integration is composed of + - A Synopsys DesignWare MIPI DSI Host Controller IP + - A TOP control block controlling the Clocks & Resets of the IP + +allOf: + - $ref: dsi-controller.yaml# + +properties: + compatible: + enum: + - amlogic,meson-g12a-dw-mipi-dsi + + reg: + maxItems: 1 + + clocks: + minItems: 3 + maxItems: 4 + + clock-names: + minItems: 3 + items: + - const: pclk + - const: bit + - const: px + - const: meas + + resets: + maxItems: 1 + + reset-names: + items: + - const: top + + phys: + maxItems: 1 + + phy-names: + items: + - const: dphy + + 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 + - reg + - clocks + - clock-names + - resets + - reset-names + - phys + - phy-names + - ports + +unevaluatedProperties: false + +examples: + - | + dsi@6000 { + compatible = "amlogic,meson-g12a-dw-mipi-dsi"; + reg = <0x6000 0x400>; + resets = <&reset_top>; + reset-names = "top"; + clocks = <&clk_pclk>, <&bit_clk>, <&clk_px>; + clock-names = "pclk", "bit", "px"; + phys = <&mipi_dphy>; + phy-names = "dphy"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + /* VPU VENC Input */ + mipi_dsi_venc_port: port@0 { + reg = <0>; + + mipi_dsi_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + + /* DSI Output */ + mipi_dsi_panel_port: port@1 { + reg = <1>; + + mipi_out_panel: endpoint { + remote-endpoint = <&mipi_in_panel>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml index 0c72120acc4f..cb0a90f02321 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml @@ -96,6 +96,11 @@ properties: description: A port node pointing to the HDMI-TX port node. + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: + A port node pointing to the DPI port node (e.g. DSI or LVDS transceiver). + "#address-cells": const: 1 diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt index 0398aec488ac..923aea25344c 100644 --- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt +++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt @@ -12,7 +12,7 @@ Required properties: Required children nodes: Children nodes are encoding available output ports and their connections - to external devices using the OF graph reprensentation (see ../graph.txt). + to external devices using the OF graph representation (see ../graph.txt). At least one port node is required. Optional properties in grandchild nodes: diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml index c9b06885cc63..62f0521b0924 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml @@ -26,6 +26,7 @@ properties: const: dp force-hpd: + type: boolean description: Indicate driver need force hpd when hpd detect failed, this is used for some eDP screen which don not have a hpd signal. diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml index 6e0e3ba9b49e..07388bf2b90d 100644 --- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml +++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml @@ -17,6 +17,7 @@ description: | properties: compatible: enum: + - fsl,imx6sx-ldb - fsl,imx8mp-ldb - fsl,imx93-ldb @@ -64,7 +65,9 @@ allOf: properties: compatible: contains: - const: fsl,imx93-ldb + enum: + - fsl,imx6sx-ldb + - fsl,imx93-ldb then: properties: ports: diff --git a/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml b/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml index c4bf54397473..21d995f29a1e 100644 --- a/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml +++ b/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml @@ -20,6 +20,7 @@ properties: maxItems: 1 video-ports: + $ref: /schemas/types.yaml#/definitions/uint32 default: 0x230145 maximum: 0xffffff description: diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml index e841659e20cd..4ed7a799ba26 100644 --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -70,7 +70,9 @@ properties: samsung,burst-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 description: - DSIM high speed burst mode frequency. + DSIM high speed burst mode frequency. If absent, + the pixel clock from the attached device or bridge + will be used instead. samsung,esc-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 @@ -80,7 +82,8 @@ properties: samsung,pll-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 description: - DSIM oscillator clock frequency. + DSIM oscillator clock frequency. If absent, the clock frequency + of sclk_mipi will be used instead. phys: maxItems: 1 @@ -100,20 +103,42 @@ properties: specified. port@1: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: DSI output port node to the panel or the next bridge in the chain. + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + uniqueItems: true + items: + enum: [ 1, 2, 3, 4 ] + + lane-polarities: + minItems: 1 + maxItems: 5 + description: + The Samsung MIPI DSI IP requires that all the data lanes have + the same polarity. + + dependencies: + lane-polarities: [data-lanes] + required: - clock-names - clocks - compatible - interrupts - reg - - samsung,burst-clock-frequency - samsung,esc-clock-frequency - - samsung,pll-clock-frequency allOf: - $ref: ../dsi-controller.yaml# diff --git a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml index 0b51c64f141a..8747b95ec20d 100644 --- a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml @@ -11,7 +11,7 @@ maintainers: description: | This document defines device tree properties for the Synopsys DesignWare MIPI - DSI host controller. It doesn't constitue a device tree binding specification + DSI host controller. It doesn't constitute a device tree binding specification by itself but is meant to be referenced by platform-specific device tree bindings. diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml index 81ca3cbc7abe..6c1de0b21722 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml @@ -21,6 +21,9 @@ properties: maxItems: 1 description: virtual channel number of a DSI peripheral + reset-gpios: + maxItems: 1 + vddc-supply: description: Regulator for 1.2V internal core power. diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml index e1494b5007cb..ae894d996d21 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml @@ -4,16 +4,24 @@ $id: http://devicetree.org/schemas/display/bridge/toshiba,tc358767.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Toshiba TC358767 eDP bridge +title: Toshiba TC358767/TC358867/TC9595 DSI/DPI/eDP bridge maintainers: - Andrey Gusakov <andrey.gusakov@cogentembedded.com> -description: The TC358767 is bridge device which converts DSI/DPI to eDP/DP +description: | + The TC358767/TC358867/TC9595 is bridge device which + converts DSI/DPI to eDP/DP . properties: compatible: - const: toshiba,tc358767 + oneOf: + - items: + - enum: + - toshiba,tc358867 + - toshiba,tc9595 + - const: toshiba,tc358767 + - const: toshiba,tc358767 reg: enum: @@ -41,6 +49,9 @@ properties: description: | OF device-tree gpio specification for RSTX pin(active low system reset) + interrupts: + maxItems: 1 + toshiba,hpd-pin: $ref: /schemas/types.yaml#/definitions/uint32 enum: diff --git a/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt b/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt index 0ab5f0663611..84c75f849891 100644 --- a/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt +++ b/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt @@ -1,4 +1,4 @@ -* Currus Logic CLPS711X Framebuffer +* Cirrus Logic CLPS711X Framebuffer Required properties: - compatible: Shall contain "cirrus,ep7209-fb". diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml index 83c0d008265b..3ee8f9225984 100644 --- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml +++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml @@ -36,6 +36,9 @@ properties: description: GPIO signal to enable DDC bus maxItems: 1 + hdmi-pwr-supply: + description: Power supply for the HDMI +5V Power pin + port: $ref: /schemas/graph.yaml#/properties/port description: Connection to controller providing HDMI signals diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index 75b4efd70ba8..fc11ab5fc465 100644 --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml @@ -21,6 +21,7 @@ properties: - fsl,imx28-lcdif - fsl,imx6sx-lcdif - fsl,imx8mp-lcdif + - fsl,imx93-lcdif - items: - enum: - fsl,imx6sl-lcdif @@ -88,7 +89,9 @@ allOf: properties: compatible: contains: - const: fsl,imx8mp-lcdif + enum: + - fsl,imx8mp-lcdif + - fsl,imx93-lcdif then: properties: clocks: @@ -107,6 +110,7 @@ allOf: enum: - fsl,imx6sx-lcdif - fsl,imx8mp-lcdif + - fsl,imx93-lcdif then: properties: clocks: @@ -123,6 +127,7 @@ allOf: - fsl,imx8mm-lcdif - fsl,imx8mn-lcdif - fsl,imx8mp-lcdif + - fsl,imx93-lcdif then: required: - power-domains diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index 92741486c24d..7fd42c8fdc32 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -27,6 +27,7 @@ properties: - items: - enum: - mediatek,mt2712-disp-aal + - mediatek,mt6795-disp-aal - const: mediatek,mt8173-disp-aal - items: - enum: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index d0ea77fc4b06..f21e44092043 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -33,6 +33,7 @@ properties: - const: mediatek,mt2701-disp-color - items: - enum: + - mediatek,mt6795-disp-color - mediatek,mt8183-disp-color - mediatek,mt8186-disp-color - mediatek,mt8188-disp-color diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml index d976380801e3..803c00f26206 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml @@ -17,15 +17,20 @@ description: | properties: compatible: - enum: - - mediatek,mt2701-dpi - - mediatek,mt7623-dpi - - mediatek,mt8173-dpi - - mediatek,mt8183-dpi - - mediatek,mt8186-dpi - - mediatek,mt8188-dp-intf - - mediatek,mt8192-dpi - - mediatek,mt8195-dp-intf + oneOf: + - enum: + - mediatek,mt2701-dpi + - mediatek,mt7623-dpi + - mediatek,mt8173-dpi + - mediatek,mt8183-dpi + - mediatek,mt8186-dpi + - mediatek,mt8188-dp-intf + - mediatek,mt8192-dpi + - mediatek,mt8195-dp-intf + - items: + - enum: + - mediatek,mt6795-dpi + - const: mediatek,mt8183-dpi reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml index 4707b60238b0..12441b937684 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml @@ -22,13 +22,18 @@ allOf: properties: compatible: - enum: - - mediatek,mt2701-dsi - - mediatek,mt7623-dsi - - mediatek,mt8167-dsi - - mediatek,mt8173-dsi - - mediatek,mt8183-dsi - - mediatek,mt8186-dsi + oneOf: + - enum: + - mediatek,mt2701-dsi + - mediatek,mt7623-dsi + - mediatek,mt8167-dsi + - mediatek,mt8173-dsi + - mediatek,mt8183-dsi + - mediatek,mt8186-dsi + - items: + - enum: + - mediatek,mt6795-dsi + - const: mediatek,mt8173-dsi reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index 6c2be9d6840b..c6641acd75d6 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -26,6 +26,10 @@ properties: - mediatek,mt8183-disp-gamma - items: - enum: + - mediatek,mt6795-disp-gamma + - const: mediatek,mt8173-disp-gamma + - items: + - enum: - mediatek,mt8186-disp-gamma - mediatek,mt8188-disp-gamma - mediatek,mt8192-disp-gamma diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index 2f8e2f4dc3b8..eead5cb8636e 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -24,6 +24,9 @@ properties: - enum: - mediatek,mt8173-disp-merge - mediatek,mt8195-disp-merge + - items: + - const: mediatek,mt6795-disp-merge + - const: mediatek,mt8173-disp-merge reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml index 29f9fa8f8219..831c653caffd 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml @@ -24,6 +24,9 @@ properties: - enum: - mediatek,mt2712-disp-od - mediatek,mt8173-disp-od + - items: + - const: mediatek,mt6795-disp-od + - const: mediatek,mt8173-disp-od reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index 92e320d54ba2..3e1069b00b56 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -33,6 +33,10 @@ properties: - const: mediatek,mt2701-disp-ovl - items: - enum: + - mediatek,mt6795-disp-ovl + - const: mediatek,mt8173-disp-ovl + - items: + - enum: - mediatek,mt8188-disp-ovl - mediatek,mt8195-disp-ovl - const: mediatek,mt8183-disp-ovl diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml index 42059efad45d..39dbb5c8bcf8 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml @@ -39,6 +39,10 @@ properties: - const: mediatek,mt2701-disp-rdma - items: - enum: + - mediatek,mt6795-disp-rdma + - const: mediatek,mt8173-disp-rdma + - items: + - enum: - mediatek,mt8186-disp-rdma - mediatek,mt8192-disp-rdma - const: mediatek,mt8183-disp-rdma diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml index 21a4e96ecd93..a8a5c9608598 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml @@ -23,6 +23,9 @@ properties: oneOf: - enum: - mediatek,mt8173-disp-split + - items: + - const: mediatek,mt6795-disp-split + - const: mediatek,mt8173-disp-split reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml index 62fad23a26f5..39e3e2d4a0db 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml @@ -24,6 +24,9 @@ properties: oneOf: - enum: - mediatek,mt8173-disp-ufoe + - items: + - const: mediatek,mt6795-disp-ufoe + - const: mediatek,mt8173-disp-ufoe reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml index 991183165d29..a3a2b71a4523 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml @@ -23,6 +23,9 @@ properties: oneOf: - enum: - mediatek,mt8173-disp-wdma + - items: + - const: mediatek,mt6795-disp-wdma + - const: mediatek,mt8173-disp-wdma reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index f0c2237d5f82..f12558960cd8 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -28,7 +28,9 @@ properties: - qcom,sm8350-dp - items: - enum: + - qcom,sm8250-dp - qcom,sm8450-dp + - qcom,sm8550-dp - const: qcom,sm8350-dp reg: @@ -78,7 +80,8 @@ properties: operating-points-v2: true - opp-table: true + opp-table: + type: object power-domains: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 130e16d025bc..c6dbab65d5f7 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/dsi-controller-main.yaml# @@ -15,6 +15,7 @@ properties: - items: - enum: - qcom,apq8064-dsi-ctrl + - qcom,msm8226-dsi-ctrl - qcom,msm8916-dsi-ctrl - qcom,msm8953-dsi-ctrl - qcom,msm8974-dsi-ctrl @@ -26,6 +27,9 @@ properties: - qcom,sdm660-dsi-ctrl - qcom,sdm845-dsi-ctrl - qcom,sm6115-dsi-ctrl + - qcom,sm6125-dsi-ctrl + - qcom,sm6350-dsi-ctrl + - qcom,sm6375-dsi-ctrl - qcom,sm8150-dsi-ctrl - qcom,sm8250-dsi-ctrl - qcom,sm8350-dsi-ctrl @@ -163,6 +167,10 @@ properties: description: Phandle to vdd regulator device node + refgen-supply: + description: + Phandle to REFGEN regulator device node + vcca-supply: description: Phandle to vdd regulator device node @@ -256,6 +264,7 @@ allOf: compatible: contains: enum: + - qcom,msm8226-dsi-ctrl - qcom,msm8974-dsi-ctrl then: properties: @@ -297,6 +306,8 @@ allOf: contains: enum: - qcom,msm8998-dsi-ctrl + - qcom,sm6125-dsi-ctrl + - qcom,sm6350-dsi-ctrl then: properties: clocks: @@ -364,6 +375,7 @@ allOf: enum: - qcom,sdm845-dsi-ctrl - qcom,sm6115-dsi-ctrl + - qcom,sm6375-dsi-ctrl then: properties: clocks: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml index e6b00d7387ce..69d13867b7cf 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/dsi-phy-10nm.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml index a43e11d3b00d..52bbe132e6da 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/dsi-phy-14nm.yaml# @@ -19,6 +19,7 @@ properties: - qcom,dsi-phy-14nm-2290 - qcom,dsi-phy-14nm-660 - qcom,dsi-phy-14nm-8953 + - qcom,sm6125-dsi-phy-14nm reg: items: @@ -35,6 +36,16 @@ properties: vcca-supply: description: Phandle to vcca regulator device node. + power-domains: + description: + A phandle and PM domain specifier for an optional power domain. + maxItems: 1 + + required-opps: + description: + A phandle to an OPP node describing the power domain's performance point. + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml index 9c1f9140c731..7e6687cb002b 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/dsi-phy-20nm.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml index cf4a338c4661..288d8babb76a 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/dsi-phy-28nm.yaml# @@ -15,10 +15,11 @@ allOf: properties: compatible: enum: + - qcom,dsi-phy-28nm-8226 + - qcom,dsi-phy-28nm-8960 - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-hpm-fam-b - qcom,dsi-phy-28nm-lp - - qcom,dsi-phy-28nm-8960 reg: items: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml index 8e9031bbde73..dd6619555a12 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/dsi-phy-7nm.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml index 0f6f08890e7e..6b57ce41c95f 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/dsi-phy-common.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml index 029d72822d8b..d65926b4f054 100644 --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml @@ -19,16 +19,18 @@ description: | properties: compatible: - items: - - pattern: '^qcom,adreno-gmu-6[0-9][0-9]\.[0-9]$' - - const: qcom,adreno-gmu + oneOf: + - items: + - pattern: '^qcom,adreno-gmu-6[0-9][0-9]\.[0-9]$' + - const: qcom,adreno-gmu + - const: qcom,adreno-gmu-wrapper reg: - minItems: 3 + minItems: 1 maxItems: 4 reg-names: - minItems: 3 + minItems: 1 maxItems: 4 clocks: @@ -44,7 +46,6 @@ properties: - description: GMU HFI interrupt - description: GMU interrupt - interrupt-names: items: - const: hfi @@ -72,14 +73,8 @@ required: - compatible - reg - reg-names - - clocks - - clock-names - - interrupts - - interrupt-names - power-domains - power-domain-names - - iommus - - operating-points-v2 additionalProperties: false @@ -122,6 +117,7 @@ allOf: contains: enum: - qcom,adreno-gmu-635.0 + - qcom,adreno-gmu-660.1 then: properties: reg: @@ -217,6 +213,28 @@ allOf: - const: axi - const: memnoc + - if: + properties: + compatible: + contains: + const: qcom,adreno-gmu-wrapper + then: + properties: + reg: + items: + - description: GMU wrapper register space + reg-names: + items: + - const: gmu + else: + required: + - clocks + - clock-names + - interrupts + - interrupt-names + - iommus + - operating-points-v2 + examples: - | #include <dt-bindings/clock/qcom,gpucc-sdm845.h> @@ -225,7 +243,7 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> gmu: gmu@506a000 { - compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu"; + compatible = "qcom,adreno-gmu-630.2", "qcom,adreno-gmu"; reg = <0x506a000 0x30000>, <0xb280000 0x10000>, @@ -249,3 +267,12 @@ examples: iommus = <&adreno_smmu 5>; operating-points-v2 = <&gmu_opp_table>; }; + + gmu_wrapper: gmu@596a000 { + compatible = "qcom,adreno-gmu-wrapper"; + reg = <0x0596a000 0x30000>; + reg-names = "gmu"; + power-domains = <&gpucc GPU_CX_GDSC>, + <&gpucc GPU_GX_GDSC>; + power-domain-names = "cx", "gx"; + }; diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml index 5dabe7b6794b..56b9b247e8c2 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml @@ -15,6 +15,12 @@ properties: oneOf: - description: | The driver is parsing the compat string for Adreno to + figure out the chip-id. + items: + - pattern: '^qcom,adreno-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]$' + - const: qcom,adreno + - description: | + The driver is parsing the compat string for Adreno to figure out the gpu-id and patch level. items: - pattern: '^qcom,adreno-[3-6][0-9][0-9]\.[0-9]$' @@ -36,10 +42,7 @@ properties: reg-names: minItems: 1 - items: - - const: kgsl_3d0_reg_memory - - const: cx_mem - - const: cx_dbgc + maxItems: 3 interrupts: maxItems: 1 @@ -157,16 +160,62 @@ allOf: required: - clocks - clock-names + - if: properties: compatible: contains: - pattern: '^qcom,adreno-6[0-9][0-9]\.[0-9]$' - - then: # Since Adreno 6xx series clocks should be defined in GMU + enum: + - qcom,adreno-610.0 + - qcom,adreno-619.1 + then: properties: - clocks: false - clock-names: false + clocks: + minItems: 6 + maxItems: 6 + + clock-names: + items: + - const: core + description: GPU Core clock + - const: iface + description: GPU Interface clock + - const: mem_iface + description: GPU Memory Interface clock + - const: alt_mem_iface + description: GPU Alternative Memory Interface clock + - const: gmu + description: CX GMU clock + - const: xo + description: GPUCC clocksource clock + + reg-names: + minItems: 1 + items: + - const: kgsl_3d0_reg_memory + - const: cx_dbgc + + required: + - clocks + - clock-names + else: + if: + properties: + compatible: + contains: + pattern: '^qcom,adreno-6[0-9][0-9]\.[0-9]$' + + then: # Starting with A6xx, the clocks are usually defined in the GMU node + properties: + clocks: false + clock-names: false + + reg-names: + minItems: 1 + items: + - const: kgsl_3d0_reg_memory + - const: cx_mem + - const: cx_dbgc examples: - | diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml index ccd7d6417523..f69196e4cc76 100644 --- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml +++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/mdss-common.yaml# @@ -77,6 +77,12 @@ properties: items: - description: MDSS_CORE reset + memory-region: + maxItems: 1 + description: + Phandle to a node describing a reserved framebuffer memory region. + For example, the splash memory region set up by the bootloader. + required: - reg - reg-names diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml index a763cf8da122..91c774f106ce 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,mdp5.yaml# @@ -22,6 +22,7 @@ properties: - items: - enum: - qcom,apq8084-mdp5 + - qcom,msm8226-mdp5 - qcom,msm8916-mdp5 - qcom,msm8917-mdp5 - qcom,msm8953-mdp5 diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml index b0100105e428..0999ea07f47b 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,mdss.yaml# @@ -11,7 +11,7 @@ maintainers: - Rob Clark <robdclark@gmail.com> description: - This is the bindings documentation for the Mobile Display Subsytem(MDSS) that + This is the bindings documentation for the Mobile Display Subsystem(MDSS) that encapsulates sub-blocks like MDP5, DSI, HDMI, eDP, etc. properties: @@ -125,6 +125,7 @@ patternProperties: - qcom,dsi-phy-14nm-660 - qcom,dsi-phy-14nm-8953 - qcom,dsi-phy-20nm + - qcom,dsi-phy-28nm-8226 - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-lp - qcom,hdmi-phy-8084 diff --git a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml index 8d3cd46260fb..d5a64c8a921f 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,msm8998-dpu.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml index 3c2b6ed98a56..e320ab1de6de 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,msm8998-mdss.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml index 414f4e7ebdf1..be6cd8adb3b6 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,qcm2290-dpu.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml index 2995b84b2cd4..4184b84d4c21 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,qcm2290-mdss.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml index 1fb8321d9ee8..8137618237ce 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sc7180-dpu.yaml# @@ -13,7 +13,11 @@ $ref: /schemas/display/msm/dpu-common.yaml# properties: compatible: - const: qcom,sc7180-dpu + enum: + - qcom,sc7180-dpu + - qcom,sm6125-dpu + - qcom,sm6350-dpu + - qcom,sm6375-dpu reg: items: @@ -26,6 +30,7 @@ properties: - const: vbif clocks: + minItems: 6 items: - description: Display hf axi clock - description: Display ahb clock @@ -33,8 +38,10 @@ properties: - description: Display lut clock - description: Display core clock - description: Display vsync clock + - description: Display core throttle clock clock-names: + minItems: 6 items: - const: bus - const: iface @@ -42,6 +49,7 @@ properties: - const: lut - const: core - const: vsync + - const: throttle required: - compatible @@ -52,6 +60,22 @@ required: unevaluatedProperties: false +allOf: + - if: + properties: + compatible: + enum: + - qcom,sm6375-dpu + - qcom,sm6125-dpu + + then: + properties: + clocks: + minItems: 7 + + clock-names: + minItems: 7 + examples: - | #include <dt-bindings/clock/qcom,dispcc-sc7180.h> diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml index 42ef06edddc4..3b9c103e504a 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sc7180-mdss.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml index 26dc073bd19a..b0fbe86219d1 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sc7280-dpu.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml index 078e1d1a7d2f..43500dad66e7 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sc7280-mdss.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml index f2c8e16cf067..d19e3bec4600 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sc8280xp-dpu.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml index c239544bc37f..db680fb12b6a 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sc8280xp-mdss.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml index 0f7765d832e7..b917064bdf33 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sdm845-dpu.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml index 6ecb00920d7f..d6d7ac1b2ef8 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sdm845-mdss.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml index bf62c2f5325a..510eb6c19364 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm6115-dpu.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml index b9f83088f370..17221b62a642 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm6115-mdss.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml new file mode 100644 index 000000000000..57f0e3647711 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml @@ -0,0 +1,213 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,sm6125-mdss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM6125 Display MDSS + +maintainers: + - Marijn Suijten <marijn.suijten@somainline.org> + +description: + SM6125 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks + like DPU display controller, DSI and DP interfaces etc. + +$ref: /schemas/display/msm/mdss-common.yaml# + +properties: + compatible: + const: qcom,sm6125-mdss + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display AHB clock + - description: Display core clock + + clock-names: + items: + - const: iface + - const: ahb + - const: core + + iommus: + maxItems: 1 + + interconnects: + maxItems: 2 + + interconnect-names: + maxItems: 2 + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + properties: + compatible: + const: qcom,sm6125-dpu + + "^dsi@[0-9a-f]+$": + type: object + properties: + compatible: + items: + - const: qcom,sm6125-dsi-ctrl + - const: qcom,mdss-dsi-ctrl + + "^phy@[0-9a-f]+$": + type: object + properties: + compatible: + const: qcom,sm6125-dsi-phy-14nm + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sm6125.h> + #include <dt-bindings/clock/qcom,gcc-sm6125.h> + #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-subsystem@5e00000 { + compatible = "qcom,sm6125-mdss"; + reg = <0x05e00000 0x1000>; + reg-names = "mdss"; + + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", + "ahb", + "core"; + + power-domains = <&dispcc MDSS_GDSC>; + + iommus = <&apps_smmu 0x400 0x0>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + display-controller@5e01000 { + compatible = "qcom,sm6125-dpu"; + reg = <0x05e01000 0x83208>, + <0x05eb0000 0x2008>; + reg-names = "mdp", "vbif"; + + interrupt-parent = <&mdss>; + interrupts = <0>; + + clocks = <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_ROT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>, + <&gcc GCC_DISP_THROTTLE_CORE_CLK>; + clock-names = "bus", + "iface", + "rot", + "lut", + "core", + "vsync", + "throttle"; + assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + assigned-clock-rates = <19200000>; + + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmpd SM6125_VDDCX>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&mdss_dsi0_in>; + }; + }; + }; + }; + + dsi@5e94000 { + compatible = "qcom,sm6125-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x05e94000 0x400>; + reg-names = "dsi_ctrl"; + + 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>, + <&gcc GCC_DISP_HF_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>; + assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>; + + operating-points-v2 = <&dsi_opp_table>; + power-domains = <&rpmpd SM6125_VDDCX>; + + phys = <&mdss_dsi0_phy>; + phy-names = "dsi"; + + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + mdss_dsi0_in: endpoint { + remote-endpoint = <&dpu_intf1_out>; + }; + }; + + port@1 { + reg = <1>; + mdss_dsi0_out: endpoint { + }; + }; + }; + }; + + phy@5e94400 { + compatible = "qcom,sm6125-dsi-phy-14nm"; + reg = <0x05e94400 0x100>, + <0x05e94500 0x300>, + <0x05e94800 0x188>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmcc RPM_SMD_XO_CLK_SRC>; + clock-names = "iface", + "ref"; + + required-opps = <&rpmpd_opp_nom>; + power-domains = <&rpmpd SM6125_VDDMX>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml new file mode 100644 index 000000000000..db255b1f4c20 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml @@ -0,0 +1,206 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,sm6350-mdss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM6350 Display MDSS + +maintainers: + - Krishna Manikandan <quic_mkrishn@quicinc.com> + +description: + SM6350 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks + like DPU display controller, DSI and DP interfaces etc. + +$ref: /schemas/display/msm/mdss-common.yaml# + +properties: + compatible: + const: qcom,sm6350-mdss + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display AXI clock from gcc + - 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 + properties: + compatible: + const: qcom,sm6350-dpu + + "^dsi@[0-9a-f]+$": + type: object + properties: + compatible: + items: + - const: qcom,sm6350-dsi-ctrl + - const: qcom,mdss-dsi-ctrl + + "^phy@[0-9a-f]+$": + type: object + properties: + compatible: + const: qcom,dsi-phy-10nm + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sm6350.h> + #include <dt-bindings/clock/qcom,gcc-sm6350.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-subsystem@ae00000 { + compatible = "qcom,sm6350-mdss"; + reg = <0x0ae00000 0x1000>; + reg-names = "mdss"; + + power-domains = <&dispcc MDSS_GDSC>; + + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "bus", "core"; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + iommus = <&apps_smmu 0x800 0x2>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,sm6350-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_ROT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", "iface", "rot", "lut", "core", + "vsync"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>, + <&dispcc DISP_CC_MDSS_ROT_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>; + assigned-clock-rates = <300000000>, + <19200000>, + <19200000>, + <19200000>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmhpd SM6350_CX>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + }; + }; + + dsi@ae94000 { + compatible = "qcom,sm6350-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x0ae94000 0x400>; + reg-names = "dsi_ctrl"; + + 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>, + <&gcc GCC_DISP_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>; + assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>; + + operating-points-v2 = <&dsi_opp_table>; + power-domains = <&rpmhpd SM6350_MX>; + + phys = <&dsi0_phy>; + phy-names = "dsi"; + + #address-cells = <1>; + #size-cells = <0>; + + 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 { + }; + }; + }; + }; + + dsi0_phy: 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>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml new file mode 100644 index 000000000000..30d36fffaedb --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml @@ -0,0 +1,208 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,sm6375-mdss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM6375 Display MDSS + +maintainers: + - Konrad Dybcio <konrad.dybcio@linaro.org> + +description: + SM6375 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks + like DPU display controller, DSI and DP interfaces etc. + +$ref: /schemas/display/msm/mdss-common.yaml# + +properties: + compatible: + const: qcom,sm6375-mdss + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display AHB clock + - description: Display core clock + + clock-names: + items: + - const: iface + - const: ahb + - const: core + + iommus: + maxItems: 1 + + interconnects: + maxItems: 2 + + interconnect-names: + maxItems: 2 + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + properties: + compatible: + const: qcom,sm6375-dpu + + "^dsi@[0-9a-f]+$": + type: object + properties: + compatible: + items: + - const: qcom,sm6375-dsi-ctrl + - const: qcom,mdss-dsi-ctrl + + "^phy@[0-9a-f]+$": + type: object + properties: + compatible: + const: qcom,sm6375-dsi-phy-7nm + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/clock/qcom,sm6375-gcc.h> + #include <dt-bindings/clock/qcom,sm6375-dispcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-subsystem@5e00000 { + compatible = "qcom,sm6375-mdss"; + reg = <0x05e00000 0x1000>; + reg-names = "mdss"; + + power-domains = <&dispcc MDSS_GDSC>; + + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "ahb", "core"; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + iommus = <&apps_smmu 0x820 0x2>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + display-controller@5e01000 { + compatible = "qcom,sm6375-dpu"; + reg = <0x05e01000 0x8e030>, + <0x05eb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_ROT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>, + <&gcc GCC_DISP_THROTTLE_CORE_CLK>; + clock-names = "bus", + "iface", + "rot", + "lut", + "core", + "vsync", + "throttle"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + assigned-clock-rates = <19200000>; + + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmpd SM6375_VDDCX>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + }; + }; + + dsi@5e94000 { + compatible = "qcom,sm6375-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x05e94000 0x400>; + reg-names = "dsi_ctrl"; + + 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>, + <&gcc GCC_DISP_HF_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>; + assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>; + + operating-points-v2 = <&dsi_opp_table>; + power-domains = <&rpmpd SM6375_VDDMX>; + + phys = <&mdss_dsi0_phy>; + phy-names = "dsi"; + + #address-cells = <1>; + #size-cells = <0>; + + 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 { + }; + }; + }; + }; + + mdss_dsi0_phy: phy@5e94400 { + compatible = "qcom,sm6375-dsi-phy-7nm"; + reg = <0x05e94400 0x200>, + <0x05e94600 0x280>, + <0x05e94900 0x264>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmcc RPM_SMD_XO_CLK_SRC>; + clock-names = "iface", "ref"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml index 2b3f3fe9bdf7..13146b3f053c 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm8150-dpu.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml index 5182e958e069..54cdaa827cd3 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm8150-mdss.yaml# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml index 687c8c170cd4..ffa5047e901f 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm8250-dpu.yaml# @@ -54,7 +54,7 @@ examples: #include <dt-bindings/clock/qcom,gcc-sm8250.h> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interconnect/qcom,sm8250.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> display-controller@ae01000 { compatible = "qcom,sm8250-dpu"; @@ -72,7 +72,7 @@ examples: assigned-clock-rates = <19200000>; operating-points-v2 = <&mdp_opp_table>; - power-domains = <&rpmhpd SM8250_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; interrupt-parent = <&mdss>; interrupts = <0>; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml index 368d3db0ce96..e887f031b8be 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm8250-mdss.yaml# @@ -76,7 +76,7 @@ examples: #include <dt-bindings/clock/qcom,rpmh.h> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interconnect/qcom,sm8250.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> display-subsystem@ae00000 { compatible = "qcom,sm8250-mdss"; @@ -121,7 +121,7 @@ examples: assigned-clock-rates = <19200000>; operating-points-v2 = <&mdp_opp_table>; - power-domains = <&rpmhpd SM8250_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; interrupt-parent = <&mdss>; interrupts = <0>; @@ -196,7 +196,7 @@ examples: assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>; operating-points-v2 = <&dsi_opp_table>; - power-domains = <&rpmhpd SM8250_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; phys = <&dsi0_phy>; phy-names = "dsi"; @@ -286,7 +286,7 @@ examples: assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>; operating-points-v2 = <&dsi_opp_table>; - power-domains = <&rpmhpd SM8250_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; phys = <&dsi1_phy>; phy-names = "dsi"; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml index 120500395c9a..96ef2d9c3512 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm8350-dpu.yaml# @@ -51,7 +51,7 @@ examples: #include <dt-bindings/clock/qcom,gcc-sm8350.h> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interconnect/qcom,sm8350.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> display-controller@ae01000 { compatible = "qcom,sm8350-dpu"; @@ -76,7 +76,7 @@ examples: assigned-clock-rates = <19200000>; operating-points-v2 = <&mdp_opp_table>; - power-domains = <&rpmhpd SM8350_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; interrupt-parent = <&mdss>; interrupts = <0>; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml index 4d94dbff3054..60d4aae1131b 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm8350-mdss.yaml# @@ -52,6 +52,12 @@ patternProperties: compatible: const: qcom,sm8350-dpu + "^displayport-controller@[0-9a-f]+$": + type: object + properties: + compatible: + const: qcom,sm8350-dp + "^dsi@[0-9a-f]+$": type: object properties: @@ -64,7 +70,7 @@ patternProperties: type: object properties: compatible: - const: qcom,dsi-phy-5nm-8350 + const: qcom,sm8350-dsi-phy-5nm unevaluatedProperties: false @@ -75,7 +81,7 @@ examples: #include <dt-bindings/clock/qcom,rpmh.h> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interconnect/qcom,sm8350.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> display-subsystem@ae00000 { compatible = "qcom,sm8350-mdss"; @@ -128,7 +134,7 @@ examples: assigned-clock-rates = <19200000>; operating-points-v2 = <&mdp_opp_table>; - power-domains = <&rpmhpd SM8350_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; interrupt-parent = <&mdss>; interrupts = <0>; @@ -197,7 +203,7 @@ examples: <&mdss_dsi0_phy 1>; operating-points-v2 = <&dsi_opp_table>; - power-domains = <&rpmhpd SM8350_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; phys = <&mdss_dsi0_phy>; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml index 0d17ece1c453..2a5d3daed0e1 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm8450-dpu.yaml# @@ -58,7 +58,7 @@ examples: #include <dt-bindings/clock/qcom,gcc-sm8450.h> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interconnect/qcom,sm8450.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> display-controller@ae01000 { compatible = "qcom,sm8450-dpu"; @@ -83,7 +83,7 @@ examples: assigned-clock-rates = <19200000>; operating-points-v2 = <&mdp_opp_table>; - power-domains = <&rpmhpd SM8450_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; interrupt-parent = <&mdss>; interrupts = <0>; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml index f26eb5643aed..bb22940b9385 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm8450-mdss.yaml# @@ -42,6 +42,14 @@ patternProperties: compatible: const: qcom,sm8450-dpu + "^displayport-controller@[0-9a-f]+$": + type: object + properties: + compatible: + items: + - const: qcom,sm8450-dp + - const: qcom,sm8350-dp + "^dsi@[0-9a-f]+$": type: object properties: @@ -68,7 +76,7 @@ examples: #include <dt-bindings/clock/qcom,rpmh.h> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interconnect/qcom,sm8450.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> display-subsystem@ae00000 { compatible = "qcom,sm8450-mdss"; @@ -122,7 +130,7 @@ examples: assigned-clock-rates = <19200000>; operating-points-v2 = <&mdp_opp_table>; - power-domains = <&rpmhpd SM8450_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; interrupt-parent = <&mdss>; interrupts = <0>; @@ -202,7 +210,7 @@ examples: assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>; operating-points-v2 = <&dsi_opp_table>; - power-domains = <&rpmhpd SM8450_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; phys = <&dsi0_phy>; phy-names = "dsi"; @@ -297,7 +305,7 @@ examples: assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>; operating-points-v2 = <&dsi_opp_table>; - power-domains = <&rpmhpd SM8450_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; phys = <&dsi1_phy>; phy-names = "dsi"; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml index ff58a747bb6f..16a541fca66f 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm8550-dpu.yaml# @@ -57,7 +57,7 @@ examples: #include <dt-bindings/clock/qcom,sm8550-dispcc.h> #include <dt-bindings/clock/qcom,sm8550-gcc.h> #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> display-controller@ae01000 { compatible = "qcom,sm8550-dpu"; @@ -82,7 +82,7 @@ examples: assigned-clock-rates = <19200000>; operating-points-v2 = <&mdp_opp_table>; - power-domains = <&rpmhpd SM8550_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; interrupt-parent = <&mdss>; interrupts = <0>; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml index 887be33ba108..48aea8005c86 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/msm/qcom,sm8550-mdss.yaml# @@ -42,6 +42,14 @@ patternProperties: compatible: const: qcom,sm8550-dpu + "^displayport-controller@[0-9a-f]+$": + type: object + properties: + compatible: + items: + - const: qcom,sm8550-dp + - const: qcom,sm8350-dp + "^dsi@[0-9a-f]+$": type: object properties: @@ -68,7 +76,7 @@ examples: #include <dt-bindings/clock/qcom,rpmh.h> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> display-subsystem@ae00000 { compatible = "qcom,sm8550-mdss"; @@ -122,7 +130,7 @@ examples: assigned-clock-rates = <19200000>; operating-points-v2 = <&mdp_opp_table>; - power-domains = <&rpmhpd SM8550_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; interrupt-parent = <&mdss>; interrupts = <0>; @@ -197,7 +205,7 @@ examples: assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>; operating-points-v2 = <&dsi_opp_table>; - power-domains = <&rpmhpd SM8550_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; phys = <&dsi0_phy>; phy-names = "dsi"; @@ -286,7 +294,7 @@ examples: assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>; operating-points-v2 = <&dsi_opp_table>; - power-domains = <&rpmhpd SM8550_MMCX>; + power-domains = <&rpmhpd RPMHPD_MMCX>; phys = <&dsi1_phy>; phy-names = "dsi"; diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml index 67682fe77f10..2e8dbdb5a3d5 100644 --- a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml +++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml @@ -19,6 +19,9 @@ description: | second port, therefore the ports must be marked accordingly (with either dual-lvds-odd-pixels or dual-lvds-even-pixels). +allOf: + - $ref: panel-common.yaml# + properties: compatible: items: diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml index aed55608ebf6..906ef62709b8 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml @@ -32,6 +32,10 @@ properties: - innolux,hj110iz-01a # STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel - starry,2081101qfh032011-53g + # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel + - starry,himax83102-j02 + # STARRY ili9882t 10.51" WUXGA TFT LCD panel + - starry,ili9882t reg: description: the virtual channel number of a DSI peripheral diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml index 1b2a1baa26f9..ffb35288ffbb 100644 --- a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml +++ b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/display/panel/himax,hx8394.yaml# diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml index c5d1df680858..e7ab6224b52e 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml @@ -18,6 +18,7 @@ properties: - enum: - bananapi,lhr050h41 - feixin,k101-im2byl02 + - tdo,tl050hdv35 - wanchanglong,w552946aba - const: ilitek,ili9881c diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml index a4b8569ab81c..74ff772973d6 100644 --- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml +++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml# diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml index 0039561ef04c..5f7e4c486094 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml @@ -19,11 +19,16 @@ allOf: properties: compatible: - items: - - enum: - - xiaomi,elish-boe-nt36523 - - xiaomi,elish-csot-nt36523 - - const: novatek,nt36523 + oneOf: + - items: + - enum: + - xiaomi,elish-boe-nt36523 + - xiaomi,elish-csot-nt36523 + - const: novatek,nt36523 + - items: + - enum: + - lenovo,j606f-boe-nt36523w + - const: novatek,nt36523w reset-gpios: maxItems: 1 @@ -34,6 +39,7 @@ properties: reg: true ports: true + rotation: true backlight: true required: diff --git a/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml index 9f97598efdfa..72463795e4c6 100644 --- a/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml +++ b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml @@ -20,7 +20,7 @@ description: | The panel itself contains: - AT24C16C EEPROM holding panel identification and timing requirements - AR1021 resistive touch screen controller (optional) - - FT5x6 capacitive touch screnn controller (optional) + - FT5x6 capacitive touch screen controller (optional) - GT911/GT928 capacitive touch screen controller (optional) The above chips share same I2C bus. The EEPROM is factory preprogrammed with diff --git a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml index ad7d3575190e..1e4f140f48b8 100644 --- a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml +++ b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/display/panel/orisetech,otm8009a.yaml# diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml index 5b38dc89cb21..0a57a31f4f3d 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml @@ -12,7 +12,7 @@ maintainers: description: | This document defines device tree properties common to several classes of - display panels. It doesn't constitue a device tree binding specification by + display panels. It doesn't constitute a device tree binding specification by itself but is meant to be referenced by device tree bindings. When referenced from panel device tree bindings the properties defined in this diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml index 4a36aa64c716..f8dc9929e833 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/display/panel/panel-dsi-cm.yaml# diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml index 929fe046d1e7..9f1016551e0b 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -40,6 +40,12 @@ properties: items: - enum: - auo,b101ew05 + # Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel + - chunghwa,claa070wp03xg + # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel + - hannstar,hsd101pww2 + # Hydis Technologies 7" WXGA (800x1280) TFT LCD LVDS panel + - hydis,hv070wx2-1e0 - tbs,a711-panel - const: panel-lvds diff --git a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml index 9b701df5e9d2..e808215cb39e 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml# @@ -66,7 +66,9 @@ properties: compatible: items: - enum: + - saef,sftc154b - sainsmart18 + - shineworld,lh133k - const: panel-mipi-dbi-spi write-only: @@ -86,6 +88,8 @@ properties: Logic level supply for interface signals (Vddi). No need to set if this is the same as power-supply. + spi-3wire: true + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index 90c04cff8281..73674baea75d 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/display/panel/panel-simple-dsi.yaml# diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 01560fe226dd..25b4589d4a58 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -33,6 +33,8 @@ properties: - ampire,am-1280800n3tzqw-t00h # Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel - ampire,am-480272h3tmqw-t01h + # Ampire AM-800480L1TMQW-T00H 5" WVGA TFT LCD panel + - ampire,am-800480l1tmqw-t00h # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel - ampire,am800480r3tmqwa1h # Ampire AM-800600P5TMQW-TB8H 8.0" SVGA TFT LCD panel @@ -77,6 +79,8 @@ properties: - auo,t215hvn01 # Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel - avic,tm070ddh03 + # BOE EV121WXM-N10-1850 12.1" WXGA (1280x800) TFT LCD panel + - boe,ev121wxm-n10-1850 # BOE HV070WSA-100 7.01" WSVGA TFT LCD panel - boe,hv070wsa-100 # BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel @@ -99,8 +103,6 @@ properties: - cdtech,s070wv95-ct16 # Chefree CH101OLHLWH-002 10.1" (1280x800) color TFT LCD panel - chefree,ch101olhlwh-002 - # Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel - - chunghwa,claa070wp03xg # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel - chunghwa,claa101wa01a # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel @@ -164,8 +166,6 @@ properties: - hannstar,hsd070pww1 # HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel - hannstar,hsd100pxn1 - # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel - - hannstar,hsd101pww2 # Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel - hit,tx23d38vm0caa # InfoVision Optoelectronics M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel @@ -174,6 +174,8 @@ properties: - innolux,at043tn24 # Innolux AT070TN92 7.0" WQVGA TFT LCD panel - innolux,at070tn92 + # Innolux G070ACE-L01 7" WVGA (800x480) TFT LCD panel + - innolux,g070ace-l01 # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel - innolux,g070y2-l01 # Innolux G070Y2-T02 7" WVGA (800x480) TFT LCD TTL panel @@ -190,6 +192,8 @@ properties: - innolux,n116bge # InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel - innolux,n125hce-gn1 + # InnoLux 15.6" FHD (1920x1080) TFT LCD panel + - innolux,g156hce-l01 # InnoLux 15.6" WXGA TFT LCD panel - innolux,n156bge-l21 # Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel @@ -280,6 +284,8 @@ properties: - rocktech,rk101ii01d-ct # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel - rocktech,rk070er9427 + # Rocktech Display Ltd. RK043FN48H 4.3" 480x272 LCD-TFT panel + - rocktech,rk043fn48h # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel - samsung,atna33xc20 # Samsung 12.2" (2560x1600 pixels) TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml index e8ce2315631a..46fe1014ebc4 100644 --- a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/display/panel/raydium,rm68200.yaml# diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml index 09b5eb7542f8..5ea74426b1d5 100644 --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/display/panel/rocktech,jh057n00900.yaml# @@ -20,6 +20,8 @@ allOf: properties: compatible: enum: + # Anberic RG353V-V2 5.0" 640x480 TFT LCD panel + - anbernic,rg353v-panel-v2 # Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel - rocktech,jh057n00900 # Xingbangda XBD599 5.99" 720x1440 TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml new file mode 100644 index 000000000000..45a236d2cc70 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,s6d7aa0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S6D7AA0 MIPI-DSI LCD panel controller + +maintainers: + - Artur Weber <aweber.kernel@gmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + # 1280x800 LSL080AL02 panel + - samsung,lsl080al02 + # 1024x768 LSL080AL03 panel + - samsung,lsl080al03 + # 1024x768 LTL101AT01 panel + - samsung,ltl101at01 + - const: samsung,s6d7aa0 + + reg: true + + backlight: + description: + Backlight to use for the panel. If this property is set on panels + that have DSI-based backlight control (LSL080AL03 and LTL101AT01), + it overrides the DSI-based backlight. + + reset-gpios: + description: Reset GPIO pin, usually GPIO_ACTIVE_LOW. + + power-supply: + description: + Main power supply for the panel; the exact voltage differs between + panels, and is usually somewhere around 3.3-5v. + + vmipi-supply: + description: VMIPI supply, usually 1.8v. + +required: + - compatible + - reg + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "samsung,lsl080al02", "samsung,s6d7aa0"; + reg = <0>; + power-supply = <&display_3v3_supply>; + reset-gpios = <&gpf0 4 GPIO_ACTIVE_LOW>; + backlight = <&backlight>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml index 1cdc91b3439f..200fbf1c74a0 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml @@ -74,7 +74,7 @@ examples: vdd3-supply = <&vcclcd_reg>; vci-supply = <&vlcd_reg>; reset-gpios = <&gpy4 5 0>; - power-on-delay= <50>; + power-on-delay = <50>; reset-delay = <100>; init-delay = <100>; panel-width-mm = <58>; diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml index fa6556363cca..ef162b51d010 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml @@ -15,17 +15,26 @@ allOf: properties: compatible: - const: sitronix,st7789v + enum: + - edt,et028013dma + - inanbo,t28cp45tn89-v17 + - jasonic,jt240mhqs-hwt-ek-e3 + - sitronix,st7789v reg: true reset-gpios: true power-supply: true backlight: true port: true + rotation: true spi-cpha: true spi-cpol: true + spi-rx-bus-width: + minimum: 0 + maximum: 1 + dc-gpios: maxItems: 1 description: DCX pin, Display data/command selection pin in parallel interface @@ -33,7 +42,6 @@ properties: required: - compatible - reg - - reset-gpios - power-supply unevaluatedProperties: false @@ -52,6 +60,7 @@ examples: reset-gpios = <&pio 6 11 GPIO_ACTIVE_LOW>; backlight = <&pwm_bl>; power-supply = <&power>; + rotation = <180>; spi-max-frequency = <100000>; spi-cpol; spi-cpha; diff --git a/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml new file mode 100644 index 000000000000..d817f998cddc --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/startek,kd070fhfid015.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Startek Electronic Technology Co. kd070fhfid015 7 inch TFT LCD panel + +maintainers: + - Alexandre Mergnat <amergnat@baylibre.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: startek,kd070fhfid015 + + enable-gpios: true + + iovcc-supply: + description: Reference to the regulator powering the panel IO pins. + + reg: + maxItems: 1 + description: DSI virtual channel + + reset-gpios: true + + port: true + + power-supply: true + +additionalProperties: false + +required: + - compatible + - enable-gpios + - iovcc-supply + - reg + - reset-gpios + - port + - power-supply + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi0 { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "startek,kd070fhfid015"; + reg = <0>; + enable-gpios = <&pio 67 GPIO_ACTIVE_HIGH>; + reset-gpios = <&pio 20 GPIO_ACTIVE_HIGH>; + iovcc-supply = <&mt6357_vsim1_reg>; + power-supply = <&vsys_lcm_reg>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi_out>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml new file mode 100644 index 000000000000..6ba323683921 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/visionox,r66451.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Visionox R66451 AMOLED DSI Panel + +maintainers: + - Jessica Zhang <quic_jesszhan@quicinc.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: visionox,r66451 + + reg: + maxItems: 1 + description: DSI virtual channel + + vddio-supply: true + vdd-supply: true + port: true + reset-gpios: true + +additionalProperties: false + +required: + - compatible + - reg + - vddio-supply + - vdd-supply + - reset-gpios + - port + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "visionox,r66451"; + reg = <0>; + vddio-supply = <&vreg_l12c_1p8>; + vdd-supply = <&vreg_l13c_3p0>; + + reset-gpios = <&tlmm 24 GPIO_ACTIVE_LOW>; + + port { + panel0_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml index 444ac2a4772d..fa745a6f4456 100644 --- a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml +++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/panel/visionox,rm69299.yaml# diff --git a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml index 84562a5b710a..d5a8295106c1 100644 --- a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml +++ b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/panel/visionox,vtdr6130.yaml# diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml index 6f43d885c9b3..df61cb5f5c54 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml @@ -121,11 +121,11 @@ examples: #size-cells = <0>; vopb_out_edp: endpoint@0 { reg = <0>; - remote-endpoint=<&edp_in_vopb>; + remote-endpoint = <&edp_in_vopb>; }; vopb_out_hdmi: endpoint@1 { reg = <1>; - remote-endpoint=<&hdmi_in_vopb>; + remote-endpoint = <&hdmi_in_vopb>; }; }; }; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml index fba45091d909..b60b90472d42 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/display/rockchip/rockchip-vop2.yaml# diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 94bb5ef567c6..20e2bd15d4d2 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -49,15 +49,15 @@ properties: solomon,height: $ref: /schemas/types.yaml#/definitions/uint32 - default: 16 description: - Height in pixel of the screen driven by the controller + Height in pixel of the screen driven by the controller. + The default value is controller-dependent. solomon,width: $ref: /schemas/types.yaml#/definitions/uint32 - default: 96 description: - Width in pixel of the screen driven by the controller + Width in pixel of the screen driven by the controller. + The default value is controller-dependent. solomon,page-offset: $ref: /schemas/types.yaml#/definitions/uint32 @@ -157,6 +157,10 @@ allOf: const: sinowealth,sh1106 then: properties: + width: + default: 132 + height: + default: 64 solomon,dclk-div: default: 1 solomon,dclk-frq: @@ -171,6 +175,10 @@ allOf: - solomon,ssd1305 then: properties: + width: + default: 132 + height: + default: 64 solomon,dclk-div: default: 1 solomon,dclk-frq: @@ -185,6 +193,10 @@ allOf: - solomon,ssd1306 then: properties: + width: + default: 128 + height: + default: 64 solomon,dclk-div: default: 1 solomon,dclk-frq: @@ -199,6 +211,10 @@ allOf: - solomon,ssd1307 then: properties: + width: + default: 128 + height: + default: 39 solomon,dclk-div: default: 2 solomon,dclk-frq: @@ -215,6 +231,10 @@ allOf: - solomon,ssd1309 then: properties: + width: + default: 128 + height: + default: 64 solomon,dclk-div: default: 1 solomon,dclk-frq: diff --git a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml index c488308d7be1..53560052aaf0 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml +++ b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml @@ -74,8 +74,6 @@ properties: - const: 2 required: - - "#address-cells" - - "#size-cells" - compatible - reg - clocks diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml index 70f0e45c71d6..6f2e22471965 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml @@ -97,7 +97,7 @@ properties: # optional when driving an eDP output nvidia,dpaux: - description: phandle to a DispayPort AUX interface + description: phandle to a DisplayPort AUX interface $ref: /schemas/types.yaml#/definitions/phandle allOf: diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml index a42bf33d1e7d..2181855a0920 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml @@ -73,6 +73,18 @@ properties: avdd-dsi-csi-supply: description: DSI/CSI power supply. Must supply 1.2 V. + vip: + $ref: /schemas/display/tegra/nvidia,tegra20-vip.yaml + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Input from the VIP (parallel input capture) module + patternProperties: "^csi@[0-9a-f]+$": type: object @@ -108,6 +120,22 @@ examples: #include <dt-bindings/clock/tegra20-car.h> #include <dt-bindings/interrupt-controller/arm-gic.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + camera@48 { + compatible = "aptina,mt9v111"; + reg = <0x48>; + clocks = <&camera_clk>; + + port { + mt9v111_out: endpoint { + remote-endpoint = <&vi_vip_in>; + }; + }; + }; + }; + vi@54080000 { compatible = "nvidia,tegra20-vi"; reg = <0x54080000 0x00040000>; @@ -115,6 +143,37 @@ examples: clocks = <&tegra_car TEGRA20_CLK_VI>; resets = <&tegra_car 100>; reset-names = "vi"; + + vip { + compatible = "nvidia,tegra20-vip"; + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + vi_vip_in: endpoint { + remote-endpoint = <&mt9v111_out>; + }; + }; + port@1 { + reg = <1>; + vi_vip_out: endpoint { + remote-endpoint = <&vi_in>; + }; + }; + }; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + vi_in: endpoint { + remote-endpoint = <&vi_vip_out>; + }; + }; + }; }; - | diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml new file mode 100644 index 000000000000..14294edb8d8c --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-vip.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra VIP (parallel video capture) controller + +maintainers: + - Luca Ceresoli <luca.ceresoli@bootlin.com> + +properties: + compatible: + enum: + - nvidia,tegra20-vip + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Port receiving the video stream from the sensor + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Port sending the video stream to the VI + + required: + - port@0 + - port@1 + +unevaluatedProperties: false + +required: + - compatible + - ports + +# see nvidia,tegra20-vi.yaml for an example diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index b6b402f16161..ae09cd3cbce1 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -12,14 +12,18 @@ maintainers: - Tomi Valkeinen <tomi.valkeinen@ti.com> description: | - The AM65x TI Keystone Display SubSystem with two output ports and - two video planes. The first video port supports OLDI and the second - supports DPI format. The fist plane is full video plane with all - features and the second is a "lite plane" without scaling support. + The AM625 and AM65x TI Keystone Display SubSystem with two output + ports and two video planes. In AM65x DSS, the first video port + supports 1 OLDI TX and in AM625 DSS, the first video port output is + internally routed to 2 OLDI TXes. The second video port supports DPI + format. The first plane is full video plane with all features and the + second is a "lite plane" without scaling support. properties: compatible: - const: ti,am65x-dss + enum: + - ti,am625-dss + - ti,am65x-dss reg: description: @@ -80,7 +84,9 @@ properties: port@0: $ref: /schemas/graph.yaml#/properties/port description: - The DSS OLDI output port node form video port 1 + For AM65x DSS, the OLDI output port node from video port 1. + For AM625 DSS, the internal DPI output port node from video + port 1. port@1: $ref: /schemas/graph.yaml#/properties/port diff --git a/Documentation/devicetree/bindings/dma/atmel-xdma.txt b/Documentation/devicetree/bindings/dma/atmel-xdma.txt index 510b7f25ba24..76d649b3a25d 100644 --- a/Documentation/devicetree/bindings/dma/atmel-xdma.txt +++ b/Documentation/devicetree/bindings/dma/atmel-xdma.txt @@ -3,7 +3,8 @@ * XDMA Controller Required properties: - compatible: Should be "atmel,sama5d4-dma", "microchip,sam9x60-dma" or - "microchip,sama7g5-dma". + "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 diff --git a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt deleted file mode 100644 index b6a8cc0978cd..000000000000 --- a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt +++ /dev/null @@ -1,83 +0,0 @@ -* BCM2835 DMA controller - -The BCM2835 DMA controller has 16 channels in total. -Only the lower 13 channels have an associated IRQ. -Some arbitrary channels are used by the firmware -(1,3,6,7 in the current firmware version). -The channels 0,2 and 3 have special functionality -and should not be used by the driver. - -Required properties: -- compatible: Should be "brcm,bcm2835-dma". -- reg: Should contain DMA registers location and length. -- interrupts: Should contain the DMA interrupts associated - to the DMA channels in ascending order. -- interrupt-names: Should contain the names of the interrupt - in the form "dmaXX". - Use "dma-shared-all" for the common interrupt line - that is shared by all dma channels. -- #dma-cells: Must be <1>, the cell in the dmas property of the - client device represents the DREQ number. -- brcm,dma-channel-mask: Bit mask representing the channels - not used by the firmware in ascending order, - i.e. first channel corresponds to LSB. - -Example: - -dma: dma@7e007000 { - compatible = "brcm,bcm2835-dma"; - reg = <0x7e007000 0xf00>; - interrupts = <1 16>, - <1 17>, - <1 18>, - <1 19>, - <1 20>, - <1 21>, - <1 22>, - <1 23>, - <1 24>, - <1 25>, - <1 26>, - /* dma channel 11-14 share one irq */ - <1 27>, - <1 27>, - <1 27>, - <1 27>, - /* unused shared irq for all channels */ - <1 28>; - interrupt-names = "dma0", - "dma1", - "dma2", - "dma3", - "dma4", - "dma5", - "dma6", - "dma7", - "dma8", - "dma9", - "dma10", - "dma11", - "dma12", - "dma13", - "dma14", - "dma-shared-all"; - - #dma-cells = <1>; - brcm,dma-channel-mask = <0x7f35>; -}; - - -DMA clients connected to the BCM2835 DMA controller must use the format -described in the dma.txt file, using a two-cell specifier for each channel. - -Example: - -bcm2835_i2s: i2s@7e203000 { - compatible = "brcm,bcm2835-i2s"; - reg = < 0x7e203000 0x24>; - clocks = <&clocks BCM2835_CLOCK_PCM>; - - dmas = <&dma 2>, - <&dma 3>; - dma-names = "tx", "rx"; -}; diff --git a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.yaml b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.yaml new file mode 100644 index 000000000000..c9b9a5490826 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/brcm,bcm2835-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: BCM2835 DMA controller + +maintainers: + - Nicolas Saenz Julienne <nsaenz@kernel.org> + +description: + The BCM2835 DMA controller has 16 channels in total. Only the lower + 13 channels have an associated IRQ. Some arbitrary channels are used by the + VideoCore firmware (1,3,6,7 in the current firmware version). The channels + 0, 2 and 3 have special functionality and should not be used by the driver. + +allOf: + - $ref: dma-controller.yaml# + +properties: + compatible: + const: brcm,bcm2835-dma + + reg: + maxItems: 1 + + interrupts: + description: + Should contain the DMA interrupts associated to the DMA channels in + ascending order. + minItems: 1 + maxItems: 16 + + interrupt-names: + minItems: 1 + maxItems: 16 + + '#dma-cells': + description: The single cell represents the DREQ number. + const: 1 + + brcm,dma-channel-mask: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Bitmask of available DMA channels in ascending order that are + not reserved by firmware and are available to the + kernel. i.e. first channel corresponds to LSB. + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - "#dma-cells" + - brcm,dma-channel-mask + +examples: + - | + dma-controller@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16>, + <1 17>, + <1 18>, + <1 19>, + <1 20>, + <1 21>, + <1 22>, + <1 23>, + <1 24>, + <1 25>, + <1 26>, + /* dma channel 11-14 share one irq */ + <1 27>, + <1 27>, + <1 27>, + <1 27>, + /* unused shared irq for all channels */ + <1 28>; + interrupt-names = "dma0", + "dma1", + "dma2", + "dma3", + "dma4", + "dma5", + "dma6", + "dma7", + "dma8", + "dma9", + "dma10", + "dma11", + "dma12", + "dma13", + "dma14", + "dma-shared-all"; + #dma-cells = <1>; + brcm,dma-channel-mask = <0x7f35>; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml index 5fd8fc604261..437db0c62339 100644 --- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml +++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml @@ -21,32 +21,41 @@ properties: - enum: - fsl,vf610-edma - fsl,imx7ulp-edma + - fsl,imx8qm-adma + - fsl,imx8qm-edma + - fsl,imx93-edma3 + - fsl,imx93-edma4 - items: - const: fsl,ls1028a-edma - const: fsl,vf610-edma reg: - minItems: 2 + minItems: 1 maxItems: 3 interrupts: - minItems: 2 - maxItems: 17 + minItems: 1 + maxItems: 64 interrupt-names: - minItems: 2 - maxItems: 17 + minItems: 1 + maxItems: 64 "#dma-cells": - const: 2 + enum: + - 2 + - 3 dma-channels: - const: 32 + minItems: 1 + maxItems: 64 clocks: + minItems: 1 maxItems: 2 clock-names: + minItems: 1 maxItems: 2 big-endian: @@ -69,21 +78,52 @@ allOf: properties: compatible: contains: + enum: + - fsl,imx8qm-adma + - fsl,imx8qm-edma + - fsl,imx93-edma3 + - fsl,imx93-edma4 + then: + properties: + "#dma-cells": + const: 3 + # It is not necessary to write the interrupt name for each channel. + # instead, you can simply maintain the sequential IRQ numbers as + # defined for the DMA channels. + interrupt-names: false + clock-names: + items: + - const: dma + clocks: + maxItems: 1 + + - if: + properties: + compatible: + contains: const: fsl,vf610-edma then: properties: + clocks: + minItems: 2 clock-names: items: - const: dmamux0 - const: dmamux1 interrupts: + minItems: 2 maxItems: 2 interrupt-names: items: - const: edma-tx - const: edma-err reg: + minItems: 2 maxItems: 3 + "#dma-cells": + const: 2 + dma-channels: + const: 32 - if: properties: @@ -92,14 +132,22 @@ allOf: const: fsl,imx7ulp-edma then: properties: + clock: + minItems: 2 clock-names: items: - const: dma - const: dmamux0 interrupts: + minItems: 2 maxItems: 17 reg: + minItems: 2 maxItems: 2 + "#dma-cells": + const: 2 + dma-channels: + const: 32 unevaluatedProperties: false @@ -153,3 +201,47 @@ examples: clock-names = "dma", "dmamux0"; clocks = <&pcc2 IMX7ULP_CLK_DMA1>, <&pcc2 IMX7ULP_CLK_DMA_MUX1>; }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx93-clock.h> + + dma-controller@44000000 { + compatible = "fsl,imx93-edma3"; + reg = <0x44000000 0x200000>; + #dma-cells = <3>; + dma-channels = <31>; + interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>, + <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>; + clocks = <&clk IMX93_CLK_EDMA1_GATE>; + clock-names = "dma"; + }; diff --git a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml index 37400496e086..d9cca3006e73 100644 --- a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml +++ b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml @@ -68,7 +68,7 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 description: > Bitmask of channels to reserve for devices that need a specific - channel. These channels will only be assigned when explicitely + channel. These channels will only be assigned when explicitly requested by a client. The primary use for this is channels 0 and 1, which can be configured to have special behaviour for NAND/BCH when using programmable firmware. diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt index c6908e7c42cc..447fb44e7abe 100644 --- a/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt @@ -2,7 +2,7 @@ Required properties: - compatible: Should be "nvidia,<chip>-apbdma" -- reg: Should contain DMA registers location and length. This shuld include +- reg: Should contain DMA registers location and length. This should include all of the per-channel registers. - interrupts: Should contain all of the per-channel DMA interrupts. - clocks: Must contain one entry, for the module clock. diff --git a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml index f1ddcf672261..3ad0d9b1fbc5 100644 --- a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml @@ -15,13 +15,19 @@ allOf: properties: compatible: - enum: - # APQ8064, IPQ8064 and MSM8960 - - qcom,bam-v1.3.0 - # MSM8974, APQ8074 and APQ8084 - - qcom,bam-v1.4.0 - # MSM8916 and SDM845 - - qcom,bam-v1.7.0 + oneOf: + - enum: + # APQ8064, IPQ8064 and MSM8960 + - qcom,bam-v1.3.0 + # MSM8974, APQ8074 and APQ8084 + - qcom,bam-v1.4.0 + # MSM8916, SDM630 + - qcom,bam-v1.7.0 + - items: + - enum: + # SDM845, SM6115, SM8150, SM8250 and QCM2290 + - qcom,bam-v1.7.4 + - const: qcom,bam-v1.7.0 clocks: maxItems: 1 @@ -38,7 +44,7 @@ properties: iommus: minItems: 1 - maxItems: 4 + maxItems: 6 num-channels: $ref: /schemas/types.yaml#/definitions/uint32 @@ -48,7 +54,7 @@ properties: qcom,controlled-remotely: type: boolean description: - Indicates that the bam is controlled by remote proccessor i.e. execution + Indicates that the bam is controlled by remote processor i.e. execution environment. qcom,ee: @@ -81,6 +87,15 @@ required: - qcom,ee - reg +anyOf: + - required: + - qcom,powered-remotely + - required: + - qcom,controlled-remotely + - required: + - clocks + - clock-names + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml index 64845347f44d..7b94d24d5ef4 100644 --- a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml +++ b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml @@ -112,14 +112,23 @@ properties: - const: stericsson,dma40 reg: - items: - - description: DMA40 memory base - - description: LCPA memory base + oneOf: + - items: + - description: DMA40 memory base + - items: + - description: DMA40 memory base + - description: LCPA memory base, deprecated, use eSRAM pool instead + deprecated: true + reg-names: - items: - - const: base - - const: lcpa + oneOf: + - items: + - const: base + - items: + - const: base + - const: lcpa + deprecated: true interrupts: maxItems: 1 @@ -127,10 +136,19 @@ properties: clocks: maxItems: 1 + sram: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: A phandle array with inner size 1 (no arg cells). + First phandle is the LCPA (Logical Channel Parameter Address) memory. + Second phandle is the LCLA (Logical Channel Link base Address) memory. + maxItems: 2 + items: + maxItems: 1 + memcpy-channels: $ref: /schemas/types.yaml#/definitions/uint32-array description: Array of u32 elements indicating which channels on the DMA - engine are elegible for memcpy transfers + engine are eligible for memcpy transfers required: - "#dma-cells" @@ -138,6 +156,7 @@ required: - reg - interrupts - clocks + - sram - memcpy-channels additionalProperties: false @@ -149,8 +168,9 @@ examples: #include <dt-bindings/mfd/dbx500-prcmu.h> dma-controller@801c0000 { compatible = "stericsson,db8500-dma40", "stericsson,dma40"; - reg = <0x801c0000 0x1000>, <0x40010000 0x800>; - reg-names = "base", "lcpa"; + reg = <0x801c0000 0x1000>; + reg-names = "base"; + sram = <&lcpa>, <&lcla>; interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; #dma-cells = <3>; memcpy-channels = <56 57 58 59 60>; diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml index beecfe7a1732..4ca300a42a99 100644 --- a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml +++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml @@ -33,6 +33,7 @@ properties: enum: - ti,am62a-dmss-bcdma-csirx - ti,am64-dmss-bcdma + - ti,j721s2-dmss-bcdma-csi reg: minItems: 3 @@ -151,7 +152,12 @@ allOf: required: - power-domains - else: + - if: + properties: + compatible: + contains: + const: ti,am64-dmss-bcdma + then: properties: reg: minItems: 5 @@ -168,6 +174,28 @@ allOf: - ti,sci-rm-range-bchan - ti,sci-rm-range-tchan + - if: + properties: + compatible: + contains: + const: ti,j721s2-dmss-bcdma-csi + then: + properties: + ti,sci-rm-range-bchan: false + + reg: + maxItems: 4 + + reg-names: + items: + - const: gcfg + - const: rchanrt + - const: tchanrt + - const: ringrt + + required: + - ti,sci-rm-range-tchan + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt index d1700a5c36bf..590d1948f202 100644 --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt @@ -49,6 +49,12 @@ Optional properties for AXI DMA and MCDMA: register as configured in h/w. Takes values {8...26}. If the property is missing or invalid then the default value 23 is used. This is the maximum value that is supported by all IP versions. + +Optional properties for AXI DMA: +- xlnx,axistream-connected: Tells whether DMA is connected to AXI stream IP. +- xlnx,irq-delay: Tells the interrupt delay timeout value. Valid range is from + 0-255. Setting this value to zero disables the delay timer interrupt. + 1 timeout interval = 125 * clock period of SG clock. Optional properties for VDMA: - xlnx,flush-fsync: Tells which channel to Flush on Frame sync. It takes following values: diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml index d6cbd95ec26d..2128f4645c98 100644 --- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml @@ -41,6 +41,9 @@ properties: clock-names: const: axi_clk + power-domains: + maxItems: 1 + required: - "#dma-cells" - compatible @@ -48,12 +51,14 @@ required: - interrupts - clocks - clock-names + - power-domains additionalProperties: false examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/xlnx-zynqmp-power.h> dma: dma-controller@fd4c0000 { compatible = "xlnx,zynqmp-dpdma"; @@ -63,6 +68,7 @@ examples: clocks = <&dpdma_clk>; clock-names = "axi_clk"; #dma-cells = <1>; + power-domains = <&zynqmp_firmware PD_DP>; }; ... diff --git a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml index 1dcb85a02a76..cc930660b794 100644 --- a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml +++ b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml @@ -42,7 +42,7 @@ properties: enum: [ 0, 1 ] performance-domains: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array description: A phandle and performance domain specifier as defined by bindings of the performance controller/provider specified by phandle. diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml index 84af0d5f52aa..98139489d4b5 100644 --- a/Documentation/devicetree/bindings/eeprom/at24.yaml +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/eeprom/at24.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/eeprom/at24.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: I2C EEPROMs compatible with Atmel's AT24 @@ -102,6 +102,9 @@ properties: # These are special cases that don't conform to the above pattern. # Each requires a standard at24 model as fallback. - items: + - const: belling,bl24c16a + - const: atmel,24c16 + - items: - enum: - rohm,br24g01 - rohm,br24t01 diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml b/Documentation/devicetree/bindings/eeprom/at25.yaml index 11e2a95a7bcb..1715b0c9feea 100644 --- a/Documentation/devicetree/bindings/eeprom/at25.yaml +++ b/Documentation/devicetree/bindings/eeprom/at25.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: "http://devicetree.org/schemas/eeprom/at25.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/eeprom/at25.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: SPI EEPROMs or FRAMs compatible with Atmel's AT25 @@ -33,6 +33,7 @@ properties: - microchip,25lc040 - st,m95m02 - st,m95256 + - st,m95640 - cypress,fm25 - const: atmel,at25 diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index f4eec4c42fb3..a41f9b9a196b 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml @@ -52,8 +52,7 @@ properties: - vendor,soc4-ip - vendor,soc3-ip - vendor,soc2-ip - - enum: - - vendor,soc1-ip + - const: vendor,soc1-ip # additionalItems being false is implied # minItems/maxItems equal to 2 is implied - items: @@ -85,6 +84,9 @@ properties: discouraged. clock-names: + # For single-entry lists in clocks, resets etc., the xxx-names often do not + # bring any value, especially if they copy the IP block name. In such case + # just skip the xxx-names. items: - const: bus diff --git a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml index 128960545640..55800fb0221d 100644 --- a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml +++ b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml @@ -23,6 +23,7 @@ properties: connector: $ref: /schemas/connector/usb-connector.yaml# + unevaluatedProperties: false ports: $ref: /schemas/graph.yaml#/properties/ports diff --git a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml index 6a9c96f0352a..6b80518cbf62 100644 --- a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml +++ b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies, Inc. PM8941 USB ID Extcon device maintainers: - - Guru Das Srinagesh <gurus@codeaurora.org> + - Guru Das Srinagesh <quic_gurus@quicinc.com> description: | Some Qualcomm PMICs have a "misc" module that can be used to detect when @@ -27,10 +27,14 @@ properties: interrupt-names: minItems: 1 - items: - - const: usb_id - - const: usb_vbus - + anyOf: + - items: + - const: usb_id + - const: usb_vbus + - items: + - const: usb_id + - items: + - const: usb_vbus required: - compatible - reg @@ -49,7 +53,7 @@ examples: interrupt-controller; #interrupt-cells = <4>; - usb_id: misc@900 { + usb_id: usb-detect@900 { compatible = "qcom,pm8941-misc"; reg = <0x900>; interrupts = <0x0 0x9 0 IRQ_TYPE_EDGE_BOTH>; diff --git a/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml index 7a224b2f0977..7ef2d9bef72d 100644 --- a/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml +++ b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml @@ -27,6 +27,10 @@ properties: description: I2C slave address of the device. Usually 0x25 for SM5502 and SM5703, 0x14 for SM5504. + connector: + $ref: /schemas/connector/usb-connector.yaml# + unevaluatedProperties: false + interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml index efdf59abb2e1..351b202d0e10 100644 --- a/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml +++ b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml @@ -23,7 +23,7 @@ properties: headphone detect mode to HPDETL, ARIZONA_ACCDET_MODE_HPR/2 sets it to HPDETR. If this node is not included or if the value is unknown, then headphone detection mode is set to HPDETL. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 1 maximum: 2 @@ -51,7 +51,7 @@ properties: description: Additional software microphone detection debounce specified in milliseconds. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 wlf,micd-pol-gpio: description: @@ -63,7 +63,7 @@ properties: description: Time allowed for MICBIAS to startup prior to performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX defines. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 12 @@ -71,7 +71,7 @@ properties: description: Delay between successive microphone detection measurements, specified as per the ARIZONA_MICD_TIME_XXX defines. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 12 @@ -79,7 +79,7 @@ properties: description: Microphone detection hardware debounces specified as the number of measurements to take. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: [2, 4] wlf,micd-timeout-ms: @@ -97,7 +97,7 @@ properties: CTIA / OMTP headsets), the field can be of variable length but should always be a multiple of 3 cells long, each three cell group represents one polarity configuration. - $ref: "/schemas/types.yaml#/definitions/uint32-matrix" + $ref: /schemas/types.yaml#/definitions/uint32-matrix items: items: - description: @@ -119,7 +119,7 @@ properties: description: Settings for the general purpose switch, set as one of the ARIZONA_GPSW_XXX defines. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3 diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index 5824c43e9893..b138f3d23df8 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -34,6 +34,10 @@ properties: - description: SCMI compliant firmware with ARM SMC/HVC transport items: - const: arm,scmi-smc + - description: SCMI compliant firmware with ARM SMC/HVC transport + with shmem address(4KB-page, offset) as parameters + items: + - const: arm,scmi-smc-param - description: SCMI compliant firmware with SCMI Virtio transport. The virtio transport only supports a single device. items: @@ -214,7 +218,7 @@ properties: patternProperties: '^regulator@[0-9a-f]+$': type: object - $ref: "../regulator/regulator.yaml#" + $ref: /schemas/regulator/regulator.yaml# unevaluatedProperties: false properties: @@ -299,7 +303,9 @@ else: properties: compatible: contains: - const: arm,scmi-smc + enum: + - arm,scmi-smc + - arm,scmi-smc-param then: required: - arm,smc-id diff --git a/Documentation/devicetree/bindings/firmware/brcm,kona-smc.yaml b/Documentation/devicetree/bindings/firmware/brcm,kona-smc.yaml new file mode 100644 index 000000000000..684b15ba9ad0 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/brcm,kona-smc.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/brcm,kona-smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Kona family Secure Monitor bounce buffer + +description: + A bounce buffer used for non-secure to secure communications. + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +properties: + compatible: + items: + - enum: + - brcm,bcm11351-smc + - brcm,bcm21664-smc + - brcm,bcm23550-smc + - const: brcm,kona-smc + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + smc@3404c000 { + compatible = "brcm,bcm11351-smc", "brcm,kona-smc"; + reg = <0x3404c000 0x400>; /* 1 KiB in SRAM */ + }; +... diff --git a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml index 9a785bbaafb7..e6bed7d93e2d 100644 --- a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml +++ b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Linaro Ltd. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/firmware/intel,ixp4xx-network-processing-engine.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/firmware/intel,ixp4xx-network-processing-engine.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel IXP4xx Network Processing Engine diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml index 833c07f1685c..c43d17f6e96b 100644 --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml @@ -57,8 +57,11 @@ description: | "#address-cells" or "#size-cells" property. The shared memory area for the IPC TX and RX between CPU and BPMP are - predefined and work on top of sysram, which is an SRAM inside the - chip. See ".../sram/sram.yaml" for the bindings. + predefined and work on top of either sysram, which is an SRAM inside the + chip, or in normal SDRAM. + See ".../sram/sram.yaml" for the bindings for the SRAM case. + See "../reserved-memory/nvidia,tegra264-bpmp-shmem.yaml" for bindings for + the SDRAM case. properties: compatible: @@ -81,6 +84,11 @@ properties: minItems: 2 maxItems: 2 + memory-region: + description: phandle to reserved memory region used for IPC between + CPU-NS and BPMP. + maxItems: 1 + "#clock-cells": const: 1 @@ -115,10 +123,15 @@ properties: additionalProperties: false +oneOf: + - required: + - memory-region + - required: + - shmem + required: - compatible - mboxes - - shmem - "#clock-cells" - "#power-domain-cells" - "#reset-cells" @@ -165,8 +178,7 @@ examples: <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW &emc>; interconnect-names = "read", "write", "dma-mem", "dma-write"; iommus = <&smmu TEGRA186_SID_BPMP>; - mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB - TEGRA_HSP_DB_MASTER_BPMP>; + mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>; shmem = <&cpu_bpmp_tx>, <&cpu_bpmp_rx>; #clock-cells = <1>; #power-domain-cells = <1>; @@ -184,3 +196,20 @@ examples: #thermal-sensor-cells = <1>; }; }; + + - | + #include <dt-bindings/mailbox/tegra186-hsp.h> + + bpmp { + compatible = "nvidia,tegra186-bpmp"; + interconnects = <&mc TEGRA186_MEMORY_CLIENT_BPMPR &emc>, + <&mc TEGRA186_MEMORY_CLIENT_BPMPW &emc>, + <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAR &emc>, + <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW &emc>; + interconnect-names = "read", "write", "dma-mem", "dma-write"; + mboxes = <&hsp_top1 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>; + memory-region = <&dram_cpu_bpmp_mail>; + #clock-cells = <1>; + #power-domain-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml index 83381f3a1341..4233ea839bfc 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml @@ -51,6 +51,7 @@ properties: - qcom,scm-sdm845 - qcom,scm-sdx55 - qcom,scm-sdx65 + - qcom,scm-sdx75 - qcom,scm-sm6115 - qcom,scm-sm6125 - qcom,scm-sm6350 @@ -175,6 +176,7 @@ allOf: contains: enum: - qcom,scm-qdu1000 + - qcom,scm-sc8280xp - qcom,scm-sm8450 - qcom,scm-sm8550 then: diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml index f14f7b454f07..822864488dcb 100644 --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx firmware driver maintainers: - - Nava kishore Manne <nava.manne@xilinx.com> + - Nava kishore Manne <nava.kishore.manne@amd.com> description: The zynqmp-firmware node describes the interface to platform firmware. ZynqMP has an interface to communicate with secure firmware. @@ -38,6 +38,9 @@ properties: - smc - hvc + "#power-domain-cells": + const: 1 + versal_fpga: $ref: /schemas/fpga/xlnx,versal-fpga.yaml# description: Compatible of the FPGA device. @@ -66,6 +69,17 @@ additionalProperties: false examples: - | + #include <dt-bindings/power/xlnx-zynqmp-power.h> + firmware { + zynqmp_firmware: zynqmp-firmware { + #power-domain-cells = <1>; + }; + }; + + sata { + power-domains = <&zynqmp_firmware PD_SATA>; + }; + versal-firmware { compatible = "xlnx,versal-firmware"; method = "smc"; diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt index 6694ef29a267..528df8a0e6d8 100644 --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt @@ -63,7 +63,7 @@ FPGA Bridge will be disabled. * During Partial Reconfiguration of a specific region, that region's bridge will be used to gate the busses. Traffic to other regions is not affected. - * In some implementations, the FPGA Manager transparantly handles gating the + * In some implementations, the FPGA Manager transparently handles gating the buses, eliminating the need to show the hardware FPGA bridges in the device tree. * An FPGA image may create a set of reprogrammable regions, each having its @@ -466,7 +466,7 @@ It is beyond the scope of this document to fully describe all the FPGA design constraints required to make partial reconfiguration work[1] [2] [3], but a few deserve quick mention. -A persona must have boundary connections that line up with those of the partion +A persona must have boundary connections that line up with those of the partition or region it is designed to go into. During programming, transactions through those connections must be stopped and diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml index f47b6140a742..04dcadc2c20e 100644 --- a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml +++ b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx Zynq FPGA Manager maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml index ac6a207278d5..26f18834caa3 100644 --- a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml +++ b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx Versal FPGA driver. maintainers: - - Nava kishore Manne <nava.manne@xilinx.com> + - Nava kishore Manne <nava.kishore.manne@amd.com> description: | Device Tree Versal FPGA bindings for the Versal SoC, controlled diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml index 00a8d92ff736..1390ae103b0b 100644 --- a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml +++ b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx Zynq Ultrascale MPSoC FPGA Manager maintainers: - - Nava kishore Manne <navam@xilinx.com> + - Nava kishore Manne <nava.kishore.manne@amd.com> description: | Device Tree Bindings for Zynq Ultrascale MPSoC FPGA Manager. diff --git a/Documentation/devicetree/bindings/fsi/ibm,i2cr-fsi-master.yaml b/Documentation/devicetree/bindings/fsi/ibm,i2cr-fsi-master.yaml new file mode 100644 index 000000000000..442cecdc57cb --- /dev/null +++ b/Documentation/devicetree/bindings/fsi/ibm,i2cr-fsi-master.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fsi/ibm,i2cr-fsi-master.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IBM I2C Responder virtual FSI master + +maintainers: + - Eddie James <eajames@linux.ibm.com> + +description: | + The I2C Responder (I2CR) is a an I2C device that's connected to an FSI CFAM + (see fsi.txt). The I2CR translates I2C bus operations to FSI CFAM reads and + writes or SCOM operations, thereby acting as an FSI master. + +properties: + compatible: + enum: + - ibm,i2cr-fsi-master + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + i2cr@20 { + compatible = "ibm,i2cr-fsi-master"; + reg = <0x20>; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/adi,ds4520-gpio.yaml b/Documentation/devicetree/bindings/gpio/adi,ds4520-gpio.yaml new file mode 100644 index 000000000000..25b3198c4d3e --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/adi,ds4520-gpio.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/adi,ds4520-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DS4520 I2C GPIO expander + +maintainers: + - Okan Sahin <okan.sahin@analog.com> + +properties: + compatible: + enum: + - adi,ds4520-gpio + + reg: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + const: 2 + + ngpios: + minimum: 1 + maximum: 9 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - ngpios + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + gpio@50 { + compatible = "adi,ds4520-gpio"; + reg = <0x50>; + ngpios = <9>; + gpio-controller; + #gpio-cells = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml index 4d69f79df859..62fcc2bd5d80 100644 --- a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml @@ -1,10 +1,10 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml# +$id: http://devicetree.org/schemas/gpio/brcm,bcm63xx-gpio.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Broadcom BCM6345 GPIO controller +title: Broadcom BCM63xx GPIO controller maintainers: - Álvaro Fernández Rojas <noltari@gmail.com> @@ -18,8 +18,6 @@ description: |+ BCM6338 have 8-bit data and dirout registers, where GPIO state can be read and/or written, and the direction changed from input to output. - BCM6345 have 16-bit data and dirout registers, where GPIO state can be read - and/or written, and the direction changed from input to output. BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data and dirout registers, where GPIO state can be read and/or written, and the direction changed from input to output. @@ -29,7 +27,6 @@ properties: enum: - brcm,bcm6318-gpio - brcm,bcm6328-gpio - - brcm,bcm6345-gpio - brcm,bcm6358-gpio - brcm,bcm6362-gpio - brcm,bcm6368-gpio @@ -64,17 +61,6 @@ additionalProperties: false examples: - | - gpio@fffe0406 { - compatible = "brcm,bcm6345-gpio"; - reg-names = "dirout", "dat"; - reg = <0xfffe0406 2>, <0xfffe040a 2>; - native-endian; - - gpio-controller; - #gpio-cells = <2>; - }; - - - | gpio@0 { compatible = "brcm,bcm63268-gpio"; reg-names = "dirout", "dat"; diff --git a/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt b/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt deleted file mode 100644 index 4a63bc96b687..000000000000 --- a/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt +++ /dev/null @@ -1,52 +0,0 @@ -Broadcom Kona Family GPIO -========================= - -This GPIO driver is used in the following Broadcom SoCs: - BCM11130, BCM11140, BCM11351, BCM28145, BCM28155 - -The Broadcom GPIO Controller IP can be configured prior to synthesis to -support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The -GPIO controller only supports edge, not level, triggering of interrupts. - -Required properties -------------------- - -- compatible: "brcm,bcm11351-gpio", "brcm,kona-gpio" -- reg: Physical base address and length of the controller's registers. -- interrupts: The interrupt outputs from the controller. There is one GPIO - interrupt per GPIO bank. The number of interrupts listed depends on the - number of GPIO banks on the SoC. The interrupts must be ordered by bank, - starting with bank 0. There is always a 1:1 mapping between banks and - IRQs. -- #gpio-cells: Should be <2>. The first cell is the pin number, the second - cell is used to specify optional parameters: - - bit 0 specifies polarity (0 for normal, 1 for inverted) - See also "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt. -- #interrupt-cells: Should be <2>. The first cell is the GPIO number. The - second cell is used to specify flags. The following subset of flags is - supported: - - trigger type (bits[1:0]): - 1 = low-to-high edge triggered. - 2 = high-to-low edge triggered. - 3 = low-to-high or high-to-low edge triggered - Valid values are 1, 2, 3 - See also .../devicetree/bindings/interrupt-controller/interrupts.txt. -- gpio-controller: Marks the device node as a GPIO controller. -- interrupt-controller: Marks the device node as an interrupt controller. - -Example: - gpio: gpio@35003000 { - compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio"; - reg = <0x35003000 0x800>; - interrupts = - <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH - GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH - GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH - GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH - GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH - GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>; - #gpio-cells = <2>; - #interrupt-cells = <2>; - gpio-controller; - interrupt-controller; - }; diff --git a/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.yaml new file mode 100644 index 000000000000..296fdd6b8f38 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/brcm,kona-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Kona family GPIO controller + +description: + The Broadcom GPIO Controller IP can be configured prior to synthesis to + support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The + GPIO controller only supports edge, not level, triggering of interrupts. + +maintainers: + - Ray Jui <rjui@broadcom.com> + +properties: + compatible: + items: + - enum: + - brcm,bcm11351-gpio + - brcm,bcm21664-gpio + - brcm,bcm23550-gpio + - const: brcm,kona-gpio + + reg: + maxItems: 1 + + interrupts: + minItems: 4 + maxItems: 6 + description: + The interrupt outputs from the controller. There is one GPIO interrupt + per GPIO bank. The number of interrupts listed depends on the number of + GPIO banks on the SoC. The interrupts must be ordered by bank, starting + with bank 0. There is always a 1:1 mapping between banks and IRQs. + + '#gpio-cells': + const: 2 + + '#interrupt-cells': + const: 2 + + gpio-controller: true + + interrupt-controller: true + +required: + - compatible + - reg + - interrupts + - '#gpio-cells' + - '#interrupt-cells' + - gpio-controller + - interrupt-controller + +allOf: + - if: + properties: + compatible: + contains: + const: brcm,bcm11351-gpio + then: + properties: + interrupts: + minItems: 6 + - if: + properties: + compatible: + contains: + enum: + - brcm,bcm21664-gpio + - brcm,bcm23550-gpio + then: + properties: + interrupts: + maxItems: 4 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + gpio@35003000 { + compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio"; + reg = <0x35003000 0x800>; + interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>; + #gpio-cells = <2>; + #interrupt-cells = <2>; + gpio-controller; + interrupt-controller; + }; +... diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml index ae18603697d7..d0ca2af89f1e 100644 --- a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml @@ -32,10 +32,12 @@ properties: - fsl,imx6sx-gpio - fsl,imx6ul-gpio - fsl,imx7d-gpio + - fsl,imx8dxl-gpio - fsl,imx8mm-gpio - fsl,imx8mn-gpio - fsl,imx8mp-gpio - fsl,imx8mq-gpio + - fsl,imx8qm-gpio - fsl,imx8qxp-gpio - fsl,imxrt1050-gpio - fsl,imxrt1170-gpio diff --git a/Documentation/devicetree/bindings/gpio/gpio-delay.yaml b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml new file mode 100644 index 000000000000..1cebc4058e27 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-delay.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO delay controller + +maintainers: + - Alexander Stein <linux@ew.tq-group.com> + +description: | + This binding describes an electrical setup where setting an GPIO output + is delayed by some external setup, e.g. RC circuit. + + +----------+ +-----------+ + | | VCC_B | | + | | | | | + | | VCC_A _ | | + | GPIO | | | R | Consumer | + |controller| ___ |_| | | + | | | | | | | + | [IOx|-------| |--+-----|-----+ | + | | |___| | | input | + | | | | | + +----------+ --- C +-----------+ + --- + | + - + GND + + If the input on the consumer is controlled by an open-drain signal + attached to an RC circuit the ramp-up delay is not under control + of the GPIO controller. + +properties: + compatible: + const: gpio-delay + + "#gpio-cells": + description: | + Specifies the pin, ramp-up and ramp-down delays. The + delays are specified in microseconds. + const: 3 + + gpios: + description: Array of GPIOs which output signal change is delayed + minItems: 1 + maxItems: 32 + + gpio-controller: true + + gpio-line-names: + minItems: 1 + maxItems: 32 + +required: + - compatible + - "#gpio-cells" + - gpio-controller + - gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + enable_delay: enable-delay { + compatible = "gpio-delay"; + #gpio-cells = <3>; + gpio-controller; + gpios = <&gpio0 3 GPIO_ACTIVE_LOW>, + <&gpio3 1 GPIO_ACTIVE_HIGH>; + }; + + consumer { + enable-gpios = <&enable_delay 0 130000 30000>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml b/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml new file mode 100644 index 000000000000..daadfb4926c3 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml @@ -0,0 +1,154 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-ep9301.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: EP93xx GPIO controller + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + - Bartosz Golaszewski <brgl@bgdev.pl> + - Nikita Shubin <nikita.shubin@maquefel.me> + +properties: + compatible: + oneOf: + - const: cirrus,ep9301-gpio + - items: + - enum: + - cirrus,ep9302-gpio + - cirrus,ep9307-gpio + - cirrus,ep9312-gpio + - cirrus,ep9315-gpio + - const: cirrus,ep9301-gpio + + reg: + minItems: 2 + items: + - description: data register + - description: direction register + - description: interrupt registers base + + reg-names: + minItems: 2 + items: + - const: data + - const: dir + - const: intr + + gpio-controller: true + + gpio-ranges: true + + "#gpio-cells": + const: 2 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + interrupts: + oneOf: + - maxItems: 1 + - description: port F has dedicated irq line for each gpio line + maxItems: 8 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + gpio@80840000 { + compatible = "cirrus,ep9301-gpio"; + reg = <0x80840000 0x04>, + <0x80840010 0x04>, + <0x80840090 0x1c>; + reg-names = "data", "dir", "intr"; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + interrupt-parent = <&vic1>; + interrupts = <27>; + }; + + gpio@80840004 { + compatible = "cirrus,ep9301-gpio"; + reg = <0x80840004 0x04>, + <0x80840014 0x04>, + <0x808400ac 0x1c>; + reg-names = "data", "dir", "intr"; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + interrupt-parent = <&vic1>; + interrupts = <27>; + }; + + gpio@80840008 { + compatible = "cirrus,ep9301-gpio"; + reg = <0x80840008 0x04>, + <0x80840018 0x04>; + reg-names = "data", "dir"; + gpio-controller; + #gpio-cells = <2>; + }; + + gpio@8084000c { + compatible = "cirrus,ep9301-gpio"; + reg = <0x8084000c 0x04>, + <0x8084001c 0x04>; + reg-names = "data", "dir"; + gpio-controller; + #gpio-cells = <2>; + }; + + gpio@80840020 { + compatible = "cirrus,ep9301-gpio"; + reg = <0x80840020 0x04>, + <0x80840024 0x04>; + reg-names = "data", "dir"; + gpio-controller; + #gpio-cells = <2>; + }; + + gpio@80840030 { + compatible = "cirrus,ep9301-gpio"; + reg = <0x80840030 0x04>, + <0x80840034 0x04>, + <0x8084004c 0x1c>; + reg-names = "data", "dir", "intr"; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + interrupts-extended = <&vic0 19>, <&vic0 20>, + <&vic0 21>, <&vic0 22>, + <&vic1 15>, <&vic1 16>, + <&vic1 17>, <&vic1 18>; + }; + + gpio@80840038 { + compatible = "cirrus,ep9301-gpio"; + reg = <0x80840038 0x04>, + <0x8084003c 0x04>; + reg-names = "data", "dir"; + gpio-controller; + #gpio-cells = <2>; + }; + + gpio@80840040 { + compatible = "cirrus,ep9301-gpio"; + reg = <0x80840040 0x04>, + <0x80840044 0x04>; + reg-names = "data", "dir"; + gpio-controller; + #gpio-cells = <2>; + }; + +... diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml new file mode 100644 index 000000000000..b394e058256e --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-mmio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic MMIO GPIO + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + - Bartosz Golaszewski <brgl@bgdev.pl> + +description: + Some simple GPIO controllers may consist of a single data register or a pair + of set/clear-bit registers. Such controllers are common for glue logic in + FPGAs or ASICs. Commonly, these controllers are accessed over memory-mapped + NAND-style parallel busses. + +properties: + compatible: + enum: + - brcm,bcm6345-gpio + - ni,169445-nand-gpio + - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller + + big-endian: true + + '#gpio-cells': + const: 2 + + gpio-controller: true + + little-endian: true + + reg: + minItems: 1 + description: + A list of registers in the controller. The width of each register is + determined by its size. All registers must have the same width. The number + of GPIOs is set by the width, with bit 0 corresponding to GPIO 0. + items: + - description: + Register to READ the value of the GPIO lines. If GPIO line is high, + the bit will be set. If the GPIO line is low, the bit will be cleared. + This register may also be used to drive GPIOs if the SET register is + omitted. + - description: + Register to SET the value of the GPIO lines. Setting a bit in this + register will drive the GPIO line high. + - description: + Register to CLEAR the value of the GPIO lines. Setting a bit in this + register will drive the GPIO line low. If this register is omitted, + the SET register will be used to clear the GPIO lines as well, by + actively writing the line with 0. + - description: + Register to set the line as OUTPUT. Setting a bit in this register + will turn that line into an output line. Conversely, clearing a bit + will turn that line into an input. + - description: + Register to set this line as INPUT. Setting a bit in this register + will turn that line into an input line. Conversely, clearing a bit + will turn that line into an output. + + reg-names: + minItems: 1 + maxItems: 5 + items: + enum: + - dat + - set + - clr + - dirout + - dirin + + native-endian: true + + no-output: + $ref: /schemas/types.yaml#/definitions/flag + description: + If this property is present, the controller cannot drive the GPIO lines. + +required: + - compatible + - reg + - reg-names + - '#gpio-cells' + - gpio-controller + +additionalProperties: false + +examples: + - | + gpio@1f300010 { + compatible = "ni,169445-nand-gpio"; + reg = <0x1f300010 0x4>; + reg-names = "dat"; + gpio-controller; + #gpio-cells = <2>; + }; + + gpio@e0100000 { + compatible = "wd,mbl-gpio"; + reg-names = "dat"; + reg = <0xe0100000 0x1>; + #gpio-cells = <2>; + gpio-controller; + no-output; + }; + + gpio@fffe0406 { + compatible = "brcm,bcm6345-gpio"; + reg-names = "dirout", "dat"; + reg = <0xfffe0406 2>, <0xfffe040a 2>; + native-endian; + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml index 5b0134304e51..452f8972a965 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml @@ -24,6 +24,10 @@ properties: '#gpio-cells': const: 2 + gpio-line-names: + minItems: 4 + maxItems: 8 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml index fa116148ee90..99febb8ea1b6 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml @@ -66,6 +66,7 @@ properties: - ti,tca6408 - ti,tca6416 - ti,tca6424 + - ti,tca9538 - ti,tca9539 - ti,tca9554 diff --git a/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt b/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt deleted file mode 100644 index b33f8f02c0d7..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt +++ /dev/null @@ -1,17 +0,0 @@ -STMPE gpio ----------- - -Required properties: - - compatible: "st,stmpe-gpio" - -Optional properties: - - st,norequest-mask: bitmask specifying which GPIOs should _not_ be requestable - due to different usage (e.g. touch, keypad) - -Node should be child node of stmpe node to which it belongs. - -Example: - stmpe_gpio { - compatible = "st,stmpe-gpio"; - st,norequest-mask = <0x20>; //gpio 5 can't be used - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml index d2c39dba56ad..7c2d152e8617 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml @@ -61,6 +61,13 @@ properties: gpio-ranges: maxItems: 1 +patternProperties: + "^.+-hog(-[0-9]+)?$": + type: object + + required: + - gpio-hog + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt index e90fb987e25f..7ddf292db144 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt @@ -27,7 +27,7 @@ Required properties: - gpio-controller: Marks the device node as a GPIO controller. - interrupts: The EXT_INT_0 parent interrupt resource must be listed first. - interrupt-cells: Should be two. - - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N. + - first cell is 0-N corresponding for EXT_INT_0 to EXT_INT_N. - second cell is used to specify flags. - interrupt-controller: Marks the device node as an interrupt controller. - apm,nr-gpios: Optional, specify number of gpios pin. diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml index 572e1718f501..5e2496379a3c 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx Zynq GPIO controller maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt b/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt deleted file mode 100644 index 966514744df4..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt +++ /dev/null @@ -1,47 +0,0 @@ -* Oxford Semiconductor OXNAS SoC GPIO Controller - -Please refer to gpio.txt for generic information regarding GPIO bindings. - -Required properties: - - compatible: "oxsemi,ox810se-gpio" or "oxsemi,ox820-gpio" - - reg: Base address and length for the device. - - interrupts: The port interrupt shared by all pins. - - gpio-controller: Marks the port as GPIO controller. - - #gpio-cells: Two. The first cell is the pin number and - the second cell is used to specify the gpio polarity as defined in - defined in <dt-bindings/gpio/gpio.h>: - 0 = GPIO_ACTIVE_HIGH - 1 = GPIO_ACTIVE_LOW - - interrupt-controller: Marks the device node as an interrupt controller. - - #interrupt-cells: Two. The first cell is the GPIO number and second cell - is used to specify the trigger type as defined in - <dt-bindings/interrupt-controller/irq.h>: - IRQ_TYPE_EDGE_RISING - IRQ_TYPE_EDGE_FALLING - IRQ_TYPE_EDGE_BOTH - - gpio-ranges: Interaction with the PINCTRL subsystem, it also specifies the - gpio base and count, should be in the format of numeric-gpio-range as - specified in the gpio.txt file. - -Example: - -gpio0: gpio@0 { - compatible = "oxsemi,ox810se-gpio"; - reg = <0x000000 0x100000>; - interrupts = <21>; - #gpio-cells = <2>; - gpio-controller; - interrupt-controller; - #interrupt-cells = <2>; - gpio-ranges = <&pinctrl 0 0 32>; -}; - -keys { - ... - - button-esc { - label = "ESC"; - linux,code = <1>; - gpios = <&gpio0 12 0>; - }; -}; diff --git a/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt b/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt deleted file mode 100644 index ca2f8c745a27..000000000000 --- a/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt +++ /dev/null @@ -1,38 +0,0 @@ -Bindings for the National Instruments 169445 GPIO NAND controller - -The 169445 GPIO NAND controller has two memory mapped GPIO registers, one -for input (the ready signal) and one for output (control signals). It is -intended to be used with the GPIO NAND driver. - -Required properties: - - compatible: should be "ni,169445-nand-gpio" - - reg-names: must contain - "dat" - data register - - reg: address + size pairs describing the GPIO register sets; - order must correspond with the order of entries in reg-names - - #gpio-cells: must be set to 2. The first cell is the pin number and - the second cell is used to specify the gpio polarity: - 0 = active high - 1 = active low - - gpio-controller: Marks the device node as a gpio controller. - -Optional properties: - - no-output: disables driving output on the pins - -Examples: - gpio1: nand-gpio-out@1f300010 { - compatible = "ni,169445-nand-gpio"; - reg = <0x1f300010 0x4>; - reg-names = "dat"; - gpio-controller; - #gpio-cells = <2>; - }; - - gpio2: nand-gpio-in@1f300014 { - compatible = "ni,169445-nand-gpio"; - reg = <0x1f300014 0x4>; - reg-names = "dat"; - gpio-controller; - #gpio-cells = <2>; - no-output; - }; diff --git a/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml b/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml index b391cc1b4590..eefe7b345286 100644 --- a/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml @@ -9,7 +9,7 @@ title: Synopsys DesignWare APB GPIO controller description: | Synopsys DesignWare GPIO controllers have a configurable number of ports, each of which are intended to be represented as child nodes with the generic - GPIO-controller properties as desribed in this bindings file. + GPIO-controller properties as described in this bindings file. maintainers: - Hoan Tran <hoan@os.amperecomputing.com> @@ -61,6 +61,10 @@ patternProperties: '#gpio-cells': const: 2 + gpio-line-names: + minItems: 1 + maxItems: 32 + ngpios: default: 32 minimum: 1 diff --git a/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml b/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml new file mode 100644 index 000000000000..4555f1644a4d --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/st,stmpe-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectonics Port Expander (STMPE) GPIO Block + +description: + STMicroelectronics Port Expander (STMPE) is a series of slow + bus controllers for various expanded peripherals such as GPIO, keypad, + touchscreen, ADC, PWM or rotator. It can contain one or several different + peripherals connected to SPI or I2C. These bindings pertain to the + GPIO portions of these expanders. + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +properties: + compatible: + const: st,stmpe-gpio + + "#gpio-cells": + const: 2 + + "#interrupt-cells": + const: 2 + + gpio-controller: true + + gpio-line-names: + minItems: 1 + maxItems: 24 + + interrupt-controller: true + + st,norequest-mask: + description: + A bitmask of GPIO lines that cannot be requested because for + for example not being connected to anything on the system + $ref: /schemas/types.yaml#/definitions/uint32 + +patternProperties: + "^.+-hog(-[0-9]+)?$": + type: object + + required: + - gpio-hog + +additionalProperties: false + +required: + - compatible + - "#gpio-cells" + - "#interrupt-cells" + - gpio-controller + - interrupt-controller diff --git a/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml index bd721c839059..7b75d2f92f1b 100644 --- a/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml @@ -58,14 +58,14 @@ properties: deprecated: true description: Name of the hwmod associated with the GPIO. Needed on some legacy OMAP - SoCs which have not been converted to the ti,sysc interconnect hierarachy. + SoCs which have not been converted to the ti,sysc interconnect hierarchy. ti,no-reset-on-init: $ref: /schemas/types.yaml#/definitions/flag deprecated: true description: Do not reset on init. Used with ti,hwmods on some legacy OMAP SoCs which - have not been converted to the ti,sysc interconnect hierarachy. + have not been converted to the ti,sysc interconnect hierarchy. patternProperties: "^(.+-hog(-[0-9]+)?)$": diff --git a/Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt b/Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt deleted file mode 100644 index 038c3a6a1f4d..000000000000 --- a/Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt +++ /dev/null @@ -1,38 +0,0 @@ -Bindings for the Western Digital's MyBook Live memory-mapped GPIO controllers. - -The Western Digital MyBook Live has two memory-mapped GPIO controllers. -Both GPIO controller only have a single 8-bit data register, where GPIO -state can be read and/or written. - -Required properties: - - compatible: should be "wd,mbl-gpio" - - reg-names: must contain - "dat" - data register - - reg: address + size pairs describing the GPIO register sets; - order must correspond with the order of entries in reg-names - - #gpio-cells: must be set to 2. The first cell is the pin number and - the second cell is used to specify the gpio polarity: - 0 = active high - 1 = active low - - gpio-controller: Marks the device node as a gpio controller. - -Optional properties: - - no-output: GPIOs are read-only. - -Examples: - gpio0: gpio0@e0000000 { - compatible = "wd,mbl-gpio"; - reg-names = "dat"; - reg = <0xe0000000 0x1>; - #gpio-cells = <2>; - gpio-controller; - }; - - gpio1: gpio1@e0100000 { - compatible = "wd,mbl-gpio"; - reg-names = "dat"; - reg = <0xe0100000 0x1>; - #gpio-cells = <2>; - gpio-controller; - no-output; - }; diff --git a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml index 31906c253940..5eeb29bcdd21 100644 --- a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/gpio/x-powers,axp209-gpio.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/gpio/x-powers,axp209-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: X-Powers AXP209 GPIO @@ -44,6 +44,7 @@ patternProperties: - GPIO0 - GPIO1 - GPIO2 + - GPIO3 function: enum: diff --git a/Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml b/Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml index f333ee2288e7..c1060e5fcef3 100644 --- a/Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml +++ b/Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx AXI GPIO controller maintainers: - - Neeli Srinivas <srinivas.neeli@xilinx.com> + - Neeli Srinivas <srinivas.neeli@amd.com> description: The AXI GPIO design provides a general purpose input/output interface diff --git a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml index 31c0fc345903..56143f1fe84a 100644 --- a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml +++ b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: ZynqMP Mode Pin GPIO controller @@ -12,7 +12,7 @@ description: PS_MODE). Every pin can be configured as input/output. maintainers: - - Piyush Mehta <piyush.mehta@xilinx.com> + - Piyush Mehta <piyush.mehta@amd.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml b/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml index a36aec27069c..59c79a6943ec 100644 --- a/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Bootlin %YAML 1.2 --- -$id: "http://devicetree.org/schemas/gpio/xylon,logicvc-gpio.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/gpio/xylon,logicvc-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Xylon LogiCVC GPIO controller diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 0400a361875d..e796a1ff8c82 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -86,7 +86,7 @@ properties: const: 2 dynamic-power-coefficient: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: A u32 value that represents the running time dynamic power coefficient in units of uW/MHz/V^2. The diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml index 2a25384ca3ef..ca02baba5526 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml @@ -92,7 +92,7 @@ properties: dma-coherent: true dynamic-power-coefficient: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: A u32 value that represents the running time dynamic power coefficient in units of uW/MHz/V^2. The diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml index 318122d95eb5..0fae1ef013be 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,rk3228-mali - samsung,exynos4210-mali - stericsson,db8500-mali + - xlnx,zynqmp-mali - const: arm,mali-400 - items: - enum: diff --git a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml index 38478dad8b25..584cce3211c0 100644 --- a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml +++ b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/hwlock/allwinner,sun6i-a31-hwspinlock.yaml# diff --git a/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml index 0a955c7b9706..5ba60d532fcd 100644 --- a/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml +++ b/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/hwlock/ti,omap-hwspinlock.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml index ca2b47320689..2e45364d0543 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml @@ -27,7 +27,7 @@ properties: shunt-resistor-micro-ohms: description: - The value of curent sense resistor in microohms. If not provided, + The value of current sense resistor in microohms. If not provided, the current reading and overcurrent alert is disabled. adi,shutdown-threshold-microamp: diff --git a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml index 0cf3ed6212a6..6751f9b643b4 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml @@ -11,7 +11,7 @@ maintainers: - Nuno Sá <nuno.sa@analog.com> description: |+ - Bindings for the Analog Devices AXI FAN Control driver. Spefications of the + Bindings for the Analog Devices AXI FAN Control driver. Specifications of the core can be found in: https://wiki.analog.com/resources/fpga/docs/axi_fan_control diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml index b39c632956e8..0ad12d245656 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml @@ -46,7 +46,7 @@ patternProperties: shunt-resistor-micro-ohms: description: - The value of curent sense resistor in microohms. + The value of current sense resistor in microohms. required: - compatible diff --git a/Documentation/devicetree/bindings/hwmon/adi,max31827.yaml b/Documentation/devicetree/bindings/hwmon/adi,max31827.yaml new file mode 100644 index 000000000000..2dc8b07b4d3b --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/adi,max31827.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/adi,max31827.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices MAX31827, MAX31828, MAX31829 Low-Power Temperature Switch + +maintainers: + - Daniel Matyas <daniel.matyas@analog.com> + +description: | + Analog Devices MAX31827, MAX31828, MAX31829 Low-Power Temperature Switch with + I2C Interface + https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31827-MAX31829.pdf + +properties: + compatible: + oneOf: + - const: adi,max31827 + - items: + - enum: + - adi,max31828 + - adi,max31829 + - const: adi,max31827 + + reg: + maxItems: 1 + + vref-supply: + description: + Must have values in the interval (1.6V; 3.6V) in order for the device to + function correctly. + +required: + - compatible + - reg + - vref-supply + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + temperature-sensor@42 { + compatible = "adi,max31827"; + reg = <0x42>; + vref-supply = <®_vdd>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt index 3ac02988a1a5..8645cd3b867a 100644 --- a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt +++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt @@ -45,7 +45,7 @@ Required properties for each child node: - aspeed,fan-tach-ch : should specify the Fan tach input channel. integer value in the range 0 through 15, with 0 indicating Fan tach channel 0 and 15 indicating Fan tach channel 15. - Atleast one Fan tach input channel is required. + At least one Fan tach input channel is required. Examples: diff --git a/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml index c54b5986b365..e5b24782f448 100644 --- a/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml +++ b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/hwmon/iio-hwmon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: ADC-attached Hardware Sensor diff --git a/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml b/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml index 0e49b3901161..bf3332153ad8 100644 --- a/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml +++ b/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/hwmon/jedec,jc42.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml index b1a4c235376e..e62aff670478 100644 --- a/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml +++ b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/hwmon/lltc,ltc4151.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml b/Documentation/devicetree/bindings/hwmon/lm75.yaml index 8226e3b5d028..0b69897f0c63 100644 --- a/Documentation/devicetree/bindings/hwmon/lm75.yaml +++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/hwmon/lm75.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/lm87.txt b/Documentation/devicetree/bindings/hwmon/lm87.txt index e1b79903f204..758ff398b67b 100644 --- a/Documentation/devicetree/bindings/hwmon/lm87.txt +++ b/Documentation/devicetree/bindings/hwmon/lm87.txt @@ -18,7 +18,7 @@ optional properties: in7. Otherwise the pin is set as FAN2 input. - vcc-supply: a Phandle for the regulator supplying power, can be - cofigured to measure 5.0V power supply. Default is 3.3V. + configured to measure 5.0V power supply. Default is 3.3V. Example: diff --git a/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt index 33fd00a987c7..473b34c876dd 100644 --- a/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt +++ b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt @@ -1,4 +1,4 @@ -Lantiq cpu temperatur sensor +Lantiq cpu temperature sensor Requires node properties: - compatible value : diff --git a/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml index 028d6e570131..f5e104c1b0d0 100644 --- a/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml +++ b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/hwmon/microchip,mcp3021.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml index ae4f68d4e696..56db2292f062 100644 --- a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml +++ b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml @@ -42,7 +42,7 @@ properties: reg: items: - description: PVT common registers - - description: PVT temprature sensor registers + - description: PVT temperature sensor registers - description: PVT process detector registers - description: PVT voltage monitor registers @@ -105,7 +105,7 @@ properties: G coefficient for temperature equation. Default for series 5 = 60000 Default for series 6 = 57400 - multipleOf: 1000 + multipleOf: 100 minimum: 1000 $ref: /schemas/types.yaml#/definitions/uint32 @@ -114,7 +114,7 @@ properties: H coefficient for temperature equation. Default for series 5 = 200000 Default for series 6 = 249400 - multipleOf: 1000 + multipleOf: 100 minimum: 1000 $ref: /schemas/types.yaml#/definitions/uint32 @@ -131,7 +131,7 @@ properties: J coefficient for temperature equation. Default for series 5 = -100 Default for series 6 = 0 - multipleOf: 1000 + multipleOf: 100 maximum: 0 $ref: /schemas/types.yaml#/definitions/int32 diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml index 7b9d48d6d6da..6e59c8fdef30 100644 --- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/hwmon/national,lm90.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt index 28f43e929f6d..8523777f560c 100644 --- a/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt +++ b/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt @@ -23,7 +23,7 @@ Required properties for pwm-fan node fan subnode format: =================== Under fan subnode can be upto 8 child nodes, each child node representing a fan. -Each fan subnode must have one PWM channel and atleast one Fan tach channel. +Each fan subnode must have one PWM channel and at least one Fan tach channel. For PWM channel can be configured cooling-levels to create cooling device. Cooling device could be bound to a thermal zone for the thermal control. diff --git a/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml b/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml index 306f67315835..48d654e52114 100644 --- a/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml +++ b/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/hwmon/nxp,mc34vr500.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml index 80df7182ea28..14ac783c9a5f 100644 --- a/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml +++ b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/hwmon/sensirion,sht15.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml index 159238efa9ed..3d14d5fc96c5 100644 --- a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml +++ b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml @@ -13,7 +13,7 @@ description: | The SHTC1, SHTW1 and SHTC3 are digital humidity and temperature sensors designed especially for battery-driven high-volume consumer electronics applications. - For further information refere to Documentation/hwmon/shtc1.rst + For further information refer to Documentation/hwmon/shtc1.rst This binding document describes the binding for the hardware monitor portion of the driver. diff --git a/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml b/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml index f5b34528928d..733cba780186 100644 --- a/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml +++ b/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml @@ -27,8 +27,8 @@ properties: clock-names: items: - - const: "sense" - - const: "bus" + - const: sense + - const: bus '#thermal-sensor-cells': const: 0 @@ -39,8 +39,8 @@ properties: reset-names: items: - - const: "sense" - - const: "bus" + - const: sense + - const: bus required: - compatible diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml index c5a889e3e27b..7e5b62a0215d 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/hwmon/ti,tmp102.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml index dcbc6fbc3b48..8b5307c875ff 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/hwmon/ti,tmp108.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml index fde5225ce012..cdd1489e0c54 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml @@ -33,7 +33,7 @@ properties: shunt-resistor-micro-ohms: description: | - If 0, the calibration process will be skiped and the current and power + If 0, the calibration process will be skipped and the current and power measurement engine will not work. Temperature and voltage measurement will continue to work. The shunt value also need to respect: rshunt <= pga-gain * 40 * 1000 * 1000. diff --git a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml index bce68a326919..ebc8d466c1aa 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml @@ -26,7 +26,7 @@ properties: maxItems: 1 shunt-resistor-micro-ohms: - description: The value of curent sense resistor in microohms. + description: The value of current sense resistor in microohms. default: 255000 minimum: 250000 maximum: 255000 diff --git a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml index cb24d7b3221c..9f1d35ce1fe8 100644 --- a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml +++ b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence I2C controller maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> allOf: - $ref: /schemas/i2c/i2c-controller.yaml# @@ -48,6 +48,9 @@ properties: default: 16 enum: [2, 4, 8, 16, 32, 64, 128, 256] + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt deleted file mode 100644 index 548a73cde796..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt +++ /dev/null @@ -1,82 +0,0 @@ -GPIO-based I2C Arbitration Using a Challenge & Response Mechanism -================================================================= -This uses GPIO lines and a challenge & response mechanism to arbitrate who is -the master of an I2C bus in a multimaster situation. - -In many cases using GPIOs to arbitrate is not needed and a design can use -the standard I2C multi-master rules. Using GPIOs is generally useful in -the case where there is a device on the bus that has errata and/or bugs -that makes standard multimaster mode not feasible. - -Note that this scheme works well enough but has some downsides: -* It is nonstandard (not using standard I2C multimaster) -* Having two masters on a bus in general makes it relatively hard to debug - problems (hard to tell if i2c issues were caused by one master, another, or - some device on the bus). - - -Algorithm: - -All masters on the bus have a 'bus claim' line which is an output that the -others can see. These are all active low with pull-ups enabled. We'll -describe these lines as: - -- OUR_CLAIM: output from us signaling to other hosts that we want the bus -- THEIR_CLAIMS: output from others signaling that they want the bus - -The basic algorithm is to assert your line when you want the bus, then make -sure that the other side doesn't want it also. A detailed explanation is best -done with an example. - -Let's say we want to claim the bus. We: -1. Assert OUR_CLAIM. -2. Waits a little bit for the other sides to notice (slew time, say 10 - microseconds). -3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we are - done. -4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released. -5. If not, back off, release the claim and wait for a few more milliseconds. -6. Go back to 1 (until retry time has expired). - - -Required properties: -- compatible: i2c-arb-gpio-challenge -- our-claim-gpio: The GPIO that we use to claim the bus. -- their-claim-gpios: The GPIOs that the other sides use to claim the bus. - Note that some implementations may only support a single other master. -- I2C arbitration bus node. See i2c-arb.txt in this directory. - -Optional properties: -- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us. -- wait-retry-us: we'll attempt another claim after this many microseconds. - Default is 3000 us. -- wait-free-us: we'll give up after this many microseconds. Default is 50000 us. - - -Example: - i2c@12ca0000 { - compatible = "acme,some-i2c-device"; - #address-cells = <1>; - #size-cells = <0>; - }; - - i2c-arbitrator { - compatible = "i2c-arb-gpio-challenge"; - - i2c-parent = <&{/i2c@12CA0000}>; - - our-claim-gpio = <&gpf0 3 1>; - their-claim-gpios = <&gpe0 4 1>; - slew-delay-us = <10>; - wait-retry-us = <3000>; - wait-free-us = <50000>; - - i2c-arb { - #address-cells = <1>; - #size-cells = <0>; - - i2c@52 { - // Normal I2C device - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.yaml b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.yaml new file mode 100644 index 000000000000..b618b5a3433a --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-arb-gpio-challenge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO-based I2C Arbitration Using a Challenge & Response Mechanism + +maintainers: + - Doug Anderson <dianders@chromium.org> + - Peter Rosin <peda@axentia.se> + +description: | + This uses GPIO lines and a challenge & response mechanism to arbitrate who is + the master of an I2C bus in a multimaster situation. + + In many cases using GPIOs to arbitrate is not needed and a design can use the + standard I2C multi-master rules. Using GPIOs is generally useful in the case + where there is a device on the bus that has errata and/or bugs that makes + standard multimaster mode not feasible. + + Note that this scheme works well enough but has some downsides: + * It is nonstandard (not using standard I2C multimaster) + * Having two masters on a bus in general makes it relatively hard to debug + problems (hard to tell if i2c issues were caused by one master, another, + or some device on the bus). + + Algorithm: + All masters on the bus have a 'bus claim' line which is an output that the + others can see. These are all active low with pull-ups enabled. We'll + describe these lines as: + * OUR_CLAIM: output from us signaling to other hosts that we want the bus + * THEIR_CLAIMS: output from others signaling that they want the bus + + The basic algorithm is to assert your line when you want the bus, then make + sure that the other side doesn't want it also. A detailed explanation is + best done with an example. + + Let's say we want to claim the bus. We: + 1. Assert OUR_CLAIM. + 2. Waits a little bit for the other sides to notice (slew time, say 10 + microseconds). + 3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we + are done. + 4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released. + 5. If not, back off, release the claim and wait for a few more milliseconds. + 6. Go back to 1 (until retry time has expired). + +properties: + compatible: + const: i2c-arb-gpio-challenge + + i2c-parent: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The I2C bus that this multiplexer's master-side port is connected to. + + our-claim-gpios: + maxItems: 1 + description: + The GPIO that we use to claim the bus. + + slew-delay-us: + default: 10 + description: + Time to wait for a GPIO to go high. + + their-claim-gpios: + minItems: 1 + maxItems: 8 + description: + The GPIOs that the other sides use to claim the bus. Note that some + implementations may only support a single other master. + + wait-free-us: + default: 50000 + description: + We'll give up after this many microseconds. + + wait-retry-us: + default: 3000 + description: + We'll attempt another claim after this many microseconds. + + i2c-arb: + type: object + $ref: /schemas/i2c/i2c-controller.yaml + unevaluatedProperties: false + description: + I2C arbitration bus node. + +required: + - compatible + - i2c-arb + - our-claim-gpios + - their-claim-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c-arbitrator { + compatible = "i2c-arb-gpio-challenge"; + i2c-parent = <&i2c_4>; + + our-claim-gpios = <&gpf0 3 GPIO_ACTIVE_LOW>; + their-claim-gpios = <&gpe0 4 GPIO_ACTIVE_LOW>; + slew-delay-us = <10>; + wait-retry-us = <3000>; + wait-free-us = <50000>; + + i2c-arb { + #address-cells = <1>; + #size-cells = <0>; + + sbs-battery@b { + compatible = "sbs,sbs-battery"; + reg = <0xb>; + sbs,poll-retry-count = <1>; + }; + + embedded-controller@1e { + compatible = "google,cros-ec-i2c"; + reg = <0x1e>; + interrupts = <6 IRQ_TYPE_LEVEL_HIGH>; + interrupt-parent = <&gpx1>; + pinctrl-names = "default"; + pinctrl-0 = <&ec_irq>; + wakeup-source; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb.txt b/Documentation/devicetree/bindings/i2c/i2c-arb.txt deleted file mode 100644 index 59abf9277bdc..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-arb.txt +++ /dev/null @@ -1,35 +0,0 @@ -Common i2c arbitration bus properties. - -- i2c-arb child node - -Required properties for the i2c-arb child node: -- #address-cells = <1>; -- #size-cells = <0>; - -Optional properties for i2c-arb child node: -- Child nodes conforming to i2c bus binding - - -Example : - - /* - An NXP pca9541 I2C bus master selector at address 0x74 - with a NXP pca8574 GPIO expander attached. - */ - - arb@74 { - compatible = "nxp,pca9541"; - reg = <0x74>; - - i2c-arb { - #address-cells = <1>; - #size-cells = <0>; - - gpio@38 { - compatible = "nxp,pca8574"; - reg = <0x38>; - #gpio-cells = <2>; - gpio-controller; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-atr.yaml b/Documentation/devicetree/bindings/i2c/i2c-atr.yaml new file mode 100644 index 000000000000..1939ab339bfc --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-atr.yaml @@ -0,0 +1,34 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-atr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common i2c address translator properties + +maintainers: + - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> + +description: + An I2C Address Translator (ATR) is a device with an I2C slave parent + ("upstream") port and N I2C master child ("downstream") ports, and + forwards transactions from upstream to the appropriate downstream port + with a modified slave address. The address used on the parent bus is + called the "alias" and is (potentially) different from the physical + slave address of the child bus. Address translation is done by the + hardware. + +properties: + i2c-alias-pool: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + I2C alias pool is a pool of I2C addresses on the main I2C bus that can be + used to access the remote peripherals on the serializer's I2C bus. The + addresses must be available, not used by any other peripheral. Each + remote peripheral is assigned an alias from the pool, and transactions to + that address will be forwarded to the remote peripheral, with the address + translated to the remote peripheral's real address. This property is not + needed if there are no I2C addressable remote peripherals. + +additionalProperties: true +... diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml index 9f1726d0356b..2d7bb998b0e9 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml @@ -4,21 +4,29 @@ $id: http://devicetree.org/schemas/i2c/i2c-mux-pca954x.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: NXP PCA954x I2C bus switch +title: NXP PCA954x I2C and compatible bus switches maintainers: - Laurent Pinchart <laurent.pinchart@ideasonboard.com> description: - The binding supports NXP PCA954x and PCA984x I2C mux/switch devices. - -allOf: - - $ref: /schemas/i2c/i2c-mux.yaml# + The NXP PCA954x and compatible devices are I2C bus + multiplexer/switches that share the same functionality + and register layout. + The devices usually have 4 or 8 child buses, which are + attached to the parent bus by using the SMBus "Send Byte" + command. properties: compatible: oneOf: - enum: + - maxim,max7356 + - maxim,max7357 + - maxim,max7358 + - maxim,max7367 + - maxim,max7368 + - maxim,max7369 - nxp,pca9540 - nxp,pca9542 - nxp,pca9543 @@ -59,10 +67,34 @@ properties: description: if present, overrides i2c-mux-idle-disconnect $ref: /schemas/mux/mux-controller.yaml#/properties/idle-state + vdd-supply: + description: A voltage regulator supplying power to the chip. On PCA9846 + the regulator supplies power to VDD2 (core logic) and optionally to VDD1. + required: - compatible - reg +allOf: + - $ref: /schemas/i2c/i2c-mux.yaml# + - if: + not: + properties: + compatible: + contains: + enum: + - maxim,max7367 + - maxim,max7369 + - nxp,pca9542 + - nxp,pca9543 + - nxp,pca9544 + - nxp,pca9545 + then: + properties: + interrupts: false + "#interrupt-cells": false + interrupt-controller: false + unevaluatedProperties: false examples: @@ -74,11 +106,13 @@ examples: #size-cells = <0>; i2c-mux@74 { - compatible = "nxp,pca9548"; + compatible = "nxp,pca9545"; #address-cells = <1>; #size-cells = <0>; reg = <0x74>; + vdd-supply = <&p3v3>; + interrupt-parent = <&ipic>; interrupts = <17 IRQ_TYPE_LEVEL_LOW>; interrupt-controller; diff --git a/Documentation/devicetree/bindings/i2c/i2c-sprd.txt b/Documentation/devicetree/bindings/i2c/i2c-sprd.txt index 60b7cda15dd2..7b6b3b8d0d11 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-sprd.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-sprd.txt @@ -10,7 +10,7 @@ Required properties: "source" for I2C source (parent) clock, "enable" for I2C module enable clock. - clocks: Should contain a clock specifier for each entry in clock-names. -- clock-frequency: Constains desired I2C bus clock frequency in Hz. +- clock-frequency: Contains desired I2C bus clock frequency in Hz. - #address-cells: Should be 1 to describe address cells for I2C device address. - #size-cells: Should be 0 means no size cell for I2C device address. diff --git a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt b/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt deleted file mode 100644 index 42bfc09c8918..000000000000 --- a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt +++ /dev/null @@ -1,29 +0,0 @@ -* NXP PCA9541 I2C bus master selector - -Required Properties: - - - compatible: Must be "nxp,pca9541" - - - reg: The I2C address of the device. - - The following required properties are defined externally: - - - I2C arbitration bus node. See i2c-arb.txt in this directory. - - -Example: - - i2c-arbitrator@74 { - compatible = "nxp,pca9541"; - reg = <0x74>; - - i2c-arb { - #address-cells = <1>; - #size-cells = <0>; - - eeprom@54 { - compatible = "atmel,24c08"; - reg = <0x54>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/nxp,pca9541.yaml b/Documentation/devicetree/bindings/i2c/nxp,pca9541.yaml new file mode 100644 index 000000000000..b65c25c1a435 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/nxp,pca9541.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/nxp,pca9541.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP PCA9541 I2C bus master selector + +maintainers: + - Peter Rosin <peda@axentia.se> + +properties: + compatible: + const: nxp,pca9541 + + reg: + maxItems: 1 + + i2c-arb: + type: object + $ref: /schemas/i2c/i2c-controller.yaml + unevaluatedProperties: false + description: + I2C arbitration bus node. + +required: + - compatible + - reg + - i2c-arb + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + i2c-arbitrator@74 { + compatible = "nxp,pca9541"; + reg = <0x74>; + + i2c-arb { + #address-cells = <1>; + #size-cells = <0>; + + eeprom@54 { + compatible = "atmel,24c08"; + reg = <0x54>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml index c002afdbfc7c..5dda8cb44cdb 100644 --- a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml +++ b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/i3c/mipi-i3c-hci.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/i3c/mipi-i3c-hci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MIPI I3C HCI diff --git a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml index 32c821f97779..133855f11b4f 100644 --- a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml +++ b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml @@ -10,7 +10,7 @@ maintainers: - Conor Culhane <conor.culhane@silvaco.com> allOf: - - $ref: "i3c.yaml#" + - $ref: i3c.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml index c8659c5eba2a..cb31e75ba680 100644 --- a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml +++ b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml @@ -36,8 +36,8 @@ properties: maxItems: 2 items: enum: - - "INT1" - - "INT2" + - INT1 + - INT2 required: - compatible diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml index d521d516088b..16def2985ab4 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml @@ -47,6 +47,9 @@ properties: avdd-supply: description: AVdd voltage supply + vref-supply: + description: VRef voltage supply + adi,rejection-60-Hz-enable: description: | This bit enables a notch at 60 Hz when the first notch of the sinc @@ -89,6 +92,7 @@ required: - interrupts - dvdd-supply - avdd-supply + - vref-supply - spi-cpol - spi-cpha @@ -115,6 +119,7 @@ examples: interrupt-parent = <&gpio>; dvdd-supply = <&dvdd>; avdd-supply = <&avdd>; + vref-supply = <&vref>; adi,refin2-pins-enable; adi,rejection-60-Hz-enable; diff --git a/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml b/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml new file mode 100644 index 000000000000..7ef46c90ebc8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/allwinner,sun20i-d1-gpadc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner D1 General Purpose ADC + +maintainers: + - Maksim Kiselev <bigunclemax@gmail.com> + +properties: + compatible: + enum: + - allwinner,sun20i-d1-gpadc + + "#io-channel-cells": + const: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + resets: + maxItems: 1 + +patternProperties: + "^channel@[0-9a-f]+$": + $ref: adc.yaml + type: object + description: + Represents the internal channels of the ADC. + + properties: + reg: + items: + minimum: 0 + maximum: 15 + + required: + - reg + + unevaluatedProperties: false + +required: + - "#io-channel-cells" + - clocks + - compatible + - interrupts + - reg + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/sun20i-d1-ccu.h> + #include <dt-bindings/reset/sun20i-d1-ccu.h> + #include <dt-bindings/interrupt-controller/irq.h> + + gpadc: adc@2009000 { + compatible = "allwinner,sun20i-d1-gpadc"; + reg = <0x2009000 0x400>; + clocks = <&ccu CLK_BUS_GPADC>; + resets = <&ccu RST_BUS_GPADC>; + interrupts = <73 IRQ_TYPE_LEVEL_HIGH>; + #io-channel-cells = <1>; + + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + }; + + channel@1 { + reg = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml index e6a1f915b542..1f30a8569187 100644 --- a/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml @@ -56,8 +56,8 @@ properties: String corresponding to an identifier from atmel,adc-res-names property. If not specified, the highest resolution will be used. enum: - - "lowres" - - "highres" + - lowres + - highres atmel,adc-sleep-mode: $ref: /schemas/types.yaml#/definitions/flag diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml index 7f79a06e76f5..6168b44ea72c 100644 --- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt2712-auxadc - mediatek,mt6765-auxadc - mediatek,mt7622-auxadc + - mediatek,mt7986-auxadc - mediatek,mt8173-auxadc - items: - enum: diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml index bd6e0d6f6e0c..ad7d6fc49de5 100644 --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml @@ -54,7 +54,7 @@ required: - '#io-channel-cells' patternProperties: - "^.*@[0-9a-f]+$": + "^channel@[0-9a-f]+$": type: object additionalProperties: false description: | @@ -101,7 +101,7 @@ patternProperties: oneOf: - items: - const: 1 - - enum: [ 1, 3, 4, 6, 20, 8, 10 ] + - enum: [ 1, 3, 4, 6, 20, 8, 10, 16 ] - items: - const: 10 - const: 81 @@ -148,7 +148,7 @@ allOf: then: patternProperties: - "^.*@[0-9a-f]+$": + "^channel@[0-9a-f]+$": properties: qcom,decimation: enum: [ 512, 1024, 2048, 4096 ] @@ -171,7 +171,7 @@ allOf: then: patternProperties: - "^.*@[0-9a-f]+$": + "^channel@[0-9a-f]+$": properties: qcom,decimation: enum: [ 256, 512, 1024 ] @@ -194,7 +194,7 @@ allOf: then: patternProperties: - "^.*@[0-9a-f]+$": + "^channel@[0-9a-f]+$": properties: qcom,decimation: enum: [ 250, 420, 840 ] @@ -217,7 +217,7 @@ allOf: then: patternProperties: - "^.*@[0-9a-f]+$": + "^channel@[0-9a-f]+$": properties: qcom,decimation: enum: [ 85, 340, 1360 ] @@ -249,7 +249,7 @@ examples: #io-channel-cells = <1>; /* Channel node */ - adc-chan@39 { + channel@39 { reg = <0x39>; qcom,decimation = <512>; qcom,ratiometric; @@ -258,19 +258,19 @@ examples: qcom,pre-scaling = <1 3>; }; - adc-chan@9 { + channel@9 { reg = <0x9>; }; - adc-chan@a { + channel@a { reg = <0xa>; }; - adc-chan@e { + channel@e { reg = <0xe>; }; - adc-chan@f { + channel@f { reg = <0xf>; }; }; @@ -292,16 +292,18 @@ examples: #io-channel-cells = <1>; /* Other properties are omitted */ - xo-therm@44 { + channel@44 { reg = <PMK8350_ADC7_AMUX_THM1_100K_PU>; qcom,ratiometric; qcom,hw-settle-time = <200>; + label = "xo_therm"; }; - conn-therm@47 { + channel@47 { reg = <PM8350_ADC7_AMUX_THM4_100K_PU(1)>; qcom,ratiometric; qcom,hw-settle-time = <200>; + label = "conn_therm"; }; }; }; diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml index da50b529c157..aa24b841393c 100644 --- a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml @@ -15,6 +15,7 @@ properties: - const: rockchip,saradc - const: rockchip,rk3066-tsadc - const: rockchip,rk3399-saradc + - const: rockchip,rk3588-saradc - items: - enum: - rockchip,px30-saradc diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml index 9b072b057f16..a60b1e100ee4 100644 --- a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml @@ -35,7 +35,7 @@ unevaluatedProperties: false examples: - | spi { - #address-cells= <1>; + #address-cells = <1>; #size-cells = <0>; adc@0 { diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml index 2127d639a768..e004659099c1 100644 --- a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml @@ -78,9 +78,9 @@ patternProperties: ti,datarate: $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 - maximum: 6 + maximum: 7 description: | - Data acquisition rate in samples per second + Data acquisition rate in samples per second for ADS1015, TLA2024 0: 128 1: 250 2: 490 @@ -88,6 +88,17 @@ patternProperties: 4: 1600 (default) 5: 2400 6: 3300 + 7: 3300 + + Data acquisition rate in samples per second for ADS1115 + 0: 8 + 1: 16 + 2: 32 + 3: 64 + 4: 128 (default) + 5: 250 + 6: 475 + 7: 860 required: - reg diff --git a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml index be93c109d6ac..8cbad7e792b6 100644 --- a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml +++ b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml @@ -57,7 +57,7 @@ description: | |27 |FPD Internal voltage measurement, VCC_PSINTFP (supply5). |Voltage |28 |PS Auxiliary voltage measurement (supply6). |Voltage |29 |PL VCCADC voltage measurement (vccams). |Voltage - |30 |Differential analog input signal voltage measurment. |Voltage + |30 |Differential analog input signal voltage measurement. |Voltage |31 |VUser0 voltage measurement (supply7). |Voltage |32 |VUser1 voltage measurement (supply8). |Voltage |33 |VUser2 voltage measurement (supply9). |Voltage diff --git a/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml b/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml index 72d2e910f206..2594fa192f93 100644 --- a/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml +++ b/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml @@ -216,7 +216,6 @@ properties: description: Whether to enable burnout current for EXT1. adi,ext1-burnout-current-nanoamp: - $ref: /schemas/types.yaml#/definitions/uint32 description: Burnout current in nanoamps to be applied to EXT1. enum: [0, 50, 500, 1000, 10000] @@ -233,7 +232,6 @@ properties: description: Whether to enable burnout current for EXT2. adi,ext2-burnout-current-nanoamp: - $ref: /schemas/types.yaml#/definitions/uint32 description: Burnout current in nanoamps to be applied to EXT2. enum: [0, 50, 500, 1000, 10000] default: 0 @@ -249,7 +247,6 @@ properties: description: Whether to enable burnout current for VIOUT. adi,viout-burnout-current-nanoamp: - $ref: /schemas/types.yaml#/definitions/uint32 description: Burnout current in nanoamps to be applied to VIOUT. enum: [0, 1000, 10000] default: 0 diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml index df2589f214e1..dddf97b50549 100644 --- a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml +++ b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml @@ -13,7 +13,7 @@ description: | When an io-channel measures the midpoint of a voltage divider, the interesting voltage is often the voltage over the full resistance of the divider. This binding describes the voltage divider in such - a curcuit. + a circuit. Vin ----. | diff --git a/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml b/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml index 2155d3f5666c..3d7074fd17be 100644 --- a/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml +++ b/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/iio/cdc/adi,ad7150.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Analog device AD7150 and similar capacitance to digital convertors. +title: Analog device AD7150 and similar capacitance to digital converters. maintainers: - Jonathan Cameron <jic23@kernel.org> diff --git a/Documentation/devicetree/bindings/iio/common.yaml b/Documentation/devicetree/bindings/iio/common.yaml index f845b41d74c4..b3a10af86d76 100644 --- a/Documentation/devicetree/bindings/iio/common.yaml +++ b/Documentation/devicetree/bindings/iio/common.yaml @@ -12,7 +12,7 @@ maintainers: description: | This document defines device tree properties common to several iio - sensors. It doesn't constitue a device tree binding specification by itself but + sensors. It doesn't constitute a device tree binding specification by itself but is meant to be referenced by device tree bindings. When referenced from sensor tree bindings the properties defined in this diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp4728.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4728.yaml new file mode 100644 index 000000000000..99831d7f1c16 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4728.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/iio/dac/microchip,mcp4728.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MCP4728 DAC + +maintainers: + - Andrea Collamati <andrea.collamati@gmail.com> + +description: | + MCP4728 is a quad channel, 12-bit voltage output + Digital-to-Analog Converter with non-volatile + memory and I2C compatible Serial Interface. + https://www.microchip.com/en-us/product/mcp4728 + +properties: + compatible: + const: microchip,mcp4728 + + reg: + maxItems: 1 + + vdd-supply: + description: | + Provides both power and acts as the reference supply on the MCP4728 + when Internal Vref is not selected. + +required: + - compatible + - reg + - vdd-supply + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + dac@60 { + compatible = "microchip,mcp4728"; + reg = <0x60>; + vdd-supply = <&vdac_vdd>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml index fc813bcb6532..f2eb2287ed9e 100644 --- a/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml +++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml @@ -39,6 +39,46 @@ properties: description: Analog voltage regulator. + vcc-drv-supply: + description: + RF Driver voltage regulator. + + vcc2-drv-supply: + description: + RF predriver voltage regulator. + + vcc-vva-supply: + description: + VVA Control Circuit voltage regulator. + + vcc-amp1-supply: + description: + RF Amplifier 1 voltage regulator. + + vcc-amp2-supply: + description: + RF Amplifier 2 voltage regulator. + + vcc-env-supply: + description: + Envelope Detector voltage regulator. + + vcc-bg-supply: + description: + Mixer Chip Band Gap Circuit voltage regulator. + + vcc-bg2-supply: + description: + VGA Chip Band Gap Circuit voltage regulator. + + vcc-mixer-supply: + description: + Mixer voltage regulator. + + vcc-quad-supply: + description: + Quadruppler voltage regulator. + adi,detector-enable: description: Enable the Envelope Detector available at output pins VENV_P and @@ -69,6 +109,16 @@ required: - clocks - clock-names - vcm-supply + - vcc-drv-supply + - vcc2-drv-supply + - vcc-vva-supply + - vcc-amp1-supply + - vcc-amp2-supply + - vcc-env-supply + - vcc-bg-supply + - vcc-bg2-supply + - vcc-mixer-supply + - vcc-quad-supply allOf: - $ref: /schemas/spi/spi-peripheral-props.yaml# @@ -87,6 +137,16 @@ examples: clocks = <&admv1013_lo>; clock-names = "lo_in"; vcm-supply = <&vcm>; + vcc-drv-supply = <&vcc_drv>; + vcc2-drv-supply = <&vcc2_drv>; + vcc-vva-supply = <&vcc_vva>; + vcc-amp1-supply = <&vcc_amp1>; + vcc-amp2-supply = <&vcc_amp2>; + vcc-env-supply = <&vcc_env>; + vcc-bg-supply = <&vcc_bg>; + vcc-bg2-supply = <&vcc_bg2>; + vcc-mixer-supply = <&vcc_mixer>; + vcc-quad-supply = <&vcc_quad>; adi,quad-se-mode = "diff"; adi,detector-enable; }; diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml index ab86daa2c56e..39cc63a11762 100644 --- a/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml +++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml @@ -33,7 +33,7 @@ properties: items: - const: lo_in description: - External clock that provides the Local Oscilator input. + External clock that provides the Local Oscillator input. vcm-supply: description: @@ -103,6 +103,14 @@ required: - clocks - clock-names - vcm-supply + - vcc-if-bb-supply + - vcc-vga-supply + - vcc-vva-supply + - vcc-lna-3p3-supply + - vcc-lna-1p5-supply + - vcc-bg-supply + - vcc-quad-supply + - vcc-mixer-supply allOf: - $ref: /schemas/spi/spi-peripheral-props.yaml# diff --git a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml index a2bc1fa92da0..79e75a8675cb 100644 --- a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml +++ b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml @@ -10,7 +10,7 @@ maintainers: - Eugene Zaikonnikov <ez@norophonic.com> description: | - Relative humidity and tempereature sensors on I2C bus + Relative humidity and temperature sensors on I2C bus Datasheets are available at: http://www.ti.com/product/HDC2010/datasheet diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml index ec64d7877fe5..1db6952ddca5 100644 --- a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml +++ b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml @@ -31,6 +31,9 @@ properties: - invensense,mpu9250 - invensense,mpu9255 - items: + - const: invensense,icm20600 + - const: invensense,icm20602 + - items: - const: invensense,icm20608d - const: invensense,icm20608 diff --git a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml index b39f5217d8ff..ee8724ad33ab 100644 --- a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml +++ b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml @@ -98,6 +98,7 @@ required: - reg allOf: + - $ref: /schemas/iio/iio.yaml# - $ref: /schemas/spi/spi-peripheral-props.yaml# unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bu27008.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bu27008.yaml new file mode 100644 index 000000000000..4f66fd47b016 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/rohm,bu27008.yaml @@ -0,0 +1,49 @@ +# 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 new file mode 100644 index 000000000000..8376d64a641a --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/rohm,bu27010.yaml @@ -0,0 +1,49 @@ +# 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>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/light/ti,opt4001.yaml b/Documentation/devicetree/bindings/iio/light/ti,opt4001.yaml new file mode 100644 index 000000000000..12b0c7ed5d72 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/ti,opt4001.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/ti,opt4001.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments OPT4001 Ambient Light Sensor + +maintainers: + - Stefan Windfeldt-Prytz <stefan.windfeldt-prytz@axis.com> + +description: + Ambient light sensor with an i2c interface. + Last part of compatible is for the packaging used. + Picostar is a 4 pinned SMT and sot-5x3 is a 8 pinned SOT. + https://www.ti.com/lit/gpn/opt4001 + +properties: + compatible: + enum: + - ti,opt4001-picostar + - ti,opt4001-sot-5x3 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vdd-supply: + description: Regulator that provides power to the sensor + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: ti,opt4001-sot-5x3 + then: + properties: + interrupts: + maxItems: 1 + else: + properties: + interrupts: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + light-sensor@44 { + compatible = "ti,opt4001-sot-5x3"; + reg = <0x44>; + vdd-supply = <&vdd_reg>; + interrupt-parent = <&gpio1>; + interrupts = <28 IRQ_TYPE_EDGE_FALLING>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/potentiometer/renesas,x9250.yaml b/Documentation/devicetree/bindings/iio/potentiometer/renesas,x9250.yaml new file mode 100644 index 000000000000..ab5c09c00ff4 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/potentiometer/renesas,x9250.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/potentiometer/renesas,x9250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas X9250 quad potentiometers + +maintainers: + - Herve Codina <herve.codina@bootlin.com> + +description: + The Renesas X9250 integrates four digitally controlled potentiometers. + On each potentiometer, the X9250T has a 100 kOhms total resistance and the + X9250U has a 50 kOhms total resistance. + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml + +properties: + compatible: + enum: + - renesas,x9250t + - renesas,x9250u + + reg: + maxItems: 1 + + vcc-supply: + description: + Regulator for the VCC power supply. + + avp-supply: + description: + Regulator for the analog V+ power supply. + + avn-supply: + description: + Regulator for the analog V- power supply. + + '#io-channel-cells': + const: 1 + + spi-max-frequency: + maximum: 2000000 + + wp-gpios: + maxItems: 1 + description: + GPIO connected to the write-protect pin. + +required: + - compatible + - reg + - vcc-supply + - avp-supply + - avn-supply + - '#io-channel-cells' + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + potentiometer@0 { + compatible = "renesas,x9250t"; + reg = <0>; + vcc-supply = <&vcc_regulator>; + avp-supply = <&avp_regulator>; + avn-supply = <&avp_regulator>; + wp-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + spi-max-frequency = <2000000>; + #io-channel-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml new file mode 100644 index 000000000000..b31f8120f14e --- /dev/null +++ b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/pressure/honeywell,mprls0025pa.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Honeywell mprls0025pa pressure sensor + +maintainers: + - Andreas Klinger <ak@it-klinger.de> + +description: | + Honeywell pressure sensor of model mprls0025pa. + + This sensor has an I2C and SPI interface. Only the I2C interface is + implemented. + + There are many models with different pressure ranges available. The vendor + calls them "mpr series". All of them have the identical programming model and + differ in the pressure range, unit and transfer function. + + To support different models one need to specify the pressure range as well as + the transfer function. Pressure range needs to be converted from its unit to + pascal. + + The transfer function defines the ranges of numerical values delivered by the + sensor. The minimal range value stands for the minimum pressure and the + maximum value also for the maximum pressure with linear relation inside the + range. + + Specifications about the devices can be found at: + https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/ + products/sensors/pressure-sensors/board-mount-pressure-sensors/ + micropressure-mpr-series/documents/ + sps-siot-mpr-series-datasheet-32332628-ciid-172626.pdf + +properties: + compatible: + const: honeywell,mprls0025pa + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + reset-gpios: + description: + Optional GPIO for resetting the device. + If not present the device is not reset during the probe. + maxItems: 1 + + honeywell,pmin-pascal: + description: + Minimum pressure value the sensor can measure in pascal. + $ref: /schemas/types.yaml#/definitions/uint32 + + honeywell,pmax-pascal: + description: + Maximum pressure value the sensor can measure in pascal. + $ref: /schemas/types.yaml#/definitions/uint32 + + honeywell,transfer-function: + description: | + Transfer function which defines the range of valid values delivered by the + sensor. + 1 - A, 10% to 90% of 2^24 (1677722 .. 15099494) + 2 - B, 2.5% to 22.5% of 2^24 (419430 .. 3774874) + 3 - C, 20% to 80% of 2^24 (3355443 .. 13421773) + $ref: /schemas/types.yaml#/definitions/uint32 + + vdd-supply: + description: provide VDD power to the sensor. + +required: + - compatible + - reg + - honeywell,pmin-pascal + - honeywell,pmax-pascal + - honeywell,transfer-function + - vdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pressure@18 { + compatible = "honeywell,mprls0025pa"; + reg = <0x18>; + reset-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>; + interrupt-parent = <&gpio3>; + interrupts = <21 IRQ_TYPE_EDGE_FALLING>; + honeywell,pmin-pascal = <0>; + honeywell,pmax-pascal = <172369>; + honeywell,transfer-function = <1>; + vdd-supply = <&vcc_3v3>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml b/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml index c999994e19e3..9567993ce480 100644 --- a/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml @@ -10,7 +10,7 @@ maintainers: - Matt Ranostay <matt.ranostay@konsulko.com> description: - This lightening distance sensor uses an I2C or SPI interface. The + This lightning distance sensor uses an I2C or SPI interface. The binding currently only covers the SPI option. properties: diff --git a/Documentation/devicetree/bindings/iio/proximity/murata,irsd200.yaml b/Documentation/devicetree/bindings/iio/proximity/murata,irsd200.yaml new file mode 100644 index 000000000000..67f5389ece67 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/proximity/murata,irsd200.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/proximity/murata,irsd200.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Murata IRS-D200 PIR sensor + +maintainers: + - Waqar Hameed <waqar.hameed@axis.com> + +description: + PIR sensor for human detection. + +properties: + compatible: + const: murata,irsd200 + + reg: + items: + - enum: + - 0x48 + - 0x49 + description: | + When the AD pin is connected to GND, the slave address is 0x48. + When the AD pin is connected to VDD, the slave address is 0x49. + + interrupts: + maxItems: 1 + description: + Type should be IRQ_TYPE_EDGE_RISING. + + vdd-supply: + description: + 3.3 V supply voltage. + +required: + - compatible + - reg + - interrupts + - vdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + proximity@48 { + compatible = "murata,irsd200"; + reg = <0x48>; + interrupts = <24 IRQ_TYPE_EDGE_RISING>; + vdd-supply = <®ulator_3v3>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml index 5de0bb2180e6..775555d147bf 100644 --- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml @@ -15,6 +15,9 @@ description: | Specifications about the devices can be found at: https://www.semtech.com/products/smart-sensing/sar-sensors/sx9310 +allOf: + - $ref: /schemas/iio/iio.yaml# + properties: compatible: enum: @@ -102,7 +105,7 @@ required: - reg - "#io-channel-cells" -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml index b3aa2ebf9661..48f221463166 100644 --- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml @@ -13,6 +13,9 @@ maintainers: description: | Semtech's SX9324 proximity sensor. +allOf: + - $ref: /schemas/iio/iio.yaml# + properties: compatible: const: semtech,sx9324 @@ -167,7 +170,7 @@ required: - reg - "#io-channel-cells" -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml index 1ff3afca9149..fff7e3d83a02 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -84,6 +84,7 @@ properties: - st,lps35hw - description: IMUs enum: + - st,lsm303d-imu - st,lsm9ds0-imu - description: Deprecated bindings enum: @@ -96,7 +97,7 @@ properties: interrupts: description: interrupt line(s) connected to the DRDY line(s) and/or the - Intertial interrupt lines INT1 and INT2 if these exist. This means up to + Inertial interrupt lines INT1 and INT2 if these exist. This means up to three interrupts, and the DRDY must be the first one if it exists on the package. The trigger edge of the interrupts is sometimes software configurable in the hardware so the operating system should parse this diff --git a/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml index d6965a0c1cf3..654d31f65d36 100644 --- a/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml +++ b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/iio/temperature/melexis,mlx90614.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Melexis MLX90614 contactless IR temperature sensor +title: Melexis MLX90614/MLX90615 contactless IR temperature sensor maintainers: - Peter Meerwald <pmeerw@pmeerw.net> @@ -15,7 +15,9 @@ description: | properties: compatible: - const: melexis,mlx90614 + enum: + - melexis,mlx90614 + - melexis,mlx90615 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/temperature/ti,tmp006.yaml b/Documentation/devicetree/bindings/iio/temperature/ti,tmp006.yaml new file mode 100644 index 000000000000..d43002b9bfdc --- /dev/null +++ b/Documentation/devicetree/bindings/iio/temperature/ti,tmp006.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/temperature/ti,tmp006.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI TMP006 IR thermopile sensor + +maintainers: + - Peter Meerwald <pmeerw@pmeerw.net> + +description: | + TI TMP006 - Infrared Thermopile Sensor in Chip-Scale Package. + https://cdn.sparkfun.com/datasheets/Sensors/Temp/tmp006.pdf + +properties: + compatible: + const: ti,tmp006 + + reg: + maxItems: 1 + + vdd-supply: + description: provide VDD power to the sensor. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + temperature-sensor@40 { + compatible = "ti,tmp006"; + reg = <0x40>; + vdd-supply = <&ldo4_reg>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/elan,ekth3000.yaml b/Documentation/devicetree/bindings/input/elan,ekth3000.yaml index 2a9bb6ace021..24dc2d69613f 100644 --- a/Documentation/devicetree/bindings/input/elan,ekth3000.yaml +++ b/Documentation/devicetree/bindings/input/elan,ekth3000.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/input/elan,ekth3000.yaml# diff --git a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml index 05e6f2df604c..3e2d216c6432 100644 --- a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml +++ b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml @@ -13,6 +13,9 @@ description: Supports the Elan eKTH6915 touchscreen controller. This touchscreen controller uses the i2c-hid protocol with a reset GPIO. +allOf: + - $ref: /schemas/input/touchscreen/touchscreen.yaml# + properties: compatible: items: @@ -24,6 +27,8 @@ properties: interrupts: maxItems: 1 + panel: true + reset-gpios: description: Reset GPIO; not all touchscreens using eKTH6915 hook this up. diff --git a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml index ce18d7dadae2..358cb8275bf1 100644 --- a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml +++ b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml @@ -14,6 +14,9 @@ description: This touchscreen uses the i2c-hid protocol but has some non-standard power sequencing required. +allOf: + - $ref: /schemas/input/touchscreen/touchscreen.yaml# + properties: compatible: oneOf: @@ -30,6 +33,8 @@ properties: interrupts: maxItems: 1 + panel: true + reset-gpios: true @@ -43,6 +48,15 @@ properties: itself as long as it allows the main board to make signals compatible with what the touchscreen is expecting for its IO rails. + goodix,no-reset-during-suspend: + description: + Set this to true to enforce the driver to not assert the reset GPIO + during suspend. + Due to potential touchscreen hardware flaw, back-powering could happen in + suspend if the power supply is on and with active-low reset GPIO asserted. + This property is used to avoid the back-powering issue. + type: boolean + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.yaml b/Documentation/devicetree/bindings/input/hid-over-i2c.yaml index 7156b08f7645..138caad96a29 100644 --- a/Documentation/devicetree/bindings/input/hid-over-i2c.yaml +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.yaml @@ -44,6 +44,8 @@ properties: description: HID descriptor address $ref: /schemas/types.yaml#/definitions/uint32 + panel: true + post-power-on-delay-ms: description: Time required by the device after enabling its regulators or powering it on, before it is ready for communication. diff --git a/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml new file mode 100644 index 000000000000..c5d9e0e919f9 --- /dev/null +++ b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/ilitek,ili9882t.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ilitek ili9882t touchscreen controller + +maintainers: + - Cong Yang <yangcong5@huaqin.corp-partner.google.com> + +description: + Supports the Ilitek ili9882t touchscreen controller. + This touchscreen controller uses the i2c-hid protocol with a reset GPIO. + +allOf: + - $ref: /schemas/input/touchscreen/touchscreen.yaml# + +properties: + compatible: + const: ilitek,ili9882t + + reg: + const: 0x41 + + interrupts: + maxItems: 1 + + panel: true + + reset-gpios: + maxItems: 1 + description: Reset GPIO. + + vccio-supply: + description: The 1.8V supply to the touchscreen. + +required: + - compatible + - reg + - interrupts + - panel + - vccio-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen: touchscreen@41 { + compatible = "ilitek,ili9882t"; + reg = <0x41>; + + interrupt-parent = <&pio>; + interrupts = <12 IRQ_TYPE_LEVEL_LOW>; + + panel = <&panel>; + reset-gpios = <&pio 60 GPIO_ACTIVE_LOW>; + vccio-supply = <&mt6366_vio18_reg>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml index 037c3ae9f1c3..e34c9e78d38d 100644 --- a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml +++ b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml @@ -55,7 +55,7 @@ patternProperties: interrupt-names: true - linux-keycodes: + linux,keycodes: maxItems: 1 wakeup-source: true diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt deleted file mode 100644 index 9afffbdf6e28..000000000000 --- a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt +++ /dev/null @@ -1,56 +0,0 @@ -Synaptics RMI4 2D Sensor Device Binding - -The Synaptics RMI4 core is able to support RMI4 devices using different -transports and different functions. This file describes the device tree -bindings for devices which contain 2D sensors using Function 11 or -Function 12. Complete documentation for transports and other functions -can be found in: -Documentation/devicetree/bindings/input/rmi4. - -RMI4 Function 11 and Function 12 are for 2D touch position sensing. -Additional documentation for F11 can be found at: -http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf - -Optional Touch Properties: -Description in Documentation/devicetree/bindings/input/touchscreen -- touchscreen-inverted-x -- touchscreen-inverted-y -- touchscreen-swapped-x-y -- touchscreen-x-mm -- touchscreen-y-mm - -Optional Properties: -- syna,clip-x-low: Sets a minimum value for X. -- syna,clip-y-low: Sets a minimum value for Y. -- syna,clip-x-high: Sets a maximum value for X. -- syna,clip-y-high: Sets a maximum value for Y. -- syna,offset-x: Add an offset to X. -- syna,offset-y: Add an offset to Y. -- syna,delta-x-threshold: Set the minimum distance on the X axis required - to generate an interrupt in reduced reporting - mode. -- syna,delta-y-threshold: Set the minimum distance on the Y axis required - to generate an interrupt in reduced reporting - mode. -- syna,sensor-type: Set the sensor type. 1 for touchscreen 2 for touchpad. -- syna,disable-report-mask: Mask for disabling posiiton reporting. Used to - disable reporing absolute position data. -- syna,rezero-wait-ms: Time in miliseconds to wait after issuing a rezero - command. - - -Example of a RMI4 I2C device with F11: -Example: - &i2c1 { - rmi4-i2c-dev@2c { - compatible = "syna,rmi4-i2c"; - - ... - - rmi4-f11@11 { - reg = <0x11>; - touchscreen-inverted-y; - syna,sensor-type = <2>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt deleted file mode 100644 index 079cad2b6843..000000000000 --- a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt +++ /dev/null @@ -1,39 +0,0 @@ -Synaptics RMI4 F01 Device Binding - -The Synaptics RMI4 core is able to support RMI4 devices using different -transports and different functions. This file describes the device tree -bindings for devices which contain Function 1. Complete documentation -for transports and other functions can be found in: -Documentation/devicetree/bindings/input/rmi4. - -Additional documentation for F01 can be found at: -http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf - -Optional Properties: -- syna,nosleep-mode: If set the device will run at full power without sleeping. - nosleep has 3 modes, 0 will not change the default - setting, 1 will disable nosleep (allow sleeping), - and 2 will enable nosleep (disabling sleep). -- syna,wakeup-threshold: Defines the amplitude of the disturbance to the - background capacitance that will cause the - device to wake from dozing. -- syna,doze-holdoff-ms: The delay to wait after the last finger lift and the - first doze cycle. -- syna,doze-interval-ms: The time period that the device sleeps between finger - activity. - - -Example of a RMI4 I2C device with F01: - Example: - &i2c1 { - rmi4-i2c-dev@2c { - compatible = "syna,rmi4-i2c"; - - ... - - rmi4-f01@1 { - reg = <0x1>; - syna,nosleep-mode = <1>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt deleted file mode 100644 index dcb012f5b3ee..000000000000 --- a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt +++ /dev/null @@ -1,61 +0,0 @@ -Synaptics RMI4 I2C Device Binding - -The Synaptics RMI4 core is able to support RMI4 devices using different -transports and different functions. This file describes the device tree -bindings for devices using the I2C transport driver. Complete documentation -for other transports and functions can be found in -Documentation/devicetree/bindings/input/rmi4. - -Required Properties: -- compatible: syna,rmi4-i2c -- reg: I2C address -- #address-cells: Set to 1 to indicate that the function child nodes - consist of only on uint32 value. -- #size-cells: Set to 0 to indicate that the function child nodes do not - have a size property. - -Optional Properties: -- interrupts: interrupt which the rmi device is connected to. -See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - -- syna,reset-delay-ms: The number of milliseconds to wait after resetting the - device. - -- syna,startup-delay-ms: The number of milliseconds to wait after powering on - the device. - -- vdd-supply: VDD power supply. -See ../regulator/regulator.txt - -- vio-supply: VIO power supply -See ../regulator/regulator.txt - -Function Parameters: -Parameters specific to RMI functions are contained in child nodes of the rmi device - node. Documentation for the parameters of each function can be found in: -Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt. - - - -Example: - &i2c1 { - rmi4-i2c-dev@2c { - compatible = "syna,rmi4-i2c"; - reg = <0x2c>; - #address-cells = <1>; - #size-cells = <0>; - interrupt-parent = <&gpio>; - interrupts = <4 2>; - - rmi4-f01@1 { - reg = <0x1>; - syna,nosleep-mode = <1>; - }; - - rmi4-f11@11 { - reg = <0x11>; - touchscreen-inverted-y; - syna,sensor-type = <2>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt deleted file mode 100644 index 632f473db65b..000000000000 --- a/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt +++ /dev/null @@ -1,56 +0,0 @@ -Synaptics RMI4 SPI Device Binding - -The Synaptics RMI4 core is able to support RMI4 devices using different -transports and different functions. This file describes the device tree -bindings for devices using the SPI transport driver. Complete documentation -for other transports and functions can be found in -Documentation/devicetree/bindings/input/rmi4. - -Required Properties: -- compatible: syna,rmi4-spi -- reg: Chip select address for the device -- #address-cells: Set to 1 to indicate that the function child nodes - consist of only on uint32 value. -- #size-cells: Set to 0 to indicate that the function child nodes do not - have a size property. - -Optional Properties: -- interrupts: interrupt which the rmi device is connected to. -See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - -- spi-rx-delay-us: microsecond delay after a read transfer. -- spi-tx-delay-us: microsecond delay after a write transfer. - -Function Parameters: -Parameters specific to RMI functions are contained in child nodes of the rmi device - node. Documentation for the parameters of each function can be found in: -Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt. - - - -Example: - spi@7000d800 { - rmi4-spi-dev@0 { - compatible = "syna,rmi4-spi"; - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - spi-max-frequency = <4000000>; - spi-cpha; - spi-cpol; - interrupt-parent = <&gpio>; - interrupts = <TEGRA_GPIO(K, 2) 0x2>; - spi-rx-delay-us = <30>; - - rmi4-f01@1 { - reg = <0x1>; - syna,nosleep-mode = <1>; - }; - - rmi4-f11@11 { - reg = <0x11>; - touchscreen-inverted-y; - syna,sensor-type = <2>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/input/stmpe-keypad.txt b/Documentation/devicetree/bindings/input/stmpe-keypad.txt deleted file mode 100644 index 12bb771d66d4..000000000000 --- a/Documentation/devicetree/bindings/input/stmpe-keypad.txt +++ /dev/null @@ -1,41 +0,0 @@ -* STMPE Keypad - -Required properties: - - compatible : "st,stmpe-keypad" - - linux,keymap : See ./matrix-keymap.txt - -Optional properties: - - debounce-interval : Debouncing interval time in milliseconds - - st,scan-count : Scanning cycles elapsed before key data is updated - - st,no-autorepeat : If specified device will not autorepeat - - keypad,num-rows : See ./matrix-keymap.txt - - keypad,num-columns : See ./matrix-keymap.txt - -Example: - - stmpe_keypad { - compatible = "st,stmpe-keypad"; - - debounce-interval = <64>; - st,scan-count = <8>; - st,no-autorepeat; - - linux,keymap = <0x205006b - 0x4010074 - 0x3050072 - 0x1030004 - 0x502006a - 0x500000a - 0x5008b - 0x706001c - 0x405000b - 0x6070003 - 0x3040067 - 0x303006c - 0x60400e7 - 0x602009e - 0x4020073 - 0x5050002 - 0x4030069 - 0x3020008>; - }; diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml new file mode 100644 index 000000000000..4d4e1a8e36be --- /dev/null +++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml @@ -0,0 +1,271 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/syna,rmi4.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synaptics RMI4 compliant devices + +maintainers: + - Jason A. Donenfeld <Jason@zx2c4.com> + - Matthias Schiffer <matthias.schiffer@ew.tq-group.com + - Vincent Huang <vincent.huang@tw.synaptics.com> + +description: | + The Synaptics RMI4 (Register Mapped Interface 4) core is able to support RMI4 + devices using different transports (I2C, SPI) and different functions (e.g. + Function 1, 2D sensors using Function 11 or 12). + +properties: + compatible: + enum: + - syna,rmi4-i2c + - syna,rmi4-spi + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + interrupts: + maxItems: 1 + + reset-gpios: + maxItems: 1 + description: Active low signal + + spi-cpha: true + spi-cpol: true + + syna,reset-delay-ms: + description: + Delay to wait after resetting the device. + + syna,startup-delay-ms: + description: + Delay to wait after powering on the device. + + vdd-supply: true + vio-supply: true + + rmi4-f01@1: + type: object + additionalProperties: false + description: + Function 1 + + properties: + reg: + maxItems: 1 + + syna,nosleep-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + description: + If set the device will run at full power without sleeping. nosleep + has 3 modes, 0 will not change the default setting, 1 will disable + nosleep (allow sleeping), and 2 will enable nosleep (disabling + sleep). + + syna,wakeup-threshold: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Defines the amplitude of the disturbance to the background + capacitance that will cause the device to wake from dozing. + + syna,doze-holdoff-ms: + description: + The delay to wait after the last finger lift and the first doze + cycle. + + syna,doze-interval-ms: + description: + The time period that the device sleeps between finger activity. + + required: + - reg + +patternProperties: + "^rmi4-f1[12]@1[12]$": + type: object + unevaluatedProperties: false + $ref: /schemas/input/touchscreen/touchscreen.yaml# + description: + RMI4 Function 11 and Function 12 are for 2D touch position sensing. + + properties: + reg: + maxItems: 1 + + syna,clip-x-low: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Minimum value for X. + + syna,clip-y-low: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Minimum value for Y. + + syna,clip-x-high: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Maximum value for X. + + syna,clip-y-high: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Maximum value for Y. + + syna,offset-x: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Add an offset to X. + + syna,offset-y: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Add an offset to Y. + + syna,delta-x-threshold: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Minimum distance on the X axis required to generate an interrupt in + reduced reporting mode. + + syna,delta-y-threshold: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Minimum distance on the Y axis required to generate an interrupt in + reduced reporting mode. + + syna,sensor-type: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2] + description: | + Sensor type: 1 for touchscreen 2 for touchpad. + + syna,disable-report-mask: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Mask for disabling posiiton reporting. Used to disable reporing + absolute position data. + + syna,rezero-wait-ms: + description: + Time to wait after issuing a rezero command. + + required: + - reg + + "^rmi4-f[0-9a-f]+@[0-9a-f]+$": + type: object + description: + Other functions, not documented yet. + + properties: + reg: + maxItems: 1 + + required: + - reg + +required: + - compatible + - reg + +unevaluatedProperties: false + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + + - if: + properties: + compatible: + contains: + const: syna,rmi4-i2c + then: + properties: + spi-rx-delay-us: false + spi-tx-delay-us: false + else: + properties: + syna,reset-delay-ms: false + syna,startup-delay-ms: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen@20 { + compatible = "syna,rmi4-i2c"; + reg = <0x20>; + interrupt-parent = <&gpx1>; + interrupts = <6 IRQ_TYPE_EDGE_FALLING>; + + syna,startup-delay-ms = <100>; + vdd-supply = <&tsp_vdd>; + vio-supply = <&ldo32_reg>; + + pinctrl-0 = <&touch_irq>; + pinctrl-names = "default"; + #address-cells = <1>; + #size-cells = <0>; + + rmi4-f01@1 { + reg = <0x1>; + syna,nosleep-mode = <1>; + }; + + rmi4-f12@12 { + reg = <0x12>; + syna,sensor-type = <1>; + }; + + rmi4-f1a@1a { + reg = <0x1a>; + }; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen@0 { + compatible = "syna,rmi4-spi"; + reg = <0x0>; + interrupt-parent = <&gpx1>; + interrupts = <6 IRQ_TYPE_EDGE_FALLING>; + + spi-max-frequency = <4000000>; + spi-rx-delay-us = <30>; + spi-cpha; + spi-cpol; + + #address-cells = <1>; + #size-cells = <0>; + + rmi4-f01@1 { + reg = <0x1>; + syna,nosleep-mode = <1>; + }; + + rmi4-f11@11 { + reg = <0x11>; + touchscreen-inverted-y; + syna,sensor-type = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt deleted file mode 100644 index 238b51555c04..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt +++ /dev/null @@ -1,108 +0,0 @@ -STMPE Touchscreen ----------------- - -Required properties: - - compatible: "st,stmpe-ts" - -Optional properties: -- st,ave-ctrl : Sample average control - 0 -> 1 sample - 1 -> 2 samples - 2 -> 4 samples - 3 -> 8 samples -- st,touch-det-delay : Touch detect interrupt delay (recommended is 3) - 0 -> 10 us - 1 -> 50 us - 2 -> 100 us - 3 -> 500 us - 4 -> 1 ms - 5 -> 5 ms - 6 -> 10 ms - 7 -> 50 ms -- st,settling : Panel driver settling time (recommended is 2) - 0 -> 10 us - 1 -> 100 us - 2 -> 500 us - 3 -> 1 ms - 4 -> 5 ms - 5 -> 10 ms - 6 -> 50 ms - 7 -> 100 ms -- st,fraction-z : Length of the fractional part in z (recommended is 7) - (fraction-z ([0..7]) = Count of the fractional part) -- st,i-drive : current limit value of the touchscreen drivers - 0 -> 20 mA (typical 35mA max) - 1 -> 50 mA (typical 80 mA max) - -Optional properties common with MFD (deprecated): - - st,sample-time : ADC conversion time in number of clock. - 0 -> 36 clocks - 1 -> 44 clocks - 2 -> 56 clocks - 3 -> 64 clocks - 4 -> 80 clocks (recommended) - 5 -> 96 clocks - 6 -> 124 clocks - - st,mod-12b : ADC Bit mode - 0 -> 10bit ADC - 1 -> 12bit ADC - - st,ref-sel : ADC reference source - 0 -> internal - 1 -> external - - st,adc-freq : ADC Clock speed - 0 -> 1.625 MHz - 1 -> 3.25 MHz - 2 || 3 -> 6.5 MHz - -Node should be child node of stmpe node to which it belongs. - -Note that common ADC settings of stmpe_touchscreen (child) will take precedence -over the settings done in MFD. - -Example: - -stmpe811@41 { - compatible = "st,stmpe811"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_touch_int>; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x41>; - interrupts = <10 IRQ_TYPE_LEVEL_LOW>; - interrupt-parent = <&gpio4>; - interrupt-controller; - id = <0>; - blocks = <0x5>; - irq-trigger = <0x1>; - /* Common ADC settings */ - /* 3.25 MHz ADC clock speed */ - st,adc-freq = <1>; - /* 12-bit ADC */ - st,mod-12b = <1>; - /* internal ADC reference */ - st,ref-sel = <0>; - /* ADC converstion time: 80 clocks */ - st,sample-time = <4>; - - stmpe_touchscreen { - compatible = "st,stmpe-ts"; - reg = <0>; - /* 8 sample average control */ - st,ave-ctrl = <3>; - /* 5 ms touch detect interrupt delay */ - st,touch-det-delay = <5>; - /* 1 ms panel driver settling time */ - st,settling = <3>; - /* 7 length fractional part in z */ - st,fraction-z = <7>; - /* - * 50 mA typical 80 mA max touchscreen drivers - * current limit value - */ - st,i-drive = <1>; - }; - stmpe_adc { - compatible = "st,stmpe-adc"; - st,norequest-mask = <0x0F>; - }; -}; diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml index 895592da9626..431c13335c40 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml @@ -10,6 +10,13 @@ maintainers: - Dmitry Torokhov <dmitry.torokhov@gmail.com> properties: + panel: + description: If this touchscreen is integrally connected to a panel, this + is a reference to that panel. The presence of this reference indicates + that the touchscreen should be power sequenced together with the panel + and that they may share power and/or reset signals. + $ref: /schemas/types.yaml#/definitions/phandle + touchscreen-min-x: description: minimum x coordinate reported $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt index ed00f61b8c08..210486a3fb11 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt @@ -6,7 +6,7 @@ Required properties: - ti,x-plate-ohms: X-plate resistance in ohms. Optional properties: -- gpios: the interrupt gpio the chip is connected to (trough the penirq pin). +- gpios: the interrupt gpio the chip is connected to (through the penirq pin). The penirq pin goes to low when the panel is touched. (see GPIO binding[1] for more details). - interrupts: (gpio) interrupt to which the chip is connected diff --git a/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml index f7a5e31c506e..fc21fe3e7b37 100644 --- a/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml +++ b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml @@ -51,7 +51,7 @@ properties: type: object fsl,ddrc: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: Phandle to DDR Controller. diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml index 5d17bdcfdf70..73f809cdb783 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml @@ -25,14 +25,20 @@ properties: - const: qcom,msm8998-bwmon # BWMON v4 - items: - enum: + - qcom,sc7180-cpu-bwmon - qcom,sc7280-cpu-bwmon - qcom,sc8280xp-cpu-bwmon - qcom,sdm845-cpu-bwmon + - qcom,sm6350-llcc-bwmon + - qcom,sm8250-cpu-bwmon - qcom,sm8550-cpu-bwmon - const: qcom,sdm845-bwmon # BWMON v4, unified register space - items: - enum: + - qcom,sc7180-llcc-bwmon - qcom,sc8280xp-llcc-bwmon + - qcom,sm6350-cpu-bwmon + - qcom,sm8250-llcc-bwmon - qcom,sm8550-llcc-bwmon - const: qcom,sc7280-llcc-bwmon - const: qcom,sc7280-llcc-bwmon # BWMON v5 diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index 9d0a98d77ae9..21dae0b92819 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -21,6 +21,7 @@ properties: - enum: - qcom,sc7180-osm-l3 - qcom,sc8180x-osm-l3 + - qcom,sdm670-osm-l3 - qcom,sdm845-osm-l3 - qcom,sm6350-osm-l3 - qcom,sm8150-osm-l3 diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index 4d93ad415e0b..a46497af1fd8 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -18,9 +18,6 @@ description: | least one RPMh device child node pertaining to their RSC and each provider can map to multiple RPMh resources. -allOf: - - $ref: qcom,rpmh-common.yaml# - properties: reg: maxItems: 1 @@ -91,6 +88,7 @@ properties: - qcom,sm8250-mc-virt - qcom,sm8250-mmss-noc - qcom,sm8250-npu-noc + - qcom,sm8250-qup-virt - qcom,sm8250-system-noc - qcom,sm8350-aggre1-noc - qcom,sm8350-aggre2-noc @@ -107,7 +105,19 @@ properties: required: - compatible - - reg + +allOf: + - $ref: qcom,rpmh-common.yaml# + - if: + not: + properties: + compatible: + enum: + - qcom,sm8250-qup-virt + then: + required: + - reg + unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt deleted file mode 100644 index bde63f8f090e..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt +++ /dev/null @@ -1,38 +0,0 @@ -Amlogic meson GPIO interrupt controller - -Meson SoCs contains an interrupt controller which is able to watch the SoC -pads and generate an interrupt on edge or level. The controller is essentially -a 256 pads to 8 GIC interrupt multiplexer, with a filter block to select edge -or level and polarity. It does not expose all 256 mux inputs because the -documentation shows that the upper part is not mapped to any pad. The actual -number of interrupt exposed depends on the SoC. - -Required properties: - -- compatible : must have "amlogic,meson8-gpio-intc" and either - "amlogic,meson8-gpio-intc" for meson8 SoCs (S802) or - "amlogic,meson8b-gpio-intc" for meson8b SoCs (S805) or - "amlogic,meson-gxbb-gpio-intc" for GXBB SoCs (S905) or - "amlogic,meson-gxl-gpio-intc" for GXL SoCs (S905X, S912) - "amlogic,meson-axg-gpio-intc" for AXG SoCs (A113D, A113X) - "amlogic,meson-g12a-gpio-intc" for G12A SoCs (S905D2, S905X2, S905Y2) - "amlogic,meson-sm1-gpio-intc" for SM1 SoCs (S905D3, S905X3, S905Y3) - "amlogic,meson-a1-gpio-intc" for A1 SoCs (A113L) - "amlogic,meson-s4-gpio-intc" for S4 SoCs (S802X2, S905Y4, S805X2G, S905W2) -- reg : Specifies base physical address and size of the registers. -- 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 2. -- meson,channel-interrupts: Array with the 8 upstream hwirq numbers. These - are the hwirqs used on the parent interrupt controller. - -Example: - -gpio_interrupt: interrupt-controller@9880 { - compatible = "amlogic,meson-gxbb-gpio-intc", - "amlogic,meson-gpio-intc"; - reg = <0x0 0x9880 0x0 0x10>; - interrupt-controller; - #interrupt-cells = <2>; - meson,channel-interrupts = <64 65 66 67 68 69 70 71>; -}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml new file mode 100644 index 000000000000..3d06db98e978 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/amlogic,meson-gpio-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson GPIO interrupt controller + +maintainers: + - Heiner Kallweit <hkallweit1@gmail.com> + +description: | + Meson SoCs contains an interrupt controller which is able to watch the SoC + pads and generate an interrupt on edge or level. The controller is essentially + a 256 pads to 8 or 12 GIC interrupt multiplexer, with a filter block to select + edge or level and polarity. It does not expose all 256 mux inputs because the + documentation shows that the upper part is not mapped to any pad. The actual + number of interrupts exposed depends on the SoC. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + oneOf: + - const: amlogic,meson-gpio-intc + - items: + - enum: + - amlogic,meson8-gpio-intc + - amlogic,meson8b-gpio-intc + - amlogic,meson-gxbb-gpio-intc + - amlogic,meson-gxl-gpio-intc + - amlogic,meson-axg-gpio-intc + - amlogic,meson-g12a-gpio-intc + - amlogic,meson-sm1-gpio-intc + - amlogic,meson-a1-gpio-intc + - amlogic,meson-s4-gpio-intc + - amlogic,c3-gpio-intc + - const: amlogic,meson-gpio-intc + + reg: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + amlogic,channel-interrupts: + description: Array with the upstream hwirq numbers + minItems: 8 + maxItems: 12 + $ref: /schemas/types.yaml#/definitions/uint32-array + +required: + - compatible + - reg + - interrupt-controller + - "#interrupt-cells" + - amlogic,channel-interrupts + +additionalProperties: false + +examples: + - | + interrupt-controller@9880 { + compatible = "amlogic,meson-gxbb-gpio-intc", + "amlogic,meson-gpio-intc"; + reg = <0x9880 0x10>; + interrupt-controller; + #interrupt-cells = <2>; + amlogic,channel-interrupts = <64 65 66 67 68 69 70 71>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml index 39e64c7f6360..2bc38479a41e 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml @@ -49,7 +49,7 @@ properties: The 2nd cell contains the interrupt number for the interrupt type. SPI interrupts are in the range [0-987]. PPI interrupts are in the - range [0-15]. Extented SPI interrupts are in the range [0-1023]. + range [0-15]. Extended SPI interrupts are in the range [0-1023]. Extended PPI interrupts are in the range [0-127]. The 3rd cell is the flags, encoded as follows: diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt index 2a1d16bdf834..ea939f54c5eb 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt @@ -6,7 +6,7 @@ controllers are OR:ed together and fed to the CPU tile's IRQ input. Each instance can handle up to 32 interrupts. Required properties: -- compatible: "arm,versatile-fpga-irq" or "oxsemi,ox810se-rps-irq" +- compatible: "arm,versatile-fpga-irq" - interrupt-controller: Identifies the node as an interrupt controller - #interrupt-cells: The number of cells to define the interrupts. Must be 1 as the FPGA IRQ controller has no configuration options for interrupt @@ -19,6 +19,8 @@ Required properties: the system till not make it possible for devices to request these interrupts. +The "oxsemi,ox810se-rps-irq" compatible is deprecated. + Example: pic: pic@14000000 { diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt index 0f1af5a1c12e..bdd173056f72 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt @@ -70,7 +70,7 @@ Bank 1: 25: DMA9 26: DMA10 27: DMA11-14 - shared interrupt for DMA 11 to 14 -28: DMAALL - triggers on all dma interrupts (including chanel 15) +28: DMAALL - triggers on all dma interrupts (including channel 15) 29: AUX 30: ARM 31: VPUDMA 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 c680de1cbd56..786f2426399b 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml @@ -59,7 +59,7 @@ description: > .. 31 ........................ X - The BCM3380 Level 1 / Level 2 interrrupt controller shows up in various forms + The BCM3380 Level 1 / Level 2 interrupt controller shows up in various forms on many BCM338x/BCM63xx chipsets. It has the following properties: - outputs a single interrupt signal to its interrupt controller parent diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml new file mode 100644 index 000000000000..393c128a41d8 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/loongson,eiointc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson Extended I/O Interrupt Controller + +maintainers: + - Binbin Zhou <zhoubinbin@loongson.cn> + +description: | + This interrupt controller is found on the Loongson-3 family chips and + Loongson-2K series chips and is used to distribute interrupts directly to + individual cores without forwarding them through the HT's interrupt line. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + enum: + - loongson,ls2k0500-eiointc + - loongson,ls2k2000-eiointc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - '#interrupt-cells' + +unevaluatedProperties: false + +examples: + - | + eiointc: interrupt-controller@1fe11600 { + compatible = "loongson,ls2k0500-eiointc"; + reg = <0x1fe10000 0x10000>; + + interrupt-controller; + #interrupt-cells = <1>; + + interrupt-parent = <&cpuintc>; + interrupts = <3>; + }; + +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml b/Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml index 50003880ee6f..d56ba65b17d1 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/interrupt-controller/microchip,eic.yaml# +$id: http://devicetree.org/schemas/interrupt-controller/microchip,sama7g5-eic.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Microchip External Interrupt Controller diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml index a106ba6e810b..4847b04be1a1 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml @@ -31,6 +31,7 @@ properties: - qcom,sc7180-pdc - qcom,sc7280-pdc - qcom,sc8280xp-pdc + - qcom,sdm670-pdc - qcom,sdm845-pdc - qcom,sdx55-pdc - qcom,sdx65-pdc diff --git a/Documentation/devicetree/bindings/interrupt-controller/ralink,rt2880-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ralink,rt2880-intc.yaml new file mode 100644 index 000000000000..0fa952a9edfd --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/ralink,rt2880-intc.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/ralink,rt2880-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink SoCs Interrupt Controller + +maintainers: + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +description: + This interrupt controller support a central point for interrupt aggregation + for platform related blocks. + +properties: + compatible: + const: ralink,rt2880-intc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - '#interrupt-cells' + +additionalProperties: false + +examples: + - | + interrupt-controller@200 { + compatible = "ralink,rt2880-intc"; + reg = <0x200 0x100>; + interrupt-controller; + #interrupt-cells = <1>; + + interrupt-parent = <&cpuintc>; + interrupts = <2>; + }; +... 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 f75736a061af..dc1f28e55266 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 @@ -57,14 +57,15 @@ properties: - const: andestech,nceplic100 - items: - enum: + - canaan,k210-plic - sifive,fu540-c000-plic - starfive,jh7100-plic - starfive,jh7110-plic - - canaan,k210-plic - const: sifive,plic-1.0.0 - items: - enum: - allwinner,sun20i-d1-plic + - thead,th1520-plic - const: thead,c900-plic - items: - const: sifive,plic-1.0.0 diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml index 65523d9459d8..3cd5a1822e14 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/interrupt-controller/ti,pruss-intc.yaml# diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index ba677d401e24..cf29ab10501c 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -29,6 +29,7 @@ properties: - qcom,msm8996-smmu-v2 - qcom,msm8998-smmu-v2 - qcom,sdm630-smmu-v2 + - qcom,sm6375-smmu-v2 - const: qcom,smmu-v2 - description: Qcom SoCs implementing "qcom,smmu-500" and "arm,mmu-500" @@ -45,6 +46,7 @@ properties: - qcom,sdm845-smmu-500 - qcom,sdx55-smmu-500 - qcom,sdx65-smmu-500 + - qcom,sdx75-smmu-500 - qcom,sm6115-smmu-500 - qcom,sm6125-smmu-500 - qcom,sm6350-smmu-500 @@ -79,7 +81,9 @@ properties: - description: Qcom Adreno GPUs implementing "qcom,smmu-500" and "arm,mmu-500" items: - enum: + - qcom,sa8775p-smmu-500 - qcom,sc7280-smmu-500 + - qcom,sc8280xp-smmu-500 - qcom,sm6115-smmu-500 - qcom,sm6125-smmu-500 - qcom,sm8150-smmu-500 @@ -266,7 +270,49 @@ allOf: contains: enum: - qcom,msm8998-smmu-v2 + then: + anyOf: + - properties: + clock-names: + items: + - const: bus + clocks: + items: + - description: bus clock required for downstream bus access and for + the smmu ptw + - properties: + clock-names: + items: + - const: iface + - const: mem + - const: mem_iface + clocks: + items: + - description: interface clock required to access smmu's registers + through the TCU's programming interface. + - description: bus clock required for memory access + - description: bus clock required for GPU memory access + - properties: + clock-names: + items: + - const: iface-mm + - const: iface-smmu + - const: bus-smmu + clocks: + items: + - description: interface clock required to access mnoc's registers + through the TCU's programming interface. + - description: interface clock required to access smmu's registers + through the TCU's programming interface. + - description: bus clock required for the smmu ptw + + - if: + properties: + compatible: + contains: + enum: - qcom,sdm630-smmu-v2 + - qcom,sm6375-smmu-v2 then: anyOf: - properties: @@ -331,7 +377,10 @@ allOf: properties: compatible: contains: - const: qcom,sc7280-smmu-500 + enum: + - qcom,sa8775p-smmu-500 + - qcom,sc7280-smmu-500 + - qcom,sc8280xp-smmu-500 then: properties: clock-names: @@ -413,10 +462,8 @@ allOf: - nvidia,smmu-500 - qcom,qcm2290-smmu-500 - qcom,qdu1000-smmu-500 - - qcom,sa8775p-smmu-500 - qcom,sc7180-smmu-500 - qcom,sc8180x-smmu-500 - - qcom,sc8280xp-smmu-500 - qcom,sdm670-smmu-500 - qcom,sdm845-smmu-500 - qcom,sdx55-smmu-500 diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index 5b6395bc10e0..ea6b0f5f24de 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -78,6 +78,9 @@ properties: - mediatek,mt8173-m4u # generation two - mediatek,mt8183-m4u # generation two - mediatek,mt8186-iommu-mm # generation two + - mediatek,mt8188-iommu-vdo # generation two + - mediatek,mt8188-iommu-vpp # generation two + - mediatek,mt8188-iommu-infra # generation two - mediatek,mt8192-m4u # generation two - mediatek,mt8195-iommu-vdo # generation two - mediatek,mt8195-iommu-vpp # generation two @@ -123,6 +126,7 @@ properties: description: | This is the mtk_m4u_id according to the HW. Specifies the mtk_m4u_id as defined in + dt-binding/memory/mediatek,mt8188-memory-port.h for mt8188, dt-binding/memory/mt2701-larb-port.h for mt2701 and mt7623, dt-binding/memory/mt2712-larb-port.h for mt2712, dt-binding/memory/mt6779-larb-port.h for mt6779, @@ -155,6 +159,8 @@ allOf: - mediatek,mt6795-m4u - mediatek,mt8173-m4u - mediatek,mt8186-iommu-mm + - mediatek,mt8188-iommu-vdo + - mediatek,mt8188-iommu-vpp - mediatek,mt8192-m4u - mediatek,mt8195-iommu-vdo - mediatek,mt8195-iommu-vpp @@ -168,6 +174,8 @@ allOf: compatible: enum: - mediatek,mt8186-iommu-mm + - mediatek,mt8188-iommu-vdo + - mediatek,mt8188-iommu-vpp - mediatek,mt8192-m4u - mediatek,mt8195-iommu-vdo - mediatek,mt8195-iommu-vpp @@ -194,7 +202,9 @@ allOf: properties: compatible: contains: - const: mediatek,mt8195-iommu-infra + enum: + - mediatek,mt8188-iommu-infra + - mediatek,mt8195-iommu-infra then: required: diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml index d9fabdf930d9..a74eb899c381 100644 --- a/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml @@ -17,11 +17,16 @@ description: | properties: compatible: - items: - - enum: - - qcom,msm8916-iommu - - qcom,msm8953-iommu - - const: qcom,msm-iommu-v1 + oneOf: + - items: + - enum: + - qcom,msm8916-iommu + - qcom,msm8953-iommu + - const: qcom,msm-iommu-v1 + - items: + - enum: + - qcom,msm8976-iommu + - const: qcom,msm-iommu-v2 clocks: items: @@ -64,6 +69,8 @@ patternProperties: enum: - qcom,msm-iommu-v1-ns - qcom,msm-iommu-v1-sec + - qcom,msm-iommu-v2-ns + - qcom,msm-iommu-v2-sec interrupts: maxItems: 1 @@ -71,6 +78,11 @@ patternProperties: reg: maxItems: 1 + qcom,ctx-asid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The ASID number associated to the context bank. + required: - compatible - interrupts diff --git a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml index be1539d234f9..3528b81daa25 100644 --- a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml +++ b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/iommu/xen,grant-dma.yaml# diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml index 4ff6fabfcb30..129e32c4c774 100644 --- a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml +++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml @@ -41,7 +41,7 @@ properties: - description: STR register aspeed,lpc-io-reg: - $ref: '/schemas/types.yaml#/definitions/uint32-array' + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 2 description: | @@ -50,7 +50,7 @@ properties: status address may be optionally provided. aspeed,lpc-interrupts: - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 2 maxItems: 2 description: | @@ -63,12 +63,12 @@ properties: kcs_chan: deprecated: true - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: The LPC channel number in the controller kcs_addr: deprecated: true - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: The host CPU IO map address required: diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml index 3f25cdb4e99b..52647bff31af 100644 --- a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml +++ b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml @@ -18,7 +18,7 @@ properties: device_type: items: - - const: "ipmi" + - const: ipmi reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml index c1b4bf95ef99..4bffa3d86128 100644 --- a/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml +++ b/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml @@ -20,7 +20,7 @@ properties: device_type: items: - - const: "ipmi" + - const: ipmi reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/leds/awinic,aw200xx.yaml b/Documentation/devicetree/bindings/leds/awinic,aw200xx.yaml new file mode 100644 index 000000000000..feb5febaf361 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/awinic,aw200xx.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/awinic,aw200xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AWINIC AW200XX LED + +maintainers: + - Martin Kurbanov <mmkurbanov@sberdevices.ru> + +description: | + This controller is present on AW20036/AW20054/AW20072. + It is a 3x12/6x9/6x12 matrix LED programmed via + an I2C interface, up to 36/54/72 LEDs or 12/18/24 RGBs, + 3 pattern controllers for auto breathing or group dimming control. + + For more product information please see the link below: + aw20036 - https://www.awinic.com/en/productDetail/AW20036QNR#tech-docs + aw20054 - https://www.awinic.com/en/productDetail/AW20054QNR#tech-docs + aw20072 - https://www.awinic.com/en/productDetail/AW20072QNR#tech-docs + +properties: + compatible: + enum: + - awinic,aw20036 + - awinic,aw20054 + - awinic,aw20072 + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + awinic,display-rows: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Leds matrix size + +patternProperties: + "^led@[0-9a-f]$": + type: object + $ref: common.yaml# + unevaluatedProperties: false + + properties: + reg: + description: + LED number + maxItems: 1 + + led-max-microamp: + default: 9780 + description: | + Note that a driver will take the minimum of all LED limits + since the chip has a single global setting. + The maximum output current of each LED is calculated by the + following formula: + IMAXled = 160000 * (592 / 600.5) * (1 / display-rows) + And the minimum output current formula: + IMINled = 3300 * (592 / 600.5) * (1 / display-rows) + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - awinic,display-rows + +allOf: + - if: + properties: + compatible: + contains: + const: awinic,aw20036 + then: + properties: + awinic,display-rows: + enum: [1, 2, 3] + else: + properties: + awinic,display-rows: + enum: [1, 2, 3, 4, 5, 6, 7] + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@3a { + compatible = "awinic,aw20036"; + reg = <0x3a>; + #address-cells = <1>; + #size-cells = <0>; + awinic,display-rows = <3>; + + led@0 { + reg = <0x0>; + color = <LED_COLOR_ID_RED>; + led-max-microamp = <9780>; + }; + + led@1 { + reg = <0x1>; + color = <LED_COLOR_ID_GREEN>; + led-max-microamp = <9780>; + }; + + led@2 { + reg = <0x2>; + color = <LED_COLOR_ID_BLUE>; + led-max-microamp = <9780>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml index e1191453c2f0..c914e1276982 100644 --- a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml @@ -21,6 +21,9 @@ properties: compatible: const: kinetic,ktz8866 + reg: + maxItems: 1 + vddpos-supply: description: positive boost supply regulator. @@ -33,6 +36,7 @@ properties: current-num-sinks: description: number of the LED current sinks' channels. + $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 2, 3, 4, 5, 6] kinetic,current-ramp-delay-ms: @@ -53,6 +57,7 @@ properties: required: - compatible + - reg - vddpos-supply - vddneg-supply - enable-gpios @@ -63,14 +68,19 @@ examples: - | #include <dt-bindings/gpio/gpio.h> - backlight { - compatible = "kinetic,ktz8866"; - - vddpos-supply = <&bl_vddpos_5p5>; - vddneg-supply = <&bl_vddneg_5p5>; - enable-gpios = <&tlmm 139 GPIO_ACTIVE_HIGH>; - current-num-sinks = <5>; - kinetic,current-ramp-delay-ms = <128>; - kinetic,led-enable-ramp-delay-ms = <1>; - kinetic,enable-lcd-bias; + i2c { + #address-cells = <1>; + #size-cells = <0>; + + backlight@11 { + compatible = "kinetic,ktz8866"; + reg = <0x11>; + vddpos-supply = <&bl_vddpos_5p5>; + vddneg-supply = <&bl_vddneg_5p5>; + enable-gpios = <&tlmm 139 GPIO_ACTIVE_HIGH>; + current-num-sinks = <5>; + kinetic,current-ramp-delay-ms = <128>; + kinetic,led-enable-ramp-delay-ms = <1>; + kinetic,enable-lcd-bias; + }; }; diff --git a/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml new file mode 100644 index 000000000000..9416e1bfab92 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml @@ -0,0 +1,149 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/lp855x-backlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments LP855X backlight controllers + +maintainers: + - Artur Weber <aweber.kernel@gmail.com> + +properties: + compatible: + enum: + - ti,lp8550 + - ti,lp8551 + - ti,lp8552 + - ti,lp8553 + - ti,lp8555 + - ti,lp8556 + - ti,lp8557 + + reg: + maxItems: 1 + + dev-ctrl: + $ref: /schemas/types.yaml#/definitions/uint8 + description: + Value of device control register. This is a device-specific value. + + bl-name: + $ref: /schemas/types.yaml#/definitions/string + description: Backlight device name. + + init-brt: + $ref: /schemas/types.yaml#/definitions/uint8 + description: Initial value of backlight brightness. + + power-supply: + description: Regulator which controls the 3V rail. + + enable-supply: + description: Regulator which controls the EN/VDDIO input. + + pwms: + maxItems: 1 + description: | + PWM channel to use for controlling the backlight; setting this + enables the PWM-based backlight control mode. + + pwm-names: true + + pwm-period: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + PWM period value. Deprecated; set the period value in the pwms + property instead. + deprecated: true + +patternProperties: + "^rom-[0-9a-f]{2}h$": + type: object + description: Nodes containing the values of configuration registers. + additionalProperties: false + properties: + rom-addr: + $ref: /schemas/types.yaml#/definitions/uint8 + description: Register address of ROM area to be updated. + + rom-val: + $ref: /schemas/types.yaml#/definitions/uint8 + description: Value to write to the ROM register. + +required: + - compatible + - reg + - dev-ctrl + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + backlight@2c { + compatible = "ti,lp8555"; + reg = <0x2c>; + + dev-ctrl = /bits/ 8 <0x00>; + + pwms = <&pwm 0 10000>; + pwm-names = "lp8555"; + + /* 4V OV, 4 output LED0 string enabled */ + rom-14h { + rom-addr = /bits/ 8 <0x14>; + rom-val = /bits/ 8 <0xcf>; + }; + + /* Heavy smoothing, 24ms ramp time step */ + rom-15h { + rom-addr = /bits/ 8 <0x15>; + rom-val = /bits/ 8 <0xc7>; + }; + + /* 4 output LED1 string enabled */ + rom-19h { + rom-addr = /bits/ 8 <0x19>; + rom-val = /bits/ 8 <0x0f>; + }; + }; + }; + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + backlight@2c { + compatible = "ti,lp8556"; + reg = <0x2c>; + + bl-name = "lcd-bl"; + dev-ctrl = /bits/ 8 <0x85>; + init-brt = /bits/ 8 <0x10>; + }; + }; + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + backlight@2c { + compatible = "ti,lp8557"; + reg = <0x2c>; + enable-supply = <&backlight_vddio>; + power-supply = <&backlight_vdd>; + + dev-ctrl = /bits/ 8 <0x41>; + init-brt = /bits/ 8 <0x0a>; + + /* 4V OV, 4 output LED string enabled */ + rom-14h { + rom-addr = /bits/ 8 <0x14>; + rom-val = /bits/ 8 <0xcf>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/leds/backlight/lp855x.txt b/Documentation/devicetree/bindings/leds/backlight/lp855x.txt deleted file mode 100644 index 88f56641fc28..000000000000 --- a/Documentation/devicetree/bindings/leds/backlight/lp855x.txt +++ /dev/null @@ -1,72 +0,0 @@ -lp855x bindings - -Required properties: - - compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553", - "ti,lp8555", "ti,lp8556", "ti,lp8557" - - reg: I2C slave address (u8) - - dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device. - -Optional properties: - - bl-name: Backlight device name (string) - - init-brt: Initial value of backlight brightness (u8) - - pwm-period: PWM period value. Set only PWM input mode used (u32) - - rom-addr: Register address of ROM area to be updated (u8) - - rom-val: Register value to be updated (u8) - - power-supply: Regulator which controls the 3V rail - - enable-supply: Regulator which controls the EN/VDDIO input - -Example: - - /* LP8555 */ - backlight@2c { - compatible = "ti,lp8555"; - reg = <0x2c>; - - dev-ctrl = /bits/ 8 <0x00>; - pwm-period = <10000>; - - /* 4V OV, 4 output LED0 string enabled */ - rom_14h { - rom-addr = /bits/ 8 <0x14>; - rom-val = /bits/ 8 <0xcf>; - }; - - /* Heavy smoothing, 24ms ramp time step */ - rom_15h { - rom-addr = /bits/ 8 <0x15>; - rom-val = /bits/ 8 <0xc7>; - }; - - /* 4 output LED1 string enabled */ - rom_19h { - rom-addr = /bits/ 8 <0x19>; - rom-val = /bits/ 8 <0x0f>; - }; - }; - - /* LP8556 */ - backlight@2c { - compatible = "ti,lp8556"; - reg = <0x2c>; - - bl-name = "lcd-bl"; - dev-ctrl = /bits/ 8 <0x85>; - init-brt = /bits/ 8 <0x10>; - }; - - /* LP8557 */ - backlight@2c { - compatible = "ti,lp8557"; - reg = <0x2c>; - enable-supply = <&backlight_vddio>; - power-supply = <&backlight_vdd>; - - dev-ctrl = /bits/ 8 <0x41>; - init-brt = /bits/ 8 <0x0a>; - - /* 4V OV, 4 output LED string enabled */ - rom_14h { - rom-addr = /bits/ 8 <0x14>; - rom-val = /bits/ 8 <0xcf>; - }; - }; diff --git a/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml index 5533b6562d92..16fc98e71233 100644 --- a/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml @@ -66,7 +66,7 @@ properties: mediatek,bled-ocp-shutdown: description: | - Enable the backlight shutdown when OCP level triggerred. + Enable the backlight shutdown when OCP level triggered. type: boolean mediatek,bled-ocp-microamp: diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml index 5ec47a8c6568..535690288990 100644 --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml @@ -68,7 +68,6 @@ dependencies: required: - compatible - pwms - - power-supply additionalProperties: false diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index 11aedf1650a1..5fb7007f3618 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -83,8 +83,7 @@ properties: - enum: # LED will act as a back-light, controlled by the framebuffer system - backlight - # LED will turn on (but for leds-gpio see "default-state" property in - # Documentation/devicetree/bindings/leds/leds-gpio.yaml) + # LED will turn on (see also "default-state" property) - default-on # LED "double" flashes at a load average based rate - heartbeat @@ -105,8 +104,6 @@ properties: - audio-mute # LED indicates bluetooth power state - bluetooth-power - # LED indicates activity of all CPUs - - cpu # LED indicates camera flash state - flash # LED indicated keyboard capslock @@ -160,6 +157,18 @@ properties: For flash LED controllers with configurable current this property is mandatory for the LEDs in the non-flash modes (e.g. torch or indicator). + max-brightness: + description: + Normally, the maximum brightness is determined by the hardware, and this + property is not required. This property is used to set a software limit. + It could happen that an LED is made so bright that it gets damaged or + causes damage due to restrictions in a specific system, such as mounting + conditions. + Note that this flag is mainly used for PWM-LEDs, where it is not possible + to map brightness to current. Drivers for other controllers should use + led-max-microamp. + $ref: /schemas/types.yaml#definitions/uint32 + panic-indicator: description: This property specifies that the LED should be used, if at all possible, diff --git a/Documentation/devicetree/bindings/leds/leds-an30259a.txt b/Documentation/devicetree/bindings/leds/leds-an30259a.txt deleted file mode 100644 index cbd833906b2b..000000000000 --- a/Documentation/devicetree/bindings/leds/leds-an30259a.txt +++ /dev/null @@ -1,55 +0,0 @@ -* Panasonic AN30259A 3-channel LED driver - -The AN30259A is a LED controller capable of driving three LEDs independently. It supports -constant current output and sloping current output modes. The chip is connected over I2C. - -Required properties: - - compatible: Must be "panasonic,an30259a". - - reg: I2C slave address. - - #address-cells: Must be 1. - - #size-cells: Must be 0. - -Each LED is represented as a sub-node of the panasonic,an30259a node. - -Required sub-node properties: - - reg: Pin that the LED is connected to. Must be 1, 2, or 3. - -Optional sub-node 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@30 { - compatible = "panasonic,an30259a"; - reg = <0x30>; - #address-cells = <1>; - #size-cells = <0>; - - led@1 { - reg = <1>; - linux,default-trigger = "heartbeat"; - function = LED_FUNCTION_INDICATOR; - color = <LED_COLOR_ID_RED>; - }; - - led@2 { - reg = <2>; - function = LED_FUNCTION_INDICATOR; - color = <LED_COLOR_ID_GREEN>; - }; - - led@3 { - reg = <3>; - function = LED_FUNCTION_INDICATOR; - color = <LED_COLOR_ID_BLUE>; - }; -}; diff --git a/Documentation/devicetree/bindings/leds/leds-aw2013.yaml b/Documentation/devicetree/bindings/leds/leds-aw2013.yaml index 08f3e1cfc1b1..26238446f2bd 100644 --- a/Documentation/devicetree/bindings/leds/leds-aw2013.yaml +++ b/Documentation/devicetree/bindings/leds/leds-aw2013.yaml @@ -20,9 +20,20 @@ properties: reg: maxItems: 1 + interrupts: + maxItems: 1 + description: Open-drain, low active interrupt pin "INTN". + Used to report completion of operations (power up, LED breath effects). + vcc-supply: description: Regulator providing power to the "VCC" pin. + vio-supply: + description: Regulator providing power for pull-up of the I/O lines. + "VIO1" in the typical application circuit example of the datasheet. + Note that this regulator does not directly connect to AW2013, but is + needed for the correct operation of the interrupt and I2C lines. + "#address-cells": const: 1 @@ -52,6 +63,7 @@ additionalProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/leds/common.h> i2c { @@ -61,6 +73,7 @@ examples: led-controller@45 { compatible = "awinic,aw2013"; reg = <0x45>; + interrupts = <42 IRQ_TYPE_LEVEL_LOW>; #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 31840e33dcf5..e850a8894758 100644 --- a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml +++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml @@ -34,7 +34,7 @@ required: - color allOf: - - $ref: "common.yaml#" + - $ref: common.yaml# additionalProperties: true diff --git a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml new file mode 100644 index 000000000000..8ed059a5a724 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-group-multicolor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Multi-color LED built with monochromatic LEDs + +maintainers: + - Jean-Jacques Hiblot <jjhiblot@traphandler.com> + +description: | + This driver combines several monochromatic LEDs into one multi-color + LED using the multicolor LED class. + +properties: + compatible: + const: leds-group-multicolor + + leds: + description: + An aray of monochromatic leds + $ref: /schemas/types.yaml#/definitions/phandle-array + +required: + - leds + +allOf: + - $ref: leds-class-multicolor.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> + + monochromatic-leds { + compatible = "gpio-leds"; + + led0: led-0 { + gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>; + color = <LED_COLOR_ID_RED>; + }; + + led1: led-1 { + gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>; + color = <LED_COLOR_ID_GREEN>; + }; + + led2: led-2 { + gpios = <&mcu_pio 2 GPIO_ACTIVE_HIGH>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + + multi-led { + compatible = "leds-group-multicolor"; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_INDICATOR; + leds = <&led0>, <&led1>, <&led2>; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml index ae607911f1db..e9d4514d0166 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml @@ -66,6 +66,14 @@ properties: '#size-cells': const: 0 + ti,charge-pump-mode: + description: + Set the operating mode of the internal charge pump as defined in + <dt-bindings/leds/leds-lp55xx.h>. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 3 # auto + maximum: 3 + patternProperties: '^multi-led@[0-8]$': type: object @@ -98,7 +106,7 @@ patternProperties: max-cur: $ref: /schemas/types.yaml#/definitions/uint8 - description: Maximun current at each LED channel. + description: Maximum current at each LED channel. reg: maximum: 8 @@ -121,7 +129,7 @@ patternProperties: max-cur: $ref: /schemas/types.yaml#/definitions/uint8 - description: Maximun current at each LED channel. + description: Maximum current at each LED channel. reg: description: | @@ -152,6 +160,7 @@ additionalProperties: false examples: - | #include <dt-bindings/leds/common.h> + #include <dt-bindings/leds/leds-lp55xx.h> i2c { #address-cells = <1>; @@ -164,6 +173,7 @@ examples: reg = <0x32>; clock-mode = /bits/ 8 <2>; pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */ + ti,charge-pump-mode = <LP55XX_CP_BYPASS>; led@0 { reg = <0>; diff --git a/Documentation/devicetree/bindings/leds/leds-mt6323.txt b/Documentation/devicetree/bindings/leds/leds-mt6323.txt index 73353692efa1..052dccb8f2ce 100644 --- a/Documentation/devicetree/bindings/leds/leds-mt6323.txt +++ b/Documentation/devicetree/bindings/leds/leds-mt6323.txt @@ -12,7 +12,10 @@ For MediaTek PMIC wrapper bindings see: Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml Required properties: -- compatible : Must be "mediatek,mt6323-led" +- compatible : Must be one of + - "mediatek,mt6323-led" + - "mediatek,mt6331-led" + - "mediatek,mt6332-led" - address-cells : Must be 1 - size-cells : Must be 0 diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml index 6295c91f43e8..ea84ad426df1 100644 --- a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml @@ -16,18 +16,24 @@ description: > properties: compatible: - enum: - - qcom,pm660l-lpg - - qcom,pm8150b-lpg - - qcom,pm8150l-lpg - - qcom,pm8350c-pwm - - qcom,pm8916-pwm - - qcom,pm8941-lpg - - qcom,pm8994-lpg - - qcom,pmc8180c-lpg - - qcom,pmi8994-lpg - - qcom,pmi8998-lpg - - qcom,pmk8550-pwm + oneOf: + - enum: + - qcom,pm660l-lpg + - qcom,pm8150b-lpg + - qcom,pm8150l-lpg + - qcom,pm8350c-pwm + - qcom,pm8916-pwm + - qcom,pm8941-lpg + - qcom,pm8994-lpg + - qcom,pmc8180c-lpg + - qcom,pmi632-lpg + - qcom,pmi8994-lpg + - qcom,pmi8998-lpg + - qcom,pmk8550-pwm + - items: + - enum: + - qcom,pm8550-pwm + - const: qcom,pm8350c-pwm "#pwm-cells": const: 2 @@ -50,7 +56,7 @@ properties: description: > A list of integer pairs, where each pair represent the dtest line the particular channel should be connected to and the flags denoting how the - value should be outputed, as defined in the datasheet. The number of + value should be outputted, as defined in the datasheet. The number of pairs should be the same as the number of channels. items: items: diff --git a/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml b/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml index 4d2ffe5fcfc7..37d2a93780ab 100644 --- a/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml +++ b/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml @@ -20,6 +20,7 @@ properties: compatible: enum: - ocs,ocp8110 + - richtek,rt5033-led - sgmicro,sgm3140 enable-gpios: diff --git a/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml b/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml index edf6f55df685..9610bca57dd5 100644 --- a/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml +++ b/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml @@ -29,6 +29,10 @@ properties: gpio-controller: true + gpio-line-names: + minItems: 1 + maxItems: 16 + '#gpio-cells': const: 2 diff --git a/Documentation/devicetree/bindings/leds/nxp,pca995x.yaml b/Documentation/devicetree/bindings/leds/nxp,pca995x.yaml new file mode 100644 index 000000000000..654915c1f687 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/nxp,pca995x.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/nxp,pca995x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP PCA995x LED controllers + +maintainers: + - Isai Gaspar <isaiezequiel.gaspar@nxp.com> + - Marek Vasut <marex@denx.de> + +description: + The NXP PCA9952/PCA9955B are programmable LED controllers connected via I2C + that can drive 16 separate lines. Each of them can be individually switched + on and off, and brightness can be controlled via individual PWM. + + Datasheets are available at + https://www.nxp.com/docs/en/data-sheet/PCA9952_PCA9955.pdf + https://www.nxp.com/docs/en/data-sheet/PCA9955B.pdf + +properties: + compatible: + enum: + - nxp,pca9952 + - nxp,pca9955b + + 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: 15 + + required: + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@1 { + compatible = "nxp,pca9955b"; + reg = <0x01>; + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0x0>; + color = <LED_COLOR_ID_RED>; + function = LED_FUNCTION_POWER; + }; + + led@2 { + reg = <0x2>; + color = <LED_COLOR_ID_WHITE>; + function = LED_FUNCTION_STATUS; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/panasonic,an30259a.yaml b/Documentation/devicetree/bindings/leds/panasonic,an30259a.yaml new file mode 100644 index 000000000000..e918dceea082 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/panasonic,an30259a.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/panasonic,an30259a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Panasonic AN30259A 3-channel LED controller + +maintainers: + - Iskren Chernev <me@iskren.info> + +description: + The AN30259A is a LED controller capable of driving three LEDs independently. + It supports constant current output and sloping current output modes. The chip + is connected over I2C. + +properties: + compatible: + const: panasonic,an30259a + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^led@[1-3]$": + $ref: common.yaml# + unevaluatedProperties: false + + properties: + reg: + enum: [ 1, 2, 3 ] + +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@30 { + compatible = "panasonic,an30259a"; + reg = <0x30>; + #address-cells = <1>; + #size-cells = <0>; + + led@1 { + reg = <1>; + linux,default-trigger = "heartbeat"; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_RED>; + }; + + led@2 { + reg = <2>; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_GREEN>; + }; + + led@3 { + reg = <3>; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_BLUE>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml b/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml index ffacf703d9f9..a8736fd5a539 100644 --- a/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml +++ b/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml @@ -26,6 +26,8 @@ properties: - qcom,pm8150c-flash-led - qcom,pm8150l-flash-led - qcom,pm8350c-flash-led + - qcom,pm8550-flash-led + - qcom,pmi8998-flash-led - const: qcom,spmi-flash-led reg: diff --git a/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml b/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml index 14700a2e5fea..44dd91aa239d 100644 --- a/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml +++ b/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml @@ -35,7 +35,7 @@ properties: description: GPIO pin to enable/disable the device. patternProperties: - "^led@[0-6]$": + "^led@[0-5]$": type: object $ref: common.yaml# unevaluatedProperties: false @@ -43,7 +43,7 @@ patternProperties: properties: reg: minimum: 0 - maximum: 6 + maximum: 5 required: - reg diff --git a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml index 64b0be9cf70b..b7a3ef76cbf4 100644 --- a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml +++ b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml @@ -18,8 +18,6 @@ description: | The device has two LED outputs referred as GRNLED and AMBLED in data-sheet. -select: false - properties: compatible: const: rohm,bd71828-leds @@ -32,7 +30,7 @@ patternProperties: properties: rohm,led-compatible: description: LED identification string - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string enum: - bd71828-ambled - bd71828-grnled diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt deleted file mode 100644 index b48d7d30012c..000000000000 --- a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt +++ /dev/null @@ -1,26 +0,0 @@ -Broadcom BCM2835 VideoCore mailbox IPC - -Required properties: - -- compatible: Should be "brcm,bcm2835-mbox" -- reg: Specifies base physical address and size of the registers -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt -- #mbox-cells: Specifies the number of cells needed to encode a mailbox - channel. The value shall be 0, since there is only one - mailbox channel implemented by the device. - -Example: - -mailbox: mailbox@7e00b880 { - compatible = "brcm,bcm2835-mbox"; - reg = <0x7e00b880 0x40>; - interrupts = <0 1>; - #mbox-cells = <0>; -}; - -firmware: firmware { - compatible = "raspberrypi,firmware"; - mboxes = <&mailbox>; - #power-domain-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.yaml b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.yaml new file mode 100644 index 000000000000..9588817f4511 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/brcm,bcm2835-mbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM2835 VideoCore mailbox IPC + +maintainers: + - Stefan Wahren <stefan.wahren@i2se.com> + +properties: + compatible: + const: brcm,bcm2835-mbox + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#mbox-cells": + const: 0 + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + mailbox@7e00b880 { + compatible = "brcm,bcm2835-mbox"; + reg = <0x7e00b880 0x40>; + interrupts = <0 1>; + #mbox-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt index 752ae6b00d26..c80065a1eb97 100644 --- a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt +++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt @@ -29,7 +29,7 @@ Required properties: where N is the value specified by 2nd cell above. If FlexRM does not get required number of completion messages in time specified by this cell then it will inject one MSI interrupt - to CPU provided atleast one completion message is available. + to CPU provided at least one completion message is available. Optional properties: -------------------- diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml index a3e87516d637..2d14fc948999 100644 --- a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml +++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml @@ -66,6 +66,7 @@ properties: oneOf: - const: nvidia,tegra186-hsp - const: nvidia,tegra194-hsp + - const: nvidia,tegra264-hsp - items: - const: nvidia,tegra234-hsp - const: nvidia,tegra194-hsp diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 32d7bbc98cac..d2e25ff6db7f 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -18,6 +18,7 @@ properties: oneOf: - items: - enum: + - qcom,ipq5018-apcs-apps-global - qcom,ipq5332-apcs-apps-global - qcom,ipq8074-apcs-apps-global - qcom,ipq9574-apcs-apps-global diff --git a/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml index d433e496ec6e..1a2001e58880 100644 --- a/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/mailbox/ti,omap-mailbox.yaml# @@ -159,7 +159,7 @@ properties: a corresponding sysc interconnect node. This property is only needed on some legacy OMAP SoCs which have not - yet been converted to the ti,sysc interconnect hierarachy, but is + yet been converted to the ti,sysc interconnect hierarchy, but is otherwise considered obsolete. patternProperties: diff --git a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml index 374ffe64016f..aeaddbf574b0 100644 --- a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml @@ -33,7 +33,7 @@ description: | +------------------------------------------+ maintainers: - - Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> + - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/media/amphion,vpu.yaml b/Documentation/devicetree/bindings/media/amphion,vpu.yaml index a9d80eaeeeb6..c0d83d755239 100644 --- a/Documentation/devicetree/bindings/media/amphion,vpu.yaml +++ b/Documentation/devicetree/bindings/media/amphion,vpu.yaml @@ -47,7 +47,7 @@ patternProperties: $ref: ../mailbox/fsl,mu.yaml# - "^vpu_core@[0-9a-f]+$": + "^vpu-core@[0-9a-f]+$": description: Each core correspond a decoder or encoder, need to configure them separately. NXP i.MX8QM SoC has one decoder and two encoder, i.MX8QXP SoC @@ -143,7 +143,7 @@ examples: power-domains = <&pd IMX_SC_R_VPU_MU_2>; }; - vpu_core0: vpu_core@2d080000 { + vpu_core0: vpu-core@2d080000 { compatible = "nxp,imx8q-vpu-decoder"; reg = <0x2d080000 0x10000>; power-domains = <&pd IMX_SC_R_VPU_DEC_0>; @@ -154,7 +154,7 @@ examples: memory-region = <&decoder_boot>, <&decoder_rpc>; }; - vpu_core1: vpu_core@2d090000 { + vpu_core1: vpu-core@2d090000 { compatible = "nxp,imx8q-vpu-encoder"; reg = <0x2d090000 0x10000>; power-domains = <&pd IMX_SC_R_VPU_ENC_0>; @@ -165,7 +165,7 @@ examples: memory-region = <&encoder1_boot>, <&encoder1_rpc>; }; - vpu_core2: vpu_core@2d0a0000 { + vpu_core2: vpu-core@2d0a0000 { reg = <0x2d0a0000 0x10000>; compatible = "nxp,imx8q-vpu-encoder"; power-domains = <&pd IMX_SC_R_VPU_ENC_1>; diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt deleted file mode 100644 index 6b02a0657ad9..000000000000 --- a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt +++ /dev/null @@ -1,100 +0,0 @@ -Cadence MIPI-CSI2 RX controller -=============================== - -The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI -lanes in input, and 4 different pixel streams in output. - -Required properties: - - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible - - reg: base address and size of the memory mapped region - - clocks: phandles to the clocks driving the controller - - clock-names: must contain: - * sys_clk: main clock - * p_clk: register bank clock - * pixel_if[0-3]_clk: pixel stream output clock, one for each stream - implemented in hardware, between 0 and 3 - -Optional properties: - - phys: phandle to the external D-PHY, phy-names must be provided - - phy-names: must contain "dphy", if the implementation uses an - external D-PHY - -Required subnodes: - - ports: A ports node with one port child node per device input and output - port, in accordance with the video interface bindings defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. The - port nodes are numbered as follows: - - Port Description - ----------------------------- - 0 CSI-2 input - 1 Stream 0 output - 2 Stream 1 output - 3 Stream 2 output - 4 Stream 3 output - - The stream output port nodes are optional if they are not - connected to anything at the hardware level or implemented - in the design.Since there is only one endpoint per port, - the endpoints are not numbered. - - -Example: - -csi2rx: csi-bridge@0d060000 { - compatible = "cdns,csi2rx"; - reg = <0x0d060000 0x1000>; - clocks = <&byteclock>, <&byteclock> - <&coreclock>, <&coreclock>, - <&coreclock>, <&coreclock>; - clock-names = "sys_clk", "p_clk", - "pixel_if0_clk", "pixel_if1_clk", - "pixel_if2_clk", "pixel_if3_clk"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - csi2rx_in_sensor: endpoint { - remote-endpoint = <&sensor_out_csi2rx>; - clock-lanes = <0>; - data-lanes = <1 2>; - }; - }; - - port@1 { - reg = <1>; - - csi2rx_out_grabber0: endpoint { - remote-endpoint = <&grabber0_in_csi2rx>; - }; - }; - - port@2 { - reg = <2>; - - csi2rx_out_grabber1: endpoint { - remote-endpoint = <&grabber1_in_csi2rx>; - }; - }; - - port@3 { - reg = <3>; - - csi2rx_out_grabber2: endpoint { - remote-endpoint = <&grabber2_in_csi2rx>; - }; - }; - - port@4 { - reg = <4>; - - csi2rx_out_grabber3: endpoint { - remote-endpoint = <&grabber3_in_csi2rx>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml new file mode 100644 index 000000000000..30a335b10762 --- /dev/null +++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml @@ -0,0 +1,201 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/cdns,csi2rx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence MIPI-CSI2 RX controller + +maintainers: + - Maxime Ripard <mripard@kernel.org> + +description: + The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI + lanes in input, and 4 different pixel streams in output. + +properties: + compatible: + items: + - enum: + - starfive,jh7110-csi2rx + - const: cdns,csi2rx + + reg: + maxItems: 1 + + clocks: + items: + - description: CSI2Rx system clock + - description: Gated Register bank clock for APB interface + - description: pixel Clock for Stream interface 0 + - description: pixel Clock for Stream interface 1 + - description: pixel Clock for Stream interface 2 + - description: pixel Clock for Stream interface 3 + + clock-names: + items: + - const: sys_clk + - const: p_clk + - const: pixel_if0_clk + - const: pixel_if1_clk + - const: pixel_if2_clk + - const: pixel_if3_clk + + resets: + items: + - description: CSI2Rx system reset + - description: Gated Register bank reset for APB interface + - description: pixel reset for Stream interface 0 + - description: pixel reset for Stream interface 1 + - description: pixel reset for Stream interface 2 + - description: pixel reset for Stream interface 3 + + reset-names: + items: + - const: sys + - const: reg_bank + - const: pixel_if0 + - const: pixel_if1 + - const: pixel_if2 + - const: pixel_if3 + + phys: + maxItems: 1 + description: MIPI D-PHY + + phy-names: + items: + - const: dphy + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port node, single endpoint describing the CSI-2 transmitter. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + bus-type: + const: 4 + + clock-lanes: + const: 0 + + data-lanes: + minItems: 1 + maxItems: 4 + items: + maximum: 4 + + required: + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Stream 0 Output port node + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: + Stream 1 Output port node + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: + Stream 2 Output port node + + port@4: + $ref: /schemas/graph.yaml#/properties/port + description: + Stream 3 Output port node + + required: + - port@0 + +required: + - compatible + - reg + - clocks + - clock-names + - ports + +additionalProperties: false + +examples: + - | + csi@d060000 { + compatible = "starfive,jh7110-csi2rx", "cdns,csi2rx"; + reg = <0x0d060000 0x1000>; + clocks = <&byteclock 7>, <&byteclock 6>, + <&coreclock 8>, <&coreclock 9>, + <&coreclock 10>, <&coreclock 11>; + clock-names = "sys_clk", "p_clk", + "pixel_if0_clk", "pixel_if1_clk", + "pixel_if2_clk", "pixel_if3_clk"; + resets = <&bytereset 9>, <&bytereset 4>, + <&corereset 5>, <&corereset 6>, + <&corereset 7>, <&corereset 8>; + reset-names = "sys", "reg_bank", + "pixel_if0", "pixel_if1", + "pixel_if2", "pixel_if3"; + phys = <&csi_phy>; + phy-names = "dphy"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + csi2rx_in_sensor: endpoint { + remote-endpoint = <&sensor_out_csi2rx>; + clock-lanes = <0>; + data-lanes = <1 2>; + }; + }; + + port@1 { + reg = <1>; + + csi2rx_out_grabber0: endpoint { + remote-endpoint = <&grabber0_in_csi2rx>; + }; + }; + + port@2 { + reg = <2>; + + csi2rx_out_grabber1: endpoint { + remote-endpoint = <&grabber1_in_csi2rx>; + }; + }; + + port@3 { + reg = <3>; + + csi2rx_out_grabber2: endpoint { + remote-endpoint = <&grabber2_in_csi2rx>; + }; + }; + + port@4 { + reg = <4>; + + csi2rx_out_grabber3: endpoint { + remote-endpoint = <&grabber3_in_csi2rx>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml b/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml index 369c48fd9bf9..a6b73498bc21 100644 --- a/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml +++ b/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml @@ -53,6 +53,5 @@ examples: interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>; clocks = <&tegra_car TEGRA124_CLK_CEC>; clock-names = "cec"; - status = "disabled"; hdmi-phandle = <&hdmi>; }; diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml index 444f24838d3d..6c72e77b927c 100644 --- a/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml @@ -65,9 +65,14 @@ properties: properties: data-lanes: true + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY required: - data-lanes + - bus-type required: - port@4 @@ -82,6 +87,7 @@ additionalProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/media/video-interfaces.h> i2c@e6508000 { #address-cells = <1>; @@ -101,6 +107,7 @@ examples: port@4 { reg = <4>; max96712_out0: endpoint { + bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>; clock-lanes = <0>; data-lanes = <1 2 3 4>; remote-endpoint = <&csi40_in>; diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml index 19a39d753aad..b68141264c0e 100644 --- a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml +++ b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml @@ -143,7 +143,6 @@ examples: mipid02: csi2rx@14 { compatible = "st,st-mipid02"; reg = <0x14>; - status = "okay"; clocks = <&clk_ext_camera_12>; clock-names = "xclk"; VDDE-supply = <&vdd>; diff --git a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub913.yaml b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub913.yaml new file mode 100644 index 000000000000..f6612bb0f667 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub913.yaml @@ -0,0 +1,133 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ti,ds90ub913.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments DS90UB913 FPD-Link III Serializer + +maintainers: + - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> + +description: + The TI DS90UB913 is an FPD-Link III video serializer for parallel video. + +properties: + compatible: + enum: + - ti,ds90ub913a-q1 + + '#gpio-cells': + const: 2 + description: + First cell is the GPO pin number, second cell is the flags. The GPO pin + number must be in range of [0, 3]. Note that GPOs 2 and 3 are not + available in external oscillator mode. + + gpio-controller: true + + clocks: + maxItems: 1 + description: + Reference clock connected to the CLKIN pin. + + clock-names: + items: + - const: clkin + + '#clock-cells': + const: 0 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: Parallel input port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + required: + - pclk-sample + + port@1: + $ref: /schemas/graph.yaml#/properties/port + unevaluatedProperties: false + description: FPD-Link III output port + + required: + - port@0 + - port@1 + + i2c: + $ref: /schemas/i2c/i2c-controller.yaml# + unevaluatedProperties: false + +required: + - compatible + - '#gpio-cells' + - gpio-controller + - '#clock-cells' + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + serializer { + compatible = "ti,ds90ub913a-q1"; + + gpio-controller; + #gpio-cells = <2>; + + clocks = <&clk_cam_48M>; + clock-names = "clkin"; + + #clock-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + ub913_in: endpoint { + remote-endpoint = <&sensor_out>; + pclk-sample = <1>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&deser_fpd_in>; + }; + }; + }; + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@48 { + compatible = "aptina,mt9v111"; + reg = <0x48>; + + clocks = <&fixed_clock>; + + port { + sensor_out: endpoint { + remote-endpoint = <&ub913_in>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub953.yaml b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub953.yaml new file mode 100644 index 000000000000..2030366994d1 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub953.yaml @@ -0,0 +1,134 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ti,ds90ub953.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments DS90UB953 FPD-Link III Serializer + +maintainers: + - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> + +description: + The TI DS90UB953 is an FPD-Link III video serializer for MIPI CSI-2. + +properties: + compatible: + enum: + - ti,ds90ub953-q1 + - ti,ds90ub971-q1 + + '#gpio-cells': + const: 2 + description: + First cell is the GPIO pin number, second cell is the flags. The GPIO pin + number must be in range of [0, 3]. + + gpio-controller: true + + clocks: + maxItems: 1 + description: + Reference clock connected to the CLKIN pin. + + clock-names: + items: + - const: clkin + + '#clock-cells': + const: 0 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: CSI-2 input port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + required: + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/properties/port + unevaluatedProperties: false + description: FPD-Link III output port + + required: + - port@0 + - port@1 + + i2c: + $ref: /schemas/i2c/i2c-controller.yaml# + unevaluatedProperties: false + +required: + - compatible + - '#gpio-cells' + - gpio-controller + - '#clock-cells' + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + serializer { + compatible = "ti,ds90ub953-q1"; + + gpio-controller; + #gpio-cells = <2>; + + #clock-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + ub953_in: endpoint { + clock-lanes = <0>; + data-lanes = <1 2 3 4>; + remote-endpoint = <&sensor_out>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&deser_fpd_in>; + }; + }; + }; + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@1a { + compatible = "sony,imx274"; + reg = <0x1a>; + + reset-gpios = <&serializer 0 GPIO_ACTIVE_LOW>; + + clocks = <&serializer>; + clock-names = "inck"; + + port { + sensor_out: endpoint { + remote-endpoint = <&ub953_in>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml new file mode 100644 index 000000000000..289737721c2c --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml @@ -0,0 +1,427 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ti,ds90ub960.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments DS90UB9XX Family FPD-Link Deserializer Hubs + +maintainers: + - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> + +description: + The TI DS90UB9XX devices are FPD-Link video deserializers with I2C and GPIO + forwarding. + +allOf: + - $ref: /schemas/i2c/i2c-atr.yaml# + +properties: + compatible: + enum: + - ti,ds90ub960-q1 + - ti,ds90ub9702-q1 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + description: + Reference clock connected to the REFCLK pin. + + clock-names: + items: + - const: refclk + + powerdown-gpios: + maxItems: 1 + description: + Specifier for the GPIO connected to the PDB pin. + + i2c-alias-pool: + minItems: 1 + maxItems: 32 + + links: + type: object + additionalProperties: false + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + ti,manual-strobe: + type: boolean + description: + Enable manual strobe position and EQ level + + patternProperties: + '^link@[0-3]$': + type: object + additionalProperties: false + properties: + reg: + description: The link number + maxItems: 1 + + i2c-alias: + description: + The I2C address used for the serializer. Transactions to this + address on the I2C bus where the deserializer resides are + forwarded to the serializer. + + ti,rx-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # RAW10 + - 1 # RAW12 HF + - 2 # RAW12 LF + - 3 # CSI2 SYNC + - 4 # CSI2 NON-SYNC + description: + FPD-Link Input Mode. This should reflect the hardware and the + default mode of the connected device. + + ti,cdr-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # FPD-Link III + - 1 # FPD-Link IV + description: + FPD-Link CDR Mode. This should reflect the hardware and the + default mode of the connected device. + + ti,strobe-pos: + $ref: /schemas/types.yaml#/definitions/int32 + minimum: -13 + maximum: 13 + description: Manual strobe position + + ti,eq-level: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 14 + description: Manual EQ level + + serializer: + type: object + description: FPD-Link Serializer node + + required: + - reg + - i2c-alias + - ti,rx-mode + - serializer + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: FPD-Link input 0 + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + description: + Endpoint for FPD-Link port. If the RX mode for this port is RAW, + hsync-active and vsync-active must be defined. + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: FPD-Link input 1 + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + description: + Endpoint for FPD-Link port. If the RX mode for this port is RAW, + hsync-active and vsync-active must be defined. + + port@2: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: FPD-Link input 2 + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + description: + Endpoint for FPD-Link port. If the RX mode for this port is RAW, + hsync-active and vsync-active must be defined. + + port@3: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: FPD-Link input 3 + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + description: + Endpoint for FPD-Link port. If the RX mode for this port is RAW, + hsync-active and vsync-active must be defined. + + port@4: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: CSI-2 Output 0 + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + link-frequencies: + maxItems: 1 + + required: + - data-lanes + - link-frequencies + + port@5: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: CSI-2 Output 1 + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + link-frequencies: + maxItems: 1 + + required: + - data-lanes + - link-frequencies + + required: + - port@0 + - port@1 + - port@2 + - port@3 + - port@4 + - port@5 + +required: + - compatible + - reg + - clocks + - clock-names + - ports + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + clock-frequency = <400000>; + #address-cells = <1>; + #size-cells = <0>; + + deser@3d { + compatible = "ti,ds90ub960-q1"; + reg = <0x3d>; + + clock-names = "refclk"; + clocks = <&fixed_clock>; + + powerdown-gpios = <&pca9555 7 GPIO_ACTIVE_LOW>; + + i2c-alias-pool = <0x4a 0x4b 0x4c 0x4d 0x4e 0x4f>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + /* Port 0, Camera 0 */ + port@0 { + reg = <0>; + + ub960_fpd3_1_in: endpoint { + remote-endpoint = <&ub953_1_out>; + }; + }; + + /* Port 1, Camera 1 */ + port@1 { + reg = <1>; + + ub960_fpd3_2_in: endpoint { + remote-endpoint = <&ub913_2_out>; + hsync-active = <0>; + vsync-active = <1>; + }; + }; + + /* Port 2, unconnected */ + port@2 { + reg = <2>; + }; + + /* Port 3, unconnected */ + port@3 { + reg = <3>; + }; + + /* Port 4, CSI-2 TX */ + port@4 { + reg = <4>; + ds90ub960_0_csi_out: endpoint { + data-lanes = <1 2 3 4>; + link-frequencies = /bits/ 64 <800000000>; + remote-endpoint = <&csi2_phy0>; + }; + }; + + /* Port 5, unconnected */ + port@5 { + reg = <5>; + }; + }; + + links { + #address-cells = <1>; + #size-cells = <0>; + + /* Link 0 has DS90UB953 serializer and IMX274 sensor */ + + link@0 { + reg = <0>; + i2c-alias = <0x44>; + + ti,rx-mode = <3>; + + serializer1: serializer { + compatible = "ti,ds90ub953-q1"; + + gpio-controller; + #gpio-cells = <2>; + + #clock-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + ub953_1_in: endpoint { + data-lanes = <1 2 3 4>; + remote-endpoint = <&sensor_1_out>; + }; + }; + + port@1 { + reg = <1>; + + ub953_1_out: endpoint { + remote-endpoint = <&ub960_fpd3_1_in>; + }; + }; + }; + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@1a { + compatible = "sony,imx274"; + reg = <0x1a>; + + reset-gpios = <&serializer1 0 GPIO_ACTIVE_LOW>; + + port { + sensor_1_out: endpoint { + remote-endpoint = <&ub953_1_in>; + }; + }; + }; + }; + }; + }; /* End of link@0 */ + + /* Link 1 has DS90UB913 serializer and MT9V111 sensor */ + + link@1 { + reg = <1>; + i2c-alias = <0x45>; + + ti,rx-mode = <0>; + + serializer2: serializer { + compatible = "ti,ds90ub913a-q1"; + + gpio-controller; + #gpio-cells = <2>; + + clocks = <&clk_cam_48M>; + clock-names = "clkin"; + + #clock-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + ub913_2_in: endpoint { + remote-endpoint = <&sensor_2_out>; + pclk-sample = <1>; + }; + }; + + port@1 { + reg = <1>; + + ub913_2_out: endpoint { + remote-endpoint = <&ub960_fpd3_2_in>; + }; + }; + }; + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@48 { + compatible = "aptina,mt9v111"; + reg = <0x48>; + + clocks = <&serializer2>; + + port { + sensor_2_out: endpoint { + remote-endpoint = <&ub913_2_in>; + }; + }; + }; + }; + }; + }; /* End of link@1 */ + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml index b8ba85a2416c..c5cab549ee8e 100644 --- a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml @@ -12,7 +12,7 @@ maintainers: description: |- The Toshiba TC358746 converts a parallel video stream into a MIPI CSI-2 stream. The direction can be either parallel-in -> csi-out or csi-in -> - parallel-out The chip is programmable trough I2C and SPI but the SPI + parallel-out The chip is programmable through I2C and SPI but the SPI interface is only supported in parallel-in -> csi-out mode. Note that the current device tree bindings only support the diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt index 719b2995dc17..94b908ace53c 100644 --- a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt +++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt @@ -53,7 +53,7 @@ Optional Connector Properties: ============================== - sdtv-standards: Set the possible signals to which the hardware tries to lock - instead of using the autodetection mechnism. Please look at + instead of using the autodetection mechanism. Please look at [1] for more information. [1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml. diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml index fad59b486d5d..b401c67e3ba0 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml @@ -21,24 +21,33 @@ properties: - mediatek,mt8183-vcodec-dec reg: - maxItems: 12 + minItems: 11 + maxItems: 11 + + reg-names: + items: + - const: misc + - const: ld + - const: top + - const: cm + - const: ad + - const: av + - const: pp + - const: hwd + - const: hwq + - const: hwb + - const: hwg interrupts: maxItems: 1 clocks: + minItems: 1 maxItems: 8 clock-names: - items: - - const: vcodecpll - - const: univpll_d2 - - const: clk_cci400_sel - - const: vdec_sel - - const: vdecpll - - const: vencpll - - const: venc_lt_sel - - const: vdec_bus_clk_src + minItems: 1 + maxItems: 8 assigned-clocks: true @@ -66,6 +75,10 @@ properties: description: Describes point to scp. + mediatek,vdecsys: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to the vdecsys syscon node. + required: - compatible - reg @@ -73,8 +86,7 @@ required: - clocks - clock-names - iommus - - assigned-clocks - - assigned-clock-parents + - mediatek,vdecsys allOf: - if: @@ -88,6 +100,15 @@ allOf: required: - mediatek,scp + properties: + clocks: + minItems: 1 + maxItems: 1 + + clock-names: + items: + - const: vdec + - if: properties: compatible: @@ -99,6 +120,22 @@ allOf: required: - mediatek,vpu + properties: + clocks: + minItems: 8 + maxItems: 8 + + clock-names: + items: + - const: vcodecpll + - const: univpll_d2 + - const: clk_cci400_sel + - const: vdec_sel + - const: vdecpll + - const: vencpll + - const: venc_lt_sel + - const: vdec_bus_clk_src + additionalProperties: false examples: @@ -109,10 +146,9 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/power/mt8173-power.h> - vcodec_dec: vcodec@16000000 { + vcodec_dec: vcodec@16020000 { compatible = "mediatek,mt8173-vcodec-dec"; - reg = <0x16000000 0x100>, /*VDEC_SYS*/ - <0x16020000 0x1000>, /*VDEC_MISC*/ + reg = <0x16020000 0x1000>, /*VDEC_MISC*/ <0x16021000 0x800>, /*VDEC_LD*/ <0x16021800 0x800>, /*VDEC_TOP*/ <0x16022000 0x1000>, /*VDEC_CM*/ @@ -133,6 +169,7 @@ examples: <&iommu M4U_PORT_HW_VDEC_VLD_EXT>, <&iommu M4U_PORT_HW_VDEC_VLD2_EXT>; mediatek,vpu = <&vpu>; + mediatek,vdecsys = <&vdecsys>; power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>; clocks = <&apmixedsys CLK_APMIXED_VCODECPLL>, <&topckgen CLK_TOP_UNIVPLL_D2>, diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml index dca9b0c5e106..a500a585c692 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml @@ -36,7 +36,7 @@ description: | 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 deocder. Lat workqueue need to get input bitstream and lat buffer, + 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 diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml index 6038b9b5ab36..e4665469a86c 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,imx93-isi reg: maxItems: 1 @@ -72,7 +73,9 @@ allOf: properties: compatible: contains: - const: fsl,imx8mn-isi + enum: + - fsl,imx8mn-isi + - fsl,imx93-isi then: properties: interrupts: diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml index eb1499912c58..9cc0a968a401 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml @@ -155,7 +155,7 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/qcom,gcc-msm8916.h> - camss: camss@1b00000 { + camss: camss@1b0ac00 { compatible = "qcom,msm8916-camss"; clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>, diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml index 2350bf4b370e..9410f13ca97c 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml @@ -40,7 +40,7 @@ properties: properties: compatible: - const: "venus-decoder" + const: venus-decoder required: - compatible @@ -52,7 +52,7 @@ properties: properties: compatible: - const: "venus-encoder" + const: venus-encoder required: - compatible diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml index 8a10aa1cafc5..5cb0e337ea6e 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml @@ -221,7 +221,7 @@ examples: #include <dt-bindings/clock/qcom,gcc-msm8996.h> #include <dt-bindings/clock/qcom,mmcc-msm8996.h> - camss: camss@a00000 { + camss: camss@a34000 { compatible = "qcom,msm8996-camss"; clocks = <&mmcc CAMSS_TOP_AHB_CLK>, diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml index 0a109e126064..584106e275f6 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml @@ -227,7 +227,7 @@ examples: #include <dt-bindings/clock/qcom,gcc-sdm660.h> #include <dt-bindings/clock/qcom,mmcc-sdm660.h> - camss: camss@ca00000 { + camss: camss@ca00020 { compatible = "qcom,sdm660-camss"; clocks = <&mmcc CAMSS_AHB_CLK>, diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml index 1530ad0d80bd..ec4380a0a03f 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml @@ -219,7 +219,7 @@ examples: #address-cells = <2>; #size-cells = <2>; - camss: camss@a00000 { + camss: camss@acb3000 { compatible = "qcom,sdm845-camss"; clocks = <&clock_camcc CAM_CC_CAMNOC_AXI_CLK>, diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml index 7915dcd2d99f..f66033ae8b59 100644 --- a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml @@ -106,7 +106,7 @@ examples: #include <dt-bindings/clock/qcom,videocc-sm8250.h> #include <dt-bindings/interconnect/qcom,sm8250.h> #include <dt-bindings/clock/qcom,gcc-sm8250.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> venus: video-codec@aa00000 { compatible = "qcom,sm8250-venus"; @@ -114,7 +114,7 @@ examples: interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; power-domains = <&videocc MVS0C_GDSC>, <&videocc MVS0_GDSC>, - <&rpmhpd SM8250_MX>; + <&rpmhpd RPMHPD_MX>; power-domain-names = "venus", "vcodec0", "mx"; clocks = <&gcc GCC_VIDEO_AXI0_CLK>, diff --git a/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml b/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml index 7dde7967c886..1e72b8808d24 100644 --- a/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml +++ b/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml @@ -137,7 +137,7 @@ examples: cru_parallel_in: endpoint@0 { reg = <0>; - remote-endpoint= <&ov5642>; + remote-endpoint = <&ov5642>; hsync-active = <1>; vsync-active = <1>; }; @@ -150,7 +150,7 @@ examples: cru_csi_in: endpoint@0 { reg = <0>; - remote-endpoint= <&csi_cru_in>; + remote-endpoint = <&csi_cru_in>; }; }; }; diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml index 91e8f368fb52..324703bfb1bd 100644 --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml @@ -303,11 +303,11 @@ examples: vin0csi20: endpoint@0 { reg = <0>; - remote-endpoint= <&csi20vin0>; + remote-endpoint = <&csi20vin0>; }; vin0csi40: endpoint@2 { reg = <2>; - remote-endpoint= <&csi40vin0>; + remote-endpoint = <&csi40vin0>; }; }; }; diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.yaml b/Documentation/devicetree/bindings/media/rockchip-rga.yaml index dd645ddccb07..ea2342222408 100644 --- a/Documentation/devicetree/bindings/media/rockchip-rga.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-rga.yaml @@ -21,7 +21,9 @@ properties: - const: rockchip,rk3288-rga - const: rockchip,rk3399-rga - items: - - const: rockchip,rk3228-rga + - enum: + - rockchip,rk3228-rga + - rockchip,rk3568-rga - const: rockchip,rk3288-rga reg: diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index ee622a8ee1cc..772ec3283bc6 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -24,6 +24,7 @@ properties: - rockchip,rk3399-vpu - rockchip,px30-vpu - rockchip,rk3568-vpu + - rockchip,rk3588-av1-vpu - items: - const: rockchip,rk3188-vpu - const: rockchip,rk3066-vpu diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index 8eb90c043d5d..e69de29bb2d1 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -1,78 +0,0 @@ -* Samsung Multi Format Codec (MFC) - -Multi Format Codec (MFC) is the IP present in Samsung SoCs which -supports high resolution decoding and encoding functionalities. -The MFC device driver is a v4l2 driver which can encode/decode -video raw/elementary streams and has support for all popular -video codecs. - -Required properties: - - compatible : value should be either one among the following - (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs - (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs - (c) "samsung,exynos3250-mfc", "samsung,mfc-v7" for MFC v7 - present in Exynos3250 SoC - (d) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC - (e) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC - (f) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC - (g) "samsung,mfc-v10" for MFC v10 present in Exynos7880 SoC - - - reg : Physical base address of the IP registers and length of memory - mapped region. - - - interrupts : MFC interrupt number to the CPU. - - clocks : from common clock binding: handle to mfc clock. - - clock-names : from common clock binding: must contain "mfc", - corresponding to entry in the clocks property. - -Optional properties: - - power-domains : power-domain property defined with a phandle - to respective power domain. - - memory-region : from reserved memory binding: phandles to two reserved - memory regions, first is for "left" mfc memory bus interfaces, - second if for the "right" mfc memory bus, used when no SYSMMU - support is available; used only by MFC v5 present in Exynos4 SoCs - -Obsolete properties: - - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region - property instead - - -Example: -SoC specific DT entry: - -mfc: codec@13400000 { - compatible = "samsung,mfc-v5"; - reg = <0x13400000 0x10000>; - interrupts = <0 94 0>; - power-domains = <&pd_mfc>; - clocks = <&clock 273>; - clock-names = "mfc"; -}; - -Reserved memory specific DT entry for given board (see reserved memory binding -for more information): - -reserved-memory { - #address-cells = <1>; - #size-cells = <1>; - ranges; - - mfc_left: region@51000000 { - compatible = "shared-dma-pool"; - no-map; - reg = <0x51000000 0x800000>; - }; - - mfc_right: region@43000000 { - compatible = "shared-dma-pool"; - no-map; - reg = <0x43000000 0x800000>; - }; -}; - -Board specific DT entry: - -codec@13400000 { - memory-region = <&mfc_left>, <&mfc_right>; -}; diff --git a/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml b/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml new file mode 100644 index 000000000000..084b44582a43 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,s5p-mfc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos Multi Format Codec (MFC) + +maintainers: + - Marek Szyprowski <m.szyprowski@samsung.com> + - Aakarsh Jain <aakarsh.jain@samsung.com> + +description: + Multi Format Codec (MFC) is the IP present in Samsung SoCs which + supports high resolution decoding and encoding functionalities. + +properties: + compatible: + oneOf: + - enum: + - samsung,exynos5433-mfc # Exynos5433 + - samsung,mfc-v5 # Exynos4 + - samsung,mfc-v6 # Exynos5 + - samsung,mfc-v7 # Exynos5420 + - samsung,mfc-v8 # Exynos5800 + - samsung,mfc-v10 # Exynos7880 + - items: + - enum: + - samsung,exynos3250-mfc # Exynos3250 + - const: samsung,mfc-v7 # Fall back for Exynos3250 + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 3 + + clock-names: + minItems: 1 + maxItems: 3 + + interrupts: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 2 + + iommu-names: + minItems: 1 + maxItems: 2 + + power-domains: + maxItems: 1 + + memory-region: + minItems: 1 + maxItems: 2 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos3250-mfc + then: + properties: + clocks: + maxItems: 2 + clock-names: + items: + - const: mfc + - const: sclk_mfc + iommus: + maxItems: 1 + iommus-names: false + + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5433-mfc + then: + properties: + clocks: + maxItems: 3 + clock-names: + items: + - const: pclk + - const: aclk + - const: aclk_xiu + iommus: + maxItems: 2 + iommus-names: + items: + - const: left + - const: right + + - if: + properties: + compatible: + contains: + enum: + - samsung,mfc-v5 + then: + properties: + clocks: + maxItems: 2 + clock-names: + items: + - const: mfc + - const: sclk_mfc + iommus: + maxItems: 2 + iommus-names: + items: + - const: left + - const: right + + - if: + properties: + compatible: + contains: + enum: + - samsung,mfc-v6 + - samsung,mfc-v8 + then: + properties: + clocks: + maxItems: 1 + clock-names: + items: + - const: mfc + iommus: + maxItems: 2 + iommus-names: + items: + - const: left + - const: right + + - if: + properties: + compatible: + contains: + enum: + - samsung,mfc-v7 + then: + properties: + clocks: + minItems: 1 + maxItems: 2 + iommus: + minItems: 1 + maxItems: 2 + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/clock/exynos-audss-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + codec@13400000 { + compatible = "samsung,mfc-v5"; + reg = <0x13400000 0x10000>; + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&pd_mfc>; + clocks = <&clock CLK_MFC>, <&clock CLK_SCLK_MFC>; + clock-names = "mfc", "sclk_mfc"; + iommus = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>; + iommu-names = "left", "right"; + }; diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml index 7d77823dbb7a..43daf837fc9f 100644 --- a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx MIPI CSI-2 Receiver Subsystem maintainers: - - Vishal Sagar <vishal.sagar@xilinx.com> + - Vishal Sagar <vishal.sagar@amd.com> description: | The Xilinx MIPI CSI-2 Receiver Subsystem is used to capture MIPI CSI-2 diff --git a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml index a02724221ff3..b40cec0eb651 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml @@ -39,6 +39,7 @@ properties: patternProperties: ".*@[0-9]+$": type: object + $ref: mc-peripheral-props.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml index 5acfcad12bb7..8d9dae15ade0 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml @@ -34,6 +34,8 @@ required: # The controller specific properties go here. allOf: - $ref: st,stm32-fmc2-ebi-props.yaml# + - $ref: ingenic,nemc-peripherals.yaml# - $ref: intel,ixp4xx-expansion-peripheral-props.yaml# + - $ref: ti,gpmc-child.yaml# additionalProperties: true diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index aee7f6cf1300..2381660b324c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -67,7 +67,7 @@ properties: minimum: 0 maximum: 31 description: the hardware id of this larb. It's only required when this - hardward id is not consecutive from its M4U point of view. + hardware id is not consecutive from its M4U point of view. required: - compatible diff --git a/Documentation/devicetree/bindings/memory-controllers/nuvoton,npcm-memory-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/nuvoton,npcm-memory-controller.yaml new file mode 100644 index 000000000000..ac1a5a17749d --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/nuvoton,npcm-memory-controller.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/nuvoton,npcm-memory-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton NPCM Memory Controller + +maintainers: + - Marvin Lin <kflin@nuvoton.com> + - Stanley Chu <yschu@nuvoton.com> + +description: | + The Nuvoton BMC SoC supports DDR4 memory with or without ECC (error correction + check). + + The memory controller supports single bit error correction, double bit error + detection (in-line ECC in which a section (1/8th) of the memory device used to + store data is used for ECC storage). + + Note, the bootloader must configure ECC mode for the memory controller. + +properties: + compatible: + enum: + - nuvoton,npcm750-memory-controller + - nuvoton,npcm845-memory-controller + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mc: memory-controller@f0824000 { + compatible = "nuvoton,npcm750-memory-controller"; + reg = <0xf0824000 0x1000>; + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml index 2fa44951cfde..f54e553e6c0e 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml @@ -165,7 +165,7 @@ patternProperties: const: 0 lpddr2: - $ref: "ddr/jedec,lpddr2.yaml#" + $ref: ddr/jedec,lpddr2.yaml# type: object patternProperties: diff --git a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml index fb4920397d08..4e4af3cfc0fe 100644 --- a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml @@ -152,7 +152,7 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 description: When the DRAM type is DDR3, this parameter defines the phy side CA line - (incluing command line, address line and clock line) drive strength. + (including command line, address line and clock line) drive strength. default: 40 rockchip,phy_ddr3_dq_drv: @@ -305,7 +305,7 @@ properties: description: Defines the self-refresh power down idle period in which memories are placed into self-refresh power down mode if bus is idle for - srpd_lite_idle nanoseonds. This parameter is for LPDDR4 only. + srpd_lite_idle nanoseconds. This parameter is for LPDDR4 only. rockchip,standby-idle-ns: description: diff --git a/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml b/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml index e68c4306025a..87ff9ee098f5 100644 --- a/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml @@ -8,8 +8,7 @@ title: Synopsys DesignWare Universal Multi-Protocol Memory Controller maintainers: - Krzysztof Kozlowski <krzk@kernel.org> - - Manish Narani <manish.narani@xilinx.com> - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> description: | Synopsys DesignWare Enhanced uMCTL2 DDR Memory Controller is capable of diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml index bc9406929f6c..b049837ee669 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml @@ -129,7 +129,7 @@ patternProperties: The child device node represents the device connected to the GPMC bus. The device can be a NAND chip, SRAM device, NOR device or an ASIC. - $ref: "ti,gpmc-child.yaml" + $ref: ti,gpmc-child.yaml required: diff --git a/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml index 8f72e2f8588a..b74ad9a3305c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml @@ -8,12 +8,11 @@ title: Zynq A05 DDR Memory Controller maintainers: - Krzysztof Kozlowski <krzk@kernel.org> - - Manish Narani <manish.narani@xilinx.com> - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> description: The Zynq DDR ECC controller has an optional ECC support in half-bus width - (16-bit) configuration. It is cappable of correcting single bit ECC errors + (16-bit) configuration. It is capable of correcting single bit ECC errors and detecting double bit ECC errors. properties: diff --git a/Documentation/devicetree/bindings/mfd/adi,max77541.yaml b/Documentation/devicetree/bindings/mfd/adi,max77541.yaml new file mode 100644 index 000000000000..c7895b2c38c9 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/adi,max77541.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/adi,max77541.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MAX77540/MAX77541 PMIC from ADI + +maintainers: + - Okan Sahin <okan.sahin@analog.com> + +description: | + MAX77540 is a Power Management IC with 2 buck regulators. + + MAX77541 is a Power Management IC with 2 buck regulators and 1 ADC. + +properties: + compatible: + enum: + - adi,max77540 + - adi,max77541 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + regulators: + $ref: /schemas/regulator/adi,max77541-regulator.yaml# + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@69 { + compatible = "adi,max77541"; + reg = <0x69>; + interrupt-parent = <&gpio>; + interrupts = <16 IRQ_TYPE_EDGE_FALLING>; + + regulators { + buck1 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <5200000>; + regulator-boot-on; + regulator-always-on; + }; + buck2 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <5200000>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml b/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml index cf94176fe1eb..8789e3639ff7 100644 --- a/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml +++ b/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml @@ -34,6 +34,9 @@ patternProperties: - allwinner,sun6i-a31-clock-reset - fixed-factor-clock + required: + - compatible + allOf: - if: properties: @@ -55,25 +58,17 @@ patternProperties: "#clock-cells": const: 0 - # Already checked in the main schema - compatible: true - clocks: maxItems: 2 clock-output-names: maxItems: 1 - phandle: true - required: - "#clock-cells" - - compatible - clocks - clock-output-names - additionalProperties: false - - if: properties: compatible: @@ -85,25 +80,17 @@ patternProperties: "#clock-cells": const: 0 - # Already checked in the main schema - compatible: true - clocks: maxItems: 1 clock-output-names: maxItems: 1 - phandle: true - required: - "#clock-cells" - - compatible - clocks - clock-output-names - additionalProperties: false - - if: properties: compatible: @@ -119,9 +106,6 @@ patternProperties: offset of the bit controlling this particular gate in the register. - # Already checked in the main schema - compatible: true - clocks: maxItems: 1 @@ -129,16 +113,11 @@ patternProperties: minItems: 1 maxItems: 32 - phandle: true - required: - "#clock-cells" - - compatible - clocks - clock-output-names - additionalProperties: false - - if: properties: compatible: @@ -150,9 +129,6 @@ patternProperties: "#clock-cells": const: 0 - # Already checked in the main schema - compatible: true - clocks: maxItems: 4 description: > @@ -162,16 +138,11 @@ patternProperties: clock-output-names: maxItems: 1 - phandle: true - required: - "#clock-cells" - - compatible - clocks - clock-output-names - additionalProperties: false - - if: properties: compatible: @@ -183,16 +154,8 @@ patternProperties: "#reset-cells": const: 1 - # Already checked in the main schema - compatible: true - - phandle: true - required: - "#reset-cells" - - compatible - - additionalProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml b/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml index 16c80a7eec49..e51f85519911 100644 --- a/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml +++ b/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml @@ -57,25 +57,17 @@ patternProperties: "#clock-cells": const: 0 - # Already checked in the main schema - compatible: true - clocks: maxItems: 1 clock-output-names: maxItems: 1 - phandle: true - required: - "#clock-cells" - - compatible - clocks - clock-output-names - additionalProperties: false - - if: properties: compatible: @@ -91,9 +83,6 @@ patternProperties: offset of the bit controlling this particular gate in the register. - # Already checked in the main schema - compatible: true - clocks: maxItems: 1 @@ -101,16 +90,11 @@ patternProperties: minItems: 1 maxItems: 32 - phandle: true - required: - "#clock-cells" - - compatible - clocks - clock-output-names - additionalProperties: false - - if: properties: compatible: @@ -122,34 +106,8 @@ patternProperties: "#reset-cells": const: 1 - # Already checked in the main schema - compatible: true - - phandle: true - required: - "#reset-cells" - - compatible - - additionalProperties: false - - - if: - properties: - compatible: - contains: - const: allwinner,sun8i-a23-codec-analog - - then: - properties: - # Already checked in the main schema - compatible: true - - phandle: true - - required: - - compatible - - additionalProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml index 750996d9a175..5dfe77aca167 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml @@ -27,7 +27,7 @@ description: as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART management and bus snoop configuration. - * A set of SuperIO[3] scratch registers enableing implementation of e.g. custom + * A set of SuperIO[3] scratch registers enabling implementation of e.g. custom hardware management protocols for handover between the host and baseboard management controller. diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt index 9d837535637b..af692e8833a5 100644 --- a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt @@ -6,6 +6,7 @@ at boot time according to the device tree. Required properties: - compatible: Should be "atmel,sama5d2-flexcom" + or "microchip,sam9x7-flexcom", "atmel,sama5d2-flexcom" - reg: Should be the offset/length value for Flexcom dedicated I/O registers (without USART, TWI or SPI registers). - clocks: Should be the Flexcom peripheral clock from PMC. diff --git a/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt b/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt index e8c525569f10..3c989d1760a2 100644 --- a/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt +++ b/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt @@ -6,6 +6,7 @@ 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. diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt index 5f8880cc757e..7de696eefaed 100644 --- a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt +++ b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt @@ -8,6 +8,7 @@ Required properties: "atmel,sama5d3-hlcdc" "atmel,sama5d4-hlcdc" "microchip,sam9x60-hlcdc" + "microchip,sam9x75-xlcdc" - reg: base address and size of the HLCDC device registers. - clock-names: the name of the 3 clocks requested by the HLCDC device. Should contain "periph_clk", "sys_clk" and "slow_clk". diff --git a/Documentation/devicetree/bindings/mfd/atmel-matrix.txt b/Documentation/devicetree/bindings/mfd/atmel-matrix.txt index 89d05c64fb01..6e5f83614e83 100644 --- a/Documentation/devicetree/bindings/mfd/atmel-matrix.txt +++ b/Documentation/devicetree/bindings/mfd/atmel-matrix.txt @@ -14,6 +14,7 @@ Required properties: "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. diff --git a/Documentation/devicetree/bindings/mfd/atmel-smc.txt b/Documentation/devicetree/bindings/mfd/atmel-smc.txt index 5696d9fcb5dc..fd62add38a79 100644 --- a/Documentation/devicetree/bindings/mfd/atmel-smc.txt +++ b/Documentation/devicetree/bindings/mfd/atmel-smc.txt @@ -10,6 +10,7 @@ Required properties: "atmel,sama5d3-smc", "syscon" "atmel,sama5d2-smc", "syscon" "microchip,sam9x60-smc", "syscon" + "microchip,sam9x7-smc", "atmel,at91sam9260-smc", "syscon" - reg: Contains offset/length value of the SMC memory region. diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml index 148f1da47603..cb480162f967 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml @@ -35,16 +35,16 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm6345-gpio.yaml" + $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml description: GPIO controller for the SoC GPIOs. This child node definition should follow the bindings specified in - Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml. + Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml. "^pinctrl@[0-9a-f]+$": # Child node type: object - $ref: "../pinctrl/brcm,bcm6318-pinctrl.yaml" + $ref: /schemas/pinctrl/brcm,bcm6318-pinctrl.yaml description: Pin controller for the SoC pins. This child node definition should follow the bindings specified in diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml index 7e582243ea76..c14def1b2ad2 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml @@ -35,16 +35,16 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm6345-gpio.yaml" + $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml description: GPIO controller for the SoC GPIOs. This child node definition should follow the bindings specified in - Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml. + Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml. "^pinctrl@[0-9a-f]+$": # Child node type: object - $ref: "../pinctrl/brcm,bcm63268-pinctrl.yaml" + $ref: /schemas/pinctrl/brcm,bcm63268-pinctrl.yaml description: Pin controller for the SoC pins. This child node definition should follow the bindings specified in diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml index 2230848e11c3..5f48209ed40f 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml @@ -35,16 +35,16 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm6345-gpio.yaml" + $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml description: GPIO controller for the SoC GPIOs. This child node definition should follow the bindings specified in - Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml. + Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml. "^pinctrl@[0-9a-f]+$": # Child node type: object - $ref: "../pinctrl/brcm,bcm6328-pinctrl.yaml" + $ref: /schemas/pinctrl/brcm,bcm6328-pinctrl.yaml description: Pin controller for the SoC pins. This child node definition should follow the bindings specified in diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml index c06693b6f7aa..f1f4629565d9 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml @@ -35,16 +35,16 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm6345-gpio.yaml" + $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml description: GPIO controller for the SoC GPIOs. This child node definition should follow the bindings specified in - Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml. + Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml. "^pinctrl@[0-9a-f]+$": # Child node type: object - $ref: "../pinctrl/brcm,bcm6358-pinctrl.yaml" + $ref: /schemas/pinctrl/brcm,bcm6358-pinctrl.yaml description: Pin controller for the SoC pins. This child node definition should follow the bindings specified in diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml index c560bede0e37..4d594739b382 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml @@ -35,16 +35,16 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm6345-gpio.yaml" + $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml description: GPIO controller for the SoC GPIOs. This child node definition should follow the bindings specified in - Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml. + Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml. "^pinctrl@[0-9a-f]+$": # Child node type: object - $ref: "../pinctrl/brcm,bcm6362-pinctrl.yaml" + $ref: /schemas/pinctrl/brcm,bcm6362-pinctrl.yaml description: Pin controller for the SoC pins. This child node definition should follow the bindings specified in diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml index c534f5f2404e..aae83d432880 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml @@ -35,16 +35,16 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm6345-gpio.yaml" + $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml description: GPIO controller for the SoC GPIOs. This child node definition should follow the bindings specified in - Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml. + Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml. "^pinctrl@[0-9a-f]+$": # Child node type: object - $ref: "../pinctrl/brcm,bcm6368-pinctrl.yaml" + $ref: /schemas/pinctrl/brcm,bcm6368-pinctrl.yaml description: Pin controller for the SoC pins. This child node definition should follow the bindings specified in diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml index acb9c54942d9..dc379f3ebf24 100644 --- a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml +++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml @@ -122,12 +122,6 @@ patternProperties: compatible: const: gw,gsc-fan - "#address-cells": - const: 1 - - "#size-cells": - const: 0 - reg: description: The fan controller base address maxItems: 1 @@ -135,8 +129,6 @@ patternProperties: required: - compatible - reg - - "#address-cells" - - "#size-cells" required: - compatible @@ -194,8 +186,6 @@ examples: }; fan-controller@2c { - #address-cells = <1>; - #size-cells = <0>; compatible = "gw,gsc-fan"; reg = <0x2c>; }; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml index 1b06a77ec798..9804d13de648 100644 --- a/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml +++ b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml @@ -31,12 +31,17 @@ properties: charger: $ref: /schemas/power/supply/maxim,max77693.yaml + connector: + $ref: /schemas/connector/usb-connector.yaml# + unevaluatedProperties: false + led: $ref: /schemas/leds/maxim,max77693.yaml max77693-muic: type: object additionalProperties: false + deprecated: true properties: compatible: @@ -45,6 +50,21 @@ properties: required: - compatible + muic: + type: object + additionalProperties: false + + properties: + compatible: + const: maxim,max77693-muic + + connector: + $ref: /schemas/connector/usb-connector.yaml# + unevaluatedProperties: false + + required: + - compatible + motor-driver: type: object additionalProperties: false @@ -107,6 +127,38 @@ examples: }; }; + muic { + compatible = "maxim,max77693-muic"; + + connector { + compatible = "samsung,usb-connector-11pin", + "usb-b-connector"; + label = "micro-USB"; + type = "micro"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + muic_to_usb: endpoint { + remote-endpoint = <&usb_to_muic>; + }; + }; + + port@3 { + reg = <3>; + + muic_to_mhl: endpoint { + remote-endpoint = <&mhl_to_muic>; + }; + }; + }; + }; + }; + motor-driver { compatible = "maxim,max77693-haptic"; haptic-supply = <&ldo26_reg>; diff --git a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml index e6a2387d8650..9e4eed34dae8 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies, Inc. PM8008 PMIC maintainers: - - Guru Das Srinagesh <gurus@codeaurora.org> + - Guru Das Srinagesh <quic_gurus@quicinc.com> description: | Qualcomm Technologies, Inc. PM8008 is a dedicated camera PMIC that integrates diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml index 36de335a33aa..9f03436b1cdc 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml @@ -41,6 +41,7 @@ properties: - qcom,pm660 - qcom,pm660l - qcom,pm7250b + - qcom,pm7550ba - qcom,pm7325 - qcom,pm8004 - qcom,pm8005 @@ -70,7 +71,10 @@ properties: - qcom,pm8994 - qcom,pm8998 - qcom,pma8084 + - qcom,pmc8180 + - qcom,pmc8180c - qcom,pmd9635 + - qcom,pmi632 - qcom,pmi8950 - qcom,pmi8962 - qcom,pmi8994 @@ -87,6 +91,7 @@ properties: - qcom,pms405 - qcom,pmx55 - qcom,pmx65 + - qcom,pmx75 - qcom,smb2351 - const: qcom,spmi-pmic @@ -126,13 +131,14 @@ patternProperties: "^audio-codec@[0-9a-f]+$": type: object - additionalProperties: true # FIXME qcom,pm8916-wcd-analog-codec binding not converted yet + $ref: /schemas/sound/qcom,pm8916-wcd-analog-codec.yaml# "^charger@[0-9a-f]+$": type: object oneOf: - $ref: /schemas/power/supply/qcom,pm8941-charger.yaml# - $ref: /schemas/power/supply/qcom,pm8941-coincell.yaml# + - $ref: /schemas/power/supply/qcom,pmi8998-charger.yaml# "gpio@[0-9a-f]+$": type: object @@ -146,6 +152,10 @@ patternProperties: type: object $ref: /schemas/nvmem/qcom,spmi-sdam.yaml# + "phy@[0-9a-f]+$": + type: object + $ref: /schemas/phy/qcom,snps-eusb2-repeater.yaml# + "pon@[0-9a-f]+$": type: object $ref: /schemas/power/reset/qcom,pon.yaml# diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml index fe790af7b4fb..5ad9d5deaaf8 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml @@ -34,6 +34,7 @@ properties: - qcom,tcsr-ipq5332 - qcom,tcsr-ipq6018 - qcom,tcsr-ipq8064 + - qcom,tcsr-ipq8074 - qcom,tcsr-ipq9574 - qcom,tcsr-mdm9615 - qcom,tcsr-msm8226 diff --git a/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml new file mode 100644 index 000000000000..386b1a50158a --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml @@ -0,0 +1,138 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/richtek,rt5033.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT5033 Power Management Integrated Circuit + +maintainers: + - Jakob Hauser <jahau@rocketmail.com> + +description: + RT5033 is a multifunction device which includes battery charger, fuel gauge, + flash LED current source, LDO and synchronous Buck converter for portable + applications. It is interfaced to host controller using I2C interface. The + battery fuel gauge uses a separate I2C bus. + +properties: + compatible: + const: richtek,rt5033 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + regulators: + description: + The regulators of RT5033 have to be instantiated under a sub-node named + "regulators". For SAFE_LDO voltage there is only one value of 4.9 V. LDO + voltage ranges from 1.2 V to 3.0 V in 0.1 V steps. BUCK voltage ranges + from 1.0 V to 3.0 V in 0.1 V steps. + type: object + patternProperties: + "^(SAFE_LDO|LDO|BUCK)$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + additionalProperties: false + + charger: + type: object + $ref: /schemas/power/supply/richtek,rt5033-charger.yaml# + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + battery: battery { + compatible = "simple-battery"; + precharge-current-microamp = <450000>; + constant-charge-current-max-microamp = <1000000>; + charge-term-current-microamp = <150000>; + precharge-upper-limit-microvolt = <3500000>; + constant-charge-voltage-max-microvolt = <4350000>; + }; + + extcon { + usb_con: connector { + compatible = "usb-b-connector"; + label = "micro-USB"; + type = "micro"; + }; + }; + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + i2c@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + fuel-gauge@35 { + compatible = "richtek,rt5033-battery"; + reg = <0x35>; + + interrupt-parent = <&msmgpio>; + interrupts = <121 IRQ_TYPE_EDGE_FALLING>; + + pinctrl-names = "default"; + pinctrl-0 = <&fg_alert_default>; + + power-supplies = <&rt5033_charger>; + }; + }; + + i2c@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + + pmic@34 { + compatible = "richtek,rt5033"; + reg = <0x34>; + + interrupt-parent = <&msmgpio>; + interrupts = <62 IRQ_TYPE_EDGE_FALLING>; + + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int_default>; + + regulators { + safe_ldo_reg: SAFE_LDO { + regulator-name = "SAFE_LDO"; + regulator-min-microvolt = <4900000>; + regulator-max-microvolt = <4900000>; + regulator-always-on; + }; + ldo_reg: LDO { + regulator-name = "LDO"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + }; + buck_reg: BUCK { + regulator-name = "BUCK"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + }; + }; + + rt5033_charger: charger { + compatible = "richtek,rt5033-charger"; + monitored-battery = <&battery>; + richtek,usb-connector = <&usb_con>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml new file mode 100644 index 000000000000..cf2500f2e9a0 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml @@ -0,0 +1,406 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/rockchip,rk806.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RK806 Power Management Integrated Circuit + +maintainers: + - Sebastian Reichel <sebastian.reichel@collabora.com> + +description: + Rockchip RK806 series PMIC. This device consists of an spi or + i2c controlled MFD that includes multiple switchable regulators. + +properties: + compatible: + enum: + - rockchip,rk806 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + vcc1-supply: + description: + The input supply for dcdc-reg1. + + vcc2-supply: + description: + The input supply for dcdc-reg2. + + vcc3-supply: + description: + The input supply for dcdc-reg3. + + vcc4-supply: + description: + The input supply for dcdc-reg4. + + vcc5-supply: + description: + The input supply for dcdc-reg5. + + vcc6-supply: + description: + The input supply for dcdc-reg6. + + vcc7-supply: + description: + The input supply for dcdc-reg7. + + vcc8-supply: + description: + The input supply for dcdc-reg8. + + vcc9-supply: + description: + The input supply for dcdc-reg9. + + vcc10-supply: + description: + The input supply for dcdc-reg10. + + vcc11-supply: + description: + The input supply for pldo-reg1, pldo-reg2 and pldo-reg3. + + vcc12-supply: + description: + The input supply for pldo-reg4 and pldo-reg5. + + vcc13-supply: + description: + The input supply for nldo-reg1, nldo-reg2 and nldo-reg3. + + vcc14-supply: + description: + The input supply for nldo-reg4 and nldo-reg5. + + vcca-supply: + description: + The input supply for pldo-reg6. + + regulators: + type: object + additionalProperties: false + patternProperties: + "^(dcdc-reg([1-9]|10)|pldo-reg[1-6]|nldo-reg[1-5])$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + +patternProperties: + '-pins$': + type: object + additionalProperties: false + $ref: /schemas/pinctrl/pinmux-node.yaml + + properties: + function: + enum: [pin_fun0, pin_fun1, pin_fun2, pin_fun3, pin_fun4, pin_fun5] + + pins: + $ref: /schemas/types.yaml#/definitions/string + enum: [gpio_pwrctrl1, gpio_pwrctrl2, gpio_pwrctrl3] + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/rockchip.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + pmic@0 { + compatible = "rockchip,rk806"; + reg = <0x0>; + + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + + vcc1-supply = <&vcc5v0_sys>; + vcc2-supply = <&vcc5v0_sys>; + vcc3-supply = <&vcc5v0_sys>; + vcc4-supply = <&vcc5v0_sys>; + vcc5-supply = <&vcc5v0_sys>; + vcc6-supply = <&vcc5v0_sys>; + vcc7-supply = <&vcc5v0_sys>; + vcc8-supply = <&vcc5v0_sys>; + vcc9-supply = <&vcc5v0_sys>; + vcc10-supply = <&vcc5v0_sys>; + vcc11-supply = <&vcc_2v0_pldo_s3>; + vcc12-supply = <&vcc5v0_sys>; + vcc13-supply = <&vcc5v0_sys>; + vcc14-supply = <&vcc_1v1_nldo_s3>; + vcca-supply = <&vcc5v0_sys>; + + regulators { + vdd_gpu_s0: dcdc-reg1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <550000>; + regulator-max-microvolt = <950000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_gpu_s0"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_npu_s0: dcdc-reg2 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <550000>; + regulator-max-microvolt = <950000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_npu_s0"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_log_s0: dcdc-reg3 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <750000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_log_s0"; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <750000>; + }; + }; + + vdd_vdenc_s0: dcdc-reg4 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <550000>; + regulator-max-microvolt = <950000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_vdenc_s0"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_gpu_mem_s0: dcdc-reg5 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <675000>; + regulator-max-microvolt = <950000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_gpu_mem_s0"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_npu_mem_s0: dcdc-reg6 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <675000>; + regulator-max-microvolt = <950000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_npu_mem_s0"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc_2v0_pldo_s3: dcdc-reg7 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <2000000>; + regulator-max-microvolt = <2000000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_2v0_pldo_s3"; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <2000000>; + }; + }; + + vdd_vdenc_mem_s0: dcdc-reg8 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <675000>; + regulator-max-microvolt = <950000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_vdenc_mem_s0"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd2_ddr_s3: dcdc-reg9 { + regulator-always-on; + regulator-boot-on; + regulator-name = "vdd2_ddr_s3"; + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + vcc_1v1_nldo_s3: dcdc-reg10 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-ramp-delay = <12500>; + regulator-name = "vcc_1v1_nldo_s3"; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1100000>; + }; + }; + + avcc_1v8_s0: pldo-reg1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-ramp-delay = <12500>; + regulator-name = "avcc_1v8_s0"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd1_1v8_ddr_s3: pldo-reg2 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd1_1v8_ddr_s3"; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vcc_1v8_s3: pldo-reg3 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-ramp-delay = <12500>; + regulator-name = "vcc_1v8_s3"; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vcc_3v3_s0: pldo-reg4 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-ramp-delay = <12500>; + regulator-name = "vcc_3v3_s0"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vccio_sd_s0: pldo-reg5 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-ramp-delay = <12500>; + regulator-name = "vccio_sd_s0"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + master_pldo6_s3: pldo-reg6 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "master_pldo6_s3"; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vdd_0v75_s3: nldo-reg1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <750000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_0v75_s3"; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <750000>; + }; + }; + + vdd2l_0v9_ddr_s3: nldo-reg2 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <900000>; + regulator-name = "vdd2l_0v9_ddr_s3"; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <900000>; + }; + }; + + master_nldo3: nldo-reg3 { + regulator-name = "master_nldo3"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + avdd_0v75_s0: nldo-reg4 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <750000>; + regulator-name = "avdd_0v75_s0"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_0v85_s0: nldo-reg5 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <850000>; + regulator-max-microvolt = <850000>; + regulator-name = "vdd_0v85_s0"; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml index 7ab7b2c7f3e6..d783cc4e4e86 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml @@ -130,7 +130,6 @@ dependencies: examples: - | #include <dt-bindings/interrupt-controller/irq.h> - #include <dt-bindings/leds/common.h> i2c { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml index 10f207a38178..b7b323b1a4f2 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml @@ -34,7 +34,7 @@ properties: BD9576 and BD9573 VOUT1 regulator enable state can be individually controlled by a GPIO. This is dictated by state of vout1-en pin during the PMIC startup. If vout1-en is LOW during PMIC startup then the VOUT1 - enable sate is controlled via this pin. Set this property if vout1-en + enable state is controlled via this pin. Set this property if vout1-en is wired to be down at PMIC start-up. type: boolean @@ -61,7 +61,7 @@ properties: rohm,hw-timeout-ms: maxItems: 2 description: - Watchog timeout in milliseconds. If single value is given it is + Watchdog timeout in milliseconds. If single value is given it is the maximum timeout. Eg. if pinging watchdog is not done within this time limit the watchdog will be triggered. If two values are given watchdog is configured in "window mode". Then first value is limit for short-ping diff --git a/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml b/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml index 10c7b408f33a..aea0b7d57d04 100644 --- a/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml +++ b/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml @@ -153,29 +153,18 @@ dependencies: additionalProperties: false allOf: - - if: + - not: required: - s5m8767,pmic-buck2-uses-gpio-dvs - then: - properties: - s5m8767,pmic-buck3-uses-gpio-dvs: false - s5m8767,pmic-buck4-uses-gpio-dvs: false - - - if: - required: - s5m8767,pmic-buck3-uses-gpio-dvs - then: - properties: - s5m8767,pmic-buck2-uses-gpio-dvs: false - s5m8767,pmic-buck4-uses-gpio-dvs: false - - - if: + - not: required: + - s5m8767,pmic-buck2-uses-gpio-dvs + - s5m8767,pmic-buck4-uses-gpio-dvs + - not: + required: + - s5m8767,pmic-buck3-uses-gpio-dvs - s5m8767,pmic-buck4-uses-gpio-dvs - then: - properties: - s5m8767,pmic-buck2-uses-gpio-dvs: false - s5m8767,pmic-buck3-uses-gpio-dvs: false examples: - | diff --git a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml new file mode 100644 index 000000000000..b77cc3f3075d --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml @@ -0,0 +1,297 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/st,stmpe.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectonics Port Expander (STMPE) + +description: STMicroelectronics Port Expander (STMPE) is a series of slow + bus controllers for various expanded peripherals such as GPIO, keypad, + touchscreen, ADC, PWM or rotator. It can contain one or several different + peripherals connected to SPI or I2C. + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + enum: + - st,stmpe601 + - st,stmpe801 + - st,stmpe811 + - st,stmpe1600 + - st,stmpe1601 + - st,stmpe2401 + - st,stmpe2403 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vcc-supply: true + + vio-supply: true + + reset-gpios: + maxItems: 1 + + wakeup-source: true + + st,autosleep-timeout: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 4, 16, 32, 64, 128, 256, 512, 1024 ] + description: Time idle before going to automatic sleep to save power + + st,sample-time: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2, 3, 4, 5, 6 ] + description: | + Sample time per iteration + 0 = 36 clock ticks + 1 = 44 clock ticks + 2 = 56 clock ticks + 3 = 64 clock ticks + 4 = 80 clock ticks - recommended + 5 = 96 clock ticks + 6 = 124 clock ticks + + st,mod-12b: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1 ] + description: ADC bit mode 0 = 10bit ADC, 1 = 12bit ADC + + st,ref-sel: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1 ] + description: ADC reference source 0 = internal, 1 = external + + st,adc-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2, 3 ] + description: | + ADC clock speed + 0 = 1.625 MHz + 1 = 3.25 MHz + 2, 3 = 6.5 MHz + + adc: + type: object + $ref: /schemas/iio/adc/st,stmpe-adc.yaml# + + gpio: + type: object + $ref: /schemas/gpio/st,stmpe-gpio.yaml# + + keyboard-controller: + type: object + $ref: /schemas/input/matrix-keymap.yaml# + + unevaluatedProperties: false + + properties: + compatible: + const: st,stmpe-keypad + + debounce-interval: + description: Debouncing interval in milliseconds + $ref: /schemas/types.yaml#/definitions/uint32 + + st,no-autorepeat: + description: If present, the keys will not autorepeat when pressed + $ref: /schemas/types.yaml#/definitions/flag + + st,scan-count: + description: Scanning cycles elapsed before key data is updated + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - compatible + - linux,keymap + + pwm: + type: object + $ref: /schemas/pwm/pwm.yaml# + + unevaluatedProperties: false + + properties: + compatible: + const: st,stmpe-pwm + + "#pwm-cells": + const: 2 + + touchscreen: + type: object + $ref: /schemas/input/touchscreen/touchscreen.yaml# + + unevaluatedProperties: false + + properties: + compatible: + const: st,stmpe-ts + + st,ave-ctrl: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2, 3 ] + description: | + Sample average control + 0 = 1 sample + 1 = 2 samples + 2 = 4 samples + 3 = 8 samples + + st,touch-det-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ] + description: | + Touch detection delay + 0 = 10 us + 1 = 50 us + 2 = 100 us + 3 = 500 us - recommended + 4 = 1 ms + 5 = 5 ms + 6 = 10 ms + 7 = 50 ms + + st,settling: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ] + description: | + Panel driver settling time + 0 = 10 us + 1 = 100 us + 2 = 500 us - recommended + 3 = 1 ms + 4 = 5 ms + 5 = 10 ms + 6 = 50 ms + 7 = 100 ms + + st,fraction-z: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ] + description: Length of the fractional part in z, recommended is 7 + (fraction-z ([0..7]) = Count of the fractional part) + + st,i-drive: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1 ] + description: | + current limit value of the touchscreen drivers + 0 = 20 mA (typical 35 mA max) + 1 = 50 mA (typical 80 mA max) + + required: + - compatible + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/input/input.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + port-expander@43 { + compatible = "st,stmpe2401"; + reg = <0x43>; + reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>; + interrupts = <26 IRQ_TYPE_EDGE_FALLING>; + interrupt-parent = <&gpio>; + vcc-supply = <&db8500_vsmps2_reg>; + vio-supply = <&db8500_vsmps2_reg>; + wakeup-source; + st,autosleep-timeout = <1024>; + + gpio { + compatible = "st,stmpe-gpio"; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + st,norequest-mask = <0xf0f002>; + }; + + keyboard-controller { + compatible = "st,stmpe-keypad"; + debounce-interval = <64>; + st,scan-count = <8>; + st,no-autorepeat; + keypad,num-rows = <8>; + keypad,num-columns = <8>; + linux,keymap = < + MATRIX_KEY(0x00, 0x00, KEY_1) + MATRIX_KEY(0x00, 0x01, KEY_2) + MATRIX_KEY(0x00, 0x02, KEY_3) + MATRIX_KEY(0x00, 0x03, KEY_4) + MATRIX_KEY(0x00, 0x04, KEY_5) + MATRIX_KEY(0x00, 0x05, KEY_6) + MATRIX_KEY(0x00, 0x06, KEY_7) + MATRIX_KEY(0x00, 0x07, KEY_8) + MATRIX_KEY(0x00, 0x08, KEY_9) + MATRIX_KEY(0x00, 0x09, KEY_0) + >; + }; + + pwm { + compatible = "st,stmpe-pwm"; + #pwm-cells = <2>; + }; + }; + + port-expander@41 { + compatible = "st,stmpe811"; + reg = <0x41>; + interrupts = <10 IRQ_TYPE_LEVEL_LOW>; + interrupt-parent = <&gpio>; + st,adc-freq = <1>; + st,mod-12b = <1>; + st,ref-sel = <0>; + st,sample-time = <4>; + + adc { + compatible = "st,stmpe-adc"; + st,norequest-mask = <0x0f>; + #io-channel-cells = <1>; + }; + + gpio { + compatible = "st,stmpe-gpio"; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + pwm { + compatible = "st,stmpe-pwm"; + #pwm-cells = <2>; + }; + + touchscreen { + compatible = "st,stmpe-ts"; + st,ave-ctrl = <3>; + st,touch-det-delay = <5>; + st,settling = <3>; + st,fraction-z = <7>; + st,i-drive = <1>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml index 9573e4af949e..b17ebeb0a42f 100644 --- a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml @@ -106,6 +106,7 @@ properties: const: st,stpmic1-regulators ldo3: + $ref: /schemas/regulator/regulator.yaml type: object properties: @@ -128,6 +129,7 @@ properties: additionalProperties: false ldo4: + $ref: /schemas/regulator/regulator.yaml type: object properties: @@ -142,11 +144,14 @@ properties: regulator-name: true regulator-boot-on: true regulator-always-on: true + regulator-min-microvolt: true + regulator-max-microvolt: true regulator-over-current-protection: true additionalProperties: false vref_ddr: + $ref: /schemas/regulator/regulator.yaml type: object properties: @@ -165,6 +170,7 @@ properties: additionalProperties: false boost: + $ref: /schemas/regulator/regulator.yaml type: object properties: @@ -184,13 +190,11 @@ properties: additionalProperties: false patternProperties: - "^(buck[1-4]|ldo[1-6]|boost|pwr_sw[1-2])-supply$": + "^(buck[1-4]|ldo[1-6]|vref_ddr|boost|pwr_sw[1-2])-supply$": description: STPMIC1 voltage regulators supplies - "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])$": - $ref: ../regulator/regulator.yaml - "^ldo[1-2,5-6]$": + $ref: /schemas/regulator/regulator.yaml type: object properties: @@ -213,6 +217,7 @@ properties: additionalProperties: false "^buck[1-4]$": + $ref: /schemas/regulator/regulator.yaml type: object properties: @@ -237,6 +242,7 @@ properties: additionalProperties: false "^pwr_sw[1-2]$": + $ref: /schemas/regulator/regulator.yaml type: object properties: diff --git a/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml b/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml index 6c8d42f27fe8..94f9767a927d 100644 --- a/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml +++ b/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml @@ -313,7 +313,7 @@ properties: - const: audioclk stericsson,earpeice-cmv: - description: Earpeice voltage + description: Earpiece voltage $ref: /schemas/types.yaml#/definitions/uint32 enum: [ 950, 1100, 1270, 1580 ] @@ -337,39 +337,39 @@ properties: with power. ab8500_ldo_aux1: - description: The voltage for the auxilary LDO regulator 1 + description: The voltage for the auxiliary LDO regulator 1 type: object $ref: ../regulator/regulator.yaml# unevaluatedProperties: false ab8500_ldo_aux2: - description: The voltage for the auxilary LDO regulator 2 + description: The voltage for the auxiliary LDO regulator 2 type: object $ref: ../regulator/regulator.yaml# unevaluatedProperties: false ab8500_ldo_aux3: - description: The voltage for the auxilary LDO regulator 3 + description: The voltage for the auxiliary LDO regulator 3 type: object $ref: ../regulator/regulator.yaml# unevaluatedProperties: false ab8500_ldo_aux4: - description: The voltage for the auxilary LDO regulator 4 + description: The voltage for the auxiliary LDO regulator 4 only present on AB8505 type: object $ref: ../regulator/regulator.yaml# unevaluatedProperties: false ab8500_ldo_aux5: - description: The voltage for the auxilary LDO regulator 5 + description: The voltage for the auxiliary LDO regulator 5 only present on AB8505 type: object $ref: ../regulator/regulator.yaml# unevaluatedProperties: false ab8500_ldo_aux6: - description: The voltage for the auxilary LDO regulator 6 + description: The voltage for the auxiliary LDO regulator 6 only present on AB8505 type: object $ref: ../regulator/regulator.yaml# @@ -378,7 +378,7 @@ properties: # There is never any AUX7 regulator which is confusing ab8500_ldo_aux8: - description: The voltage for the auxilary LDO regulator 8 + description: The voltage for the auxiliary LDO regulator 8 only present on AB8505 type: object $ref: ../regulator/regulator.yaml# diff --git a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml index 1d4d88f7e82d..5e0002f099e4 100644 --- a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml +++ b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml @@ -72,44 +72,52 @@ properties: main voltage domain for the chip. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_varm: description: The voltage for the ARM Cortex A-9 CPU. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_vmodem: description: The voltage for the modem subsystem. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_vpll: description: The voltage for the phase locked loop clocks. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_vsmps1: description: Also known as VIO12, is a step-down voltage regulator for 1.2V I/O. SMPS means System Management Power Source. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_vsmps2: description: Also known as VIO18, is a step-down voltage regulator for 1.8V I/O. SMPS means System Management Power Source. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_vsmps3: description: This is a step-down voltage regulator for 0.87 thru 1.875V I/O. SMPS means System Management Power Source. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_vrf1: - description: RF transciever voltage regulator. + description: RF transceiver voltage regulator. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_sva_mmdsp: description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP) @@ -117,18 +125,21 @@ properties: for video encoding and decoding. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_sva_mmdsp_ret: description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP) voltage regulator for retention mode. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_sva_pipe: description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP) voltage regulator for the data pipe. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_sia_mmdsp: description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP) @@ -136,18 +147,21 @@ properties: for image encoding and decoding. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_sia_mmdsp_ret: description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP) voltage regulator for retention mode. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_sia_pipe: description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP) voltage regulator for the data pipe. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_sga: description: Smart Graphics Accelerator (SGA) voltage regulator. @@ -155,6 +169,7 @@ properties: accelerator block. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_b2r2_mcde: description: Blit Blend Rotate and Rescale (B2R2), and Multi-Channel @@ -162,28 +177,33 @@ properties: blocks. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_esram12: description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_esram12_ret: description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator for retention mode. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_esram34: description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false db8500_esram34_ret: description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator for retention mode. type: object $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt deleted file mode 100644 index d4408a417193..000000000000 --- a/Documentation/devicetree/bindings/mfd/stmpe.txt +++ /dev/null @@ -1,42 +0,0 @@ -* ST Microelectronics STMPE Multi-Functional Device - -STMPE is an MFD device which may expose the following inbuilt devices: gpio, -keypad, touchscreen, adc, pwm, rotator. - -Required properties: - - compatible : "st,stmpe[610|801|811|1600|1601|2401|2403]" - - reg : I2C/SPI address of the device - -Optional properties: - - interrupts : The interrupt outputs from the controller - - interrupt-controller : Marks the device node as an interrupt controller - - wakeup-source : Marks the input device as wakable - - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024 - - irq-gpio : If present, which GPIO to use for event IRQ - -Optional properties for devices with touch and ADC (STMPE811|STMPE610): - - st,sample-time : ADC conversion time in number of clock. - 0 -> 36 clocks 4 -> 80 clocks (recommended) - 1 -> 44 clocks 5 -> 96 clocks - 2 -> 56 clocks 6 -> 124 clocks - 3 -> 64 clocks - - st,mod-12b : ADC Bit mode - 0 -> 10bit ADC 1 -> 12bit ADC - - st,ref-sel : ADC reference source - 0 -> internal 1 -> external - - st,adc-freq : ADC Clock speed - 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz - 1 -> 3.25 MHz - -Example: - - stmpe1601: stmpe1601@40 { - compatible = "st,stmpe1601"; - reg = <0x40>; - interrupts = <26 0x4>; - interrupt-parent = <&gpio6>; - interrupt-controller; - - wakeup-source; - st,autosleep-timeout = <1024>; - }; diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml index 0c98d913747b..e6289fbe6907 100644 --- a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml @@ -101,7 +101,7 @@ examples: }; clock-controller@4140 { - compatible = "ti,am654-ehrpwm-tbclk", "syscon"; + compatible = "ti,am654-ehrpwm-tbclk"; reg = <0x4140 0x18>; #clock-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml b/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml new file mode 100644 index 000000000000..9d43376bebed --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml @@ -0,0 +1,193 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/ti,tps6594.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI TPS6594 Power Management Integrated Circuit + +maintainers: + - Julien Panis <jpanis@baylibre.com> + +description: + TPS6594 is a Power Management IC which provides regulators and others + features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and + PFSM (Pre-configurable Finite State Machine) managing the state of the device. + TPS6594 is the super-set device while TPS6593 and LP8764 are derivatives. + +properties: + compatible: + enum: + - ti,lp8764-q1 + - ti,tps6593-q1 + - ti,tps6594-q1 + + reg: + description: I2C slave address or SPI chip select number. + maxItems: 1 + + ti,primary-pmic: + type: boolean + description: | + Identify the primary PMIC on SPMI bus. + A multi-PMIC synchronization scheme is implemented in the PMIC device + to synchronize the power state changes with other PMIC devices. This is + accomplished through a SPMI bus: the primary PMIC is the controller + device on the SPMI bus, and the secondary PMICs are the target devices + on the SPMI bus. + + system-power-controller: true + + gpio-controller: true + + '#gpio-cells': + const: 2 + description: | + The first cell is the pin number, the second cell is used to specify flags. + See ../gpio/gpio.txt for more information. + + interrupts: + maxItems: 1 + + regulators: + type: object + description: List of regulators provided by this controller. + + patternProperties: + "^buck([1-5]|12|34|123|1234)$": + type: object + $ref: /schemas/regulator/regulator.yaml# + + unevaluatedProperties: false + + "^ldo[1-4]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + + unevaluatedProperties: false + + allOf: + - if: + required: + - buck12 + then: + properties: + buck123: false + buck1234: false + - if: + required: + - buck123 + then: + properties: + buck34: false + - if: + required: + - buck1234 + then: + properties: + buck34: false + + additionalProperties: false + +patternProperties: + "^buck([1-5]|12|34|123|1234)-supply$": + description: Input supply phandle for each buck. + + "^ldo[1-4]-supply$": + description: Input supply phandle for each ldo. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + tps6593: pmic@48 { + compatible = "ti,tps6593-q1"; + reg = <0x48>; + ti,primary-pmic; + system-power-controller; + + gpio-controller; + #gpio-cells = <2>; + + pinctrl-names = "default"; + pinctrl-0 = <&pmic_irq_pins_default>; + interrupt-parent = <&mcu_gpio0>; + interrupts = <0 IRQ_TYPE_EDGE_FALLING>; + + buck123-supply = <&vcc_3v3_sys>; + buck4-supply = <&vcc_3v3_sys>; + buck5-supply = <&vcc_3v3_sys>; + ldo1-supply = <&vcc_3v3_sys>; + ldo2-supply = <&vcc_3v3_sys>; + ldo3-supply = <&buck5>; + ldo4-supply = <&vcc_3v3_sys>; + + regulators { + buck123: buck123 { + regulator-name = "vcc_core"; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <850000>; + regulator-boot-on; + regulator-always-on; + }; + + buck4: buck4 { + regulator-name = "vcc_1v1"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-boot-on; + regulator-always-on; + }; + + buck5: buck5 { + regulator-name = "vcc_1v8_sys"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo1: ldo1 { + regulator-name = "vddshv5_sdio"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo2: ldo2 { + regulator-name = "vpp_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo3: ldo3 { + regulator-name = "vcc_0v85"; + regulator-min-microvolt = <850000>; + regulator-max-microvolt = <850000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo4: ldo4 { + regulator-name = "vdda_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml index f7f0f2c0421a..9ad55746133b 100644 --- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml +++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml @@ -90,6 +90,7 @@ properties: oneOf: - enum: - x-powers,axp152 + - x-powers,axp192 - x-powers,axp202 - x-powers,axp209 - x-powers,axp221 diff --git a/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml b/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml index 20b5836efd90..358ac8cd4d1d 100644 --- a/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml +++ b/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/mips/loongson/ls2k-reset.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/mips/loongson/ls2k-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Loongson 2K1000 PM Controller diff --git a/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml b/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml index 7c0f9022202c..3e3a3705e879 100644 --- a/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml +++ b/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/mips/loongson/rs780e-acpi.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/mips/loongson/rs780e-acpi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Loongson RS780E PCH ACPI Controller diff --git a/Documentation/devicetree/bindings/mips/ralink.yaml b/Documentation/devicetree/bindings/mips/ralink.yaml index 704b5b595127..53c1f6635377 100644 --- a/Documentation/devicetree/bindings/mips/ralink.yaml +++ b/Documentation/devicetree/bindings/mips/ralink.yaml @@ -80,6 +80,7 @@ properties: - enum: - gnubee,gb-pc1 - gnubee,gb-pc2 + - tplink,hc220-g5-v1 - const: mediatek,mt7621-soc additionalProperties: true diff --git a/Documentation/devicetree/bindings/misc/brcm,kona-smc.txt b/Documentation/devicetree/bindings/misc/brcm,kona-smc.txt deleted file mode 100644 index 05b47232ed9e..000000000000 --- a/Documentation/devicetree/bindings/misc/brcm,kona-smc.txt +++ /dev/null @@ -1,15 +0,0 @@ -Broadcom Secure Monitor Bounce buffer ------------------------------------------------------ -This binding defines the location of the bounce buffer -used for non-secure to secure communications. - -Required properties: -- compatible : "brcm,kona-smc" -- DEPRECATED: compatible : "bcm,kona-smc" -- reg : Location and size of bounce buffer - -Example: - smc@3404c000 { - compatible = "brcm,bcm11351-smc", "brcm,kona-smc"; - reg = <0x3404c000 0x400>; //1 KiB in SRAM - }; diff --git a/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml b/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml index 38ab0499102d..36a9dbdf3f03 100644 --- a/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml +++ b/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Linaro Ltd. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/misc/intel,ixp4xx-ahb-queue-manager.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/misc/intel,ixp4xx-ahb-queue-manager.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel IXP4xx AHB Queue Manager diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml index 1ab9588cdd89..2dc3e245fa5d 100644 --- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml +++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml @@ -36,7 +36,7 @@ properties: description: A list of channels tied to this function, used for matching the function to a set of virtual channels. - $ref: "/schemas/types.yaml#/definitions/string-array" + $ref: /schemas/types.yaml#/definitions/string-array items: - const: fastrpcglink-apps-dsp @@ -48,14 +48,14 @@ properties: qcom,smd-channels: description: Channel name used for the RPM communication - $ref: "/schemas/types.yaml#/definitions/string-array" + $ref: /schemas/types.yaml#/definitions/string-array items: - const: fastrpcsmd-apps-dsp qcom,vmids: description: Virtual machine IDs for remote processor. - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: /schemas/types.yaml#/definitions/uint32-array "#address-cells": const: 1 diff --git a/Documentation/devicetree/bindings/misc/ti,j721e-esm.yaml b/Documentation/devicetree/bindings/misc/ti,j721e-esm.yaml new file mode 100644 index 000000000000..0c9a8444844c --- /dev/null +++ b/Documentation/devicetree/bindings/misc/ti,j721e-esm.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/ti,j721e-esm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments K3 ESM + +maintainers: + - Neha Malcom Francis <n-francis@ti.com> + +description: + The ESM (Error Signaling Module) is an IP block on TI K3 devices + that allows handling of safety events somewhat similar to what interrupt + controller would do. The safety signals have their separate paths within + the SoC, and they are handled by the ESM, which routes them to the proper + destination, which can be system reset, interrupt controller, etc. In the + simplest configuration the signals are just routed to reset the SoC. + +properties: + compatible: + const: ti,j721e-esm + + reg: + maxItems: 1 + + ti,esm-pins: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + integer array of ESM interrupt pins to route to external event pin + which can be used to reset the SoC. + minItems: 1 + maxItems: 255 + +required: + - compatible + - reg + - ti,esm-pins + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + esm@700000 { + compatible = "ti,j721e-esm"; + reg = <0x0 0x700000 0x0 0x1000>; + ti,esm-pins = <344>, <345>; + }; + }; diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml index a6c19a6cc99e..3e99801f77d2 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml @@ -160,6 +160,12 @@ properties: description: The MIO bank number in which the command and data lines are configured. + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + dependencies: '#clock-cells': [ clock-output-names ] diff --git a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml index 1c96da04f0e5..2459a55ed540 100644 --- a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml +++ b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml @@ -53,10 +53,11 @@ properties: items: - const: arm,pl18x - const: arm,primecell - - description: Entry for STMicroelectronics variant of PL18x. - This dedicated compatible is used by bootloaders. + - description: Entries for STMicroelectronics variant of PL18x. items: - - const: st,stm32-sdmmc2 + - enum: + - st,stm32-sdmmc2 + - st,stm32mp25-sdmmc2 - const: arm,pl18x - const: arm,primecell diff --git a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.txt b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.txt deleted file mode 100644 index d876580ae3b8..000000000000 --- a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.txt +++ /dev/null @@ -1,23 +0,0 @@ -Broadcom BCM2835 SDHOST controller - -This file documents differences between the core properties described -by mmc.txt and the properties that represent the BCM2835 controller. - -Required properties: -- compatible: Should be "brcm,bcm2835-sdhost". -- clocks: The clock feeding the SDHOST controller. - -Optional properties: -- dmas: DMA channel for read and write. - See Documentation/devicetree/bindings/dma/dma.txt for details - -Example: - -sdhost: mmc@7e202000 { - compatible = "brcm,bcm2835-sdhost"; - reg = <0x7e202000 0x100>; - interrupts = <2 24>; - clocks = <&clocks BCM2835_CLOCK_VPU>; - dmas = <&dma 13>; - dma-names = "rx-tx"; -}; diff --git a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.yaml b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.yaml new file mode 100644 index 000000000000..3a5a44800675 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/brcm,bcm2835-sdhost.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM2835 SDHOST controller + +maintainers: + - Stefan Wahren <stefan.wahren@i2se.com> + +allOf: + - $ref: mmc-controller.yaml + +properties: + compatible: + const: brcm,bcm2835-sdhost + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + const: rx-tx + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/bcm2835.h> + + sdhost: mmc@7e202000 { + compatible = "brcm,bcm2835-sdhost"; + reg = <0x7e202000 0x100>; + interrupts = <2 24>; + clocks = <&clocks BCM2835_CLOCK_VPU>; + dmas = <&dma 13>; + dma-names = "rx-tx"; + bus-width = <4>; + }; diff --git a/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt b/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt deleted file mode 100644 index 7f5dd83f5bd9..000000000000 --- a/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt +++ /dev/null @@ -1,21 +0,0 @@ -Broadcom BCM281xx SDHCI - -This file documents differences between the core properties in mmc.txt -and the properties present in the bcm281xx SDHCI - -Required properties: -- compatible : Should be "brcm,kona-sdhci" -- DEPRECATED: compatible : Should be "bcm,kona-sdhci" -- clocks: phandle + clock specifier pair of the external clock - -Refer to clocks/clock-bindings.txt for generic clock consumer properties. - -Example: - -sdio2: sdio@3f1a0000 { - compatible = "brcm,kona-sdhci"; - reg = <0x3f1a0000 0x10000>; - clocks = <&sdio3_clk>; - interrupts = <0x0 74 0x4>; -}; - diff --git a/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.yaml b/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.yaml new file mode 100644 index 000000000000..12eb3988f824 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.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/brcm,kona-sdhci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Kona family SDHCI controller + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +allOf: + - $ref: sdhci-common.yaml# + +properties: + compatible: + const: brcm,kona-sdhci + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/bcm281xx.h> + + mmc@3f1a0000 { + compatible = "brcm,kona-sdhci"; + reg = <0x3f1a0000 0x10000>; + clocks = <&master_ccu BCM281XX_MASTER_CCU_SDIO3>; + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>; + }; +... diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index fbfd822b9270..82eb7a24c857 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -42,6 +42,7 @@ properties: - enum: - fsl,imx6sll-usdhc - fsl,imx6ull-usdhc + - fsl,imx6ul-usdhc - const: fsl,imx6sx-usdhc - items: - const: fsl,imx7d-usdhc diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml index 3ee758886558..3a8e74894ae0 100644 --- a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml @@ -71,8 +71,8 @@ properties: marvell,xenon-phy-type: $ref: /schemas/types.yaml#/definitions/string enum: - - "emmc 5.1 phy" - - "emmc 5.0 phy" + - emmc 5.1 phy + - emmc 5.0 phy description: | Xenon support multiple types of PHYs. To select eMMC 5.1 PHY, set: marvell,xenon-phy-type = "emmc 5.1 phy" eMMC 5.1 PHY is the default diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index 86c73fd825fd..58ae298cd2fc 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -269,7 +269,7 @@ properties: post-power-on-delay-ms: description: It was invented for MMC pwrseq-simple which could be referred to - mmc-pwrseq-simple.txt. But now it\'s reused as a tunable delay + 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. diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index 46eefdd19a2c..3fffa467e4e1 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -91,16 +91,6 @@ properties: should switch dat1 pin to GPIO mode. maxItems: 1 - assigned-clocks: - description: - PLL of the source clock. - maxItems: 1 - - assigned-clock-parents: - description: - parent of source clock, used for HS400 mode to get 400Mhz source clock. - maxItems: 1 - hs400-ds-delay: $ref: /schemas/types.yaml#/definitions/uint32 description: diff --git a/Documentation/devicetree/bindings/mmc/pxa-mmc.txt b/Documentation/devicetree/bindings/mmc/pxa-mmc.txt index 5f5c2bec2b8c..66a78eae4dc9 100644 --- a/Documentation/devicetree/bindings/mmc/pxa-mmc.txt +++ b/Documentation/devicetree/bindings/mmc/pxa-mmc.txt @@ -9,7 +9,7 @@ Required properties: Optional properties: - marvell,detect-delay-ms: sets the detection delay timeout in ms. -In addition to the properties described in this docuent, the details +In addition to the properties described in this document, the details described in mmc.txt are supported. Examples: diff --git a/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt b/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt index 69edfd4d3922..a9fb0a91245f 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt @@ -5,11 +5,13 @@ Documentation/devicetree/bindings/mmc/mmc.txt and the properties used by the sdhci-of-at91 driver. Required properties: -- compatible: Must be "atmel,sama5d2-sdhci" or "microchip,sam9x60-sdhci". +- compatible: Must be "atmel,sama5d2-sdhci" or "microchip,sam9x60-sdhci" + or "microchip,sam9x7-sdhci", "microchip,sam9x60-sdhci". - clocks: Phandlers to the clocks. - clock-names: Must be "hclock", "multclk", "baseclk" for "atmel,sama5d2-sdhci". Must be "hclock", "multclk" for "microchip,sam9x60-sdhci". + Must be "hclock", "multclk" for "microchip,sam9x7-sdhci". Optional properties: - assigned-clocks: The same with "multclk". diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml index 4f2d9e8127dd..80141eb7fc6b 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml @@ -36,11 +36,14 @@ properties: - enum: - qcom,ipq5018-sdhci - qcom,ipq5332-sdhci + - qcom,ipq6018-sdhci - qcom,ipq9574-sdhci - qcom,qcm2290-sdhci - qcom,qcs404-sdhci + - qcom,qdu1000-sdhci - qcom,sc7180-sdhci - qcom,sc7280-sdhci + - qcom,sc8280xp-sdhci - qcom,sdm630-sdhci - qcom,sdm670-sdhci - qcom,sdm845-sdhci @@ -212,7 +215,7 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/qcom,gcc-sm8250.h> #include <dt-bindings/clock/qcom,rpmh.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> sdhc_2: mmc@8804000 { compatible = "qcom,sm8250-sdhci", "qcom,sdhci-msm-v5"; @@ -229,7 +232,7 @@ examples: iommus = <&apps_smmu 0x4a0 0x0>; qcom,dll-config = <0x0007642c>; qcom,ddr-config = <0x80040868>; - power-domains = <&rpmhpd SM8250_CX>; + power-domains = <&rpmhpd RPMHPD_CX>; operating-points-v2 = <&sdhc2_opp_table>; diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 57d077c0b7c1..7a0e9dcdc444 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -95,7 +95,7 @@ while in suspend. | card | -- CIRQ --> | hsmmc | -- IRQ --> | CPU | ------ ------- ----- -In suspend the fclk is off and the module is disfunctional. Even register reads +In suspend the fclk is off and the module is dysfunctional. Even register reads will fail. A small logic in the host will request fclk restore, when an external event is detected. Once the clock is restored, the host detects the event normally. Since am33xx doesn't have this line it never wakes from diff --git a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml index 9a88870cd865..054b6b8bf9b9 100644 --- a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml @@ -49,13 +49,12 @@ properties: patternProperties: "^nand@[a-f0-9]$": type: object + $ref: raw-nand-chip.yaml properties: reg: minimum: 0 maximum: 7 - nand-ecc-mode: true - nand-ecc-algo: const: bch @@ -75,7 +74,7 @@ patternProperties: minimum: 0 maximum: 1 - additionalProperties: false + unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml index 28fb9a7dd70f..57b6957c8415 100644 --- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml @@ -40,6 +40,7 @@ properties: patternProperties: "^nand@[0-7]$": type: object + $ref: raw-nand-chip.yaml properties: reg: minimum: 0 @@ -49,7 +50,7 @@ patternProperties: const: hw nand-ecc-step-size: - const: 1024 + enum: [512, 1024] nand-ecc-strength: enum: [8, 16, 24, 30, 40, 50, 60] @@ -58,6 +59,18 @@ patternProperties: meson-gxl-nfc 8, 16, 24, 30, 40, 50, 60 meson-axg-nfc 8 + nand-rb: + maxItems: 1 + items: + maximum: 0 + + unevaluatedProperties: false + + dependencies: + nand-ecc-strength: [nand-ecc-step-size] + nand-ecc-step-size: [nand-ecc-strength] + + required: - compatible - reg @@ -87,6 +100,7 @@ examples: nand@0 { reg = <0>; + nand-rb = <0>; }; }; diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml index 1571024aa119..f57e96374e67 100644 --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml @@ -114,6 +114,7 @@ properties: patternProperties: "^nand@[a-f0-9]$": type: object + $ref: raw-nand-chip.yaml properties: compatible: const: brcm,nandcs @@ -136,6 +137,8 @@ patternProperties: layout. $ref: /schemas/types.yaml#/definitions/uint32 + unevaluatedProperties: false + allOf: - $ref: nand-controller.yaml# - if: diff --git a/Documentation/devicetree/bindings/mtd/denali,nand.yaml b/Documentation/devicetree/bindings/mtd/denali,nand.yaml index 0be83ad42970..81f95538d415 100644 --- a/Documentation/devicetree/bindings/mtd/denali,nand.yaml +++ b/Documentation/devicetree/bindings/mtd/denali,nand.yaml @@ -63,6 +63,12 @@ properties: minItems: 1 maxItems: 2 +patternProperties: + "^nand@[a-f0-9]$": + type: object + $ref: raw-nand-chip.yaml + unevaluatedProperties: false + allOf: - $ref: nand-controller.yaml @@ -74,7 +80,6 @@ allOf: then: patternProperties: "^nand@[a-f0-9]$": - type: object properties: nand-ecc-strength: enum: @@ -92,7 +97,6 @@ allOf: then: patternProperties: "^nand@[a-f0-9]$": - type: object properties: nand-ecc-strength: enum: @@ -111,7 +115,6 @@ allOf: then: patternProperties: "^nand@[a-f0-9]$": - type: object properties: nand-ecc-strength: enum: diff --git a/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml index a7bdb5d3675c..b9312ebefeb9 100644 --- a/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml +++ b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml @@ -39,7 +39,9 @@ properties: patternProperties: "^nand@[a-f0-9]$": type: object + $ref: raw-nand-chip.yaml properties: + rb-gpios: description: GPIO specifier for the busy pin. maxItems: 1 @@ -48,6 +50,8 @@ patternProperties: description: GPIO specifier for the write-protect pin. maxItems: 1 + unevaluatedProperties: false + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml index cc3def758e00..07bc7e3efd3a 100644 --- a/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml +++ b/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml @@ -42,17 +42,16 @@ properties: patternProperties: "^nand@[a-f0-9]$": type: object + $ref: raw-nand-chip.yaml properties: reg: minimum: 0 maximum: 1 - nand-ecc-mode: true - nand-ecc-algo: const: hw - additionalProperties: false + unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 89959e5c47ba..58f0cea160ef 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -43,8 +43,10 @@ properties: - const: jedec,spi-nor - const: jedec,spi-nor description: - Must also include "jedec,spi-nor" for any SPI NOR flash that can be - identified by the JEDEC READ ID opcode (0x9F). + SPI NOR flashes compatible with the JEDEC SFDP standard or which may be + identified with the READ ID opcode (0x9F) do not deserve a specific + compatible. They should instead only be matched against the generic + "jedec,spi-nor" compatible. reg: minItems: 1 @@ -70,6 +72,21 @@ properties: be used on such systems, to denote the absence of a reliable reset mechanism. + no-wp: + type: boolean + description: + The status register write disable (SRWD) bit in status register, combined + with the WP# signal, provides hardware data protection for the device. When + the SRWD bit is set to 1, and the WP# signal is either driven LOW or hard + strapped to LOW, the status register nonvolatile bits become read-only and + the WRITE STATUS REGISTER operation will not execute. The only way to exit + this hardware-protected mode is to drive WP# HIGH. If the WP# signal of the + flash device is not connected or is wrongly tied to GND (that includes internal + pull-downs) then status register permanently becomes read-only as the SRWD bit + cannot be reset. This boolean flag can be used on such systems to avoid setting + the SRWD bit while writing the status register. WP# signal hard strapped to GND + can be a valid use case. + reset-gpios: description: A GPIO line connected to the RESET (active low) signal of the device. diff --git a/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml new file mode 100644 index 000000000000..1ecea848e8b9 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml @@ -0,0 +1,227 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/marvell,nand-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell NAND Flash Controller (NFC) + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +properties: + compatible: + oneOf: + - items: + - const: marvell,armada-8k-nand-controller + - const: marvell,armada370-nand-controller + - enum: + - marvell,ac5-nand-controller + - marvell,armada370-nand-controller + - marvell,pxa3xx-nand-controller + - description: legacy bindings + deprecated: true + enum: + - marvell,armada-8k-nand + - marvell,armada370-nand + - marvell,pxa3xx-nand + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: + Shall reference the NAND controller clocks, the second one is + is only needed for the Armada 7K/8K SoCs + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: core + - const: reg + + dmas: + maxItems: 1 + + dma-names: + items: + - const: data + + marvell,system-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: Syscon node that handles NAND controller related registers + +patternProperties: + "^nand@[a-f0-9]$": + type: object + $ref: raw-nand-chip.yaml + + properties: + reg: + minimum: 0 + maximum: 3 + + nand-rb: + items: + - minimum: 0 + maximum: 1 + + nand-ecc-step-size: + const: 512 + + nand-ecc-strength: + enum: [1, 4, 8, 12, 16] + + nand-ecc-mode: + const: hw + + marvell,nand-keep-config: + $ref: /schemas/types.yaml#/definitions/flag + description: + Orders the driver not to take the timings from the core and + leaving them completely untouched. Bootloader timings will then + be used. + + marvell,nand-enable-arbiter: + $ref: /schemas/types.yaml#/definitions/flag + description: + To enable the arbiter, all boards blindly used it, + this bit was set by the bootloader for many boards and even if + it is marked reserved in several datasheets, it might be needed to set + it (otherwise it is harmless). + deprecated: true + + required: + - reg + - nand-rb + + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + +allOf: + - $ref: nand-controller.yaml# + + - if: + properties: + compatible: + contains: + const: marvell,pxa3xx-nand-controller + then: + required: + - dmas + - dma-names + + - if: + properties: + compatible: + contains: + const: marvell,armada-8k-nand-controller + then: + properties: + clocks: + minItems: 2 + + clock-names: + minItems: 2 + + required: + - marvell,system-controller + + else: + properties: + clocks: + minItems: 1 + + clock-names: + minItems: 1 + + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + nand_controller: nand-controller@d0000 { + compatible = "marvell,armada370-nand-controller"; + reg = <0xd0000 0x54>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&coredivclk 0>; + + nand@0 { + reg = <0>; + label = "main-storage"; + nand-rb = <0>; + nand-ecc-mode = "hw"; + marvell,nand-keep-config; + nand-on-flash-bbt; + nand-ecc-strength = <4>; + nand-ecc-step-size = <512>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "Rootfs"; + reg = <0x00000000 0x40000000>; + }; + }; + }; + }; + + - | + cp0_nand_controller: nand-controller@720000 { + compatible = "marvell,armada-8k-nand-controller", + "marvell,armada370-nand-controller"; + reg = <0x720000 0x54>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <115 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "core", "reg"; + clocks = <&cp0_clk 1 2>, + <&cp0_clk 1 17>; + marvell,system-controller = <&cp0_syscon0>; + + nand@0 { + reg = <0>; + label = "main-storage"; + nand-rb = <0>; + nand-ecc-mode = "hw"; + nand-ecc-strength = <8>; + nand-ecc-step-size = <512>; + }; + }; + + - | + nand-controller@43100000 { + compatible = "marvell,pxa3xx-nand-controller"; + reg = <0x43100000 90>; + interrupts = <45>; + clocks = <&clks 1>; + clock-names = "core"; + dmas = <&pdma 97 3>; + dma-names = "data"; + #address-cells = <1>; + #size-cells = <0>; + nand@0 { + reg = <0>; + nand-rb = <0>; + nand-ecc-mode = "hw"; + marvell,nand-keep-config; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mtd/marvell-nand.txt b/Documentation/devicetree/bindings/mtd/marvell-nand.txt deleted file mode 100644 index a2d9a0f2b683..000000000000 --- a/Documentation/devicetree/bindings/mtd/marvell-nand.txt +++ /dev/null @@ -1,126 +0,0 @@ -Marvell NAND Flash Controller (NFC) - -Required properties: -- compatible: can be one of the following: - * "marvell,armada-8k-nand-controller" - * "marvell,armada370-nand-controller" - * "marvell,pxa3xx-nand-controller" - * "marvell,armada-8k-nand" (deprecated) - * "marvell,armada370-nand" (deprecated) - * "marvell,pxa3xx-nand" (deprecated) - Compatibles marked deprecated support only the old bindings described - at the bottom. -- reg: NAND flash controller memory area. -- #address-cells: shall be set to 1. Encode the NAND CS. -- #size-cells: shall be set to 0. -- interrupts: shall define the NAND controller interrupt. -- clocks: shall reference the NAND controller clocks, the second one is - is only needed for the Armada 7K/8K SoCs -- clock-names: mandatory if there is a second clock, in this case there - should be one clock named "core" and another one named "reg" -- marvell,system-controller: Set to retrieve the syscon node that handles - NAND controller related registers (only required with the - "marvell,armada-8k-nand[-controller]" compatibles). - -Optional properties: -- label: see partition.txt. New platforms shall omit this property. -- dmas: shall reference DMA channel associated to the NAND controller. - This property is only used with "marvell,pxa3xx-nand[-controller]" - compatible strings. -- dma-names: shall be "rxtx". - This property is only used with "marvell,pxa3xx-nand[-controller]" - compatible strings. - -Optional children nodes: -Children nodes represent the available NAND chips. - -Required properties: -- reg: shall contain the native Chip Select ids (0-3). -- nand-rb: see nand-controller.yaml (0-1). - -Optional properties: -- marvell,nand-keep-config: orders the driver not to take the timings - from the core and leaving them completely untouched. Bootloader - timings will then be used. -- label: MTD name. -- nand-on-flash-bbt: see nand-controller.yaml. -- nand-ecc-mode: see nand-controller.yaml. Will use hardware ECC if not specified. -- nand-ecc-algo: see nand-controller.yaml. This property is essentially useful when - not using hardware ECC. Howerver, it may be added when using hardware - ECC for clarification but will be ignored by the driver because ECC - mode is chosen depending on the page size and the strength required by - the NAND chip. This value may be overwritten with nand-ecc-strength - property. -- nand-ecc-strength: see nand-controller.yaml. -- nand-ecc-step-size: see nand-controller.yaml. Marvell's NAND flash controller does - use fixed strength (1-bit for Hamming, 16-bit for BCH), so the actual - step size will shrink or grow in order to fit the required strength. - Step sizes are not completely random for all and follow certain - patterns described in AN-379, "Marvell SoC NFC ECC". - -See Documentation/devicetree/bindings/mtd/nand-controller.yaml for more details on -generic bindings. - - -Example: -nand_controller: nand-controller@d0000 { - compatible = "marvell,armada370-nand-controller"; - reg = <0xd0000 0x54>; - #address-cells = <1>; - #size-cells = <0>; - interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&coredivclk 0>; - - nand@0 { - reg = <0>; - label = "main-storage"; - nand-rb = <0>; - nand-ecc-mode = "hw"; - marvell,nand-keep-config; - nand-on-flash-bbt; - nand-ecc-strength = <4>; - nand-ecc-step-size = <512>; - - partitions { - compatible = "fixed-partitions"; - #address-cells = <1>; - #size-cells = <1>; - - partition@0 { - label = "Rootfs"; - reg = <0x00000000 0x40000000>; - }; - }; - }; -}; - - -Note on legacy bindings: One can find, in not-updated device trees, -bindings slightly different than described above with other properties -described below as well as the partitions node at the root of a so -called "nand" node (without clear controller/chip separation). - -Legacy properties: -- marvell,nand-enable-arbiter: To enable the arbiter, all boards blindly - used it, this bit was set by the bootloader for many boards and even if - it is marked reserved in several datasheets, it might be needed to set - it (otherwise it is harmless) so whether or not this property is set, - the bit is selected by the driver. -- num-cs: Number of chip-select lines to use, all boards blindly set 1 - to this and for a reason, other values would have failed. The value of - this property is ignored. - -Example: - - nand0: nand@43100000 { - compatible = "marvell,pxa3xx-nand"; - reg = <0x43100000 90>; - interrupts = <45>; - dmas = <&pdma 97 0>; - dma-names = "rxtx"; - #address-cells = <1>; - marvell,nand-keep-config; - marvell,nand-enable-arbiter; - num-cs = <1>; - /* Partitions (optional) */ - }; diff --git a/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml b/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml index a6e7f123eda7..ab503a33a269 100644 --- a/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml +++ b/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml @@ -40,12 +40,11 @@ properties: patternProperties: "^nand@[a-f0-9]$": - $ref: nand-chip.yaml# + $ref: raw-nand-chip.yaml# unevaluatedProperties: false properties: reg: maximum: 1 - nand-on-flash-bbt: true nand-ecc-mode: const: hw diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml index 00882892f47e..0ff32bd00bf6 100644 --- a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml +++ b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/mtd/microchip,mchp48l640.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/mtd/microchip,mchp48l640.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Microchip 48l640 (and similar) serial EERAM diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml index f8c976898a95..18f6733408b4 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml @@ -164,7 +164,7 @@ examples: reg = <0 0xf80000>; }; firmware@f80000 { - label ="firmware"; + label = "firmware"; reg = <0xf80000 0x80000>; read-only; }; diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml b/Documentation/devicetree/bindings/mtd/mtd.yaml index da3d488c335f..b82ca03e969c 100644 --- a/Documentation/devicetree/bindings/mtd/mtd.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd.yaml @@ -12,7 +12,7 @@ maintainers: properties: $nodename: - pattern: "^(flash|.*sram)(@.*)?$" + pattern: "^(flash|.*sram|nand)(@.*)?$" label: description: diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index f70a32d2d9d4..28167c0cf271 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0 +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/mtd/nand-controller.yaml# @@ -16,16 +16,6 @@ description: | children nodes of the NAND controller. This representation should be enforced even for simple controllers supporting only one chip. - The ECC strength and ECC step size properties define the user - desires in terms of correction capability of a controller. Together, - they request the ECC engine to correct {strength} bit errors per - {size} bytes. - - The interpretation of these parameters is implementation-defined, so - not all implementations must support all possible - combinations. However, implementations are encouraged to further - specify the value(s) they support. - properties: $nodename: pattern: "^nand-controller(@.*)?" @@ -51,79 +41,8 @@ properties: patternProperties: "^nand@[a-f0-9]$": - $ref: nand-chip.yaml# - - properties: - reg: - description: - Contains the chip-select IDs. - - nand-ecc-placement: - description: - Location of the ECC bytes. This location is unknown by default - but can be explicitly set to "oob", if all ECC bytes are - known to be stored in the OOB area, or "interleaved" if ECC - bytes will be interleaved with regular data in the main area. - $ref: /schemas/types.yaml#/definitions/string - enum: [ oob, interleaved ] - - nand-bus-width: - description: - Bus width to the NAND chip - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [8, 16] - default: 8 - - nand-on-flash-bbt: - description: - With this property, the OS will search the device for a Bad - Block Table (BBT). If not found, it will create one, reserve - a few blocks at the end of the device to store it and update - it as the device ages. Otherwise, the out-of-band area of a - few pages of all the blocks will be scanned at boot time to - find Bad Block Markers (BBM). These markers will help to - build a volatile BBT in RAM. - $ref: /schemas/types.yaml#/definitions/flag - - nand-ecc-maximize: - description: - Whether or not the ECC strength should be maximized. The - maximum ECC strength is both controller and chip - dependent. The ECC engine has to select the ECC config - providing the best strength and taking the OOB area size - constraint into account. This is particularly useful when - only the in-band area is used by the upper layers, and you - want to make your NAND as reliable as possible. - $ref: /schemas/types.yaml#/definitions/flag - - nand-is-boot-medium: - description: - Whether or not the NAND chip is a boot medium. Drivers might - use this information to select ECC algorithms supported by - the boot ROM or similar restrictions. - $ref: /schemas/types.yaml#/definitions/flag - - nand-rb: - description: - Contains the native Ready/Busy IDs. - $ref: /schemas/types.yaml#/definitions/uint32-array - - rb-gpios: - description: - Contains one or more GPIO descriptor (the numper of descriptor - depends on the number of R/B pins exposed by the flash) for the - Ready/Busy pins. Active state refers to the NAND ready state and - should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. - - wp-gpios: - description: - Contains one GPIO descriptor for the Write Protect pin. - Active state refers to the NAND Write Protect state and should be - set to GPIOD_ACTIVE_LOW unless the signal is inverted. - maxItems: 1 - - required: - - reg + type: object + $ref: raw-nand-chip.yaml# required: - "#address-cells" diff --git a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt deleted file mode 100644 index 2ba07fc8b79c..000000000000 --- a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt +++ /dev/null @@ -1,41 +0,0 @@ -* Oxford Semiconductor OXNAS NAND Controller - -Please refer to nand-controller.yaml for generic information regarding MTD NAND bindings. - -Required properties: - - compatible: "oxsemi,ox820-nand" - - reg: Base address and length for NAND mapped memory. - -Optional Properties: - - clocks: phandle to the NAND gate clock if needed. - - resets: phandle to the NAND reset control if needed. - -Example: - -nandc: nand-controller@41000000 { - compatible = "oxsemi,ox820-nand"; - reg = <0x41000000 0x100000>; - clocks = <&stdclk CLK_820_NAND>; - resets = <&reset RESET_NAND>; - #address-cells = <1>; - #size-cells = <0>; - - nand@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <1>; - nand-ecc-mode = "soft"; - nand-ecc-algo = "hamming"; - - partition@0 { - label = "boot"; - reg = <0x00000000 0x00e00000>; - read-only; - }; - - partition@e00000 { - label = "ubi"; - reg = <0x00e00000 0x07200000>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml index cdffbb9cedc2..1ebe9e2347ea 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml @@ -55,6 +55,7 @@ properties: linux,rootfs: description: Marks partition that contains root filesystem to mount and boot user space from + type: boolean if: not: diff --git a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml index 2edc65e0e361..1dda2c80747b 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml @@ -21,6 +21,7 @@ oneOf: - $ref: linksys,ns-partitions.yaml - $ref: qcom,smem-part.yaml - $ref: redboot-fis.yaml + - $ref: tplink,safeloader-partitions.yaml properties: compatible: true diff --git a/Documentation/devicetree/bindings/mtd/partitions/seama.yaml b/Documentation/devicetree/bindings/mtd/partitions/seama.yaml new file mode 100644 index 000000000000..4c1cbf43e81a --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/seama.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/seama.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Seattle Image Partitions + +description: The SEAttle iMAge (SEAMA) partition is a type of partition + used for NAND flash devices. This type of flash image is found in some + D-Link routers such as DIR-645, DIR-842, DIR-859, DIR-860L, DIR-885L, + DIR890L and DCH-M225, as well as in WD and NEC routers on the ath79 + (MIPS), Broadcom BCM53xx, and RAMIPS platforms. This partition type + does not have children defined in the device tree, they need to be + detected by software. + +allOf: + - $ref: partition.yaml# + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +properties: + compatible: + const: seama + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + compatible = "seama"; + reg = <0x0 0x800000>; + label = "firmware"; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml index 00c991ffa6c4..4ada60fbf81d 100644 --- a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml +++ b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml @@ -34,7 +34,9 @@ properties: patternProperties: "^nand@[a-f0-9]$": type: object + $ref: raw-nand-chip.yaml properties: + nand-bus-width: const: 8 @@ -45,6 +47,24 @@ patternProperties: enum: - 512 + qcom,boot-partitions: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: offset + - description: size + description: + Boot partition use a different layout where the 4 bytes of spare + data are not protected by ECC. Use this to declare these special + partitions by defining first the offset and then the size. + + It's in the form of <offset1 size1 offset2 size2 offset3 ...> + and should be declared in ascending order. + + Refer to the ipq8064 example on how to use this special binding. + + unevaluatedProperties: false + allOf: - $ref: nand-controller.yaml# @@ -107,22 +127,15 @@ allOf: - qcom,ipq806x-nand then: - properties: - qcom,boot-partitions: - $ref: /schemas/types.yaml#/definitions/uint32-matrix - items: - items: - - description: offset - - description: size - description: - Boot partition use a different layout where the 4 bytes of spare - data are not protected by ECC. Use this to declare these special - partitions by defining first the offset and then the size. - - It's in the form of <offset1 size1 offset2 size2 offset3 ...> - and should be declared in ascending order. - - Refer to the ipq8064 example on how to use this special binding. + patternProperties: + "^nand@[a-f0-9]$": + properties: + qcom,boot-partitions: true + else: + patternProperties: + "^nand@[a-f0-9]$": + properties: + qcom,boot-partitions: false required: - compatible diff --git a/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml new file mode 100644 index 000000000000..092448d7bfc5 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml @@ -0,0 +1,111 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/raw-nand-chip.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Raw NAND Chip Common Properties + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +allOf: + - $ref: nand-chip.yaml# + +description: | + The ECC strength and ECC step size properties define the user + desires in terms of correction capability of a controller. Together, + they request the ECC engine to correct {strength} bit errors per + {size} bytes for a particular raw NAND chip. + + The interpretation of these parameters is implementation-defined, so + not all implementations must support all possible + combinations. However, implementations are encouraged to further + specify the value(s) they support. + +properties: + $nodename: + pattern: "^nand@[a-f0-9]$" + + reg: + description: + Contains the chip-select IDs. + + nand-ecc-placement: + description: + Location of the ECC bytes. This location is unknown by default + but can be explicitly set to "oob", if all ECC bytes are + known to be stored in the OOB area, or "interleaved" if ECC + bytes will be interleaved with regular data in the main area. + $ref: /schemas/types.yaml#/definitions/string + enum: [ oob, interleaved ] + deprecated: true + + nand-ecc-mode: + description: + Legacy ECC configuration mixing the ECC engine choice and + configuration. + $ref: /schemas/types.yaml#/definitions/string + enum: [none, soft, soft_bch, hw, hw_syndrome, on-die] + deprecated: true + + nand-bus-width: + description: + Bus width to the NAND chip + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16] + default: 8 + + nand-on-flash-bbt: + description: + With this property, the OS will search the device for a Bad + Block Table (BBT). If not found, it will create one, reserve + a few blocks at the end of the device to store it and update + it as the device ages. Otherwise, the out-of-band area of a + few pages of all the blocks will be scanned at boot time to + find Bad Block Markers (BBM). These markers will help to + build a volatile BBT in RAM. + $ref: /schemas/types.yaml#/definitions/flag + + nand-ecc-maximize: + description: + Whether or not the ECC strength should be maximized. The + maximum ECC strength is both controller and chip + dependent. The ECC engine has to select the ECC config + providing the best strength and taking the OOB area size + constraint into account. This is particularly useful when + only the in-band area is used by the upper layers, and you + want to make your NAND as reliable as possible. + $ref: /schemas/types.yaml#/definitions/flag + + nand-is-boot-medium: + description: + Whether or not the NAND chip is a boot medium. Drivers might + use this information to select ECC algorithms supported by + the boot ROM or similar restrictions. + $ref: /schemas/types.yaml#/definitions/flag + + nand-rb: + description: + Contains the native Ready/Busy IDs. + $ref: /schemas/types.yaml#/definitions/uint32-array + + rb-gpios: + description: + Contains one or more GPIO descriptor (the numper of descriptor + depends on the number of R/B pins exposed by the flash) for the + Ready/Busy pins. Active state refers to the NAND ready state and + should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. + + wp-gpios: + description: + Contains one GPIO descriptor for the Write Protect pin. + Active state refers to the NAND Write Protect state and should be + set to GPIOD_ACTIVE_LOW unless the signal is inverted. + maxItems: 1 + +required: + - reg + +# This is a generic file other binding inherit from and extend +additionalProperties: true diff --git a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml index 7eb1d0a38565..ee53715ffdca 100644 --- a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml @@ -57,6 +57,7 @@ properties: patternProperties: "^nand@[0-7]$": type: object + $ref: raw-nand-chip.yaml properties: reg: minimum: 0 @@ -116,6 +117,8 @@ patternProperties: Only used in combination with 'nand-is-boot-medium'. + unevaluatedProperties: false + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml index 986e85ccebc7..e72cb5bacaf0 100644 --- a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml @@ -37,6 +37,7 @@ properties: patternProperties: "^nand@[a-f0-9]$": type: object + $ref: raw-nand-chip.yaml properties: nand-ecc-step-size: const: 512 @@ -44,6 +45,8 @@ patternProperties: nand-ecc-strength: enum: [1, 4, 8] + unevaluatedProperties: false + allOf: - $ref: nand-controller.yaml# diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml index 4774c92e7fc4..df4fdc02456d 100644 --- a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml +++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml @@ -30,6 +30,8 @@ properties: patternProperties: "^flash@[0-1],[0-9a-f]+$": type: object + $ref: mtd-physmap.yaml + unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml index 3bd912ed7c7e..23e92be33ac8 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Allwinner A20 GMAC allOf: - - $ref: "snps,dwmac.yaml#" + - $ref: snps,dwmac.yaml# maintainers: - Chen-Yu Tsai <wens@csie.org> diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml index 47bc2057e629..4bfac9186886 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml @@ -63,7 +63,7 @@ required: - syscon allOf: - - $ref: "snps,dwmac.yaml#" + - $ref: snps,dwmac.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/net/altr,tse.yaml b/Documentation/devicetree/bindings/net/altr,tse.yaml index 9d02af468906..f5d3b70af07a 100644 --- a/Documentation/devicetree/bindings/net/altr,tse.yaml +++ b/Documentation/devicetree/bindings/net/altr,tse.yaml @@ -72,8 +72,8 @@ allOf: compatible: contains: enum: - - const: altr,tse-1.0 - - const: ALTR,tse-1.0 + - altr,tse-1.0 + - ALTR,tse-1.0 then: properties: reg: diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index a2c51a84efa5..ee7a65b528cd 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -27,7 +27,7 @@ select: - compatible allOf: - - $ref: "snps,dwmac.yaml#" + - $ref: snps,dwmac.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml index 57e4c87cb00b..f01a3988538c 100644 --- a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml +++ b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml @@ -24,11 +24,12 @@ properties: - nxp,88w8997-bt fw-init-baudrate: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 115200 description: Chip baudrate after FW is downloaded and initialized. This property depends on the module vendor's - configuration. If this property is not specified, - 115200 is set as default. + configuration. required: - compatible diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml index 68f78b90d23a..eba2f3026ab0 100644 --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml @@ -16,14 +16,17 @@ description: properties: compatible: enum: + - qcom,qca2066-bt - qcom,qca6174-bt - qcom,qca9377-bt + - qcom,wcn3988-bt - qcom,wcn3990-bt - qcom,wcn3991-bt - qcom,wcn3998-bt - qcom,qca6390-bt - qcom,wcn6750-bt - qcom,wcn6855-bt + - qcom,wcn7850-bt enable-gpios: maxItems: 1 @@ -50,9 +53,15 @@ properties: vddch0-supply: description: VDD_CH0 supply regulator handle + vddch1-supply: + description: VDD_CH1 supply regulator handle + vddaon-supply: description: VDD_AON supply regulator handle + vdddig-supply: + description: VDD_DIG supply regulator handle + vddbtcxmx-supply: description: VDD_BT_CXMX supply regulator handle @@ -68,6 +77,9 @@ properties: vddrfa1p2-supply: description: VDD_RFA_1P2 supply regulator handle + vddrfa1p9-supply: + description: VDD_RFA_1P9 supply regulator handle + vddrfa2p2-supply: description: VDD_RFA_2P2 supply regulator handle @@ -95,6 +107,7 @@ allOf: compatible: contains: enum: + - qcom,qca2066-bt - qcom,qca6174-bt then: required: @@ -106,6 +119,7 @@ allOf: compatible: contains: enum: + - qcom,wcn3988-bt - qcom,wcn3990-bt - qcom,wcn3991-bt - qcom,wcn3998-bt @@ -150,6 +164,22 @@ allOf: - vddrfa0p8-supply - vddrfa1p2-supply - vddrfa1p7-supply + - if: + properties: + compatible: + contains: + enum: + - qcom,wcn7850-bt + then: + required: + - enable-gpios + - swctrl-gpios + - vddio-supply + - vddaon-supply + - vdddig-supply + - vddrfa0p8-supply + - vddrfa1p2-supply + - vddrfa1p9-supply examples: - | diff --git a/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml new file mode 100644 index 000000000000..aa3162c74833 --- /dev/null +++ b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml @@ -0,0 +1,155 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom ASP 2.0 Ethernet controller + +maintainers: + - Justin Chen <justin.chen@broadcom.com> + - Florian Fainelli <florian.fainelli@broadcom.com> + +description: Broadcom Ethernet controller first introduced with 72165 + +properties: + compatible: + oneOf: + - items: + - enum: + - brcm,bcm74165-asp + - const: brcm,asp-v2.1 + - items: + - enum: + - brcm,bcm72165-asp + - const: brcm,asp-v2.0 + + "#address-cells": + const: 1 + "#size-cells": + const: 1 + + reg: + maxItems: 1 + + ranges: true + + interrupts: + minItems: 1 + items: + - description: RX/TX interrupt + - description: Port 0 Wake-on-LAN + - description: Port 1 Wake-on-LAN + + clocks: + maxItems: 1 + + ethernet-ports: + type: object + properties: + "#address-cells": + const: 1 + "#size-cells": + const: 0 + + patternProperties: + "^port@[0-9]+$": + type: object + + $ref: ethernet-controller.yaml# + + unevaluatedProperties: false + + properties: + reg: + maxItems: 1 + description: Port number + + brcm,channel: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + ASP Channel Number + + The depacketizer channel that consumes packets from + the unimac/port. + + required: + - reg + - brcm,channel + + additionalProperties: false + +patternProperties: + "^mdio@[0-9a-f]+$": + type: object + $ref: brcm,unimac-mdio.yaml + + description: + ASP internal UniMAC MDIO bus + +required: + - compatible + - reg + - interrupts + - clocks + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + ethernet@9c00000 { + compatible = "brcm,bcm72165-asp", "brcm,asp-v2.0"; + reg = <0x9c00000 0x1fff14>; + interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>; + ranges = <0x0 0x9c00000 0x1fff14>; + clocks = <&scmi 14>; + #address-cells = <1>; + #size-cells = <1>; + + mdio@c614 { + compatible = "brcm,asp-v2.0-mdio"; + reg = <0xc614 0x8>; + reg-names = "mdio"; + #address-cells = <1>; + #size-cells = <0>; + + phy0: ethernet-phy@1 { + reg = <1>; + }; + }; + + mdio@ce14 { + compatible = "brcm,asp-v2.0-mdio"; + reg = <0xce14 0x8>; + reg-names = "mdio"; + #address-cells = <1>; + #size-cells = <0>; + + phy1: ethernet-phy@1 { + reg = <1>; + }; + }; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + brcm,channel = <8>; + phy-mode = "rgmii"; + phy-handle = <&phy0>; + }; + + port@1 { + reg = <1>; + brcm,channel = <9>; + phy-mode = "rgmii"; + phy-handle = <&phy1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt b/Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt index d0935d2afef8..284cddb3118e 100644 --- a/Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt +++ b/Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt @@ -1,4 +1,4 @@ -* Broadcom Starfighter 2 integrated swich +* Broadcom Starfighter 2 integrated switch See dsa/brcm,bcm7445-switch-v4.0.yaml for the documentation. diff --git a/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml index 0e5e5db32faf..7c90a4390531 100644 --- a/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml +++ b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml @@ -55,7 +55,7 @@ properties: patternProperties: "^mdio@[0-9a-f]+$": type: object - $ref: "brcm,unimac-mdio.yaml" + $ref: brcm,unimac-mdio.yaml description: GENET internal UniMAC MDIO bus diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml index 0be426ee1e44..6684810fcbf0 100644 --- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml +++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml @@ -22,6 +22,8 @@ properties: - brcm,genet-mdio-v3 - brcm,genet-mdio-v4 - brcm,genet-mdio-v5 + - brcm,asp-v2.0-mdio + - brcm,asp-v2.1-mdio - brcm,unimac-mdio reg: diff --git a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml index 9c494957a07a..e42ea28d6ab4 100644 --- a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml +++ b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml @@ -21,6 +21,7 @@ properties: - const: allwinner,sun4i-a10-can - const: allwinner,sun4i-a10-can - const: allwinner,sun8i-r40-can + - const: allwinner,sun20i-d1-can reg: maxItems: 1 @@ -37,8 +38,9 @@ properties: if: properties: compatible: - contains: - const: allwinner,sun8i-r40-can + enum: + - allwinner,sun8i-r40-can + - allwinner,sun20i-d1-can then: required: diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 67879aab623b..f9ffb963d6b1 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -122,16 +122,15 @@ required: - compatible - reg - reg-names - - interrupts - - interrupt-names - clocks - clock-names - bosch,mram-cfg -additionalProperties: false +unevaluatedProperties: false examples: - | + // Example with interrupts #include <dt-bindings/clock/imx6sx-clock.h> can@20e8000 { compatible = "bosch,m_can"; @@ -149,4 +148,21 @@ examples: }; }; + - | + // Example with timer polling + #include <dt-bindings/clock/imx6sx-clock.h> + can@20e8000 { + compatible = "bosch,m_can"; + reg = <0x020e8000 0x4000>, <0x02298000 0x4000>; + reg-names = "m_can", "message_ram"; + clocks = <&clks IMX6SX_CLK_CANFD>, + <&clks IMX6SX_CLK_CANFD>; + clock-names = "hclk", "cclk"; + bosch,mram-cfg = <0x0 0 0 32 0 0 0 1>; + + can-transceiver { + max-bitrate = <5000000>; + }; + }; + ... diff --git a/Documentation/devicetree/bindings/net/can/cc770.txt b/Documentation/devicetree/bindings/net/can/cc770.txt index 77027bf6460a..042200cf4419 100644 --- a/Documentation/devicetree/bindings/net/can/cc770.txt +++ b/Documentation/devicetree/bindings/net/can/cc770.txt @@ -26,7 +26,7 @@ Optional properties: will be disabled. - bosch,slew-rate : slew rate of the CLKOUT signal. If not specified, - a resonable value will be calculated. + a reasonable value will be calculated. - bosch,disconnect-rx0-input : see data sheet. diff --git a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt index e3501bfa22e9..170e23f0610d 100644 --- a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt +++ b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt @@ -4,7 +4,10 @@ Texas Instruments TCAN4x5x CAN Controller This file provides device node information for the TCAN4x5x interface contains. Required properties: - - compatible: "ti,tcan4x5x" + - compatible: + "ti,tcan4552", "ti,tcan4x5x" + "ti,tcan4553", "ti,tcan4x5x" or + "ti,tcan4x5x" - reg: 0 - #address-cells: 1 - #size-cells: 0 @@ -21,8 +24,10 @@ 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. - - device-wake-gpios: Wake up GPIO to wake up the TCAN device. + 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. Example: tcan4x5x: tcan4x5x@0 { diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml index 897d2cbda45b..64d57c343e6f 100644 --- a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml +++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml @@ -46,6 +46,9 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 description: CAN Tx mailbox buffer count (CAN FD) + resets: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml index bef5e0f895be..bf8894a0257e 100644 --- a/Documentation/devicetree/bindings/net/cdns,macb.yaml +++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml @@ -109,6 +109,16 @@ properties: power-domains: maxItems: 1 + cdns,rx-watermark: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + When the receive partial store and forward mode is activated, + the receiver will only begin to forward the packet to the external + AHB or AXI slave when enough packet data is stored in the SRAM packet buffer. + rx-watermark corresponds to the number of SRAM buffer locations, + that need to be filled, before the forwarding process is activated. + Width of the SRAM is platform dependent, and can be 4, 8 or 16 bytes. + '#address-cells': const: 1 @@ -166,6 +176,7 @@ examples: compatible = "cdns,macb"; reg = <0xfffc4000 0x4000>; interrupts = <21>; + cdns,rx-watermark = <0x44>; phy-mode = "rmii"; local-mac-address = [3a 0e 03 04 05 06]; clock-names = "pclk", "hclk", "tx_clk"; diff --git a/Documentation/devicetree/bindings/net/davicom,dm9000.yaml b/Documentation/devicetree/bindings/net/davicom,dm9000.yaml new file mode 100644 index 000000000000..66a7c6eec767 --- /dev/null +++ b/Documentation/devicetree/bindings/net/davicom,dm9000.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/davicom,dm9000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Davicom DM9000 Fast Ethernet Controller + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +properties: + compatible: + const: davicom,dm9000 + + reg: + items: + - description: Address registers + - description: Data registers + + interrupts: + maxItems: 1 + + davicom,no-eeprom: + type: boolean + description: Configuration EEPROM is not available + + davicom,ext-phy: + type: boolean + description: Use external PHY + + reset-gpios: + maxItems: 1 + + vcc-supply: true + +required: + - compatible + - reg + - interrupts + +allOf: + - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml# + - $ref: /schemas/net/ethernet-controller.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + ethernet@a8000000 { + compatible = "davicom,dm9000"; + reg = <0xa8000000 0x2>, <0xa8000002 0x2>; + interrupt-parent = <&gph1>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; + local-mac-address = [00 00 de ad be ef]; + davicom,no-eeprom; + }; diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt b/Documentation/devicetree/bindings/net/davicom-dm9000.txt deleted file mode 100644 index 64c159e9cbf7..000000000000 --- a/Documentation/devicetree/bindings/net/davicom-dm9000.txt +++ /dev/null @@ -1,27 +0,0 @@ -Davicom DM9000 Fast Ethernet controller - -Required properties: -- compatible = "davicom,dm9000"; -- reg : physical addresses and sizes of registers, must contain 2 entries: - first entry : address register, - second entry : data register. -- interrupts : interrupt specifier specific to interrupt controller - -Optional properties: -- davicom,no-eeprom : Configuration EEPROM is not available -- davicom,ext-phy : Use external PHY -- reset-gpios : phandle of gpio that will be used to reset chip during probe -- vcc-supply : phandle of regulator that will be used to enable power to chip - -Example: - - ethernet@18000000 { - compatible = "davicom,dm9000"; - reg = <0x18000000 0x2 0x18000004 0x2>; - interrupt-parent = <&gpn>; - interrupts = <7 4>; - local-mac-address = [00 00 de ad be ef]; - davicom,no-eeprom; - reset-gpios = <&gpf 12 GPIO_ACTIVE_LOW>; - vcc-supply = <ð0_power>; - }; diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml index c745407f2f68..b06c416893ff 100644 --- a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml +++ b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/net/dsa/brcm,sf2.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Broadcom Starfighter 2 integrated swich +title: Broadcom Starfighter 2 integrated switch maintainers: - Florian Fainelli <f.fainelli@gmail.com> diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml index 8d971813bab6..ec74a660beda 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml @@ -36,7 +36,7 @@ additionalProperties: true $defs: ethernet-ports: description: A DSA switch without any extra port properties - $ref: '#/' + $ref: '#' patternProperties: "^(ethernet-)?ports$": diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt index 2363b412410c..6ec0c181b6db 100644 --- a/Documentation/devicetree/bindings/net/dsa/marvell.txt +++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt @@ -20,7 +20,7 @@ which is at a different MDIO base address in different switch families. 6171, 6172, 6175, 6176, 6185, 6240, 6320, 6321, 6341, 6350, 6351, 6352 - "marvell,mv88e6190" : Switch has base address 0x00. Use with models: - 6190, 6190X, 6191, 6290, 6390, 6390X + 6190, 6190X, 6191, 6290, 6361, 6390, 6390X - "marvell,mv88e6250" : Switch has base address 0x08 or 0x18. Use with model: 6220, 6250 diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml index e51be1ac0362..03b5567be389 100644 --- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml +++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml @@ -49,6 +49,9 @@ properties: Set if the output SYNCLKO clock should be disabled. Do not mix with microchip,synclko-125. + interrupts: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml index 9a64ed658745..4d5f5cc6d031 100644 --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml @@ -12,10 +12,6 @@ description: cs_sck_delay of 500ns. Ensuring that this SPI timing requirement is observed depends on the SPI bus master driver. -allOf: - - $ref: dsa.yaml#/$defs/ethernet-ports - - $ref: /schemas/spi/spi-peripheral-props.yaml# - maintainers: - Vladimir Oltean <vladimir.oltean@nxp.com> @@ -36,6 +32,9 @@ properties: reg: maxItems: 1 + spi-cpha: true + spi-cpol: true + # Optional container node for the 2 internal MDIO buses of the SJA1110 # (one for the internal 100base-T1 PHYs and the other for the single # 100base-TX PHY). The "reg" property does not have physical significance. @@ -109,6 +108,30 @@ $defs: 1860, 1880, 1900, 1920, 1940, 1960, 1980, 2000, 2020, 2040, 2060, 2080, 2100, 2120, 2140, 2160, 2180, 2200, 2220, 2240, 2260] +allOf: + - $ref: dsa.yaml#/$defs/ethernet-ports + - $ref: /schemas/spi/spi-peripheral-props.yaml# + - if: + properties: + compatible: + enum: + - nxp,sja1105e + - nxp,sja1105p + - nxp,sja1105q + - nxp,sja1105r + - nxp,sja1105s + - nxp,sja1105t + then: + properties: + spi-cpol: false + required: + - spi-cpha + else: + properties: + spi-cpha: false + required: + - spi-cpol + unevaluatedProperties: false examples: @@ -120,6 +143,7 @@ examples: ethernet-switch@1 { reg = <0x1>; compatible = "nxp,sja1105t"; + spi-cpha; ethernet-ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index 6b0d359367da..9f6a5ccbcefe 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -66,6 +66,7 @@ properties: - mii - gmii - sgmii + - psgmii - qsgmii - qusgmii - tbi diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 4f574532ee13..8fb2a6ee7e5b 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -93,6 +93,12 @@ properties: the turn around line low at end of the control phase of the MDIO transaction. + clocks: + maxItems: 1 + description: + External clock connected to the PHY. If not specified it is assumed + that the PHY uses a fixed crystal or an internal oscillator. + enet-phy-lane-swap: $ref: /schemas/types.yaml#/definitions/flag description: @@ -104,7 +110,7 @@ properties: $ref: /schemas/types.yaml#/definitions/flag description: If set, indicates that PHY will disable swap of the - TX/RX lanes. This property allows the PHY to work correcly after + TX/RX lanes. This property allows the PHY to work correctly after e.g. wrong bootstrap configuration caused by issues in PCB layout design. diff --git a/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml b/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml new file mode 100644 index 000000000000..9bcbacb6640d --- /dev/null +++ b/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/faraday,ftgmac100.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Faraday Technology FTGMAC100 gigabit ethernet controller + +allOf: + - $ref: ethernet-controller.yaml# + +maintainers: + - Po-Yu Chuang <ratbert@faraday-tech.com> + +properties: + compatible: + oneOf: + - const: faraday,ftgmac100 + - items: + - enum: + - aspeed,ast2400-mac + - aspeed,ast2500-mac + - aspeed,ast2600-mac + - const: faraday,ftgmac100 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: MAC IP clock + - description: RMII RCLK gate for AST2500/2600 + + clock-names: + minItems: 1 + items: + - const: MACCLK + - const: RCLK + + phy-mode: + enum: + - rgmii + - rmii + + phy-handle: true + + use-ncsi: + description: + Use the NC-SI stack instead of an MDIO PHY. Currently assumes + rmii (100bT) but kept as a separate property in case NC-SI grows support + for a gigabit link. + type: boolean + + no-hw-checksum: + description: + Used to disable HW checksum support. Here for backward + compatibility as the driver now should have correct defaults based on + the SoC. + type: boolean + deprecated: true + + mdio: + $ref: /schemas/net/mdio.yaml# + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + ethernet@1e660000 { + compatible = "aspeed,ast2500-mac", "faraday,ftgmac100"; + reg = <0x1e660000 0x180>; + interrupts = <2>; + use-ncsi; + }; + + ethernet@1e680000 { + compatible = "aspeed,ast2500-mac", "faraday,ftgmac100"; + reg = <0x1e680000 0x180>; + interrupts = <2>; + + phy-handle = <&phy>; + phy-mode = "rgmii"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + phy: ethernet-phy@1 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/ftgmac100.txt b/Documentation/devicetree/bindings/net/ftgmac100.txt deleted file mode 100644 index 29234021f601..000000000000 --- a/Documentation/devicetree/bindings/net/ftgmac100.txt +++ /dev/null @@ -1,67 +0,0 @@ -* Faraday Technology FTGMAC100 gigabit ethernet controller - -Required properties: -- compatible: "faraday,ftgmac100" - - Must also contain one of these if used as part of an Aspeed AST2400 - or 2500 family SoC as they have some subtle tweaks to the - implementation: - - - "aspeed,ast2400-mac" - - "aspeed,ast2500-mac" - - "aspeed,ast2600-mac" - -- reg: Address and length of the register set for the device -- interrupts: Should contain ethernet controller interrupt - -Optional properties: -- phy-handle: See ethernet.txt file in the same directory. -- phy-mode: See ethernet.txt file in the same directory. If the property is - absent, "rgmii" is assumed. Supported values are "rgmii*" and "rmii" for - aspeed parts. Other (unknown) parts will accept any value. -- use-ncsi: Use the NC-SI stack instead of an MDIO PHY. Currently assumes - rmii (100bT) but kept as a separate property in case NC-SI grows support - for a gigabit link. -- no-hw-checksum: Used to disable HW checksum support. Here for backward - compatibility as the driver now should have correct defaults based on - the SoC. -- clocks: In accordance with the generic clock bindings. Must describe the MAC - IP clock, and optionally an RMII RCLK gate for the AST2500/AST2600. The - required MAC clock must be the first cell. -- clock-names: - - - "MACCLK": The MAC IP clock - - "RCLK": Clock gate for the RMII RCLK - -Optional subnodes: -- mdio: See mdio.txt file in the same directory. - -Example: - - mac0: ethernet@1e660000 { - compatible = "aspeed,ast2500-mac", "faraday,ftgmac100"; - reg = <0x1e660000 0x180>; - interrupts = <2>; - use-ncsi; - }; - -Example with phy-handle: - - mac1: ethernet@1e680000 { - compatible = "aspeed,ast2500-mac", "faraday,ftgmac100"; - reg = <0x1e680000 0x180>; - interrupts = <2>; - - phy-handle = <&phy>; - phy-mode = "rgmii"; - - mdio { - #address-cells = <1>; - #size-cells = <0>; - - phy: ethernet-phy@1 { - compatible = "ethernet-phy-ieee802.3-c22"; - reg = <1>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml index d23fa3771210..42a0bc94312c 100644 --- a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml +++ b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml @@ -19,7 +19,7 @@ select: - compatible allOf: - - $ref: "snps,dwmac.yaml#" + - $ref: snps,dwmac.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml index d71fa9de2b64..8a3713abd1ca 100644 --- a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml +++ b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml @@ -17,11 +17,12 @@ properties: maxlinear,use-broken-interrupts: description: | Interrupts are broken on some GPY2xx PHYs in that they keep the - interrupt line asserted even after the interrupt status register is - cleared. Thus it is blocking the interrupt line which is usually bad - for shared lines. By default interrupts are disabled for this PHY and - polling mode is used. If one can live with the consequences, this - property can be used to enable interrupt handling. + interrupt line asserted for a random amount of time even after the + interrupt status register is cleared. Thus it is blocking the + interrupt line which is usually bad for shared lines. By default, + interrupts are disabled for this PHY and polling mode is used. If one + can live with the consequences, this property can be used to enable + interrupt handling. Affected PHYs (as far as known) are GPY215B and GPY215C. type: boolean diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml index acb2b2ac4fe1..e74502a0afe8 100644 --- a/Documentation/devicetree/bindings/net/mediatek,net.yaml +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml @@ -19,10 +19,12 @@ properties: enum: - mediatek,mt2701-eth - mediatek,mt7623-eth + - mediatek,mt7621-eth - mediatek,mt7622-eth - mediatek,mt7629-eth - mediatek,mt7981-eth - mediatek,mt7986-eth + - mediatek,mt7988-eth - ralink,rt5350-eth reg: @@ -32,7 +34,7 @@ properties: clock-names: true interrupts: - minItems: 3 + minItems: 1 maxItems: 4 power-domains: @@ -60,6 +62,12 @@ properties: Phandle to the mediatek hifsys controller used to provide various clocks and reset to the system. + mediatek,infracfg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon node that handles the path from GMAC to + PHY variants. + mediatek,sgmiisys: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 @@ -121,6 +129,8 @@ allOf: - const: gp1 - const: gp2 + mediatek,infracfg: false + mediatek,pctl: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -135,6 +145,32 @@ allOf: properties: compatible: contains: + enum: + - mediatek,mt7621-eth + then: + properties: + interrupts: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: ethif + - const: fe + + mediatek,infracfg: false + + mediatek,wed: false + + mediatek,wed-pcie: false + + - if: + properties: + compatible: + contains: const: mediatek,mt7622-eth then: properties: @@ -159,6 +195,8 @@ allOf: - const: sgmii_ck - const: eth2pll + mediatek,infracfg: false + mediatek,sgmiisys: minItems: 1 maxItems: 1 @@ -204,12 +242,6 @@ allOf: - const: sgmii_ck - const: eth2pll - mediatek,infracfg: - $ref: /schemas/types.yaml#/definitions/phandle - description: - Phandle to the syscon node that handles the path from GMAC to - PHY variants. - mediatek,sgmiisys: minItems: 2 maxItems: 2 @@ -250,6 +282,8 @@ allOf: - const: netsys0 - const: netsys1 + mediatek,infracfg: false + mediatek,sgmiisys: minItems: 2 maxItems: 2 @@ -286,6 +320,67 @@ allOf: - const: netsys0 - const: netsys1 + mediatek,infracfg: false + + mediatek,sgmiisys: + minItems: 2 + maxItems: 2 + + - if: + properties: + compatible: + contains: + const: mediatek,mt7988-eth + then: + properties: + interrupts: + minItems: 4 + + clocks: + minItems: 34 + maxItems: 34 + + clock-names: + items: + - const: crypto + - const: fe + - const: gp2 + - const: gp1 + - const: gp3 + - const: ethwarp_wocpu2 + - const: ethwarp_wocpu1 + - const: ethwarp_wocpu0 + - const: esw + - const: netsys0 + - const: netsys1 + - const: sgmii_tx250m + - const: sgmii_rx250m + - const: sgmii2_tx250m + - const: sgmii2_rx250m + - const: top_usxgmii0_sel + - const: top_usxgmii1_sel + - const: top_sgm0_sel + - const: top_sgm1_sel + - const: top_xfi_phy0_xtal_sel + - const: top_xfi_phy1_xtal_sel + - const: top_eth_gmii_sel + - const: top_eth_refck_50m_sel + - const: top_eth_sys_200m_sel + - const: top_eth_sys_sel + - const: top_eth_xgmii_sel + - const: top_eth_mii_sel + - const: top_netsys_sel + - const: top_netsys_500m_sel + - const: top_netsys_pao_2x_sel + - const: top_netsys_sync_250m_sel + - const: top_netsys_ppefb_250m_sel + - const: top_netsys_warp_sel + - const: wocpu1 + - const: wocpu0 + - const: xgp1 + - const: xgp2 + - const: xgp3 + mediatek,sgmiisys: minItems: 2 maxItems: 2 @@ -293,7 +388,7 @@ allOf: patternProperties: "^mac@[0-1]$": type: object - additionalProperties: false + unevaluatedProperties: false allOf: - $ref: ethernet-controller.yaml# description: @@ -305,14 +400,9 @@ patternProperties: reg: maxItems: 1 - phy-handle: true - - phy-mode: true - required: - reg - compatible - - phy-handle required: - compatible diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml index 0fa2132fa4f4..ed9d845f6008 100644 --- a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml @@ -25,7 +25,7 @@ select: - compatible allOf: - - $ref: "snps,dwmac.yaml#" + - $ref: snps,dwmac.yaml# properties: compatible: @@ -129,7 +129,7 @@ properties: type: boolean description: If present, indicates that MAC supports WOL(Wake-On-LAN), and MAC WOL will be enabled. - Otherwise, PHY WOL is perferred. + Otherwise, PHY WOL is preferred. required: - compatible @@ -156,7 +156,7 @@ examples: reg = <0x1101c000 0x1300>; interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>; interrupt-names = "macirq"; - phy-mode ="rgmii-rxid"; + phy-mode = "rgmii-rxid"; mac-address = [00 55 7b b5 7d f7]; clock-names = "axi", "apb", diff --git a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml index b44d83554ef5..b726c6e14633 100644 --- a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml +++ b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml @@ -44,13 +44,13 @@ required: allOf: - $ref: ethernet-controller.yaml# - - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml# - if: properties: compatible: contains: const: micrel,ks8851 then: + $ref: /schemas/spi/spi-peripheral-props.yaml# properties: reg: maxItems: 1 @@ -60,6 +60,7 @@ allOf: contains: const: micrel,ks8851-mll then: + $ref: /schemas/memory-controllers/mc-peripheral-props.yaml# properties: reg: minItems: 2 diff --git a/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml index 0b97e14d947f..77c9bbf987e1 100644 --- a/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml +++ b/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml @@ -33,7 +33,7 @@ properties: - usb424,9906 # SMSC9505A USB Ethernet Device (HAL) - usb424,9907 # SMSC9500 USB Ethernet Device (Alternate ID) - usb424,9908 # SMSC9500A USB Ethernet Device (Alternate ID) - - usb424,9909 # SMSC9512/9514 USB Hub & Ethernet Devic. ID) + - usb424,9909 # SMSC9512/9514 USB Hub & Ethernet Device ID) - usb424,9e00 # SMSC9500A USB Ethernet Device - usb424,9e01 # SMSC9505A USB Ethernet Device - usb424,9e08 # SMSC LAN89530 USB Ethernet Device diff --git a/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml b/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml index 157e3bbcaf6f..26688e2302ea 100644 --- a/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml +++ b/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml @@ -52,6 +52,40 @@ properties: for a timer. type: boolean + motorcomm,rx-clk-drv-microamp: + description: | + drive strength of rx_clk rgmii pad. + The YT8531 RGMII LDO voltage supports 1.8V/3.3V, and the LDO voltage can + be configured with hardware pull-up resistors to match the SOC voltage + (usually 1.8V). + The software can read the registers to obtain the LDO voltage and configure + the legal drive strength(curren). + ===================================================== + | voltage | current Available (uA) | + | 1.8v | 1200 2100 2700 2910 3110 3600 3970 4350 | + | 3.3v | 3070 4080 4370 4680 5020 5450 5740 6140 | + ===================================================== + enum: [ 1200, 2100, 2700, 2910, 3070, 3110, 3600, 3970, + 4080, 4350, 4370, 4680, 5020, 5450, 5740, 6140 ] + default: 2910 + + motorcomm,rx-data-drv-microamp: + description: | + drive strength of rx_data/rx_ctl rgmii pad. + The YT8531 RGMII LDO voltage supports 1.8V/3.3V, and the LDO voltage can + be configured with hardware pull-up resistors to match the SOC voltage + (usually 1.8V). + The software can read the registers to obtain the LDO voltage and configure + the legal drive strength(curren). + ===================================================== + | voltage | current Available (uA) | + | 1.8v | 1200 2100 2700 2910 3110 3600 3970 4350 | + | 3.3v | 3070 4080 4370 4680 5020 5450 5740 6140 | + ===================================================== + enum: [ 1200, 2100, 2700, 2910, 3070, 3110, 3600, 3970, + 4080, 4350, 4370, 4680, 5020, 5450, 5740, 6140 ] + default: 2910 + motorcomm,tx-clk-adj-enabled: description: | This configuration is mainly to adapt to VF2 with JH7110 SoC. diff --git a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml index 8e9a95f24c80..89663fdd3eba 100644 --- a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml +++ b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml @@ -37,13 +37,13 @@ properties: type: boolean description: | For I2C type of connection. Specifies that the chip read event shall be - trigged on falling edge. + triggered on falling edge. i2c-int-rising: type: boolean description: | For I2C type of connection. Specifies that the chip read event shall be - trigged on rising edge. + triggered on rising edge. break-control: type: boolean diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml index 63409cbff5ad..4c01cae7c93a 100644 --- a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml +++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml @@ -24,7 +24,7 @@ select: - compatible allOf: - - $ref: "snps,dwmac.yaml#" + - $ref: snps,dwmac.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt deleted file mode 100644 index 27db496f1ce8..000000000000 --- a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt +++ /dev/null @@ -1,41 +0,0 @@ -* Oxford Semiconductor OXNAS DWMAC Ethernet controller - -The device inherits all the properties of the dwmac/stmmac devices -described in the file stmmac.txt in the current directory with the -following changes. - -Required properties on all platforms: - -- compatible: For the OX820 SoC, it should be : - - "oxsemi,ox820-dwmac" to select glue - - "snps,dwmac-3.512" to select IP version. - For the OX810SE SoC, it should be : - - "oxsemi,ox810se-dwmac" to select glue - - "snps,dwmac-3.512" to select IP version. - -- clocks: Should contain phandles to the following clocks -- clock-names: Should contain the following: - - "stmmaceth" for the host clock - see stmmac.txt - - "gmac" for the peripheral gate clock - -- oxsemi,sys-ctrl: a phandle to the system controller syscon node - -Example : - -etha: ethernet@40400000 { - compatible = "oxsemi,ox820-dwmac", "snps,dwmac-3.512"; - reg = <0x40400000 0x2000>; - interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "macirq", "eth_wake_irq"; - mac-address = [000000000000]; /* Filled in by U-Boot */ - phy-mode = "rgmii"; - - clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>; - clock-names = "gmac", "stmmaceth"; - resets = <&reset RESET_MAC>; - - /* Regmap for sys registers */ - oxsemi,sys-ctrl = <&sys>; - -}; diff --git a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml index b110abb42597..2d382faca0e6 100644 --- a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml +++ b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml @@ -16,7 +16,7 @@ maintainers: properties: $nodename: - pattern: "^ethernet-pse(@.*)?$" + pattern: "^ethernet-pse(@.*|-([0-9]|[1-9][0-9]+))?$" "#pse-cells": description: diff --git a/Documentation/devicetree/bindings/net/qca,ar803x.yaml b/Documentation/devicetree/bindings/net/qca,ar803x.yaml index 161d28919316..3acd09f0da86 100644 --- a/Documentation/devicetree/bindings/net/qca,ar803x.yaml +++ b/Documentation/devicetree/bindings/net/qca,ar803x.yaml @@ -75,6 +75,7 @@ properties: description: Initial data for the VDDIO regulator. Set this to 1.5V or 1.8V. $ref: /schemas/regulator/regulator.yaml + unevaluatedProperties: false vddh-regulator: type: object @@ -82,6 +83,7 @@ properties: Dummy subnode to model the external connection of the PHY VDDH regulator to VDDIO. $ref: /schemas/regulator/regulator.yaml + unevaluatedProperties: false unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml index 60a38044fb19..7bdb412a0185 100644 --- a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml @@ -20,6 +20,7 @@ properties: compatible: enum: - qcom,qcs404-ethqos + - qcom,sa8775p-ethqos - qcom,sc8280xp-ethqos - qcom,sm8150-ethqos @@ -32,11 +33,13 @@ properties: - const: rgmii interrupts: + minItems: 1 items: - description: Combined signal for various interrupt events - description: The interrupt that occurs when Rx exits the LPI state interrupt-names: + minItems: 1 items: - const: macirq - const: eth_lpi @@ -49,11 +52,18 @@ properties: - const: stmmaceth - const: pclk - const: ptp_ref - - const: rgmii + - enum: + - rgmii + - phyaux iommus: maxItems: 1 + phys: true + + phy-names: + const: serdes + required: - compatible - clocks diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml index 2a21bbe02892..70bbc4220e2a 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml @@ -32,7 +32,7 @@ select: - compatible allOf: - - $ref: "snps,dwmac.yaml#" + - $ref: snps,dwmac.yaml# properties: compatible: @@ -80,6 +80,7 @@ properties: "output" means GMAC provides the reference clock. $ref: /schemas/types.yaml#/definitions/string enum: [input, output] + default: input rockchip,grf: description: The phandle of the syscon node for the general register file. @@ -91,12 +92,18 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle tx_delay: - description: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as default. + description: Delay value for TXD timing. $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 0x7F + default: 0x30 rx_delay: - description: Delay value for RXD timing. Range value is 0~0x7F, 0x10 as default. + description: Delay value for RXD timing. $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 0x7F + default: 0x10 phy-supply: description: PHY regulator diff --git a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt index 2cff6d8a585a..b9381b761a27 100644 --- a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt +++ b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt @@ -5,10 +5,10 @@ Required properties: - reg: Address and length of the register set for the device - interrupts: Should contain the SXGBE interrupts These interrupts are ordered by fixed and follows variable - trasmit DMA interrupts, receive DMA interrupts and lpi interrupt. + transmit DMA interrupts, receive DMA interrupts and lpi interrupt. index 0 - this is fixed common interrupt of SXGBE and it is always available. - index 1 to 25 - 8 variable trasmit interrupts, variable 16 receive interrupts + index 1 to 25 - 8 variable transmit interrupts, variable 16 receive interrupts and 1 optional lpi interrupt. - phy-mode: String, operation mode of the PHY interface. Supported values are: "sgmii", "xgmii". diff --git a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt index ad3c6e109ce1..bb0224a3e826 100644 --- a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt +++ b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt @@ -110,7 +110,7 @@ Optional properties: It depends on the SoC configuration. - snps,read-requests: Number of read requests that the AXI port can issue. It depends on the SoC configuration. -- snps,burst-map: Bitmap of allowed AXI burst lengts, with the LSB +- snps,burst-map: Bitmap of allowed AXI burst lengths, with the LSB representing 4, then 8 etc. - snps,txpbl: DMA Programmable burst length for the TX DMA - snps,rxpbl: DMA Programmable burst length for the RX DMA diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 363b3e3ea3a6..ddf9522a5dc2 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -67,6 +67,7 @@ properties: - loongson,ls2k-dwmac - loongson,ls7a-dwmac - qcom,qcs404-ethqos + - qcom,sa8775p-ethqos - qcom,sc8280xp-ethqos - qcom,sm8150-ethqos - renesas,r9a06g032-gmac @@ -582,6 +583,7 @@ allOf: - ingenic,x1600-mac - ingenic,x1830-mac - ingenic,x2000-mac + - qcom,sa8775p-ethqos - qcom,sc8280xp-ethqos - snps,dwmac-3.50a - snps,dwmac-4.10a @@ -638,6 +640,7 @@ allOf: - ingenic,x1830-mac - ingenic,x2000-mac - qcom,qcs404-ethqos + - qcom,sa8775p-ethqos - qcom,sc8280xp-ethqos - qcom,sm8150-ethqos - snps,dwmac-4.00 diff --git a/Documentation/devicetree/bindings/net/sti-dwmac.txt b/Documentation/devicetree/bindings/net/sti-dwmac.txt index 42cd075456ab..e16287c06e5e 100644 --- a/Documentation/devicetree/bindings/net/sti-dwmac.txt +++ b/Documentation/devicetree/bindings/net/sti-dwmac.txt @@ -21,7 +21,7 @@ Optional properties: MAC can generate it. - st,tx-retime-src: This specifies which clk is wired up to the mac for retimeing tx lines. This is totally board dependent and can take one of the - posssible values from "txclk", "clk_125" or "clkgen". + possible values from "txclk", "clk_125" or "clkgen". If not passed, the internal clock will be used by default. - sti-ethclk: this is the phy clock. - sti-clkconf: this is an extra sysconfig register, available in new SoCs, diff --git a/Documentation/devicetree/bindings/net/ti,icss-iep.yaml b/Documentation/devicetree/bindings/net/ti,icss-iep.yaml new file mode 100644 index 000000000000..f5c22d6dcaee --- /dev/null +++ b/Documentation/devicetree/bindings/net/ti,icss-iep.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/ti,icss-iep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments ICSS Industrial Ethernet Peripheral (IEP) module + +maintainers: + - Md Danish Anwar <danishanwar@ti.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,am642-icss-iep + - ti,j721e-icss-iep + - const: ti,am654-icss-iep + + - const: ti,am654-icss-iep + + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + description: phandle to the IEP source clock + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + /* AM65x */ + icssg0_iep0: iep@2e000 { + compatible = "ti,am654-icss-iep"; + reg = <0x2e000 0x1000>; + clocks = <&icssg0_iepclk_mux>; + }; diff --git a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml new file mode 100644 index 000000000000..311c570165f9 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml @@ -0,0 +1,193 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments ICSSG PRUSS Ethernet + +maintainers: + - Md Danish Anwar <danishanwar@ti.com> + +description: + Ethernet based on the Programmable Real-Time Unit and Industrial + Communication Subsystem. + +allOf: + - $ref: /schemas/remoteproc/ti,pru-consumer.yaml# + +properties: + compatible: + enum: + - ti,am654-icssg-prueth # for AM65x SoC family + + sram: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to MSMC SRAM node + + dmas: + maxItems: 10 + + dma-names: + items: + - const: tx0-0 + - const: tx0-1 + - const: tx0-2 + - const: tx0-3 + - const: tx1-0 + - const: tx1-1 + - const: tx1-2 + - const: tx1-3 + - const: rx0 + - const: rx1 + + ti,mii-g-rt: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to MII_G_RT module's syscon regmap. + + ti,mii-rt: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to MII_RT module's syscon regmap + + ti,iep: + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 2 + items: + maxItems: 1 + description: + phandle to IEP (Industrial Ethernet Peripheral) for ICSSG + + interrupts: + maxItems: 2 + description: + Interrupt specifiers to TX timestamp IRQ. + + interrupt-names: + items: + - const: tx_ts0 + - const: tx_ts1 + + ethernet-ports: + type: object + additionalProperties: false + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + ^port@[0-1]$: + type: object + description: ICSSG PRUETH external ports + $ref: ethernet-controller.yaml# + unevaluatedProperties: false + + properties: + reg: + items: + - enum: [0, 1] + description: ICSSG PRUETH port number + + interrupts: + maxItems: 1 + + ti,syscon-rgmii-delay: + items: + - items: + - description: phandle to system controller node + - description: The offset to ICSSG control register + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + phandle to system controller node and register offset + to ICSSG control register for RGMII transmit delay + + required: + - reg + anyOf: + - required: + - port@0 + - required: + - port@1 + +required: + - compatible + - sram + - dmas + - dma-names + - ethernet-ports + - ti,mii-g-rt + - interrupts + - interrupt-names + +unevaluatedProperties: false + +examples: + - | + /* Example k3-am654 base board SR2.0, dual-emac */ + pruss2_eth: ethernet { + compatible = "ti,am654-icssg-prueth"; + pinctrl-names = "default"; + pinctrl-0 = <&icssg2_rgmii_pins_default>; + sram = <&msmc_ram>; + + ti,prus = <&pru2_0>, <&rtu2_0>, <&tx_pru2_0>, + <&pru2_1>, <&rtu2_1>, <&tx_pru2_1>; + firmware-name = "ti-pruss/am65x-pru0-prueth-fw.elf", + "ti-pruss/am65x-rtu0-prueth-fw.elf", + "ti-pruss/am65x-txpru0-prueth-fw.elf", + "ti-pruss/am65x-pru1-prueth-fw.elf", + "ti-pruss/am65x-rtu1-prueth-fw.elf", + "ti-pruss/am65x-txpru1-prueth-fw.elf"; + ti,pruss-gp-mux-sel = <2>, /* MII mode */ + <2>, + <2>, + <2>, /* MII mode */ + <2>, + <2>; + dmas = <&main_udmap 0xc300>, /* egress slice 0 */ + <&main_udmap 0xc301>, /* egress slice 0 */ + <&main_udmap 0xc302>, /* egress slice 0 */ + <&main_udmap 0xc303>, /* egress slice 0 */ + <&main_udmap 0xc304>, /* egress slice 1 */ + <&main_udmap 0xc305>, /* egress slice 1 */ + <&main_udmap 0xc306>, /* egress slice 1 */ + <&main_udmap 0xc307>, /* egress slice 1 */ + <&main_udmap 0x4300>, /* ingress slice 0 */ + <&main_udmap 0x4301>; /* ingress slice 1 */ + dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3", + "tx1-0", "tx1-1", "tx1-2", "tx1-3", + "rx0", "rx1"; + ti,mii-g-rt = <&icssg2_mii_g_rt>; + ti,iep = <&icssg2_iep0>, <&icssg2_iep1>; + interrupt-parent = <&icssg2_intc>; + interrupts = <24 0 2>, <25 1 3>; + interrupt-names = "tx_ts0", "tx_ts1"; + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + pruss2_emac0: port@0 { + reg = <0>; + phy-handle = <&pruss2_eth0_phy>; + phy-mode = "rgmii-id"; + interrupts-extended = <&icssg2_intc 24>; + ti,syscon-rgmii-delay = <&scm_conf 0x4120>; + /* Filled in by bootloader */ + local-mac-address = [00 00 00 00 00 00]; + }; + + pruss2_emac1: port@1 { + reg = <1>; + phy-handle = <&pruss2_eth1_phy>; + phy-mode = "rgmii-id"; + interrupts-extended = <&icssg2_intc 25>; + ti,syscon-rgmii-delay = <&scm_conf 0x4124>; + /* Filled in by bootloader */ + local-mac-address = [00 00 00 00 00 00]; + }; + }; + }; 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 395a4650e285..c9c25132d154 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml @@ -168,14 +168,14 @@ properties: patternProperties: "^mdio@[0-9a-f]+$": type: object - $ref: "ti,davinci-mdio.yaml#" + $ref: ti,davinci-mdio.yaml# description: CPSW MDIO bus. "^cpts@[0-9a-f]+": type: object - $ref: "ti,k3-am654-cpts.yaml#" + $ref: ti,k3-am654-cpts.yaml# description: CPSW Common Platform Time Sync (CPTS) module. diff --git a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml index 474fa8bcf302..052f636158b3 100644 --- a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml @@ -19,7 +19,7 @@ select: - compatible allOf: - - $ref: "snps,dwmac.yaml#" + - $ref: snps,dwmac.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml index fec1cc9b9a08..4aa521f1be8c 100644 --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml @@ -15,6 +15,9 @@ description: These chips also have a Bluetooth portion described in a separate binding. +allOf: + - $ref: ieee80211.yaml# + properties: compatible: oneOf: @@ -38,6 +41,7 @@ properties: - brcm,bcm4354-fmac - brcm,bcm4356-fmac - brcm,bcm4359-fmac + - brcm,bcm4366-fmac - cypress,cyw4373-fmac - cypress,cyw43012-fmac - const: brcm,bcm4329-fmac @@ -120,7 +124,7 @@ required: - compatible - reg -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml index 67b63f119f64..252207adbc54 100644 --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml @@ -28,6 +28,7 @@ properties: - mediatek,mt76 - mediatek,mt7628-wmac - mediatek,mt7622-wmac + - mediatek,mt7981-wmac - mediatek,mt7986-wmac reg: @@ -71,6 +72,14 @@ properties: ieee80211-freq-limit: true + nvmem-cells: + items: + - description: NVMEM cell with EEPROM + + nvmem-cell-names: + items: + - const: eeprom + mediatek,eeprom-data: $ref: /schemas/types.yaml#/definitions/uint32-array description: @@ -84,6 +93,7 @@ properties: - description: offset containing EEPROM data description: Phandle to a MTD partition + offset containing EEPROM data + deprecated: true big-endian: $ref: /schemas/types.yaml#/definitions/flag @@ -258,7 +268,8 @@ examples: interrupt-parent = <&cpuintc>; interrupts = <6>; - mediatek,mtd-eeprom = <&factory 0x0>; + nvmem-cells = <&eeprom>; + nvmem-cell-names = "eeprom"; }; - | diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml index c85ed330426d..7758a55dd328 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml @@ -84,6 +84,8 @@ properties: required: - iommus + ieee80211-freq-limit: true + qcom,ath10k-calibration-data: $ref: /schemas/types.yaml#/definitions/uint8-array description: @@ -164,6 +166,7 @@ required: additionalProperties: false allOf: + - $ref: ieee80211.yaml# - if: properties: compatible: @@ -355,4 +358,5 @@ examples: "msi14", "msi15", "legacy"; + ieee80211-freq-limit = <5470000 5875000>; }; diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt b/Documentation/devicetree/bindings/net/xilinx_axienet.txt deleted file mode 100644 index 80e505a2fda1..000000000000 --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt +++ /dev/null @@ -1,101 +0,0 @@ -XILINX AXI ETHERNET Device Tree Bindings --------------------------------------------------------- - -Also called AXI 1G/2.5G Ethernet Subsystem, the xilinx axi ethernet IP core -provides connectivity to an external ethernet PHY supporting different -interfaces: MII, GMII, RGMII, SGMII, 1000BaseX. It also includes two -segments of memory for buffering TX and RX, as well as the capability of -offloading TX/RX checksum calculation off the processor. - -Management configuration is done through the AXI interface, while payload is -sent and received through means of an AXI DMA controller. This driver -includes the DMA driver code, so this driver is incompatible with AXI DMA -driver. - -For more details about mdio please refer phy.txt file in the same directory. - -Required properties: -- compatible : Must be one of "xlnx,axi-ethernet-1.00.a", - "xlnx,axi-ethernet-1.01.a", "xlnx,axi-ethernet-2.01.a" -- reg : Address and length of the IO space, as well as the address - and length of the AXI DMA controller IO space, unless - axistream-connected is specified, in which case the reg - attribute of the node referenced by it is used. -- interrupts : Should be a list of 2 or 3 interrupts: TX DMA, RX DMA, - and optionally Ethernet core. If axistream-connected is - specified, the TX/RX DMA interrupts should be on that node - instead, and only the Ethernet core interrupt is optionally - specified here. -- phy-handle : Should point to the external phy device if exists. Pointing - this to the PCS/PMA PHY is deprecated and should be avoided. - See ethernet.txt file in the same directory. -- xlnx,rxmem : Set to allocated memory buffer for Rx/Tx in the hardware - -Optional properties: -- phy-mode : See ethernet.txt -- xlnx,phy-type : Deprecated, do not use, but still accepted in preference - to phy-mode. -- xlnx,txcsum : 0 or empty for disabling TX checksum offload, - 1 to enable partial TX checksum offload, - 2 to enable full TX checksum offload -- xlnx,rxcsum : Same values as xlnx,txcsum but for RX checksum offload -- xlnx,switch-x-sgmii : Boolean to indicate the Ethernet core is configured to - support both 1000BaseX and SGMII modes. If set, the phy-mode - should be set to match the mode selected on core reset (i.e. - by the basex_or_sgmii core input line). -- clock-names: Tuple listing input clock names. Possible clocks: - s_axi_lite_clk: Clock for AXI register slave interface - axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS interfaces - ref_clk: Ethernet reference clock, used by signal delay - primitives and transceivers - mgt_clk: MGT reference clock (used by optional internal - PCS/PMA PHY) - - Note that if s_axi_lite_clk is not specified by name, the - first clock of any name is used for this. If that is also not - specified, the clock rate is auto-detected from the CPU clock - (but only on platforms where this is possible). New device - trees should specify all applicable clocks by name - the - fallbacks to an unnamed clock or to CPU clock are only for - backward compatibility. -- clocks: Phandles to input clocks matching clock-names. Refer to common - clock bindings. -- axistream-connected: Reference to another node which contains the resources - for the AXI DMA controller used by this device. - If this is specified, the DMA-related resources from that - device (DMA registers and DMA TX/RX interrupts) rather - than this one will be used. - - mdio : Child node for MDIO bus. Must be defined if PHY access is - required through the core's MDIO interface (i.e. always, - unless the PHY is accessed through a different bus). - Non-standard MDIO bus frequency is supported via - "clock-frequency", see mdio.yaml. - - - pcs-handle: Phandle to the internal PCS/PMA PHY in SGMII or 1000Base-X - modes, where "pcs-handle" should be used to point - to the PCS/PMA PHY, and "phy-handle" should point to an - external PHY if exists. - -Example: - axi_ethernet_eth: ethernet@40c00000 { - compatible = "xlnx,axi-ethernet-1.00.a"; - device_type = "network"; - interrupt-parent = <µblaze_0_axi_intc>; - interrupts = <2 0 1>; - clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk"; - clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; - phy-mode = "mii"; - reg = <0x40c00000 0x40000 0x50c00000 0x40000>; - xlnx,rxcsum = <0x2>; - xlnx,rxmem = <0x800>; - xlnx,txcsum = <0x2>; - phy-handle = <&phy0>; - axi_ethernetlite_0_mdio: mdio { - #address-cells = <1>; - #size-cells = <0>; - phy0: phy@0 { - device_type = "ethernet-phy"; - reg = <1>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt b/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt deleted file mode 100644 index 038dda48b8e6..000000000000 --- a/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt +++ /dev/null @@ -1,35 +0,0 @@ -XILINX GMIITORGMII Converter Driver Device Tree Bindings --------------------------------------------------------- - -The Gigabit Media Independent Interface (GMII) to Reduced Gigabit Media -Independent Interface (RGMII) core provides the RGMII between RGMII-compliant -Ethernet physical media devices (PHY) and the Gigabit Ethernet controller. -This core can be used in all three modes of operation(10/100/1000 Mb/s). -The Management Data Input/Output (MDIO) interface is used to configure the -Speed of operation. This core can switch dynamically between the three -Different speed modes by configuring the conveter register through mdio write. - -This converter sits between the ethernet MAC and the external phy. -MAC <==> GMII2RGMII <==> RGMII_PHY - -For more details about mdio please refer phy.txt file in the same directory. - -Required properties: -- compatible : Should be "xlnx,gmii-to-rgmii-1.0" -- reg : The ID number for the phy, usually a small integer -- phy-handle : Should point to the external phy device. - See ethernet.txt file in the same directory. - -Example: - mdio { - #address-cells = <1>; - #size-cells = <0>; - phy: ethernet-phy@0 { - ...... - }; - gmiitorgmii: gmiitorgmii@8 { - compatible = "xlnx,gmii-to-rgmii-1.0"; - reg = <8>; - phy-handle = <&phy>; - }; - }; diff --git a/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml b/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml new file mode 100644 index 000000000000..1d33d80af11c --- /dev/null +++ b/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml @@ -0,0 +1,183 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/xlnx,axi-ethernet.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AXI 1G/2.5G Ethernet Subsystem + +description: | + Also called AXI 1G/2.5G Ethernet Subsystem, the xilinx axi ethernet IP core + provides connectivity to an external ethernet PHY supporting different + interfaces: MII, GMII, RGMII, SGMII, 1000BaseX. It also includes two + segments of memory for buffering TX and RX, as well as the capability of + offloading TX/RX checksum calculation off the processor. + + Management configuration is done through the AXI interface, while payload is + sent and received through means of an AXI DMA controller. This driver + includes the DMA driver code, so this driver is incompatible with AXI DMA + driver. + +maintainers: + - Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> + +properties: + compatible: + enum: + - xlnx,axi-ethernet-1.00.a + - xlnx,axi-ethernet-1.01.a + - xlnx,axi-ethernet-2.01.a + + reg: + description: + Address and length of the IO space, as well as the address + and length of the AXI DMA controller IO space, unless + axistream-connected is specified, in which case the reg + attribute of the node referenced by it is used. + maxItems: 2 + + interrupts: + items: + - description: Ethernet core interrupt + - description: Tx DMA interrupt + - description: Rx DMA interrupt + description: + Ethernet core interrupt is optional. If axistream-connected property is + present DMA node should contains TX/RX DMA interrupts else DMA interrupt + resources are mentioned on ethernet node. + minItems: 1 + + phy-handle: true + + xlnx,rxmem: + description: + Set to allocated memory buffer for Rx/Tx in the hardware. + $ref: /schemas/types.yaml#/definitions/uint32 + + phy-mode: + enum: + - mii + - gmii + - rgmii + - sgmii + - 1000BaseX + + xlnx,phy-type: + description: + Do not use, but still accepted in preference to phy-mode. + deprecated: true + $ref: /schemas/types.yaml#/definitions/uint32 + + xlnx,txcsum: + description: + TX checksum offload. 0 or empty for disabling TX checksum offload, + 1 to enable partial TX checksum offload and 2 to enable full TX + checksum offload. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + + xlnx,rxcsum: + description: + RX checksum offload. 0 or empty for disabling RX checksum offload, + 1 to enable partial RX checksum offload and 2 to enable full RX + checksum offload. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + + xlnx,switch-x-sgmii: + type: boolean + description: + Indicate the Ethernet core is configured to support both 1000BaseX and + SGMII modes. If set, the phy-mode should be set to match the mode + selected on core reset (i.e. by the basex_or_sgmii core input line). + + clocks: + items: + - description: Clock for AXI register slave interface. + - description: AXI4-Stream clock for TXD RXD TXC and RXS interfaces. + - description: Ethernet reference clock, used by signal delay primitives + and transceivers. + - description: MGT reference clock (used by optional internal PCS/PMA PHY) + + clock-names: + items: + - const: s_axi_lite_clk + - const: axis_clk + - const: ref_clk + - const: mgt_clk + + axistream-connected: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle of AXI DMA controller which contains the resources + used by this device. If this is specified, the DMA-related resources + from that device (DMA registers and DMA TX/RX interrupts) rather than + this one will be used. + + mdio: + type: object + + pcs-handle: + description: Phandle to the internal PCS/PMA PHY in SGMII or 1000Base-X + modes, where "pcs-handle" should be used to point to the PCS/PMA PHY, + and "phy-handle" should point to an external PHY if exists. + maxItems: 1 + +required: + - compatible + - interrupts + - reg + - xlnx,rxmem + - phy-handle + +allOf: + - $ref: /schemas/net/ethernet-controller.yaml# + +additionalProperties: false + +examples: + - | + axi_ethernet_eth: ethernet@40c00000 { + compatible = "xlnx,axi-ethernet-1.00.a"; + interrupts = <2 0 1>; + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk"; + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; + phy-mode = "mii"; + reg = <0x40c00000 0x40000>,<0x50c00000 0x40000>; + xlnx,rxcsum = <0x2>; + xlnx,rxmem = <0x800>; + xlnx,txcsum = <0x2>; + phy-handle = <&phy0>; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + phy0: ethernet-phy@1 { + device_type = "ethernet-phy"; + reg = <1>; + }; + }; + }; + + - | + axi_ethernet_eth1: ethernet@40000000 { + compatible = "xlnx,axi-ethernet-1.00.a"; + interrupts = <0>; + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk"; + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; + phy-mode = "mii"; + reg = <0x00 0x40000000 0x00 0x40000>; + xlnx,rxcsum = <0x2>; + xlnx,rxmem = <0x800>; + xlnx,txcsum = <0x2>; + phy-handle = <&phy1>; + axistream-connected = <&dma>; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + phy1: ethernet-phy@1 { + device_type = "ethernet-phy"; + reg = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml b/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml new file mode 100644 index 000000000000..0f781dac6717 --- /dev/null +++ b/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/xlnx,gmii-to-rgmii.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx GMII to RGMII Converter + +maintainers: + - Harini Katakam <harini.katakam@amd.com> + +description: + The Gigabit Media Independent Interface (GMII) to Reduced Gigabit Media + Independent Interface (RGMII) core provides the RGMII between RGMII-compliant + ethernet physical media devices (PHY) and the Gigabit Ethernet controller. + This core can be used in all three modes of operation(10/100/1000 Mb/s). + The Management Data Input/Output (MDIO) interface is used to configure the + speed of operation. This core can switch dynamically between the three + different speed modes by configuring the converter register through mdio write. + The core cannot function without an external phy connected to it. + +properties: + compatible: + const: xlnx,gmii-to-rgmii-1.0 + + reg: + minimum: 0 + maximum: 31 + description: The ID number for the phy. + + phy-handle: + $ref: ethernet-controller.yaml#/properties/phy-handle + +required: + - compatible + - reg + - phy-handle + +unevaluatedProperties: false + +examples: + - | + mdio { + #address-cells = <1>; + #size-cells = <0>; + + phy: ethernet-phy@0 { + reg = <0>; + }; + gmiitorgmii@8 { + compatible = "xlnx,gmii-to-rgmii-1.0"; + reg = <8>; + phy-handle = <&phy>; + }; + }; diff --git a/Documentation/devicetree/bindings/nios2/nios2.txt b/Documentation/devicetree/bindings/nios2/nios2.txt index b95e831bcba3..3e9cabe667b3 100644 --- a/Documentation/devicetree/bindings/nios2/nios2.txt +++ b/Documentation/devicetree/bindings/nios2/nios2.txt @@ -23,7 +23,7 @@ Required properties: - altr,tlb-num-ways: Specifies the number of set-associativity ways in the TLB. - altr,tlb-num-entries: Specifies the number of entries in the TLB. - altr,tlb-ptr-sz: Specifies size of TLB pointer. -- altr,has-mul: Specifies CPU hardware multipy support, should be 1. +- altr,has-mul: Specifies CPU hardware multiply support, should be 1. - altr,has-mmu: Specifies CPU support MMU support, should be 1. - altr,has-initda: Specifies CPU support initda instruction, should be 1. - altr,reset-addr: Specifies CPU reset address diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml index 36def7128fca..13412af7f046 100644 --- a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml +++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml @@ -36,14 +36,29 @@ properties: et0macaddr: type: object description: First Ethernet interface's MAC address + properties: + "#nvmem-cell-cells": + description: The first argument is a MAC address offset. + const: 1 + additionalProperties: false et1macaddr: type: object description: Second Ethernet interface's MAC address + properties: + "#nvmem-cell-cells": + description: The first argument is a MAC address offset. + const: 1 + additionalProperties: false et2macaddr: type: object description: Third Ethernet interface's MAC address + properties: + "#nvmem-cell-cells": + description: The first argument is a MAC address offset. + const: 1 + additionalProperties: false unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml new file mode 100644 index 000000000000..df826b40d8ca --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/fsl,t1023-sfp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP QorIQ eFuse support + +maintainers: + - Richard Alpe <richard@bit42.se> + +description: + Read support for the eFuses (SFP) on NXP QorIQ series SoC's. + +allOf: + - $ref: nvmem.yaml# + +properties: + compatible: + const: fsl,t1023-sfp + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + efuse@e8000 { + compatible = "fsl,t1023-sfp"; + reg = <0xe8000 0x1000>; + }; +... diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml index 9876243ff1e8..99e60d713dac 100644 --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/nvmem/imx-ocotp.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Freescale i.MX6 On-Chip OTP Controller (OCOTP) +title: Freescale i.MX On-Chip OTP Controller (OCOTP) maintainers: - Anson Huang <Anson.Huang@nxp.com> @@ -12,7 +12,7 @@ maintainers: description: | This binding represents the on-chip eFuse OTP controller found on i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL, i.MX6ULL/ULZ, i.MX6SLL, - i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM, i.MX8MN and i.MX8MP SoCs. + i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM, i.MX8MN i.MX8MP and i.MX93 SoCs. allOf: - $ref: nvmem.yaml# @@ -32,6 +32,7 @@ properties: - fsl,imx7ulp-ocotp - fsl,imx8mq-ocotp - fsl,imx8mm-ocotp + - fsl,imx93-ocotp - const: syscon - items: - enum: @@ -46,12 +47,6 @@ properties: reg: maxItems: 1 - "#address-cells": - const: 1 - - "#size-cells": - const: 1 - clocks: maxItems: 1 @@ -61,21 +56,6 @@ required: - compatible - reg -patternProperties: - "^.*@[0-9a-f]+$": - type: object - - properties: - reg: - maxItems: 1 - description: - Offset and size in bytes within the storage device. - - required: - - reg - - additionalProperties: false - unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml new file mode 100644 index 000000000000..ac2381e66027 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/layouts/fixed-cell.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Fixed offset & size NVMEM cell + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +properties: + compatible: + oneOf: + - const: mac-base + description: > + Cell with base MAC address to be used for calculating extra relative + addresses. + It can be stored in a plain binary format (cell length 6) or as an + ASCII text like "00:11:22:33:44:55" (cell length 17). + + reg: + maxItems: 1 + + bits: + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - minimum: 0 + maximum: 7 + description: + Offset in bit within the address range specified by reg. + - minimum: 1 + description: + Size in bit within the address range specified by reg. + +allOf: + - if: + required: [ compatible ] + then: + if: + properties: + compatible: + contains: + const: mac-base + then: + properties: + "#nvmem-cell-cells": + description: The first argument is a MAC address offset. + const: 1 + required: + - "#nvmem-cell-cells" + +required: + - reg + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml new file mode 100644 index 000000000000..9bd34bd5af30 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/layouts/fixed-layout.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVMEM layout for fixed NVMEM cells + +description: + Many NVMEM devices have hardcoded cells layout (offset and size of defined + NVMEM content doesn't change). + + This binding allows defining such NVMEM layout with its cells. It can be used + on top of any NVMEM device. + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +properties: + compatible: + const: fixed-layout + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + +patternProperties: + "@[a-f0-9]+$": + type: object + $ref: fixed-cell.yaml + unevaluatedProperties: false + +required: + - compatible + +additionalProperties: false + +examples: + - | + nvmem-layout { + compatible = "fixed-layout"; + #address-cells = <1>; + #size-cells = <1>; + + mac@100 { + compatible = "mac-base"; + reg = <0x100 0x6>; + #nvmem-cell-cells = <1>; + }; + + mac@110 { + compatible = "mac-base"; + reg = <0x110 0x11>; + #nvmem-cell-cells = <1>; + }; + + calibration@4000 { + reg = <0x4000 0x100>; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml index 8512ee538c4c..3b40f7880774 100644 --- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml +++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml @@ -18,16 +18,13 @@ description: | perform their parsing. The nvmem-layout container is here to describe these. oneOf: + - $ref: fixed-layout.yaml - $ref: kontron,sl28-vpd.yaml - $ref: onie,tlv-layout.yaml properties: compatible: true - '#address-cells': false - - '#size-cells': false - required: - compatible diff --git a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml index 714a6538cc7c..ee8ac322332d 100644 --- a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml +++ b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml @@ -14,7 +14,7 @@ description: infrastructure shall provide a non-volatile memory with a table whose the content is well specified and gives many information about the manufacturer (name, country of manufacture, etc) as well as device caracteristics (serial - number, hardware version, mac addresses, etc). The underlaying device type + number, hardware version, mac addresses, etc). The underlying device type (flash, EEPROM,...) is not specified. The exact location of each value is also dynamic and should be discovered at run time because it depends on the parameters the manufacturer decided to embed. diff --git a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml index d16d42fb98b6..7ec2988b597e 100644 --- a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml +++ b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml @@ -27,6 +27,7 @@ properties: - enum: - mediatek,mt7622-efuse - mediatek,mt7623-efuse + - mediatek,mt7986-efuse - mediatek,mt8173-efuse - mediatek,mt8183-efuse - mediatek,mt8186-efuse diff --git a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml index 8938eec22b52..a9b822aeaa7e 100644 --- a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml +++ b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml @@ -18,12 +18,6 @@ properties: - fsl,imx23-ocotp - fsl,imx28-ocotp - "#address-cells": - const: 1 - - "#size-cells": - const: 1 - reg: maxItems: 1 @@ -35,7 +29,7 @@ required: - reg - clocks -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml index 75bb93dda9df..9f921d940142 100644 --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml @@ -49,23 +49,11 @@ properties: patternProperties: "@[0-9a-f]+(,[0-7])?$": type: object - - properties: - reg: - maxItems: 1 - description: - Offset and size in bytes within the storage device. - - bits: - $ref: /schemas/types.yaml#/definitions/uint32-array - items: - - minimum: 0 - maximum: 7 - description: - Offset in bit within the address range specified by reg. - - minimum: 1 - description: - Size in bit within the address range specified by reg. + allOf: + - $ref: layouts/fixed-cell.yaml + - properties: + compatible: false + deprecated: true additionalProperties: true @@ -83,24 +71,30 @@ examples: /* ... */ - /* Data cells */ - tsens_calibration: calib@404 { - reg = <0x404 0x10>; - }; - - tsens_calibration_bckp: calib_bckp@504 { - reg = <0x504 0x11>; - bits = <6 128>; - }; - - pvs_version: pvs-version@6 { - reg = <0x6 0x2>; - bits = <7 2>; - }; - - speed_bin: speed-bin@c{ - reg = <0xc 0x1>; - bits = <2 3>; + nvmem-layout { + compatible = "fixed-layout"; + #address-cells = <1>; + #size-cells = <1>; + + /* Data cells */ + tsens_calibration: calib@404 { + reg = <0x404 0x10>; + }; + + tsens_calibration_bckp: calib_bckp@504 { + reg = <0x504 0x11>; + bits = <6 128>; + }; + + pvs_version: pvs-version@6 { + reg = <0x6 0x2>; + bits = <7 2>; + }; + + speed_bin: speed-bin@c{ + reg = <0xc 0x1>; + bits = <2 3>; + }; }; }; diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml index 8d8503dd934b..8740938c32eb 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml @@ -18,13 +18,18 @@ properties: - enum: - qcom,apq8064-qfprom - qcom,apq8084-qfprom + - qcom,ipq5332-qfprom + - qcom,ipq6018-qfprom - qcom,ipq8064-qfprom - qcom,ipq8074-qfprom + - qcom,ipq9574-qfprom + - qcom,msm8226-qfprom - qcom,msm8916-qfprom - qcom,msm8974-qfprom - qcom,msm8976-qfprom - qcom,msm8996-qfprom - qcom,msm8998-qfprom + - qcom,qcm2290-qfprom - qcom,qcs404-qfprom - qcom,sc7180-qfprom - qcom,sc7280-qfprom @@ -64,12 +69,6 @@ properties: power-domains: maxItems: 1 - # Needed if any child nodes are present. - "#address-cells": - const: 1 - "#size-cells": - const: 1 - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/nvmem/qcom,sec-qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,sec-qfprom.yaml new file mode 100644 index 000000000000..9b133f783d29 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/qcom,sec-qfprom.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/qcom,sec-qfprom.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies Inc, Secure QFPROM Efuse + +maintainers: + - Komal Bajaj <quic_kbajaj@quicinc.com> + +description: + For some of the Qualcomm SoC's, it is possible that the qfprom region is + protected from non-secure access. In such situations, the OS have to use + secure calls to read the region. + +allOf: + - $ref: nvmem.yaml# + +properties: + compatible: + items: + - enum: + - qcom,qdu1000-sec-qfprom + - const: qcom,sec-qfprom + + reg: + items: + - description: The secure qfprom corrected region. + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + efuse@221c8000 { + compatible = "qcom,qdu1000-sec-qfprom", "qcom,sec-qfprom"; + reg = <0 0x221c8000 0 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + + multi_chan_ddr: multi-chan-ddr@12b { + reg = <0x12b 0x1>; + bits = <0 2>; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml index dce0c7d84ce7..cd980def97b8 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml @@ -25,12 +25,6 @@ properties: reg: maxItems: 1 - "#address-cells": - const: 1 - - "#size-cells": - const: 1 - ranges: true required: diff --git a/Documentation/devicetree/bindings/nvmem/rmem.yaml b/Documentation/devicetree/bindings/nvmem/rmem.yaml index 38a39c9b8c1c..1ec0d09bcafa 100644 --- a/Documentation/devicetree/bindings/nvmem/rmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/rmem.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - raspberrypi,bootloader-config + - raspberrypi,bootloader-public-key - const: nvmem-rmem reg: diff --git a/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml b/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml new file mode 100644 index 000000000000..9c6eff788928 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml @@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/rockchip,otp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip internal OTP (One Time Programmable) memory + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + enum: + - rockchip,px30-otp + - rockchip,rk3308-otp + - rockchip,rk3588-otp + + reg: + maxItems: 1 + + clocks: + minItems: 3 + maxItems: 4 + + clock-names: + minItems: 3 + items: + - const: otp + - const: apb_pclk + - const: phy + - const: arb + + resets: + minItems: 1 + maxItems: 3 + + reset-names: + minItems: 1 + maxItems: 3 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + +allOf: + - $ref: nvmem.yaml# + + - if: + properties: + compatible: + contains: + enum: + - rockchip,px30-otp + - rockchip,rk3308-otp + then: + properties: + clocks: + maxItems: 3 + resets: + maxItems: 1 + reset-names: + items: + - const: phy + + - if: + properties: + compatible: + contains: + enum: + - rockchip,rk3588-otp + then: + properties: + clocks: + minItems: 4 + resets: + minItems: 3 + reset-names: + items: + - const: otp + - const: apb + - const: arb + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/px30-cru.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + otp: efuse@ff290000 { + compatible = "rockchip,px30-otp"; + reg = <0x0 0xff290000 0x0 0x4000>; + clocks = <&cru SCLK_OTP_USR>, <&cru PCLK_OTP_NS>, + <&cru PCLK_OTP_PHY>; + clock-names = "otp", "apb_pclk", "phy"; + resets = <&cru SRST_OTP_PHY>; + reset-names = "phy"; + #address-cells = <1>; + #size-cells = <1>; + + cpu_id: id@7 { + reg = <0x07 0x10>; + }; + + cpu_leakage: cpu-leakage@17 { + reg = <0x17 0x1>; + }; + + performance: performance@1e { + reg = <0x1e 0x1>; + bits = <4 3>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-otp.txt b/Documentation/devicetree/bindings/nvmem/rockchip-otp.txt deleted file mode 100644 index 40f649f7c2e5..000000000000 --- a/Documentation/devicetree/bindings/nvmem/rockchip-otp.txt +++ /dev/null @@ -1,25 +0,0 @@ -Rockchip internal OTP (One Time Programmable) memory device tree bindings - -Required properties: -- compatible: Should be one of the following. - - "rockchip,px30-otp" - for PX30 SoCs. - - "rockchip,rk3308-otp" - for RK3308 SoCs. -- reg: Should contain the registers location and size -- clocks: Must contain an entry for each entry in clock-names. -- clock-names: Should be "otp", "apb_pclk" and "phy". -- resets: Must contain an entry for each entry in reset-names. - See ../../reset/reset.txt for details. -- reset-names: Should be "phy". - -See nvmem.txt for more information. - -Example: - otp: otp@ff290000 { - compatible = "rockchip,px30-otp"; - reg = <0x0 0xff290000 0x0 0x4000>; - #address-cells = <1>; - #size-cells = <1>; - clocks = <&cru SCLK_OTP_USR>, <&cru PCLK_OTP_NS>, - <&cru PCLK_OTP_PHY>; - clock-names = "otp", "apb_pclk", "phy"; - }; diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml index b8bca0599c45..efccc5aacbe0 100644 --- a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml +++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml @@ -14,9 +14,6 @@ allOf: - $ref: nvmem.yaml# properties: - "#address-cells": true - "#size-cells": true - compatible: const: socionext,uniphier-efuse diff --git a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml index 8877c2283e9e..da3f1de7d281 100644 --- a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml +++ b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml @@ -28,12 +28,6 @@ properties: clocks: maxItems: 1 - "#address-cells": - const: 1 - - "#size-cells": - const: 1 - thermal-calibration: type: object description: thermal calibration values diff --git a/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml new file mode 100644 index 000000000000..02d1d2c17129 --- /dev/null +++ b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/opp/operating-points-v2-ti-cpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI CPU OPP (Operating Performance Points) + +description: + TI SoCs, like those in the AM335x, AM437x, AM57xx, AM62x, and DRA7xx + families, the CPU frequencies subset and the voltage value of each + OPP vary based on the silicon variant used. The data sheet sections + corresponding to "Operating Performance Points" describe the frequency + and voltage values based on device type and speed bin information + blown in corresponding eFuse bits as referred to by the Technical + Reference Manual. + + This document extends the operating-points-v2 binding by providing + the hardware description for the scheme mentioned above. + +maintainers: + - Nishanth Menon <nm@ti.com> + +allOf: + - $ref: opp-v2-base.yaml# + +properties: + compatible: + const: operating-points-v2-ti-cpu + + syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + points to syscon node representing the control module + register space of the SoC. + + opp-shared: true + +patternProperties: + '^opp(-?[0-9]+)*$': + type: object + additionalProperties: false + + properties: + clock-latency-ns: true + opp-hz: true + opp-microvolt: true + opp-supported-hw: true + opp-suspend: true + turbo-mode: true + + required: + - opp-hz + - opp-supported-hw + +required: + - compatible + - syscon + +additionalProperties: false + +examples: + - | + opp-table { + compatible = "operating-points-v2-ti-cpu"; + syscon = <&scm_conf>; + + opp-300000000 { + opp-hz = /bits/ 64 <300000000>; + opp-microvolt = <1100000 1078000 1122000>; + opp-supported-hw = <0x06 0x0020>; + opp-suspend; + }; + + opp-500000000 { + opp-hz = /bits/ 64 <500000000>; + opp-microvolt = <1100000 1078000 1122000>; + opp-supported-hw = <0x01 0xFFFF>; + }; + + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <1100000 1078000 1122000>; + opp-supported-hw = <0x06 0x0040>; + }; + + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <1325000 1298500 1351500>; + opp-supported-hw = <0x04 0x0200>; + }; + }; diff --git a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml index 47e6f36b7637..e2f8f7af3cf4 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml @@ -56,7 +56,7 @@ patternProperties: need to be configured and that is left for the implementation specific binding. minItems: 1 - maxItems: 16 + maxItems: 32 items: maxItems: 1 diff --git a/Documentation/devicetree/bindings/opp/ti,omap-opp-supply.yaml b/Documentation/devicetree/bindings/opp/ti,omap-opp-supply.yaml new file mode 100644 index 000000000000..693f22539606 --- /dev/null +++ b/Documentation/devicetree/bindings/opp/ti,omap-opp-supply.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/opp/ti,omap-opp-supply.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments OMAP compatible OPP supply + +description: + OMAP5, DRA7, and AM57 families of SoCs have Class 0 AVS eFuse + registers, which contain OPP-specific voltage information tailored + for the specific device. This binding provides the information + needed to describe such a hardware values and relate them to program + the primary regulator during an OPP transition. + + Also, some supplies may have an associated vbb-supply, an Adaptive + Body Bias regulator, which must transition in a specific sequence + w.r.t the vdd-supply and clk when making an OPP transition. By + supplying two regulators to the device that will undergo OPP + transitions, we can use the multi-regulator support implemented by + the OPP core to describe both regulators the platform needs. The + OPP core binding Documentation/devicetree/bindings/opp/opp-v2.yaml + provides further information (refer to Example 4 Handling multiple + regulators). + +maintainers: + - Nishanth Menon <nm@ti.com> + +properties: + $nodename: + pattern: '^opp-supply(@[0-9a-f]+)?$' + + compatible: + oneOf: + - description: Basic OPP supply controlling VDD and VBB + const: ti,omap-opp-supply + - description: OMAP5+ optimized voltages in efuse(Class 0) VDD along with + VBB. + const: ti,omap5-opp-supply + - description: OMAP5+ optimized voltages in efuse(class0) VDD but no VBB + const: ti,omap5-core-opp-supply + + reg: + maxItems: 1 + + ti,absolute-max-voltage-uv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Absolute maximum voltage for the OPP supply in micro-volts. + minimum: 750000 + maximum: 1500000 + + ti,efuse-settings: + description: An array of u32 tuple items providing information about + optimized efuse configuration. + minItems: 1 + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: Reference voltage in micro-volts (OPP Voltage) + minimum: 750000 + maximum: 1500000 + multipleOf: 10000 + - description: efuse offset where the optimized voltage is located + multipleOf: 4 + maximum: 256 + +required: + - compatible + - ti,absolute-max-voltage-uv + +allOf: + - if: + not: + properties: + compatible: + contains: + const: ti,omap-opp-supply + then: + required: + - reg + - ti,efuse-settings + +additionalProperties: false + +examples: + - | + opp-supply { + compatible = "ti,omap-opp-supply"; + ti,absolute-max-voltage-uv = <1375000>; + }; + - | + opp-supply@4a003b20 { + compatible = "ti,omap5-opp-supply"; + reg = <0x4a003b20 0x8>; + ti,efuse-settings = + /* uV offset */ + <1060000 0x0>, + <1160000 0x4>, + <1210000 0x8>; + ti,absolute-max-voltage-uv = <1500000>; + }; diff --git a/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt b/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt deleted file mode 100644 index b70d326117cd..000000000000 --- a/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt +++ /dev/null @@ -1,63 +0,0 @@ -Texas Instruments OMAP compatible OPP supply description - -OMAP5, DRA7, and AM57 family of SoCs have Class0 AVS eFuse registers which -contain data that can be used to adjust voltages programmed for some of their -supplies for more efficient operation. This binding provides the information -needed to read these values and use them to program the main regulator during -an OPP transitions. - -Also, some supplies may have an associated vbb-supply which is an Adaptive Body -Bias regulator which much be transitioned in a specific sequence with regards -to the vdd-supply and clk when making an OPP transition. By supplying two -regulators to the device that will undergo OPP transitions we can make use -of the multi regulator binding that is part of the OPP core described here [1] -to describe both regulators needed by the platform. - -[1] Documentation/devicetree/bindings/opp/opp-v2.yaml - -Required Properties for Device Node: -- vdd-supply: phandle to regulator controlling VDD supply -- vbb-supply: phandle to regulator controlling Body Bias supply - (Usually Adaptive Body Bias regulator) - -Required Properties for opp-supply node: -- compatible: Should be one of: - "ti,omap-opp-supply" - basic OPP supply controlling VDD and VBB - "ti,omap5-opp-supply" - OMAP5+ optimized voltages in efuse(class0)VDD - along with VBB - "ti,omap5-core-opp-supply" - OMAP5+ optimized voltages in efuse(class0) VDD - but no VBB. -- reg: Address and length of the efuse register set for the device (mandatory - only for "ti,omap5-opp-supply") -- ti,efuse-settings: An array of u32 tuple items providing information about - optimized efuse configuration. Each item consists of the following: - volt: voltage in uV - reference voltage (OPP voltage) - efuse_offseet: efuse offset from reg where the optimized voltage is stored. -- ti,absolute-max-voltage-uv: absolute maximum voltage for the OPP supply. - -Example: - -/* Device Node (CPU) */ -cpus { - cpu0: cpu@0 { - device_type = "cpu"; - - ... - - vdd-supply = <&vcc>; - vbb-supply = <&abb_mpu>; - }; -}; - -/* OMAP OPP Supply with Class0 registers */ -opp_supply_mpu: opp_supply@4a003b20 { - compatible = "ti,omap5-opp-supply"; - reg = <0x4a003b20 0x8>; - ti,efuse-settings = < - /* uV offset */ - 1060000 0x0 - 1160000 0x4 - 1210000 0x8 - >; - ti,absolute-max-voltage-uv = <1500000>; -}; diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml index b3c22ebd156c..a223ce029cab 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml @@ -11,9 +11,13 @@ maintainers: properties: compatible: - enum: - - qcom,sdx55-pcie-ep - - qcom,sm8450-pcie-ep + oneOf: + - enum: + - qcom,sdx55-pcie-ep + - qcom,sm8450-pcie-ep + - items: + - const: qcom,sdx65-pcie-ep + - const: qcom,sdx55-pcie-ep reg: items: @@ -70,6 +74,14 @@ properties: description: GPIO used as WAKE# output signal maxItems: 1 + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: pcie-mem + - const: cpu-pcie + resets: maxItems: 1 @@ -97,6 +109,8 @@ required: - interrupts - interrupt-names - reset-gpios + - interconnects + - interconnect-names - resets - reset-names - power-domains @@ -165,7 +179,9 @@ examples: - | #include <dt-bindings/clock/qcom,gcc-sdx55.h> #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interconnect/qcom,sdx55.h> #include <dt-bindings/interrupt-controller/arm-gic.h> + pcie_ep: pcie-ep@1c00000 { compatible = "qcom,sdx55-pcie-ep"; reg = <0x01c00000 0x3000>, @@ -192,6 +208,9 @@ examples: interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "global", "doorbell"; + interconnects = <&system_noc MASTER_PCIE &mc_virt SLAVE_EBI_CH0>, + <&mem_noc MASTER_AMPSS_M0 &system_noc SLAVE_PCIE_0>; + interconnect-names = "pcie-mem", "cpu-pcie"; reset-gpios = <&tlmm 57 GPIO_ACTIVE_LOW>; wake-gpios = <&tlmm 53 GPIO_ACTIVE_LOW>; resets = <&gcc GCC_PCIE_BCR>; diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml index 81971be4e554..eadba38171e1 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml @@ -29,6 +29,7 @@ properties: - qcom,pcie-msm8996 - qcom,pcie-qcs404 - qcom,pcie-sa8540p + - qcom,pcie-sa8775p - qcom,pcie-sc7280 - qcom,pcie-sc8180x - qcom,pcie-sc8280xp @@ -211,6 +212,7 @@ allOf: compatible: contains: enum: + - qcom,pcie-sa8775p - qcom,pcie-sc7280 - qcom,pcie-sc8180x - qcom,pcie-sc8280xp @@ -748,7 +750,32 @@ allOf: compatible: contains: enum: + - qcom,pcie-sa8775p + then: + properties: + clocks: + minItems: 5 + maxItems: 5 + clock-names: + items: + - const: aux # Auxiliary clock + - const: cfg # Configuration clock + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - const: slave_q2a # Slave Q2A clock + resets: + maxItems: 1 + reset-names: + items: + - const: pci # PCIe core reset + + - if: + properties: + compatible: + contains: + enum: - qcom,pcie-sa8540p + - qcom,pcie-sa8775p - qcom,pcie-sc8280xp then: required: @@ -790,6 +817,7 @@ allOf: contains: enum: - qcom,pcie-msm8996 + - qcom,pcie-sa8775p - qcom,pcie-sc7280 - qcom,pcie-sc8180x - qcom,pcie-sdm845 diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml index 88386a6d7011..6b62f6f58efe 100644 --- a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml @@ -47,7 +47,7 @@ examples: pcie-ep@f8000000 { compatible = "rockchip,rk3399-pcie-ep"; - reg = <0x0 0xfd000000 0x0 0x1000000>, <0x0 0x80000000 0x0 0x20000>; + reg = <0x0 0xfd000000 0x0 0x1000000>, <0x0 0xfa000000 0x0 0x2000000>; reg-names = "apb-base", "mem-base"; clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>, <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>; @@ -63,6 +63,8 @@ examples: phys = <&pcie_phy 0>, <&pcie_phy 1>, <&pcie_phy 2>, <&pcie_phy 3>; phy-names = "pcie-phy-0", "pcie-phy-1", "pcie-phy-2", "pcie-phy-3"; rockchip,max-outbound-regions = <16>; + pinctrl-names = "default"; + pinctrl-0 = <&pcie_clkreqnb_cpm>; }; }; ... diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml index 24c88942e59e..1ae8dcfa072c 100644 --- a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml @@ -41,20 +41,79 @@ properties: - const: config clocks: + minItems: 5 items: - description: AHB clock for PCIe master - description: AHB clock for PCIe slave - description: AHB clock for PCIe dbi - description: APB clock for PCIe - description: Auxiliary clock for PCIe + - description: PIPE clock clock-names: + minItems: 5 items: - const: aclk_mst - const: aclk_slv - const: aclk_dbi - const: pclk - const: aux + - const: pipe + + interrupts: + items: + - description: + Combined system interrupt, which is used to signal the following + interrupts - phy_link_up, dll_link_up, link_req_rst_not, hp_pme, + hp, hp_msi, link_auto_bw, link_auto_bw_msi, bw_mgt, bw_mgt_msi, + edma_wr, edma_rd, dpa_sub_upd, rbar_update, link_eq_req, ep_elbi_app + - description: + Combined PM interrupt, which is used to signal the following + interrupts - linkst_in_l1sub, linkst_in_l1, linkst_in_l2, + linkst_in_l0s, linkst_out_l1sub, linkst_out_l1, linkst_out_l2, + linkst_out_l0s, pm_dstate_update + - description: + Combined message interrupt, which is used to signal the following + interrupts - ven_msg, unlock_msg, ltr_msg, cfg_pme, cfg_pme_msi, + pm_pme, pm_to_ack, pm_turnoff, obff_idle, obff_obff, obff_cpu_active + - description: + Combined legacy interrupt, which is used to signal the following + interrupts - inta, intb, intc, intd + - description: + Combined error interrupt, which is used to signal the following + interrupts - aer_rc_err, aer_rc_err_msi, rx_cpl_timeout, + tx_cpl_timeout, cor_err_sent, nf_err_sent, f_err_sent, cor_err_rx, + nf_err_rx, f_err_rx, radm_qoverflow + + interrupt-names: + items: + - const: sys + - const: pmc + - const: msg + - const: legacy + - const: err + + legacy-interrupt-controller: + description: Interrupt controller node for handling legacy PCI interrupts. + type: object + additionalProperties: false + properties: + "#address-cells": + const: 0 + + "#interrupt-cells": + const: 1 + + interrupt-controller: true + + interrupts: + items: + - description: combined legacy interrupt + required: + - "#address-cells" + - "#interrupt-cells" + - interrupt-controller + - interrupts msi-map: true @@ -70,13 +129,19 @@ properties: maxItems: 1 ranges: - maxItems: 2 + minItems: 2 + maxItems: 3 resets: - maxItems: 1 + minItems: 1 + maxItems: 2 reset-names: - const: pipe + oneOf: + - const: pipe + - items: + - const: pwr + - const: pipe vpcie3v3-supply: true @@ -98,6 +163,7 @@ unevaluatedProperties: false examples: - | + #include <dt-bindings/interrupt-controller/arm-gic.h> bus { #address-cells = <2>; @@ -117,6 +183,12 @@ examples: "aclk_dbi", "pclk", "aux"; device_type = "pci"; + interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "sys", "pmc", "msg", "legacy", "err"; linux,pci-domain = <2>; max-link-speed = <2>; msi-map = <0x2000 &its 0x2000 0x1000>; @@ -130,6 +202,14 @@ examples: reset-names = "pipe"; #address-cells = <3>; #size-cells = <2>; + + legacy-interrupt-controller { + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>; + }; }; }; ... diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml index 1a83f0f65f19..8bbdeb8821f8 100644 --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml @@ -25,6 +25,15 @@ select: allOf: - $ref: /schemas/pci/pci-bus.yaml# - $ref: /schemas/pci/snps,dw-pcie-common.yaml# + - if: + not: + required: + - msi-map + then: + properties: + interrupt-names: + contains: + const: msi properties: reg: @@ -188,14 +197,15 @@ properties: Link Control register). const: bw_mg - description: + Combined Legacy A/B/C/D interrupt signal. See "^int(a|b|c|d)$" for + details. + const: legacy + - description: Vendor-specific IRQ names. Consider using the generic names above for new bindings. oneOf: - description: See native "app" IRQ for details - enum: [ intr ] - allOf: - - contains: - const: msi + enum: [ intr, sys, pmc, msg, err ] additionalProperties: true diff --git a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml index 24ddc2855b94..4734be456bde 100644 --- a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml +++ b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: CPM Host Controller device tree for Xilinx Versal SoCs maintainers: - - Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> + - Bharat Kumar Gogada <bharat.kumar.gogada@amd.com> allOf: - $ref: /schemas/pci/pci-bus.yaml# diff --git a/Documentation/devicetree/bindings/peci/nuvoton,npcm-peci.yaml b/Documentation/devicetree/bindings/peci/nuvoton,npcm-peci.yaml new file mode 100644 index 000000000000..087e02a9ade3 --- /dev/null +++ b/Documentation/devicetree/bindings/peci/nuvoton,npcm-peci.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/peci/nuvoton,npcm-peci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton PECI Bus + +maintainers: + - Tomer Maimon <tmaimon77@gmail.com> + +allOf: + - $ref: peci-controller.yaml# + +properties: + compatible: + enum: + - nuvoton,npcm750-peci + - nuvoton,npcm845-peci + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: + Clock source for PECI controller. Should reference the APB clock. + maxItems: 1 + + cmd-timeout-ms: + minimum: 1 + maximum: 1000 + default: 1000 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/nuvoton,npcm7xx-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + peci-controller@f0100000 { + compatible = "nuvoton,npcm750-peci"; + reg = <0xf0100000 0x200>; + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk NPCM7XX_CLK_APB3>; + cmd-timeout-ms = <1000>; + }; +... diff --git a/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml b/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml index 50f46a6898b1..4adab0149108 100644 --- a/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml +++ b/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml @@ -42,8 +42,8 @@ examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> pmu { - #address-cells=<2>; - #size-cells=<2>; + #address-cells = <2>; + #size-cells = <2>; pmu@ff638000 { compatible = "amlogic,g12a-ddr-pmu"; diff --git a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml index 80a92385367e..e9fad4b3de68 100644 --- a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml +++ b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/perf/fsl-imx-ddr.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Freescale(NXP) IMX8 DDR performance monitor +title: Freescale(NXP) IMX8/9 DDR performance monitor maintainers: - Frank Li <frank.li@nxp.com> @@ -19,6 +19,7 @@ properties: - fsl,imx8mm-ddr-pmu - fsl,imx8mn-ddr-pmu - fsl,imx8mp-ddr-pmu + - fsl,imx93-ddr-pmu - items: - enum: - fsl,imx8mm-ddr-pmu diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml index 43a4b880534c..580fbe37b37f 100644 --- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml @@ -115,8 +115,8 @@ allOf: compatible: contains: enum: - - const: brcm,bcm4908-usb-phy - - const: brcm,brcmstb-usb-phy + - brcm,bcm4908-usb-phy + - brcm,brcmstb-usb-phy then: properties: reg: diff --git a/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.txt deleted file mode 100644 index 3dc8b3d2ffbb..000000000000 --- a/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.txt +++ /dev/null @@ -1,15 +0,0 @@ -BROADCOM KONA USB2 PHY - -Required properties: - - compatible: brcm,kona-usb2-phy - - reg: offset and length of the PHY registers - - #phy-cells: must be 0 -Refer to phy/phy-bindings.txt for the generic PHY binding properties - -Example: - - usbphy: usb-phy@3f130000 { - compatible = "brcm,kona-usb2-phy"; - reg = <0x3f130000 0x28>; - #phy-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.yaml new file mode 100644 index 000000000000..d7faeb81f7a7 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/brcm,kona-usb2-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Kona family USB 2.0 PHY + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +properties: + compatible: + const: brcm,kona-usb2-phy + + reg: + maxItems: 1 + + '#phy-cells': + const: 0 + +required: + - compatible + - reg + - '#phy-cells' + +additionalProperties: false + +examples: + - | + usb-phy@3f130000 { + compatible = "brcm,kona-usb2-phy"; + reg = <0x3f130000 0x28>; + #phy-cells = <0>; + }; +... diff --git a/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml b/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml index c9e65a2facd5..c7281a7c8244 100644 --- a/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml +++ b/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml @@ -31,6 +31,12 @@ properties: "#phy-cells": const: 0 + cdns,usb2-disconnect-threshold-microvolt: + description: The microvolt threshold value utilized for detecting + USB disconnection event. + enum: [575, 610, 645] + default: 575 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml index e6f9f5540cc3..dc3a3f709fea 100644 --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml @@ -35,6 +35,53 @@ properties: description: A phandle to the regulator for USB VBUS. + fsl,phy-tx-vref-tune-percent: + description: + Tunes the HS DC level relative to the nominal level + minimum: 94 + maximum: 124 + + fsl,phy-tx-rise-tune-percent: + description: + Adjusts the rise/fall time duration of the HS waveform relative to + its nominal value + minimum: 97 + maximum: 103 + + fsl,phy-tx-preemp-amp-tune-microamp: + description: + Adjust amount of current sourced to DPn and DMn after a J-to-K + or K-to-J transition. Default is 0 (disabled). + minimum: 0 + maximum: 1800 + + fsl,phy-tx-vboost-level-microvolt: + description: + Adjust the boosted transmit launch pk-pk differential amplitude + minimum: 880 + maximum: 1120 + + fsl,phy-comp-dis-tune-percent: + description: + Adjust the voltage level used to detect a disconnect event at the host + relative to the nominal value + minimum: 91 + maximum: 115 + + fsl,phy-pcs-tx-deemph-3p5db-attenuation-db: + description: + Adjust TX de-emphasis attenuation in dB at nominal + 3.5dB point as per USB specification + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 36 + + fsl,phy-pcs-tx-swing-full-percent: + description: + Scaling of the voltage defined by fsl,phy-tx-vboost-level-microvolt + minimum: 0 + maximum: 100 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml new file mode 100644 index 000000000000..f4b1ca2fb562 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml @@ -0,0 +1,128 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/fsl,mxs-usbphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MXS USB Phy Device + +maintainers: + - Xu Yang <xu.yang_2@nxp.com> + +properties: + compatible: + oneOf: + - enum: + - fsl,imx23-usbphy + - fsl,imx7ulp-usbphy + - fsl,vf610-usbphy + - items: + - enum: + - fsl,imx28-usbphy + - fsl,imx6ul-usbphy + - fsl,imx6sl-usbphy + - fsl,imx6sx-usbphy + - fsl,imx6q-usbphy + - const: fsl,imx23-usbphy + - items: + - const: fsl,imx6sll-usbphy + - const: fsl,imx6ul-usbphy + - const: fsl,imx23-usbphy + - items: + - enum: + - fsl,imx8dxl-usbphy + - fsl,imx8qm-usbphy + - fsl,imx8ulp-usbphy + - const: fsl,imx7ulp-usbphy + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + '#phy-cells': + const: 0 + + power-domains: + maxItems: 1 + + fsl,anatop: + description: + phandle for anatop register, it is only for imx6 SoC series. + $ref: /schemas/types.yaml#/definitions/phandle + + phy-3p0-supply: + description: + One of USB PHY's power supply. Can be used to keep a good signal + quality. + + fsl,tx-cal-45-dn-ohms: + description: + Resistance (in ohms) of switchable high-speed trimming resistor + connected in parallel with the 45 ohm resistor that terminates + the DN output signal. + minimum: 35 + maximum: 54 + default: 45 + + fsl,tx-cal-45-dp-ohms: + description: + Resistance (in ohms) of switchable high-speed trimming resistor + connected in parallel with the 45 ohm resistor that terminates + the DP output signal. + minimum: 35 + maximum: 54 + default: 45 + + fsl,tx-d-cal: + description: + Current trimming value (as a percentage) of the 17.78 mA TX + reference current. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 79 + maximum: 119 + default: 100 + +required: + - compatible + - reg + - clocks + +allOf: + - if: + properties: + compatible: + oneOf: + - enum: + - fsl,imx6q-usbphy + - fsl,imx6sl-usbphy + - fsl,imx6sx-usbphy + - fsl,imx6sll-usbphy + - fsl,vf610-usbphy + - items: + - const: fsl,imx6ul-usbphy + - const: fsl,imx23-usbphy + then: + required: + - fsl,anatop + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx6qdl-clock.h> + + usbphy1: usb-phy@20c9000 { + compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy"; + reg = <0x020c9000 0x1000>; + clocks = <&clks IMX6QDL_CLK_USBPHY1>; + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; + fsl,anatop = <&anatop>; + }; + +... diff --git a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml index 5d54b0a0e873..7dd6a4d94b48 100644 --- a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml +++ b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml @@ -15,7 +15,7 @@ description: | properties: $nodename: - pattern: "combophy(@.*|-[0-9a-f])*$" + pattern: "combophy(@.*|-([0-9]|[1-9][0-9]+))?$" compatible: items: diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml index 26f2b887cfc1..a63b20dfa4a5 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml @@ -26,6 +26,10 @@ properties: - const: mediatek,mt2701-mipi-tx - items: - enum: + - mediatek,mt6795-mipi-tx + - const: mediatek,mt8173-mipi-tx + - items: + - enum: - mediatek,mt8365-mipi-tx - const: mediatek,mt8183-mipi-tx - const: mediatek,mt2701-mipi-tx @@ -83,7 +87,7 @@ examples: clocks = <&clk26m>; clock-output-names = "mipi_tx0_pll"; drive-strength-microamp = <4000>; - nvmem-cells= <&mipi_tx_calibration>; + nvmem-cells = <&mipi_tx_calibration>; nvmem-cell-names = "calibration-data"; #clock-cells = <0>; #phy-cells = <0>; diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml index b35c4d256e40..99eac888ae03 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/phy/mediatek,mt7621-pci-phy.yaml# diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index 230a17f24966..2bb91542e984 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -64,7 +64,7 @@ description: | properties: $nodename: - pattern: "^t-phy@[0-9a-f]+$" + pattern: "^t-phy(@[0-9a-f]+)?$" compatible: oneOf: diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml index 786cfd71cb7e..3c28ec50f097 100644 --- a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml @@ -32,15 +32,6 @@ properties: clock-names: const: phy_ref - assigned-clocks: - maxItems: 1 - - assigned-clock-parents: - maxItems: 1 - - assigned-clock-rates: - maxItems: 1 - "#phy-cells": const: 0 diff --git a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt deleted file mode 100644 index 70c813b0755f..000000000000 --- a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt +++ /dev/null @@ -1,33 +0,0 @@ -* Freescale MXS USB Phy Device - -Required properties: -- compatible: should contain: - * "fsl,imx23-usbphy" for imx23 and imx28 - * "fsl,imx6q-usbphy" for imx6dq and imx6dl - * "fsl,imx6sl-usbphy" for imx6sl - * "fsl,vf610-usbphy" for Vybrid vf610 - * "fsl,imx6sx-usbphy" for imx6sx - * "fsl,imx7ulp-usbphy" for imx7ulp - * "fsl,imx8dxl-usbphy" for imx8dxl - "fsl,imx23-usbphy" is still a fallback for other strings -- reg: Should contain registers location and length -- interrupts: Should contain phy interrupt -- fsl,anatop: phandle for anatop register, it is only for imx6 SoC series - -Optional properties: -- fsl,tx-cal-45-dn-ohms: Integer [35-54]. Resistance (in ohms) of switchable - high-speed trimming resistor connected in parallel with the 45 ohm resistor - that terminates the DN output signal. Default: 45 -- fsl,tx-cal-45-dp-ohms: Integer [35-54]. Resistance (in ohms) of switchable - high-speed trimming resistor connected in parallel with the 45 ohm resistor - that terminates the DP output signal. Default: 45 -- fsl,tx-d-cal: Integer [79-119]. Current trimming value (as a percentage) of - the 17.78mA TX reference current. Default: 100 - -Example: -usbphy1: usb-phy@20c9000 { - compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy"; - reg = <0x020c9000 0x1000>; - interrupts = <0 44 0x04>; - fsl,anatop = <&anatop>; -}; diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml index d16bd6e47f90..e9237c58ce45 100644 --- a/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/phy/nvidia,tegra210-xusb-padctl.yaml# diff --git a/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt b/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt index 0d70c8341095..104953e849e7 100644 --- a/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt +++ b/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt @@ -14,7 +14,7 @@ Required properties: - #size-cells: Must be 0. The INNO USB2 PHY device should be a child node of peripheral controller that -contains the PHY configuration register, and each device suppports up to 2 PHY +contains the PHY configuration register, and each device supports up to 2 PHY ports which are represented as child nodes of INNO USB2 PHY device. Required properties for PHY port node: diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml index 9ae514fa7533..d3cd7997879f 100644 --- a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml @@ -31,8 +31,14 @@ properties: - const: pipe resets: + minItems: 1 + maxItems: 2 + + reset-names: + minItems: 1 items: - - description: exclusive PHY reset line + - const: phy + - const: apb rockchip,enable-ssc: type: boolean @@ -78,6 +84,32 @@ required: - rockchip,pipe-phy-grf - "#phy-cells" +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,rk3568-naneng-combphy + then: + properties: + resets: + maxItems: 1 + reset-names: + maxItems: 1 + - if: + properties: + compatible: + contains: + const: rockchip,rk3588-naneng-combphy + then: + properties: + resets: + minItems: 2 + reset-names: + minItems: 2 + required: + - reset-names + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt index afbc7e24a3de..c7970c07ee32 100644 --- a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt +++ b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt @@ -8,7 +8,7 @@ Required properties: - clocks: Must contain an entry for each entry in clock-names. See ../clock/clock-bindings.txt for details. - clock-names: Must include "usb_phy". - - img,cr-top: Must constain a phandle to the CR_TOP syscon node. + - img,cr-top: Must contain a phandle to the CR_TOP syscon node. - img,refclk: Indicates the reference clock source for the USB PHY. See <dt-bindings/phy/phy-pistachio-usb.h> for a list of valid values. diff --git a/Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt b/Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt index 660a13ca90b3..da94426aa694 100644 --- a/Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt +++ b/Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt @@ -4,7 +4,7 @@ Required properties: - compatible: "marvell,pxa1928-usb-phy" or "marvell,pxa1928-hsic-phy" - reg: base address and length of the registers - clocks - A single clock. From common clock binding. -- #phys-cells: should be 0. From commmon phy binding. +- #phys-cells: should be 0. From common phy binding. - resets: reference to the reset controller Example: diff --git a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml index c4f8e6ffa5c3..6566353f1a02 100644 --- a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml @@ -43,6 +43,9 @@ properties: "#phy-cells": const: 0 + power-domains: + maxItems: 1 + vdda-phy-supply: true vdda-pll-supply: true diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq5332-usb-hsphy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq5332-usb-hsphy.yaml new file mode 100644 index 000000000000..2671a048c926 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,ipq5332-usb-hsphy.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/qcom,ipq5332-usb-hsphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: M31 USB PHY + +maintainers: + - Sricharan Ramabadhran <quic_srichara@quicinc.com> + - Varadarajan Narayanan <quic_varada@quicinc.com> + +description: + USB M31 PHY (https://www.m31tech.com) found in Qualcomm + IPQ5018, IPQ5332 SoCs. + +properties: + compatible: + items: + - const: qcom,ipq5332-usb-hsphy + + "#phy-cells": + const: 0 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: cfg_ahb + + resets: + maxItems: 1 + + vdd-supply: + description: + Phandle to 5V regulator supply to PHY digital circuit. + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,ipq5332-gcc.h> + usb-phy@7b000 { + compatible = "qcom,ipq5332-usb-hsphy"; + reg = <0x0007b000 0x12c>; + + clocks = <&gcc GCC_USB0_PHY_CFG_AHB_CLK>; + clock-names = "cfg_ahb"; + + #phy-cells = <0>; + + resets = <&gcc GCC_QUSB2_0_PHY_BCR>; + + vdd-supply = <®ulator_fixed_5p0>; + }; 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 62045dcfb20c..5073007267ad 100644 --- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml @@ -13,287 +13,79 @@ description: QMP PHY controller supports physical layer functionality for a number of controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB. - Note that these bindings are for SoCs up to SC8180X. For newer SoCs, see - qcom,sc8280xp-qmp-pcie-phy.yaml. - properties: compatible: enum: - qcom,ipq6018-qmp-pcie-phy - qcom,ipq8074-qmp-gen3-pcie-phy - qcom,ipq8074-qmp-pcie-phy - - qcom,msm8998-qmp-pcie-phy - - qcom,sc8180x-qmp-pcie-phy - - qcom,sdm845-qhp-pcie-phy - - qcom,sdm845-qmp-pcie-phy - - qcom,sdx55-qmp-pcie-phy - - qcom,sm8250-qmp-gen3x1-pcie-phy - - qcom,sm8250-qmp-gen3x2-pcie-phy - - qcom,sm8250-qmp-modem-pcie-phy - - qcom,sm8450-qmp-gen3x1-pcie-phy - - qcom,sm8450-qmp-gen4x2-pcie-phy reg: items: - description: serdes - "#address-cells": - enum: [ 1, 2 ] - - "#size-cells": - enum: [ 1, 2 ] - - ranges: true - clocks: - minItems: 2 - maxItems: 4 + maxItems: 3 clock-names: - minItems: 2 - maxItems: 4 + items: + - const: aux + - const: cfg_ahb + - const: pipe resets: - minItems: 1 maxItems: 2 reset-names: - minItems: 1 - maxItems: 2 - - vdda-phy-supply: true - - vdda-pll-supply: true - - vddp-ref-clk-supply: true - -patternProperties: - "^phy@[0-9a-f]+$": - type: object - description: single PHY-provider child node - properties: - reg: - minItems: 3 - maxItems: 6 - - clocks: - items: - - description: PIPE clock - - clock-names: - deprecated: true - items: - - const: pipe0 - - "#clock-cells": - const: 0 - - clock-output-names: - maxItems: 1 + items: + - const: phy + - const: common - "#phy-cells": - const: 0 + "#clock-cells": + const: 0 - required: - - reg - - clocks - - "#clock-cells" - - clock-output-names - - "#phy-cells" + clock-output-names: + maxItems: 1 - additionalProperties: false + "#phy-cells": + const: 0 required: - compatible - reg - - "#address-cells" - - "#size-cells" - - ranges - clocks - clock-names - resets - reset-names + - "#clock-cells" + - clock-output-names + - "#phy-cells" additionalProperties: false -allOf: - - if: - properties: - compatible: - contains: - enum: - - qcom,msm8998-qmp-pcie-phy - then: - properties: - clocks: - maxItems: 3 - clock-names: - items: - - const: aux - - const: cfg_ahb - - const: ref - resets: - maxItems: 2 - reset-names: - items: - - const: phy - - const: common - required: - - vdda-phy-supply - - vdda-pll-supply - - - if: - properties: - compatible: - contains: - enum: - - qcom,ipq6018-qmp-pcie-phy - - qcom,ipq8074-qmp-gen3-pcie-phy - - qcom,ipq8074-qmp-pcie-phy - then: - properties: - clocks: - maxItems: 2 - clock-names: - items: - - const: aux - - const: cfg_ahb - resets: - maxItems: 2 - reset-names: - items: - - const: phy - - const: common - - - if: - properties: - compatible: - contains: - enum: - - qcom,sc8180x-qmp-pcie-phy - - qcom,sdm845-qhp-pcie-phy - - qcom,sdm845-qmp-pcie-phy - - qcom,sdx55-qmp-pcie-phy - - qcom,sm8250-qmp-gen3x1-pcie-phy - - qcom,sm8250-qmp-gen3x2-pcie-phy - - qcom,sm8250-qmp-modem-pcie-phy - - qcom,sm8450-qmp-gen3x1-pcie-phy - - qcom,sm8450-qmp-gen4x2-pcie-phy - then: - properties: - clocks: - maxItems: 4 - clock-names: - items: - - const: aux - - const: cfg_ahb - - const: ref - - const: refgen - resets: - maxItems: 1 - reset-names: - items: - - const: phy - required: - - vdda-phy-supply - - vdda-pll-supply - - - if: - properties: - compatible: - contains: - enum: - - qcom,sm8250-qmp-gen3x2-pcie-phy - - qcom,sm8250-qmp-modem-pcie-phy - - qcom,sm8450-qmp-gen4x2-pcie-phy - then: - patternProperties: - "^phy@[0-9a-f]+$": - properties: - reg: - items: - - description: TX lane 1 - - description: RX lane 1 - - description: PCS - - description: TX lane 2 - - description: RX lane 2 - - description: PCS_MISC - - - if: - properties: - compatible: - contains: - enum: - - qcom,sc8180x-qmp-pcie-phy - - qcom,sdm845-qmp-pcie-phy - - qcom,sdx55-qmp-pcie-phy - - qcom,sm8250-qmp-gen3x1-pcie-phy - - qcom,sm8450-qmp-gen3x1-pcie-phy - then: - patternProperties: - "^phy@[0-9a-f]+$": - properties: - reg: - items: - - description: TX - - description: RX - - description: PCS - - description: PCS_MISC - - - if: - properties: - compatible: - contains: - enum: - - qcom,ipq6018-qmp-pcie-phy - - qcom,ipq8074-qmp-pcie-phy - - qcom,msm8998-qmp-pcie-phy - - qcom,sdm845-qhp-pcie-phy - then: - patternProperties: - "^phy@[0-9a-f]+$": - properties: - reg: - items: - - description: TX - - description: RX - - description: PCS - examples: - | - #include <dt-bindings/clock/qcom,gcc-sm8250.h> - phy-wrapper@1c0e000 { - compatible = "qcom,sm8250-qmp-gen3x2-pcie-phy"; - reg = <0x01c0e000 0x1c0>; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0x0 0x01c0e000 0x1000>; - - clocks = <&gcc GCC_PCIE_PHY_AUX_CLK>, - <&gcc GCC_PCIE_1_CFG_AHB_CLK>, - <&gcc GCC_PCIE_WIGIG_CLKREF_EN>, - <&gcc GCC_PCIE1_PHY_REFGEN_CLK>; - clock-names = "aux", "cfg_ahb", "ref", "refgen"; - - resets = <&gcc GCC_PCIE_1_PHY_BCR>; - reset-names = "phy"; + #include <dt-bindings/clock/qcom,gcc-ipq6018.h> + #include <dt-bindings/reset/qcom,gcc-ipq6018.h> - vdda-phy-supply = <&vreg_l10c_0p88>; - vdda-pll-supply = <&vreg_l6b_1p2>; + phy@84000 { + compatible = "qcom,ipq6018-qmp-pcie-phy"; + reg = <0x0 0x00084000 0x0 0x1000>; - phy@200 { - reg = <0x200 0x170>, - <0x400 0x200>, - <0xa00 0x1f0>, - <0x600 0x170>, - <0x800 0x200>, - <0xe00 0xf4>; + clocks = <&gcc GCC_PCIE0_AUX_CLK>, + <&gcc GCC_PCIE0_AHB_CLK>, + <&gcc GCC_PCIE0_PIPE_CLK>; + clock-names = "aux", + "cfg_ahb", + "pipe"; - clocks = <&gcc GCC_PCIE_1_PIPE_CLK>; + clock-output-names = "gcc_pcie0_pipe_clk_src"; + #clock-cells = <0>; - #clock-cells = <0>; - clock-output-names = "pcie_1_pipe_clk"; + #phy-cells = <0>; - #phy-cells = <0>; - }; + resets = <&gcc GCC_PCIE0_PHY_BCR>, + <&gcc GCC_PCIE0PHY_PHY_BCR>; + reset-names = "phy", + "common"; }; diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml deleted file mode 100644 index 80a5348dbfde..000000000000 --- a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml +++ /dev/null @@ -1,244 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/phy/qcom,msm8996-qmp-ufs-phy.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Qualcomm QMP PHY controller (UFS, MSM8996) - -maintainers: - - Vinod Koul <vkoul@kernel.org> - -description: - QMP PHY controller supports physical layer functionality for a number of - controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB. - - Note that these bindings are for SoCs up to SC8180X. For newer SoCs, see - qcom,sc8280xp-qmp-ufs-phy.yaml. - -properties: - compatible: - enum: - - qcom,msm8996-qmp-ufs-phy - - qcom,msm8998-qmp-ufs-phy - - qcom,sc8180x-qmp-ufs-phy - - qcom,sdm845-qmp-ufs-phy - - qcom,sm6115-qmp-ufs-phy - - qcom,sm6350-qmp-ufs-phy - - qcom,sm8150-qmp-ufs-phy - - qcom,sm8250-qmp-ufs-phy - - qcom,sm8350-qmp-ufs-phy - - qcom,sm8450-qmp-ufs-phy - - reg: - items: - - description: serdes - - "#address-cells": - enum: [ 1, 2 ] - - "#size-cells": - enum: [ 1, 2 ] - - ranges: true - - clocks: - minItems: 1 - maxItems: 3 - - clock-names: - minItems: 1 - maxItems: 3 - - power-domains: - maxItems: 1 - - resets: - maxItems: 1 - - reset-names: - items: - - const: ufsphy - - vdda-phy-supply: true - - vdda-pll-supply: true - - vddp-ref-clk-supply: true - -patternProperties: - "^phy@[0-9a-f]+$": - type: object - description: single PHY-provider child node - properties: - reg: - minItems: 3 - maxItems: 6 - - "#clock-cells": - const: 1 - - "#phy-cells": - const: 0 - - required: - - reg - - "#phy-cells" - - additionalProperties: false - -required: - - compatible - - reg - - "#address-cells" - - "#size-cells" - - ranges - - clocks - - clock-names - - resets - - reset-names - - vdda-phy-supply - - vdda-pll-supply - -additionalProperties: false - -allOf: - - if: - properties: - compatible: - contains: - enum: - - qcom,msm8996-qmp-ufs-phy - then: - properties: - clocks: - maxItems: 1 - clock-names: - items: - - const: ref - - - if: - properties: - compatible: - contains: - enum: - - qcom,msm8998-qmp-ufs-phy - - qcom,sc8180x-qmp-ufs-phy - - qcom,sdm845-qmp-ufs-phy - - qcom,sm6115-qmp-ufs-phy - - qcom,sm6350-qmp-ufs-phy - - qcom,sm8150-qmp-ufs-phy - - qcom,sm8250-qmp-ufs-phy - then: - properties: - clocks: - maxItems: 2 - clock-names: - items: - - const: ref - - const: ref_aux - - - if: - properties: - compatible: - contains: - enum: - - qcom,sm8450-qmp-ufs-phy - then: - properties: - clocks: - maxItems: 3 - clock-names: - items: - - const: ref - - const: ref_aux - - const: qref - - - if: - properties: - compatible: - contains: - enum: - - qcom,msm8998-qmp-ufs-phy - - qcom,sdm845-qmp-ufs-phy - - qcom,sm6350-qmp-ufs-phy - - qcom,sm8150-qmp-ufs-phy - - qcom,sm8250-qmp-ufs-phy - - qcom,sm8350-qmp-ufs-phy - - qcom,sm8450-qmp-ufs-phy - then: - patternProperties: - "^phy@[0-9a-f]+$": - properties: - reg: - items: - - description: TX lane 1 - - description: RX lane 1 - - description: PCS - - description: TX lane 2 - - description: RX lane 2 - - - if: - properties: - compatible: - contains: - enum: - - qcom,sc8180x-qmp-ufs-phy - then: - patternProperties: - "^phy@[0-9a-f]+$": - properties: - reg: - items: - - description: TX - - description: RX - - description: PCS - - description: PCS_MISC - - - if: - properties: - compatible: - contains: - enum: - - qcom,msm8996-qmp-ufs-phy - - qcom,sm6115-qmp-ufs-phy - then: - patternProperties: - "^phy@[0-9a-f]+$": - properties: - reg: - items: - - description: TX - - description: RX - - description: PCS - -examples: - - | - #include <dt-bindings/clock/qcom,gcc-sm8250.h> - #include <dt-bindings/clock/qcom,rpmh.h> - - phy-wrapper@1d87000 { - compatible = "qcom,sm8250-qmp-ufs-phy"; - reg = <0x01d87000 0x1c0>; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0x0 0x01d87000 0x1000>; - - clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_UFS_PHY_PHY_AUX_CLK>; - clock-names = "ref", "ref_aux"; - - resets = <&ufs_mem_hc 0>; - reset-names = "ufsphy"; - - vdda-phy-supply = <&vreg_l6b>; - vdda-pll-supply = <&vreg_l3b>; - - phy@400 { - reg = <0x400 0x108>, - <0x600 0x1e0>, - <0xc00 0x1dc>, - <0x800 0x108>, - <0xa00 0x1e0>; - #phy-cells = <0>; - }; - }; diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml index e81a38281f8c..827109d37041 100644 --- a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml @@ -23,27 +23,16 @@ properties: - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-usb3-phy - qcom,msm8998-qmp-usb3-phy - - qcom,qcm2290-qmp-usb3-phy - - qcom,sc7180-qmp-usb3-phy - - qcom,sc8180x-qmp-usb3-phy - - qcom,sdm845-qmp-usb3-phy - qcom,sdm845-qmp-usb3-uni-phy - qcom,sdx55-qmp-usb3-uni-phy - qcom,sdx65-qmp-usb3-uni-phy - - qcom,sm6115-qmp-usb3-phy - - qcom,sm8150-qmp-usb3-phy - qcom,sm8150-qmp-usb3-uni-phy - - qcom,sm8250-qmp-usb3-phy - qcom,sm8250-qmp-usb3-uni-phy - - qcom,sm8350-qmp-usb3-phy - qcom,sm8350-qmp-usb3-uni-phy - - qcom,sm8450-qmp-usb3-phy reg: - minItems: 1 items: - description: serdes - - description: DP_COM "#address-cells": enum: [ 1, 2 ] @@ -133,28 +122,6 @@ allOf: compatible: contains: enum: - - qcom,sc7180-qmp-usb3-phy - then: - properties: - clocks: - maxItems: 4 - clock-names: - items: - - const: aux - - const: cfg_ahb - - const: ref - - const: com_aux - resets: - maxItems: 1 - reset-names: - items: - - const: phy - - - if: - properties: - compatible: - contains: - enum: - qcom,sdm845-qmp-usb3-uni-phy then: properties: @@ -204,7 +171,6 @@ allOf: compatible: contains: enum: - - qcom,sm8150-qmp-usb3-phy - qcom,sm8150-qmp-usb3-uni-phy - qcom,sm8250-qmp-usb3-uni-phy - qcom,sm8350-qmp-usb3-uni-phy @@ -230,74 +196,6 @@ allOf: compatible: contains: enum: - - qcom,sm8250-qmp-usb3-phy - - qcom,sm8350-qmp-usb3-phy - then: - properties: - clocks: - maxItems: 3 - clock-names: - items: - - const: aux - - const: ref_clk_src - - const: com_aux - resets: - maxItems: 2 - reset-names: - items: - - const: phy - - const: common - - - if: - properties: - compatible: - contains: - enum: - - qcom,qcm2290-qmp-usb3-phy - - qcom,sm6115-qmp-usb3-phy - then: - properties: - clocks: - maxItems: 3 - clock-names: - items: - - const: cfg_ahb - - const: ref - - const: com_aux - resets: - maxItems: 2 - reset-names: - items: - - const: phy_phy - - const: phy - - - if: - properties: - compatible: - contains: - enum: - - qcom,sdm845-qmp-usb3-phy - - qcom,sm8150-qmp-usb3-phy - - qcom,sm8350-qmp-usb3-phy - - qcom,sm8450-qmp-usb3-phy - then: - patternProperties: - "^phy@[0-9a-f]+$": - properties: - reg: - items: - - description: TX lane 1 - - description: RX lane 1 - - description: PCS - - description: TX lane 2 - - description: RX lane 2 - - description: PCS_MISC - - - if: - properties: - compatible: - contains: - enum: - qcom,msm8998-qmp-usb3-phy then: patternProperties: @@ -318,14 +216,9 @@ allOf: enum: - qcom,ipq6018-qmp-usb3-phy - qcom,ipq8074-qmp-usb3-phy - - qcom,qcm2290-qmp-usb3-phy - - qcom,sc7180-qmp-usb3-phy - - qcom,sc8180x-qmp-usb3-phy - qcom,sdx55-qmp-usb3-uni-phy - qcom,sdx65-qmp-usb3-uni-phy - - qcom,sm6115-qmp-usb3-phy - qcom,sm8150-qmp-usb3-uni-phy - - qcom,sm8250-qmp-usb3-phy then: patternProperties: "^phy@[0-9a-f]+$": diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-pcie-phy.yaml new file mode 100644 index 000000000000..d05eef0e1ccd --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-pcie-phy.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/qcom,msm8998-qmp-pcie-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm QMP PHY controller (PCIe, MSM8998) + +maintainers: + - Vinod Koul <vkoul@kernel.org> + +description: + The QMP PHY controller supports physical layer functionality for a number of + controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB. + +properties: + compatible: + const: qcom,msm8998-qmp-pcie-phy + + reg: + items: + - description: serdes + + clocks: + maxItems: 4 + + clock-names: + items: + - const: aux + - const: cfg_ahb + - const: ref + - const: pipe + + resets: + maxItems: 2 + + reset-names: + items: + - const: phy + - const: common + + vdda-phy-supply: true + + vdda-pll-supply: true + + "#clock-cells": + const: 0 + + clock-output-names: + maxItems: 1 + + "#phy-cells": + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - vdda-phy-supply + - vdda-pll-supply + - "#clock-cells" + - clock-output-names + - "#phy-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-msm8998.h> + + phy@1c18000 { + compatible = "qcom,msm8998-qmp-pcie-phy"; + reg = <0x01c06000 0x1000>; + + clocks = <&gcc GCC_PCIE_PHY_AUX_CLK>, + <&gcc GCC_PCIE_0_CFG_AHB_CLK>, + <&gcc GCC_PCIE_CLKREF_CLK>, + <&gcc GCC_PCIE_0_PIPE_CLK>; + clock-names = "aux", + "cfg_ahb", + "ref", + "pipe"; + + clock-output-names = "pcie_0_pipe_clk_src"; + #clock-cells = <0>; + + #phy-cells = <0>; + + resets = <&gcc GCC_PCIE_0_PHY_BCR>, <&gcc GCC_PCIE_PHY_BCR>; + reset-names = "phy", "common"; + + vdda-phy-supply = <&vreg_l1a_0p875>; + vdda-pll-supply = <&vreg_l2a_1p2>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index 543c1a2811a5..95eecbaef05c 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -18,13 +18,14 @@ properties: oneOf: - items: - enum: + - qcom,ipq6018-qusb2-phy - qcom,ipq8074-qusb2-phy + - qcom,ipq9574-qusb2-phy - qcom,msm8953-qusb2-phy - qcom,msm8996-qusb2-phy - qcom,msm8998-qusb2-phy - qcom,qcm2290-qusb2-phy - qcom,sdm660-qusb2-phy - - qcom,ipq6018-qusb2-phy - qcom,sm4250-qusb2-phy - qcom,sm6115-qusb2-phy - items: diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml new file mode 100644 index 000000000000..b9107759b2a5 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SerDes/SGMII ethernet PHY controller + +maintainers: + - Bartosz Golaszewski <bartosz.golaszewski@linaro.org> + +description: + The SerDes PHY sits between the MAC and the external PHY and provides + separate Rx Tx lines. + +properties: + compatible: + const: qcom,sa8775p-dwmac-sgmii-phy + + reg: + items: + - description: serdes + + clocks: + maxItems: 1 + + clock-names: + const: sgmi_ref + + phy-supply: + description: + Phandle to a regulator that provides power to the PHY. + + "#phy-cells": + const: 0 + +required: + - compatible + - reg + - "#phy-cells" + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sa8775p-gcc.h> + serdes_phy: phy@8901000 { + compatible = "qcom,sa8775p-dwmac-sgmii-phy"; + reg = <0x08901000 0xe10>; + clocks = <&gcc GCC_SGMI_CLKREF_EN>; + clock-names = "sgmi_ref"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml deleted file mode 100644 index 0ef2c9b9d466..000000000000 --- a/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml +++ /dev/null @@ -1,276 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Qualcomm QMP USB3 DP PHY controller (SC7180) - -description: - The QMP PHY controller supports physical layer functionality for a number of - controllers on Qualcomm chipsets, such as, PCIe, UFS and USB. - - Note that these bindings are for SoCs up to SC8180X. For newer SoCs, see - qcom,sc8280xp-qmp-usb43dp-phy.yaml. - -maintainers: - - Wesley Cheng <quic_wcheng@quicinc.com> - -properties: - compatible: - oneOf: - - enum: - - qcom,sc7180-qmp-usb3-dp-phy - - qcom,sc8180x-qmp-usb3-dp-phy - - qcom,sdm845-qmp-usb3-dp-phy - - qcom,sm8250-qmp-usb3-dp-phy - - items: - - enum: - - qcom,sc7280-qmp-usb3-dp-phy - - const: qcom,sm8250-qmp-usb3-dp-phy - - reg: - items: - - description: Address and length of PHY's USB serdes block. - - description: Address and length of the DP_COM control block. - - description: Address and length of PHY's DP serdes block. - - reg-names: - items: - - const: usb - - const: dp_com - - const: dp - - "#address-cells": - enum: [ 1, 2 ] - - "#size-cells": - enum: [ 1, 2 ] - - ranges: true - - clocks: - minItems: 3 - maxItems: 4 - - clock-names: - minItems: 3 - maxItems: 4 - - power-domains: - maxItems: 1 - - resets: - items: - - description: reset of phy block. - - description: phy common block reset. - - reset-names: - items: - - const: phy - - const: common - - 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. - - vddp-ref-clk-supply: - description: - Phandle to a regulator supply to any specific refclk pll block. - -# Required nodes: -patternProperties: - "^usb3-phy@[0-9a-f]+$": - type: object - additionalProperties: false - description: - The USB3 PHY. - - properties: - reg: - items: - - description: Address and length of TX. - - description: Address and length of RX. - - description: Address and length of PCS. - - description: Address and length of TX2. - - description: Address and length of RX2. - - description: Address and length of pcs_misc. - - clocks: - items: - - description: pipe clock - - clock-names: - deprecated: true - items: - - const: pipe0 - - clock-output-names: - items: - - const: usb3_phy_pipe_clk_src - - '#clock-cells': - const: 0 - - '#phy-cells': - const: 0 - - required: - - reg - - clocks - - '#clock-cells' - - '#phy-cells' - - "^dp-phy@[0-9a-f]+$": - type: object - additionalProperties: false - description: - The DP PHY. - - properties: - reg: - items: - - description: Address and length of TX. - - description: Address and length of RX. - - description: Address and length of PCS. - - description: Address and length of TX2. - - description: Address and length of RX2. - - '#clock-cells': - const: 1 - - '#phy-cells': - const: 0 - - required: - - reg - - '#clock-cells' - - '#phy-cells' - -required: - - compatible - - reg - - "#address-cells" - - "#size-cells" - - ranges - - clocks - - clock-names - - resets - - reset-names - - vdda-phy-supply - - vdda-pll-supply - -allOf: - - if: - properties: - compatible: - enum: - - qcom,sc7180-qmp-usb3-dp-phy - - qcom,sdm845-qmp-usb3-dp-phy - then: - properties: - clocks: - items: - - description: Phy aux clock - - description: Phy config clock - - description: 19.2 MHz ref clk - - description: Phy common block aux clock - clock-names: - items: - - const: aux - - const: cfg_ahb - - const: ref - - const: com_aux - - - if: - properties: - compatible: - enum: - - qcom,sc8180x-qmp-usb3-dp-phy - then: - properties: - clocks: - items: - - description: Phy aux clock - - description: 19.2 MHz ref clk - - description: Phy common block aux clock - clock-names: - items: - - const: aux - - const: ref - - const: com_aux - - - if: - properties: - compatible: - enum: - - qcom,sm8250-qmp-usb3-dp-phy - then: - properties: - clocks: - items: - - description: Phy aux clock - - description: Board XO source - - description: Phy common block aux clock - clock-names: - items: - - const: aux - - const: ref_clk_src - - const: com_aux - -additionalProperties: false - -examples: - - | - #include <dt-bindings/clock/qcom,gcc-sdm845.h> - usb_1_qmpphy: phy-wrapper@88e9000 { - compatible = "qcom,sdm845-qmp-usb3-dp-phy"; - reg = <0x088e9000 0x18c>, - <0x088e8000 0x10>, - <0x088ea000 0x40>; - reg-names = "usb", "dp_com", "dp"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0x0 0x088e9000 0x2000>; - - clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>, - <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>, - <&gcc GCC_USB3_PRIM_CLKREF_CLK>, - <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>; - clock-names = "aux", "cfg_ahb", "ref", "com_aux"; - - resets = <&gcc GCC_USB3_PHY_PRIM_BCR>, - <&gcc GCC_USB3_DP_PHY_PRIM_BCR>; - reset-names = "phy", "common"; - - vdda-phy-supply = <&vdda_usb2_ss_1p2>; - vdda-pll-supply = <&vdda_usb2_ss_core>; - - usb3-phy@200 { - reg = <0x200 0x128>, - <0x400 0x200>, - <0xc00 0x218>, - <0x600 0x128>, - <0x800 0x200>, - <0xa00 0x100>; - #clock-cells = <0>; - #phy-cells = <0>; - clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>; - clock-output-names = "usb3_phy_pipe_clk_src"; - }; - - dp-phy@88ea200 { - reg = <0xa200 0x200>, - <0xa400 0x200>, - <0xaa00 0x200>, - <0xa600 0x200>, - <0xa800 0x200>; - #clock-cells = <1>; - #phy-cells = <0>; - }; - }; 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 a0407fc79563..2c3d6553a7ba 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml @@ -16,11 +16,24 @@ description: properties: compatible: enum: + - qcom,sa8775p-qmp-gen4x2-pcie-phy + - qcom,sa8775p-qmp-gen4x4-pcie-phy + - qcom,sc8180x-qmp-pcie-phy - qcom,sc8280xp-qmp-gen3x1-pcie-phy - qcom,sc8280xp-qmp-gen3x2-pcie-phy - qcom,sc8280xp-qmp-gen3x4-pcie-phy + - qcom,sdm845-qhp-pcie-phy + - qcom,sdm845-qmp-pcie-phy + - qcom,sdx55-qmp-pcie-phy - qcom,sdx65-qmp-gen4x2-pcie-phy + - qcom,sm8150-qmp-gen3x1-pcie-phy + - qcom,sm8150-qmp-gen3x2-pcie-phy + - qcom,sm8250-qmp-gen3x1-pcie-phy + - qcom,sm8250-qmp-gen3x2-pcie-phy + - qcom,sm8250-qmp-modem-pcie-phy - qcom,sm8350-qmp-gen3x1-pcie-phy + - qcom,sm8450-qmp-gen3x1-pcie-phy + - qcom,sm8450-qmp-gen4x2-pcie-phy - qcom,sm8550-qmp-gen3x2-pcie-phy - qcom,sm8550-qmp-gen4x2-pcie-phy @@ -30,7 +43,7 @@ properties: clocks: minItems: 5 - maxItems: 6 + maxItems: 7 clock-names: minItems: 5 @@ -38,9 +51,10 @@ properties: - const: aux - const: cfg_ahb - const: ref - - const: rchng + - enum: [rchng, refgen] - const: pipe - const: pipediv2 + - const: phy_aux power-domains: maxItems: 1 @@ -84,7 +98,6 @@ required: - reg - clocks - clock-names - - power-domains - resets - reset-names - vdda-phy-supply @@ -120,7 +133,18 @@ allOf: compatible: contains: enum: + - qcom,sc8180x-qmp-pcie-phy + - qcom,sdm845-qhp-pcie-phy + - qcom,sdm845-qmp-pcie-phy + - qcom,sdx55-qmp-pcie-phy + - qcom,sm8150-qmp-gen3x1-pcie-phy + - qcom,sm8150-qmp-gen3x2-pcie-phy + - qcom,sm8250-qmp-gen3x1-pcie-phy + - qcom,sm8250-qmp-gen3x2-pcie-phy + - qcom,sm8250-qmp-modem-pcie-phy - qcom,sm8350-qmp-gen3x1-pcie-phy + - qcom,sm8450-qmp-gen3x1-pcie-phy + - qcom,sm8450-qmp-gen3x2-pcie-phy - qcom,sm8550-qmp-gen3x2-pcie-phy - qcom,sm8550-qmp-gen4x2-pcie-phy then: @@ -129,7 +153,16 @@ allOf: maxItems: 5 clock-names: maxItems: 5 - else: + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc8280xp-qmp-gen3x1-pcie-phy + - qcom,sc8280xp-qmp-gen3x2-pcie-phy + - qcom,sc8280xp-qmp-gen3x4-pcie-phy + then: properties: clocks: minItems: 6 @@ -141,6 +174,20 @@ allOf: compatible: contains: enum: + - qcom,sa8775p-qmp-gen4x2-pcie-phy + - qcom,sa8775p-qmp-gen4x4-pcie-phy + then: + properties: + clocks: + minItems: 7 + clock-names: + minItems: 7 + + - if: + properties: + compatible: + contains: + enum: - qcom,sm8550-qmp-gen4x2-pcie-phy then: properties: diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml index 94c0fab065a8..d981d77e82e4 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml @@ -16,21 +16,31 @@ description: properties: compatible: enum: + - qcom,msm8996-qmp-ufs-phy + - qcom,msm8998-qmp-ufs-phy - qcom,sa8775p-qmp-ufs-phy + - qcom,sc8180x-qmp-ufs-phy - qcom,sc8280xp-qmp-ufs-phy + - qcom,sdm845-qmp-ufs-phy + - qcom,sm6115-qmp-ufs-phy - qcom,sm6125-qmp-ufs-phy + - qcom,sm6350-qmp-ufs-phy - qcom,sm7150-qmp-ufs-phy + - qcom,sm8150-qmp-ufs-phy + - qcom,sm8250-qmp-ufs-phy + - qcom,sm8350-qmp-ufs-phy + - qcom,sm8450-qmp-ufs-phy - qcom,sm8550-qmp-ufs-phy reg: maxItems: 1 clocks: - minItems: 2 + minItems: 1 maxItems: 3 clock-names: - minItems: 2 + minItems: 1 items: - const: ref - const: ref_aux @@ -75,19 +85,51 @@ allOf: contains: enum: - qcom,sa8775p-qmp-ufs-phy + - qcom,sm8450-qmp-ufs-phy then: properties: clocks: - maxItems: 3 + minItems: 3 clock-names: - maxItems: 3 - else: + minItems: 3 + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8998-qmp-ufs-phy + - qcom,sc8180x-qmp-ufs-phy + - qcom,sc8280xp-qmp-ufs-phy + - qcom,sdm845-qmp-ufs-phy + - qcom,sm6115-qmp-ufs-phy + - qcom,sm6125-qmp-ufs-phy + - qcom,sm6350-qmp-ufs-phy + - qcom,sm7150-qmp-ufs-phy + - qcom,sm8150-qmp-ufs-phy + - qcom,sm8250-qmp-ufs-phy + - qcom,sm8350-qmp-ufs-phy + - qcom,sm8550-qmp-ufs-phy + then: properties: clocks: maxItems: 2 clock-names: maxItems: 2 + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8996-qmp-ufs-phy + then: + properties: + clocks: + maxItems: 1 + clock-names: + maxItems: 1 + additionalProperties: false examples: 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 16fce1038285..f99fbbcd68fb 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,7 +16,11 @@ description: properties: compatible: enum: + - qcom,ipq9574-qmp-usb3-phy + - qcom,qcm2290-qmp-usb3-phy + - qcom,sa8775p-qmp-usb3-uni-phy - qcom,sc8280xp-qmp-usb3-uni-phy + - qcom,sm6115-qmp-usb3-phy reg: maxItems: 1 @@ -25,11 +29,7 @@ properties: maxItems: 4 clock-names: - items: - - const: aux - - const: ref - - const: com_aux - - const: pipe + maxItems: 4 power-domains: maxItems: 1 @@ -60,7 +60,6 @@ required: - reg - clocks - clock-names - - power-domains - resets - reset-names - vdda-phy-supply @@ -69,6 +68,60 @@ required: - clock-output-names - "#phy-cells" +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,ipq9574-qmp-usb3-phy + then: + properties: + clock-names: + items: + - const: aux + - const: ref + - const: cfg_ahb + - const: pipe + + - if: + properties: + compatible: + contains: + enum: + - qcom,qcm2290-qmp-usb3-phy + - qcom,sm6115-qmp-usb3-phy + then: + properties: + clocks: + maxItems: 4 + clock-names: + items: + - const: cfg_ahb + - const: ref + - const: com_aux + - const: pipe + + - if: + properties: + compatible: + contains: + enum: + - qcom,sa8775p-qmp-usb3-uni-phy + - qcom,sc8280xp-qmp-usb3-uni-phy + then: + properties: + clocks: + maxItems: 4 + clock-names: + items: + - const: aux + - const: ref + - const: com_aux + - const: pipe + required: + - power-domains + additionalProperties: false examples: 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 3cd5fc3e8fab..9af203dc8793 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml @@ -16,8 +16,14 @@ description: properties: compatible: enum: + - qcom,sc7180-qmp-usb3-dp-phy + - qcom,sc7280-qmp-usb3-dp-phy + - qcom,sc8180x-qmp-usb3-dp-phy - qcom,sc8280xp-qmp-usb43dp-phy + - qcom,sdm845-qmp-usb3-dp-phy - qcom,sm6350-qmp-usb3-dp-phy + - qcom,sm8150-qmp-usb3-dp-phy + - qcom,sm8250-qmp-usb3-dp-phy - qcom,sm8350-qmp-usb3-dp-phy - qcom,sm8450-qmp-usb3-dp-phy - qcom,sm8550-qmp-usb3-dp-phy @@ -26,14 +32,17 @@ properties: maxItems: 1 clocks: - maxItems: 4 + minItems: 4 + maxItems: 5 clock-names: + minItems: 4 items: - const: aux - const: ref - const: com_aux - const: usb3_pipe + - const: cfg_ahb power-domains: maxItems: 1 @@ -60,12 +69,31 @@ properties: description: See include/dt-bindings/dt-bindings/phy/phy-qcom-qmp.h + orientation-switch: + description: + Flag the PHY as possible handler of USB Type-C orientation switching + type: boolean + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Output endpoint of the PHY + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Incoming endpoint from the USB controller + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: Incoming endpoint from the DisplayPort controller + required: - compatible - reg - clocks - clock-names - - power-domains - resets - reset-names - vdda-phy-supply @@ -73,6 +101,40 @@ required: - "#clock-cells" - "#phy-cells" +allOf: + - if: + properties: + compatible: + enum: + - qcom,sc7180-qmp-usb3-dp-phy + - qcom,sdm845-qmp-usb3-dp-phy + then: + properties: + clocks: + maxItems: 5 + clock-names: + maxItems: 5 + else: + properties: + clocks: + maxItems: 4 + clock-names: + maxItems: 4 + + - if: + properties: + compatible: + enum: + - qcom,sc8280xp-qmp-usb43dp-phy + - qcom,sm6350-qmp-usb3-dp-phy + - qcom,sm8550-qmp-usb3-dp-phy + then: + required: + - power-domains + else: + properties: + power-domains: false + additionalProperties: false examples: @@ -98,6 +160,37 @@ examples: vdda-phy-supply = <&vreg_l9d>; vdda-pll-supply = <&vreg_l4d>; + orientation-switch; + #clock-cells = <1>; #phy-cells = <1>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + endpoint { + remote-endpoint = <&typec_connector_ss>; + }; + }; + + port@1 { + reg = <1>; + + endpoint { + remote-endpoint = <&dwc3_ss_out>; + }; + }; + + port@2 { + reg = <2>; + + endpoint { + remote-endpoint = <&mdss_dp_out>; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml index 083fda530b48..029569d5fcf3 100644 --- a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml @@ -15,7 +15,12 @@ description: properties: compatible: - const: qcom,pm8550b-eusb2-repeater + oneOf: + - items: + - enum: + - qcom,pm7550ba-eusb2-repeater + - const: qcom,pm8550b-eusb2-repeater + - const: qcom,pm8550b-eusb2-repeater reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml index aa97478dd016..f042d6af1594 100644 --- a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml @@ -13,7 +13,9 @@ if: properties: compatible: contains: - const: qcom,usb-hs-phy-apq8064 + enum: + - qcom,usb-hs-phy-apq8064 + - qcom,usb-hs-phy-msm8960 then: properties: resets: @@ -40,6 +42,7 @@ properties: - qcom,usb-hs-phy-apq8064 - qcom,usb-hs-phy-msm8226 - qcom,usb-hs-phy-msm8916 + - qcom,usb-hs-phy-msm8960 - qcom,usb-hs-phy-msm8974 - const: qcom,usb-hs-phy diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml index a26524b7e7b7..0f200e3f97a9 100644 --- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml @@ -20,6 +20,7 @@ properties: - qcom,usb-snps-femto-v2-phy - items: - enum: + - qcom,sa8775p-usb-hs-phy - qcom,sc8280xp-usb-hs-phy - const: qcom,usb-snps-hs-5nm-phy - items: diff --git a/Documentation/devicetree/bindings/phy/realtek,usb2phy.yaml b/Documentation/devicetree/bindings/phy/realtek,usb2phy.yaml new file mode 100644 index 000000000000..9911ada39ee7 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/realtek,usb2phy.yaml @@ -0,0 +1,175 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2023 Realtek Semiconductor Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/realtek,usb2phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek DHC SoCs USB 2.0 PHY + +maintainers: + - Stanley Chang <stanley_chang@realtek.com> + +description: | + Realtek USB 2.0 PHY support the digital home center (DHC) RTD series SoCs. + The USB 2.0 PHY driver is designed to support the XHCI controller. The SoCs + support multiple XHCI controllers. One PHY device node maps to one XHCI + controller. + + RTD1295/RTD1619 SoCs USB + The USB architecture includes three XHCI controllers. + Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on some + controllers. + XHCI controller#0 -- usb2phy -- phy#0 + |- usb3phy -- phy#0 + XHCI controller#1 -- usb2phy -- phy#0 + XHCI controller#2 -- usb2phy -- phy#0 + |- usb3phy -- phy#0 + + RTD1395 SoCs USB + The USB architecture includes two XHCI controllers. + The controller#0 has one USB 2.0 PHY. The controller#1 includes two USB 2.0 + PHY. + XHCI controller#0 -- usb2phy -- phy#0 + XHCI controller#1 -- usb2phy -- phy#0 + |- phy#1 + + RTD1319/RTD1619b SoCs USB + The USB architecture includes three XHCI controllers. + Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#2. + XHCI controller#0 -- usb2phy -- phy#0 + XHCI controller#1 -- usb2phy -- phy#0 + XHCI controller#2 -- usb2phy -- phy#0 + |- usb3phy -- phy#0 + + RTD1319d SoCs USB + The USB architecture includes three XHCI controllers. + Each xhci maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#0. + XHCI controller#0 -- usb2phy -- phy#0 + |- usb3phy -- phy#0 + XHCI controller#1 -- usb2phy -- phy#0 + XHCI controller#2 -- usb2phy -- phy#0 + + RTD1312c/RTD1315e SoCs USB + The USB architecture includes three XHCI controllers. + Each XHCI maps to one USB 2.0 PHY. + XHCI controller#0 -- usb2phy -- phy#0 + XHCI controller#1 -- usb2phy -- phy#0 + XHCI controller#2 -- usb2phy -- phy#0 + +properties: + compatible: + enum: + - realtek,rtd1295-usb2phy + - realtek,rtd1312c-usb2phy + - realtek,rtd1315e-usb2phy + - realtek,rtd1319-usb2phy + - realtek,rtd1319d-usb2phy + - realtek,rtd1395-usb2phy + - realtek,rtd1395-usb2phy-2port + - realtek,rtd1619-usb2phy + - realtek,rtd1619b-usb2phy + + reg: + items: + - description: PHY data registers + - description: PHY control registers + + "#phy-cells": + const: 0 + + nvmem-cells: + maxItems: 2 + description: + Phandles to nvmem cell that contains the trimming data. + If unspecified, default value is used. + + nvmem-cell-names: + items: + - const: usb-dc-cal + - const: usb-dc-dis + description: + The following names, which correspond to each nvmem-cells. + usb-dc-cal is the driving level for each phy specified via efuse. + usb-dc-dis is the disconnection level for each phy specified via efuse. + + realtek,inverse-hstx-sync-clock: + description: + For one of the phys of RTD1619b SoC, the synchronous clock of the + high-speed tx must be inverted. + type: boolean + + realtek,driving-level: + description: + Control the magnitude of High speed Dp/Dm output swing (mV). + For a different board or port, the original magnitude maybe not meet + the specification. In this situation we can adjust the value to meet + the specification. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 8 + minimum: 0 + maximum: 31 + + realtek,driving-level-compensate: + description: + For RTD1315e SoC, the driving level can be adjusted by reading the + efuse table. This property provides drive compensation. + If the magnitude of High speed Dp/Dm output swing still not meet the + specification, then we can set this value to meet the specification. + $ref: /schemas/types.yaml#/definitions/int32 + default: 0 + minimum: -8 + maximum: 8 + + realtek,disconnection-compensate: + description: + This adjusts the disconnection level compensation for the different + boards with different disconnection level. + $ref: /schemas/types.yaml#/definitions/int32 + default: 0 + minimum: -8 + maximum: 8 + +required: + - compatible + - reg + - "#phy-cells" + +allOf: + - if: + not: + properties: + compatible: + contains: + enum: + - realtek,rtd1619b-usb2phy + then: + properties: + realtek,inverse-hstx-sync-clock: false + + - if: + not: + properties: + compatible: + contains: + enum: + - realtek,rtd1315e-usb2phy + then: + properties: + realtek,driving-level-compensate: false + +additionalProperties: false + +examples: + - | + usb-phy@13214 { + compatible = "realtek,rtd1619b-usb2phy"; + reg = <0x13214 0x4>, <0x28280 0x4>; + #phy-cells = <0>; + nvmem-cells = <&otp_usb_port0_dc_cal>, <&otp_usb_port0_dc_dis>; + nvmem-cell-names = "usb-dc-cal", "usb-dc-dis"; + + realtek,inverse-hstx-sync-clock; + realtek,driving-level = <0xa>; + realtek,disconnection-compensate = <(-1)>; + }; diff --git a/Documentation/devicetree/bindings/phy/realtek,usb3phy.yaml b/Documentation/devicetree/bindings/phy/realtek,usb3phy.yaml new file mode 100644 index 000000000000..dfe2bb4e59e7 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/realtek,usb3phy.yaml @@ -0,0 +1,107 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2023 Realtek Semiconductor Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/realtek,usb3phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek DHC SoCs USB 3.0 PHY + +maintainers: + - Stanley Chang <stanley_chang@realtek.com> + +description: | + Realtek USB 3.0 PHY support the digital home center (DHC) RTD series SoCs. + The USB 3.0 PHY driver is designed to support the XHCI controller. The SoCs + support multiple XHCI controllers. One PHY device node maps to one XHCI + controller. + + RTD1295/RTD1619 SoCs USB + The USB architecture includes three XHCI controllers. + Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on some + controllers. + XHCI controller#0 -- usb2phy -- phy#0 + |- usb3phy -- phy#0 + XHCI controller#1 -- usb2phy -- phy#0 + XHCI controller#2 -- usb2phy -- phy#0 + |- usb3phy -- phy#0 + + RTD1319/RTD1619b SoCs USB + The USB architecture includes three XHCI controllers. + Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#2. + XHCI controller#0 -- usb2phy -- phy#0 + XHCI controller#1 -- usb2phy -- phy#0 + XHCI controller#2 -- usb2phy -- phy#0 + |- usb3phy -- phy#0 + + RTD1319d SoCs USB + The USB architecture includes three XHCI controllers. + Each xhci maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#0. + XHCI controller#0 -- usb2phy -- phy#0 + |- usb3phy -- phy#0 + XHCI controller#1 -- usb2phy -- phy#0 + XHCI controller#2 -- usb2phy -- phy#0 + +properties: + compatible: + enum: + - realtek,rtd1295-usb3phy + - realtek,rtd1319-usb3phy + - realtek,rtd1319d-usb3phy + - realtek,rtd1619-usb3phy + - realtek,rtd1619b-usb3phy + + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + + nvmem-cells: + maxItems: 1 + description: A phandle to the tx lfps swing trim data provided by + a nvmem device, if unspecified, default values shall be used. + + nvmem-cell-names: + items: + - const: usb_u3_tx_lfps_swing_trim + + realtek,amplitude-control-coarse-tuning: + description: + This adjusts the signal amplitude for normal operation and beacon LFPS. + This value is a parameter for coarse tuning. + For different boards, if the default value is inappropriate, this + property can be assigned to adjust. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 255 + minimum: 0 + maximum: 255 + + realtek,amplitude-control-fine-tuning: + description: + This adjusts the signal amplitude for normal operation and beacon LFPS. + This value is used for fine-tuning parameters. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 65535 + minimum: 0 + maximum: 65535 + +required: + - compatible + - reg + - "#phy-cells" + +additionalProperties: false + +examples: + - | + usb-phy@13e10 { + compatible = "realtek,rtd1319d-usb3phy"; + reg = <0x13e10 0x4>; + #phy-cells = <0>; + + nvmem-cells = <&otp_usb_u3_tx_lfps_swing_trim>; + nvmem-cell-names = "usb_u3_tx_lfps_swing_trim"; + + realtek,amplitude-control-coarse-tuning = <0x77>; + }; diff --git a/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml index 0d6b8c28be07..5254413137c6 100644 --- a/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml +++ b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml @@ -20,6 +20,7 @@ properties: - rockchip,rk3366-usb2phy - rockchip,rk3399-usb2phy - rockchip,rk3568-usb2phy + - rockchip,rk3588-usb2phy - rockchip,rv1108-usb2phy reg: @@ -56,6 +57,14 @@ properties: description: Muxed interrupt for both ports maxItems: 1 + resets: + maxItems: 2 + + reset-names: + items: + - const: phy + - const: apb + rockchip,usbgrf: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -120,15 +129,21 @@ required: - reg - clock-output-names - "#clock-cells" - - host-port - - otg-port + +anyOf: + - required: + - otg-port + - required: + - host-port allOf: - if: properties: compatible: contains: - const: rockchip,rk3568-usb2phy + enum: + - rockchip,rk3568-usb2phy + - rockchip,rk3588-usb2phy then: properties: diff --git a/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml index 9f2d8d2cc7a5..c4fbffcde6e4 100644 --- a/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml @@ -13,19 +13,18 @@ properties: compatible: enum: - rockchip,rk3568-pcie3-phy + - rockchip,rk3588-pcie3-phy reg: maxItems: 1 clocks: - minItems: 3 + minItems: 1 maxItems: 3 clock-names: - items: - - const: refclk_m - - const: refclk_n - - const: pclk + minItems: 1 + maxItems: 3 data-lanes: description: which lanes (by position) should be mapped to which @@ -61,6 +60,30 @@ required: - rockchip,phy-grf - "#phy-cells" +allOf: + - if: + properties: + compatible: + enum: + - rockchip,rk3588-pcie3-phy + then: + properties: + clocks: + maxItems: 1 + clock-names: + items: + - const: pclk + else: + properties: + clocks: + minItems: 3 + + clock-names: + items: + - const: refclk_m + - const: refclk_n + - const: pclk + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml index 5c35e5ceec0b..46e64fa293d5 100644 --- a/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml +++ b/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml @@ -19,6 +19,7 @@ properties: - rockchip,rk3128-dsi-dphy - rockchip,rk3368-dsi-dphy - rockchip,rk3568-dsi-dphy + - rockchip,rv1126-dsi-dphy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml index 0e6505e9da50..5ac994b3c0aa 100644 --- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml @@ -10,7 +10,7 @@ maintainers: - Heiko Stuebner <heiko@sntech.de> description: | - The Rockchip SoC has a MIPI CSI D-PHY based on an Innosilicon IP wich + The Rockchip SoC has a MIPI CSI D-PHY based on an Innosilicon IP which connects to the ISP1 (Image Signal Processing unit v1.0) for CSI cameras. properties: diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml index 5ba55f9f20cc..452e584d9812 100644 --- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml @@ -29,6 +29,7 @@ properties: - samsung,exynos5420-usbdrd-phy - samsung,exynos5433-usbdrd-phy - samsung,exynos7-usbdrd-phy + - samsung,exynos850-usbdrd-phy clocks: minItems: 2 diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-rx.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-rx.yaml new file mode 100644 index 000000000000..7224cde6fce0 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-rx.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/starfive,jh7110-dphy-rx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive SoC JH7110 MIPI D-PHY Rx Controller + +maintainers: + - Jack Zhu <jack.zhu@starfivetech.com> + - Changhuang Liang <changhuang.liang@starfivetech.com> + +description: + StarFive SoCs contain a MIPI CSI D-PHY based on M31 IP, used to + transfer CSI camera data. + +properties: + compatible: + const: starfive,jh7110-dphy-rx + + reg: + maxItems: 1 + + clocks: + items: + - description: config clock + - description: reference clock + - description: escape mode transmit clock + + clock-names: + items: + - const: cfg + - const: ref + - const: tx + + resets: + items: + - description: DPHY_HW reset + - description: DPHY_B09_ALWAYS_ON reset + + power-domains: + maxItems: 1 + + "#phy-cells": + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - power-domains + - "#phy-cells" + +additionalProperties: false + +examples: + - | + phy@19820000 { + compatible = "starfive,jh7110-dphy-rx"; + reg = <0x19820000 0x10000>; + clocks = <&ispcrg 3>, + <&ispcrg 4>, + <&ispcrg 5>; + clock-names = "cfg", "ref", "tx"; + resets = <&ispcrg 2>, + <&ispcrg 3>; + power-domains = <&aon_syscon 1>; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-pcie-phy.yaml new file mode 100644 index 000000000000..2e83a6164cd1 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-pcie-phy.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/starfive,jh7110-pcie-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 PCIe 2.0 PHY + +maintainers: + - Minda Chen <minda.chen@starfivetech.com> + +properties: + compatible: + const: starfive,jh7110-pcie-phy + + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + + starfive,sys-syscon: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to System Register Controller sys_syscon node. + - description: PHY connect offset of SYS_SYSCONSAIF__SYSCFG register for USB PHY. + description: + The phandle to System Register Controller syscon node and the PHY connect offset + of SYS_SYSCONSAIF__SYSCFG register. Connect PHY to USB3 controller. + + starfive,stg-syscon: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to System Register Controller stg_syscon node. + - description: PHY mode offset of STG_SYSCONSAIF__SYSCFG register. + - description: PHY enable for USB offset of STG_SYSCONSAIF__SYSCFG register. + description: + The phandle to System Register Controller syscon node and the offset + of STG_SYSCONSAIF__SYSCFG register for PCIe PHY. Total 2 regsisters offset. + +required: + - compatible + - reg + - "#phy-cells" + +additionalProperties: false + +examples: + - | + phy@10210000 { + compatible = "starfive,jh7110-pcie-phy"; + reg = <0x10210000 0x10000>; + #phy-cells = <0>; + starfive,sys-syscon = <&sys_syscon 0x18>; + starfive,stg-syscon = <&stg_syscon 0x148 0x1f4>; + }; diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml new file mode 100644 index 000000000000..269e9f9f12b6 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/starfive,jh7110-usb-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 USB 2.0 PHY + +maintainers: + - Minda Chen <minda.chen@starfivetech.com> + +properties: + compatible: + const: starfive,jh7110-usb-phy + + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + + clocks: + items: + - description: PHY 125m + - description: app 125m + + clock-names: + items: + - const: 125m + - const: app_125m + +required: + - compatible + - reg + - clocks + - clock-names + - "#phy-cells" + +additionalProperties: false + +examples: + - | + phy@10200000 { + compatible = "starfive,jh7110-usb-phy"; + reg = <0x10200000 0x10000>; + clocks = <&syscrg 95>, + <&stgcrg 6>; + clock-names = "125m", "app_125m"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml index 9ea30eaba314..3f16ff14484d 100644 --- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml +++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml @@ -59,7 +59,7 @@ properties: description: GPIO to signal Type-C cable orientation for lane swap. If GPIO is active, lane 0 and lane 1 of SERDES will be swapped to - achieve the funtionality of an external type-C plug flip mux. + achieve the functionality of an external type-C plug flip mux. typec-dir-debounce-ms: minimum: 100 diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index 60c9d0ac75e6..7c7936b89f2c 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -62,7 +62,7 @@ Deprecated properties: - ctrl-module : phandle of the control module used by PHY driver to power on the PHY. -Recommended properies: +Recommended properties: - syscon-phy-power : phandle/offset pair. Phandle to the system control module and the register offset to power on/off the PHY. diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml index 467016cbb037..450240570314 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml @@ -97,7 +97,7 @@ patternProperties: # It's pretty scary, but the basic idea is that: # - One node name can start with either s- or r- for PRCM nodes, # - Then, the name itself can be any repetition of <string>- (to - # accomodate with nodes like uart4-rts-cts-pins), where each + # accommodate with nodes like uart4-rts-cts-pins), where each # string can be either starting with 'p' but in a string longer # than 3, or something that doesn't start with 'p', # - Then, the bank name is optional and will be between pa and pg, diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml index 99080c9eaac3..4e7a456ea4cc 100644 --- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml @@ -15,6 +15,7 @@ allOf: properties: compatible: enum: + - amlogic,c3-periphs-pinctrl - amlogic,meson-a1-periphs-pinctrl - amlogic,meson-s4-periphs-pinctrl @@ -36,6 +37,10 @@ patternProperties: - const: mux - const: gpio + gpio-line-names: + minItems: 62 # A1 + maxItems: 82 # S4 + unevaluatedProperties: type: object $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml index a7b29ef0bab6..e707c222a07f 100644 --- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml @@ -41,6 +41,13 @@ $defs: gpio-ranges: maxItems: 1 + patternProperties: + "^.+-hog(-[0-9]+)?$": + type: object + + required: + - gpio-hog + required: - reg - reg-names diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml index 7c9c94ec5b7b..0942ea60c6cd 100644 --- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml @@ -36,6 +36,9 @@ patternProperties: - const: ds - const: gpio + gpio-line-names: + maxItems: 15 + unevaluatedProperties: type: object $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml index 4bcb8b60420f..e3c8bde30559 100644 --- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml @@ -38,6 +38,9 @@ patternProperties: - const: mux - const: ds + gpio-line-names: + maxItems: 85 + unevaluatedProperties: type: object $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml index 32d99c9b6afc..c1b03147e8ec 100644 --- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml @@ -44,6 +44,10 @@ patternProperties: - const: pull - const: gpio + gpio-line-names: + minItems: 11 # GXL + maxItems: 16 # Meson8 + unevaluatedProperties: type: object $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml index d0441051f34a..4ec85b8248fa 100644 --- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml @@ -45,6 +45,10 @@ patternProperties: - const: pull-enable - const: gpio + gpio-line-names: + minItems: 86 # AXG + maxItems: 120 # Meson8 + unevaluatedProperties: type: object $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml index bef85c25cdef..37c0a74c7c01 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml @@ -25,30 +25,32 @@ properties: reg: maxItems: 2 -patternProperties: - '^.*$': - if: - type: object - then: - patternProperties: - "^function|groups$": - $ref: /schemas/types.yaml#/definitions/string - enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, - ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT, - EXTRST, FLACK, FLBUSY, FLWP, GPID, GPID0, GPID2, GPID4, GPID6, GPIE0, - GPIE2, GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4, - I2C5, I2C6, I2C7, I2C8, I2C9, LPCPD, LPCPME, LPCRST, LPCSMI, MAC1LINK, - MAC2LINK, MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, - NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, - NDTS4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, OSCCLK, PWM0, - PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1, - RMII2, ROM16, ROM8, ROMCS1, ROMCS2, ROMCS3, ROMCS4, RXD1, RXD2, RXD3, - RXD4, SALT1, SALT2, SALT3, SALT4, SD1, SD2, SGPMCK, SGPMI, SGPMLD, - SGPMO, SGPSCK, SGPSI0, SGPSI1, SGPSLD, SIOONCTRL, SIOPBI, SIOPBO, - SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1DEBUG, SPI1PASSTHRU, - SPICS1, TIMER3, TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2, - TXD3, TXD4, UART6, USB11D1, USB11H2, USB2D1, USB2H1, USBCKI, VGABIOS_ROM, - VGAHS, VGAVS, VPI18, VPI24, VPI30, VPO12, VPO24, WDTRST1, WDTRST2] +additionalProperties: + $ref: pinmux-node.yaml# + additionalProperties: false + + properties: + pins: true + bias-disable: true + + patternProperties: + "^function|groups$": + enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, + ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT, + EXTRST, FLACK, FLBUSY, FLWP, GPID, GPID0, GPID2, GPID4, GPID6, GPIE0, + GPIE2, GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4, + I2C5, I2C6, I2C7, I2C8, I2C9, LPCPD, LPCPME, LPCRST, LPCSMI, MAC1LINK, + MAC2LINK, MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, + NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, + NDTS4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, OSCCLK, PWM0, + PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1, + RMII2, ROM16, ROM8, ROMCS1, ROMCS2, ROMCS3, ROMCS4, RXD1, RXD2, RXD3, + RXD4, SALT1, SALT2, SALT3, SALT4, SD1, SD2, SGPMCK, SGPMI, SGPMLD, + SGPMO, SGPSCK, SGPSI0, SGPSI1, SGPSLD, SIOONCTRL, SIOPBI, SIOPBO, + SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1DEBUG, SPI1PASSTHRU, + SPICS1, TIMER3, TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2, + TXD3, TXD4, UART6, USB11D1, USB11H2, USB2D1, USB2H1, USBCKI, VGABIOS_ROM, + VGAHS, VGAVS, VPI18, VPI24, VPI30, VPO12, VPO24, WDTRST1, WDTRST2] allOf: - $ref: pinctrl.yaml# @@ -56,8 +58,6 @@ allOf: required: - compatible -additionalProperties: false - examples: - | syscon: scu@1e6e2000 { diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml index 14c391f16899..863da5d80826 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml @@ -37,32 +37,34 @@ properties: 0: compatible with "aspeed,ast2500-gfx", "syscon" 1: compatible with "aspeed,ast2500-lhc", "syscon" -patternProperties: - '^.*$': - if: - type: object - then: - patternProperties: - "^function|groups$": - $ref: /schemas/types.yaml#/definitions/string - enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, - ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT, - ESPI, FWSPICS1, FWSPICS2, GPID0, GPID2, GPID4, GPID6, GPIE0, GPIE2, - GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4, I2C5, - I2C6, I2C7, I2C8, I2C9, LAD0, LAD1, LAD2, LAD3, LCLK, LFRAME, LPCHC, - LPCPD, LPCPLUS, LPCPME, LPCRST, LPCSMI, LSIRQ, MAC1LINK, MAC2LINK, - MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, - NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, - NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PNOR, PWM0, - PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1, - RMII2, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, - SALT14, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, SALT9, SCL1, - SCL2, SD1, SD2, SDA1, SDA2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO, - SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1CS1, SPI1DEBUG, - SPI1PASSTHRU, SPI2CK, SPI2CS0, SPI2CS1, SPI2MISO, SPI2MOSI, TIMER3, - TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2, TXD3, TXD4, UART6, - USB11BHID, USB2AD, USB2AH, USB2BD, USB2BH, USBCKI, VGABIOSROM, VGAHS, - VGAVS, VPI24, VPO, WDTRST1, WDTRST2] +additionalProperties: + $ref: pinmux-node.yaml# + additionalProperties: false + + properties: + pins: true + bias-disable: true + + patternProperties: + "^function|groups$": + enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, + ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT, + ESPI, FWSPICS1, FWSPICS2, GPID0, GPID2, GPID4, GPID6, GPIE0, GPIE2, + GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4, I2C5, + I2C6, I2C7, I2C8, I2C9, LAD0, LAD1, LAD2, LAD3, LCLK, LFRAME, LPCHC, + LPCPD, LPCPLUS, LPCPME, LPCRST, LPCSMI, LSIRQ, MAC1LINK, MAC2LINK, + MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, + NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, + NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PNOR, PWM0, + PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1, + RMII2, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, + SALT14, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, SALT9, SCL1, + SCL2, SD1, SD2, SDA1, SDA2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO, + SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1CS1, SPI1DEBUG, + SPI1PASSTHRU, SPI2CK, SPI2CS0, SPI2CS1, SPI2MISO, SPI2MOSI, TIMER3, + TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2, TXD3, TXD4, UART6, + USB11BHID, USB2AD, USB2AH, USB2BD, USB2BH, USBCKI, VGABIOSROM, VGAHS, + VGAVS, VPI24, VPO, WDTRST1, WDTRST2] allOf: - $ref: pinctrl.yaml# @@ -71,8 +73,6 @@ required: - compatible - aspeed,external-nodes -additionalProperties: false - examples: - | #include <dt-bindings/clock/aspeed-clock.h> diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index 859a1889dc1e..612464aef98b 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -23,65 +23,65 @@ properties: compatible: const: aspeed,ast2600-pinctrl -patternProperties: - '^.*$': - if: - type: object - then: - properties: - function: - $ref: /schemas/types.yaml#/definitions/string - enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, - ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMC, ESPI, ESPIALT, - FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, - GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5, - GPIU6, GPIU7, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, - I2C2, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, - I3C6, JTAGM, LHPD, LHSIRQ, LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, - MACLINK1, MACLINK2, MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, - NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, - NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, - NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PWM0, PWM1, PWM10, PWM11, - PWM12, PWM13, PWM14, PWM15, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, PWM8, - PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4, - RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, SALT14, - SALT15, SALT16, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, - SALT9, SD1, SD2, SGPM1, SGPM2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO, - SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2, - SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, TACH12, TACH13, TACH14, - TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0, - THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12, - UART13, UART6, UART7, UART8, UART9, USBAD, USBADP, USB2AH, USB2AHP, - USB2BD, USB2BH, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, WDTRST4 ] - - groups: - $ref: /schemas/types.yaml#/definitions/string - enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, - ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, EMMCG4, - EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, - GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, - GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1, I2C10, - I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, - I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ, - LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2, MACLINK3, - MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, NCTS1, NCTS2, NCTS3, NCTS4, - NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, - NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, - OSCCLK, PEWAKE, PWM0, PWM1, PWM10G0, PWM10G1, PWM11G0, PWM11G1, PWM12G0, - PWM12G1, PWM13G0, PWM13G1, PWM14G0, PWM14G1, PWM15G0, PWM15G1, PWM2, - PWM3, PWM4, PWM5, PWM6, PWM7, PWM8G0, PWM8G1, PWM9G0, PWM9G1, QSPI1, - QSPI2, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4, - RXD1, RXD2, RXD3, RXD4, SALT1, SALT10G0, SALT10G1, SALT11G0, SALT11G1, - SALT12G0, SALT12G1, SALT13G0, SALT13G1, SALT14G0, SALT14G1, SALT15G0, - SALT15G1, SALT16G0, SALT16G1, SALT2, SALT3, SALT4, SALT5, SALT6, - SALT7, SALT8, SALT9G0, SALT9G1, SD1, SD2, SD3, SGPM1, SGPM2, SGPS1, SGPS2, - SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, - SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, - TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, - TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, - TXD4, UART10, UART11, UART12G0, UART12G1, UART13G0, UART13G1, UART6, - UART7, UART8, UART9, USBA, USBB, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, - WDTRST3, WDTRST4] +additionalProperties: + $ref: pinmux-node.yaml# + additionalProperties: false + + properties: + function: + enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, + ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMC, ESPI, ESPIALT, + FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, + GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5, + GPIU6, GPIU7, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, + I2C2, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, + I3C6, JTAGM, LHPD, LHSIRQ, LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, + MACLINK1, MACLINK2, MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, + NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, + NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, + NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PWM0, PWM1, PWM10, PWM11, + PWM12, PWM13, PWM14, PWM15, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, PWM8, + PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4, + RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, SALT14, + SALT15, SALT16, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, + SALT9, SD1, SD2, SGPM1, SGPM2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO, + SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2, + SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, TACH12, TACH13, TACH14, + TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0, + THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12, + UART13, UART6, UART7, UART8, UART9, USBAD, USBADP, USB2AH, USB2AHP, + USB2BD, USB2BH, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, WDTRST4 ] + + groups: + enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, + ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, EMMCG4, + EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, + GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, + GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1, I2C10, + I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, + I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ, + LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2, MACLINK3, + MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, NCTS1, NCTS2, NCTS3, NCTS4, + NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, + NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, + OSCCLK, PEWAKE, PWM0, PWM1, PWM10G0, PWM10G1, PWM11G0, PWM11G1, PWM12G0, + PWM12G1, PWM13G0, PWM13G1, PWM14G0, PWM14G1, PWM15G0, PWM15G1, PWM2, + PWM3, PWM4, PWM5, PWM6, PWM7, PWM8G0, PWM8G1, PWM9G0, PWM9G1, QSPI1, + QSPI2, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4, + RXD1, RXD2, RXD3, RXD4, SALT1, SALT10G0, SALT10G1, SALT11G0, SALT11G1, + SALT12G0, SALT12G1, SALT13G0, SALT13G1, SALT14G0, SALT14G1, SALT15G0, + SALT15G1, SALT16G0, SALT16G1, SALT2, SALT3, SALT4, SALT5, SALT6, + SALT7, SALT8, SALT9G0, SALT9G1, SD1, SD2, SD3, SGPM1, SGPM2, SGPS1, SGPS2, + SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, + SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, + TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, + TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, + TXD4, UART10, UART11, UART12G0, UART12G1, UART13G0, UART13G1, UART6, + UART7, UART8, UART9, USBA, USBB, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, + WDTRST3, WDTRST4] + + pins: true + bias-disable: true allOf: - $ref: pinctrl.yaml# @@ -89,8 +89,6 @@ allOf: required: - compatible -additionalProperties: false - examples: - | syscon: scu@1e6e2000 { diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt index e2b861ce16d8..774c3c269c40 100644 --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt @@ -37,7 +37,8 @@ right representation of the pin. Optional properties: - GENERIC_PINCONFIG: generic pinconfig options to use: - bias-disable, bias-pull-down, bias-pull-up, drive-open-drain, - input-schmitt-enable, input-debounce, output-low, output-high. + drive-push-pull input-schmitt-enable, input-debounce, output-low, + output-high. - for microchip,sama7g5-pinctrl only: - slew-rate: 0 - disabled, 1 - enabled (default) - atmel,drive-strength: 0 or 1 for low drive, 2 for medium drive and 3 for diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt deleted file mode 100644 index e047a198db38..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt +++ /dev/null @@ -1,461 +0,0 @@ -Broadcom BCM281xx Pin Controller - -This is a pin controller for the Broadcom BCM281xx SoC family, which includes -BCM11130, BCM11140, BCM11351, BCM28145, and BCM28155 SoCs. - -=== Pin Controller Node === - -Required Properties: - -- compatible: Must be "brcm,bcm11351-pinctrl" -- reg: Base address of the PAD Controller register block and the size - of the block. - -For example, the following is the bare minimum node: - - pinctrl@35004800 { - compatible = "brcm,bcm11351-pinctrl"; - reg = <0x35004800 0x430>; - }; - -As a pin controller device, in addition to the required properties, this node -should also contain the pin configuration nodes that client devices reference, -if any. - -=== Pin Configuration Node === - -Each pin configuration node is a sub-node of the pin controller node and is a -container of an arbitrary number of subnodes, called pin group nodes in this -document. - -Please refer to the pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the definition of a -"pin configuration node". - -=== Pin Group Node === - -A pin group node specifies the desired pin mux and/or pin configuration for an -arbitrary number of pins. The name of the pin group node is optional and not -used. - -A pin group node only affects the properties specified in the node, and has no -effect on any properties that are omitted. - -The pin group node accepts a subset of the generic pin config properties. For -details generic pin config properties, please refer to pinctrl-bindings.txt -and <include/linux/pinctrl/pinconfig-generic.h>. - -Each pin controlled by this pin controller belong to one of three types: -Standard, I2C, and HDMI. Each type accepts a different set of pin config -properties. A list of pins and their types is provided below. - -Required Properties (applicable to all pins): - -- pins: Multiple strings. Specifies the name(s) of one or more pins to - be configured by this node. - -Optional Properties (for standard pins): - -- function: String. Specifies the pin mux selection. Values - must be one of: "alt1", "alt2", "alt3", "alt4" -- input-schmitt-enable: No arguments. Enable schmitt-trigger mode. -- input-schmitt-disable: No arguments. Disable schmitt-trigger mode. -- bias-pull-up: No arguments. Pull up on pin. -- bias-pull-down: No arguments. Pull down on pin. -- bias-disable: No arguments. Disable pin bias. -- slew-rate: Integer. Meaning depends on configured pin mux: - *_SCL or *_SDA: - 0: Standard(100kbps)& Fast(400kbps) mode - 1: Highspeed (3.4Mbps) mode - IC_DM or IC_DP: - 0: normal slew rate - 1: fast slew rate - Otherwise: - 0: fast slew rate - 1: normal slew rate -- input-enable: No arguments. Enable input (does not affect - output.) -- input-disable: No arguments. Disable input (does not affect - output.) -- drive-strength: Integer. Drive strength in mA. Valid values are - 2, 4, 6, 8, 10, 12, 14, 16 mA. - -Optional Properties (for I2C pins): - -- function: String. Specifies the pin mux selection. Values - must be one of: "alt1", "alt2", "alt3", "alt4" -- bias-pull-up: Integer. Pull up strength in Ohm. There are 3 - pull-up resistors (1.2k, 1.8k, 2.7k) available - in parallel for I2C pins, so the valid values - are: 568, 720, 831, 1080, 1200, 1800, 2700 Ohm. -- bias-disable: No arguments. Disable pin bias. -- slew-rate: Integer. Meaning depends on configured pin mux: - *_SCL or *_SDA: - 0: Standard(100kbps)& Fast(400kbps) mode - 1: Highspeed (3.4Mbps) mode - IC_DM or IC_DP: - 0: normal slew rate - 1: fast slew rate - Otherwise: - 0: fast slew rate - 1: normal slew rate -- input-enable: No arguments. Enable input (does not affect - output.) -- input-disable: No arguments. Disable input (does not affect - output.) - -Optional Properties (for HDMI pins): - -- function: String. Specifies the pin mux selection. Values - must be one of: "alt1", "alt2", "alt3", "alt4" -- slew-rate: Integer. Controls slew rate. - 0: Standard(100kbps)& Fast(400kbps) mode - 1: Highspeed (3.4Mbps) mode -- input-enable: No arguments. Enable input (does not affect - output.) -- input-disable: No arguments. Disable input (does not affect - output.) - -Example: -// pin controller node -pinctrl@35004800 { - compatible = "brcm,bcm11351-pinctrl"; - reg = <0x35004800 0x430>; - - // pin configuration node - dev_a_default: dev_a_active { - //group node defining 1 standard pin - grp_1 { - pins = "std_pin1"; - function = "alt1"; - input-schmitt-enable; - bias-disable; - slew-rate = <1>; - drive-strength = <4>; - }; - - // group node defining 2 I2C pins - grp_2 { - pins = "i2c_pin1", "i2c_pin2"; - function = "alt2"; - bias-pull-up = <720>; - input-enable; - }; - - // group node defining 2 HDMI pins - grp_3 { - pins = "hdmi_pin1", "hdmi_pin2"; - function = "alt3"; - slew-rate = <1>; - }; - - // other pin group nodes - ... - }; - - // other pin configuration nodes - ... -}; - -In the example above, "dev_a_active" is a pin configuration node with a number -of sub-nodes. In the pin group node "grp_1", one pin, "std_pin1", is defined in -the "pins" property. Thus, the remaining properties in the "grp_1" node applies -only to this pin, including the following settings: - - setting pinmux to "alt1" - - enabling schmitt-trigger (hystersis) mode - - disabling pin bias - - setting the slew-rate to 1 - - setting the drive strength to 4 mA -Note that neither "input-enable" nor "input-disable" was specified - the pinctrl -subsystem will therefore leave this property unchanged from whatever state it -was in before applying these changes. - -The "pins" property in the pin group node "grp_2" specifies two pins - -"i2c_pin1" and "i2c_pin2"; the remaining properties in this pin group node, -therefore, applies to both of these pins. The properties include: - - setting pinmux to "alt2" - - setting pull-up resistance to 720 Ohm (ie. enabling 1.2k and 1.8k resistors - in parallel) - - enabling both pins' input -"slew-rate" is not specified in this pin group node, so the slew-rate for these -pins are left as-is. - -Finally, "grp_3" defines two HDMI pins. The following properties are applied to -both pins: - - setting pinmux to "alt3" - - setting slew-rate to 1; for HDMI pins, this corresponds to the 3.4 Mbps - Highspeed mode -The input is neither enabled or disabled, and is left untouched. - -=== Pin Names and Type === - -The following are valid pin names and their pin types: - - "adcsync", Standard - "bat_rm", Standard - "bsc1_scl", I2C - "bsc1_sda", I2C - "bsc2_scl", I2C - "bsc2_sda", I2C - "classgpwr", Standard - "clk_cx8", Standard - "clkout_0", Standard - "clkout_1", Standard - "clkout_2", Standard - "clkout_3", Standard - "clkreq_in_0", Standard - "clkreq_in_1", Standard - "cws_sys_req1", Standard - "cws_sys_req2", Standard - "cws_sys_req3", Standard - "digmic1_clk", Standard - "digmic1_dq", Standard - "digmic2_clk", Standard - "digmic2_dq", Standard - "gpen13", Standard - "gpen14", Standard - "gpen15", Standard - "gpio00", Standard - "gpio01", Standard - "gpio02", Standard - "gpio03", Standard - "gpio04", Standard - "gpio05", Standard - "gpio06", Standard - "gpio07", Standard - "gpio08", Standard - "gpio09", Standard - "gpio10", Standard - "gpio11", Standard - "gpio12", Standard - "gpio13", Standard - "gpio14", Standard - "gps_pablank", Standard - "gps_tmark", Standard - "hdmi_scl", HDMI - "hdmi_sda", HDMI - "ic_dm", Standard - "ic_dp", Standard - "kp_col_ip_0", Standard - "kp_col_ip_1", Standard - "kp_col_ip_2", Standard - "kp_col_ip_3", Standard - "kp_row_op_0", Standard - "kp_row_op_1", Standard - "kp_row_op_2", Standard - "kp_row_op_3", Standard - "lcd_b_0", Standard - "lcd_b_1", Standard - "lcd_b_2", Standard - "lcd_b_3", Standard - "lcd_b_4", Standard - "lcd_b_5", Standard - "lcd_b_6", Standard - "lcd_b_7", Standard - "lcd_g_0", Standard - "lcd_g_1", Standard - "lcd_g_2", Standard - "lcd_g_3", Standard - "lcd_g_4", Standard - "lcd_g_5", Standard - "lcd_g_6", Standard - "lcd_g_7", Standard - "lcd_hsync", Standard - "lcd_oe", Standard - "lcd_pclk", Standard - "lcd_r_0", Standard - "lcd_r_1", Standard - "lcd_r_2", Standard - "lcd_r_3", Standard - "lcd_r_4", Standard - "lcd_r_5", Standard - "lcd_r_6", Standard - "lcd_r_7", Standard - "lcd_vsync", Standard - "mdmgpio0", Standard - "mdmgpio1", Standard - "mdmgpio2", Standard - "mdmgpio3", Standard - "mdmgpio4", Standard - "mdmgpio5", Standard - "mdmgpio6", Standard - "mdmgpio7", Standard - "mdmgpio8", Standard - "mphi_data_0", Standard - "mphi_data_1", Standard - "mphi_data_2", Standard - "mphi_data_3", Standard - "mphi_data_4", Standard - "mphi_data_5", Standard - "mphi_data_6", Standard - "mphi_data_7", Standard - "mphi_data_8", Standard - "mphi_data_9", Standard - "mphi_data_10", Standard - "mphi_data_11", Standard - "mphi_data_12", Standard - "mphi_data_13", Standard - "mphi_data_14", Standard - "mphi_data_15", Standard - "mphi_ha0", Standard - "mphi_hat0", Standard - "mphi_hat1", Standard - "mphi_hce0_n", Standard - "mphi_hce1_n", Standard - "mphi_hrd_n", Standard - "mphi_hwr_n", Standard - "mphi_run0", Standard - "mphi_run1", Standard - "mtx_scan_clk", Standard - "mtx_scan_data", Standard - "nand_ad_0", Standard - "nand_ad_1", Standard - "nand_ad_2", Standard - "nand_ad_3", Standard - "nand_ad_4", Standard - "nand_ad_5", Standard - "nand_ad_6", Standard - "nand_ad_7", Standard - "nand_ale", Standard - "nand_cen_0", Standard - "nand_cen_1", Standard - "nand_cle", Standard - "nand_oen", Standard - "nand_rdy_0", Standard - "nand_rdy_1", Standard - "nand_wen", Standard - "nand_wp", Standard - "pc1", Standard - "pc2", Standard - "pmu_int", Standard - "pmu_scl", I2C - "pmu_sda", I2C - "rfst2g_mtsloten3g", Standard - "rgmii_0_rx_ctl", Standard - "rgmii_0_rxc", Standard - "rgmii_0_rxd_0", Standard - "rgmii_0_rxd_1", Standard - "rgmii_0_rxd_2", Standard - "rgmii_0_rxd_3", Standard - "rgmii_0_tx_ctl", Standard - "rgmii_0_txc", Standard - "rgmii_0_txd_0", Standard - "rgmii_0_txd_1", Standard - "rgmii_0_txd_2", Standard - "rgmii_0_txd_3", Standard - "rgmii_1_rx_ctl", Standard - "rgmii_1_rxc", Standard - "rgmii_1_rxd_0", Standard - "rgmii_1_rxd_1", Standard - "rgmii_1_rxd_2", Standard - "rgmii_1_rxd_3", Standard - "rgmii_1_tx_ctl", Standard - "rgmii_1_txc", Standard - "rgmii_1_txd_0", Standard - "rgmii_1_txd_1", Standard - "rgmii_1_txd_2", Standard - "rgmii_1_txd_3", Standard - "rgmii_gpio_0", Standard - "rgmii_gpio_1", Standard - "rgmii_gpio_2", Standard - "rgmii_gpio_3", Standard - "rtxdata2g_txdata3g1", Standard - "rtxen2g_txdata3g2", Standard - "rxdata3g0", Standard - "rxdata3g1", Standard - "rxdata3g2", Standard - "sdio1_clk", Standard - "sdio1_cmd", Standard - "sdio1_data_0", Standard - "sdio1_data_1", Standard - "sdio1_data_2", Standard - "sdio1_data_3", Standard - "sdio4_clk", Standard - "sdio4_cmd", Standard - "sdio4_data_0", Standard - "sdio4_data_1", Standard - "sdio4_data_2", Standard - "sdio4_data_3", Standard - "sim_clk", Standard - "sim_data", Standard - "sim_det", Standard - "sim_resetn", Standard - "sim2_clk", Standard - "sim2_data", Standard - "sim2_det", Standard - "sim2_resetn", Standard - "sri_c", Standard - "sri_d", Standard - "sri_e", Standard - "ssp_extclk", Standard - "ssp0_clk", Standard - "ssp0_fs", Standard - "ssp0_rxd", Standard - "ssp0_txd", Standard - "ssp2_clk", Standard - "ssp2_fs_0", Standard - "ssp2_fs_1", Standard - "ssp2_fs_2", Standard - "ssp2_fs_3", Standard - "ssp2_rxd_0", Standard - "ssp2_rxd_1", Standard - "ssp2_txd_0", Standard - "ssp2_txd_1", Standard - "ssp3_clk", Standard - "ssp3_fs", Standard - "ssp3_rxd", Standard - "ssp3_txd", Standard - "ssp4_clk", Standard - "ssp4_fs", Standard - "ssp4_rxd", Standard - "ssp4_txd", Standard - "ssp5_clk", Standard - "ssp5_fs", Standard - "ssp5_rxd", Standard - "ssp5_txd", Standard - "ssp6_clk", Standard - "ssp6_fs", Standard - "ssp6_rxd", Standard - "ssp6_txd", Standard - "stat_1", Standard - "stat_2", Standard - "sysclken", Standard - "traceclk", Standard - "tracedt00", Standard - "tracedt01", Standard - "tracedt02", Standard - "tracedt03", Standard - "tracedt04", Standard - "tracedt05", Standard - "tracedt06", Standard - "tracedt07", Standard - "tracedt08", Standard - "tracedt09", Standard - "tracedt10", Standard - "tracedt11", Standard - "tracedt12", Standard - "tracedt13", Standard - "tracedt14", Standard - "tracedt15", Standard - "txdata3g0", Standard - "txpwrind", Standard - "uartb1_ucts", Standard - "uartb1_urts", Standard - "uartb1_urxd", Standard - "uartb1_utxd", Standard - "uartb2_urxd", Standard - "uartb2_utxd", Standard - "uartb3_ucts", Standard - "uartb3_urts", Standard - "uartb3_urxd", Standard - "uartb3_utxd", Standard - "uartb4_ucts", Standard - "uartb4_urts", Standard - "uartb4_urxd", Standard - "uartb4_utxd", Standard - "vc_cam1_scl", I2C - "vc_cam1_sda", I2C - "vc_cam2_scl", I2C - "vc_cam2_sda", I2C - "vc_cam3_scl", I2C - "vc_cam3_sda", I2C diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.yaml new file mode 100644 index 000000000000..90c275295199 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.yaml @@ -0,0 +1,259 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/brcm,bcm11351-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM281xx pin controller + +maintainers: + - Florian Fainelli <florian.fainelli@broadcom.com> + - Ray Jui <rjui@broadcom.com> + - Scott Branden <sbranden@broadcom.com> + +allOf: + - $ref: pinctrl.yaml# + +properties: + compatible: + const: brcm,bcm11351-pinctrl + + reg: + maxItems: 1 + +patternProperties: + '-pins$': + type: object + additionalProperties: false + + patternProperties: + '-grp[0-9]$': + type: object + unevaluatedProperties: false + + properties: + pins: + description: + Specifies the name(s) of one or more pins to be configured by + this node. + items: + enum: [ adcsync, bat_rm, bsc1_scl, bsc1_sda, bsc2_scl, bsc2_sda, + classgpwr, clk_cx8, clkout_0, clkout_1, clkout_2, + clkout_3, clkreq_in_0, clkreq_in_1, cws_sys_req1, + cws_sys_req2, cws_sys_req3, digmic1_clk, digmic1_dq, + digmic2_clk, digmic2_dq, gpen13, gpen14, gpen15, gpio00, + gpio01, gpio02, gpio03, gpio04, gpio05, gpio06, gpio07, + gpio08, gpio09, gpio10, gpio11, gpio12, gpio13, gpio14, + gps_pablank, gps_tmark, hdmi_scl, hdmi_sda, ic_dm, ic_dp, + kp_col_ip_0, kp_col_ip_1, kp_col_ip_2, kp_col_ip_3, + kp_row_op_0, kp_row_op_1, kp_row_op_2, kp_row_op_3, + lcd_b_0, lcd_b_1, lcd_b_2, lcd_b_3, lcd_b_4, lcd_b_5, + lcd_b_6, lcd_b_7, lcd_g_0, lcd_g_1, lcd_g_2, lcd_g_3, + lcd_g_4, lcd_g_5, lcd_g_6, lcd_g_7, lcd_hsync, lcd_oe, + lcd_pclk, lcd_r_0, lcd_r_1, lcd_r_2, lcd_r_3, lcd_r_4, + lcd_r_5, lcd_r_6, lcd_r_7, lcd_vsync, mdmgpio0, mdmgpio1, + mdmgpio2, mdmgpio3, mdmgpio4, mdmgpio5, mdmgpio6, + mdmgpio7, mdmgpio8, mphi_data_0, mphi_data_1, mphi_data_2, + mphi_data_3, mphi_data_4, mphi_data_5, mphi_data_6, + mphi_data_7, mphi_data_8, mphi_data_9, mphi_data_10, + mphi_data_11, mphi_data_12, mphi_data_13, mphi_data_14, + mphi_data_15, mphi_ha0, mphi_hat0, mphi_hat1, mphi_hce0_n, + mphi_hce1_n, mphi_hrd_n, mphi_hwr_n, mphi_run0, mphi_run1, + mtx_scan_clk, mtx_scan_data, nand_ad_0, nand_ad_1, + nand_ad_2, nand_ad_3, nand_ad_4, nand_ad_5, nand_ad_6, + nand_ad_7, nand_ale, nand_cen_0, nand_cen_1, nand_cle, + nand_oen, nand_rdy_0, nand_rdy_1, nand_wen, nand_wp, pc1, + pc2, pmu_int, pmu_scl, pmu_sda, rfst2g_mtsloten3g, + rgmii_0_rx_ctl, rgmii_0_rxc, rgmii_0_rxd_0, rgmii_0_rxd_1, + rgmii_0_rxd_2, rgmii_0_rxd_3, rgmii_0_tx_ctl, rgmii_0_txc, + rgmii_0_txd_0, rgmii_0_txd_1, rgmii_0_txd_2, + rgmii_0_txd_3, rgmii_1_rx_ctl, rgmii_1_rxc, rgmii_1_rxd_0, + rgmii_1_rxd_1, rgmii_1_rxd_2, rgmii_1_rxd_3, + rgmii_1_tx_ctl, rgmii_1_txc, rgmii_1_txd_0, rgmii_1_txd_1, + rgmii_1_txd_2, rgmii_1_txd_3, rgmii_gpio_0, rgmii_gpio_1, + rgmii_gpio_2, rgmii_gpio_3, rtxdata2g_txdata3g1, + rtxen2g_txdata3g2, rxdata3g0, rxdata3g1, rxdata3g2, + sdio1_clk, sdio1_cmd, sdio1_data_0, sdio1_data_1, + sdio1_data_2, sdio1_data_3, sdio4_clk, sdio4_cmd, + sdio4_data_0, sdio4_data_1, sdio4_data_2, sdio4_data_3, + sim_clk, sim_data, sim_det, sim_resetn, sim2_clk, + sim2_data, sim2_det, sim2_resetn, sri_c, sri_d, sri_e, + ssp_extclk, ssp0_clk, ssp0_fs, ssp0_rxd, ssp0_txd, + ssp2_clk, ssp2_fs_0, ssp2_fs_1, ssp2_fs_2, ssp2_fs_3, + ssp2_rxd_0, ssp2_rxd_1, ssp2_txd_0, ssp2_txd_1, ssp3_clk, + ssp3_fs, ssp3_rxd, ssp3_txd, ssp4_clk, ssp4_fs, ssp4_rxd, + ssp4_txd, ssp5_clk, ssp5_fs, ssp5_rxd, ssp5_txd, ssp6_clk, + ssp6_fs, ssp6_rxd, ssp6_txd, stat_1, stat_2, sysclken, + traceclk, tracedt00, tracedt01, tracedt02, tracedt03, + tracedt04, tracedt05, tracedt06, tracedt07, tracedt08 + tracedt09, tracedt10, tracedt11, tracedt12, tracedt13 + tracedt14, tracedt15, txdata3g0, txpwrind, uartb1_ucts, + uartb1_urts, uartb1_urxd, uartb1_utxd, uartb2_urxd, + uartb2_utxd, uartb3_ucts, uartb3_urts, uartb3_urxd, + uartb3_utxd, uartb4_ucts, uartb4_urts, uartb4_urxd, + uartb4_utxd, vc_cam1_scl, vc_cam1_sda, vc_cam2_scl, + vc_cam2_sda, vc_cam3_scl, vc_cam3_sda ] + + function: + description: + Specifies the pin mux selection. + enum: [ alt1, alt2, alt3, alt4 ] + + slew-rate: + description: | + Meaning depends on configured pin mux: + *_scl or *_sda: + 0: Standard (100 kbps) & Fast (400 kbps) mode + 1: Highspeed (3.4 Mbps) mode + ic_dm or ic_dp: + 0: normal slew rate + 1: fast slew rate + Otherwise: + 0: fast slew rate + 1: normal slew rate + + bias-disable: true + input-disable: true + input-enable: true + + required: + - pins + + allOf: + - $ref: pincfg-node.yaml# + + # Optional properties for standard pins + - if: + properties: + pins: + contains: + enum: [ adcsync, bat_rm, classgpwr, clk_cx8, clkout_0, + clkout_1, clkout_2, clkout_3, clkreq_in_0, + clkreq_in_1, cws_sys_req1, cws_sys_req2, + cws_sys_req3, digmic1_clk, digmic1_dq, digmic2_clk, + digmic2_dq, gpen13, gpen14, gpen15, gpio00, gpio01, + gpio02, gpio03, gpio04, gpio05, gpio06, gpio07, + gpio08, gpio09, gpio10, gpio11, gpio12, gpio13, + gpio14, gps_pablank, gps_tmark, ic_dm, ic_dp, + kp_col_ip_0, kp_col_ip_1, kp_col_ip_2, kp_col_ip_3, + kp_row_op_0, kp_row_op_1, kp_row_op_2, kp_row_op_3, + lcd_b_0, lcd_b_1, lcd_b_2, lcd_b_3, lcd_b_4, lcd_b_5, + lcd_b_6, lcd_b_7, lcd_g_0, lcd_g_1, lcd_g_2, lcd_g_3, + lcd_g_4, lcd_g_5, lcd_g_6, lcd_g_7, lcd_hsync, + lcd_oe, lcd_pclk, lcd_r_0, lcd_r_1, lcd_r_2, + lcd_r_3, lcd_r_4, lcd_r_5, lcd_r_6, lcd_r_7, + lcd_vsync, mdmgpio0, mdmgpio1, mdmgpio2, mdmgpio3, + mdmgpio4, mdmgpio5, mdmgpio6, mdmgpio7, mdmgpio8, + mphi_data_0, mphi_data_1, mphi_data_2, mphi_data_3, + mphi_data_4, mphi_data_5, mphi_data_6, mphi_data_7, + mphi_data_8, mphi_data_9, mphi_data_10, + mphi_data_11, mphi_data_12, mphi_data_13, + mphi_data_14, mphi_data_15, mphi_ha0, mphi_hat0, + mphi_hat1, mphi_hce0_n, mphi_hce1_n, mphi_hrd_n, + mphi_hwr_n, mphi_run0, mphi_run1, mtx_scan_clk, + mtx_scan_data, nand_ad_0, nand_ad_1, nand_ad_2, + nand_ad_3, nand_ad_4, nand_ad_5, nand_ad_6, + nand_ad_7, nand_ale, nand_cen_0, nand_cen_1, + nand_cle, nand_oen, nand_rdy_0, nand_rdy_1, + nand_wen, nand_wp, pc1, pc2, pmu_int, + rfst2g_mtsloten3g, rgmii_0_rx_ctl, rgmii_0_rxc, + rgmii_0_rxd_0, rgmii_0_rxd_1, rgmii_0_rxd_2, + rgmii_0_rxd_3, rgmii_0_tx_ctl, rgmii_0_txc, + rgmii_0_txd_0, rgmii_0_txd_1, rgmii_0_txd_2, + rgmii_0_txd_3, rgmii_1_rx_ctl, rgmii_1_rxc, + rgmii_1_rxd_0, rgmii_1_rxd_1, rgmii_1_rxd_2, + rgmii_1_rxd_3, rgmii_1_tx_ctl, rgmii_1_txc, + rgmii_1_txd_0, rgmii_1_txd_1, rgmii_1_txd_2, + rgmii_1_txd_3, rgmii_gpio_0, rgmii_gpio_1, + rgmii_gpio_2, rgmii_gpio_3, rtxdata2g_txdata3g1, + rtxen2g_txdata3g2, rxdata3g0, rxdata3g1, rxdata3g2, + sdio1_clk, sdio1_cmd, sdio1_data_0, sdio1_data_1, + sdio1_data_2, sdio1_data_3, sdio4_clk, sdio4_cmd, + sdio4_data_0, sdio4_data_1, sdio4_data_2, + sdio4_data_3, sim_clk, sim_data, sim_det, + sim_resetn, sim2_clk, sim2_data, sim2_det, + sim2_resetn, sri_c, sri_d, sri_e, ssp_extclk, + ssp0_clk, ssp0_fs, ssp0_rxd, ssp0_txd, ssp2_clk, + ssp2_fs_0, ssp2_fs_1, ssp2_fs_2, ssp2_fs_3, + ssp2_rxd_0, ssp2_rxd_1, ssp2_txd_0, ssp2_txd_1, + ssp3_clk, ssp3_fs, ssp3_rxd, ssp3_txd, ssp4_clk, + ssp4_fs, ssp4_rxd, ssp4_txd, ssp5_clk, ssp5_fs, + ssp5_rxd, ssp5_txd, ssp6_clk, ssp6_fs, ssp6_rxd, + ssp6_txd, stat_1, stat_2, sysclken, traceclk, + tracedt00, tracedt01, tracedt02, tracedt03, + tracedt04, tracedt05, tracedt06, tracedt07, + tracedt08, tracedt09, tracedt10, tracedt11, + tracedt12, tracedt13, tracedt14, tracedt15, + txdata3g0, txpwrind, uartb1_ucts, uartb1_urts, + uartb1_urxd, uartb1_utxd, uartb2_urxd, uartb2_utxd, + uartb3_ucts, uartb3_urts, uartb3_urxd, uartb3_utxd, + uartb4_ucts, uartb4_urts, uartb4_urxd, uartb4_utxd ] + then: + properties: + drive-strength: + enum: [ 2, 4, 6, 8, 10, 12, 14, 16 ] + + bias-disable: true + bias-pull-up: true + bias-pull-down: true + input-schmitt-enable: true + input-schmitt-disable: true + + # Optional properties for I2C pins + - if: + properties: + pins: + contains: + enum: [ bsc1_scl, bsc1_sda, bsc2_scl, bsc2_sda, pmu_scl, + pmu_sda, vc_cam1_scl, vc_cam1_sda, vc_cam2_scl, + vc_cam2_sda, vc_cam3_scl, vc_cam3_sda ] + then: + properties: + bias-pull-up: + description: + There are 3 pull-up resistors (1.2k, 1.8k, 2.7k) available + in parallel for I2C pins. + enum: [ 568, 720, 831, 1080, 1200, 1800, 2700 ] + + bias-disable: true + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + pinctrl@35004800 { + compatible = "brcm,bcm11351-pinctrl"; + reg = <0x35004800 0x430>; + + dev-a-active-pins { + /* group node defining 1 standard pin */ + std-grp0 { + pins = "gpio00"; + function = "alt1"; + input-schmitt-enable; + bias-disable; + slew-rate = <1>; + drive-strength = <4>; + }; + + /* group node defining 2 I2C pins */ + i2c-grp0 { + pins = "bsc1_scl", "bsc1_sda"; + function = "alt2"; + bias-pull-up = <720>; + input-enable; + }; + + /* group node defining 2 HDMI pins */ + hdmi-grp0 { + pins = "hdmi_scl", "hdmi_sda"; + function = "alt3"; + slew-rate = <1>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml index 739a08f00467..beb769e887c7 100644 --- a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml +++ b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml @@ -11,7 +11,7 @@ maintainers: description: The Canaan Kendryte K210 SoC Fully Programmable IO Array (FPIOA) - controller allows assiging any of 256 possible functions to any of + controller allows assigning any of 256 possible functions to any of 48 IO pins of the SoC. Pin function configuration is performed on a per-pin basis. diff --git a/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml b/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml index 222d57541b65..7f30ec2f1e54 100644 --- a/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml @@ -51,6 +51,10 @@ properties: description: Optional power supply. + reset-gpios: + description: GPIO connected to the XRES pin + maxItems: 1 + patternProperties: '-pins$': type: object diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml index 35723966b70a..890961826c6f 100644 --- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml @@ -135,7 +135,6 @@ additionalProperties: - $ref: pinmux-node.yaml# properties: - phandle: true function: true groups: true pins: true @@ -147,8 +146,6 @@ additionalProperties: additionalProperties: false - type: object - properties: - phandle: true additionalProperties: type: object allOf: @@ -156,7 +153,6 @@ additionalProperties: - $ref: pinmux-node.yaml# properties: - phandle: true function: true groups: true pins: true diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml index 7f0e2d6cd6d9..3bbc00df5548 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml @@ -159,7 +159,7 @@ patternProperties: mediatek,pull-up-adv: description: | - Pull up setings for 2 pull resistors, R0 and R1. User can + Pull up settings for 2 pull resistors, R0 and R1. User can configure those special pins. Valid arguments are described as below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml index 601d86aecdd4..68e91c05f122 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml @@ -130,7 +130,7 @@ patternProperties: mediatek,pull-up-adv: description: | - Pull up setings for 2 pull resistors, R0 and R1. User can + Pull up settings for 2 pull resistors, R0 and R1. User can configure those special pins. Valid arguments are described as below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml index 10717cee9058..74d52a741f6f 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml @@ -386,7 +386,7 @@ patternProperties: mediatek,pull-up-adv: description: | Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3' - Pull up setings for 2 pull resistors, R0 and R1. Valid arguments + 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. @@ -398,7 +398,7 @@ patternProperties: mediatek,pull-down-adv: description: | Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3' - Pull down setings for 2 pull resistors, R0 and R1. Valid arguments + 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. diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml index 0f615ada290a..5ad65135fe1c 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml @@ -332,7 +332,7 @@ patternProperties: mediatek,pull-up-adv: description: | Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3' - Pull up setings for 2 pull resistors, R0 and R1. Valid arguments + 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. @@ -344,7 +344,7 @@ patternProperties: mediatek,pull-down-adv: description: | Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3' - Pull down setings for 2 pull resistors, R0 and R1. Valid arguments + 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. diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml index ff24cf29eea7..8507bd15f243 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml @@ -143,7 +143,7 @@ patternProperties: mediatek,pull-up-adv: description: | - Pull up setings for 2 pull resistors, R0 and R1. User can + Pull up settings for 2 pull resistors, R0 and R1. User can configure those special pins. Valid arguments are described as below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml index 61b33b5416f5..7b43e7857281 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml @@ -149,7 +149,7 @@ patternProperties: deprecated: true description: | DEPRECATED: Please use bias-pull-up instead. - Pull up setings for 2 pull resistors, R0 and R1. User can + Pull up settings for 2 pull resistors, R0 and R1. User can configure those special pins. Valid arguments are described as below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml index 065dedb3573a..1690c0ef553a 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml @@ -22,8 +22,6 @@ properties: patternProperties: "^pinmux(-[a-z0-9-_]+)?$": type: object - properties: - phandle: true # pin groups additionalProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml index f924652bef0d..9b7368bd3862 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml @@ -32,8 +32,6 @@ properties: patternProperties: "^pinmux(-[a-z0-9-_]+)?$": type: object - properties: - phandle: true # pin groups additionalProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml index 60a4bdf01bf2..87b6f4f42f25 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml @@ -23,8 +23,6 @@ properties: patternProperties: "^pinmux(-[a-z0-9-_]+)?$": type: object - properties: - phandle: true # pin groups additionalProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml index 432ea40209a8..63cd743a30e0 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml @@ -24,8 +24,6 @@ properties: patternProperties: "^pinmux(-[a-z0-9-_]+)?$": type: object - properties: - phandle: true # pin groups additionalProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml index 28ae2e6d0cbc..e99387a6da5e 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml @@ -22,8 +22,6 @@ properties: patternProperties: "^pinmux(-[a-z0-9-_]+)?$": type: object - properties: - phandle: true # pin groups additionalProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml new file mode 100644 index 000000000000..f3deda9f7127 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux-aon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra234 AON Pinmux Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +$ref: nvidia,tegra234-pinmux-common.yaml + +properties: + compatible: + const: nvidia,tegra234-pinmux-aon + +patternProperties: + "^pinmux(-[a-z0-9-]+)?$": + type: object + + # pin groups + additionalProperties: + properties: + nvidia,pins: + items: + enum: [ can0_dout_paa0, can0_din_paa1, can1_dout_paa2, + can1_din_paa3, can0_stb_paa4, can0_en_paa5, + soc_gpio49_paa6, can0_err_paa7, can1_stb_pbb0, + can1_en_pbb1, soc_gpio50_pbb2, can1_err_pbb3, + spi2_sck_pcc0, spi2_miso_pcc1, spi2_mosi_pcc2, + spi2_cs0_pcc3, touch_clk_pcc4, uart3_tx_pcc5, + uart3_rx_pcc6, gen2_i2c_scl_pcc7, gen2_i2c_sda_pdd0, + gen8_i2c_scl_pdd1, gen8_i2c_sda_pdd2, + sce_error_pee0, vcomp_alert_pee1, + ao_retention_n_pee2, batt_oc_pee3, power_on_pee4, + soc_gpio26_pee5, soc_gpio27_pee6, bootv_ctl_n_pee7, + hdmi_cec_pgg0, + # drive groups + drive_touch_clk_pcc4, drive_uart3_rx_pcc6, + drive_uart3_tx_pcc5, drive_gen8_i2c_sda_pdd2, + drive_gen8_i2c_scl_pdd1, drive_spi2_mosi_pcc2, + drive_gen2_i2c_scl_pcc7, drive_spi2_cs0_pcc3, + drive_gen2_i2c_sda_pdd0, drive_spi2_sck_pcc0, + drive_spi2_miso_pcc1, drive_can1_dout_paa2, + drive_can1_din_paa3, drive_can0_dout_paa0, + drive_can0_din_paa1, drive_can0_stb_paa4, + drive_can0_en_paa5, drive_soc_gpio49_paa6, + drive_can0_err_paa7, drive_can1_stb_pbb0, + drive_can1_en_pbb1, drive_soc_gpio50_pbb2, + drive_can1_err_pbb3, drive_sce_error_pee0, + drive_batt_oc_pee3, drive_bootv_ctl_n_pee7, + drive_power_on_pee4, drive_soc_gpio26_pee5, + drive_soc_gpio27_pee6, drive_ao_retention_n_pee2, + drive_vcomp_alert_pee1, drive_hdmi_cec_pgg0 ] + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/pinctrl-tegra.h> + + pinmux@c300000 { + compatible = "nvidia,tegra234-pinmux-aon"; + reg = <0xc300000 0x4000>; + + pinctrl-names = "cec"; + pinctrl-0 = <&cec_state>; + + cec_state: pinmux-cec { + cec { + nvidia,pins = "hdmi_cec_pgg0"; + nvidia,function = "gp"; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-common.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-common.yaml new file mode 100644 index 000000000000..4f9de78085e5 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-common.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra234 Pinmux Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + reg: + items: + - description: pinmux registers + +patternProperties: + "^pinmux(-[a-z0-9-]+)?$": + type: object + + # pin groups + additionalProperties: + $ref: nvidia,tegra-pinmux-common.yaml + # We would typically use unevaluatedProperties here but that has the + # downside that all the properties in the common bindings become valid + # for all chip generations. In this case, however, we want the per-SoC + # bindings to be able to override which of the common properties are + # allowed, since not all pinmux generations support the same sets of + # properties. This way, the common bindings define the format of the + # properties but the per-SoC bindings define which of them apply to a + # given chip. + additionalProperties: false + properties: + nvidia,function: + enum: [ gp, uartc, i2c8, spi2, i2c2, can1, can0, rsvd0, eth0, eth2, + eth1, dp, eth3, i2c4, i2c7, i2c9, eqos, pe2, pe1, pe0, pe3, + pe4, pe5, pe6, pe7, pe8, pe9, pe10, qspi0, qspi1, qpsi, + sdmmc1, sce, soc, gpio, hdmi, ufs0, spi3, spi1, uartb, uarte, + usb, extperiph2, extperiph1, i2c3, vi0, i2c5, uarta, uartd, + i2c1, i2s4, i2s6, aud, spi5, touch, uartj, rsvd1, wdt, tsc, + dmic3, led, vi0_alt, i2s5, nv, extperiph3, extperiph4, spi4, + ccla, i2s1, i2s2, i2s3, i2s8, rsvd2, dmic5, dca, displayb, + displaya, vi1, dcb, dmic1, dmic4, i2s7, dmic2, dspk0, rsvd3, + tsc_alt, istctrl, vi1_alt, dspk1, igpu ] + + # out of the common properties, only these are allowed for Tegra234 + nvidia,pins: true + nvidia,pull: true + nvidia,tristate: true + nvidia,schmitt: true + nvidia,enable-input: true + nvidia,open-drain: true + nvidia,lock: true + nvidia,drive-type: true + nvidia,io-hv: true + + required: + - nvidia,pins + +required: + - compatible + - reg + +additionalProperties: true +... diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml new file mode 100644 index 000000000000..17b865ecfcda --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml @@ -0,0 +1,139 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra234 Pinmux Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +$ref: nvidia,tegra234-pinmux-common.yaml + +properties: + compatible: + const: nvidia,tegra234-pinmux + +patternProperties: + "^pinmux(-[a-z0-9-]+)?$": + type: object + + # pin groups + additionalProperties: + properties: + nvidia,pins: + items: + enum: [ dap6_sclk_pa0, dap6_dout_pa1, dap6_din_pa2, + dap6_fs_pa3, dap4_sclk_pa4, dap4_dout_pa5, + dap4_din_pa6, dap4_fs_pa7, soc_gpio08_pb0, + qspi0_sck_pc0, qspi0_cs_n_pc1, + qspi0_io0_pc2, qspi0_io1_pc3, qspi0_io2_pc4, + qspi0_io3_pc5, qspi1_sck_pc6, qspi1_cs_n_pc7, + qspi1_io0_pd0, qspi1_io1_pd1, qspi1_io2_pd2, + qspi1_io3_pd3, eqos_txc_pe0, eqos_td0_pe1, + eqos_td1_pe2, eqos_td2_pe3, eqos_td3_pe4, + eqos_tx_ctl_pe5, eqos_rd0_pe6, eqos_rd1_pe7, + eqos_rd2_pf0, eqos_rd3_pf1, eqos_rx_ctl_pf2, + eqos_rxc_pf3, eqos_sma_mdio_pf4, eqos_sma_mdc_pf5, + soc_gpio13_pg0, soc_gpio14_pg1, soc_gpio15_pg2, + soc_gpio16_pg3, soc_gpio17_pg4, soc_gpio18_pg5, + soc_gpio19_pg6, soc_gpio20_pg7, soc_gpio21_ph0, + soc_gpio22_ph1, soc_gpio06_ph2, uart4_tx_ph3, + uart4_rx_ph4, uart4_rts_ph5, uart4_cts_ph6, + soc_gpio41_ph7, soc_gpio42_pi0, soc_gpio43_pi1, + soc_gpio44_pi2, gen1_i2c_scl_pi3, gen1_i2c_sda_pi4, + cpu_pwr_req_pi5, soc_gpio07_pi6, + sdmmc1_clk_pj0, sdmmc1_cmd_pj1, sdmmc1_dat0_pj2, + sdmmc1_dat1_pj3, sdmmc1_dat2_pj4, sdmmc1_dat3_pj5, + pex_l0_clkreq_n_pk0, pex_l0_rst_n_pk1, + pex_l1_clkreq_n_pk2, pex_l1_rst_n_pk3, + pex_l2_clkreq_n_pk4, pex_l2_rst_n_pk5, + pex_l3_clkreq_n_pk6, pex_l3_rst_n_pk7, + pex_l4_clkreq_n_pl0, pex_l4_rst_n_pl1, + pex_wake_n_pl2, soc_gpio34_pl3, dp_aux_ch0_hpd_pm0, + dp_aux_ch1_hpd_pm1, dp_aux_ch2_hpd_pm2, + dp_aux_ch3_hpd_pm3, soc_gpio55_pm4, soc_gpio36_pm5, + soc_gpio53_pm6, soc_gpio38_pm7, dp_aux_ch3_n_pn0, + soc_gpio39_pn1, soc_gpio40_pn2, dp_aux_ch1_p_pn3, + dp_aux_ch1_n_pn4, dp_aux_ch2_p_pn5, dp_aux_ch2_n_pn6, + dp_aux_ch3_p_pn7, extperiph1_clk_pp0, + extperiph2_clk_pp1, cam_i2c_scl_pp2, cam_i2c_sda_pp3, + soc_gpio23_pp4, soc_gpio24_pp5, soc_gpio25_pp6, + pwr_i2c_scl_pp7, pwr_i2c_sda_pq0, soc_gpio28_pq1, + soc_gpio29_pq2, soc_gpio30_pq3, soc_gpio31_pq4, + soc_gpio32_pq5, soc_gpio33_pq6, soc_gpio35_pq7, + soc_gpio37_pr0, soc_gpio56_pr1, uart1_tx_pr2, + uart1_rx_pr3, uart1_rts_pr4, uart1_cts_pr5, + soc_gpio61_pw0, soc_gpio62_pw1, gpu_pwr_req_px0, + cv_pwr_req_px1, gp_pwm2_px2, gp_pwm3_px3, uart2_tx_px4, + uart2_rx_px5, uart2_rts_px6, uart2_cts_px7, spi3_sck_py0, + spi3_miso_py1, spi3_mosi_py2, spi3_cs0_py3, + spi3_cs1_py4, uart5_tx_py5, uart5_rx_py6, + uart5_rts_py7, uart5_cts_pz0, usb_vbus_en0_pz1, + usb_vbus_en1_pz2, spi1_sck_pz3, spi1_miso_pz4, + spi1_mosi_pz5, spi1_cs0_pz6, spi1_cs1_pz7, + spi5_sck_pac0, spi5_miso_pac1, spi5_mosi_pac2, + spi5_cs0_pac3, soc_gpio57_pac4, soc_gpio58_pac5, + soc_gpio59_pac6, soc_gpio60_pac7, soc_gpio45_pad0, + soc_gpio46_pad1, soc_gpio47_pad2, soc_gpio48_pad3, + ufs0_ref_clk_pae0, ufs0_rst_n_pae1, + pex_l5_clkreq_n_paf0, pex_l5_rst_n_paf1, + pex_l6_clkreq_n_paf2, pex_l6_rst_n_paf3, + pex_l7_clkreq_n_pag0, pex_l7_rst_n_pag1, + pex_l8_clkreq_n_pag2, pex_l8_rst_n_pag3, + pex_l9_clkreq_n_pag4, pex_l9_rst_n_pag5, + pex_l10_clkreq_n_pag6, pex_l10_rst_n_pag7, + sdmmc1_comp, eqos_comp, qspi_comp, + # drive groups + drive_soc_gpio08_pb0, drive_soc_gpio36_pm5, + drive_soc_gpio53_pm6, drive_soc_gpio55_pm4, + drive_soc_gpio38_pm7, drive_soc_gpio39_pn1, + drive_soc_gpio40_pn2, drive_dp_aux_ch0_hpd_pm0, + drive_dp_aux_ch1_hpd_pm1, drive_dp_aux_ch2_hpd_pm2, + drive_dp_aux_ch3_hpd_pm3, drive_dp_aux_ch1_p_pn3, + drive_dp_aux_ch1_n_pn4, drive_dp_aux_ch2_p_pn5, + drive_dp_aux_ch2_n_pn6, drive_dp_aux_ch3_p_pn7, + drive_dp_aux_ch3_n_pn0, drive_pex_l2_clkreq_n_pk4, + drive_pex_wake_n_pl2, drive_pex_l1_clkreq_n_pk2, + drive_pex_l1_rst_n_pk3, drive_pex_l0_clkreq_n_pk0, + drive_pex_l0_rst_n_pk1, drive_pex_l2_rst_n_pk5, + drive_pex_l3_clkreq_n_pk6, drive_pex_l3_rst_n_pk7, + drive_pex_l4_clkreq_n_pl0, drive_pex_l4_rst_n_pl1, + drive_soc_gpio34_pl3, drive_pex_l5_clkreq_n_paf0, + drive_pex_l5_rst_n_paf1, drive_pex_l6_clkreq_n_paf2, + drive_pex_l6_rst_n_paf3, drive_pex_l10_clkreq_n_pag6, + drive_pex_l10_rst_n_pag7, drive_pex_l7_clkreq_n_pag0, + drive_pex_l7_rst_n_pag1, drive_pex_l8_clkreq_n_pag2, + drive_pex_l8_rst_n_pag3, drive_pex_l9_clkreq_n_pag4, + drive_pex_l9_rst_n_pag5, drive_sdmmc1_clk_pj0, + drive_sdmmc1_cmd_pj1, drive_sdmmc1_dat3_pj5, + drive_sdmmc1_dat2_pj4, drive_sdmmc1_dat1_pj3, + drive_sdmmc1_dat0_pj2 ] + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/pinctrl-tegra.h> + + pinmux@2430000 { + compatible = "nvidia,tegra234-pinmux"; + reg = <0x2430000 0x17000>; + + pinctrl-names = "pex_rst"; + pinctrl-0 = <&pex_rst_c5_out_state>; + + pex_rst_c5_out_state: pinmux-pex-rst-c5-out { + pexrst { + nvidia,pins = "pex_l5_rst_n_paf1"; + nvidia,schmitt = <TEGRA_PIN_DISABLE>; + nvidia,enable-input = <TEGRA_PIN_DISABLE>; + nvidia,io-hv = <TEGRA_PIN_ENABLE>; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + nvidia,pull = <TEGRA_PIN_PULL_NONE>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml index c0eda7848767..36c8f3301a8f 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml @@ -22,8 +22,6 @@ properties: patternProperties: "^pinmux(-[a-z0-9-_]+)?$": type: object - properties: - phandle: true # pin groups additionalProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt deleted file mode 100644 index b1159434f593..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt +++ /dev/null @@ -1,56 +0,0 @@ -* Oxford Semiconductor OXNAS SoC Family Pin Controller - -Please refer to pinctrl-bindings.txt, ../gpio/gpio.txt, and -../interrupt-controller/interrupts.txt for generic information regarding -pin controller, GPIO, and interrupt bindings. - -OXNAS 'pin configuration node' is a node of a group of pins which can be -used for a specific device or function. This node represents configurations of -pins, optional function, and optional mux related configuration. - -Required properties for pin controller node: - - compatible: "oxsemi,ox810se-pinctrl" or "oxsemi,ox820-pinctrl" - - oxsemi,sys-ctrl: a phandle to the system controller syscon node - -Required properties for pin configuration sub-nodes: - - pins: List of pins to which the configuration applies. - -Optional properties for pin configuration sub-nodes: ----------------------------------------------------- - - function: Mux function for the specified pins. - - bias-pull-up: Enable weak pull-up. - -Example: - -pinctrl: pinctrl { - compatible = "oxsemi,ox810se-pinctrl"; - - /* Regmap for sys registers */ - oxsemi,sys-ctrl = <&sys>; - - pinctrl_uart2: pinctrl_uart2 { - uart2a { - pins = "gpio31"; - function = "fct3"; - }; - uart2b { - pins = "gpio32"; - function = "fct3"; - }; - }; -}; - -uart2: serial@900000 { - compatible = "ns16550a"; - reg = <0x900000 0x100000>; - clocks = <&sysclk>; - interrupts = <29>; - reg-shift = <0>; - fifo-size = <16>; - reg-io-width = <1>; - current-speed = <115200>; - no-loopback-test; - resets = <&reset 22>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_uart2>; -}; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt index 511fc234558b..28fbca180068 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt @@ -38,7 +38,7 @@ Valid values for function properties are: gpio, lpm-control-in, fps-out, 32k-out, sd0-dvs-in, sd1-dvs-in, reference-out -Theres is also customised properties for the GPIO1, GPIO2 and GPIO3. These +There are also customised properties for the GPIO1, GPIO2 and GPIO3. These customised properties are required to configure FPS configuration parameters of these GPIOs. Please refer <devicetree/bindings/mfd/max77620.txt> for more detail of Flexible Power Sequence (FPS). diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt index 939cb5b6ffea..6ad49e51c72e 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt @@ -40,7 +40,7 @@ on default. Valid values for function properties are: gpio. -Theres is also not customised properties for any GPIO. +There are also not customised properties for any GPIO. Example: -------- diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt deleted file mode 100644 index bfd222b05495..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt +++ /dev/null @@ -1,262 +0,0 @@ -One-register-per-pin type device tree based pinctrl driver - -Required properties: -- compatible : "pinctrl-single" or "pinconf-single". - "pinctrl-single" means that pinconf isn't supported. - "pinconf-single" means that generic pinconf is supported. - -- reg : offset and length of the register set for the mux registers - -- #pinctrl-cells : number of cells in addition to the index, set to 1 - or 2 for pinctrl-single,pins and set to 2 for pinctrl-single,bits - -- pinctrl-single,register-width : pinmux register access width in bits - -- pinctrl-single,function-mask : mask of allowed pinmux function bits - in the pinmux register - -Optional properties: -- pinctrl-single,function-off : function off mode for disabled state if - available and same for all registers; if not specified, disabling of - pin functions is ignored - -- pinctrl-single,bit-per-mux : boolean to indicate that one register controls - more than one pin, for which "pinctrl-single,function-mask" property specifies - position mask of pin. - -- pinctrl-single,drive-strength : array of value that are used to configure - drive strength in the pinmux register. They're value of drive strength - current and drive strength mask. - - /* drive strength current, mask */ - pinctrl-single,power-source = <0x30 0xf0>; - -- pinctrl-single,bias-pullup : array of value that are used to configure the - input bias pullup in the pinmux register. - - /* input, enabled pullup bits, disabled pullup bits, mask */ - pinctrl-single,bias-pullup = <0 1 0 1>; - -- pinctrl-single,bias-pulldown : array of value that are used to configure the - input bias pulldown in the pinmux register. - - /* input, enabled pulldown bits, disabled pulldown bits, mask */ - pinctrl-single,bias-pulldown = <2 2 0 2>; - - * Two bits to control input bias pullup and pulldown: User should use - pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. One bit means - pullup, and the other one bit means pulldown. - * Three bits to control input bias enable, pullup and pulldown. User should - use pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. Input bias - enable bit should be included in pullup or pulldown bits. - * Although driver could set PIN_CONFIG_BIAS_DISABLE, there's no property as - pinctrl-single,bias-disable. Because pinctrl single driver could implement - it by calling pulldown, pullup disabled. - -- pinctrl-single,input-schmitt : array of value that are used to configure - input schmitt in the pinmux register. In some silicons, there're two input - schmitt value (rising-edge & falling-edge) in the pinmux register. - - /* input schmitt value, mask */ - pinctrl-single,input-schmitt = <0x30 0x70>; - -- pinctrl-single,input-schmitt-enable : array of value that are used to - configure input schmitt enable or disable in the pinmux register. - - /* input, enable bits, disable bits, mask */ - pinctrl-single,input-schmitt-enable = <0x30 0x40 0 0x70>; - -- pinctrl-single,low-power-mode : array of value that are used to configure - low power mode of this pin. For some silicons, the low power mode will - control the output of the pin when the pad including the pin enter low - power mode. - /* low power mode value, mask */ - pinctrl-single,low-power-mode = <0x288 0x388>; - -- pinctrl-single,gpio-range : list of value that are used to configure a GPIO - range. They're value of subnode phandle, pin base in pinctrl device, pin - number in this range, GPIO function value of this GPIO range. - The number of parameters is depend on #pinctrl-single,gpio-range-cells - property. - - /* pin base, nr pins & gpio function */ - pinctrl-single,gpio-range = <&range 0 3 0>, <&range 3 9 1>; - -- interrupt-controller : standard interrupt controller binding if using - interrupts for wake-up events for example. In this case pinctrl-single - is set up as a chained interrupt controller and the wake-up interrupts - can be requested by the drivers using request_irq(). - -- #interrupt-cells : standard interrupt binding if using interrupts - -This driver assumes that there is only one register for each pin (unless the -pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as -specified in the pinctrl-bindings.txt document in this directory. - -The pin configuration nodes for pinctrl-single are specified as pinctrl -register offset and values using pinctrl-single,pins. Only the bits specified -in pinctrl-single,function-mask are updated. - -When #pinctrl-cells = 1, then setting a pin for a device could be done with: - - pinctrl-single,pins = <0xdc 0x118>; - -Where 0xdc is the offset from the pinctrl register base address for the device -pinctrl register, and 0x118 contains the desired value of the pinctrl register. - -When #pinctrl-cells = 2, then setting a pin for a device could be done with: - - pinctrl-single,pins = <0xdc 0x30 0x07>; - -Where 0x30 is the pin configuration value and 0x07 is the pin mux mode value. -These two values are OR'd together to produce the value stored at offset 0xdc. -See the device example and static board pins example below for more information. - -In case when one register changes more than one pin's mux the -pinctrl-single,bits need to be used which takes three parameters: - - pinctrl-single,bits = <0xdc 0x18 0xff>; - -Where 0xdc is the offset from the pinctrl register base address for the -device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to -be used when applying this change to the register. - - -Optional sub-node: In case some pins could be configured as GPIO in the pinmux -register, those pins could be defined as a GPIO range. This sub-node is required -by pinctrl-single,gpio-range property. - -Required properties in sub-node: -- #pinctrl-single,gpio-range-cells : the number of parameters after phandle in - pinctrl-single,gpio-range property. - - range: gpio-range { - #pinctrl-single,gpio-range-cells = <3>; - }; - - -Example: - -/* SoC common file */ - -/* first controller instance for pins in core domain */ -pmx_core: pinmux@4a100040 { - compatible = "pinctrl-single"; - reg = <0x4a100040 0x0196>; - #address-cells = <1>; - #size-cells = <0>; - #interrupt-cells = <1>; - interrupt-controller; - pinctrl-single,register-width = <16>; - pinctrl-single,function-mask = <0xffff>; -}; - -/* second controller instance for pins in wkup domain */ -pmx_wkup: pinmux@4a31e040 { - compatible = "pinctrl-single"; - reg = <0x4a31e040 0x0038>; - #address-cells = <1>; - #size-cells = <0>; - #interrupt-cells = <1>; - interrupt-controller; - pinctrl-single,register-width = <16>; - pinctrl-single,function-mask = <0xffff>; -}; - -control_devconf0: pinmux@48002274 { - compatible = "pinctrl-single"; - reg = <0x48002274 4>; /* Single register */ - #address-cells = <1>; - #size-cells = <0>; - pinctrl-single,bit-per-mux; - pinctrl-single,register-width = <32>; - pinctrl-single,function-mask = <0x5F>; -}; - -/* third controller instance for pins in gpio domain */ -pmx_gpio: pinmux@d401e000 { - compatible = "pinconf-single"; - reg = <0xd401e000 0x0330>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - pinctrl-single,register-width = <32>; - pinctrl-single,function-mask = <7>; - - /* sparse GPIO range could be supported */ - pinctrl-single,gpio-range = <&range 0 3 0>, <&range 3 9 1>, - <&range 12 1 0>, <&range 13 29 1>, - <&range 43 1 0>, <&range 44 49 1>, - <&range 94 1 1>, <&range 96 2 1>; - - range: gpio-range { - #pinctrl-single,gpio-range-cells = <3>; - }; -}; - - -/* board specific .dts file */ - -&pmx_core { - - /* - * map all board specific static pins enabled by the pinctrl driver - * itself during the boot (or just set them up in the bootloader) - */ - pinctrl-names = "default"; - pinctrl-0 = <&board_pins>; - - board_pins: pinmux_board_pins { - pinctrl-single,pins = < - 0x6c 0xf - 0x6e 0xf - 0x70 0xf - 0x72 0xf - >; - }; - - uart0_pins: pinmux_uart0_pins { - pinctrl-single,pins = < - 0x208 0 /* UART0_RXD (IOCFG138) */ - 0x20c 0 /* UART0_TXD (IOCFG139) */ - >; - pinctrl-single,bias-pulldown = <0 2 2>; - pinctrl-single,bias-pullup = <0 1 1>; - }; - - /* map uart2 pins */ - uart2_pins: pinmux_uart2_pins { - pinctrl-single,pins = < - 0xd8 0x118 - 0xda 0 - 0xdc 0x118 - 0xde 0 - >; - }; -}; - -&control_devconf0 { - mcbsp1_pins: pinmux_mcbsp1_pins { - pinctrl-single,bits = < - 0x00 0x18 0x18 /* FSR/CLKR signal from FSX/CLKX pin */ - >; - }; - - mcbsp2_clks_pins: pinmux_mcbsp2_clks_pins { - pinctrl-single,bits = < - 0x00 0x40 0x40 /* McBSP2 CLKS from McBSP_CLKS pin */ - >; - }; - -}; - -&uart1 { - pinctrl-names = "default"; - pinctrl-0 = <&uart0_pins>; -}; - -&uart2 { - pinctrl-names = "default"; - pinctrl-0 = <&uart2_pins>; -}; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml new file mode 100644 index 000000000000..45a307d3ce16 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml @@ -0,0 +1,207 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/pinctrl-single.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic Pin Controller with a Single Register for One or More Pins + +maintainers: + - Tony Lindgren <tony@atomide.com> + +description: + Some pin controller devices use a single register for one or more pins. The + range of pin control registers can vary from one to many for each controller + instance. Some SoCs from Altera, Broadcom, HiSilicon, Ralink, and TI have this + kind of pin controller instances. + +properties: + compatible: + oneOf: + - enum: + - pinctrl-single + - pinconf-single + - items: + - enum: + - ti,am437-padconf + - ti,am654-padconf + - ti,dra7-padconf + - ti,omap2420-padconf + - ti,omap2430-padconf + - ti,omap3-padconf + - ti,omap4-padconf + - ti,omap5-padconf + - const: pinctrl-single + + reg: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + '#pinctrl-cells': + description: + Number of cells. Usually 2, consisting of register offset, pin configuration + value, and pinmux mode. Some controllers may use 1 for just offset and value. + enum: [ 1, 2 ] + + pinctrl-single,bit-per-mux: + description: Optional flag to indicate register controls more than one pin + type: boolean + + pinctrl-single,function-mask: + description: Mask of the allowed register bits + $ref: /schemas/types.yaml#/definitions/uint32 + + pinctrl-single,function-off: + description: Optional function off mode for disabled state + $ref: /schemas/types.yaml#/definitions/uint32 + + pinctrl-single,register-width: + description: Width of pin specific bits in the register + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 8, 16, 32 ] + + pinctrl-single,gpio-range: + description: Optional list of pin base, nr pins & gpio function + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle of a gpio-range node + - description: pin base + - description: number of pins + - description: gpio function + + '#gpio-range-cells': + description: No longer needed, may exist in older files for gpio-ranges + deprecated: true + const: 3 + + gpio-range: + description: Optional node for gpio range cells + type: object + additionalProperties: false + properties: + '#pinctrl-single,gpio-range-cells': + description: Number of gpio range cells + const: 3 + $ref: /schemas/types.yaml#/definitions/uint32 + +patternProperties: + '-pins(-[0-9]+)?$|-pin$': + description: + Pin group node name using naming ending in -pins followed by an optional + instance number + type: object + additionalProperties: false + + properties: + pinctrl-single,pins: + description: + Array of pins as described in pinmux-node.yaml for pinctrl-pin-array + $ref: /schemas/types.yaml#/definitions/uint32-array + + pinctrl-single,bits: + description: Register bit configuration for pinctrl-single,bit-per-mux + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: register offset + - description: value + - description: pin bitmask in the register + + pinctrl-single,bias-pullup: + description: Optional bias pull up configuration + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: input + - description: enabled pull up bits + - description: disabled pull up bits + - description: bias pull up mask + + pinctrl-single,bias-pulldown: + description: Optional bias pull down configuration + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: input + - description: enabled pull down bits + - description: disabled pull down bits + - description: bias pull down mask + + pinctrl-single,drive-strength: + description: Optional drive strength configuration + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: drive strength current + - description: drive strength mask + + pinctrl-single,input-schmitt: + description: Optional input schmitt configuration + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: input + - description: enable bits + - description: disable bits + - description: input schmitt mask + + pinctrl-single,low-power-mode: + description: Optional low power mode configuration + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: low power mode value + - description: low power mode mask + + pinctrl-single,slew-rate: + description: Optional slew rate configuration + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: slew rate + - description: slew rate mask + +allOf: + - $ref: pinctrl.yaml# + +required: + - compatible + - reg + - pinctrl-single,register-width + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <1>; + #size-cells = <1>; + + pinmux@4a100040 { + compatible = "pinctrl-single"; + reg = <0x4a100040 0x0196>; + #address-cells = <1>; + #size-cells = <0>; + #pinctrl-cells = <2>; + #interrupt-cells = <1>; + interrupt-controller; + pinctrl-single,register-width = <16>; + pinctrl-single,function-mask = <0xffff>; + pinctrl-single,gpio-range = <&range 0 3 0>; + range: gpio-range { + #pinctrl-single,gpio-range-cells = <3>; + }; + + uart2-pins { + pinctrl-single,pins = + <0xd8 0x118>, + <0xda 0>, + <0xdc 0x118>, + <0xde 0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml new file mode 100644 index 000000000000..fad0118fd521 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml @@ -0,0 +1,127 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,ipq5018-tlmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm IPQ5018 TLMM pin controller + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + +description: + Top Level Mode Multiplexer pin controller in Qualcomm IPQ5018 SoC. + +properties: + compatible: + const: qcom,ipq5018-tlmm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + "#interrupt-cells": true + gpio-controller: true + "#gpio-cells": true + gpio-ranges: true + wakeup-parent: true + + gpio-reserved-ranges: + minItems: 1 + maxItems: 24 + + gpio-line-names: + maxItems: 47 + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-ipq5018-tlmm-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-ipq5018-tlmm-state" + additionalProperties: false + +$defs: + qcom-ipq5018-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: + pattern: "^gpio([0-9]|[1-3][0-9]|4[0-6])$" + minItems: 1 + maxItems: 8 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ atest_char, audio_pdm0, audio_pdm1, audio_rxbclk, audio_rxd, + audio_rxfsync, audio_rxmclk, audio_txbclk, audio_txd, + audio_txfsync, audio_txmclk, blsp0_i2c, blsp0_spi, blsp0_uart0, + blsp0_uart1, blsp1_i2c0, blsp1_i2c1, blsp1_spi0, blsp1_spi1, + blsp1_uart0, blsp1_uart1, blsp1_uart2, blsp2_i2c0, blsp2_i2c1, + blsp2_spi, blsp2_spi0, blsp2_spi1, btss, burn0, burn1, cri_trng, + cri_trng0, cri_trng1, cxc_clk, cxc_data, dbg_out, eud_gpio, + gcc_plltest, gcc_tlmm, gpio, led0, led2, mac0, mac1, mdc, mdio, + pcie0_clk, pcie0_wake, pcie1_clk, pcie1_wake, pll_test, + prng_rosc, pwm0, pwm1, pwm2, pwm3, 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, qspi_clk, qspi_cs, + qspi_data, reset_out, sdc1_clk, sdc1_cmd, sdc1_data, wci_txd, + wci_rxd, wsa_swrm, wsi_clk3, wsi_data3, wsis_reset, xfem ] + + required: + - pins + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + tlmm: pinctrl@1000000 { + compatible = "qcom,ipq5018-tlmm"; + reg = <0x01000000 0x300000>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&tlmm 0 0 47>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + + uart-w-state { + rx-pins { + pins = "gpio33"; + function = "blsp1_uart1"; + bias-pull-down; + }; + + tx-pins { + pins = "gpio34"; + function = "blsp1_uart1"; + bias-pull-down; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml index 673713debac2..e5e9962b2174 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml @@ -53,6 +53,7 @@ $defs: 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: @@ -86,19 +87,9 @@ $defs: rx0, rx1, sdc_clk, sdc_cmd, sdc_data, sdc_rclk, tsens_max, wci20, wci21, wsa_swrm ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index eaadd5a9a445..3f8ad07c7cfd 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -26,6 +26,7 @@ properties: - qcom,pm6350-gpio - qcom,pm7250b-gpio - qcom,pm7325-gpio + - qcom,pm7550ba-gpio - qcom,pm8005-gpio - qcom,pm8008-gpio - qcom,pm8018-gpio @@ -49,9 +50,12 @@ properties: - qcom,pm8921-gpio - qcom,pm8941-gpio - qcom,pm8950-gpio + - qcom,pm8953-gpio - qcom,pm8994-gpio - qcom,pm8998-gpio - qcom,pma8084-gpio + - qcom,pmc8180-gpio + - qcom,pmc8180c-gpio - qcom,pmi632-gpio - qcom,pmi8950-gpio - qcom,pmi8994-gpio @@ -67,6 +71,7 @@ properties: - qcom,pms405-gpio - qcom,pmx55-gpio - qcom,pmx65-gpio + - qcom,pmx75-gpio - enum: - qcom,spmi-gpio @@ -171,10 +176,12 @@ allOf: compatible: contains: enum: + - qcom,pm7550ba-gpio - qcom,pm8226-gpio - qcom,pm8350b-gpio - qcom,pm8550ve-gpio - qcom,pm8950-gpio + - qcom,pm8953-gpio - qcom,pmi632-gpio then: properties: @@ -299,6 +306,7 @@ allOf: contains: enum: - qcom,pmx65-gpio + - qcom,pmx75-gpio then: properties: gpio-line-names: @@ -411,6 +419,7 @@ $defs: - gpio1-gpio9 for pm6350 - gpio1-gpio12 for pm7250b - gpio1-gpio10 for pm7325 + - gpio1-gpio8 for pm7550ba - gpio1-gpio4 for pm8005 - gpio1-gpio2 for pm8008 - gpio1-gpio6 for pm8018 @@ -434,6 +443,7 @@ $defs: - gpio1-gpio44 for pm8921 - gpio1-gpio36 for pm8941 - gpio1-gpio8 for pm8950 (hole on gpio3) + - gpio1-gpio8 for pm8953 (hole on gpio3 and gpio6) - gpio1-gpio22 for pm8994 - gpio1-gpio26 for pm8998 - gpio1-gpio22 for pma8084 @@ -453,6 +463,7 @@ $defs: - gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10 and gpio11) - gpio1-gpio16 for pmx65 + - gpio1-gpio16 for pmx75 items: pattern: "^gpio([0-9]+)$" diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml index 032763649336..c323f6d495a4 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml @@ -45,6 +45,7 @@ $defs: 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: @@ -81,19 +82,9 @@ $defs: uim2_data, uim2_present, uim2_reset, usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1 ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml index e608a4f1bcae..e119a226a4b1 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml @@ -87,7 +87,7 @@ $defs: emac0_mdc, emac0_mdio, emac0_ptp_aux, emac0_ptp_pps, emac1_mcg0, emac1_mcg1, emac1_mcg2, emac1_mcg3, emac1_mdc, emac1_mdio, emac1_ptp_aux, emac1_ptp_pps, gcc_gp1, gcc_gp2, gcc_gp3, - gcc_gp4, gcc_gp5, hs0_mi2s, hs1_mi2s, hs2_mi2s, ibi_i3c, + gcc_gp4, gcc_gp5, gpio, hs0_mi2s, hs1_mi2s, hs2_mi2s, ibi_i3c, jitter_bist, mdp0_vsync0, mdp0_vsync1, mdp0_vsync2, mdp0_vsync3, mdp0_vsync4, mdp0_vsync5, mdp0_vsync6, mdp0_vsync7, mdp0_vsync8, mdp1_vsync0, mdp1_vsync1, mdp1_vsync2, mdp1_vsync3, mdp1_vsync4, diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml index fa51fa9536f7..00c5a00e35fc 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml @@ -17,11 +17,6 @@ properties: compatible: const: qcom,sc7280-lpass-lpi-pinctrl - qcom,adsp-bypass-mode: - description: - Tells ADSP is in bypass mode. - type: boolean - reg: maxItems: 2 diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml index 4ae39fc7894a..4bd6d7977d3e 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml @@ -55,6 +55,7 @@ $defs: 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: @@ -104,20 +105,9 @@ $defs: usb1_phy, usb1_sbrx, usb1_sbtx, usb1_usb4, usb2phy_ac, vsense_trigger ] - bias-bus-hold: true - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml index 2ef793ae4038..27319782d94b 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml @@ -85,7 +85,7 @@ $defs: qdss_tracectl_a, dac_calib13, qdss_traceclk_a, dac_calib14, dac_calib15, hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem, dac_calib17, hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto, - dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0, + dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0, pcie_clkreq, dac_calib22, dac_calib23, dac_calib24, tsif1_sync, dac_calib25, sd_write, tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2, qdss_cti, blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, blsp_i2c3, diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml new file mode 100644 index 000000000000..7cb96aa75b08 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sdx75-tlmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SDX75 TLMM block + +maintainers: + - Rohit Agarwal <quic_rohiagar@quicinc.com> + +description: + Top Level Mode Multiplexer pin controller in Qualcomm SDX75 SoC. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,sdx75-tlmm + + reg: + maxItems: 1 + + interrupts: true + interrupt-controller: true + "#interrupt-cells": true + gpio-controller: true + + gpio-reserved-ranges: + minItems: 1 + maxItems: 67 + + gpio-line-names: + maxItems: 133 + + "#gpio-cells": true + gpio-ranges: true + wakeup-parent: true + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-sdx75-tlmm-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-sdx75-tlmm-state" + additionalProperties: false + +$defs: + qcom-sdx75-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-2])$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk, sdc2_cmd, sdc2_data ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + enum: [ adsp_ext, atest_char, audio_ref_clk, bimc_dte, char_exec, coex_uart2, + coex_uart, cri_trng, cri_trng0, cri_trng1, dbg_out_clk, ddr_bist, + ddr_pxi0, ebi0_wrcdc, ebi2_a, ebi2_lcd, ebi2_lcd_te, emac0_mcg, + emac0_ptp, emac1_mcg, emac1_ptp, emac_cdc, emac_pps_in, eth0_mdc, + eth0_mdio, eth1_mdc, eth1_mdio, ext_dbg, gcc_125_clk, gcc_gp1_clk, + gcc_gp2_clk, gcc_gp3_clk, gcc_plltest, gpio, i2s_mclk, jitter_bist, + ldo_en, ldo_update, m_voc, mgpi_clk, native_char, native_tsens, + native_tsense, nav_dr_sync, nav_gpio, pa_indicator, pci_e, + pcie0_clkreq_n, pcie1_clkreq_n, pcie2_clkreq_n, pll_bist_sync, + pll_clk_aux, pll_ref_clk, pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, + qlink0_b_en, qlink0_b_req, qlink0_l_en, qlink0_l_req, qlink0_wmss, + qlink1_l_en, qlink1_l_req, qlink1_wmss, qup_se0, qup_se1_l2_mira, + qup_se1_l2_mirb, qup_se1_l3_mira, qup_se1_l3_mirb, qup_se2, qup_se3, + qup_se4, qup_se5, qup_se6, qup_se7, qup_se8, rgmii_rx_ctl, rgmii_rxc, + rgmii_rxd, rgmii_tx_ctl, rgmii_txc, rgmii_txd, sd_card, sdc1_tb, + sdc2_tb_trig, sec_mi2s, sgmii_phy_intr0_n, sgmii_phy_intr1_n, + spmi_coex, spmi_vgi, tgu_ch0_trigout, tmess_prng0, tmess_prng1, + tmess_prng2, tmess_prng3, tri_mi2s, uim1_clk, uim1_data, uim1_present, + uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset, + usb2phy_ac_en, vsense_trigger_mirnat] + + required: + - pins + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + tlmm: pinctrl@f100000 { + compatible = "qcom,sdx75-tlmm"; + reg = <0x0f100000 0x300000>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&tlmm 0 0 133>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + + gpio-wo-state { + pins = "gpio1"; + function = "gpio"; + }; + + uart-w-state { + rx-pins { + pins = "gpio12"; + function = "qup_se1_l2_mira"; + bias-disable; + }; + + tx-pins { + pins = "gpio13"; + function = "qup_se1_l3_mira"; + bias-disable; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml new file mode 100644 index 000000000000..abac3311fc55 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM6115 SoC LPASS LPI TLMM + +maintainers: + - Konrad Dybcio <konradybcio@kernel.org> + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: + Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem + (LPASS) Low Power Island (LPI) of Qualcomm SM6115 SoC. + +properties: + compatible: + const: qcom,sm6115-lpass-lpi-pinctrl + + reg: + items: + - description: LPASS LPI TLMM Control and Status registers + - description: LPASS LPI MCC registers + + clocks: + items: + - description: LPASS Audio voting clock + + clock-names: + items: + - const: audio + + gpio-controller: true + + "#gpio-cells": + description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h + const: 2 + + gpio-ranges: + maxItems: 1 + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-sm6115-lpass-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-sm6115-lpass-state" + additionalProperties: false + +$defs: + qcom-sm6115-lpass-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: /schemas/pinctrl/pincfg-node.yaml + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + pattern: "^gpio([0-9]|1[0-8])$" + + function: + enum: [ dmic01_clk, dmic01_data, dmic23_clk, dmic23_data, gpio, i2s1_clk, + i2s1_data, i2s1_ws, i2s2_clk, i2s2_data, i2s2_ws, i2s3_clk, + i2s3_data, i2s3_ws, qua_mi2s_data, qua_mi2s_sclk, qua_mi2s_ws, + swr_rx_clk, swr_rx_data, swr_tx_clk, swr_tx_data, wsa_mclk ] + description: + Specify the alternative function to be configured for the specified + pins. + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + default: 2 + description: + Selects the drive strength for the specified pins, in mA. + + slew-rate: + enum: [0, 1, 2, 3] + default: 0 + description: | + 0: No adjustments + 1: Higher Slew rate (faster edges) + 2: Lower Slew rate (slower edges) + 3: Reserved (No adjustments) + + bias-bus-hold: true + bias-pull-down: true + bias-pull-up: true + bias-disable: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + - function + + additionalProperties: false + +allOf: + - $ref: pinctrl.yaml# + +required: + - compatible + - reg + - clocks + - clock-names + - gpio-controller + - "#gpio-cells" + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/sound/qcom,q6afe.h> + + lpass_tlmm: pinctrl@a7c0000 { + compatible = "qcom,sm6115-lpass-lpi-pinctrl"; + reg = <0x0a7c0000 0x20000>, + <0x0a950000 0x10000>; + clocks = <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>; + clock-names = "audio"; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&lpass_tlmm 0 0 19>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml index a57d44efe5bd..ede0f3acad9c 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml @@ -62,6 +62,7 @@ $defs: 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: @@ -102,19 +103,9 @@ $defs: wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk, wsa_data ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml new file mode 100644 index 000000000000..2e65ae08dd21 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml @@ -0,0 +1,143 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM8350 SoC LPASS LPI TLMM + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: + Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem + (LPASS) Low Power Island (LPI) of Qualcomm SM8350 SoC. + +properties: + compatible: + const: qcom,sm8350-lpass-lpi-pinctrl + + reg: + items: + - description: LPASS LPI TLMM Control and Status registers + - description: LPASS LPI MCC registers + + clocks: + items: + - description: LPASS Core voting clock + - description: LPASS Audio voting clock + + clock-names: + items: + - const: core + - const: audio + + gpio-controller: true + + "#gpio-cells": + description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h + const: 2 + + gpio-ranges: + maxItems: 1 + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-sm8350-lpass-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-sm8350-lpass-state" + additionalProperties: false + +$defs: + qcom-sm8350-lpass-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: /schemas/pinctrl/pincfg-node.yaml + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + pattern: "^gpio([0-9]|1[0-9]|2[0-2])$" + + function: + enum: [ dmic1_clk, dmic1_data, dmic2_clk, dmic2_data, dmic3_clk, + dmic3_data, dmic4_clk, dmic4_data, ext_mclk1_a, ext_mclk1_b, + ext_mclk1_c, ext_mclk1_d, ext_mclk1_e, gpio, i2s0_clk, + i2s0_data, i2s0_ws, i2s1_clk, i2s1_data, i2s1_ws, i2s2_clk, + i2s2_data, i2s2_ws, i2s3_clk, i2s3_data, i2s3_ws, i2s4_clk, + i2s4_data, i2s4_ws, slimbus_clk, slimbus_data, swr_rx_clk, + swr_rx_data, swr_tx_clk, swr_tx_data, wsa_swr_clk, + wsa_swr_data, wsa2_swr_clk, wsa2_swr_data ] + description: + Specify the alternative function to be configured for the specified + pins. + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + default: 2 + description: + Selects the drive strength for the specified pins, in mA. + + slew-rate: + enum: [0, 1, 2, 3] + default: 0 + description: | + 0: No adjustments + 1: Higher Slew rate (faster edges) + 2: Lower Slew rate (slower edges) + 3: Reserved (No adjustments) + + bias-bus-hold: true + bias-pull-down: true + bias-pull-up: true + bias-disable: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + - function + + additionalProperties: false + +allOf: + - $ref: pinctrl.yaml# + +required: + - compatible + - reg + - clocks + - clock-names + - gpio-controller + - "#gpio-cells" + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/sound/qcom,q6afe.h> + + lpass_tlmm: pinctrl@33c0000 { + compatible = "qcom,sm8350-lpass-lpi-pinctrl"; + reg = <0x033c0000 0x20000>, + <0x03550000 0x10000>; + + clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>, + <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>; + clock-names = "core", "audio"; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&lpass_tlmm 0 0 15>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml index 0fc3c0f52c19..181cd1676c0a 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml @@ -107,7 +107,6 @@ additionalProperties: Client device subnodes use below standard properties. properties: - phandle: true function: true groups: true pins: true @@ -127,9 +126,6 @@ additionalProperties: additionalProperties: false - type: object - properties: - phandle: true - additionalProperties: $ref: "#/additionalProperties/anyOf/0" diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml index 83800fcf0ce4..2bd7d47d0fdb 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml @@ -108,7 +108,6 @@ additionalProperties: Integers values in "pinmux" argument list are assembled as: ((PORT * 16 + PIN) | MUX_FUNC << 16) - phandle: true input-enable: true output-enable: true @@ -118,9 +117,6 @@ additionalProperties: additionalProperties: false - type: object - properties: - phandle: true - additionalProperties: $ref: "#/additionalProperties/anyOf/0" diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml index 37173a64fed2..8271e7b2c162 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml @@ -37,40 +37,37 @@ properties: gpio-ranges: maxItems: 1 -patternProperties: - "^.*$": - if: - type: object - then: - allOf: - - $ref: pincfg-node.yaml# - - $ref: pinmux-node.yaml# +additionalProperties: + type: object + + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + description: + The child nodes of the pin controller designate pins to be used for + specific peripheral functions or as GPIO. + + A pin multiplexing sub-node describes how to configure a set of + (or a single) pin in some desired alternate function mode. + The values for the pinmux properties are a combination of port name, + pin number and the desired function index. Use the RZA2_PINMUX macro + located in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily + define these. + For assigning GPIO pins, use the macro RZA2_PIN also in + to express the desired port pin. + + properties: + pinmux: description: - The child nodes of the pin controller designate pins to be used for - specific peripheral functions or as GPIO. + Values are constructed from GPIO port number, pin number, and + alternate function configuration number using the RZA2_PINMUX() + helper macro in r7s9210-pinctrl.h. - A pin multiplexing sub-node describes how to configure a set of - (or a single) pin in some desired alternate function mode. - The values for the pinmux properties are a combination of port name, - pin number and the desired function index. Use the RZA2_PINMUX macro - located in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily - define these. - For assigning GPIO pins, use the macro RZA2_PIN also in - to express the desired port pin. + required: + - pinmux - properties: - phandle: true - - pinmux: - description: - Values are constructed from GPIO port number, pin number, and - alternate function configuration number using the RZA2_PINMUX() - helper macro in r7s9210-pinctrl.h. - - required: - - pinmux - - additionalProperties: false + additionalProperties: false allOf: - $ref: pinctrl.yaml# @@ -82,8 +79,6 @@ required: - '#gpio-cells' - gpio-ranges -additionalProperties: false - examples: - | #include <dt-bindings/pinctrl/r7s9210-pinctrl.h> diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml index 9ce1a07fc015..145c5442f268 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -83,7 +83,6 @@ additionalProperties: Client device subnodes use below standard properties. properties: - phandle: true pinmux: description: Values are constructed from GPIO port number, pin number, and @@ -106,9 +105,6 @@ additionalProperties: line-name: true - type: object - properties: - phandle: true - additionalProperties: $ref: "#/additionalProperties/anyOf/0" diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml index 19d4d2facfb4..816688580e33 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml @@ -74,7 +74,6 @@ additionalProperties: offset by 10. Additional identifiers are provided to specify the MDIO source peripheral. - phandle: true bias-disable: true bias-pull-up: description: Pull up the pin with 50 kOhm @@ -91,9 +90,6 @@ additionalProperties: $ref: "#/additionalProperties/anyOf/0" - type: object - properties: - phandle: true - additionalProperties: $ref: "#/additionalProperties/anyOf/0" diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml index c87161f2954f..cb81a17bd0b1 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml @@ -63,7 +63,6 @@ additionalProperties: Client device subnodes use below standard properties. properties: - phandle: true pinmux: description: Values are constructed from GPIO port number, pin number, and @@ -87,9 +86,6 @@ additionalProperties: line-name: true - type: object - properties: - phandle: true - additionalProperties: $ref: "#/additionalProperties/anyOf/0" diff --git a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml index a6f34df82e90..880da721a927 100644 --- a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml @@ -32,7 +32,6 @@ additionalProperties: - $ref: pinmux-node.yaml# properties: - phandle: true function: true groups: true pins: true @@ -49,7 +48,6 @@ additionalProperties: - $ref: pinmux-node.yaml# properties: - phandle: true function: true groups: true pins: true diff --git a/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt index b1cea7a3a071..779b8ef0f6e6 100644 --- a/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt @@ -8,7 +8,7 @@ to configure for some global common configuration, such as domain pad driving level, system control select and so on ("domain pad driving level": One pin can output 3.0v or 1.8v, depending on the related domain pad driving selection, if the related domain pad -slect 3.0v, then the pin can output 3.0v. "system control" is used +select 3.0v, then the pin can output 3.0v. "system control" is used to choose one function (like: UART0) for which system, since we have several systems (AP/CP/CM4) on one SoC.). diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index 1ab0f8dde477..2120ef71a78d 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -27,6 +27,8 @@ properties: - st,stm32mp135-pinctrl - st,stm32mp157-pinctrl - st,stm32mp157-z-pinctrl + - st,stm32mp257-pinctrl + - st,stm32mp257-z-pinctrl '#address-cells': const: 1 @@ -56,7 +58,7 @@ properties: Indicates the SOC package used. More details in include/dt-bindings/pinctrl/stm32-pinfunc.h $ref: /schemas/types.yaml#/definitions/uint32 - enum: [1, 2, 4, 8] + enum: [0x1, 0x2, 0x4, 0x8, 0x100, 0x400, 0x800] patternProperties: '^gpio@[0-9a-f]*$': diff --git a/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt deleted file mode 100644 index 88c80273da91..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt +++ /dev/null @@ -1,13 +0,0 @@ -OMAP Pinctrl definitions - -Required properties: -- compatible : Should be one of: - "ti,omap2420-padconf" - OMAP2420 compatible pinctrl - "ti,omap2430-padconf" - OMAP2430 compatible pinctrl - "ti,omap3-padconf" - OMAP3 compatible pinctrl - "ti,omap4-padconf" - OMAP4 compatible pinctrl - "ti,omap5-padconf" - OMAP5 compatible pinctrl - "ti,dra7-padconf" - DRA7 compatible pinctrl - "ti,am437-padconf" - AM437x compatible pinctrl - -See Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt for further details. diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml index 598a042850b8..b85f9e36ce4b 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx Zynq Pinctrl maintainers: - - Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com> + - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> description: | Please refer to pinctrl-bindings.txt in this directory for details of the diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml index 2722dc7bb03d..01b6f2b57843 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml @@ -7,8 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx ZynqMP Pinctrl maintainers: - - Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com> - - Rajan Vaja <rajan.vaja@xilinx.com> + - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> description: | Please refer to pinctrl-bindings.txt in this directory for details of the @@ -274,6 +273,10 @@ patternProperties: slew-rate: enum: [0, 1] + output-enable: + description: + This will internally disable the tri-state for MIO pins. + drive-strength: description: Selects the drive strength for MIO pins, in mA. diff --git a/Documentation/devicetree/bindings/pmem/pmem-region.txt b/Documentation/devicetree/bindings/pmem/pmem-region.txt index 5cfa4f016a00..cd79975e85ec 100644 --- a/Documentation/devicetree/bindings/pmem/pmem-region.txt +++ b/Documentation/devicetree/bindings/pmem/pmem-region.txt @@ -19,7 +19,7 @@ Required properties: - compatible = "pmem-region" - reg = <base, size>; - The reg property should specificy an address range that is + The reg property should specify an address range that is translatable to a system physical address range. This address range should be mappable as normal system memory would be (i.e cacheable). @@ -30,7 +30,7 @@ Required properties: node implies no special relationship between the two ranges. Optional properties: - - Any relevant NUMA assocativity properties for the target platform. + - Any relevant NUMA associativity properties for the target platform. - volatile; This property indicates that this region is actually backed by non-persistent memory. This lets the OS know that it diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml index eab21bb2050a..d80bbedfe3aa 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml +++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml @@ -12,7 +12,7 @@ maintainers: - Jianxin Pan <jianxin.pan@amlogic.com> description: |+ - Secure Power Domains used in Meson A1/C1/S4 SoCs, and should be the child node + Secure Power Domains used in Meson A1/C1/S4 & C3 SoCs, and should be the child node of secure-monitor. properties: @@ -20,6 +20,7 @@ properties: enum: - amlogic,meson-a1-pwrc - amlogic,meson-s4-pwrc + - amlogic,c3-pwrc "#power-domain-cells": const: 1 diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index f9c211a9a938..9b03c41d3604 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -41,6 +41,7 @@ properties: - qcom,sdm845-rpmhpd - qcom,sdx55-rpmhpd - qcom,sdx65-rpmhpd + - qcom,sdx75-rpmhpd - qcom,sm6115-rpmpd - qcom,sm6125-rpmpd - qcom,sm6350-rpmhpd diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml index 559718997de7..fba6914ec40d 100644 --- a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml +++ b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml @@ -58,7 +58,7 @@ $defs: pd-node: type: object description: - PM domain node representing a PM domain. This node hould be named by + PM domain node representing a PM domain. This node should be named by the real power area name, and thus its name should be unique. properties: diff --git a/Documentation/devicetree/bindings/power/reset/atmel,at91sam9260-shdwc.yaml b/Documentation/devicetree/bindings/power/reset/atmel,at91sam9260-shdwc.yaml new file mode 100644 index 000000000000..f559a2cfd82e --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/atmel,at91sam9260-shdwc.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/atmel,at91sam9260-shdwc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip AT91 SHDWC Shutdown Controller + +maintainers: + - Claudiu Beznea <claudiu.beznea@microchip.com> + +description: | + Microchip AT91 SHDWC shutdown controller controls the power supplies VDDIO + and VDDCORE and the wake-up detection on debounced input lines. + +properties: + compatible: + enum: + - atmel,at91sam9260-shdwc + - atmel,at91sam9rl-shdwc + - atmel,at91sam9x5-shdwc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + atmel,wakeup-mode: + description: operation mode of the wakeup mode + $ref: /schemas/types.yaml#/definitions/string + enum: [ none, high, low, any ] + + atmel,wakeup-counter: + description: counter on wake-up 0 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + + atmel,wakeup-rtt-timer: + description: enable real-time timer wake-up + type: boolean + + atmel,wakeup-rtc-timer: + description: enable real-time clock wake-up + type: boolean + +required: + - compatible + - reg + - clocks + +allOf: + - if: + properties: + compatible: + contains: + const: atmel,at91sam9x5-shdwc + then: + properties: + atmel,wakeup-rtt-timer: false + + - if: + properties: + compatible: + contains: + const: atmel,at91sam9260-shdwc + then: + properties: + atmel,wakeup-rtc-timer: false + +additionalProperties: false + +examples: + - | + shdwc: poweroff@fffffd10 { + compatible = "atmel,at91sam9260-shdwc"; + reg = <0xfffffd10 0x10>; + clocks = <&clk32k>; + }; + +... diff --git a/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml b/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml new file mode 100644 index 000000000000..8c58e12cdb60 --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/atmel,sama5d2-shdwc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip AT91 SAMA5D2 SHDWC Shutdown Controller + +maintainers: + - Claudiu Beznea <claudiu.beznea@microchip.com> + +description: | + Microchip AT91 SHDWC shutdown controller controls the power supplies VDDIO + and VDDCORE and the wake-up detection on debounced input lines. + +properties: + compatible: + oneOf: + - items: + - const: microchip,sama7g5-shdwc + - const: syscon + - enum: + - atmel,sama5d2-shdwc + - microchip,sam9x60-shdwc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + debounce-delay-us: + description: + Minimum wake-up inputs debouncer period in microseconds. It is usually a + board-related property. + + atmel,wakeup-rtc-timer: + description: enable real-time clock wake-up + type: boolean + + atmel,wakeup-rtt-timer: + description: enable real-time timer wake-up + type: boolean + +patternProperties: + "^input@[0-15]$": + description: + Wake-up input nodes. These are usually described in the "board" part of + the Device Tree. Note also that input 0 is linked to the wake-up pin and + is frequently used. + type: object + properties: + reg: + description: contains the wake-up input index + minimum: 0 + maximum: 15 + + atmel,wakeup-active-high: + description: + The corresponding wake-up input described by the child forces the + wake-up of the core power supply on a high level. The default is to + be active low. + type: boolean + + required: + - reg + + additionalProperties: false + +required: + - compatible + - reg + - clocks + +allOf: + - if: + properties: + compatible: + contains: + const: atmel,sama5d2-shdwc + then: + properties: + atmel,wakeup-rtt-timer: false + +additionalProperties: false + +examples: + - | + shdwc: poweroff@f8048010 { + compatible = "atmel,sama5d2-shdwc"; + reg = <0xf8048010 0x10>; + clocks = <&clk32k>; + #address-cells = <1>; + #size-cells = <0>; + atmel,wakeup-rtc-timer; + debounce-delay-us = <976>; + + input@0 { + reg = <0>; + }; + + input@1 { + reg = <1>; + atmel,wakeup-active-high; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.txt b/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.txt deleted file mode 100644 index 93f31ca1ef4b..000000000000 --- a/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.txt +++ /dev/null @@ -1,14 +0,0 @@ -Broadcom Kona Family Reset Manager ----------------------------------- - -The reset manager is used on the Broadcom BCM21664 SoC. - -Required properties: - - compatible: brcm,bcm21664-resetmgr - - reg: memory address & range - -Example: - brcm,resetmgr@35001f00 { - compatible = "brcm,bcm21664-resetmgr"; - reg = <0x35001f00 0x24>; - }; diff --git a/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.yaml b/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.yaml new file mode 100644 index 000000000000..3e28a59d718f --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/brcm,bcm21664-resetmgr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Kona family reset manager + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +properties: + compatible: + const: brcm,bcm21664-resetmgr + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + reset-controller@35001f00 { + compatible = "brcm,bcm21664-resetmgr"; + reg = <0x35001f00 0x24>; + }; +... diff --git a/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml b/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml index 45d66c775115..b54ec003a1e0 100644 --- a/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml +++ b/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/power/reset/gpio-poweroff.yaml# diff --git a/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml b/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml index d3d18e0f5db3..53535de0d41c 100644 --- a/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml +++ b/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/power/reset/gpio-restart.yaml# diff --git a/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.txt deleted file mode 100644 index 752d6126d5da..000000000000 --- a/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.txt +++ /dev/null @@ -1,26 +0,0 @@ -NVMEM reboot mode driver - -This driver gets reboot mode magic value from reboot-mode driver -and stores it in a NVMEM cell named "reboot-mode". Then the bootloader -can read it and take different action according to the magic -value stored. - -Required properties: -- compatible: should be "nvmem-reboot-mode". -- nvmem-cells: A phandle to the reboot mode provided by a nvmem device. -- nvmem-cell-names: Should be "reboot-mode". - -The rest of the properties should follow the generic reboot-mode description -found in reboot-mode.txt - -Example: - reboot-mode { - compatible = "nvmem-reboot-mode"; - nvmem-cells = <&reboot_mode>; - nvmem-cell-names = "reboot-mode"; - - mode-normal = <0xAAAA5501>; - mode-bootloader = <0xBBBB5500>; - mode-recovery = <0xCCCC5502>; - mode-test = <0xDDDD5503>; - }; diff --git a/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.yaml b/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.yaml new file mode 100644 index 000000000000..14a262bcbf7c --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/nvmem-reboot-mode.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic NVMEM reboot mode + +maintainers: + - Bartosz Golaszewski <bartosz.golaszewski@linaro.org> + +description: + This driver gets the reboot mode magic value from the reboot-mode driver + and stores it in the NVMEM cell named "reboot-mode". The bootloader can + then read it and take different action according to the value. + +properties: + compatible: + const: nvmem-reboot-mode + + nvmem-cells: + description: + A phandle pointing to the nvmem-cells node where the vendor-specific + magic value representing the reboot mode is stored. + maxItems: 1 + + nvmem-cell-names: + items: + - const: reboot-mode + +patternProperties: + "^mode-.+": + $ref: /schemas/types.yaml#/definitions/uint32 + description: Vendor-specific mode value written to the mode register + +required: + - compatible + - nvmem-cells + - nvmem-cell-names + +additionalProperties: false + +examples: + - | + reboot-mode { + compatible = "nvmem-reboot-mode"; + nvmem-cells = <&reboot_reason>; + nvmem-cell-names = "reboot-mode"; + mode-recovery = <0x01>; + mode-bootloader = <0x02>; + }; +... diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml index d96170eecbd2..5e460128b0d1 100644 --- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml +++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml @@ -19,6 +19,7 @@ properties: compatible: enum: - qcom,pm8916-pon + - qcom,pm8941-pon - qcom,pms405-pon - qcom,pm8998-pon - qcom,pmk8350-pon @@ -56,7 +57,6 @@ required: unevaluatedProperties: false allOf: - - $ref: reboot-mode.yaml# - if: properties: compatible: @@ -66,12 +66,30 @@ allOf: - qcom,pms405-pon - qcom,pm8998-pon then: + allOf: + - $ref: reboot-mode.yaml# + + properties: + reg: + maxItems: 1 + reg-names: + items: + - const: pon + + # Special case for pm8941, which doesn't store reset mode + - if: + properties: + compatible: + contains: + const: qcom,pm8941-pon + then: properties: reg: maxItems: 1 reg-names: items: - const: pon + - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml index 1f9a2aac53c0..965a834a3dbe 100644 --- a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml +++ b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml @@ -1,10 +1,10 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/power/reset/restart-handler.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Restart and shutdown handler generic binding +title: Restart and shutdown handler Common Properties maintainers: - Sebastian Reichel <sre@kernel.org> diff --git a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml index 11f1f98c1cdc..45792e216981 100644 --- a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml +++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx Zynq MPSoC Power Management maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> description: | The zynqmp-power node describes the power management configurations. diff --git a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml index 82f382a7ffb3..a76afe3ca299 100644 --- a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) # Copyright (C) 2020 Texas Instruments Incorporated %YAML 1.2 --- @@ -68,11 +68,29 @@ properties: Interrupt sends an active low, 256 μs pulse to host to report the charger device status and faults. + ti,no-thermistor: + type: boolean + description: Indicates that no thermistor is connected to the TS pin + required: - compatible - reg - monitored-battery +allOf: + - if: + properties: + compatible: + contains: + enum: + - ti,bq25600 + - ti,bq25601 + - ti,bq25600d + - ti,bq25601d + then: + properties: + ti,no-thermistor: false + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml b/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml new file mode 100644 index 000000000000..277c47e048b6 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/qcom,pmi8998-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm PMI8998/PM660 Switch-Mode Battery Charger "2" + +maintainers: + - Caleb Connolly <caleb.connolly@linaro.org> + +properties: + compatible: + enum: + - qcom,pmi8998-charger + - qcom,pm660-charger + + reg: + maxItems: 1 + + interrupts: + maxItems: 4 + + interrupt-names: + items: + - const: usb-plugin + - const: bat-ov + - const: wdog-bark + - const: usbin-icl-change + + io-channels: + items: + - description: USB in current in uA + - description: USB in voltage in uV + + io-channel-names: + items: + - const: usbin_i + - const: usbin_v + + monitored-battery: + description: phandle to the simple-battery node + $ref: /schemas/types.yaml#/definitions/phandle + +required: + - compatible + - reg + - interrupts + - interrupt-names + - io-channels + - io-channel-names + - monitored-battery + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + pmic { + #address-cells = <1>; + #size-cells = <0>; + #interrupt-cells = <4>; + + charger@1000 { + compatible = "qcom,pmi8998-charger"; + reg = <0x1000>; + + interrupts = <0x2 0x12 0x2 IRQ_TYPE_EDGE_BOTH>, + <0x2 0x13 0x4 IRQ_TYPE_EDGE_BOTH>, + <0x2 0x13 0x6 IRQ_TYPE_EDGE_RISING>, + <0x2 0x16 0x1 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "usb-plugin", "bat-ov", "wdog-bark", "usbin-icl-change"; + + io-channels = <&pmi8998_rradc 3>, + <&pmi8998_rradc 4>; + io-channel-names = "usbin_i", + "usbin_v"; + + monitored-battery = <&battery>; + }; + }; diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml index 756c16d1727d..b5d8888d03d2 100644 --- a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml @@ -26,7 +26,7 @@ required: - compatible - reg -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml new file mode 100644 index 000000000000..5b3edd79a523 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/richtek,rt5033-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT5033 PMIC Battery Charger + +maintainers: + - Jakob Hauser <jahau@rocketmail.com> + +description: + The battery charger of the multifunction device RT5033 has to be instantiated + under sub-node named "charger" using the following format. + +properties: + compatible: + const: richtek,rt5033-charger + + monitored-battery: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + Phandle to the monitored battery according to battery.yaml. The battery + node needs to contain five parameters. + + precharge-current-microamp: + Current of pre-charge mode. The pre-charge current levels are 350 mA + to 650 mA programmed by I2C per 100 mA. + + constant-charge-current-max-microamp: + Current of fast-charge mode. The fast-charge current levels are 700 mA + to 2000 mA programmed by I2C per 100 mA. + + charge-term-current-microamp: + This property is end of charge current. Its level ranges from 150 mA + to 600 mA. Between 150 mA and 300 mA in 50 mA steps, between 300 mA and + 600 mA in 100 mA steps. + + precharge-upper-limit-microvolt: + Voltage of pre-charge mode. If the battery voltage is below the pre-charge + threshold voltage, the charger is in pre-charge mode with pre-charge + current. Its levels are 2.3 V to 3.8 V programmed by I2C per 0.1 V. + + constant-charge-voltage-max-microvolt: + Battery regulation voltage of constant voltage mode. This voltage levels + from 3.65 V to 4.4 V by I2C per 0.025 V. + + richtek,usb-connector: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to a USB connector according to usb-connector.yaml. The connector + should be a child of the extcon device. + +required: + - monitored-battery + +additionalProperties: false + +examples: + - | + charger { + compatible = "richtek,rt5033-charger"; + monitored-battery = <&battery>; + richtek,usb-connector = <&usb_con>; + }; diff --git a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml index 99f506d6b0a0..f255f3858d08 100644 --- a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml +++ b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/power/supply/sbs,sbs-manager.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: SBS compliant manger +title: SBS compliant manager maintainers: - Sebastian Reichel <sre@kernel.org> diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml index 3ce648dd91bd..34b7959d6772 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml @@ -22,6 +22,7 @@ properties: compatible: oneOf: - enum: + - x-powers,axp192-usb-power-supply - x-powers,axp202-usb-power-supply - x-powers,axp221-usb-power-supply - x-powers,axp223-usb-power-supply diff --git a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt deleted file mode 100644 index 54b9f9d0f90f..000000000000 --- a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt +++ /dev/null @@ -1,34 +0,0 @@ ------------------------------------------------------------ -Device Tree Bindings for the Xilinx Zynq MPSoC PM domains ------------------------------------------------------------ -The binding for zynqmp-power-controller follow the common -generic PM domain binding[1]. - -[1] Documentation/devicetree/bindings/power/power-domain.yaml - -== Zynq MPSoC Generic PM Domain Node == - -Required property: - - Below property should be in zynqmp-firmware node. - - #power-domain-cells: Number of cells in a PM domain specifier. Must be 1. - -Power domain ID indexes are mentioned in -include/dt-bindings/power/xlnx-zynqmp-power.h. - -------- -Example -------- - -firmware { - zynqmp_firmware: zynqmp-firmware { - ... - #power-domain-cells = <1>; - ... - }; -}; - -sata { - ... - power-domains = <&zynqmp_firmware 28>; - ... -}; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt index 801c66069121..4787db8de23f 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt @@ -28,6 +28,6 @@ PROPERTIES Snoop ID Port Mapping registers, which are part of the CoreNet Coherency fabric (CCF), provide a CoreNet Coherency Subdomain ID/CoreNet Snoop ID to cpu mapping functions. Certain bits from - these registers should be set if the coresponding CPU should be + these registers should be set if the corresponding CPU should be snooped. This property defines a bitmask which selects the bit that should be set if this cpu should be snooped. diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt index 4b01e1afafda..62744afb5b75 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt @@ -185,10 +185,10 @@ PROPERTIES with distinct functionality. The first register range describes the CoreNet Debug Controller - functionalty to perform transaction and transaction attribute matches. + functionality to perform transaction and transaction attribute matches. The second register range describes the CoreNet Debug Controller - functionalty to trigger event notifications and debug traces. + functionality to trigger event notifications and debug traces. EXAMPLE dcsr-corenet { diff --git a/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt b/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt index 4ad29b9ac2ac..ea902bc5873d 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt @@ -60,7 +60,7 @@ Optional property: - fsl,liodn: Specifies the LIODN to be used for Job Ring. This property is normally set by firmware. Value is of 12-bits which is the LIODN number for this JR. - This property is used by the IOMMU (PAMU) to distinquish + This property is used by the IOMMU (PAMU) to distinguish transactions from this JR and than be able to do address translation & protection accordingly. diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt b/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt index b558585b1aaf..3826bd1219d1 100644 --- a/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt +++ b/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt @@ -42,7 +42,7 @@ Nintendo GameCube device tree - compatible : should be "nintendo,flipper-pic" -1.c) The Digital Signal Procesor (DSP) node +1.c) The Digital Signal Processor (DSP) node Represents the digital signal processor interface, designed to offload audio related tasks. diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt index 3ff6ebbb4998..6f69a9dfe198 100644 --- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt +++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt @@ -53,7 +53,7 @@ Nintendo Wii device tree - compatible : should be "nintendo,flipper-pic" - interrupt-controller -1.c) The Digital Signal Procesor (DSP) node +1.c) The Digital Signal Processor (DSP) node Represents the digital signal processor interface, designed to offload audio related tasks. diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt b/Documentation/devicetree/bindings/pps/pps-gpio.txt deleted file mode 100644 index 9012a2a02e14..000000000000 --- a/Documentation/devicetree/bindings/pps/pps-gpio.txt +++ /dev/null @@ -1,30 +0,0 @@ -Device-Tree Bindings for a PPS Signal on GPIO - -These properties describe a PPS (pulse-per-second) signal connected to -a GPIO pin. - -Required properties: -- compatible: should be "pps-gpio" -- gpios: one PPS GPIO in the format described by ../gpio/gpio.txt - -Additional required properties for the PPS ECHO functionality: -- echo-gpios: one PPS ECHO GPIO in the format described by ../gpio/gpio.txt -- echo-active-ms: duration in ms of the active portion of the echo pulse - -Optional properties: -- assert-falling-edge: when present, assert is indicated by a falling edge - (instead of by a rising edge) - -Example: - pps { - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_pps>; - - gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>; - assert-falling-edge; - - echo-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>; - echo-active-ms = <100>; - - compatible = "pps-gpio"; - }; diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.yaml b/Documentation/devicetree/bindings/pps/pps-gpio.yaml new file mode 100644 index 000000000000..fd4adfa8d2d4 --- /dev/null +++ b/Documentation/devicetree/bindings/pps/pps-gpio.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pps/pps-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PPS Signal via GPIO + +maintainers: + - Fabio Estevam <festevam@gmail.com> + +properties: + compatible: + const: pps-gpio + + gpios: + description: The GPIO that provides the PPS signal. + maxItems: 1 + + echo-gpios: + description: The GPIO that provides the PPS ECHO signal. + maxItems: 1 + + echo-active-ms: + description: Duration in ms of the active portion of the echo pulse. + + assert-falling-edge: + description: Indicates a falling edge assert, when present. Rising edge if absent. + type: boolean + +required: + - compatible + - gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + pps { + compatible = "pps-gpio"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pps>; + gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>; + assert-falling-edge; + echo-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>; + echo-active-ms = <100>; + }; diff --git a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml index ab45df80345d..d84268b59784 100644 --- a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml @@ -11,7 +11,7 @@ maintainers: - Claudiu Beznea <claudiu.beznea@microchip.com> allOf: - - $ref: "pwm.yaml#" + - $ref: pwm.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml index b3da4e629341..c01dff3b7f84 100644 --- a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml @@ -43,6 +43,7 @@ properties: - fsl,imx8mn-pwm - fsl,imx8mp-pwm - fsl,imx8mq-pwm + - fsl,imx8qxp-pwm - const: fsl,imx27-pwm reg: @@ -61,6 +62,9 @@ properties: interrupts: maxItems: 1 + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml index 8e176ba7a525..0fbe8a6469eb 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml @@ -22,6 +22,7 @@ properties: - mediatek,mt7623-pwm - mediatek,mt7628-pwm - mediatek,mt7629-pwm + - mediatek,mt7981-pwm - mediatek,mt7986-pwm - mediatek,mt8183-pwm - mediatek,mt8365-pwm diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml index 0088bc8e7c54..153e146df7d4 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -22,7 +22,9 @@ properties: - mediatek,mt8173-disp-pwm - mediatek,mt8183-disp-pwm - items: - - const: mediatek,mt8167-disp-pwm + - enum: + - mediatek,mt6795-disp-pwm + - mediatek,mt8167-disp-pwm - const: mediatek,mt8173-disp-pwm - items: - enum: diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml index a34cbc13f691..6ffbed204c25 100644 --- a/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml @@ -25,7 +25,7 @@ properties: const: 3 fsl,pwm-number: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the number of PWM devices required: diff --git a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt deleted file mode 100644 index f5753b3f79df..000000000000 --- a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt +++ /dev/null @@ -1,30 +0,0 @@ -BCM2835 PWM controller (Raspberry Pi controller) - -Required properties: -- compatible: should be "brcm,bcm2835-pwm" -- reg: physical base address and length of the controller's registers -- clocks: This clock defines the base clock frequency of the PWM hardware - system, the period and the duty_cycle of the PWM signal is a multiple of - the base period. -- #pwm-cells: Should be 3. See pwm.yaml in this directory for a description of - the cells format. - -Examples: - -pwm@2020c000 { - compatible = "brcm,bcm2835-pwm"; - reg = <0x2020c000 0x28>; - clocks = <&clk_pwm>; - #pwm-cells = <3>; -}; - -clocks { - .... - clk_pwm: pwm { - compatible = "fixed-clock"; - reg = <3>; - #clock-cells = <0>; - clock-frequency = <9200000>; - }; - .... -}; diff --git a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml new file mode 100644 index 000000000000..15e7fd98defc --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/pwm-bcm2835.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: BCM2835 PWM controller (Raspberry Pi controller) + +maintainers: + - Stefan Wahren <stefan.wahren@i2se.com> + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + const: brcm,bcm2835-pwm + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#pwm-cells": + const: 3 + +required: + - compatible + - reg + - clocks + - "#pwm-cells" + +additionalProperties: false + +examples: + - | + pwm@2020c000 { + compatible = "brcm,bcm2835-pwm"; + reg = <0x2020c000 0x28>; + clocks = <&clk_pwm>; + #pwm-cells = <3>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml index fe603fb1b2cc..2162f661ed5a 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml @@ -20,12 +20,17 @@ description: |+ properties: compatible: - enum: - - samsung,s3c2410-pwm # 16-bit, S3C24xx - - samsung,s3c6400-pwm # 32-bit, S3C64xx - - samsung,s5p6440-pwm # 32-bit, S5P64x0 - - samsung,s5pc100-pwm # 32-bit, S5PC100, S5PV210, Exynos4210 rev0 SoCs - - samsung,exynos4210-pwm # 32-bit, Exynos + oneOf: + - enum: + - samsung,s3c2410-pwm # 16-bit, S3C24xx + - samsung,s3c6400-pwm # 32-bit, S3C64xx + - samsung,s5p6440-pwm # 32-bit, S5P64x0 + - samsung,s5pc100-pwm # 32-bit, S5PC100, S5PV210, Exynos4210 rev0 SoCs + - samsung,exynos4210-pwm # 32-bit, Exynos + - items: + - enum: + - samsung,exynosautov9-pwm + - const: samsung,exynos4210-pwm reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/pwm/pwm.yaml b/Documentation/devicetree/bindings/pwm/pwm.yaml index 3c01f85029e5..abd9fa873354 100644 --- a/Documentation/devicetree/bindings/pwm/pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm.yaml @@ -13,7 +13,7 @@ select: false properties: $nodename: - pattern: "^pwm(@.*|-[0-9a-f])*$" + pattern: "^pwm(@.*|-([0-9]|[1-9][0-9]+))?$" "#pwm-cells": description: diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml index 4c8097010687..6b6a302a175c 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml @@ -35,6 +35,7 @@ properties: - renesas,pwm-r8a77980 # R-Car V3H - renesas,pwm-r8a77990 # R-Car E3 - renesas,pwm-r8a77995 # R-Car D3 + - renesas,pwm-r8a779a0 # R-Car V3U - renesas,pwm-r8a779g0 # R-Car V4H - const: renesas,pwm-rcar diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml index 9aabdb373afa..4d0b5964443d 100644 --- a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml +++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml @@ -18,7 +18,7 @@ description: The IP block has a version register so this can be used for detection instead of having to encode the IP version number in the device tree - comaptible. + compatible. allOf: - $ref: pwm.yaml# diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml index 3725348bb235..02f45b5834d0 100644 --- a/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml +++ b/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml @@ -28,75 +28,37 @@ properties: the VSEL pin is assumed to be low. type: boolean - regulators: - type: object - additionalProperties: false + inl1-supply: + description: Handle to the INL1 input supply (REG5-7) - properties: - REG1: - type: object - $ref: /schemas/regulator/regulator.yaml# - unevaluatedProperties: false + inl2-supply: + description: Handle to the INL2 input supply (REG8-9) - properties: - vp1-supply: - description: Handle to the VP1 input supply + inl3-supply: + description: Handle to the INL3 input supply (REG10-12) - REG2: - type: object - $ref: /schemas/regulator/regulator.yaml# - unevaluatedProperties: false + vp1-supply: + description: Handle to the VP1 input supply (REG1) - properties: - vp2-supply: - description: Handle to the VP2 input supply + vp2-supply: + description: Handle to the VP2 input supply (REG2) - REG3: - type: object - $ref: /schemas/regulator/regulator.yaml# - unevaluatedProperties: false + vp3-supply: + description: Handle to the VP3 input supply (REG3) - properties: - vp3-supply: - description: Handle to the VP3 input supply - - REG4: - type: object - $ref: /schemas/regulator/regulator.yaml# - unevaluatedProperties: false + vp4-supply: + description: Handle to the VP4 input supply (REG4) - properties: - vp4-supply: - description: Handle to the VP4 input supply + regulators: + type: object + additionalProperties: false patternProperties: - "^REG[5-7]$": + "^REG([1-9]|1[0-2])$": type: object $ref: /schemas/regulator/regulator.yaml# unevaluatedProperties: false - properties: - inl1-supply: - description: Handle to the INL1 input supply - - "^REG[8-9]$": - type: object - $ref: /schemas/regulator/regulator.yaml# - unevaluatedProperties: false - - properties: - inl2-supply: - description: Handle to the INL2 input supply - - "^REG1[0-2]$": - type: object - $ref: /schemas/regulator/regulator.yaml# - unevaluatedProperties: false - - properties: - inl3-supply: - description: Handle to the INL3 input supply - additionalProperties: false required: diff --git a/Documentation/devicetree/bindings/regulator/adi,max77541-regulator.yaml b/Documentation/devicetree/bindings/regulator/adi,max77541-regulator.yaml new file mode 100644 index 000000000000..9e36d5467b56 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/adi,max77541-regulator.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/adi,max77541-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Buck Converter for MAX77540/MAX77541 + +maintainers: + - Okan Sahin <okan.sahin@analog.com> + +description: | + This is a part of device tree bindings for ADI MAX77540/MAX77541 + + The buck converter is represented as a sub-node of the PMIC node on the device tree. + + The device has two buck regulators. + See also Documentation/devicetree/bindings/mfd/adi,max77541.yaml for + additional information and example. + +patternProperties: + "^buck[12]$": + type: object + $ref: regulator.yaml# + additionalProperties: false + description: | + Buck regulator. + + properties: + regulator-name: true + regulator-always-on: true + regulator-boot-on: true + regulator-min-microvolt: + minimum: 300000 + regulator-max-microvolt: + maximum: 5200000 + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/adi,max77857.yaml b/Documentation/devicetree/bindings/regulator/adi,max77857.yaml new file mode 100644 index 000000000000..d1fa74aca721 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/adi,max77857.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2022 Analog Devices Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/adi,max77857.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices MAX77857 Buck-Boost Converter + +maintainers: + - Ibrahim Tilki <Ibrahim.Tilki@analog.com> + - Okan Sahin <Okan.Sahin@analog.com> + +description: Analog Devices MAX77857 Buck-Boost Converter + +properties: + compatible: + enum: + - adi,max77831 + - adi,max77857 + - adi,max77859 + - adi,max77859a + + reg: + description: I2C address of the device + items: + - enum: [0x66, 0x67, 0x6E, 0x6F] + + interrupts: + maxItems: 1 + + adi,switch-frequency-hz: + description: Switching frequency of the Buck-Boost converter in Hz. + items: + - enum: [1200000, 1500000, 1800000, 2100000] + + adi,rtop-ohms: + description: Top feedback resistor value in ohms for external feedback. + minimum: 150000 + maximum: 330000 + + adi,rbot-ohms: + description: Bottom feedback resistor value in ohms for external feedback. + +dependencies: + adi,rtop-ohms: [ 'adi,rbot-ohms' ] + adi,rbot-ohms: [ 'adi,rtop-ohms' ] + +required: + - compatible + - reg + +allOf: + - $ref: regulator.yaml# + - if: + properties: + compatible: + contains: + enum: + - adi,max77831 + + then: + properties: + adi,switch-frequency-hz: + items: + enum: [1200000, 1500000, 1800000] + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@66 { + reg = <0x66>; + compatible = "adi,max77857"; + interrupt-parent = <&gpio>; + interrupts = <26 IRQ_TYPE_EDGE_FALLING>; + + adi,rtop-ohms = <312000>; + adi,rbot-ohms = <12000>; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/awinic,aw37503.yaml b/Documentation/devicetree/bindings/regulator/awinic,aw37503.yaml new file mode 100644 index 000000000000..c92a881ed60e --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/awinic,aw37503.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/awinic,aw37503.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Awinic AW37503 Voltage Regulator + +maintainers: + - Alec Li <like@awinic.com> + +description: + The AW37503 are dual voltage regulator, designed to support positive/negative + supply for driving TFT-LCD panels. It support software-configurable output + switching and monitoring. The output voltages can be programmed via an I2C + compatible interface. + +properties: + compatible: + const: awinic,aw37503 + + reg: + maxItems: 1 + +patternProperties: + "^out[pn]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single regulator. + + properties: + enable-gpios: + maxItems: 1 + description: + GPIO specifier to enable the GPIO control (on/off) for regulator. + + required: + - regulator-name + +required: + - compatible + - reg + - outp + - outn + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@3e { + compatible = "awinic,aw37503"; + reg = <0x3e>; + + outp { + regulator-name = "outp"; + regulator-boot-on; + regulator-always-on; + enable-gpios = <&gpio 17 GPIO_ACTIVE_LOW>; + }; + + outn { + regulator-name = "outn"; + regulator-boot-on; + regulator-always-on; + enable-gpios = <&gpio 27 GPIO_ACTIVE_LOW>; + }; + }; + }; +... + diff --git a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml index dc626517c2ad..13b3f75f8e5e 100644 --- a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml +++ b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml @@ -95,11 +95,6 @@ properties: Properties for a single BUCK regulator properties: - regulator-name: - pattern: "^BUCK([1-2])$" - description: | - BUCK2 present in DA9122, DA9220, DA9131, DA9132 only - regulator-initial-mode: enum: [ 0, 1, 2, 3 ] description: Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h @@ -122,6 +117,23 @@ required: - reg - regulators +allOf: + - if: + properties: + compatible: + not: + contains: + enum: + - dlg,da9122 + - dlg,da9131 + - dlg,da9132 + - dlg,da9220 + then: + properties: + regulators: + properties: + buck2: false + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/regulator/dlg,slg51000.yaml b/Documentation/devicetree/bindings/regulator/dlg,slg51000.yaml new file mode 100644 index 000000000000..bad140418e49 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/dlg,slg51000.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/dlg,slg51000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dialog Semiconductor SLG51000 Voltage Regulator + +maintainers: + - Eric Jeong <eric.jeong.opensource@diasemi.com> + - Support Opensource <support.opensource@diasemi.com> + +properties: + compatible: + const: dlg,slg51000 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dlg,cs-gpios: + maxItems: 1 + description: + GPIO for chip select + + vin3-supply: + description: + Input supply for ldo3, required if regulator is enabled + + vin4-supply: + description: + Input supply for ldo4, required if regulator is enabled + + vin5-supply: + description: + Input supply for ldo5, required if regulator is enabled + + vin6-supply: + description: + Input supply for ldo6, required if regulator is enabled + + vin7-supply: + description: + Input supply for ldo7, required if regulator is enabled + + regulators: + type: object + additionalProperties: false + + patternProperties: + "^ldo[1-7]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + properties: + enable-gpios: + maxItems: 1 + + required: + - regulator-name + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/regulator/dlg,da9121-regulator.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@75 { + compatible = "dlg,slg51000"; + reg = <0x75>; + dlg,cs-gpios = <&tlmm 69 GPIO_ACTIVE_HIGH>; + vin5-supply = <&vreg_s1f_1p2>; + vin6-supply = <&vreg_s1f_1p2>; + + regulators { + ldo1 { + regulator-name = "slg51000_b_ldo1"; + regulator-min-microvolt = <2400000>; + regulator-max-microvolt = <3300000>; + }; + + ldo2 { + regulator-name = "slg51000_b_ldo2"; + regulator-min-microvolt = <2400000>; + regulator-max-microvolt = <3300000>; + }; + + ldo3 { + regulator-name = "slg51000_b_ldo3"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3750000>; + }; + + ldo4 { + regulator-name = "slg51000_b_ldo4"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3750000>; + }; + + ldo5 { + regulator-name = "slg51000_b_ldo5"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1200000>; + }; + + ldo6 { + regulator-name = "slg51000_b_ldo6"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1200000>; + }; + + ldo7 { + regulator-name = "slg51000_b_ldo7"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3750000>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml index 2e720d152890..0221397eb51e 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml @@ -29,10 +29,12 @@ properties: patternProperties: "^buck[1-4]$": $ref: regulator.yaml# + unevaluatedProperties: false type: object "^ldo[1-4]$": $ref: regulator.yaml# + unevaluatedProperties: false type: object additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml index f3fcfc8be72f..6de5b027f990 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml @@ -21,7 +21,6 @@ properties: regulators: type: object - $ref: regulator.yaml# description: | list of regulators provided by this controller, must be named @@ -39,11 +38,13 @@ properties: ldortc: type: object $ref: regulator.yaml# + unevaluatedProperties: false patternProperties: "^ldo[1-4]$": type: object $ref: regulator.yaml# + unevaluatedProperties: false "^buck[1-4]$": type: object diff --git a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt index 7034cdca54e0..b6384306db5c 100644 --- a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt @@ -8,15 +8,14 @@ Documentation/devicetree/bindings/regulator/regulator.txt. The valid names for regulators are:: BUCK: - buck_vdram1, buck_vcore, buck_vcore_sshub, buck_vpa, buck_vproc11, - buck_vproc12, buck_vgpu, buck_vs2, buck_vmodem, buck_vs1 + buck_vdram1, buck_vcore, buck_vpa, buck_vproc11, buck_vproc12, buck_vgpu, + buck_vs2, buck_vmodem, buck_vs1 LDO: ldo_vdram2, ldo_vsim1, ldo_vibr, ldo_vrf12, ldo_vio18, ldo_vusb, ldo_vcamio, ldo_vcamd, ldo_vcn18, ldo_vfe28, ldo_vsram_proc11, ldo_vcn28, ldo_vsram_others, - ldo_vsram_others_sshub, ldo_vsram_gpu, ldo_vxo22, ldo_vefuse, ldo_vaux18, - ldo_vmch, ldo_vbif28, ldo_vsram_proc12, ldo_vcama1, ldo_vemc, ldo_vio28, ldo_va12, - ldo_vrf18, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_vcama2, ldo_vmc, ldo_vldo28, ldo_vaud28, - ldo_vsim2 + ldo_vsram_gpu, ldo_vxo22, ldo_vefuse, ldo_vaux18, ldo_vmch, ldo_vbif28, + ldo_vsram_proc12, ldo_vcama1, ldo_vemc, ldo_vio28, ldo_va12, ldo_vrf18, + ldo_vcn33, ldo_vcama2, ldo_vmc, ldo_vldo28, ldo_vaud28, ldo_vsim2 Example: @@ -305,15 +304,8 @@ Example: regulator-enable-ramp-delay = <120>; }; - mt6358_vcn33_bt_reg: ldo_vcn33_bt { - regulator-name = "vcn33_bt"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3500000>; - regulator-enable-ramp-delay = <270>; - }; - - mt6358_vcn33_wifi_reg: ldo_vcn33_wifi { - regulator-name = "vcn33_wifi"; + mt6358_vcn33_reg: ldo_vcn33 { + regulator-name = "vcn33"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3500000>; regulator-enable-ramp-delay = <270>; @@ -354,17 +346,5 @@ Example: regulator-max-microvolt = <3100000>; regulator-enable-ramp-delay = <540>; }; - - mt6358_vcore_sshub_reg: buck_vcore_sshub { - regulator-name = "vcore_sshub"; - regulator-min-microvolt = <500000>; - regulator-max-microvolt = <1293750>; - }; - - mt6358_vsram_others_sshub_reg: ldo_vsram_others_sshub { - regulator-name = "vsram_others_sshub"; - regulator-min-microvolt = <500000>; - regulator-max-microvolt = <1293750>; - }; }; }; diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.yaml b/Documentation/devicetree/bindings/regulator/pfuze100.yaml index 67a30b23b92c..0eda44752cdd 100644 --- a/Documentation/devicetree/bindings/regulator/pfuze100.yaml +++ b/Documentation/devicetree/bindings/regulator/pfuze100.yaml @@ -36,6 +36,9 @@ properties: reg: maxItems: 1 + interrupts: + maxItems: 1 + fsl,pfuze-support-disable-sw: $ref: /schemas/types.yaml#/definitions/flag description: | @@ -65,18 +68,22 @@ properties: "^sw([1-4]|[1-4][a-c]|[1-4][a-c][a-c])$": $ref: regulator.yaml# type: object + unevaluatedProperties: false "^vgen[1-6]$": $ref: regulator.yaml# type: object + unevaluatedProperties: false "^vldo[1-4]$": $ref: regulator.yaml# type: object + unevaluatedProperties: false "^(vsnvs|vref|vrefddr|swbst|coin|v33|vccsd)$": $ref: regulator.yaml# type: object + unevaluatedProperties: false additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml b/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml index 7e58471097f8..80ecf938b749 100644 --- a/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml @@ -64,6 +64,7 @@ properties: defined, <100> is assumed, meaning that pwm-dutycycle-range contains values expressed in percent. + $ref: /schemas/types.yaml#/definitions/uint32 default: 100 pwm-dutycycle-range: diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml index 8a08698e3484..b4eb4001eb3d 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml @@ -49,7 +49,7 @@ patternProperties: ".*-supply$": description: Input supply phandle(s) for this node - "^((s|l|lvs)[0-9]*)|(s[1-2][a-b])|(ncp)|(mvs)|(usb-switch)|(hdmi-switch)$": + "^((s|l|lvs)[0-9]*|s[1-2][a-b]|ncp|mvs|usb-switch|hdmi-switch)$": description: List of regulators and its properties $ref: regulator.yaml# unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index b9498504ad79..127a6f39b7f0 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -53,6 +53,7 @@ description: | For PMR735A, smps1 - smps3, ldo1 - ldo7 For PMX55, smps1 - smps7, ldo1 - ldo16 For PMX65, smps1 - smps8, ldo1 - ldo21 + For PMX75, smps1 - smps10, ldo1 - ldo21 properties: compatible: @@ -84,13 +85,14 @@ properties: - qcom,pmr735a-rpmh-regulators - qcom,pmx55-rpmh-regulators - qcom,pmx65-rpmh-regulators + - qcom,pmx75-rpmh-regulators qcom,pmic-id: description: | RPMh resource name suffix used for the regulators found on this PMIC. $ref: /schemas/types.yaml#/definitions/string - enum: [a, b, c, d, e, f, g, h, k] + enum: [a, b, c, d, e, f, g, h, i, j, k, l, m, n] qcom,always-wait-for-ack: description: | @@ -109,6 +111,7 @@ properties: bob: type: object $ref: regulator.yaml# + unevaluatedProperties: false description: BOB regulator node. dependencies: regulator-allow-set-load: [ regulator-allowed-modes ] @@ -117,6 +120,7 @@ patternProperties: "^(smps|ldo|lvs|bob)[0-9]+$": type: object $ref: regulator.yaml# + unevaluatedProperties: false description: smps/ldo regulator nodes(s). dependencies: regulator-allow-set-load: [ regulator-allowed-modes ] @@ -424,10 +428,28 @@ allOf: vdd-l11-l13-supply: true patternProperties: "^vdd-l[1347]-supply$": true - "^vdd-l1[0245789]-supply$": true + "^vdd-l1[024579]-supply$": true "^vdd-l2[01]-supply$": true "^vdd-s[1-8]-supply$": true + - if: + properties: + compatible: + enum: + - qcom,pmx75-rpmh-regulators + then: + properties: + vdd-l2-l18-supply: true + vdd-l4-l16-supply: true + vdd-l5-l6-supply: true + vdd-l8-l9-supply: true + vdd-l11-l13-supply: true + vdd-l20-l21-supply: true + patternProperties: + "^vdd-l[137]-supply$": true + "^vdd-l1[024579]-supply$": true + "^vdd-s([1-9]|10)-supply$": true + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml new file mode 100644 index 000000000000..f02f97d4fdd2 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/qcom,sdm845-refgen-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. REFGEN Regulator + +maintainers: + - Konrad Dybcio <konradybcio@kernel.org> + +description: + The REFGEN (reference voltage generator) regulator provides reference + voltage for on-chip IPs (like PHYs) on some Qualcomm SoCs. + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + oneOf: + - items: + - enum: + - qcom,sc7180-refgen-regulator + - qcom,sc8180x-refgen-regulator + - qcom,sm8150-refgen-regulator + - const: qcom,sdm845-refgen-regulator + + - items: + - enum: + - qcom,sc7280-refgen-regulator + - qcom,sc8280xp-refgen-regulator + - qcom,sm6350-refgen-regulator + - qcom,sm6375-refgen-regulator + - qcom,sm8350-refgen-regulator + - const: qcom,sm8250-refgen-regulator + + - enum: + - qcom,sdm845-refgen-regulator + - qcom,sm8250-refgen-regulator + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + regulator@162f000 { + compatible = "qcom,sm8250-refgen-regulator"; + reg = <0x0162f000 0x84>; + }; +... diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index a8ca8e0b27f8..9ea8ac0786ac 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -110,6 +110,7 @@ patternProperties: "^((s|l|lvs|5vs)[0-9]*)|(boost-bypass)|(bob)$": description: List of regulators and its properties $ref: regulator.yaml# + unevaluatedProperties: false additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml index b1cff3adb21b..89c564dfa5db 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml @@ -14,6 +14,9 @@ description: | regulator will be enabled in situations where the device is required to provide power to the connected peripheral. +allOf: + - $ref: regulator.yaml# + properties: compatible: enum: @@ -25,8 +28,11 @@ properties: required: - compatible + - reg + - regulator-min-microamp + - regulator-max-microamp -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -36,6 +42,8 @@ examples: pm8150b_vbus: usb-vbus-regulator@1100 { compatible = "qcom,pm8150b-vbus-reg"; reg = <0x1100>; + regulator-min-microamp = <500000>; + regulator-max-microamp = <3000000>; }; }; ... diff --git a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt b/Documentation/devicetree/bindings/regulator/regulator-max77620.txt index 1c4bfe786736..bcf788897e44 100644 --- a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt +++ b/Documentation/devicetree/bindings/regulator/regulator-max77620.txt @@ -35,7 +35,7 @@ information for that regulator. The definition for each of these nodes is defined using the standard binding for regulators found at <Documentation/devicetree/bindings/regulator/regulator.txt>. -Theres are also additional properties for SD/LDOs. These additional properties +There are also additional properties for SD/LDOs. These additional properties are required to configure FPS configuration parameters for SDs and LDOs. Please refer <devicetree/bindings/mfd/max77620.txt> for more detail of Flexible Power Sequence (FPS). diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index e158c2d3d3f9..9daf0fc2465f 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -126,7 +126,7 @@ properties: regulator-oc-error-microamp: description: Set over current error limit. This is a limit where part of - the hardware propably is malfunctional and damage prevention is requested. + the hardware probably is malfunctional and damage prevention is requested. Zero can be passed to disable error detection and value '1' indicates that detection should be enabled but limit setting can be omitted. @@ -146,7 +146,7 @@ properties: regulator-ov-error-microvolt: description: Set over voltage error limit. This is a limit where part of - the hardware propably is malfunctional and damage prevention is requested + the hardware probably is malfunctional and damage prevention is requested Zero can be passed to disable error detection and value '1' indicates that detection should be enabled but limit setting can be omitted. Limit is given as microvolt offset from voltage set to regulator. @@ -168,7 +168,7 @@ properties: regulator-uv-error-microvolt: description: Set under voltage error limit. This is a limit where part of - the hardware propably is malfunctional and damage prevention is requested + the hardware probably is malfunctional and damage prevention is requested Zero can be passed to disable error detection and value '1' indicates that detection should be enabled but limit setting can be omitted. Limit is given as microvolt offset from voltage set to regulator. @@ -189,7 +189,7 @@ properties: regulator-temp-error-kelvin: description: Set over temperature error limit. This is a limit where part of - the hardware propably is malfunctional and damage prevention is requested + the hardware probably is malfunctional and damage prevention is requested Zero can be passed to disable error detection and value '1' indicates that detection should be enabled but limit setting can be omitted. diff --git a/Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml b/Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml new file mode 100644 index 000000000000..97cff71d2967 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/renesas,raa215300.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RAA215300 Power Management Integrated Circuit (PMIC) + +maintainers: + - Biju Das <biju.das.jz@bp.renesas.com> + +description: | + The RAA215300 is a high-performance, low-cost 9-channel PMIC designed for + 32-bit and 64-bit MCU and MPU applications. It supports DDR3, DDR3L, DDR4, + and LPDDR4 memory power requirements. The internally compensated regulators, + built-in Real-Time Clock (RTC), 32kHz crystal oscillator, and coin cell + battery charger provide a highly integrated, small footprint power solution + ideal for System-On-Module (SOM) applications. A spread spectrum feature + provides an ease-of-use solution for noise-sensitive audio or RF applications. + + This device exposes two devices via I2C. One for the integrated RTC IP, and + one for everything else. + + Link to datasheet: + https://www.renesas.com/in/en/products/power-power-management/multi-channel-power-management-ics-pmics/ssdsoc-power-management-ics-pmic-and-pmus/raa215300-high-performance-9-channel-pmic-supporting-ddr-memory-built-charger-and-rtc + +properties: + compatible: + enum: + - renesas,raa215300 + + reg: + maxItems: 2 + + reg-names: + items: + - const: main + - const: rtc + + interrupts: + maxItems: 1 + + clocks: + description: | + The clocks are optional. The RTC is disabled, if no clocks are + provided(either xin or clkin). + maxItems: 1 + + clock-names: + description: | + Use xin, if connected to an external crystal. + Use clkin, if connected to an external clock signal. + enum: + - xin + - clkin + +required: + - compatible + - reg + - reg-names + +additionalProperties: false + +examples: + - | + /* 32.768kHz crystal */ + x2: x2-clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + raa215300: pmic@12 { + compatible = "renesas,raa215300"; + reg = <0x12>, <0x6f>; + reg-names = "main", "rtc"; + + clocks = <&x2>; + clock-names = "xin"; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml index d9c23333e157..cd06e957b9db 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml @@ -29,6 +29,7 @@ patternProperties: "^DSV(LCM|P|N)$": type: object $ref: regulator.yaml# + unevaluatedProperties: false description: Properties for single Display Bias Voltage regulator. diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml index edb411be0390..89341fdaa3af 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml @@ -11,7 +11,7 @@ maintainers: description: | The RT5190A integrates 1 channel buck controller, 3 channels high efficiency - synchronous buck converters, 1 LDO, I2C control interface and peripherial + synchronous buck converters, 1 LDO, I2C control interface and peripheral logical control. It also supports mute AC OFF depop sound and quick setting storage while diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml index 358297dd3fb7..e95e046e9ed6 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml @@ -21,6 +21,7 @@ allOf: properties: compatible: enum: + - richtek,rt5733 - richtek,rt5739 reg: diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml index 446ec5127d1f..fec3d396ca50 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml @@ -121,6 +121,7 @@ properties: description: load switch current regulator description. type: object $ref: regulator.yaml# + unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml new file mode 100644 index 000000000000..609c06615bdc --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml @@ -0,0 +1,197 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rtq2208.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RTQ2208 SubPMIC Regulator + +maintainers: + - Alina Yu <alina_yu@richtek.com> + +description: | + RTQ2208 is a highly integrated power converter that offers functional safety dual + multi-configurable synchronous buck converters and two LDOs. + + Bucks support "regulator-allowed-modes" and "regulator-mode". The former defines the permitted + switching operation in normal mode; the latter defines the operation in suspend to RAM mode. + + No matter the RTQ2208 is configured to normal or suspend to RAM mode, there are two switching + operation modes for all buck rails, automatic power saving mode (Auto mode) and forced continuous + conduction mode (FCCM). + + The definition of modes is in the datasheet which is available in below link + and their meaning is:: + 0 - Auto mode for power saving, which reducing the switching frequency at light load condition + to maintain high frequency. + 1 - FCCM to meet the strict voltage regulation accuracy, which keeping constant switching frequency. + + Datasheet will be available soon at + https://www.richtek.com/assets/Products + +properties: + compatible: + enum: + - richtek,rtq2208 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + richtek,mtp-sel-high: + type: boolean + description: + vout register selection based on this boolean value. + false - Using DVS0 register setting to adjust vout + true - Using DVS1 register setting to adjust vout + + regulators: + type: object + additionalProperties: false + + patternProperties: + "^buck-[a-h]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + description for buck-[a-h] regulator. + + properties: + regulator-allowed-modes: + description: + two buck modes in different switching accuracy. + 0 - Auto mode + 1 - FCCM + items: + enum: [0, 1] + + "^ldo[1-2]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + regulator description for ldo[1-2]. + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@10 { + compatible = "richtek,rtq2208"; + reg = <0x10>; + interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>; + richtek,mtp-sel-high; + + regulators { + buck-a { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <2050000>; + regulator-allowed-modes = <0 1>; + regulator-always-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-mode = <1>; + }; + }; + buck-b { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <2050000>; + regulator-allowed-modes = <0 1>; + regulator-always-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-mode = <1>; + }; + }; + buck-c { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <2050000>; + regulator-allowed-modes = <0 1>; + regulator-always-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-mode = <1>; + }; + }; + buck-d { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <2050000>; + regulator-allowed-modes = <0 1>; + regulator-always-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-mode = <1>; + }; + }; + buck-e { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <2050000>; + regulator-allowed-modes = <0 1>; + regulator-always-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-mode = <1>; + }; + }; + buck-f { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <2050000>; + regulator-allowed-modes = <0 1>; + regulator-always-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-mode = <1>; + }; + }; + buck-g { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <2050000>; + regulator-allowed-modes = <0 1>; + regulator-always-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-mode = <1>; + }; + }; + buck-h { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <2050000>; + regulator-allowed-modes = <0 1>; + regulator-always-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-mode = <1>; + }; + }; + ldo1 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-always-on; + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + ldo2 { + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml index e6e5a9a7d940..ef62c618de67 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml @@ -35,6 +35,7 @@ properties: "^(p|n)avdd$": type: object $ref: regulator.yaml# + unevaluatedProperties: false description: | regulator description for pavdd and navdd. diff --git a/Documentation/devicetree/bindings/regulator/slg51000.txt b/Documentation/devicetree/bindings/regulator/slg51000.txt deleted file mode 100644 index aa0733e49b90..000000000000 --- a/Documentation/devicetree/bindings/regulator/slg51000.txt +++ /dev/null @@ -1,88 +0,0 @@ -* Dialog Semiconductor SLG51000 Voltage Regulator - -Required properties: -- compatible : Should be "dlg,slg51000" for SLG51000 -- reg : Specifies the I2C slave address. -- xxx-supply: Input voltage supply regulator for ldo3 to ldo7. - These entries are required if regulators are enabled for a device. - An absence of these properties can cause the regulator registration to fail. - If some of input supply is powered through battery or always-on supply then - also it is required to have these parameters with proper node handle of always - on power supply. - vin3-supply: Input supply for ldo3 - vin4-supply: Input supply for ldo4 - vin5-supply: Input supply for ldo5 - vin6-supply: Input supply for ldo6 - vin7-supply: Input supply for ldo7 - -Optional properties: -- interrupt-parent : Specifies the reference to the interrupt controller. -- interrupts : IRQ line information. -- dlg,cs-gpios : Specify a valid GPIO for chip select - -Sub-nodes: -- regulators : This node defines the settings for the regulators. - The content of the sub-node is defined by the standard binding - for regulators; see regulator.txt. - - The SLG51000 regulators are bound using their names listed below: - ldo1 - ldo2 - ldo3 - ldo4 - ldo5 - ldo6 - ldo7 - -Optional properties for regulators: -- enable-gpios : Specify a valid GPIO for platform control of the regulator. - -Example: - pmic: slg51000@75 { - compatible = "dlg,slg51000"; - reg = <0x75>; - - regulators { - ldo1 { - regulator-name = "ldo1"; - regulator-min-microvolt = <2400000>; - regulator-max-microvolt = <3300000>; - }; - - ldo2 { - regulator-name = "ldo2"; - regulator-min-microvolt = <2400000>; - regulator-max-microvolt = <3300000>; - }; - - ldo3 { - regulator-name = "ldo3"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3750000>; - }; - - ldo4 { - regulator-name = "ldo4"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3750000>; - }; - - ldo5 { - regulator-name = "ldo5"; - regulator-min-microvolt = <500000>; - regulator-max-microvolt = <1200000>; - }; - - ldo6 { - regulator-name = "ldo6"; - regulator-min-microvolt = <500000>; - regulator-max-microvolt = <1200000>; - }; - - ldo7 { - regulator-name = "ldo7"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3750000>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml index 7d53cfa2c288..c9586d277f41 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml @@ -25,8 +25,8 @@ properties: patternProperties: "^(reg11|reg18|usb33)$": type: object - $ref: regulator.yaml# + unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62870.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62870.yaml new file mode 100644 index 000000000000..386989544dac --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/ti,tps62870.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/ti,tps62870.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI TPS62870/TPS62871/TPS62872/TPS62873 voltage regulator + +maintainers: + - Mårten Lindahl <marten.lindahl@axis.com> + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - ti,tps62870 + - ti,tps62871 + - ti,tps62872 + - ti,tps62873 + + reg: + maxItems: 1 + + regulator-initial-mode: + enum: [ 1, 2 ] + description: 1 - Forced PWM mode, 2 - Low power mode + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@41 { + compatible = "ti,tps62873"; + reg = <0x41>; + regulator-name = "+0.75V"; + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1675000>; + regulator-initial-mode = <1>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/regulator/vctrl.txt b/Documentation/devicetree/bindings/regulator/vctrl.txt index 601328d7fdbb..e940377cfd69 100644 --- a/Documentation/devicetree/bindings/regulator/vctrl.txt +++ b/Documentation/devicetree/bindings/regulator/vctrl.txt @@ -21,7 +21,7 @@ Optional properties: margin from the expected value for a given control voltage. On larger voltage decreases this can occur undesiredly since the output voltage does not adjust - inmediately to changes in the control voltage. To + immediately to changes in the control voltage. To avoid this situation the vctrl driver breaks down larger voltage decreases into multiple steps, where each step is within the OVP threshold. diff --git a/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml index 011819c10988..11e378648b3f 100644 --- a/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml +++ b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml @@ -29,11 +29,13 @@ properties: Initial data for the LDO1 regulator. $ref: regulator.yaml# type: object + unevaluatedProperties: false micvdd: description: Initial data for the MICVDD regulator. $ref: regulator.yaml# type: object + unevaluatedProperties: false additionalProperties: true diff --git a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml index 3100cb870170..76e8ca44906a 100644 --- a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml @@ -75,7 +75,7 @@ additionalProperties: false examples: - | remoteproc@1c { - compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc"; + compatible = "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc"; reg = <0x1c 0x8>, <0x38 0x8>; reg-names = "remap", "cpu"; resets = <&media_cpu_reset>; diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml index 0c3910f152d1..30632efdad8b 100644 --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml @@ -20,7 +20,9 @@ properties: - fsl,imx7ulp-cm4 - fsl,imx8mm-cm4 - fsl,imx8mn-cm7 + - fsl,imx8mn-cm7-mmio - fsl,imx8mp-cm7 + - fsl,imx8mp-cm7-mmio - fsl,imx8mq-cm4 - fsl,imx8qm-cm4 - fsl,imx8qxp-cm4 @@ -70,6 +72,11 @@ properties: description: Specify CPU entry address for SCU enabled processor. + fsl,iomuxc-gpr: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to IOMUXC GPR block which provide access to CM7 CPUWAIT bit. + fsl,resource-id: $ref: /schemas/types.yaml#/definitions/uint32 description: @@ -79,6 +86,19 @@ properties: required: - compatible +allOf: + - if: + properties: + compatible: + not: + contains: + enum: + - fsl,imx8mn-cm7-mmio + - fsl,imx8mp-cm7-mmio + then: + properties: + fsl,iomuxc-gpr: false + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index 643ee787a81f..a2b0079de039 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -26,6 +26,7 @@ properties: - qcom,sdm660-adsp-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas + - qcom,sdm845-slpi-pas reg: maxItems: 1 @@ -44,8 +45,13 @@ properties: maxItems: 1 description: Reference to the reserved-memory for the Hexagon core + firmware-name: + maxItems: 1 + description: Firmware name for the Hexagon core + required: - compatible + - memory-region unevaluatedProperties: false @@ -63,6 +69,7 @@ allOf: - qcom,msm8998-adsp-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas + - qcom,sdm845-slpi-pas then: properties: clocks: @@ -104,6 +111,7 @@ allOf: - qcom,msm8998-slpi-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas + - qcom,sdm845-slpi-pas then: properties: interrupts: @@ -160,6 +168,22 @@ allOf: - if: properties: compatible: + enum: + - qcom,sdm845-slpi-pas + then: + properties: + power-domains: + items: + - description: LCX power domain + - description: LMX power domain + power-domain-names: + items: + - const: lcx + - const: lmx + + - if: + properties: + compatible: contains: enum: - qcom,msm8226-adsp-pil diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml index 7b43ad3daa56..e78a89c9ec41 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml @@ -14,9 +14,6 @@ description: related to the remote processor. properties: - $nodename: - const: glink-edge - apr: $ref: /schemas/soc/qcom/qcom,apr.yaml# required: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml index f5a044e20c4e..884158bccd50 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml @@ -84,7 +84,7 @@ examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> - rpm-glink { + glink-edge { compatible = "qcom,glink-rpm"; interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>; mboxes = <&apcs_glb 0>; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml index c1ac6ca1e759..0643faae2c39 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml @@ -19,6 +19,7 @@ properties: enum: - qcom,msm8996-mss-pil - qcom,msm8998-mss-pil + - qcom,sdm660-mss-pil - qcom,sdm845-mss-pil reg: @@ -215,13 +216,12 @@ allOf: - description: GCC MSS IFACE clock - description: GCC MSS BUS clock - description: GCC MSS MEM clock - - description: RPMH XO clock + - description: RPM XO clock - description: GCC MSS GPLL0 clock - description: GCC MSS SNOC_AXI clock - description: GCC MSS MNOC_AXI clock - - description: RPMH PNOC clock - - description: GCC MSS PRNG clock - - description: RPMH QDSS clock + - description: RPM PNOC clock + - description: RPM QDSS clock clock-names: items: - const: iface @@ -245,7 +245,9 @@ allOf: - if: properties: compatible: - const: qcom,msm8998-mss-pil + enum: + - qcom,msm8998-mss-pil + - qcom,sdm660-mss-pil then: properties: clocks: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml index 171ef85de193..63a82e7a8bf8 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml @@ -82,7 +82,6 @@ required: - clock-names - interrupts - interrupt-names - - memory-region - qcom,smem-states - qcom,smem-state-names diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml index 5efa0e5c0439..eb868a7ff4cd 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml @@ -42,7 +42,7 @@ properties: smd-edge: false memory-region: - minItems: 1 + maxItems: 1 description: Reference to the reserved-memory for the Hexagon core firmware-name: @@ -52,6 +52,7 @@ properties: required: - compatible - reg + - memory-region allOf: - $ref: /schemas/remoteproc/qcom,pas-common.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml new file mode 100644 index 000000000000..7afafde17a38 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml @@ -0,0 +1,171 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,rpm-proc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Resource Power Manager (RPM) Processor/Subsystem + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + - Konrad Dybcio <konrad.dybcio@linaro.org> + - Stephan Gerhold <stephan@gerhold.net> + +description: | + Resource Power Manager (RPM) subsystem found in various Qualcomm platforms: + + +--------------------------------------------+ + | RPM subsystem (qcom,rpm-proc) | + | | + reset | +---------------+ +-----+ +-----+ | + --------->| | | MPM | | CPR | ... | + IPC interrupts | | ARM Cortex-M3 |--- +-----+ +-----+ | + ----------------->| | | | | | + | +---------------+ |---------------------- | + | +---------------+ | | + | | Code RAM |--| +------------------+ | + | +---------------+ | | | | + | +---------------+ |--| Message RAM | | + | | Data RAM |--| | | | + | +---------------+ | +------------------+ | + +--------------------|-----------------------+ + v + NoC + + The firmware running on the processor inside the RPM subsystem allows each + component in the system to vote for state of the system resources, such as + clocks, regulators and bus frequencies. It implements multiple separate + communication interfaces that are described in subnodes, e.g. SMD and MPM: + + +------------------------------+ + | ARM Cortex-M3 | + | | +------------------------------+ + | +--------------------------+ | | Message RAM | + | | RPM firmware | | | | + IPC IRQ 0 | | +----------------------+ | | | +--------------------------+ | + -------------->| SMD server |<------->| SMD data structures | | + | | | +--------------+ | | | | | +--------------+ | | + | | | | rpm_requests | ... | | | | | | rpm_requests | ... | | + | | | +--------------+ | | | | | +--------------+ | | + IPC IRQ 1 | | +----------------------+ | | | +--------------------------+ | + -------------->| MPM virtualization |<--------| MPM register copy (vMPM) | | + | | +----------------------+ | | | +--------------------------+ | + | | ... | | | | ... | + | +--------------------|-----+ | +------------------------------+ + +----------------------|-------+ + v + +--------------+ + | MPM Hardware | + +--------------+ + + The services provided by the firmware are only available after the firmware + has been loaded and the processor has been released from reset. Usually this + happens early in the boot process before the operating system is started. + +properties: + compatible: + items: + - enum: + - qcom,apq8084-rpm-proc + - qcom,ipq6018-rpm-proc + - qcom,ipq9574-rpm-proc + - qcom,mdm9607-rpm-proc + - qcom,msm8226-rpm-proc + - qcom,msm8610-rpm-proc + - qcom,msm8909-rpm-proc + - qcom,msm8916-rpm-proc + - qcom,msm8917-rpm-proc + - qcom,msm8936-rpm-proc + - qcom,msm8937-rpm-proc + - qcom,msm8952-rpm-proc + - qcom,msm8953-rpm-proc + - qcom,msm8974-rpm-proc + - qcom,msm8976-rpm-proc + - qcom,msm8994-rpm-proc + - qcom,msm8996-rpm-proc + - qcom,msm8998-rpm-proc + - qcom,qcm2290-rpm-proc + - qcom,qcs404-rpm-proc + - qcom,sdm660-rpm-proc + - qcom,sm6115-rpm-proc + - qcom,sm6125-rpm-proc + - qcom,sm6375-rpm-proc + - const: qcom,rpm-proc + + smd-edge: + $ref: /schemas/remoteproc/qcom,smd-edge.yaml# + description: + Qualcomm Shared Memory subnode which represents communication edge, + channels and devices related to the RPM subsystem. + + glink-edge: + $ref: /schemas/remoteproc/qcom,glink-rpm-edge.yaml# + description: + Qualcomm G-Link subnode which represents communication edge, + channels and devices related to the RPM subsystem. + + interrupt-controller: + type: object + $ref: /schemas/interrupt-controller/qcom,mpm.yaml# + description: + MSM Power Manager (MPM) interrupt controller that monitors interrupts + when the system is asleep. + + master-stats: + $ref: /schemas/soc/qcom/qcom,rpm-master-stats.yaml# + description: + Subsystem-level low-power mode statistics provided by RPM. + +required: + - compatible + +oneOf: + - required: + - smd-edge + - required: + - glink-edge + +additionalProperties: false + +examples: + # SMD + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + remoteproc { + compatible = "qcom,msm8916-rpm-proc", "qcom,rpm-proc"; + + smd-edge { + interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>; + qcom,ipc = <&apcs 8 0>; + qcom,smd-edge = <15>; + + rpm-requests { + compatible = "qcom,rpm-msm8916"; + qcom,smd-channels = "rpm_requests"; + /* ... */ + }; + }; + }; + # GLINK + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + remoteproc { + compatible = "qcom,qcm2290-rpm-proc", "qcom,rpm-proc"; + + glink-edge { + compatible = "qcom,glink-rpm"; + interrupts = <GIC_SPI 194 IRQ_TYPE_EDGE_RISING>; + qcom,rpm-msg-ram = <&rpm_msg_ram>; + mboxes = <&apcs_glb 0>; + + rpm-requests { + compatible = "qcom,rpm-qcm2290"; + qcom,glink-channels = "rpm_requests"; + /* ... */ + }; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml index 5cefd2c58593..689d5d535331 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml @@ -51,7 +51,7 @@ properties: - const: mss memory-region: - minItems: 1 + maxItems: 1 description: Reference to the reserved-memory for the Hexagon core qcom,qmp: @@ -67,6 +67,7 @@ properties: required: - compatible - reg + - memory-region allOf: - $ref: /schemas/remoteproc/qcom,pas-common.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml index c1f8dd8d0e4c..4744a37b2b5d 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml @@ -38,7 +38,7 @@ properties: smd-edge: false memory-region: - minItems: 1 + maxItems: 1 description: Reference to the reserved-memory for the Hexagon core firmware-name: @@ -48,6 +48,7 @@ properties: required: - compatible - reg + - memory-region allOf: - $ref: /schemas/remoteproc/qcom,pas-common.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml index f6fbc531dc28..96d53baf6e00 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml @@ -38,7 +38,7 @@ properties: smd-edge: false memory-region: - minItems: 1 + maxItems: 1 description: Reference to the reserved-memory for the Hexagon core firmware-name: @@ -48,6 +48,7 @@ properties: required: - compatible - reg + - memory-region allOf: - $ref: /schemas/remoteproc/qcom,pas-common.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml index c66e298462c7..5d463272165f 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml @@ -46,7 +46,7 @@ properties: - const: mss memory-region: - minItems: 1 + maxItems: 1 description: Reference to the reserved-memory for the Hexagon core qcom,qmp: @@ -62,6 +62,7 @@ properties: required: - compatible - reg + - memory-region allOf: - $ref: /schemas/remoteproc/qcom,pas-common.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml index f5d1fa9f45f1..028287235912 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml @@ -15,10 +15,19 @@ description: properties: compatible: - enum: - - qcom,sm6115-adsp-pas - - qcom,sm6115-cdsp-pas - - qcom,sm6115-mpss-pas + oneOf: + - enum: + - qcom,sm6115-adsp-pas + - qcom,sm6115-cdsp-pas + - qcom,sm6115-mpss-pas + + - items: + - const: qcom,qcm2290-adsp-pas + - const: qcom,sm6115-adsp-pas + + - items: + - const: qcom,qcm2290-mpss-pas + - const: qcom,sm6115-mpss-pas reg: maxItems: 1 @@ -32,7 +41,7 @@ properties: - const: xo memory-region: - minItems: 1 + maxItems: 1 description: Reference to the reserved-memory for the Hexagon core smd-edge: false @@ -44,15 +53,17 @@ properties: required: - compatible - reg + - memory-region allOf: - $ref: /schemas/remoteproc/qcom,pas-common.yaml# - if: properties: compatible: - enum: - - qcom,sm6115-adsp-pas - - qcom,sm6115-cdsp-pas + contains: + enum: + - qcom,sm6115-adsp-pas + - qcom,sm6115-cdsp-pas then: properties: interrupts: @@ -69,9 +80,10 @@ allOf: - if: properties: compatible: - enum: - - qcom,sm6115-cdsp-pas - - qcom,sm6115-mpss-pas + contains: + enum: + - qcom,sm6115-cdsp-pas + - qcom,sm6115-mpss-pas then: properties: power-domains: @@ -84,8 +96,9 @@ allOf: - if: properties: compatible: - enum: - - qcom,sm6115-adsp-pas + contains: + enum: + - qcom,sm6115-adsp-pas then: properties: power-domains: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml index fee02fa800b5..f7e40fb166da 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml @@ -36,7 +36,7 @@ properties: description: Reference to the AOSS side-channel message RAM. memory-region: - minItems: 1 + maxItems: 1 description: Reference to the reserved-memory for the Hexagon core smd-edge: false @@ -48,6 +48,7 @@ properties: required: - compatible - reg + - memory-region allOf: - $ref: /schemas/remoteproc/qcom,pas-common.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml index 2c085ac2c3fb..238c6e5e67c5 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml @@ -40,7 +40,7 @@ properties: description: Reference to the AOSS side-channel message RAM. memory-region: - minItems: 1 + maxItems: 1 description: Reference to the reserved-memory for the Hexagon core smd-edge: false @@ -52,6 +52,7 @@ properties: required: - compatible - reg + - memory-region allOf: - $ref: /schemas/remoteproc/qcom,pas-common.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml index af24f9a3cdf1..53cea8e53a31 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml @@ -43,7 +43,7 @@ properties: smd-edge: false memory-region: - minItems: 1 + maxItems: 1 description: Reference to the reserved-memory for the Hexagon core firmware-name: @@ -53,6 +53,7 @@ properties: required: - compatible - reg + - memory-region allOf: - $ref: /schemas/remoteproc/qcom,pas-common.yaml# @@ -139,7 +140,7 @@ examples: #include <dt-bindings/clock/qcom,rpmh.h> #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/mailbox/qcom-ipcc.h> - #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> remoteproc@30000000 { compatible = "qcom,sm8450-adsp-pas"; @@ -160,8 +161,8 @@ examples: memory-region = <&adsp_mem>; - power-domains = <&rpmhpd SM8450_LCX>, - <&rpmhpd SM8450_LMX>; + power-domains = <&rpmhpd RPMHPD_LCX>, + <&rpmhpd RPMHPD_LMX>; power-domain-names = "lcx", "lmx"; qcom,qmp = <&aoss_qmp>; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml index fe216aa531ed..58120829fb06 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml @@ -53,6 +53,7 @@ properties: required: - compatible - reg + - memory-region allOf: - $ref: /schemas/remoteproc/qcom,pas-common.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index 959a56f1b6c7..370af61d8f28 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -25,7 +25,14 @@ properties: maxItems: 3 resets: - maxItems: 1 + minItems: 1 + maxItems: 2 + + reset-names: + items: + - const: mcu_rst + - const: hold_boot + minItems: 1 st,syscfg-holdboot: description: remote processor reset hold boot @@ -37,6 +44,7 @@ properties: - description: The field mask of the hold boot st,syscfg-tz: + deprecated: true description: Reference to the system configuration which holds the RCC trust zone mode $ref: /schemas/types.yaml#/definitions/phandle-array @@ -135,22 +143,48 @@ required: - compatible - reg - resets - - st,syscfg-holdboot - - st,syscfg-tz + +allOf: + - if: + properties: + reset-names: + not: + contains: + const: hold_boot + then: + required: + - st,syscfg-holdboot + else: + properties: + st,syscfg-holdboot: false additionalProperties: false examples: - | #include <dt-bindings/reset/stm32mp1-resets.h> - m4_rproc: m4@10000000 { + m4@10000000 { compatible = "st,stm32mp1-m4"; reg = <0x10000000 0x40000>, <0x30000000 0x40000>, <0x38000000 0x10000>; resets = <&rcc MCU_R>; + reset-names = "mcu_rst"; + /* Hold boot managed using system config*/ st,syscfg-holdboot = <&rcc 0x10C 0x1>; - st,syscfg-tz = <&rcc 0x000 0x1>; + st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>; + st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>; + }; + - | + #include <dt-bindings/reset/stm32mp1-resets.h> + m4@10000000 { + compatible = "st,stm32mp1-m4"; + reg = <0x10000000 0x40000>, + <0x30000000 0x40000>, + <0x38000000 0x10000>; + /* Hold boot managed using SCMI reset controller */ + resets = <&scmi MCU_R>, <&scmi MCU_HOLD_BOOT_R>; + reset-names = "mcu_rst", "hold_boot"; st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>; st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>; }; diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml index f16e90380df1..9768db8663eb 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml index fcc3db97fe8f..a492f74a8608 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/remoteproc/ti,k3-r5f-rproc.yaml# @@ -102,7 +102,7 @@ patternProperties: caches. Each of the TCMs can be enabled or disabled independently and either of them can be configured to appear at that R5F's address 0x0. - The cores do not use an MMU, but has a Region Address Translater + The cores do not use an MMU, but has a Region Address Translator (RAT) module that is accessible only from the R5Fs for providing translations between 32-bit CPU addresses into larger system bus addresses. Cache and memory access settings are provided through a diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml index 1fdc2741c36e..94eb2033e79c 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/remoteproc/ti,omap-remoteproc.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml index c6d86964b72a..2811334515d1 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml @@ -1,10 +1,10 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Common TI PRU Consumer Binding +title: TI PRU Consumer Common Properties maintainers: - Suman Anna <s-anna@ti.com> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml index cd55d80137f7..baccd98754a9 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/remoteproc/ti,pru-rproc.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml index 9f677367dd9f..78aac69f1060 100644 --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/remoteproc/xlnx,zynqmp-r5fss.yaml# diff --git a/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml b/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml index 05b6648b3458..851ec24d6142 100644 --- a/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/reserved-memory/framebuffer.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: /reserved-memory framebuffer node bindings +title: /reserved-memory framebuffer node maintainers: - devicetree-spec@vger.kernel.org diff --git a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml new file mode 100644 index 000000000000..f9b2f0fdc282 --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra CPU-NS - BPMP IPC reserved memory + +maintainers: + - Peter De Schrijver <pdeschrijver@nvidia.com> + +description: | + Define a memory region used for communication between CPU-NS and BPMP. + Typically this node is created by the bootloader as the physical address + has to be known to both CPU-NS and BPMP for correct IPC operation. + The memory region is defined using a child node under /reserved-memory. + The sub-node is named shmem@<address>. + +allOf: + - $ref: reserved-memory.yaml + +properties: + compatible: + const: nvidia,tegra264-bpmp-shmem + + reg: + description: The physical address and size of the shared SDRAM region + +unevaluatedProperties: false + +required: + - compatible + - reg + - no-map + +examples: + - | + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + dram_cpu_bpmp_mail: shmem@f1be0000 { + compatible = "nvidia,tegra264-bpmp-shmem"; + reg = <0x0 0xf1be0000 0x0 0x2000>; + no-map; + }; + }; +... diff --git a/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml b/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml index 4379cec6b35a..761c70cf9ddf 100644 --- a/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml +++ b/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Altera SOCFPGA Reset Manager maintainers: - - Dinh Nguyen <dinguyen@altera.com> + - Dinh Nguyen <dinguyen@kernel.org> properties: compatible: @@ -32,9 +32,17 @@ properties: required: - compatible - reg - - altr,modrst-offset - '#reset-cells' +if: + properties: + compatible: + contains: + const: altr,stratix10-rst-mgr +then: + properties: + altr,modrst-offset: false + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml new file mode 100644 index 000000000000..34c5c1c08ec1 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton MA35D1 Reset Controller + +maintainers: + - Chi-Fang Li <cfli0@nuvoton.com> + - Jacky Huang <ychuang3@nuvoton.com> + +description: + The system reset controller can be used to reset various peripheral + controllers in MA35D1 SoC. + +properties: + compatible: + items: + - const: nuvoton,ma35d1-reset + + reg: + maxItems: 1 + + '#reset-cells': + const: 1 + +required: + - compatible + - reg + - '#reset-cells' + +additionalProperties: false + +examples: + # system reset controller node: + - | + + system-management@40460000 { + compatible = "nuvoton,ma35d1-reset"; + reg = <0x40460000 0x200>; + #reset-cells = <1>; + }; +... + diff --git a/Documentation/devicetree/bindings/reset/oxnas,reset.txt b/Documentation/devicetree/bindings/reset/oxnas,reset.txt deleted file mode 100644 index d27ccb5d04fc..000000000000 --- a/Documentation/devicetree/bindings/reset/oxnas,reset.txt +++ /dev/null @@ -1,32 +0,0 @@ -Oxford Semiconductor OXNAS SoC Family RESET Controller -================================================ - -Please also refer to reset.txt in this directory for common reset -controller binding usage. - -Required properties: -- compatible: For OX810SE, should be "oxsemi,ox810se-reset" - For OX820, should be "oxsemi,ox820-reset" -- #reset-cells: 1, see below - -Parent node should have the following properties : -- compatible: For OX810SE, should be : - "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd" - For OX820, should be : - "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd" - -Reset indices are in dt-bindings include files : -- For OX810SE: include/dt-bindings/reset/oxsemi,ox810se.h -- For OX820: include/dt-bindings/reset/oxsemi,ox820.h - -example: - -sys: sys-ctrl@000000 { - compatible = "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"; - reg = <0x000000 0x100000>; - - reset: reset-controller { - compatible = "oxsemi,ox810se-reset"; - #reset-cells = <1>; - }; -}; diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml index dcf9206e12be..e10eb98eddad 100644 --- a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml +++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/reset/ti,sci-reset.yaml# diff --git a/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml b/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml index f436f2cf1df7..6063784f0352 100644 --- a/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml +++ b/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/reset/ti,tps380x-reset.yaml# diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt index 86945502ccb5..61a0ff33e89f 100644 --- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt +++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt @@ -43,7 +43,7 @@ Required properties: Cell #6 : bit position of the reset in the reset status register Cell #7 : Flags used to control reset behavior, - availible flags defined in the DT include + available flags defined in the DT include file <dt-bindings/reset/ti-syscon.h> SysCon Reset Consumer Nodes diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt deleted file mode 100644 index ed836868dbf1..000000000000 --- a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt +++ /dev/null @@ -1,55 +0,0 @@ --------------------------------------------------------------------------- - = Zynq UltraScale+ MPSoC and Versal reset driver binding = --------------------------------------------------------------------------- -The Zynq UltraScale+ MPSoC and Versal has several different resets. - -See Chapter 36 of the Zynq UltraScale+ MPSoC TRM (UG) for more information -about zynqmp resets. - -Please also refer to reset.txt in this directory for common reset -controller binding usage. - -Required Properties: -- compatible: "xlnx,zynqmp-reset" for Zynq UltraScale+ MPSoC platform - "xlnx,versal-reset" for Versal platform -- #reset-cells: Specifies the number of cells needed to encode reset - line, should be 1 - -------- -Example -------- - -firmware { - zynqmp_firmware: zynqmp-firmware { - compatible = "xlnx,zynqmp-firmware"; - method = "smc"; - - zynqmp_reset: reset-controller { - compatible = "xlnx,zynqmp-reset"; - #reset-cells = <1>; - }; - }; -}; - -Specifying reset lines connected to IP modules -============================================== - -Device nodes that need access to reset lines should -specify them as a reset phandle in their corresponding node as -specified in reset.txt. - -For list of all valid reset indices for Zynq UltraScale+ MPSoC see -<dt-bindings/reset/xlnx-zynqmp-resets.h> -For list of all valid reset indices for Versal see -<dt-bindings/reset/xlnx-versal-resets.h> - -Example: - -serdes: zynqmp_phy@fd400000 { - ... - - resets = <&zynqmp_reset ZYNQMP_RESET_SATA>; - reset-names = "sata_rst"; - - ... -}; diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml new file mode 100644 index 000000000000..49db66801429 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/xlnx,zynqmp-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Zynq UltraScale+ MPSoC and Versal reset + +maintainers: + - Piyush Mehta <piyush.mehta@amd.com> + +description: | + The Zynq UltraScale+ MPSoC and Versal has several different resets. + + The PS reset subsystem is responsible for handling the external reset + input to the device and that all internal reset requirements are met + for the system (as a whole) and for the functional units. + + Please also refer to reset.txt in this directory for common reset + controller binding usage. Device nodes that need access to reset + lines should specify them as a reset phandle in their corresponding + node as specified in reset.txt. + + For list of all valid reset indices for Zynq UltraScale+ MPSoC + <dt-bindings/reset/xlnx-zynqmp-resets.h> + + For list of all valid reset indices for Versal + <dt-bindings/reset/xlnx-versal-resets.h> + +properties: + compatible: + enum: + - xlnx,zynqmp-reset + - xlnx,versal-reset + - xlnx,versal-net-reset + + "#reset-cells": + const: 1 + +required: + - compatible + - "#reset-cells" + +additionalProperties: false + +examples: + - | + zynqmp_reset: reset-controller { + compatible = "xlnx,zynqmp-reset"; + #reset-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index 3d2934b15e80..38c0b5213736 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -23,6 +23,10 @@ description: | two cores, each of which has two hyperthreads, could be described as having four harts. +allOf: + - $ref: /schemas/cpu.yaml# + - $ref: extensions.yaml + properties: compatible: oneOf: @@ -61,7 +65,7 @@ properties: hart. These values originate from the RISC-V Privileged Specification document, available from https://riscv.org/specifications/ - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string enum: - riscv,sv32 - riscv,sv39 @@ -79,25 +83,9 @@ properties: description: The blocksize in bytes for the Zicboz cache operations. - riscv,isa: - description: - Identifies the specific RISC-V instruction set architecture - supported by the hart. These are documented in the RISC-V - User-Level ISA document, available from - https://riscv.org/specifications/ - - Due to revisions of the ISA specification, some deviations - have arisen over time. - Notably, riscv,isa was defined prior to the creation of the - Zicsr and Zifencei extensions and thus "i" implies - "zicsr_zifencei". - - While the isa strings in ISA specification are case - insensitive, letters in the riscv,isa string must be all - lowercase to simplify parsing. - $ref: "/schemas/types.yaml#/definitions/string" - pattern: ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$ - + # RISC-V has multiple properties for cache op block sizes as the sizes + # differ between individual CBO extensions + cache-op-block-size: false # RISC-V requires 'timebase-frequency' in /cpus, so disallow it here timebase-frequency: false @@ -120,7 +108,7 @@ properties: - interrupt-controller cpu-idle-states: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: maxItems: 1 description: | @@ -133,11 +121,20 @@ properties: DMIPS/MHz, relative to highest capacity-dmips-mhz in the system. +anyOf: + - required: + - riscv,isa + - required: + - riscv,isa-base + +dependencies: + riscv,isa-base: [ "riscv,isa-extensions" ] + riscv,isa-extensions: [ "riscv,isa-base" ] + required: - - riscv,isa - interrupt-controller -additionalProperties: true +unevaluatedProperties: false examples: - | @@ -154,7 +151,9 @@ examples: i-cache-sets = <128>; i-cache-size = <16384>; reg = <0>; - riscv,isa = "rv64imac"; + riscv,isa-base = "rv64i"; + riscv,isa-extensions = "i", "m", "a", "c"; + cpu_intc0: interrupt-controller { #interrupt-cells = <1>; compatible = "riscv,cpu-intc"; @@ -177,8 +176,10 @@ examples: i-tlb-size = <32>; mmu-type = "riscv,sv39"; reg = <1>; - riscv,isa = "rv64imafdc"; tlb-split; + riscv,isa-base = "rv64i"; + riscv,isa-extensions = "i", "m", "a", "f", "d", "c"; + cpu_intc1: interrupt-controller { #interrupt-cells = <1>; compatible = "riscv,cpu-intc"; @@ -196,8 +197,10 @@ examples: device_type = "cpu"; reg = <0>; compatible = "riscv"; - riscv,isa = "rv64imafdc"; mmu-type = "riscv,sv48"; + riscv,isa-base = "rv64i"; + riscv,isa-extensions = "i", "m", "a", "f", "d", "c"; + interrupt-controller { #interrupt-cells = <1>; interrupt-controller; diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml new file mode 100644 index 000000000000..cc1f546fdbdc --- /dev/null +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml @@ -0,0 +1,250 @@ +# SPDX-License-Identifier: (GPL-2.0 OR MIT) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/riscv/extensions.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RISC-V ISA extensions + +maintainers: + - Paul Walmsley <paul.walmsley@sifive.com> + - Palmer Dabbelt <palmer@sifive.com> + - Conor Dooley <conor@kernel.org> + +description: | + RISC-V has a large number of extensions, some of which are "standard" + extensions, meaning they are ratified by RISC-V International, and others + are "vendor" extensions. + This document defines properties that indicate whether a hart supports a + given extension. + + Once a standard extension has been ratified, no changes in behaviour can be + made without the creation of a new extension. + The properties for standard extensions therefore map to their originally + ratified states, with the exception of the I, Zicntr & Zihpm extensions. + See the "i" property for more information. + +select: + properties: + compatible: + contains: + const: riscv + +properties: + riscv,isa: + description: + Identifies the specific RISC-V instruction set architecture + supported by the hart. These are documented in the RISC-V + User-Level ISA document, available from + https://riscv.org/specifications/ + + Due to revisions of the ISA specification, some deviations + have arisen over time. + Notably, riscv,isa was defined prior to the creation of the + Zicntr, Zicsr, Zifencei and Zihpm extensions and thus "i" + implies "zicntr_zicsr_zifencei_zihpm". + + While the isa strings in ISA specification are case + insensitive, letters in the riscv,isa string must be all + lowercase. + $ref: /schemas/types.yaml#/definitions/string + pattern: ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$ + deprecated: true + + riscv,isa-base: + description: + The base ISA implemented by this hart, as described by the 20191213 + version of the unprivileged ISA specification. + enum: + - rv32i + - rv64i + + riscv,isa-extensions: + $ref: /schemas/types.yaml#/definitions/string-array + minItems: 1 + description: Extensions supported by the hart. + items: + anyOf: + # single letter extensions, in canonical order + - const: i + description: | + The base integer instruction set, as ratified in the 20191213 + version of the unprivileged ISA specification. + + This does not include Chapter 10, "Counters", which was moved into + the Zicntr and Zihpm extensions after the ratification of the + 20191213 version of the unprivileged specification. + + - const: m + description: + The standard M extension for integer multiplication and division, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: a + description: + The standard A extension for atomic instructions, as ratified in the + 20191213 version of the unprivileged ISA specification. + + - const: f + description: + The standard F extension for single-precision floating point, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: d + description: + The standard D extension for double-precision floating-point, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: q + description: + The standard Q extension for quad-precision floating-point, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: c + description: + The standard C extension for compressed instructions, as ratified in + the 20191213 version of the unprivileged ISA specification. + + - const: v + description: + The standard V extension for vector operations, as ratified + in-and-around commit 7a6c8ae ("Fix text that describes vfmv.v.f + encoding") of the riscv-v-spec. + + - const: h + description: + The standard H extension for hypervisors as ratified in the 20191213 + version of the privileged ISA specification. + + # multi-letter extensions, sorted alphanumerically + - const: smaia + description: | + The standard Smaia supervisor-level extension for the advanced + interrupt architecture for machine-mode-visible csr and behavioural + changes to interrupts as frozen at commit ccbddab ("Merge pull + request #42 from riscv/jhauser-2023-RC4") of riscv-aia. + + - const: ssaia + description: | + The standard Ssaia supervisor-level extension for the advanced + interrupt architecture for supervisor-mode-visible csr and + behavioural changes to interrupts as frozen at commit ccbddab + ("Merge pull request #42 from riscv/jhauser-2023-RC4") of riscv-aia. + + - const: sscofpmf + description: | + The standard Sscofpmf supervisor-level extension for count overflow + and mode-based filtering as ratified at commit 01d1df0 ("Add ability + to manually trigger workflow. (#2)") of riscv-count-overflow. + + - const: sstc + description: | + The standard Sstc supervisor-level extension for time compare as + ratified at commit 3f9ed34 ("Add ability to manually trigger + workflow. (#2)") of riscv-time-compare. + + - const: svinval + description: + The standard Svinval supervisor-level extension for fine-grained + address-translation cache invalidation as ratified in the 20191213 + version of the privileged ISA specification. + + - const: svnapot + description: + The standard Svnapot supervisor-level extensions for napot + translation contiguity as ratified in the 20191213 version of the + privileged ISA specification. + + - const: svpbmt + description: + The standard Svpbmt supervisor-level extensions for page-based + memory types as ratified in the 20191213 version of the privileged + ISA specification. + + - const: zba + description: | + The standard Zba bit-manipulation extension for address generation + acceleration instructions as ratified at commit 6d33919 ("Merge pull + request #158 from hirooih/clmul-fix-loop-end-condition") of + riscv-bitmanip. + + - const: zbb + description: | + The standard Zbb bit-manipulation extension for basic bit-manipulation + as ratified at commit 6d33919 ("Merge pull request #158 from + hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip. + + - const: zbc + description: | + The standard Zbc bit-manipulation extension for carry-less + multiplication as ratified at commit 6d33919 ("Merge pull request + #158 from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip. + + - const: zbs + description: | + The standard Zbs bit-manipulation extension for single-bit + instructions as ratified at commit 6d33919 ("Merge pull request #158 + from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip. + + - const: zicbom + description: + The standard Zicbom extension for base cache management operations as + ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. + + - const: zicbop + description: + The standard Zicbop extension for cache-block prefetch instructions + as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of + riscv-CMOs. + + - const: zicboz + description: + The standard Zicboz extension for cache-block zeroing as ratified + in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. + + - const: zicntr + description: + The standard Zicntr extension for base counters and timers, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: zicsr + description: | + The standard Zicsr extension for control and status register + instructions, as ratified in the 20191213 version of the + unprivileged ISA specification. + + This does not include Chapter 10, "Counters", which documents + special case read-only CSRs, that were moved into the Zicntr and + Zihpm extensions after the ratification of the 20191213 version of + the unprivileged specification. + + - const: zifencei + description: + The standard Zifencei extension for instruction-fetch fence, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: zihintpause + description: + The standard Zihintpause extension for pause hints, as ratified in + commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual. + + - const: zihpm + description: + The standard Zihpm extension for hardware performance counters, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: ztso + description: + The standard Ztso extension for total store ordering, as ratified + in commit 2e5236 ("Ztso is now ratified.") of the + riscv-isa-manual. + +additionalProperties: true +... diff --git a/Documentation/devicetree/bindings/riscv/thead.yaml b/Documentation/devicetree/bindings/riscv/thead.yaml new file mode 100644 index 000000000000..301912dcd290 --- /dev/null +++ b/Documentation/devicetree/bindings/riscv/thead.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/riscv/thead.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: T-HEAD SoC-based boards + +maintainers: + - Jisheng Zhang <jszhang@kernel.org> + +description: + T-HEAD SoC-based boards + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: BeagleV Ahead single board computer + items: + - const: beagle,beaglev-ahead + - const: thead,th1520 + - description: Sipeed Lichee Pi 4A board for the Sipeed Lichee Module 4A + items: + - enum: + - sipeed,lichee-pi-4a + - const: sipeed,lichee-module-4a + - const: thead,th1520 + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/rng/omap_rng.yaml b/Documentation/devicetree/bindings/rng/omap_rng.yaml index ccf54fae8302..c0ac4f68ea54 100644 --- a/Documentation/devicetree/bindings/rng/omap_rng.yaml +++ b/Documentation/devicetree/bindings/rng/omap_rng.yaml @@ -30,8 +30,8 @@ properties: clocks: minItems: 1 items: - - description: EIP150 gatable clock - - description: Main gatable clock + - description: EIP150 gateable clock + - description: Main gateable clock clock-names: minItems: 1 diff --git a/Documentation/devicetree/bindings/rtc/isil,isl1208.txt b/Documentation/devicetree/bindings/rtc/isil,isl1208.txt deleted file mode 100644 index 51f003006f04..000000000000 --- a/Documentation/devicetree/bindings/rtc/isil,isl1208.txt +++ /dev/null @@ -1,38 +0,0 @@ -Intersil ISL1209/19 I2C RTC/Alarm chip with event in - -ISL12X9 have additional pins EVIN and #EVDET for tamper detection, while the -ISL1208 and ISL1218 do not. They are all use the same driver with the bindings -described here, with chip specific properties as noted. - -Required properties supported by the device: - - "compatible": Should be one of the following: - - "isil,isl1208" - - "isil,isl1209" - - "isil,isl1218" - - "isil,isl1219" - - "reg": I2C bus address of the device - -Optional properties: - - "interrupt-names": list which may contains "irq" and "evdet" - evdet applies to isl1209 and isl1219 only - - "interrupts": list of interrupts for "irq" and "evdet" - evdet applies to isl1209 and isl1219 only - - "isil,ev-evienb": Enable or disable internal pull on EVIN pin - Applies to isl1209 and isl1219 only - Possible values are 0 and 1 - Value 0 enables internal pull-up on evin pin, 1 disables it. - Default will leave the non-volatile configuration of the pullup - as is. - -Example isl1219 node with #IRQ pin connected to SoC gpio1 pin12 and #EVDET pin -connected to SoC gpio2 pin 24 and internal pull-up enabled in EVIN pin. - - isl1219: rtc@68 { - compatible = "isil,isl1219"; - reg = <0x68>; - interrupt-names = "irq", "evdet"; - interrupts-extended = <&gpio1 12 IRQ_TYPE_EDGE_FALLING>, - <&gpio2 24 IRQ_TYPE_EDGE_FALLING>; - isil,ev-evienb = <1>; - }; - diff --git a/Documentation/devicetree/bindings/rtc/isil,isl1208.yaml b/Documentation/devicetree/bindings/rtc/isil,isl1208.yaml new file mode 100644 index 000000000000..11f7378d4997 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/isil,isl1208.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/isil,isl1208.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intersil ISL1209/19 I2C RTC/Alarm chip with event in + +maintainers: + - Biju Das <biju.das.jz@bp.renesas.com> + - Trent Piepho <tpiepho@gmail.com> + +description: + ISL12X9 have additional pins EVIN and EVDET for tamper detection, while the + ISL1208 and ISL1218 do not. + +properties: + compatible: + enum: + - isil,isl1208 + - isil,isl1209 + - isil,isl1218 + - isil,isl1219 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + description: | + Use xin, if connected to an external crystal. + Use clkin, if connected to an external clock signal. + enum: + - xin + - clkin + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + items: + - const: irq + - const: evdet + + isil,ev-evienb: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1 ] + description: | + Enable or disable internal pull on EVIN pin + Default will leave the non-volatile configuration of the pullup + as is. + <0> : Enables internal pull-up on evin pin + <1> : Disables internal pull-up on evin pin + +required: + - compatible + - reg + +allOf: + - $ref: rtc.yaml# + - if: + properties: + compatible: + contains: + enum: + - isil,isl1209 + - isil,isl1219 + then: + properties: + interrupts: + maxItems: 2 + interrupt-names: + items: + - const: irq + - const: evdet + else: + properties: + interrupts: + maxItems: 1 + interrupt-names: + items: + - const: irq + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc_twi: rtc@6f { + compatible = "isil,isl1208"; + reg = <0x6f>; + }; + }; diff --git a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml new file mode 100644 index 000000000000..f89c1f660aee --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/loongson,rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson Real-Time Clock + +description: + The Loongson family chips use an on-chip counter 0 (Time Of Year + counter) as the RTC. + +maintainers: + - Binbin Zhou <zhoubinbin@loongson.cn> + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + oneOf: + - enum: + - loongson,ls1b-rtc + - loongson,ls1c-rtc + - loongson,ls7a-rtc + - loongson,ls2k1000-rtc + - items: + - enum: + - loongson,ls2k2000-rtc + - loongson,ls2k0500-rtc + - const: loongson,ls7a-rtc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + rtc@1fe27800 { + compatible = "loongson,ls2k1000-rtc"; + reg = <0x1fe27800 0x100>; + + interrupt-parent = <&liointc1>; + interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; + }; + +... diff --git a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt b/Documentation/devicetree/bindings/rtc/rtc-cmos.txt index b94b35f3600b..7d7b5f6bda65 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt +++ b/Documentation/devicetree/bindings/rtc/rtc-cmos.txt @@ -10,7 +10,7 @@ Optional properties: - ctrl-reg : Contains the initial value of the control register also called "Register B". - freq-reg : Contains the initial value of the frequency register also - called "Regsiter A". + called "Register A". "Register A" and "B" are usually initialized by the firmware (BIOS for instance). If this is not done, it can be performed by the driver. diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml b/Documentation/devicetree/bindings/rtc/rtc.yaml index c6fff5486fe6..efb66df82782 100644 --- a/Documentation/devicetree/bindings/rtc/rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/rtc.yaml @@ -15,7 +15,7 @@ description: | properties: $nodename: - pattern: "^rtc(@.*|-[0-9a-f])*$" + pattern: "^rtc(@.*|-([0-9]|[1-9][0-9]+))?$" aux-voltage-chargeable: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml index a3603e638c37..9af77f21bb7f 100644 --- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml @@ -47,8 +47,6 @@ properties: - isil,isl1218 # Intersil ISL12022 Real-time Clock - isil,isl12022 - # Loongson-2K Socs/LS7A bridge Real-time Clock - - loongson,ls2x-rtc # Real Time Clock Module with I2C-Bus - microcrystal,rv3029 # Real Time Clock diff --git a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml index 7ed0230f6c67..d1f5eb996dba 100644 --- a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml @@ -11,7 +11,7 @@ description: The RTC controller has separate IRQ lines for seconds and alarm. maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> allOf: - $ref: rtc.yaml# diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml index 01ec45b3b406..2e189e548327 100644 --- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml +++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml @@ -33,6 +33,7 @@ properties: - amlogic,meson8b-uart - amlogic,meson-gx-uart - amlogic,meson-s4-uart + - amlogic,meson-a1-uart - const: amlogic,meson-ao-uart - description: Always-on power domain UART controller on G12A SoCs items: @@ -46,10 +47,15 @@ properties: - amlogic,meson8b-uart - amlogic,meson-gx-uart - amlogic,meson-s4-uart + - amlogic,meson-a1-uart - description: Everything-Else power domain UART controller on G12A SoCs items: - const: amlogic,meson-g12a-uart - const: amlogic,meson-gx-uart + - description: UART controller on S4 compatible SoCs + items: + - const: amlogic,t7-uart + - const: amlogic,meson-s4-uart reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml index 30b2131b5860..65cb2e5c5eee 100644 --- a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml +++ b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml @@ -16,7 +16,6 @@ properties: - enum: - atmel,at91rm9200-usart - atmel,at91sam9260-usart - - microchip,sam9x60-usart - items: - const: atmel,at91rm9200-dbgu - const: atmel,at91rm9200-usart @@ -24,6 +23,9 @@ properties: - const: atmel,at91sam9260-dbgu - const: atmel,at91sam9260-usart - items: + - const: microchip,sam9x60-usart + - const: atmel,at91sam9260-usart + - items: - const: microchip,sam9x60-dbgu - const: microchip,sam9x60-usart - const: atmel,at91sam9260-dbgu diff --git a/Documentation/devicetree/bindings/serial/cavium-uart.txt b/Documentation/devicetree/bindings/serial/cavium-uart.txt deleted file mode 100644 index 87a6c375cd44..000000000000 --- a/Documentation/devicetree/bindings/serial/cavium-uart.txt +++ /dev/null @@ -1,19 +0,0 @@ -* Universal Asynchronous Receiver/Transmitter (UART) - -- compatible: "cavium,octeon-3860-uart" - - Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs. - -- reg: The base address of the UART register bank. - -- interrupts: A single interrupt specifier. - -- current-speed: Optional, the current bit rate in bits per second. - -Example: - uart1: serial@1180000000c00 { - compatible = "cavium,octeon-3860-uart","ns16550"; - reg = <0x11800 0x00000c00 0x0 0x400>; - current-speed = <115200>; - interrupts = <0 35>; - }; diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml index a8b323d7bf94..e35ad1109efc 100644 --- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml +++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence UART Controller maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index 93062403276b..3a5b59f5d3e3 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -25,11 +25,15 @@ properties: - fsl,imxrt1050-lpuart - items: - enum: - - fsl,imx93-lpuart - fsl,imx8ulp-lpuart - const: fsl,imx7ulp-lpuart - items: - enum: + - fsl,imx93-lpuart + - const: fsl,imx8ulp-lpuart + - const: fsl,imx7ulp-lpuart + - items: + - enum: - fsl,imx8qm-lpuart - fsl,imx8dxl-lpuart - const: fsl,imx8qxp-lpuart diff --git a/Documentation/devicetree/bindings/serial/nuvoton,ma35d1-serial.yaml b/Documentation/devicetree/bindings/serial/nuvoton,ma35d1-serial.yaml new file mode 100644 index 000000000000..a76af0f6009b --- /dev/null +++ b/Documentation/devicetree/bindings/serial/nuvoton,ma35d1-serial.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/nuvoton,ma35d1-serial.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton MA35D1 Universal Asynchronous Receiver/Transmitter (UART) + +maintainers: + - Min-Jen Chen <mjchen@nuvoton.com> + - Jacky Huang <ychuang3@nuvoton.com> + +allOf: + - $ref: serial.yaml + +properties: + compatible: + const: nuvoton,ma35d1-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h> + + serial@40700000 { + compatible = "nuvoton,ma35d1-uart"; + reg = <0x40700000 0x100>; + interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk UART0_GATE>; + }; +... diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt deleted file mode 100644 index f709304036c2..000000000000 --- a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt +++ /dev/null @@ -1,73 +0,0 @@ -NVIDIA Tegra20/Tegra30 high speed (DMA based) UART controller driver. - -Required properties: -- compatible : should be, - "nvidia,tegra20-hsuart" for Tegra20, - "nvidia,tegra30-hsuart" for Tegra30, - "nvidia,tegra186-hsuart" for Tegra186, - "nvidia,tegra194-hsuart" for Tegra194. - -- reg: Should contain UART controller registers location and length. -- interrupts: Should contain UART controller interrupts. -- clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - serial -- dmas : Must contain an entry for each entry in dma-names. - See ../dma/dma.txt for details. -- dma-names : Must include the following entries: - - rx - - tx - -Optional properties: -- nvidia,enable-modem-interrupt: Enable modem interrupts. Should be enable - only if all 8 lines of UART controller are pinmuxed. -- nvidia,adjust-baud-rates: List of entries providing percentage of baud rate - adjustment within a range. - Each entry contains sets of 3 values. Range low/high and adjusted rate. - <range_low range_high adjusted_rate> - When baud rate set on controller falls within the range mentioned in this - field, baud rate will be adjusted by percentage mentioned here. - Ex: <9600 115200 200> - Increase baud rate by 2% when set baud rate falls within range 9600 to 115200 - -Baud Rate tolerance: - Standard UART devices are expected to have tolerance for baud rate error by - -4 to +4 %. All Tegra devices till Tegra210 had this support. However, - Tegra186 chip has a known hardware issue. UART Rx baud rate tolerance level - is 0% to +4% in 1-stop config. Otherwise, the received data will have - corruption/invalid framing errors. Parker errata suggests adjusting baud - rate to be higher than the deviations observed in Tx. - - Tx deviation of connected device can be captured over scope (or noted from - its spec) for valid range and Tegra baud rate has to be set above actual - Tx baud rate observed. To do this we use nvidia,adjust-baud-rates - - As an example, consider there is deviation observed in Tx for baud rates as - listed below. - 0 to 9600 has 1% deviation - 9600 to 115200 2% deviation - This slight deviation is expcted and Tegra UART is expected to handle it. Due - to the issue stated above, baud rate on Tegra UART should be set equal to or - above deviation observed for avoiding frame errors. - Property should be set like this - nvidia,adjust-baud-rates = <0 9600 100>, - <9600 115200 200>; - -Example: - -serial@70006000 { - compatible = "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart"; - reg = <0x70006000 0x40>; - reg-shift = <2>; - interrupts = <0 36 0x04>; - nvidia,enable-modem-interrupt; - clocks = <&tegra_car 6>; - resets = <&tegra_car 6>; - reset-names = "serial"; - dmas = <&apbdma 8>, <&apbdma 8>; - dma-names = "rx", "tx"; - nvidia,adjust-baud-rates = <1000000 4000000 136>; /* 1.36% shift */ -}; diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.yaml b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.yaml new file mode 100644 index 000000000000..04d55fecf47c --- /dev/null +++ b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.yaml @@ -0,0 +1,125 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/nvidia,tegra20-hsuart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20/Tegra30 high speed (DMA based) UART controller driver + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + oneOf: + - enum: + - nvidia,tegra20-hsuart + - nvidia,tegra30-hsuart + - nvidia,tegra186-hsuart + - nvidia,tegra194-hsuart + - items: + - const: nvidia,tegra124-hsuart + - const: nvidia,tegra30-hsuart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: module clock + + resets: + items: + - description: module reset + + reset-names: + items: + - const: serial + + dmas: + items: + - description: DMA channel used for reception + - description: DMA channel used for transmission + + dma-names: + items: + - const: rx + - const: tx + + nvidia,enable-modem-interrupt: + $ref: /schemas/types.yaml#/definitions/flag + description: Enable modem interrupts. Should be enable only if all 8 lines of UART controller + are pinmuxed. + + nvidia,adjust-baud-rates: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + description: | + List of entries providing percentage of baud rate adjustment within a range. Each entry + contains a set of 3 values: range low/high and adjusted rate. When the baud rate set on the + controller falls within the range mentioned in this field, the baud rate will be adjusted by + percentage mentioned here. + + Example: <9600 115200 200> + + Increase baud rate by 2% when set baud rate falls within range 9600 to 115200. + + Standard UART devices are expected to have tolerance for baud rate error by -4 to +4 %. All + Tegra devices till Tegra210 had this support. However, Tegra186 chip has a known hardware + issue. UART RX baud rate tolerance level is 0% to +4% in 1-stop config. Otherwise, the + received data will have corruption/invalid framing errors. Parker errata suggests adjusting + baud rate to be higher than the deviations observed in TX. + + TX deviation of connected device can be captured over scope (or noted from its spec) for + valid range and Tegra baud rate has to be set above actual TX baud rate observed. To do this + we use nvidia,adjust-baud-rates. + + As an example, consider there is deviation observed in TX for baud rates as listed below. 0 + to 9600 has 1% deviation 9600 to 115200 2% deviation. This slight deviation is expcted and + Tegra UART is expected to handle it. Due to the issue stated above, baud rate on Tegra UART + should be set equal to or above deviation observed for avoiding frame errors. Property + should be set like this: + + nvidia,adjust-baud-rates = <0 9600 100>, + <9600 115200 200>; + items: + items: + - description: range lower bound + - description: range upper bound + - description: adjustment (in permyriad, i.e. 0.01%) + +allOf: + - $ref: serial.yaml + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - resets + - reset-names + - dmas + - dma-names + +examples: + - | + #include <dt-bindings/clock/tegra30-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + serial@70006000 { + compatible = "nvidia,tegra30-hsuart"; + reg = <0x70006000 0x40>; + interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>; + nvidia,enable-modem-interrupt; + clocks = <&tegra_car TEGRA30_CLK_UARTA>; + resets = <&tegra_car 6>; + reset-names = "serial"; + dmas = <&apbdma 8>, <&apbdma 8>; + dma-names = "rx", "tx"; + nvidia,adjust-baud-rates = <1000000 4000000 136>; /* 1.36% shift */ + }; diff --git a/Documentation/devicetree/bindings/serial/nxp,lpc1850-uart.txt b/Documentation/devicetree/bindings/serial/nxp,lpc1850-uart.txt deleted file mode 100644 index 04e23e63ee4f..000000000000 --- a/Documentation/devicetree/bindings/serial/nxp,lpc1850-uart.txt +++ /dev/null @@ -1,28 +0,0 @@ -* NXP LPC1850 UART - -Required properties: -- compatible : "nxp,lpc1850-uart", "ns16550a". -- reg : offset and length of the register set for the device. -- interrupts : should contain uart interrupt. -- clocks : phandle to the input clocks. -- clock-names : required elements: "uartclk", "reg". - -Optional properties: -- dmas : Two or more DMA channel specifiers following the - convention outlined in bindings/dma/dma.txt -- dma-names : Names for the dma channels, if present. There must - be at least one channel named "tx" for transmit - and named "rx" for receive. - -Since it's also possible to also use the of_serial.c driver all -parameters from 8250.txt also apply but are optional. - -Example: -uart0: serial@40081000 { - compatible = "nxp,lpc1850-uart", "ns16550a"; - reg = <0x40081000 0x1000>; - reg-shift = <2>; - interrupts = <24>; - clocks = <&ccu2 CLK_APB0_UART0>, <&ccu1 CLK_CPU_UART0>; - clock-names = "uartclk", "reg"; -}; diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt index 0fa8e3e43bf8..1a7e4bff0456 100644 --- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt +++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt @@ -23,6 +23,9 @@ Optional properties: 1 = active low. - irda-mode-ports: An array that lists the indices of the port that should operate in IrDA mode. +- nxp,modem-control-line-ports: An array that lists the indices of the port that + should have shared GPIO lines configured as + modem control lines. Example: sc16is750: sc16is750@51 { @@ -35,6 +38,26 @@ Example: #gpio-cells = <2>; }; + sc16is752: sc16is752@53 { + compatible = "nxp,sc16is752"; + reg = <0x53>; + clocks = <&clk20m>; + interrupt-parent = <&gpio3>; + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; + nxp,modem-control-line-ports = <1>; /* Port 1 as modem control lines */ + gpio-controller; /* Port 0 as GPIOs */ + #gpio-cells = <2>; + }; + + sc16is752: sc16is752@54 { + compatible = "nxp,sc16is752"; + reg = <0x54>; + clocks = <&clk20m>; + interrupt-parent = <&gpio3>; + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; + nxp,modem-control-line-ports = <0 1>; /* Ports 0 and 1 as modem control lines */ + }; + * spi as bus Required properties: @@ -59,6 +82,9 @@ Optional properties: 1 = active low. - irda-mode-ports: An array that lists the indices of the port that should operate in IrDA mode. +- nxp,modem-control-line-ports: An array that lists the indices of the port that + should have shared GPIO lines configured as + modem control lines. Example: sc16is750: sc16is750@0 { @@ -70,3 +96,23 @@ Example: gpio-controller; #gpio-cells = <2>; }; + + sc16is752: sc16is752@1 { + compatible = "nxp,sc16is752"; + reg = <1>; + clocks = <&clk20m>; + interrupt-parent = <&gpio3>; + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; + nxp,modem-control-line-ports = <1>; /* Port 1 as modem control lines */ + gpio-controller; /* Port 0 as GPIOs */ + #gpio-cells = <2>; + }; + + sc16is752: sc16is752@2 { + compatible = "nxp,sc16is752"; + reg = <2>; + clocks = <&clk20m>; + interrupt-parent = <&gpio3>; + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; + nxp,modem-control-line-ports = <0 1>; /* Ports 0 and 1 as modem control lines */ + }; diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index 3862411c77b5..17c553123f96 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -117,7 +117,6 @@ properties: required: - compatible - reg - - interrupts unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/serial/st-asc.txt b/Documentation/devicetree/bindings/serial/st-asc.txt index 75d877f5968f..a1b9b6f3490a 100644 --- a/Documentation/devicetree/bindings/serial/st-asc.txt +++ b/Documentation/devicetree/bindings/serial/st-asc.txt @@ -8,7 +8,7 @@ Required properties: Optional properties: - st,hw-flow-ctrl bool flag to enable hardware flow control. -- st,force-m1 bool flat to force asc to be in Mode-1 recommeded +- st,force-m1 bool flat to force asc to be in Mode-1 recommended for high bit rates (above 19.2K) Example: serial@fe440000{ diff --git a/Documentation/devicetree/bindings/slimbus/slimbus.yaml b/Documentation/devicetree/bindings/slimbus/slimbus.yaml index 22513fb7c59a..3b8cae9d1016 100644 --- a/Documentation/devicetree/bindings/slimbus/slimbus.yaml +++ b/Documentation/devicetree/bindings/slimbus/slimbus.yaml @@ -15,7 +15,7 @@ description: properties: $nodename: - pattern: "^slim(@.*|-[0-9a-f])*$" + pattern: "^slim(@.*|-([0-9]|[1-9][0-9]+))?$" "#address-cells": const: 2 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 new file mode 100644 index 000000000000..16977e4e4357 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson System Control registers + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +properties: + compatible: + items: + - enum: + - amlogic,meson-gx-hhi-sysctrl + - amlogic,meson-gx-ao-sysctrl + - amlogic,meson-axg-hhi-sysctrl + - amlogic,meson-axg-ao-sysctrl + - const: simple-mfd + - const: syscon + + reg: + maxItems: 1 + + clock-controller: + type: object + + power-controller: + $ref: /schemas/power/amlogic,meson-ee-pwrc.yaml + + pinctrl: + type: object + + phy: + type: object + +allOf: + - if: + properties: + compatible: + enum: + - amlogic,meson-gx-hhi-sysctrl + - amlogic,meson-axg-hhi-sysctrl + then: + properties: + clock-controller: + $ref: /schemas/clock/amlogic,gxbb-clkc.yaml# + + required: + - power-controller + + - if: + properties: + compatible: + enum: + - amlogic,meson-gx-ao-sysctrl + - amlogic,meson-axg-ao-sysctrl + then: + properties: + clock-controller: + $ref: /schemas/clock/amlogic,gxbb-aoclkc.yaml# + + power-controller: false + phy: false + + - if: + properties: + compatible: + enum: + - amlogic,meson-gx-hhi-sysctrl + then: + properties: + phy: false + + - if: + properties: + compatible: + enum: + - amlogic,meson-axg-hhi-sysctrl + then: + properties: + phy: + oneOf: + - $ref: /schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml + - $ref: /schemas/phy/amlogic,meson-axg-mipi-pcie-analog.yaml + +required: + - compatible + - reg + - clock-controller + +additionalProperties: false + +examples: + - | + bus@c883c000 { + compatible = "simple-bus"; + reg = <0xc883c000 0x2000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0xc883c000 0x2000>; + + sysctrl: system-controller@0 { + compatible = "amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon"; + reg = <0 0x400>; + + clock-controller { + compatible = "amlogic,gxbb-clkc"; + #clock-cells = <1>; + clocks = <&xtal>; + clock-names = "xtal"; + }; + + power-controller { + compatible = "amlogic,meson-gxbb-pwrc"; + #power-domain-cells = <1>; + amlogic,ao-sysctrl = <&sysctrl_AO>; + + resets = <&reset_viu>, + <&reset_venc>, + <&reset_vcbus>, + <&reset_bt656>, + <&reset_dvin>, + <&reset_rdma>, + <&reset_venci>, + <&reset_vencp>, + <&reset_vdac>, + <&reset_vdi6>, + <&reset_vencl>, + <&reset_vid_lock>; + reset-names = "viu", "venc", "vcbus", "bt656", "dvin", + "rdma", "venci", "vencp", "vdac", "vdi6", + "vencl", "vid_lock"; + clocks = <&clk_vpu>, <&clk_vapb>; + clock-names = "vpu", "vapb"; + }; + }; + }; + + bus@c8100000 { + compatible = "simple-bus"; + reg = <0xc8100000 0x100000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0xc8100000 0x100000>; + + sysctrl_AO: system-controller@0 { + compatible = "amlogic,meson-gx-ao-sysctrl", "simple-mfd", "syscon"; + reg = <0 0x100>; + + clock-controller { + compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc"; + #clock-cells = <1>; + #reset-cells = <1>; + clocks = <&xtal>, <&clk81>; + clock-names = "xtal", "mpeg-clk"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml b/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml index 6876407124dc..51aaf34acb32 100644 --- a/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml +++ b/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml @@ -3,8 +3,8 @@ # # Copyright (c) 2021 Aspeed Technology Inc. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/aspeed/uart-routing.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/aspeed/uart-routing.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Aspeed UART Routing Controller diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm23550-cdc.yaml b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm23550-cdc.yaml new file mode 100644 index 000000000000..1a952f569803 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm23550-cdc.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/bcm/brcm,bcm23550-cdc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM23550 Cluster Dormant Control + +description: + The Cluster Dormant Control block keeps the CPU in idle state. A command + needs to be sent to this block to bring the CPU into running state. + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +properties: + compatible: + const: brcm,bcm23550-cdc + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + cdc@3fe0e000 { + compatible = "brcm,bcm23550-cdc"; + reg = <0x3fe0e000 0x78>; + }; +... diff --git a/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml b/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml index 8634865015cd..ceb81646fe75 100644 --- a/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml +++ b/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2022, Intel Corporation %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/intel/intel,hps-copy-engine.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/intel/intel,hps-copy-engine.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel HPS Copy Engine diff --git a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml index ecae9fa8561b..a64406ca17b5 100644 --- a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml +++ b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml @@ -2,8 +2,8 @@ # Copyright 2020 Antmicro <www.antmicro.com> %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/litex/litex,soc-controller.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/litex/litex,soc-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: LiteX SoC Controller driver diff --git a/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml new file mode 100644 index 000000000000..da2dcfeebf12 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/loongson/loongson,ls2k-pmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson-2 Power Manager controller + +maintainers: + - Yinbo Zhu <zhuyinbo@loongson.cn> + +properties: + compatible: + items: + - enum: + - loongson,ls2k0500-pmc + - loongson,ls2k1000-pmc + - const: syscon + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + loongson,suspend-address: + $ref: /schemas/types.yaml#/definitions/uint64 + description: + The "loongson,suspend-address" is a deep sleep state (Suspend To + RAM) firmware entry address which was jumped from kernel and it's + value was dependent on specific platform firmware code. In + addition, the PM need according to it to indicate that current + SoC whether support Suspend To RAM. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + power-management@1fe27000 { + compatible = "loongson,ls2k1000-pmc", "syscon"; + reg = <0x1fe27000 0x58>; + interrupt-parent = <&liointc1>; + interrupts = <11 IRQ_TYPE_LEVEL_LOW>; + loongson,suspend-address = <0x0 0x1c000500>; + }; diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml index 8e6ba2ec8a43..f0fa92b04b32 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml @@ -12,7 +12,7 @@ maintainers: description: The MediaTek wo-ccif provides a configuration interface for WED WO - controller used to perfrom offload rx packet processing (e.g. 802.11 + controller used to perform offload rx packet processing (e.g. 802.11 aggregation packet reordering or rx header translation) on MT7986 soc. properties: diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml index 3fefd634bc69..a06ac2177444 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml @@ -33,6 +33,7 @@ properties: - mediatek,mt2701-pwrap - mediatek,mt6765-pwrap - mediatek,mt6779-pwrap + - mediatek,mt6795-pwrap - mediatek,mt6797-pwrap - mediatek,mt6873-pwrap - mediatek,mt7622-pwrap diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml index 04ffee3a7c59..365a9fed5914 100644 --- a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml @@ -12,7 +12,7 @@ maintainers: description: | PolarFire SoC devices include a microcontroller acting as the system controller, which provides "services" to the main processor and to the FPGA fabric. These - services include hardware rng, reprogramming of the FPGA and verfification of the + services include hardware rng, reprogramming of the FPGA and verification of the eNVM contents etc. More information on these services can be found online, at https://onlinedocs.microchip.com/pr/GUID-1409CF11-8EF9-4C24-A94E-70979A688632-en-US-1/index.html diff --git a/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,npcm-gcr.yaml index 94e72f25b331..23e7e4ea01ff 100644 --- a/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml +++ b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,npcm-gcr.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/arm/npcm/nuvoton,gcr.yaml# +$id: http://devicetree.org/schemas/soc/nuvoton/nuvoton,npcm-gcr.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Global Control Registers block in Nuvoton SoCs diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml index 798f15588ee2..d1c7c2be865f 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml @@ -26,6 +26,7 @@ properties: items: - enum: - qcom,qdu1000-aoss-qmp + - qcom,sa8775p-aoss-qmp - qcom,sc7180-aoss-qmp - qcom,sc7280-aoss-qmp - qcom,sc8180x-aoss-qmp @@ -76,7 +77,7 @@ patternProperties: description: The AOSS side channel also provides the controls for three cooling devices, these are expressed as subnodes of the QMP node. The name of the node is - used to identify the resource and must therefor be "cx", "mx" or "ebi". + used to identify the resource and must therefore be "cx", "mx" or "ebi". properties: "#cooling-cells": diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml index 14dd29471c80..f2c5ec7e6437 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml @@ -55,9 +55,10 @@ additionalProperties: false examples: - | eud@88e0000 { - compatible = "qcom,sc7280-eud","qcom,eud"; + compatible = "qcom,sc7280-eud", "qcom,eud"; reg = <0x88e0000 0x2000>, <0x88e2000 0x1000>; + ports { #address-cells = <1>; #size-cells = <0>; @@ -67,6 +68,7 @@ examples: remote-endpoint = <&usb2_role_switch>; }; }; + port@1 { reg = <1>; eud_con: endpoint { diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml index 6440dc801387..bceb479f74c5 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml @@ -38,15 +38,9 @@ properties: patternProperties: '^connector@\d$': $ref: /schemas/connector/usb-connector.yaml# - - properties: - reg: true - required: - reg - unevaluatedProperties: false - required: - compatible diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml new file mode 100644 index 000000000000..031800985b5e --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,rpm-master-stats.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. (QTI) RPM Master Stats + +maintainers: + - Konrad Dybcio <konrad.dybcio@linaro.org> + +description: | + The Qualcomm RPM (Resource Power Manager) architecture includes a concept + of "RPM Masters". They can be thought of as "the local gang leaders", usually + spanning a single subsystem (e.g. APSS, ADSP, CDSP). All of the RPM decisions + (particularly around entering hardware-driven low power modes: XO shutdown + and total system-wide power collapse) are first made at Master-level, and + only then aggregated for the entire system. + + The Master Stats provide a few useful bits that can be used to assess whether + our device has entered the desired low-power mode, how long it took to do so, + the duration of that residence, how long it took to come back online, + how many times a given sleep state was entered and which cores are actively + voting for staying awake. + + This scheme has been used on various SoCs in the 2013-2023 era, with some + newer or higher-end designs providing this information through an SMEM query. + +properties: + compatible: + const: qcom,rpm-master-stats + + qcom,rpm-msg-ram: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: Phandle to an RPM MSG RAM slice containing the master stats + minItems: 1 + maxItems: 5 + + qcom,master-names: + $ref: /schemas/types.yaml#/definitions/string-array + description: + The name of the RPM Master which owns the MSG RAM slice where this + instance of Master Stats resides + minItems: 1 + maxItems: 5 + +required: + - compatible + - qcom,rpm-msg-ram + - qcom,master-names + +additionalProperties: false + +examples: + - | + stats { + compatible = "qcom,rpm-master-stats"; + qcom,rpm-msg-ram = <&apss_master_stats>, + <&mpss_master_stats>, + <&adsp_master_stats>, + <&cdsp_master_stats>, + <&tz_master_stats>; + qcom,master-names = "APSS", + "MPSS", + "ADSP", + "CDSP", + "TZ"; + }; +... diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml index a4046ba60846..af632d0e0355 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml @@ -124,6 +124,7 @@ required: - qcom,tcs-offset - reg - reg-names + - power-domains additionalProperties: false @@ -179,6 +180,7 @@ examples: <SLEEP_TCS 1>, <WAKE_TCS 1>, <CONTROL_TCS 0>; + power-domains = <&CLUSTER_PD>; }; - | diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index ea86569a40d3..2fa725b8af5d 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -34,22 +34,27 @@ properties: - qcom,rpm-apq8084 - qcom,rpm-ipq6018 - qcom,rpm-ipq9574 + - qcom,rpm-mdm9607 - qcom,rpm-msm8226 + - qcom,rpm-msm8610 - qcom,rpm-msm8909 - qcom,rpm-msm8916 + - qcom,rpm-msm8917 - qcom,rpm-msm8936 + - qcom,rpm-msm8937 + - qcom,rpm-msm8952 - qcom,rpm-msm8953 - qcom,rpm-msm8974 - qcom,rpm-msm8976 - qcom,rpm-msm8994 - qcom,rpm-msm8996 - qcom,rpm-msm8998 + - qcom,rpm-qcm2290 + - qcom,rpm-qcs404 - qcom,rpm-sdm660 - qcom,rpm-sm6115 - qcom,rpm-sm6125 - qcom,rpm-sm6375 - - qcom,rpm-qcm2290 - - qcom,rpm-qcs404 clock-controller: $ref: /schemas/clock/qcom,rpmcc.yaml# @@ -81,11 +86,18 @@ if: contains: enum: - qcom,rpm-apq8084 + - qcom,rpm-mdm9607 + - qcom,rpm-msm8226 + - qcom,rpm-msm8610 + - qcom,rpm-msm8909 - qcom,rpm-msm8916 + - qcom,rpm-msm8917 - qcom,rpm-msm8936 + - qcom,rpm-msm8937 + - qcom,rpm-msm8952 + - qcom,rpm-msm8953 - qcom,rpm-msm8974 - qcom,rpm-msm8976 - - qcom,rpm-msm8953 - qcom,rpm-msm8994 then: properties: @@ -108,10 +120,10 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interrupt-controller/irq.h> - smd { - compatible = "qcom,smd"; + remoteproc { + compatible = "qcom,msm8916-rpm-proc", "qcom,rpm-proc"; - rpm { + smd-edge { interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>; qcom,ipc = <&apcs 8 0>; qcom,smd-edge = <15>; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml index 063e595c12f7..4819ce90d206 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml @@ -15,6 +15,12 @@ description: The Qualcomm Shared Memory Driver is a FIFO based communication channel for sending data between the various subsystems in Qualcomm platforms. + Using the top-level SMD node is deprecated. Instead, the SMD edges are defined + directly below the device node representing the respective remote subsystem + or remote processor. + +deprecated: true + properties: compatible: const: qcom,smd @@ -37,6 +43,7 @@ examples: # The following example represents a smd node, with one edge representing the # "rpm" subsystem. For the "rpm" subsystem we have a device tied to the # "rpm_request" channel. + # NOTE: This is deprecated, represent the RPM using "qcom,rpm-proc" instead. - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml index 7ab8cfff18c1..96a7f1822022 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies, Inc. (QTI) Stats maintainers: - - Maulik Shah <mkshah@codeaurora.org> + - Maulik Shah <quic_mkshah@quicinc.com> description: Always On Processor/Resource Power Manager maintains statistics of the SoC diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml index 398663d21ab1..e52e176d8cb3 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/renesas/renesas,rzg2l-sysc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/renesas/renesas,rzg2l-sysc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas RZ/{G2L,V2L} System Controller (SYSC) diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 65a2d5a4f28d..e4fa6a07b4fa 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -24,6 +24,7 @@ properties: - rockchip,rk3588-bigcore1-grf - rockchip,rk3588-ioc - rockchip,rk3588-php-grf + - rockchip,rk3588-pipe-phy-grf - rockchip,rk3588-sys-grf - rockchip,rk3588-pcie3-phy-grf - rockchip,rk3588-pcie3-pipe-grf @@ -52,6 +53,7 @@ properties: - rockchip,rk3399-pmugrf - rockchip,rk3568-grf - rockchip,rk3568-pmugrf + - rockchip,rk3588-usb2phy-grf - rockchip,rv1108-grf - rockchip,rv1108-pmugrf - rockchip,rv1126-grf @@ -119,7 +121,7 @@ allOf: usbphy: type: object - $ref: "/schemas/phy/rockchip-usb-phy.yaml#" + $ref: /schemas/phy/rockchip-usb-phy.yaml# unevaluatedProperties: false @@ -134,14 +136,14 @@ allOf: gpio: type: object - $ref: "/schemas/gpio/rockchip,rk3328-grf-gpio.yaml#" + $ref: /schemas/gpio/rockchip,rk3328-grf-gpio.yaml# unevaluatedProperties: false power-controller: type: object - $ref: "/schemas/power/rockchip,power-controller.yaml#" + $ref: /schemas/power/rockchip,power-controller.yaml# unevaluatedProperties: false @@ -156,7 +158,7 @@ allOf: mipi-dphy-rx0: type: object - $ref: "/schemas/phy/rockchip-mipi-dphy-rx0.yaml#" + $ref: /schemas/phy/rockchip-mipi-dphy-rx0.yaml# unevaluatedProperties: false @@ -184,7 +186,7 @@ allOf: reboot-mode: type: object - $ref: "/schemas/power/reset/syscon-reboot-mode.yaml#" + $ref: /schemas/power/reset/syscon-reboot-mode.yaml# unevaluatedProperties: false @@ -199,6 +201,7 @@ allOf: - rockchip,rk3308-usb2phy-grf - rockchip,rk3328-usb2phy-grf - rockchip,rk3399-grf + - rockchip,rk3588-usb2phy-grf - rockchip,rv1108-grf then: @@ -238,7 +241,7 @@ allOf: io-domains: type: object - $ref: "/schemas/power/rockchip-io-domain.yaml#" + $ref: /schemas/power/rockchip-io-domain.yaml# unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml index 5d8d9497f18e..e1d716df5dfa 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml @@ -17,6 +17,7 @@ select: enum: - samsung,exynos3250-pmu - samsung,exynos4210-pmu + - samsung,exynos4212-pmu - samsung,exynos4412-pmu - samsung,exynos5250-pmu - samsung,exynos5260-pmu @@ -36,6 +37,7 @@ properties: - enum: - samsung,exynos3250-pmu - samsung,exynos4210-pmu + - samsung,exynos4212-pmu - samsung,exynos4412-pmu - samsung,exynos5250-pmu - samsung,exynos5260-pmu @@ -50,6 +52,7 @@ properties: - enum: - samsung,exynos3250-pmu - samsung,exynos4210-pmu + - samsung,exynos4212-pmu - samsung,exynos4412-pmu - samsung,exynos5250-pmu - samsung,exynos5420-pmu @@ -125,6 +128,7 @@ allOf: enum: - samsung,exynos3250-pmu - samsung,exynos4210-pmu + - samsung,exynos4212-pmu - samsung,exynos4412-pmu - samsung,exynos5250-pmu - samsung,exynos5410-pmu @@ -143,6 +147,7 @@ allOf: enum: - samsung,exynos3250-pmu - samsung,exynos4210-pmu + - samsung,exynos4212-pmu - samsung,exynos4412-pmu - samsung,exynos5250-pmu - samsung,exynos5420-pmu diff --git a/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml b/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml new file mode 100644 index 000000000000..0039319e91fe --- /dev/null +++ b/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/starfive/starfive,jh7110-syscon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 SoC system controller + +maintainers: + - William Qiu <william.qiu@starfivetech.com> + +description: + The StarFive JH7110 SoC system controller provides register information such + as offset, mask and shift to configure related modules such as MMC and PCIe. + +properties: + compatible: + oneOf: + - items: + - const: starfive,jh7110-sys-syscon + - const: syscon + - const: simple-mfd + - items: + - enum: + - starfive,jh7110-aon-syscon + - starfive,jh7110-stg-syscon + - const: syscon + + reg: + maxItems: 1 + + clock-controller: + $ref: /schemas/clock/starfive,jh7110-pll.yaml# + type: object + + "#power-domain-cells": + const: 1 + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: starfive,jh7110-sys-syscon + then: + required: + - clock-controller + else: + properties: + clock-controller: false + - if: + properties: + compatible: + contains: + const: starfive,jh7110-aon-syscon + then: + required: + - "#power-domain-cells" + else: + properties: + "#power-domain-cells": false + +additionalProperties: false + +examples: + - | + syscon@10240000 { + compatible = "starfive,jh7110-stg-syscon", "syscon"; + reg = <0x10240000 0x1000>; + }; + + syscon@13030000 { + compatible = "starfive,jh7110-sys-syscon", "syscon", "simple-mfd"; + reg = <0x13030000 0x1000>; + + clock-controller { + compatible = "starfive,jh7110-pll"; + clocks = <&osc>; + #clock-cells = <1>; + }; + }; + + syscon@17010000 { + compatible = "starfive,jh7110-aon-syscon", "syscon"; + reg = <0x17010000 0x1000>; + #power-domain-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,nvec.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,nvec.yaml new file mode 100644 index 000000000000..d5261ce3a619 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,nvec.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/tegra/nvidia,nvec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA compliant embedded controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,nvec + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: divider clock + - description: fast clock + + clock-names: + minItems: 1 + items: + - const: div-clk + - const: fast-clk + + resets: + items: + - description: module reset + + reset-names: + items: + - const: i2c + + clock-frequency: true + + request-gpios: + description: phandle to the GPIO used for EC request + + slave-addr: + $ref: /schemas/types.yaml#/definitions/uint32 + description: I2C address of the slave controller + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + - clock-frequency + - request-gpios + - slave-addr + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/gpio/tegra-gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2c@7000c500 { + compatible = "nvidia,nvec"; + reg = <0x7000c500 0x100>; + interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <80000>; + request-gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>; + slave-addr = <138>; + clocks = <&tegra_car TEGRA20_CLK_I2C3>, + <&tegra_car TEGRA20_CLK_PLL_P_OUT3>; + clock-names = "div-clk", "fast-clk"; + resets = <&tegra_car 67>; + reset-names = "i2c"; + }; diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-ahb.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-ahb.yaml new file mode 100644 index 000000000000..2f7269a26b8e --- /dev/null +++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-ahb.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/tegra/nvidia,tegra20-ahb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +title: NVIDIA Tegra AHB + +properties: + compatible: + oneOf: + - enum: + - nvidia,tegra20-ahb + - nvidia,tegra30-ahb + - items: + - enum: + - nvidia,tegra114-ahb + - nvidia,tegra124-ahb + - nvidia,tegra210-ahb + - const: nvidia,tegra30-ahb + + reg: + maxItems: 1 + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + ahb@6000c004 { + compatible = "nvidia,tegra20-ahb"; + reg = <0x6000c004 0x10c>; /* AHB Arbitration + Gizmo Controller */ + }; diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-flowctrl.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-flowctrl.yaml new file mode 100644 index 000000000000..705544b7f98f --- /dev/null +++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-flowctrl.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/tegra/nvidia,tegra20-flowctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Flow Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + oneOf: + - enum: + - nvidia,tegra20-flowctrl + - nvidia,tegra30-flowctrl + - nvidia,tegra114-flowctrl + - nvidia,tegra124-flowctrl + - nvidia,tegra210-flowctrl + + - items: + - const: nvidia,tegra132-flowctrl + - const: nvidia,tegra124-flowctrl + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + flow-controller@60007000 { + compatible = "nvidia,tegra20-flowctrl"; + reg = <0x60007000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml index 22cf9002fee7..158186610c53 100644 --- a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml +++ b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/ti/k3-ringacc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/ti/k3-ringacc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments K3 NavigatorSS Ring Accelerator @@ -34,18 +34,22 @@ properties: - const: ti,am654-navss-ringacc reg: + minItems: 4 items: - description: real time registers regions - description: fifos registers regions - description: proxy gcfg registers regions - description: proxy target registers regions + - description: configuration registers region reg-names: + minItems: 4 items: - const: rt - const: fifos - const: proxy_gcfg - const: proxy_target + - const: cfg msi-parent: true @@ -80,8 +84,9 @@ examples: reg = <0x0 0x3c000000 0x0 0x400000>, <0x0 0x38000000 0x0 0x400000>, <0x0 0x31120000 0x0 0x100>, - <0x0 0x33000000 0x0 0x40000>; - reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target"; + <0x0 0x33000000 0x0 0x40000>, + <0x0 0x31080000 0x0 0x40000>; + reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg"; ti,num-rings = <818>; ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */ ti,sci = <&dmsc>; diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml index 5df7688a1e1c..a750035d6234 100644 --- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/soc/ti/sci-pm-domain.yaml# diff --git a/Documentation/devicetree/bindings/sound/adi,max98388.yaml b/Documentation/devicetree/bindings/sound/adi,max98388.yaml new file mode 100644 index 000000000000..93ccd5905736 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/adi,max98388.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/adi,max98388.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices MAX98388 Speaker Amplifier + +maintainers: + - Ryan Lee <ryans.lee@analog.com> + +description: + The MAX98388 is a mono Class-D speaker amplifier with I/V feedback. + The device provides a PCM interface for audio data and a standard + I2C interface for control data communication. + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - adi,max98388 + + reg: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + + adi,vmon-slot-no: + description: slot number of the voltage feedback monitor + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + default: 0 + + adi,imon-slot-no: + description: slot number of the current feedback monitor + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + default: 1 + + adi,interleave-mode: + description: + For cases where a single combined channel for the I/V feedback data + is not sufficient, the device can also be configured to share + a single data output channel on alternating frames. + In this configuration, the current and voltage data will be frame + interleaved on a single output channel. + type: boolean + + reset-gpios: + maxItems: 1 + +required: + - compatible + - reg + - '#sound-dai-cells' + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + max98388: amplifier@39 { + compatible = "adi,max98388"; + reg = <0x39>; + #sound-dai-cells = <0>; + adi,vmon-slot-no = <0>; + adi,imon-slot-no = <1>; + adi,interleave-mode; + reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml b/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml new file mode 100644 index 000000000000..f3f32540779c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/adi,ssm2518.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices SSM2518 audio amplifier + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: adi,ssm2518 + + reg: + maxItems: 1 + description: | + I2C address of the device. This will either be 0x34 (ADDR pin low) + or 0x35 (ADDR pin high) + + gpios: + maxItems: 1 + description: | + GPIO connected to the nSD pin. If the property is not present + it is assumed that the nSD pin is hardwired to always on. + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@34 { + compatible = "adi,ssm2518"; + reg = <0x34>; + gpios = <&gpio 5 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/adi,ssm3515.yaml b/Documentation/devicetree/bindings/sound/adi,ssm3515.yaml new file mode 100644 index 000000000000..144450df5869 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/adi,ssm3515.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/adi,ssm3515.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices SSM3515 Audio Amplifier + +maintainers: + - Martin Povišer <povik+lin@cutebit.org> + +description: | + SSM3515 is a mono Class-D audio amplifier with digital input. + + https://www.analog.com/media/en/technical-documentation/data-sheets/SSM3515.pdf + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - adi,ssm3515 + + reg: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@14 { + compatible = "adi,ssm3515"; + reg = <0x14>; + #sound-dai-cells = <0>; + sound-name-prefix = "Left Tweeter"; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml index bf1234550343..5db718e4d0e7 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml @@ -9,6 +9,9 @@ title: Amlogic AXG sound card maintainers: - Jerome Brunet <jbrunet@baylibre.com> +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: const: amlogic,axg-sound-card @@ -17,23 +20,12 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array description: list of auxiliary devices - audio-routing: - $ref: /schemas/types.yaml#/definitions/non-unique-string-array - description: - A list of the connections between audio components. Each entry is a - pair of strings, the first being the connection's sink, the second - being the connection's source. - audio-widgets: $ref: /schemas/types.yaml#/definitions/non-unique-string-array description: A list off component DAPM widget. Each entry is a pair of strings, the first being the widget type, the second being the widget name - model: - $ref: /schemas/types.yaml#/definitions/string - description: User specified audio sound card name - patternProperties: "^dai-link-[0-9]+$": type: object @@ -108,7 +100,6 @@ patternProperties: - sound-dai required: - - model - dai-link-0 unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml index b358fd601ed3..d4277d342e69 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml @@ -9,6 +9,9 @@ title: Amlogic GX sound card maintainers: - Jerome Brunet <jbrunet@baylibre.com> +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: items: @@ -18,14 +21,6 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array description: list of auxiliary devices - audio-routing: - $ref: /schemas/types.yaml#/definitions/non-unique-string-array - minItems: 2 - description: |- - A list of the connections between audio components. Each entry is a - pair of strings, the first being the connection's sink, the second - being the connection's source. - audio-widgets: $ref: /schemas/types.yaml#/definitions/non-unique-string-array minItems: 2 @@ -33,10 +28,6 @@ properties: A list off component DAPM widget. Each entry is a pair of strings, the first being the widget type, the second being the widget name - model: - $ref: /schemas/types.yaml#/definitions/string - description: User specified audio sound card name - patternProperties: "^dai-link-[0-9]+$": type: object @@ -86,7 +77,7 @@ required: - model - dai-link-0 -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml index 3de7b36829da..d3ce4de449d5 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml +++ b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml @@ -39,22 +39,4 @@ required: additionalProperties: false -examples: - - | - sound { - compatible = "audio-graph-card2"; - - links = <&cpu_port>; - }; - - cpu { - compatible = "cpu-driver"; - - cpu_port: port { cpu_ep: endpoint { remote-endpoint = <&codec_ep>; }; }; - }; - - codec { - compatible = "codec-driver"; - - port { codec_ep: endpoint { remote-endpoint = <&cpu_ep>; }; }; - }; +... diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml index c87eb91de159..ed31e04ff6a6 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph.yaml +++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml @@ -24,7 +24,11 @@ properties: connection's sink, the second being the connection's source. $ref: /schemas/types.yaml#/definitions/non-unique-string-array widgets: - description: User specified audio sound widgets. + description: | + User specified audio sound widgets. + Each entry is a pair of strings, the first being the type of + widget ("Microphone", "Line", "Headphone", "Speaker"), the + second being the machine specific name for the widget. $ref: /schemas/types.yaml#/definitions/non-unique-string-array convert-rate: $ref: /schemas/sound/dai-params.yaml#/$defs/dai-sample-rate diff --git a/Documentation/devicetree/bindings/sound/audio-iio-aux.yaml b/Documentation/devicetree/bindings/sound/audio-iio-aux.yaml new file mode 100644 index 000000000000..d3cc1ea4a175 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/audio-iio-aux.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/audio-iio-aux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Audio IIO auxiliary + +maintainers: + - Herve Codina <herve.codina@bootlin.com> + +description: + Auxiliary device based on Industrial I/O device channels + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: audio-iio-aux + + io-channels: + description: + Industrial I/O device channels used + + io-channel-names: + description: + Industrial I/O channel names related to io-channels. + These names are used to provides sound controls, widgets and routes names. + + snd-control-invert-range: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + A list of 0/1 flags defining whether or not the related channel is + inverted + items: + enum: [0, 1] + default: 0 + description: | + Invert the sound control value compared to the IIO channel raw value. + - 1: The related sound control value is inverted meaning that the + minimum sound control value correspond to the maximum IIO channel + raw value and the maximum sound control value correspond to the + minimum IIO channel raw value. + - 0: The related sound control value is not inverted meaning that the + minimum (resp maximum) sound control value correspond to the + minimum (resp maximum) IIO channel raw value. + +required: + - compatible + - io-channels + - io-channel-names + +unevaluatedProperties: false + +examples: + - | + iio-aux { + compatible = "audio-iio-aux"; + io-channels = <&iio 0>, <&iio 1>, <&iio 2>, <&iio 3>; + io-channel-names = "CH0", "CH1", "CH2", "CH3"; + /* Invert CH1 and CH2 */ + snd-control-invert-range = <0 1 1 0>; + }; diff --git a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml index 35eef7d818a2..4051c2538caf 100644 --- a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml +++ b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml @@ -19,7 +19,9 @@ allOf: properties: compatible: - const: awinic,aw88395 + enum: + - awinic,aw88395 + - awinic,aw88261 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt index 9d049d4bfd58..b6cc5f6f78c2 100644 --- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt +++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt @@ -29,7 +29,7 @@ The schematics explaining the gpios are as follows: IN2 +---o--+------------+--o---+ OUT2 loop2 relays -The 'loop1' gpio pin controlls two relays, which are either in loop position, +The 'loop1' gpio pin controls two relays, which are either in loop position, meaning that input and output are directly connected, or they are in mixer position, meaning that the signal is passed through the 'Sum' mixer. Similarly for 'loop2'. diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml index 2ab74f995685..4c9acb8d4c4c 100644 --- a/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml @@ -62,7 +62,7 @@ patternProperties: GPIO pin direction. Valid only when 'gpio-ctrl' is 1 0 = Output 1 = Input - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1 default: 1 @@ -71,7 +71,7 @@ patternProperties: GPIO level. Valid only when 'gpio-ctrl' is 1 and 'gpio-dir' is 0 0 = Low 1 = High - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1 default: 0 @@ -80,7 +80,7 @@ patternProperties: GPIO level. Valid only when 'gpio-ctrl' is 1 and 'gpio-dir' is 0 0 = CMOS 1 = Open Drain - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1 default: 0 @@ -90,7 +90,7 @@ patternProperties: and 'gpio-dir' is 0 0 = Non-inverted, Active High 1 = Inverted, Active Low - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1 default: 0 @@ -114,7 +114,7 @@ patternProperties: 0 = High impedance input 1 = Pin acts as a GPIO, direction controlled by 'gpio-dir' 2-7 = Reserved - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 7 default: 0 diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml new file mode 100644 index 000000000000..7a6de938b11d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml @@ -0,0 +1,313 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/cirrus,cs42l43.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic CS42L43 Audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +description: | + The CS42L43 is an audio CODEC with integrated MIPI SoundWire interface + (Version 1.2.1 compliant), I2C, SPI, and I2S/TDM interfaces designed + for portable applications. It provides a high dynamic range, stereo + DAC for headphone output, two integrated Class D amplifiers for + loudspeakers, and two ADCs for wired headset microphone input or + stereo line input. PDM inputs are provided for digital microphones. + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - cirrus,cs42l43 + + reg: + maxItems: 1 + + vdd-p-supply: + description: + Power supply for the high voltage interface. + + vdd-a-supply: + description: + Power supply for internal analog circuits. + + vdd-d-supply: + description: + Power supply for internal digital circuits. Can be internally supplied. + + vdd-io-supply: + description: + Power supply for external interface and internal digital logic. + + vdd-cp-supply: + description: + Power supply for the amplifier 3 and 4 charge pump. + + vdd-amp-supply: + description: + Power supply for amplifier 1 and 2. + + reset-gpios: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + interrupts: + maxItems: 1 + + "#sound-dai-cells": + const: 1 + + clocks: + items: + - description: Synchronous audio clock provided on mclk_in. + + clock-names: + const: mclk + + cirrus,bias-low: + type: boolean + description: + Select a 1.8V headset micbias rather than 2.8V. + + cirrus,bias-sense-microamp: + description: + Current at which the headset micbias sense clamp will engage, 0 to + disable. + enum: [ 0, 14, 23, 41, 50, 60, 68, 86, 95 ] + default: 0 + + cirrus,bias-ramp-ms: + description: + Time in milliseconds the hardware allows for the headset micbias to + ramp up. + enum: [ 10, 40, 90, 170 ] + default: 170 + + cirrus,detect-us: + description: + Time in microseconds the type detection will run for. Long values will + cause more audible effects, but give more accurate detection. + enum: [ 20, 100, 1000, 10000, 50000, 75000, 100000, 200000 ] + default: 10000 + + cirrus,button-automute: + type: boolean + description: + Enable the hardware automuting of decimator 1 when a headset button is + pressed. + + cirrus,buttons-ohms: + description: + Impedance in Ohms for each headset button, these should be listed in + ascending order. + minItems: 1 + maxItems: 6 + + cirrus,tip-debounce-ms: + description: + Software debounce on tip sense triggering in milliseconds. + default: 0 + + cirrus,tip-invert: + type: boolean + description: + Indicates tip detect polarity, inverted implies open-circuit whilst the + jack is inserted. + + cirrus,tip-disable-pullup: + type: boolean + description: + Indicates if the internal pullup on the tip detect should be disabled. + + cirrus,tip-fall-db-ms: + description: + Time in milliseconds a falling edge on the tip detect should be hardware + debounced for. Note the falling edge is considered after the invert. + enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ] + default: 500 + + cirrus,tip-rise-db-ms: + description: + Time in milliseconds a rising edge on the tip detect should be hardware + debounced for. Note the rising edge is considered after the invert. + enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ] + default: 500 + + cirrus,use-ring-sense: + type: boolean + description: + Indicates if the ring sense should be used. + + cirrus,ring-invert: + type: boolean + description: + Indicates ring detect polarity, inverted implies open-circuit whilst the + jack is inserted. + + cirrus,ring-disable-pullup: + type: boolean + description: + Indicates if the internal pullup on the ring detect should be disabled. + + cirrus,ring-fall-db-ms: + description: + Time in milliseconds a falling edge on the ring detect should be hardware + debounced for. Note the falling edge is considered after the invert. + enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ] + default: 500 + + cirrus,ring-rise-db-ms: + description: + Time in milliseconds a rising edge on the ring detect should be hardware + debounced for. Note the rising edge is considered after the invert. + enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ] + default: 500 + + pinctrl: + type: object + $ref: /schemas/pinctrl/pinctrl.yaml# + additionalProperties: false + + properties: + gpio-controller: true + + "#gpio-cells": + const: 2 + + gpio-ranges: + items: + - description: A phandle to the CODEC pinctrl node + minimum: 0 + - const: 0 + - const: 0 + - const: 3 + + patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/cirrus-cs42l43-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/cirrus-cs42l43-state" + additionalProperties: false + + spi: + type: object + $ref: /schemas/spi/spi-controller.yaml# + unevaluatedProperties: false + +$defs: + cirrus-cs42l43-state: + type: object + + allOf: + - $ref: /schemas/pinctrl/pincfg-node.yaml# + - $ref: /schemas/pinctrl/pinmux-node.yaml# + + oneOf: + - required: [ groups ] + - required: [ pins ] + + additionalProperties: false + + properties: + groups: + enum: [ gpio1, gpio2, gpio3, asp, pdmout2, pdmout1, i2c, spi ] + + pins: + enum: [ gpio1, gpio2, gpio3, + asp_dout, asp_fsync, asp_bclk, + pdmout2_clk, pdmout2_data, pdmout1_clk, pdmout1_data, + i2c_sda, i2c_scl, + spi_miso, spi_sck, spi_ssb ] + + function: + enum: [ gpio, spdif, irq, mic-shutter, spk-shutter ] + + drive-strength: + description: Set drive strength in mA + enum: [ 1, 2, 4, 8, 9, 10, 12, 16 ] + + input-debounce: + description: Set input debounce in uS + enum: [ 0, 85 ] + +required: + - compatible + - reg + - vdd-p-supply + - vdd-a-supply + - vdd-io-supply + - vdd-cp-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + cs42l43: codec@1a { + compatible = "cirrus,cs42l43"; + reg = <0x1a>; + + vdd-p-supply = <&vdd5v0>; + vdd-a-supply = <&vdd1v8>; + vdd-io-supply = <&vdd1v8>; + vdd-cp-supply = <&vdd1v8>; + vdd-amp-supply = <&vdd5v0>; + + reset-gpios = <&gpio 0>; + + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&gpio>; + interrupts = <56 IRQ_TYPE_LEVEL_LOW>; + + #sound-dai-cells = <1>; + + clocks = <&clks 0>; + clock-names = "mclk"; + + cs42l43_pins: pinctrl { + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&cs42l43_pins 0 0 3>; + + pinctrl-names = "default"; + pinctrl-0 = <&pinsettings>; + + pinsettings: default-state { + shutter-pins { + groups = "gpio3"; + function = "mic-shutter"; + }; + }; + }; + + spi { + #address-cells = <1>; + #size-cells = <0>; + + cs-gpios = <&cs42l43_pins 1 0>; + + sensor@0 { + compatible = "bosch,bme680"; + reg = <0>; + spi-max-frequency = <1400000>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml index 670b67ec0b61..f7bafbd4f1c2 100644 --- a/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml +++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml @@ -44,6 +44,10 @@ properties: VAHP-supply: description: phandle to voltage regulator of headphone + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + required: - compatible - reg @@ -69,6 +73,13 @@ examples: VA-supply = <®_audio>; VAHP-supply = <®_audio>; reset-gpios = <&gpiog 9 GPIO_ACTIVE_LOW>; + + /* assume audio-graph */ + port { + cpu_endpoint: endpoint { + remote-endpoint = <&cpu_endpoint>; + }; + }; }; }; ... diff --git a/Documentation/devicetree/bindings/sound/cs35l35.txt b/Documentation/devicetree/bindings/sound/cs35l35.txt index 7915897f8a81..e84f30c5c39b 100644 --- a/Documentation/devicetree/bindings/sound/cs35l35.txt +++ b/Documentation/devicetree/bindings/sound/cs35l35.txt @@ -110,7 +110,7 @@ Optional Monitor Signal Format sub-node: See Sections 4.8.2 through 4.8.4 Serial-Port Control in the Datasheet - -cirrus,monitor-signal-format : Sub-node for the Monitor Signaling Formating + -cirrus,monitor-signal-format : Sub-node for the Monitor Signaling Formatting on the I2S Port. Each of the 3 8 bit values in the array contain the settings for depth, location, and frame. diff --git a/Documentation/devicetree/bindings/sound/cs35l36.txt b/Documentation/devicetree/bindings/sound/cs35l36.txt index 912bd162b477..d34117b8558e 100644 --- a/Documentation/devicetree/bindings/sound/cs35l36.txt +++ b/Documentation/devicetree/bindings/sound/cs35l36.txt @@ -33,7 +33,7 @@ Optional properties: one amplifier in the system. If more than one it is best to Hi-Z the ASP port to prevent bus contention on the output signal - - cirrus,boost-ctl-select : Boost conerter control source selection. + - cirrus,boost-ctl-select : Boost converter control source selection. Selects the source of the BST_CTL target VBST voltage for the boost converter to generate. 0x00 - Control Port Value diff --git a/Documentation/devicetree/bindings/sound/cs53l30.txt b/Documentation/devicetree/bindings/sound/cs53l30.txt index 4dbfb8274cd9..dc256adb35a2 100644 --- a/Documentation/devicetree/bindings/sound/cs53l30.txt +++ b/Documentation/devicetree/bindings/sound/cs53l30.txt @@ -30,7 +30,7 @@ Optional properties: * frame using two different ways: * 1) Normal I2S mode on two data pins -- each SDOUT * carries 2-channel data in the same time. - * 2) TDM mode on one signle data pin -- SDOUT1 carries + * 2) TDM mode on one single data pin -- SDOUT1 carries * 4-channel data per frame. Example: diff --git a/Documentation/devicetree/bindings/sound/da7219.txt b/Documentation/devicetree/bindings/sound/da7219.txt deleted file mode 100644 index add1caf26ac2..000000000000 --- a/Documentation/devicetree/bindings/sound/da7219.txt +++ /dev/null @@ -1,112 +0,0 @@ -Dialog Semiconductor DA7219 Audio Codec bindings - -DA7219 is an audio codec with advanced accessory detect features. - -====== - -Required properties: -- compatible : Should be "dlg,da7219" -- reg: Specifies the I2C slave address - -- interrupts : IRQ line info for DA7219. - (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for - further information relating to interrupt properties) - -- VDD-supply: VDD power supply for the device -- VDDMIC-supply: VDDMIC power supply for the device -- VDDIO-supply: VDDIO power supply for the device - (See Documentation/devicetree/bindings/regulator/regulator.txt for further - information relating to regulators) - -Optional properties: -- interrupt-names : Name associated with interrupt line. Should be "wakeup" if - interrupt is to be used to wake system, otherwise "irq" should be used. -- wakeup-source: Flag to indicate this device can wake system (suspend/resume). - -- #clock-cells : Should be set to '<1>', two clock sources provided; -- clock-output-names : Names given for DAI clock outputs (WCLK & BCLK); - -- clocks : phandle and clock specifier for codec MCLK. -- clock-names : Clock name string for 'clocks' attribute, should be "mclk". - -- dlg,micbias-lvl : Voltage (mV) for Mic Bias - [<1600>, <1800>, <2000>, <2200>, <2400>, <2600>] -- dlg,mic-amp-in-sel : Mic input source type - ["diff", "se_p", "se_n"] - -Deprecated properties: -- dlg,ldo-lvl : Required internal LDO voltage (mV) level for digital engine - (LDO unavailable in production HW so property no longer required). - -====== - -Child node - 'da7219_aad': - -Optional properties: -- dlg,micbias-pulse-lvl : Mic bias higher voltage pulse level (mV). - [<2800>, <2900>] -- dlg,micbias-pulse-time : Mic bias higher voltage pulse duration (ms) -- dlg,btn-cfg : Periodic button press measurements for 4-pole jack (ms) - [<2>, <5>, <10>, <50>, <100>, <200>, <500>] -- dlg,mic-det-thr : Impedance threshold for mic detection measurement (Ohms) - [<200>, <500>, <750>, <1000>] -- dlg,jack-ins-deb : Debounce time for jack insertion (ms) - [<5>, <10>, <20>, <50>, <100>, <200>, <500>, <1000>] -- dlg,jack-det-rate: Jack type detection latency (3/4 pole) - ["32ms_64ms", "64ms_128ms", "128ms_256ms", "256ms_512ms"] -- dlg,jack-rem-deb : Debounce time for jack removal (ms) - [<1>, <5>, <10>, <20>] -- dlg,a-d-btn-thr : Impedance threshold between buttons A and D - [0x0 - 0xFF] -- dlg,d-b-btn-thr : Impedance threshold between buttons D and B - [0x0 - 0xFF] -- dlg,b-c-btn-thr : Impedance threshold between buttons B and C - [0x0 - 0xFF] -- dlg,c-mic-btn-thr : Impedance threshold between button C and Mic - [0x0 - 0xFF] -- dlg,btn-avg : Number of 8-bit readings for averaged button measurement - [<1>, <2>, <4>, <8>] -- dlg,adc-1bit-rpt : Repeat count for 1-bit button measurement - [<1>, <2>, <4>, <8>] - -====== - -Example: - - codec: da7219@1a { - compatible = "dlg,da7219"; - reg = <0x1a>; - - interrupt-parent = <&gpio6>; - interrupts = <11 IRQ_TYPE_LEVEL_LOW>; - - VDD-supply = <®_audio>; - VDDMIC-supply = <®_audio>; - VDDIO-supply = <®_audio>; - - #clock-cells = <1>; - clock-output-names = "dai-wclk", "dai-bclk"; - - clocks = <&clks 201>; - clock-names = "mclk"; - - dlg,ldo-lvl = <1200>; - dlg,micbias-lvl = <2600>; - dlg,mic-amp-in-sel = "diff"; - - da7219_aad { - dlg,btn-cfg = <50>; - dlg,mic-det-thr = <500>; - dlg,jack-ins-deb = <20>; - dlg,jack-det-rate = "32ms_64ms"; - dlg,jack-rem-deb = <1>; - - dlg,a-d-btn-thr = <0xa>; - dlg,d-b-btn-thr = <0x16>; - dlg,b-c-btn-thr = <0x21>; - dlg,c-mic-btn-thr = <0x3E>; - - dlg,btn-avg = <4>; - dlg,adc-1bit-rpt = <1>; - }; - }; diff --git a/Documentation/devicetree/bindings/sound/dialog,da7219.yaml b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml new file mode 100644 index 000000000000..eb7d219e2c86 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml @@ -0,0 +1,237 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/dialog,da7219.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dialog Semiconductor DA7219 Audio Codec + +maintainers: + - David Rau <David.Rau.opensource@dm.renesas.com> + +description: + The DA7219 is an ultra low-power audio codec with + in-built advanced accessory detection (AAD) for mobile + computing and accessory applications, which supports + sample rates up to 96 kHz at 24-bit resolution. + +properties: + compatible: + const: dlg,da7219 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + VDD-supply: + description: + VDD power supply for the device. + + VDDMIC-supply: + description: + VDDMIC power supply for the device. + + VDDIO-supply: + description: + VDDIO power supply for the device. + + interrupt-names: + description: + Should be "wakeup" if interrupt is to be used to wake system, + otherwise "irq" should be used. + enum: + - wakeup + - irq + + wakeup-source: + type: boolean + description: + Flag to indicate this device can wake system (suspend/resume). + + "#clock-cells": + const: 1 + + clock-output-names: + minItems: 2 + maxItems: 2 + description: + Name given for DAI WCLK and BCLK outputs. + + clocks: + maxItems: 1 + description: + phandle and clock specifier for codec MCLK. + + clock-names: + const: mclk + + dlg,micbias-lvl: + enum: [1600, 1800, 2000, 2200, 2400, 2600] + description: + Voltage (mV) for Mic Bias. + $ref: /schemas/types.yaml#/definitions/uint32 + + dlg,mic-amp-in-sel: + enum: [diff, se_p, se_n] + description: + Mic input source type. + + diff - Differential. + + se_p - MIC_P. + Positive differential analog microphone input. + + se_n - MIC_N. + Negative differential analog microphone input. + $ref: /schemas/types.yaml#/definitions/string + + da7219_aad: + type: object + description: + Configuration of advanced accessory detection. + properties: + dlg,micbias-pulse-lvl: + enum: [2800, 2900] + description: + Mic bias higher voltage pulse level (mV). + $ref: /schemas/types.yaml#/definitions/uint32 + + dlg,micbias-pulse-time: + description: + Mic bias higher voltage pulse duration (ms). + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + + dlg,btn-cfg: + enum: [2, 5, 10, 50, 100, 200, 500] + description: + Periodic button press measurements for 4-pole jack (ms). + $ref: /schemas/types.yaml#/definitions/uint32 + + dlg,mic-det-thr: + enum: [200, 500, 750, 1000] + description: + Impedance threshold for mic detection measurement (Ohms). + $ref: /schemas/types.yaml#/definitions/uint32 + + dlg,jack-ins-deb: + enum: [5, 10, 20, 50, 100, 200, 500, 1000] + description: + Debounce time for jack insertion (ms). + $ref: /schemas/types.yaml#/definitions/uint32 + + dlg,jack-ins-det-pty: + enum: [low, high] + description: + Polarity for jack insertion detection. + $ref: /schemas/types.yaml#/definitions/string + + dlg,jack-det-rate: + enum: ["32_64", "64_128", "128_256", "256_512"] + description: + Jack type (3/4 pole) detection latency (ms). + $ref: /schemas/types.yaml#/definitions/string + + dlg,jack-rem-deb: + enum: [1, 5, 10, 20] + description: + Debounce time for jack removal (ms). + $ref: /schemas/types.yaml#/definitions/uint32 + + dlg,a-d-btn-thr: + description: + Impedance threshold between buttons A and D. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + + dlg,d-b-btn-thr: + description: + Impedance threshold between buttons D and B. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + + dlg,b-c-btn-thr: + description: + Impedance threshold between buttons B and C. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + + dlg,c-mic-btn-thr: + description: + Impedance threshold between button C and Mic. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + + dlg,btn-avg: + enum: [1, 2, 4, 8] + description: + Number of 8-bit readings for averaged button measurement. + $ref: /schemas/types.yaml#/definitions/uint32 + + dlg,adc-1bit-rpt: + enum: [1, 2, 4, 8] + description: + Repeat count for 1-bit button measurement. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - interrupts + - VDD-supply + - VDDMIC-supply + - VDDIO-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec: da7219@1a { + compatible = "dlg,da7219"; + reg = <0x1a>; + + interrupt-parent = <&gpio6>; + interrupts = <11 IRQ_TYPE_LEVEL_LOW>; + + VDD-supply = <&vdd_reg>; + VDDMIC-supply = <&vddmic_reg>; + VDDIO-supply = <&vddio_reg>; + + #clock-cells = <1>; + clock-output-names = "da7219-dai-wclk", "da7219-dai-bclk"; + + clocks = <&clks 201>; + clock-names = "mclk"; + + dlg,micbias-lvl = <2600>; + dlg,mic-amp-in-sel = "diff"; + + da7219_aad { + dlg,btn-cfg = <50>; + dlg,mic-det-thr = <500>; + dlg,jack-ins-deb = <20>; + dlg,jack-ins-det-pty = "low"; + dlg,jack-det-rate = "32_64"; + dlg,jack-rem-deb = <1>; + + dlg,a-d-btn-thr = <0xa>; + dlg,d-b-btn-thr = <0x16>; + dlg,b-c-btn-thr = <0x21>; + dlg,c-mic-btn-thr = <0x3E>; + + dlg,btn-avg = <4>; + dlg,adc-1bit-rpt = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt index 0a2480aeecf0..90112ca1ff42 100644 --- a/Documentation/devicetree/bindings/sound/fsl,esai.txt +++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt @@ -44,7 +44,7 @@ Required properties: - fsl,esai-synchronous: This is a boolean property. If present, indicating that ESAI would work in the synchronous mode, which means all the settings for Receiving would be - duplicated from Transmition related registers. + duplicated from Transmission related registers. Optional properties: diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml index e847611a85f7..188f38baddec 100644 --- a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml @@ -17,6 +17,9 @@ description: | such as SAI, MICFIL, .etc through building rpmsg channels between Cortex-A and Cortex-M. +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: @@ -25,10 +28,7 @@ properties: - fsl,imx8mm-rpmsg-audio - fsl,imx8mp-rpmsg-audio - fsl,imx8ulp-rpmsg-audio - - model: - $ref: /schemas/types.yaml#/definitions/string - description: User specified audio sound card name + - fsl,imx93-rpmsg-audio clocks: items: @@ -65,13 +65,6 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle to a node of audio codec - audio-routing: - $ref: /schemas/types.yaml#/definitions/non-unique-string-array - description: | - A list of the connections between audio components. Each entry is a - pair of strings, the first being the connection's sink, the second - being the connection's source. - fsl,enable-lpa: $ref: /schemas/types.yaml#/definitions/flag description: enable low power audio path. @@ -100,9 +93,8 @@ properties: required: - compatible - - model -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt index 8b4f4015cfe4..4e8dbc5abfd1 100644 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt @@ -46,6 +46,8 @@ The compatible list for this generic sound card currently: "fsl,imx-audio-wm8958" + "fsl,imx-audio-nau8822" + Required properties: - compatible : Contains one of entries in the compatible list. diff --git a/Documentation/devicetree/bindings/sound/google,chv3-codec.yaml b/Documentation/devicetree/bindings/sound/google,chv3-codec.yaml new file mode 100644 index 000000000000..5329dc140b1c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/google,chv3-codec.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/google,chv3-codec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Google Chameleon v3 audio codec + +maintainers: + - Paweł Anikiel <pan@semihalf.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: google,chv3-codec + + "#sound-dai-cells": + const: 0 + +required: + - compatible + +additionalProperties: false + +examples: + - | + audio-codec { + compatible = "google,chv3-codec"; + }; diff --git a/Documentation/devicetree/bindings/sound/google,chv3-i2s.yaml b/Documentation/devicetree/bindings/sound/google,chv3-i2s.yaml new file mode 100644 index 000000000000..3ce910f44d39 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/google,chv3-i2s.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/google,chv3-i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Google Chameleon v3 I2S device + +maintainers: + - Paweł Anikiel <pan@semihalf.com> + +description: | + I2S device for the Google Chameleon v3. The device handles both RX + and TX using a producer/consumer ring buffer design. + +properties: + compatible: + const: google,chv3-i2s + + reg: + items: + - description: core registers + - description: irq registers + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2s@c0060300 { + compatible = "google,chv3-i2s"; + reg = <0xc0060300 0x100>, + <0xc0060f00 0x10>; + interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml index 67ccddd44489..bac940553965 100644 --- a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml +++ b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml @@ -7,29 +7,21 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Google SC7180-Trogdor ASoC sound card driver maintainers: - - Rohit kumar <rohitkr@codeaurora.org> + - Rohit kumar <quic_rohkumar@quicinc.com> - Cheng-Yi Chiang <cychiang@chromium.org> description: This binding describes the SC7180 sound card which uses LPASS for audio. +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: - google,sc7180-trogdor - google,sc7180-coachz - audio-routing: - $ref: /schemas/types.yaml#/definitions/non-unique-string-array - description: - A list of the connections between audio components. Each entry is a - pair of strings, the first being the connection's sink, the second - being the connection's source. - - model: - $ref: /schemas/types.yaml#/definitions/string - description: User specified audio sound card name - "#address-cells": const: 1 @@ -74,7 +66,8 @@ patternProperties: properties: sound-dai: - maxItems: 1 + minItems: 1 + maxItems: 4 required: - link-name @@ -85,11 +78,10 @@ patternProperties: required: - compatible - - model - "#address-cells" - "#size-cells" -additionalProperties: false +unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml index 0b1a01a4c14e..ec4b6e547ca6 100644 --- a/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml +++ b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml @@ -13,22 +13,14 @@ maintainers: description: This binding describes the SC7280 sound card which uses LPASS for audio. +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: - google,sc7280-herobrine - audio-routing: - $ref: /schemas/types.yaml#/definitions/non-unique-string-array - description: - A list of the connections between audio components. Each entry is a - pair of strings, the first being the connection's sink, the second - being the connection's source. - - model: - $ref: /schemas/types.yaml#/definitions/string - description: User specified audio sound card name - "#address-cells": const: 1 @@ -97,11 +89,10 @@ patternProperties: required: - compatible - - model - "#address-cells" - "#size-cells" -additionalProperties: false +unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/sound/gtm601.txt b/Documentation/devicetree/bindings/sound/gtm601.txt deleted file mode 100644 index efa32a486c4a..000000000000 --- a/Documentation/devicetree/bindings/sound/gtm601.txt +++ /dev/null @@ -1,19 +0,0 @@ -GTM601 UMTS modem audio interface CODEC - -This device has no configuration interface. The sample rate and channels are -based on the compatible string - "option,gtm601" = 8kHz mono - "broadmobi,bm818" = 48KHz stereo - -Required properties: - - - compatible : one of - "option,gtm601" - "broadmobi,bm818" - - -Example: - -codec: gtm601_codec { - compatible = "option,gtm601"; -}; diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml index b6f5d486600e..f7ad5ea2491e 100644 --- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml @@ -9,23 +9,14 @@ title: NXP i.MX audio sound card. maintainers: - Shengjiu Wang <shengjiu.wang@nxp.com> +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: - fsl,imx-audio-card - model: - $ref: /schemas/types.yaml#/definitions/string - description: User specified audio sound card name - - audio-routing: - $ref: /schemas/types.yaml#/definitions/non-unique-string-array - description: - A list of the connections between audio components. Each entry is a - pair of strings, the first being the connection's sink, the second - being the connection's source. Valid names could be power supplies, - MicBias of codec and the jacks on the board. - patternProperties: ".*-dai-link$": description: @@ -84,9 +75,8 @@ patternProperties: required: - compatible - - model -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/sound/ingenic,aic.yaml b/Documentation/devicetree/bindings/sound/ingenic,aic.yaml index c59a7cd9eaa9..d15c000f14e1 100644 --- a/Documentation/devicetree/bindings/sound/ingenic,aic.yaml +++ b/Documentation/devicetree/bindings/sound/ingenic,aic.yaml @@ -23,6 +23,7 @@ properties: - ingenic,jz4760-i2s - ingenic,jz4770-i2s - ingenic,jz4780-i2s + - ingenic,x1000-i2s - items: - const: ingenic,jz4725b-i2s - const: ingenic,jz4740-i2s diff --git a/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml new file mode 100644 index 000000000000..61e8babed402 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/loongson,ls-audio-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson 7axxx/2kxxx ASoC audio sound card driver + +maintainers: + - Yingkun Meng <mengyingkun@loongson.cn> + +description: + The binding describes the sound card present in loongson + 7axxx/2kxxx platform. The sound card is an ASoC component + which uses Loongson I2S controller to transfer the audio data. + +properties: + compatible: + const: loongson,ls-audio-card + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + mclk-fs: + $ref: simple-card.yaml#/definitions/mclk-fs + + cpu: + description: Holds subnode which indicates cpu dai. + type: object + additionalProperties: false + properties: + sound-dai: + maxItems: 1 + required: + - sound-dai + + codec: + description: Holds subnode which indicates codec dai. + type: object + additionalProperties: false + properties: + sound-dai: + maxItems: 1 + required: + - sound-dai + +required: + - compatible + - model + - mclk-fs + - cpu + - codec + +additionalProperties: false + +examples: + - | + sound { + compatible = "loongson,ls-audio-card"; + model = "loongson-audio"; + mclk-fs = <512>; + + cpu { + sound-dai = <&i2s>; + }; + codec { + sound-dai = <&es8323>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/max9892x.txt b/Documentation/devicetree/bindings/sound/max9892x.txt deleted file mode 100644 index 98cb9ba5b328..000000000000 --- a/Documentation/devicetree/bindings/sound/max9892x.txt +++ /dev/null @@ -1,44 +0,0 @@ -Maxim Integrated MAX98925/MAX98926/MAX98927 Speaker Amplifier - -This device supports I2C. - -Required properties: - - - compatible : should be one of the following - - "maxim,max98925" - - "maxim,max98926" - - "maxim,max98927" - - - vmon-slot-no : slot number used to send voltage information - or in inteleave mode this will be used as - interleave slot. - MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0 - MAX98927 slot range : 0 ~ 15, Default : 0 - - - imon-slot-no : slot number used to send current information - MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0 - MAX98927 slot range : 0 ~ 15, Default : 0 - - - interleave-mode : When using two MAX9892X in a system it is - possible to create ADC data that that will - overflow the frame size. Digital Audio Interleave - mode provides a means to output VMON and IMON data - from two devices on a single DOUT line when running - smaller frames sizes such as 32 BCLKS per LRCLK or - 48 BCLKS per LRCLK. - Range : 0 (off), 1 (on), Default : 0 - - - reg : the I2C address of the device for I2C - -Optional properties: - - reset-gpios : GPIO to reset the device - -Example: - -codec: max98927@3a { - compatible = "maxim,max98927"; - vmon-slot-no = <0>; - imon-slot-no = <1>; - interleave-mode = <0>; - reg = <0x3a>; -}; diff --git a/Documentation/devicetree/bindings/sound/maxim,max98925.yaml b/Documentation/devicetree/bindings/sound/maxim,max98925.yaml new file mode 100644 index 000000000000..32fd86204a7a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/maxim,max98925.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/maxim,max98925.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim Integrated MAX98925/MAX98926/MAX98927 speaker amplifier + +maintainers: + - Ryan Lee <ryans.lee@maximintegrated.com> + +properties: + compatible: + enum: + - maxim,max98925 + - maxim,max98926 + - maxim,max98927 + + reg: + maxItems: 1 + + reset-gpios: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + + vmon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 30 + default: 0 + description: + Slot number used to send voltage information or in inteleave mode this + will be used as interleave slot. + + imon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 30 + default: 0 + description: + Slot number used to send current information. + + maxim,interleave-mode: + type: boolean + description: + When using two MAX9892X in a system it is possible to create ADC data + that will overflow the frame size. When enabled, the Digital Audio + Interleave mode provides a means to output VMON and IMON data from two + devices on a single DOUT line when running smaller frames sizes such as + 32 BCLKS per LRCLK or 48 BCLKS per LRCLK. + +required: + - compatible + - reg + +allOf: + - $ref: dai-common.yaml# + - if: + properties: + compatible: + contains: + enum: + - maxim,max98927 + then: + properties: + vmon-slot-no: + minimum: 0 + maximum: 15 + + imon-slot-no: + minimum: 0 + maximum: 15 + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + #include <dt-bindings/gpio/gpio.h> + audio-codec@3a { + compatible = "maxim,max98927"; + reg = <0x3a>; + #sound-dai-cells = <0>; + + pinctrl-0 = <&speaker_default>; + pinctrl-names = "default"; + + reset-gpios = <&tlmm 69 GPIO_ACTIVE_LOW>; + + vmon-slot-no = <1>; + imon-slot-no = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt7986-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt7986-afe.yaml new file mode 100644 index 000000000000..398efdfe00f5 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mediatek,mt7986-afe.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mediatek,mt7986-afe.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek AFE PCM controller for MT7986 + +maintainers: + - Maso Huang <maso.huang@mediatek.com> + +properties: + compatible: + oneOf: + - const: mediatek,mt7986-afe + - items: + - enum: + - mediatek,mt7981-afe + - mediatek,mt7988-afe + - const: mediatek,mt7986-afe + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 5 + items: + - description: audio bus clock + - description: audio 26M clock + - description: audio intbus clock + - description: audio hopping clock + - description: audio pll clock + - description: mux for pcm_mck + - description: audio i2s/pcm mck + + clock-names: + minItems: 5 + items: + - const: bus_ck + - const: 26m_ck + - const: l_ck + - const: aud_ck + - const: eg2_ck + - const: sel + - const: i2s_m + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +allOf: + - if: + properties: + compatible: + contains: + const: mediatek,mt7986-afe + then: + properties: + clocks: + items: + - description: audio bus clock + - description: audio 26M clock + - description: audio intbus clock + - description: audio hopping clock + - description: audio pll clock + clock-names: + items: + - const: bus_ck + - const: 26m_ck + - const: l_ck + - const: aud_ck + - const: eg2_ck + + - if: + properties: + compatible: + contains: + const: mediatek,mt7981-afe + then: + properties: + clocks: + items: + - description: audio bus clock + - description: audio 26M clock + - description: audio intbus clock + - description: audio hopping clock + - description: audio pll clock + - description: mux for pcm_mck + clock-names: + items: + - const: bus_ck + - const: 26m_ck + - const: l_ck + - const: aud_ck + - const: eg2_ck + - const: sel + + - if: + properties: + compatible: + contains: + const: mediatek,mt7988-afe + then: + properties: + clocks: + items: + - description: audio bus clock + - description: audio 26M clock + - description: audio intbus clock + - description: audio hopping clock + - description: audio pll clock + - description: mux for pcm_mck + - description: audio i2s/pcm mck + clock-names: + items: + - const: bus_ck + - const: 26m_ck + - const: l_ck + - const: aud_ck + - const: eg2_ck + - const: sel + - const: i2s_m + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/mt7986-clk.h> + + afe@11210000 { + compatible = "mediatek,mt7986-afe"; + reg = <0x11210000 0x9000>; + interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&infracfg_ao CLK_INFRA_AUD_BUS_CK>, + <&infracfg_ao CLK_INFRA_AUD_26M_CK>, + <&infracfg_ao CLK_INFRA_AUD_L_CK>, + <&infracfg_ao CLK_INFRA_AUD_AUD_CK>, + <&infracfg_ao CLK_INFRA_AUD_EG2_CK>; + clock-names = "bus_ck", + "26m_ck", + "l_ck", + "aud_ck", + "eg2_ck"; + assigned-clocks = <&topckgen CLK_TOP_A1SYS_SEL>, + <&topckgen CLK_TOP_AUD_L_SEL>, + <&topckgen CLK_TOP_A_TUNER_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_APLL2_D4>, + <&apmixedsys CLK_APMIXED_APLL2>, + <&topckgen CLK_TOP_APLL2_D4>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml new file mode 100644 index 000000000000..09247ceea3f7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mediatek,mt7986-wm8960.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek MT7986 sound card with WM8960 codec + +maintainers: + - Maso Huang <maso.huang@mediatek.com> + +allOf: + - $ref: sound-card-common.yaml# + +properties: + compatible: + const: mediatek,mt7986-wm8960-sound + + platform: + type: object + additionalProperties: false + properties: + sound-dai: + description: The phandle of MT7986 platform. + maxItems: 1 + required: + - sound-dai + + codec: + type: object + additionalProperties: false + properties: + sound-dai: + description: The phandle of wm8960 codec. + maxItems: 1 + required: + - sound-dai + +unevaluatedProperties: false + +required: + - compatible + - audio-routing + - platform + - codec + +examples: + - | + sound { + compatible = "mediatek,mt7986-wm8960-sound"; + model = "mt7986-wm8960"; + audio-routing = + "Headphone", "HP_L", + "Headphone", "HP_R", + "LINPUT1", "AMIC", + "RINPUT1", "AMIC"; + + platform { + sound-dai = <&afe>; + }; + + codec { + sound-dai = <&wm8960>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml index 82ccb32f08f2..90520f89208b 100644 --- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml @@ -25,10 +25,20 @@ properties: reset-names: const: audiosys + memory-region: + maxItems: 1 + description: | + Shared memory region for AFE memif. A "shared-dma-pool". + See ../reserved-memory/reserved-memory.yaml for details. + mediatek,topckgen: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of the mediatek topckgen controller + mediatek,infracfg: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the mediatek infracfg controller + power-domains: maxItems: 1 @@ -52,6 +62,11 @@ properties: - description: mux for i2si1_mck - description: mux for i2si2_mck - description: audio 26m clock + - description: audio pll1 divide 4 + - description: audio pll2 divide 4 + - description: clock divider for iec + - description: mux for a2sys clock + - description: mux for aud_iec clock-names: items: @@ -63,16 +78,21 @@ properties: - const: apll12_div2 - const: apll12_div3 - const: apll12_div9 - - const: a1sys_hp_sel - - const: aud_intbus_sel - - const: audio_h_sel - - const: audio_local_bus_sel - - const: dptx_m_sel - - const: i2so1_m_sel - - const: i2so2_m_sel - - const: i2si1_m_sel - - const: i2si2_m_sel + - const: top_a1sys_hp + - const: top_aud_intbus + - const: top_audio_h + - const: top_audio_local_bus + - const: top_dptx + - const: top_i2so1 + - const: top_i2so2 + - const: top_i2si1 + - const: top_i2si2 - const: adsp_audio_26m + - const: apll1_d4 + - const: apll2_d4 + - const: apll12_div4 + - const: top_a2sys + - const: top_aud_iec mediatek,etdm-in1-cowork-source: $ref: /schemas/types.yaml#/definitions/uint32 @@ -121,7 +141,7 @@ patternProperties: maxItems: 16 description: This is a list of channel IDs which should be disabled. - By default, all data received from ETDM pins will be outputed to + By default, all data received from ETDM pins will be outputted to memory. etdm in supports disable_out in direct mode(w/o interconn), so user can disable the specified channels by the property. uniqueItems: true @@ -144,6 +164,7 @@ required: - resets - reset-names - mediatek,topckgen + - mediatek,infracfg - power-domains - clocks - clock-names @@ -161,7 +182,9 @@ examples: interrupts = <GIC_SPI 822 IRQ_TYPE_LEVEL_HIGH 0>; resets = <&watchdog 14>; reset-names = "audiosys"; + memory-region = <&snd_dma_mem_reserved>; mediatek,topckgen = <&topckgen>; + mediatek,infracfg = <&infracfg_ao>; power-domains = <&spm 13>; //MT8188_POWER_DOMAIN_AUDIO mediatek,etdm-in2-cowork-source = <2>; mediatek,etdm-out2-cowork-source = <0>; @@ -184,7 +207,12 @@ examples: <&topckgen 78>, //CLK_TOP_I2SO2 <&topckgen 79>, //CLK_TOP_I2SI1 <&topckgen 80>, //CLK_TOP_I2SI2 - <&adsp_audio26m 0>; //CLK_AUDIODSP_AUDIO26M + <&adsp_audio26m 0>, //CLK_AUDIODSP_AUDIO26M + <&topckgen 132>, //CLK_TOP_APLL1_D4 + <&topckgen 133>, //CLK_TOP_APLL2_D4 + <&topckgen 183>, //CLK_TOP_APLL12_CK_DIV4 + <&topckgen 84>, //CLK_TOP_A2SYS + <&topckgen 82>; //CLK_TOP_AUD_IEC>; clock-names = "clk26m", "apll1", "apll2", @@ -193,16 +221,21 @@ examples: "apll12_div2", "apll12_div3", "apll12_div9", - "a1sys_hp_sel", - "aud_intbus_sel", - "audio_h_sel", - "audio_local_bus_sel", - "dptx_m_sel", - "i2so1_m_sel", - "i2so2_m_sel", - "i2si1_m_sel", - "i2si2_m_sel", - "adsp_audio_26m"; + "top_a1sys_hp", + "top_aud_intbus", + "top_audio_h", + "top_audio_local_bus", + "top_dptx", + "top_i2so1", + "top_i2so2", + "top_i2si1", + "top_i2si2", + "adsp_audio_26m", + "apll1_d4", + "apll2_d4", + "apll12_div4", + "top_a2sys", + "top_aud_iec"; }; ... diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml index 6640272b3f4f..43b3b67bdf3b 100644 --- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml @@ -9,21 +9,19 @@ title: MediaTek MT8188 ASoC sound card maintainers: - Trevor Wu <trevor.wu@mediatek.com> +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: - const: mediatek,mt8188-mt6359-evb - - model: - $ref: /schemas/types.yaml#/definitions/string - description: User specified audio sound card name + enum: + - mediatek,mt8188-mt6359-evb + - mediatek,mt8188-nau8825 audio-routing: - $ref: /schemas/types.yaml#/definitions/non-unique-string-array description: - A list of the connections between audio components. Each entry is a - sink/source pair of strings. Valid names could be the input or output - widgets of audio components, power supplies, MicBias of codec and the - software switch. + Valid names could be the input or output widgets of audio components, + power supplies, MicBias of codec and the software switch. mediatek,platform: $ref: /schemas/types.yaml#/definitions/phandle @@ -42,7 +40,6 @@ patternProperties: we are going to update parameters in this node. items: enum: - - ADDA_BE - DPTX_BE - ETDM1_IN_BE - ETDM2_IN_BE @@ -62,13 +59,30 @@ patternProperties: required: - sound-dai + dai-format: + description: audio format. + items: + enum: + - i2s + - right_j + - left_j + - dsp_a + - dsp_b + + mediatek,clk-provider: + $ref: /schemas/types.yaml#/definitions/string + description: Indicates dai-link clock master. + items: + enum: + - cpu + - codec + additionalProperties: false required: - link-name - - codec -additionalProperties: false +unevaluatedProperties: false required: - compatible @@ -78,6 +92,7 @@ examples: - | sound { compatible = "mediatek,mt8188-mt6359-evb"; + model = "MT6359-EVB"; mediatek,platform = <&afe>; pinctrl-names = "default"; pinctrl-0 = <&aud_pins_default>; @@ -87,7 +102,8 @@ examples: "AIN1", "Headset Mic"; dai-link-0 { link-name = "ETDM3_OUT_BE"; - + dai-format = "i2s"; + mediatek,clk-provider = "cpu"; codec { sound-dai = <&hdmi0>; }; diff --git a/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml b/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml index 9b40268537cb..9aa65c975c4e 100644 --- a/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml +++ b/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml @@ -56,13 +56,9 @@ properties: items: items: - description: value for DS line + enum: [0, 1] - description: value for sampling edge - anyOf: - - enum: - - [0, 0] - - [0, 1] - - [1, 0] - - [1, 1] + enum: [0, 1] minItems: 1 maxItems: 4 uniqueItems: true diff --git a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt index 560762e0a168..f548e6a58240 100644 --- a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt +++ b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt @@ -1,7 +1,7 @@ Mediatek AFE PCM controller for mt2701 Required properties: -- compatible: should be one of the followings. +- compatible: should be one of the following. - "mediatek,mt2701-audio" - "mediatek,mt7622-audio" - interrupts: should contain AFE and ASYS interrupts diff --git a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml index d5adf07d46e0..5c8dba2b3a81 100644 --- a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml +++ b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml @@ -111,7 +111,7 @@ patternProperties: $ref: /schemas/types.yaml#/definitions/uint32 description: | etdm modules can share the same external clock pin. Specify - which etdm clock source is required by this etdm in moudule. + which etdm clock source is required by this etdm in module. enum: - 0 # etdm1_in - 1 # etdm2_in @@ -122,7 +122,7 @@ patternProperties: $ref: /schemas/types.yaml#/definitions/uint32 description: | etdm modules can share the same external clock pin. Specify - which etdm clock source is required by this etdm out moudule. + which etdm clock source is required by this etdm out module. enum: - 0 # etdm1_in - 1 # etdm2_in diff --git a/Documentation/devicetree/bindings/sound/nau8315.txt b/Documentation/devicetree/bindings/sound/nau8315.txt deleted file mode 100644 index 1cd94517d45e..000000000000 --- a/Documentation/devicetree/bindings/sound/nau8315.txt +++ /dev/null @@ -1,24 +0,0 @@ -Nuvoton NAU8315 Mono Class-D Amplifier - -Required properties: -- compatible : "nuvoton,nau8315" - "nuvoton,nau8318" - -Optional properties: -- enable-gpios : GPIO specifier for the chip's device enable input(EN) pin. - If this option is not specified then driver does not manage - the pin state (e.g. chip is always on). - -Example: - -#include <dt-bindings/gpio/gpio.h> - -nau8315 { - compatible = "nuvoton,nau8315"; - enable-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>; -}; - -nau8318 { - compatible = "nuvoton,nau8318"; - enable-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>; -}; diff --git a/Documentation/devicetree/bindings/sound/nau8540.txt b/Documentation/devicetree/bindings/sound/nau8540.txt deleted file mode 100644 index 307a76528320..000000000000 --- a/Documentation/devicetree/bindings/sound/nau8540.txt +++ /dev/null @@ -1,16 +0,0 @@ -NAU85L40 audio CODEC - -This device supports I2C only. - -Required properties: - - - compatible : "nuvoton,nau8540" - - - reg : the I2C address of the device. - -Example: - -codec: nau8540@1c { - compatible = "nuvoton,nau8540"; - reg = <0x1c>; -}; diff --git a/Documentation/devicetree/bindings/sound/nau8810.txt b/Documentation/devicetree/bindings/sound/nau8810.txt deleted file mode 100644 index 7deaa452b200..000000000000 --- a/Documentation/devicetree/bindings/sound/nau8810.txt +++ /dev/null @@ -1,17 +0,0 @@ -NAU8810/NAU8812/NAU8814 audio CODEC - -This device supports I2C only. - -Required properties: - - - compatible : One of "nuvoton,nau8810" or "nuvoton,nau8812" or - "nuvoton,nau8814" - - - reg : the I2C address of the device. - -Example: - -codec: nau8810@1a { - compatible = "nuvoton,nau8810"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/nau8821.txt b/Documentation/devicetree/bindings/sound/nau8821.txt deleted file mode 100644 index 7c84e7c7327a..000000000000 --- a/Documentation/devicetree/bindings/sound/nau8821.txt +++ /dev/null @@ -1,55 +0,0 @@ -Nuvoton NAU88L21 audio codec - -This device supports I2C only. - -Required properties: - - compatible : Must be "nuvoton,nau8821" - - - reg : the I2C address of the device. This is either 0x1B (CSB=0) or 0x54 (CSB=1). - -Optional properties: - - nuvoton,jkdet-enable: Enable jack detection via JKDET pin. - - nuvoton,jkdet-pull-enable: Enable JKDET pin pull. If set - pin pull enabled, - otherwise pin in high impedance state. - - nuvoton,jkdet-pull-up: Pull-up JKDET pin. If set then JKDET pin is pull up, otherwise pull down. - - nuvoton,jkdet-polarity: JKDET pin polarity. 0 - active high, 1 - active low. - - - nuvoton,vref-impedance: VREF Impedance selection - 0 - Open - 1 - 25 kOhm - 2 - 125 kOhm - 3 - 2.5 kOhm - - - nuvoton,micbias-voltage: Micbias voltage level. - 0 - VDDA - 1 - VDDA - 2 - VDDA * 1.1 - 3 - VDDA * 1.2 - 4 - VDDA * 1.3 - 5 - VDDA * 1.4 - 6 - VDDA * 1.53 - 7 - VDDA * 1.53 - - - nuvoton,jack-insert-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms - - nuvoton,jack-eject-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms - - - nuvoton,dmic-clk-threshold: the ADC threshold of DMIC clock. - - nuvoton,key_enable: Headset button detection switch. - -Example: - - headset: nau8821@1b { - compatible = "nuvoton,nau8821"; - reg = <0x1b>; - interrupt-parent = <&gpio>; - interrupts = <23 IRQ_TYPE_LEVEL_LOW>; - nuvoton,jkdet-enable; - nuvoton,jkdet-pull-enable; - nuvoton,jkdet-pull-up; - nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>; - nuvoton,vref-impedance = <2>; - nuvoton,micbias-voltage = <6>; - nuvoton,jack-insert-debounce = <7>; - nuvoton,jack-eject-debounce = <7>; - nuvoton,dmic-clk-threshold = 3072000; - }; diff --git a/Documentation/devicetree/bindings/sound/nau8824.txt b/Documentation/devicetree/bindings/sound/nau8824.txt deleted file mode 100644 index e0058b97e49a..000000000000 --- a/Documentation/devicetree/bindings/sound/nau8824.txt +++ /dev/null @@ -1,88 +0,0 @@ -Nuvoton NAU8824 audio codec - -This device supports I2C only. - -Required properties: - - compatible : Must be "nuvoton,nau8824" - - - reg : the I2C address of the device. This is either 0x1a (CSB=0) or 0x1b (CSB=1). - -Optional properties: - - nuvoton,jkdet-polarity: JKDET pin polarity. 0 - active high, 1 - active low. - - - nuvoton,vref-impedance: VREF Impedance selection - 0 - Open - 1 - 25 kOhm - 2 - 125 kOhm - 3 - 2.5 kOhm - - - nuvoton,micbias-voltage: Micbias voltage level. - 0 - VDDA - 1 - VDDA - 2 - VDDA * 1.1 - 3 - VDDA * 1.2 - 4 - VDDA * 1.3 - 5 - VDDA * 1.4 - 6 - VDDA * 1.53 - 7 - VDDA * 1.53 - - - nuvoton,sar-threshold-num: Number of buttons supported - - nuvoton,sar-threshold: Impedance threshold for each button. Array that contains up to 8 buttons configuration. SAR value is calculated as - SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R) - where MICBIAS is configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by 'nuvoton,sar-voltage', R - button impedance. - Refer datasheet section 10.2 for more information about threshold calculation. - - - nuvoton,sar-hysteresis: Button impedance measurement hysteresis. - - - nuvoton,sar-voltage: Reference voltage for button impedance measurement. - 0 - VDDA - 1 - VDDA - 2 - VDDA * 1.1 - 3 - VDDA * 1.2 - 4 - VDDA * 1.3 - 5 - VDDA * 1.4 - 6 - VDDA * 1.53 - 7 - VDDA * 1.53 - - - nuvoton,sar-compare-time: SAR compare time - 0 - 500 ns - 1 - 1 us - 2 - 2 us - 3 - 4 us - - - nuvoton,sar-sampling-time: SAR sampling time - 0 - 2 us - 1 - 4 us - 2 - 8 us - 3 - 16 us - - - nuvoton,short-key-debounce: Button short key press debounce time. - 0 - 30 ms - 1 - 50 ms - 2 - 100 ms - - - nuvoton,jack-eject-debounce: Jack ejection debounce time. - 0 - 0 ms - 1 - 1 ms - 2 - 10 ms - - -Example: - - headset: nau8824@1a { - compatible = "nuvoton,nau8824"; - reg = <0x1a>; - interrupt-parent = <&gpio>; - interrupts = <TEGRA_GPIO(E, 6) IRQ_TYPE_LEVEL_LOW>; - nuvoton,vref-impedance = <2>; - nuvoton,micbias-voltage = <6>; - // Setup 4 buttons impedance according to Android specification - nuvoton,sar-threshold-num = <4>; - nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>; - nuvoton,sar-hysteresis = <0>; - nuvoton,sar-voltage = <6>; - nuvoton,sar-compare-time = <1>; - nuvoton,sar-sampling-time = <1>; - nuvoton,short-key-debounce = <0>; - nuvoton,jack-eject-debounce = <1>; - }; diff --git a/Documentation/devicetree/bindings/sound/nau8825.txt b/Documentation/devicetree/bindings/sound/nau8825.txt deleted file mode 100644 index a9c34526f4cb..000000000000 --- a/Documentation/devicetree/bindings/sound/nau8825.txt +++ /dev/null @@ -1,111 +0,0 @@ -Nuvoton NAU8825 audio codec - -This device supports I2C only. - -Required properties: - - compatible : Must be "nuvoton,nau8825" - - - reg : the I2C address of the device. This is either 0x1a (CSB=0) or 0x1b (CSB=1). - -Optional properties: - - nuvoton,jkdet-enable: Enable jack detection via JKDET pin. - - nuvoton,jkdet-pull-enable: Enable JKDET pin pull. If set - pin pull enabled, - otherwise pin in high impedance state. - - nuvoton,jkdet-pull-up: Pull-up JKDET pin. If set then JKDET pin is pull up, otherwise pull down. - - nuvoton,jkdet-polarity: JKDET pin polarity. 0 - active high, 1 - active low. - - - nuvoton,vref-impedance: VREF Impedance selection - 0 - Open - 1 - 25 kOhm - 2 - 125 kOhm - 3 - 2.5 kOhm - - - nuvoton,micbias-voltage: Micbias voltage level. - 0 - VDDA - 1 - VDDA - 2 - VDDA * 1.1 - 3 - VDDA * 1.2 - 4 - VDDA * 1.3 - 5 - VDDA * 1.4 - 6 - VDDA * 1.53 - 7 - VDDA * 1.53 - - - nuvoton,sar-threshold-num: Number of buttons supported - - nuvoton,sar-threshold: Impedance threshold for each button. Array that contains up to 8 buttons configuration. SAR value is calculated as - SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R) - where MICBIAS is configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by 'nuvoton,sar-voltage', R - button impedance. - Refer datasheet section 10.2 for more information about threshold calculation. - - - nuvoton,sar-hysteresis: Button impedance measurement hysteresis. - - - nuvoton,sar-voltage: Reference voltage for button impedance measurement. - 0 - VDDA - 1 - VDDA - 2 - VDDA * 1.1 - 3 - VDDA * 1.2 - 4 - VDDA * 1.3 - 5 - VDDA * 1.4 - 6 - VDDA * 1.53 - 7 - VDDA * 1.53 - - - nuvoton,sar-compare-time: SAR compare time - 0 - 500 ns - 1 - 1 us - 2 - 2 us - 3 - 4 us - - - nuvoton,sar-sampling-time: SAR sampling time - 0 - 2 us - 1 - 4 us - 2 - 8 us - 3 - 16 us - - - nuvoton,short-key-debounce: Button short key press debounce time. - 0 - 30 ms - 1 - 50 ms - 2 - 100 ms - 3 - 30 ms - - - nuvoton,jack-insert-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms - - nuvoton,jack-eject-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms - - - nuvoton,crosstalk-enable: make crosstalk function enable if set. - - - nuvoton,adcout-drive-strong: make the drive strength of ADCOUT IO PIN strong if set. - Otherwise, the drive keeps normal strength. - - - nuvoton,adc-delay-ms: Delay (in ms) to make input path stable and avoid pop noise. The - default value is 125 and range between 125 to 500 ms. - - - clocks: list of phandle and clock specifier pairs according to common clock bindings for the - clocks described in clock-names - - clock-names: should include "mclk" for the MCLK master clock - -Example: - - headset: nau8825@1a { - compatible = "nuvoton,nau8825"; - reg = <0x1a>; - interrupt-parent = <&gpio>; - interrupts = <TEGRA_GPIO(E, 6) IRQ_TYPE_LEVEL_LOW>; - nuvoton,jkdet-enable; - nuvoton,jkdet-pull-enable; - nuvoton,jkdet-pull-up; - nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>; - nuvoton,vref-impedance = <2>; - nuvoton,micbias-voltage = <6>; - // Setup 4 buttons impedance according to Android specification - nuvoton,sar-threshold-num = <4>; - nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>; - nuvoton,sar-hysteresis = <1>; - nuvoton,sar-voltage = <0>; - nuvoton,sar-compare-time = <0>; - nuvoton,sar-sampling-time = <0>; - nuvoton,short-key-debounce = <2>; - nuvoton,jack-insert-debounce = <7>; - nuvoton,jack-eject-debounce = <7>; - nuvoton,crosstalk-enable; - - clock-names = "mclk"; - clocks = <&tegra_pmc TEGRA_PMC_CLK_OUT_2>; - }; diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8315.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8315.yaml new file mode 100644 index 000000000000..24006e9dc501 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8315.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nuvoton,nau8315.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NAU8315/NAU8318 Mono Class-D Amplifier + +maintainers: + - David Lin <CTLIN0@nuvoton.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - nuvoton,nau8315 + - nuvoton,nau8318 + + '#sound-dai-cells': + const: 0 + + enable-gpios: + maxItems: 1 + description: + GPIO specifier for the chip's device enable input(EN) pin. + If this option is not specified then driver does not manage + the pin state (e.g. chip is always on). + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + codec { + compatible = "nuvoton,nau8315"; + #sound-dai-cells = <0>; + enable-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8540.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8540.yaml new file mode 100644 index 000000000000..7ccfbb8d8b04 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8540.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nuvoton,nau8540.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton Technology Corporation NAU85L40 Audio CODEC + +maintainers: + - John Hsu <KCHSU0@nuvoton.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: nuvoton,nau8540 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1c { + compatible = "nuvoton,nau8540"; + reg = <0x1c>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8810.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8810.yaml new file mode 100644 index 000000000000..d9696f6c75ed --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8810.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nuvoton,nau8810.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NAU8810/NAU8812/NAU8814 audio CODEC + +maintainers: + - David Lin <CTLIN0@nuvoton.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - nuvoton,nau8810 + - nuvoton,nau8812 + - nuvoton,nau8814 + + reg: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + #sound-dai-cells = <0>; + compatible = "nuvoton,nau8810"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml new file mode 100644 index 000000000000..3e54abd4ca74 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nuvoton,nau8821.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NAU88L21 audio codec + +maintainers: + - Seven Lee <wtli@nuvoton.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: nuvoton,nau8821 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + nuvoton,jkdet-enable: + description: Enable jack detection via JKDET pin. + type: boolean + + nuvoton,jkdet-pull-enable: + description: Enable JKDET pin pull. If set - pin pull enabled, + otherwise pin in high impedance state. + type: boolean + + nuvoton,jkdet-pull-up: + description: Pull-up JKDET pin. If set then JKDET pin is pull up, + otherwise pull down. + type: boolean + + nuvoton,key-enable: + description: handles key press detection. + type: boolean + + nuvoton,jkdet-polarity: + description: JKDET pin polarity. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # active high + - 1 # active low + default: 1 + + nuvoton,micbias-voltage: + description: MICBIAS output level select. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # VDDA + - 1 # VDDA * 1 + - 2 # VDDA * 1.1 + - 3 # VDDA * 1.2 + - 4 # VDDA * 1.3 + - 5 # VDDA * 1.4 + - 6 # VDDA * 1.53 + - 7 # VDDA * 1.53 + default: 6 + + nuvoton,vref-impedance: + description: VMID Tie-off impedance select. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # open + - 1 # 25KOhms + - 2 # 125KOhms + - 3 # 2.5KOhms + default: 2 + + nuvoton,jack-insert-debounce: + description: number from 0 to 7 that sets debounce time to 2^(n+2)ms. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 7 + default: 7 + + nuvoton,jack-eject-debounce: + description: number from 0 to 7 that sets debounce time to 2^(n+2)ms. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 7 + default: 0 + + nuvoton,dmic-clk-threshold: + description: DMIC clock speed expected value. Unit is Hz. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 3072000 + + nuvoton,left-input-single-end: + description: Enable left input with single-ended settings if set. + For the headset mic application, the single-ended control is + just limited to the left adc for design demand. + type: boolean + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1b { + compatible = "nuvoton,nau8821"; + reg = <0x1b>; + interrupt-parent = <&gpio>; + interrupts = <23 IRQ_TYPE_LEVEL_LOW>; + nuvoton,jkdet-enable; + nuvoton,jkdet-pull-enable; + nuvoton,jkdet-pull-up; + nuvoton,key-enable; + nuvoton,left-input-single-end; + nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>; + nuvoton,micbias-voltage = <6>; + nuvoton,vref-impedance = <2>; + nuvoton,jack-insert-debounce = <7>; + nuvoton,jack-eject-debounce = <0>; + nuvoton,dmic-clk-threshold = <3072000>; + #sound-dai-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml index 65105402a53d..cb8182bbc491 100644 --- a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml @@ -21,6 +21,15 @@ properties: reg: maxItems: 1 + "#sound-dai-cells": + const: 0 + + clocks: + maxItems: 1 + + clock-names: + const: mclk + nuvoton,spk-btl: description: If set, configure the two loudspeaker outputs as a Bridge Tied Load output @@ -31,6 +40,9 @@ required: - compatible - reg +allOf: + - $ref: dai-common.yaml# + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8824.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8824.yaml new file mode 100644 index 000000000000..3dbf438c3841 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8824.yaml @@ -0,0 +1,182 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nuvoton,nau8824.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NAU8824 audio CODEC + +maintainers: + - John Hsu <KCHSU0@nuvoton.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - nuvoton,nau8824 + + reg: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + + interrupts: + maxItems: 1 + + nuvoton,jkdet-polarity: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + JKDET pin polarity. + enum: + - 0 # active high + - 1 # active low + default: 1 + + nuvoton,vref-impedance: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + VREF Impedance selection. + enum: + - 0 # Open + - 1 # 25 kOhm + - 2 # 125 kOhm + - 3 # 2.5 kOhm + default: 2 + + nuvoton,micbias-voltage: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Micbias voltage level. + enum: + - 0 # VDDA + - 1 # VDDA + - 2 # VDDA * 1.1 + - 3 # VDDA * 1.2 + - 4 # VDDA * 1.3 + - 5 # VDDA * 1.4 + - 6 # VDDA * 1.53 + - 7 # VDDA * 1.53 + default: 6 + + nuvoton,sar-threshold-num: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Number of buttons supported. + minimum: 1 + maximum: 8 + default: 4 + + nuvoton,sar-threshold: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Impedance threshold for each button. Array that contains up to 8 buttons + configuration. SAR value is calculated as + SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R) where MICBIAS is + configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by + 'nuvoton,sar-voltage', R - button impedance. + Refer datasheet section 10.2 for more information about threshold + calculation. + minItems: 1 + maxItems: 8 + items: + minimum: 0 + maximum: 255 + + nuvoton,sar-hysteresis: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Button impedance measurement hysteresis. + default: 0 + + nuvoton,sar-voltage: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Reference voltage for button impedance measurement. + enum: + - 0 # VDDA + - 1 # VDDA + - 2 # VDDA * 1.1 + - 3 # VDDA * 1.2 + - 4 # VDDA * 1.3 + - 5 # VDDA * 1.4 + - 6 # VDDA * 1.53 + - 7 # VDDA * 1.53 + default: 6 + + nuvoton,sar-compare-time: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + SAR compare time. + enum: + - 0 # 500ns + - 1 # 1us + - 2 # 2us + - 3 # 4us + default: 1 + + nuvoton,sar-sampling-time: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + SAR sampling time. + enum: + - 0 # 2us + - 1 # 4us + - 2 # 8us + - 3 # 16us + default: 1 + + nuvoton,short-key-debounce: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Button short key press debounce time. + enum: + - 0 # 30 ms + - 1 # 50 ms + - 2 # 100 ms + default: 0 + + nuvoton,jack-eject-debounce: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Jack ejection debounce time. + enum: + - 0 # 0 ms + - 1 # 1 ms + - 2 # 10 ms + default: 1 + +required: + - compatible + - reg + +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 { + #sound-dai-cells = <0>; + compatible = "nuvoton,nau8824"; + reg = <0x1a>; + interrupt-parent = <&gpio>; + interrupts = <38 IRQ_TYPE_LEVEL_LOW>; + nuvoton,vref-impedance = <2>; + nuvoton,micbias-voltage = <6>; + nuvoton,sar-threshold-num = <4>; + // Setup 4 buttons impedance according to Android specification + nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>; + nuvoton,sar-hysteresis = <0>; + nuvoton,sar-voltage = <6>; + nuvoton,sar-compare-time = <1>; + nuvoton,sar-sampling-time = <1>; + nuvoton,short-key-debounce = <0>; + nuvoton,jack-eject-debounce = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8825.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8825.yaml new file mode 100644 index 000000000000..a54f194a0b49 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8825.yaml @@ -0,0 +1,239 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nuvoton,nau8825.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NAU8825 audio CODEC + +maintainers: + - John Hsu <KCHSU0@nuvoton.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - nuvoton,nau8825 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + nuvoton,jkdet-enable: + description: + Enable jack detection via JKDET pin. + type: boolean + + nuvoton,jkdet-pull-enable: + description: + Enable JKDET pin pull. + If set - pin pull enabled, otherwise pin in high impedance state. + type: boolean + + nuvoton,jkdet-pull-up: + description: + Pull-up JKDET pin. + If set then JKDET pin is pull up, otherwise pull down. + type: boolean + + nuvoton,jkdet-polarity: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + JKDET pin polarity. + enum: + - 0 # active high + - 1 # active low + default: 1 + + nuvoton,vref-impedance: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + VREF Impedance selection. + enum: + - 0 # Open + - 1 # 25 kOhm + - 2 # 125 kOhm + - 3 # 2.5 kOhm + default: 2 + + nuvoton,micbias-voltage: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Micbias voltage level. + enum: + - 0 # VDDA + - 1 # VDDA + - 2 # VDDA * 1.1 + - 3 # VDDA * 1.2 + - 4 # VDDA * 1.3 + - 5 # VDDA * 1.4 + - 6 # VDDA * 1.53 + - 7 # VDDA * 1.53 + default: 6 + + nuvoton,sar-threshold-num: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Number of buttons supported. + minimum: 1 + maximum: 4 + default: 4 + + nuvoton,sar-threshold: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Impedance threshold for each button. Array that contains up to 8 buttons + configuration. SAR value is calculated as + SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R) where MICBIAS is + configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by + 'nuvoton,sar-voltage', R - button impedance. + Refer datasheet section 10.2 for more information about threshold + calculation. + minItems: 1 + maxItems: 4 + items: + minimum: 0 + maximum: 255 + + nuvoton,sar-hysteresis: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Button impedance measurement hysteresis. + default: 0 + + nuvoton,sar-voltage: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Reference voltage for button impedance measurement. + enum: + - 0 # VDDA + - 1 # VDDA + - 2 # VDDA * 1.1 + - 3 # VDDA * 1.2 + - 4 # VDDA * 1.3 + - 5 # VDDA * 1.4 + - 6 # VDDA * 1.53 + - 7 # VDDA * 1.53 + default: 6 + + nuvoton,sar-compare-time: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + SAR compare time. + enum: + - 0 # 500 ns + - 1 # 1 us + - 2 # 2 us + - 3 # 4 us + default: 1 + + nuvoton,sar-sampling-time: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + SAR sampling time. + enum: + - 0 # 2 us + - 1 # 4 us + - 2 # 8 us + - 3 # 16 us + default: 1 + + nuvoton,short-key-debounce: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Button short key press debounce time. + enum: + - 0 # 30 ms + - 1 # 50 ms + - 2 # 100 ms + - 3 # 30 ms + default: 3 + + nuvoton,jack-insert-debounce: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + number from 0 to 7 that sets debounce time to 2^(n+2) ms. + maximum: 7 + default: 7 + + nuvoton,jack-eject-debounce: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + number from 0 to 7 that sets debounce time to 2^(n+2) ms + maximum: 7 + default: 0 + + nuvoton,crosstalk-enable: + description: + make crosstalk function enable if set. + type: boolean + + nuvoton,adcout-drive-strong: + description: + make the drive strength of ADCOUT IO PIN strong if set. + Otherwise, the drive keeps normal strength. + type: boolean + + nuvoton,adc-delay-ms: + description: + Delay (in ms) to make input path stable and avoid pop noise. + The default value is 125 and range between 125 to 500 ms. + minimum: 125 + maximum: 500 + default: 125 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: mclk + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + +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 { + #sound-dai-cells = <0>; + compatible = "nuvoton,nau8825"; + reg = <0x1a>; + interrupt-parent = <&gpio>; + interrupts = <38 IRQ_TYPE_LEVEL_LOW>; + nuvoton,jkdet-enable; + nuvoton,jkdet-pull-enable; + nuvoton,jkdet-pull-up; + nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>; + nuvoton,vref-impedance = <2>; + nuvoton,micbias-voltage = <6>; + // Setup 4 buttons impedance according to Android specification + nuvoton,sar-threshold-num = <4>; + nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>; + nuvoton,sar-hysteresis = <1>; + nuvoton,sar-voltage = <0>; + nuvoton,sar-compare-time = <0>; + nuvoton,sar-sampling-time = <0>; + nuvoton,short-key-debounce = <2>; + nuvoton,jack-insert-debounce = <7>; + nuvoton,jack-eject-debounce = <7>; + nuvoton,crosstalk-enable; + + clock-names = "mclk"; + clocks = <&tegra_pmc 1>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml index 7c1e9895ce85..2588589ad62d 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/sound/nvidia,tegra-audio-common.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Common properties for NVIDIA Tegra audio complexes diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml index fc89dbd6bf24..c29d7942915c 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml @@ -35,12 +35,12 @@ properties: items: enum: # Board Connectors - - "Int Spk" - - "Headphone Jack" - - "Earpiece" - - "Headset Mic" - - "Internal Mic 1" - - "Internal Mic 2" + - Int Spk + - Headphone Jack + - Earpiece + - Headset Mic + - Internal Mic 1 + - Internal Mic 2 # CODEC Pins - HPL diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml index a04487002e88..0c8067c3b056 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml @@ -31,10 +31,10 @@ properties: items: enum: # Board Connectors - - "Int Spk" - - "Headphone Jack" - - "Mic Jack" - - "Int Mic" + - Int Spk + - Headphone Jack + - Mic Jack + - Int Mic # CODEC Pins - MIC1 diff --git a/Documentation/devicetree/bindings/sound/option,gtm601.yaml b/Documentation/devicetree/bindings/sound/option,gtm601.yaml new file mode 100644 index 000000000000..ff813d97fc59 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/option,gtm601.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/option,gtm601.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GTM601 UMTS modem audio interface CODEC + +maintainers: + - kernel@puri.sm + +description: > + This device has no configuration interface. The sample rate and channels are + based on the compatible string + +properties: + compatible: + oneOf: + - description: Broadmobi BM818 (48Khz stereo) + items: + - const: broadmobi,bm818 + - const: option,gtm601 + - description: GTM601 (8kHz mono) + const: option,gtm601 + + '#sound-dai-cells': + const: 0 + +required: + - compatible + +allOf: + - $ref: dai-common.yaml# + +additionalProperties: false + +examples: + - | + codec { + compatible = "option,gtm601"; + #sound-dai-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml index 6cc8f86c7531..3a559bd07a79 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml @@ -8,7 +8,7 @@ title: Qualcomm Technologies Inc. LPASS CPU dai driver maintainers: - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> - - Rohit kumar <rohitkr@codeaurora.org> + - Rohit kumar <quic_rohkumar@quicinc.com> description: | Qualcomm Technologies Inc. SOC Low-Power Audio SubSystem (LPASS) that consist diff --git a/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt b/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt deleted file mode 100644 index e7d17dda55db..000000000000 --- a/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt +++ /dev/null @@ -1,101 +0,0 @@ -msm8916 analog audio CODEC - -Bindings for codec Analog IP which is integrated in pmic pm8916, - -## Bindings for codec core on pmic: - -Required properties - - compatible = "qcom,pm8916-wcd-analog-codec"; - - reg: represents the slave base address provided to the peripheral. - - interrupts: List of interrupts in given SPMI peripheral. - - interrupt-names: Names specified to above list of interrupts in same - order. List of supported interrupt names are: - "cdc_spk_cnp_int" - Speaker click and pop interrupt. - "cdc_spk_clip_int" - Speaker clip interrupt. - "cdc_spk_ocp_int" - Speaker over current protect interrupt. - "mbhc_ins_rem_det1" - jack insert removal detect interrupt 1. - "mbhc_but_rel_det" - button release interrupt. - "mbhc_but_press_det" - button press event - "mbhc_ins_rem_det" - jack insert removal detect interrupt. - "mbhc_switch_int" - multi button headset interrupt. - "cdc_ear_ocp_int" - Earphone over current protect interrupt. - "cdc_hphr_ocp_int" - Headphone R over current protect interrupt. - "cdc_hphl_ocp_det" - Headphone L over current protect interrupt. - "cdc_ear_cnp_int" - earphone cnp interrupt. - "cdc_hphr_cnp_int" - hphr click and pop interrupt. - "cdc_hphl_cnp_int" - hphl click and pop interrupt. - - - clocks: Handle to mclk. - - clock-names: should be "mclk" - - vdd-cdc-io-supply: phandle to VDD_CDC_IO regulator DT node. - - vdd-cdc-tx-rx-cx-supply: phandle to VDD_CDC_TX/RX/CX regulator DT node. - - vdd-micbias-supply: phandle of VDD_MICBIAS supply's regulator DT node. - -Optional Properties: - - qcom,mbhc-vthreshold-low: Array of 5 threshold voltages in mV for 5 buttons - detection on headset when the mbhc is powered up - by internal current source, this is a low power. - - qcom,mbhc-vthreshold-high: Array of 5 thresold voltages in mV for 5 buttons - detection on headset when mbhc is powered up - from micbias. -- qcom,micbias-lvl: Voltage (mV) for Mic Bias -- qcom,hphl-jack-type-normally-open: boolean, present if hphl pin on jack is a - NO (Normally Open). If not specified, then - its assumed that hphl pin on jack is NC - (Normally Closed). -- qcom,gnd-jack-type-normally-open: boolean, present if gnd pin on jack is - NO (Normally Open). If not specified, then - its assumed that gnd pin on jack is NC - (Normally Closed). -- qcom,micbias1-ext-cap: boolean, present if micbias1 has external capacitor - connected. -- qcom,micbias2-ext-cap: boolean, present if micbias2 has external capacitor - connected. - -Example: - -spmi_bus { - ... - audio-codec@f000{ - compatible = "qcom,pm8916-wcd-analog-codec"; - reg = <0xf000 0x200>; - reg-names = "pmic-codec-core"; - clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>; - clock-names = "mclk"; - qcom,mbhc-vthreshold-low = <75 150 237 450 500>; - qcom,mbhc-vthreshold-high = <75 150 237 450 500>; - interrupt-parent = <&spmi_bus>; - interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>, - <0x1 0xf0 0x1 IRQ_TYPE_NONE>, - <0x1 0xf0 0x2 IRQ_TYPE_NONE>, - <0x1 0xf0 0x3 IRQ_TYPE_NONE>, - <0x1 0xf0 0x4 IRQ_TYPE_NONE>, - <0x1 0xf0 0x5 IRQ_TYPE_NONE>, - <0x1 0xf0 0x6 IRQ_TYPE_NONE>, - <0x1 0xf0 0x7 IRQ_TYPE_NONE>, - <0x1 0xf1 0x0 IRQ_TYPE_NONE>, - <0x1 0xf1 0x1 IRQ_TYPE_NONE>, - <0x1 0xf1 0x2 IRQ_TYPE_NONE>, - <0x1 0xf1 0x3 IRQ_TYPE_NONE>, - <0x1 0xf1 0x4 IRQ_TYPE_NONE>, - <0x1 0xf1 0x5 IRQ_TYPE_NONE>; - interrupt-names = "cdc_spk_cnp_int", - "cdc_spk_clip_int", - "cdc_spk_ocp_int", - "mbhc_ins_rem_det1", - "mbhc_but_rel_det", - "mbhc_but_press_det", - "mbhc_ins_rem_det", - "mbhc_switch_int", - "cdc_ear_ocp_int", - "cdc_hphr_ocp_int", - "cdc_hphl_ocp_det", - "cdc_ear_cnp_int", - "cdc_hphr_cnp_int", - "cdc_hphl_cnp_int"; - vdd-cdc-io-supply = <&pm8916_l5>; - vdd-cdc-tx-rx-cx-supply = <&pm8916_l5>; - vdd-micbias-supply = <&pm8916_l13>; - #sound-dai-cells = <1>; - }; -}; diff --git a/Documentation/devicetree/bindings/sound/qcom,pm8916-wcd-analog-codec.yaml b/Documentation/devicetree/bindings/sound/qcom,pm8916-wcd-analog-codec.yaml new file mode 100644 index 000000000000..94e7a1860977 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,pm8916-wcd-analog-codec.yaml @@ -0,0 +1,153 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,pm8916-wcd-analog-codec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm PM8916 WCD Analog Audio Codec + +maintainers: + - Konrad Dybcio <konradybcio@kernel.org> + +description: + The analog WCD audio codec found on Qualcomm PM8916 PMIC. + +properties: + compatible: + const: qcom,pm8916-wcd-analog-codec + + reg: + maxItems: 1 + + interrupts: + maxItems: 14 + + interrupt-names: + items: + - const: cdc_spk_cnp_int + - const: cdc_spk_clip_int + - const: cdc_spk_ocp_int + - const: mbhc_ins_rem_det1 + - const: mbhc_but_rel_det + - const: mbhc_but_press_det + - const: mbhc_ins_rem_det + - const: mbhc_switch_int + - const: cdc_ear_ocp_int + - const: cdc_hphr_ocp_int + - const: cdc_hphl_ocp_det + - const: cdc_ear_cnp_int + - const: cdc_hphr_cnp_int + - const: cdc_hphl_cnp_int + + vdd-cdc-io-supply: + description: 1.8V buck supply + + vdd-cdc-tx-rx-cx-supply: + description: 1.8V SIDO buck supply + + vdd-micbias-supply: + description: micbias supply + + qcom,mbhc-vthreshold-low: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Array of 5 threshold voltages in mV for 5-button detection on + headset when MBHC is powered by an internal current source. + minItems: 5 + maxItems: 5 + + qcom,mbhc-vthreshold-high: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Array of 5 threshold voltages in mV for 5-button detection on + headset when MBHC is powered from micbias. + minItems: 5 + maxItems: 5 + + qcom,micbias-lvl: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Voltage (mV) for Mic Bias + + qcom,hphl-jack-type-normally-open: + type: boolean + description: + True if the HPHL pin on the jack is NO (Normally Open), false if it's + NC (Normally Closed). + + qcom,gnd-jack-type-normally-open: + type: boolean + description: + True if the GND pin on the jack is NO (Normally Open), false if it's + NC (Normally Closed). + + qcom,micbias1-ext-cap: + type: boolean + description: + True if micbias1 has an external capacitor. + + qcom,micbias2-ext-cap: + type: boolean + description: + True if micbias2 has an external capacitor. + + "#sound-dai-cells": + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/spmi/spmi.h> + + pmic@1 { + compatible = "qcom,pm8916", "qcom,spmi-pmic"; + reg = <0x1 SPMI_USID>; + #address-cells = <1>; + #size-cells = <0>; + + audio-codec@f000 { + compatible = "qcom,pm8916-wcd-analog-codec"; + reg = <0xf000>; + qcom,mbhc-vthreshold-low = <75 150 237 450 500>; + qcom,mbhc-vthreshold-high = <75 150 237 450 500>; + interrupt-parent = <&spmi_bus>; + interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>, + <0x1 0xf0 0x1 IRQ_TYPE_NONE>, + <0x1 0xf0 0x2 IRQ_TYPE_NONE>, + <0x1 0xf0 0x3 IRQ_TYPE_NONE>, + <0x1 0xf0 0x4 IRQ_TYPE_NONE>, + <0x1 0xf0 0x5 IRQ_TYPE_NONE>, + <0x1 0xf0 0x6 IRQ_TYPE_NONE>, + <0x1 0xf0 0x7 IRQ_TYPE_NONE>, + <0x1 0xf1 0x0 IRQ_TYPE_NONE>, + <0x1 0xf1 0x1 IRQ_TYPE_NONE>, + <0x1 0xf1 0x2 IRQ_TYPE_NONE>, + <0x1 0xf1 0x3 IRQ_TYPE_NONE>, + <0x1 0xf1 0x4 IRQ_TYPE_NONE>, + <0x1 0xf1 0x5 IRQ_TYPE_NONE>; + interrupt-names = "cdc_spk_cnp_int", + "cdc_spk_clip_int", + "cdc_spk_ocp_int", + "mbhc_ins_rem_det1", + "mbhc_but_rel_det", + "mbhc_but_press_det", + "mbhc_ins_rem_det", + "mbhc_switch_int", + "cdc_ear_ocp_int", + "cdc_hphr_ocp_int", + "cdc_hphl_ocp_det", + "cdc_ear_cnp_int", + "cdc_hphr_cnp_int", + "cdc_hphl_cnp_int"; + vdd-cdc-io-supply = <&pm8916_l5>; + vdd-cdc-tx-rx-cx-supply = <&pm8916_l5>; + vdd-micbias-supply = <&pm8916_l13>; + #sound-dai-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml index cdbb4096fa44..9e5b30d9c6e6 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/sound/qcom,q6apm-dai.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/sound/qcom,q6apm-dai.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Audio Process Manager Digital Audio Interfaces diff --git a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml index 1168410f6fbd..3552c44137ed 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-clocks.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-clocks.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm DSP LPASS Clock Controller diff --git a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml index 044e77718a1b..08c618e7e428 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-ports.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-ports.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm DSP LPASS(Low Power Audio SubSystem) Audio Ports diff --git a/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml b/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml new file mode 100644 index 000000000000..e6723c9e312a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wsa8840.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm WSA8840/WSA8845/WSA8845H smart speaker amplifier + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: + WSA884X is a family of Qualcomm Aqstic smart speaker amplifiers using + SoundWire digital audio interface. + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: sdw20217020400 + + reg: + maxItems: 1 + + powerdown-gpios: + description: Powerdown/Shutdown line to use (pin SD_N) + maxItems: 1 + + '#sound-dai-cells': + const: 0 + + vdd-1p8-supply: true + vdd-io-supply: true + +required: + - compatible + - reg + - powerdown-gpios + - '#sound-dai-cells' + - vdd-1p8-supply + - vdd-io-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + soundwire-controller { + #address-cells = <2>; + #size-cells = <0>; + + speaker@0,1 { + compatible = "sdw20217020400"; + reg = <0 1>; + pinctrl-names = "default"; + pinctrl-0 = <&spkr_2_sd_n_active>; + powerdown-gpios = <&lpass_tlmm 18 GPIO_ACTIVE_LOW>; + #sound-dai-cells = <0>; + sound-name-prefix = "SpkrRight"; + vdd-1p8-supply = <&vreg_l15b_1p8>; + vdd-io-supply = <&vreg_l3g_1p2>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/realtek,rt1016.yaml b/Documentation/devicetree/bindings/sound/realtek,rt1016.yaml new file mode 100644 index 000000000000..5287e9c9197e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/realtek,rt1016.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/realtek,rt1016.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Reaktek RT1016 Stereo Class D Audio Amplifier + +maintainers: + - oder_chiou@realtek.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: realtek,rt1016 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1a { + compatible = "realtek,rt1016"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index b731f16aea84..dfd768b1ad7d 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -94,7 +94,7 @@ see "Example: simple sound card for Asynchronous mode" [xx]ch [yy]ch ------> [CTU] --------> -CTU can convert [xx]ch to [yy]ch, or exchange outputed channel. +CTU can convert [xx]ch to [yy]ch, or exchange outputted channel. CTU conversion needs matrix settings. For more detail information, see below diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 8a821dec9526..13a5a0a10fe6 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -9,6 +9,20 @@ title: Renesas R-Car Sound Driver maintainers: - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> +definitions: + port-def: + $ref: audio-graph-port.yaml#/definitions/port-base + unevaluatedProperties: false + patternProperties: + "^endpoint(@[0-9a-f]+)?": + $ref: audio-graph-port.yaml#/definitions/endpoint-base + properties: + playback: + $ref: /schemas/types.yaml#/definitions/phandle-array + capture: + $ref: /schemas/types.yaml#/definitions/phandle-array + unevaluatedProperties: false + properties: compatible: @@ -77,6 +91,12 @@ properties: it must be 1 if your system has audio_clkout0/1/2/3 enum: [0, 1] + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + clock-frequency: description: for audio_clkout0/1/2/3 @@ -103,35 +123,9 @@ properties: description: List of necessary clock names. # details are defined below - ports: - $ref: audio-graph-port.yaml#/definitions/port-base - unevaluatedProperties: false - patternProperties: - '^port(@[0-9a-f]+)?$': - $ref: audio-graph-port.yaml#/definitions/port-base - unevaluatedProperties: false - patternProperties: - "^endpoint(@[0-9a-f]+)?": - $ref: audio-graph-port.yaml#/definitions/endpoint-base - properties: - playback: - $ref: /schemas/types.yaml#/definitions/phandle-array - capture: - $ref: /schemas/types.yaml#/definitions/phandle-array - unevaluatedProperties: false - + # ports is below port: - $ref: audio-graph-port.yaml#/definitions/port-base - unevaluatedProperties: false - patternProperties: - "^endpoint(@[0-9a-f]+)?": - $ref: audio-graph-port.yaml#/definitions/endpoint-base - properties: - playback: - $ref: /schemas/types.yaml#/definitions/phandle-array - capture: - $ref: /schemas/types.yaml#/definitions/phandle-array - unevaluatedProperties: false + $ref: "#/definitions/port-def" rcar_sound,dvc: description: DVC subnode. @@ -248,8 +242,9 @@ properties: - interrupts additionalProperties: false +patternProperties: # For DAI base - rcar_sound,dai: + 'rcar_sound,dai(@[0-9a-f]+)?$': description: DAI subnode. type: object patternProperties: @@ -269,6 +264,13 @@ properties: - capture additionalProperties: false + 'ports(@[0-9a-f]+)?$': + $ref: audio-graph-port.yaml#/definitions/port-base + unevaluatedProperties: false + patternProperties: + '^port(@[0-9a-f]+)?$': + $ref: "#/definitions/port-def" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt index e5430d1d34e4..73577ac1b89c 100644 --- a/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt @@ -12,7 +12,7 @@ Required properties: source. For this driver the first string should always be "Analog". -Optionnal properties: +Optional properties: - rockchip,hp-en-gpios = The phandle of the GPIO that power up/down the headphone (when the analog output is an headphone). - rockchip,hp-det-gpios = The phandle of the GPIO that detects the headphone diff --git a/Documentation/devicetree/bindings/sound/rt1016.txt b/Documentation/devicetree/bindings/sound/rt1016.txt deleted file mode 100644 index 2310f8ff259b..000000000000 --- a/Documentation/devicetree/bindings/sound/rt1016.txt +++ /dev/null @@ -1,17 +0,0 @@ -RT1016 Stereo Class D Audio Amplifier - -This device supports I2C only. - -Required properties: - -- compatible : "realtek,rt1016". - -- reg : The I2C address of the device. - - -Example: - -rt1016: codec@1a { - compatible = "realtek,rt1016"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/rt5663.txt b/Documentation/devicetree/bindings/sound/rt5663.txt index 2a55e9133408..24a6dab28f25 100644 --- a/Documentation/devicetree/bindings/sound/rt5663.txt +++ b/Documentation/devicetree/bindings/sound/rt5663.txt @@ -28,7 +28,7 @@ Optional properties: If the value is 0, it means the impedance sensing is not supported. - "realtek,impedance_sensing_table" The matrix rows of the impedance sensing table are consisted by impedance - minimum, impedance maximun, volume, DC offset w/o and w/ mic of each L and + minimum, impedance maximum, volume, DC offset w/o and w/ mic of each L and R channel accordingly. Example is shown as following. < 0 300 7 0xffd160 0xffd1c0 0xff8a10 0xff8ab0 301 65535 4 0xffe470 0xffe470 0xffb8e0 0xffb8e0> diff --git a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml index 447e013f6e17..5ea0819a261a 100644 --- a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml @@ -9,6 +9,9 @@ title: Samsung Aries audio complex with WM8994 codec maintainers: - Jonathan Bakker <xc-racer2@live.ca> +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: @@ -17,10 +20,6 @@ properties: # Without FM radio and modem slave - samsung,fascinate4g-wm8994 - model: - $ref: /schemas/types.yaml#/definitions/string - description: The user-visible name of this sound complex. - cpu: type: object additionalProperties: false @@ -46,6 +45,7 @@ properties: samsung,audio-routing: $ref: /schemas/types.yaml#/definitions/non-unique-string-array + deprecated: true description: | List of the connections between audio components; each entry is a pair of strings, the first being the @@ -56,6 +56,7 @@ properties: or FM In For samsung,fascinate4g-wm8994: HP, SPK, RCV, LINE, Main Mic, or HeadsetMic + Deprecated, use audio-routing. extcon: description: Extcon phandle for dock detection @@ -87,10 +88,9 @@ properties: required: - compatible - - model - cpu - codec - - samsung,audio-routing + - audio-routing - extcon - main-micbias-supply - headset-micbias-supply @@ -98,7 +98,7 @@ required: - headset-detect-gpios - headset-key-gpios -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -121,7 +121,7 @@ examples: headset-detect-gpios = <&gph0 6 GPIO_ACTIVE_HIGH>; headset-key-gpios = <&gph3 6 GPIO_ACTIVE_HIGH>; - samsung,audio-routing = + audio-routing = "HP", "HPOUT1L", "HP", "HPOUT1R", diff --git a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml index 31095913e330..6ec80f529d84 100644 --- a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml @@ -9,14 +9,13 @@ title: Samsung Midas audio complex with WM1811 codec maintainers: - Sylwester Nawrocki <s.nawrocki@samsung.com> +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: const: samsung,midas-audio - model: - $ref: /schemas/types.yaml#/definitions/string - description: The user-visible name of this sound complex. - cpu: type: object additionalProperties: false @@ -38,6 +37,7 @@ properties: - sound-dai samsung,audio-routing: + deprecated: true $ref: /schemas/types.yaml#/definitions/non-unique-string-array description: | List of the connections between audio components; each entry is @@ -45,6 +45,7 @@ properties: being the connection's source; valid names for sources and sinks are the WM1811's pins (as documented in its binding), and the jacks on the board: HP, SPK, Main Mic, Sub Mic, Headset Mic. + Deprecated, use audio-routing. mic-bias-supply: description: Supply for the micbias on the Main microphone @@ -62,14 +63,13 @@ properties: required: - compatible - - model - cpu - codec - - samsung,audio-routing + - audio-routing - mic-bias-supply - submic-bias-supply -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -84,7 +84,7 @@ examples: mic-bias-supply = <&mic_bias_reg>; submic-bias-supply = <&submic_bias_reg>; - samsung,audio-routing = + audio-routing = "HP", "HPOUT1L", "HP", "HPOUT1R", diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml index c6751c40e63f..b77284e3e26a 100644 --- a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml @@ -10,6 +10,9 @@ maintainers: - Krzysztof Kozlowski <krzk@kernel.org> - Sylwester Nawrocki <s.nawrocki@samsung.com> +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: oneOf: @@ -24,10 +27,6 @@ properties: - const: samsung,odroid-xu4-audio deprecated: true - model: - $ref: /schemas/types.yaml#/definitions/string - description: The user-visible name of this sound complex. - assigned-clock-parents: true assigned-clock-rates: true assigned-clocks: true @@ -52,6 +51,7 @@ properties: samsung,audio-routing: $ref: /schemas/types.yaml#/definitions/non-unique-string-array + deprecated: true description: | List of the connections between audio components; each entry is a pair of strings, the first being the @@ -61,6 +61,7 @@ properties: For Odroid X2: "Headphone Jack", "Mic Jack", "DMIC" For Odroid U3, XU3: "Headphone Jack", "Speakers" For Odroid XU4: no entries + Deprecated, use audio-routing. samsung,audio-widgets: $ref: /schemas/types.yaml#/definitions/non-unique-string-array @@ -70,18 +71,17 @@ properties: required: - compatible - - model - cpu - codec -additionalProperties: false +unevaluatedProperties: false examples: - | sound { compatible = "hardkernel,odroid-xu3-audio"; model = "Odroid-XU3"; - samsung,audio-routing = + audio-routing = "Headphone Jack", "HPL", "Headphone Jack", "HPR", "IN1", "Mic Jack", diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml index 491e08019c04..760592599143 100644 --- a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml @@ -10,6 +10,9 @@ maintainers: - Krzysztof Kozlowski <krzk@kernel.org> - Sylwester Nawrocki <s.nawrocki@samsung.com> +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: const: samsung,tm2-audio @@ -32,6 +35,8 @@ properties: being the connection's source; valid names for sources and sinks are the WM5110's and MAX98504's pins and the jacks on the board: HP, SPK, Main Mic, Sub Mic, Third Mic, Headset Mic. + Deprecated, use audio-routing. + deprecated: true $ref: /schemas/types.yaml#/definitions/non-unique-string-array i2s-controller: @@ -44,20 +49,15 @@ properties: mic-bias-gpios: description: GPIO pin that enables the Main Mic bias regulator. - model: - description: The user-visible name of this sound complex. - $ref: /schemas/types.yaml#/definitions/string - required: - compatible - audio-amplifier - audio-codec - - samsung,audio-routing + - audio-routing - i2s-controller - mic-bias-gpios - - model -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -70,7 +70,7 @@ examples: audio-amplifier = <&max98504>; mic-bias-gpios = <&gpr3 2 GPIO_ACTIVE_HIGH>; model = "wm5110"; - samsung,audio-routing = "HP", "HPOUT1L", + audio-routing = "HP", "HPOUT1L", "HP", "HPOUT1R", "SPK", "SPKOUT", "SPKOUT", "HPOUT2L", diff --git a/Documentation/devicetree/bindings/sound/serial-midi.yaml b/Documentation/devicetree/bindings/sound/serial-midi.yaml index 4afc29376efc..f6a807329a5a 100644 --- a/Documentation/devicetree/bindings/sound/serial-midi.yaml +++ b/Documentation/devicetree/bindings/sound/serial-midi.yaml @@ -20,7 +20,7 @@ description: parent serial device. If the standard MIDI baud of 31.25 kBaud is needed (as would be the case if interfacing with arbitrary external MIDI devices), configure the clocks of the parent serial device so that a requested baud of 38.4 kBaud - resuts in the standard MIDI baud rate, and set the 'current-speed' property to 38400 (default) + results in the standard MIDI baud rate, and set the 'current-speed' property to 38400 (default) properties: compatible: diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml index b05e05c81cc4..59ac2d1d1ccf 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.yaml +++ b/Documentation/devicetree/bindings/sound/simple-card.yaml @@ -148,6 +148,15 @@ definitions: required: - sound-dai + additional-devs: + type: object + description: + Additional devices used by the simple audio card. + patternProperties: + '^iio-aux(-.+)?$': + type: object + $ref: audio-iio-aux.yaml# + properties: compatible: contains: @@ -187,6 +196,8 @@ properties: $ref: "#/definitions/mclk-fs" simple-audio-card,aux-devs: $ref: "#/definitions/aux-devs" + simple-audio-card,additional-devs: + $ref: "#/definitions/additional-devs" simple-audio-card,convert-rate: $ref: "#/definitions/convert-rate" simple-audio-card,convert-channels: @@ -360,6 +371,48 @@ examples: }; # -------------------- +# route audio to/from a codec through an amplifier +# designed with a potentiometer driven by IIO: +# -------------------- + - | + sound { + compatible = "simple-audio-card"; + + simple-audio-card,aux-devs = <&_in>, <&_out>; + simple-audio-card,routing = + "CODEC LEFTIN", "AMP_IN LEFT OUT", + "CODEC RIGHTIN", "AMP_IN RIGHT OUT", + "AMP_OUT LEFT IN", "CODEC LEFTOUT", + "AMP_OUT RIGHT IN", "CODEC RIGHTOUT"; + + simple-audio-card,additional-devs { + amp_out: iio-aux-out { + compatible = "audio-iio-aux"; + io-channels = <&pot_out 0>, <&pot_out 1>; + io-channel-names = "LEFT", "RIGHT"; + snd-control-invert-range = <1 1>; + sound-name-prefix = "AMP_OUT"; + }; + + amp_in: iio_aux-in { + compatible = "audio-iio-aux"; + io-channels = <&pot_in 0>, <&pot_in 1>; + io-channel-names = "LEFT", "RIGHT"; + sound-name-prefix = "AMP_IN"; + }; + }; + + simple-audio-card,cpu { + sound-dai = <&cpu>; + }; + + simple-audio-card,codec { + sound-dai = <&codec>; + clocks = <&clocks>; + }; + }; + +# -------------------- # Sampling Rate Conversion # -------------------- - | diff --git a/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml b/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml index 56e623d4e168..a48d040b0a4f 100644 --- a/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml @@ -17,6 +17,9 @@ properties: - const: snps,designware-i2s - enum: - snps,designware-i2s + - starfive,jh7110-i2stx0 + - starfive,jh7110-i2stx1 + - starfive,jh7110-i2srx reg: maxItems: 1 @@ -29,14 +32,36 @@ properties: maxItems: 1 clocks: - description: Sampling rate reference clock - maxItems: 1 + items: + - description: Sampling rate reference clock + - description: APB clock + - description: Audio master clock + - description: Inner audio master clock source + - description: External audio master clock source + - description: Bit clock + - description: Left/right channel clock + - description: External bit clock + - description: External left/right channel clock + minItems: 1 clock-names: - const: i2sclk + items: + - const: i2sclk + - const: apb + - const: mclk + - const: mclk_inner + - const: mclk_ext + - const: bclk + - const: lrck + - const: bclk_ext + - const: lrck_ext + minItems: 1 resets: - maxItems: 1 + items: + - description: Optional controller resets + - description: controller reset of Sampling rate + minItems: 1 dmas: items: @@ -50,6 +75,17 @@ properties: - const: rx minItems: 1 + starfive,syscon: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to System Register Controller sys_syscon node. + - description: I2S-rx enabled control offset of SYS_SYSCONSAIF__SYSCFG register. + - description: I2S-rx enabled control mask + description: + The phandle to System Register Controller syscon node and the I2S-rx(ADC) + enabled control offset and mask of SYS_SYSCONSAIF__SYSCFG register. + allOf: - $ref: dai-common.yaml# - if: @@ -65,6 +101,73 @@ allOf: properties: "#sound-dai-cells": const: 0 + - if: + properties: + compatible: + contains: + const: snps,designware-i2s + then: + properties: + clocks: + maxItems: 1 + clock-names: + maxItems: 1 + resets: + maxItems: 1 + else: + properties: + resets: + minItems: 2 + maxItems: 2 + - if: + properties: + compatible: + contains: + const: starfive,jh7110-i2stx0 + then: + properties: + clocks: + minItems: 5 + maxItems: 5 + clock-names: + minItems: 5 + maxItems: 5 + required: + - resets + - if: + properties: + compatible: + contains: + const: starfive,jh7110-i2stx1 + then: + properties: + clocks: + minItems: 9 + maxItems: 9 + clock-names: + minItems: 9 + maxItems: 9 + required: + - resets + - if: + properties: + compatible: + contains: + const: starfive,jh7110-i2srx + then: + properties: + clocks: + minItems: 9 + maxItems: 9 + clock-names: + minItems: 9 + maxItems: 9 + required: + - resets + - starfive,syscon + else: + properties: + starfive,syscon: false required: - compatible diff --git a/Documentation/devicetree/bindings/sound/sound-card-common.yaml b/Documentation/devicetree/bindings/sound/sound-card-common.yaml new file mode 100644 index 000000000000..3a941177f684 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/sound-card-common.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/sound-card-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Board Sound Card Common Properties + +maintainers: + - Mark Brown <broonie@kernel.org> + +properties: + audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + +required: + - model + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/sound/sprd-pcm.txt b/Documentation/devicetree/bindings/sound/sprd-pcm.txt index 4b23e84b2e57..fbbcade2181d 100644 --- a/Documentation/devicetree/bindings/sound/sprd-pcm.txt +++ b/Documentation/devicetree/bindings/sound/sprd-pcm.txt @@ -1,4 +1,4 @@ -* Spreadtrum DMA platfrom bindings +* Spreadtrum DMA platform bindings Required properties: - compatible: Should be "sprd,pcm-platform". diff --git a/Documentation/devicetree/bindings/sound/ssm2518.txt b/Documentation/devicetree/bindings/sound/ssm2518.txt deleted file mode 100644 index 59381a778c79..000000000000 --- a/Documentation/devicetree/bindings/sound/ssm2518.txt +++ /dev/null @@ -1,20 +0,0 @@ -SSM2518 audio amplifier - -This device supports I2C only. - -Required properties: - - compatible : Must be "adi,ssm2518" - - reg : the I2C address of the device. This will either be 0x34 (ADDR pin low) - or 0x35 (ADDR pin high) - -Optional properties: - - gpios : GPIO connected to the nSD pin. If the property is not present it is - assumed that the nSD pin is hardwired to always on. - -Example: - - ssm2518: ssm2518@34 { - compatible = "adi,ssm2518"; - reg = <0x34>; - gpios = <&gpio 5 0>; - }; diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml index a040d4d31412..b9111d375b93 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml @@ -61,6 +61,10 @@ properties: description: Configure the I2S device as MCLK clock provider. const: 0 + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + required: - compatible - "#sound-dai-cells" @@ -89,6 +93,13 @@ examples: dma-names = "rx", "tx"; pinctrl-names = "default"; pinctrl-0 = <&i2s2_pins_a>; + + /* assume audio-graph */ + port { + codec_endpoint: endpoint { + remote-endpoint = <&codec_endpoint>; + }; + }; }; ... diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index 56d206f97a96..59df8a832310 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -63,7 +63,7 @@ patternProperties: additionalProperties: false description: Two subnodes corresponding to SAI sub-block instances A et B - can be defined. Subnode can be omitted for unsused sub-block. + can be defined. Subnode can be omitted for unused sub-block. properties: compatible: diff --git a/Documentation/devicetree/bindings/sound/starfive,jh7110-tdm.yaml b/Documentation/devicetree/bindings/sound/starfive,jh7110-tdm.yaml new file mode 100644 index 000000000000..abb373fbfa26 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/starfive,jh7110-tdm.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/starfive,jh7110-tdm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 TDM Controller + +description: | + The TDM Controller is a Time Division Multiplexed audio interface + integrated in StarFive JH7110 SoC, allowing up to 8 channels of + audio over a serial interface. The TDM controller can operate both + in master and slave mode. + +maintainers: + - Walker Chen <walker.chen@starfivetech.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - starfive,jh7110-tdm + + reg: + maxItems: 1 + + clocks: + items: + - description: TDM AHB Clock + - description: TDM APB Clock + - description: TDM Internal Clock + - description: TDM Clock + - description: Inner MCLK + - description: TDM External Clock + + clock-names: + items: + - const: tdm_ahb + - const: tdm_apb + - const: tdm_internal + - const: tdm + - const: mclk_inner + - const: tdm_ext + + resets: + items: + - description: tdm ahb reset line + - description: tdm apb reset line + - description: tdm core reset line + + dmas: + items: + - description: RX DMA Channel + - description: TX DMA Channel + + dma-names: + items: + - const: rx + - const: tx + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - dmas + - dma-names + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + tdm@10090000 { + compatible = "starfive,jh7110-tdm"; + reg = <0x10090000 0x1000>; + clocks = <&syscrg 184>, + <&syscrg 185>, + <&syscrg 186>, + <&syscrg 187>, + <&syscrg 17>, + <&tdm_ext>; + clock-names = "tdm_ahb", "tdm_apb", + "tdm_internal", "tdm", + "mclk_inner", "tdm_ext"; + resets = <&syscrg 105>, + <&syscrg 107>, + <&syscrg 106>; + dmas = <&dma 20>, <&dma 21>; + dma-names = "rx","tx"; + #sound-dai-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/sound/tas2562.yaml b/Documentation/devicetree/bindings/sound/tas2562.yaml index 31a3024ea789..f01c0dde0cf7 100644 --- a/Documentation/devicetree/bindings/sound/tas2562.yaml +++ b/Documentation/devicetree/bindings/sound/tas2562.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2019 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/sound/tas2562.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/sound/tas2562.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments TAS2562 Smart PA diff --git a/Documentation/devicetree/bindings/sound/tas2770.yaml b/Documentation/devicetree/bindings/sound/tas2770.yaml index 8908bf1122e9..be2536e8c440 100644 --- a/Documentation/devicetree/bindings/sound/tas2770.yaml +++ b/Documentation/devicetree/bindings/sound/tas2770.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2019-20 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/sound/tas2770.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/sound/tas2770.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments TAS2770 Smart PA diff --git a/Documentation/devicetree/bindings/sound/tas27xx.yaml b/Documentation/devicetree/bindings/sound/tas27xx.yaml index a876545ec87d..f2d878f6f495 100644 --- a/Documentation/devicetree/bindings/sound/tas27xx.yaml +++ b/Documentation/devicetree/bindings/sound/tas27xx.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2020-2022 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/sound/tas27xx.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/sound/tas27xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments TAS2764/TAS2780 Smart PA diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml index 859d369c71e2..5b2874a80a4d 100644 --- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml @@ -13,7 +13,7 @@ maintainers: description: | The Infotainment board plugs into the Common Processor Board, the support of the - extension board is extending the CPB audio support, decribed in: + extension board is extending the CPB audio support, described in: sound/ti,j721e-cpb-audio.txt The audio support on the Infotainment Expansion Board consists of McASP0 diff --git a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml new file mode 100644 index 000000000000..a69e6c223308 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 - 2023 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ti,tas2781.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TAS2781 SmartAMP + +maintainers: + - Shenghao Ding <shenghao-ding@ti.com> + +description: + The TAS2781 is a mono, digital input Class-D audio amplifier + optimized for efficiently driving high peak power into small + loudspeakers. An integrated on-chip DSP supports Texas Instruments + Smart Amp speaker protection algorithm. The integrated speaker + voltage and current sense provides for real time + monitoring of loudspeaker behavior. + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - ti,tas2781 + + reg: + description: + I2C address, in multiple tas2781s case, all the i2c address + aggregate as one Audio Device to support multiple audio slots. + maxItems: 8 + minItems: 1 + items: + minimum: 0x38 + maximum: 0x3f + + reset-gpios: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + +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>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/sound/ti,tlv320aic32x4.yaml b/Documentation/devicetree/bindings/sound/ti,tlv320aic32x4.yaml new file mode 100644 index 000000000000..a7cc9aa34468 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,tlv320aic32x4.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2019 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ti,tlv320aic32x4.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TLV320AIC32x4 Stereo Audio codec + +maintainers: + - Alexander Stein <alexander.stein@ew.tq-group.com> + +description: | + The TLV320AIC32x4 audio codec can be accessed using I2C or SPI + +properties: + compatible: + enum: + - ti,tas2505 + - ti,tlv320aic32x4 + - ti,tlv320aic32x6 + + reg: + maxItems: 1 + + clocks: + items: + - description: Master clock + + clock-names: + items: + - const: mclk + + av-supply: + description: Analog core power supply + + dv-supply: + description: Digital core power supply + + iov-supply: + description: Digital IO power supply + + ldoin-supply: + description: LDO power supply + + reset-gpios: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + + aic32x4-gpio-func: + description: | + GPIO function configuration for pins MFP1-MFP5. + Types are defined in include/sound/tlv320aic32x4.h + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 5 + maxItems: 5 + +required: + - compatible + - reg + - clocks + - clock-names + - iov-supply + +allOf: + - $ref: dai-common.yaml# + - if: + not: + required: + - ldoin-supply + then: + required: + - av-supply + - dv-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + audio-codec@18 { + compatible = "ti,tlv320aic32x4"; + reg = <0x18>; + iov-supply = <®_3v3>; + ldoin-supply = <®_3v3>; + clocks = <&clks 201>; + clock-names = "mclk"; + aic32x4-gpio-func= < + 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */ + 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */ + 0x04 /* MFP3 AIC32X4_MFP3_GPIO_ENABLED */ + 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */ + 0x08 /* MFP5 AIC32X4_MFP5_GPIO_INPUT */ + >; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml b/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml index e8ca9f3369f8..206f6d61e362 100644 --- a/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml +++ b/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml @@ -61,6 +61,7 @@ properties: GPIO specification for the active low RESET input. gpio-reset: + $ref: /schemas/types.yaml#/definitions/uint32-matrix maxItems: 1 description: Deprecated, please use reset-gpios instead. diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index c16e1760cf85..f3274bcc4c05 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml @@ -32,7 +32,7 @@ properties: reg: maxItems: 1 description: | - I2C addresss of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f + I2C address of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f reset-gpios: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt deleted file mode 100644 index 0b4e21bde5bc..000000000000 --- a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt +++ /dev/null @@ -1,42 +0,0 @@ -Texas Instruments - tlv320aic32x4 Codec module - -The tlv320aic32x4 serial control bus communicates through I2C protocols - -Required properties: - - compatible - "string" - One of: - "ti,tlv320aic32x4" TLV320AIC3204 - "ti,tlv320aic32x6" TLV320AIC3206, TLV320AIC3256 - "ti,tas2505" TAS2505, TAS2521 - - reg: I2C slave address - - *-supply: Required supply regulators are: - "iov" - digital IO power supply - "ldoin" - LDO power supply - "dv" - Digital core power supply - "av" - Analog core power supply - If you supply ldoin, dv and av are optional. Otherwise they are required - See regulator/regulator.txt for more information about the detailed binding - format. - -Optional properties: - - reset-gpios: Reset-GPIO phandle with args as described in gpio/gpio.txt - - clocks/clock-names: Clock named 'mclk' for the master clock of the codec. - See clock/clock-bindings.txt for information about the detailed format. - - aic32x4-gpio-func - <array of 5 int> - - Types are defined in include/sound/tlv320aic32x4.h - - -Example: - -codec: tlv320aic32x4@18 { - compatible = "ti,tlv320aic32x4"; - reg = <0x18>; - clocks = <&clks 201>; - clock-names = "mclk"; - aic32x4-gpio-func= < - 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */ - 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */ - 0x04 /* MFP3 AIC32X4_MFP3_GPIO_ENABLED */ - 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */ - 0x08 /* MFP5 AIC32X4_MFP5_GPIO_INPUT */ - >; -}; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml index 7105ed5fd6c7..4cfa66f62681 100644 --- a/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml +++ b/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/sound/wlf,wm8903.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/sound/wlf,wm8903.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: WM8903 audio codec diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml new file mode 100644 index 000000000000..329260cf0fa0 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8904.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wolfson WM8904/WM8912 audio codecs + +maintainers: + - patches@opensource.cirrus.com + +description: | + Pins on the device (for linking into audio routes): + IN1L, IN1R, IN2L, IN2R, IN3L, IN3R, HPOUTL, HPOUTR, LINEOUTL, LINEOUTR, + MICBIAS + +properties: + compatible: + enum: + - wlf,wm8904 + - wlf,wm8912 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + clocks: + maxItems: 1 + + clock-names: + const: mclk + + AVDD-supply: true + CPVDD-supply: true + DBVDD-supply: true + DCVDD-supply: true + MICVDD-supply: true + +required: + - compatible + - reg + - clocks + - clock-names + - AVDD-supply + - CPVDD-supply + - DBVDD-supply + - DCVDD-supply + - MICVDD-supply + +allOf: + - $ref: dai-common.yaml# + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + compatible = "wlf,wm8904"; + reg = <0x1a>; + clocks = <&pck0>; + clock-names = "mclk"; + AVDD-supply = <®_1p8v>; + CPVDD-supply = <®_1p8v>; + DBVDD-supply = <®_1p8v>; + DCVDD-supply = <®_1p8v>; + MICVDD-supply = <®_1p8v>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml index ee8eba7f0104..62e62c335d07 100644 --- a/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml +++ b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml @@ -26,6 +26,21 @@ properties: '#sound-dai-cells': const: 0 + AVDD-supply: + description: Analogue supply. + + DBVDD-supply: + description: Digital Buffer Supply. + + DCVDD-supply: + description: Digital Core Supply. + + SPKVDD1-supply: + description: Supply for speaker drivers 1. + + SPKVDD2-supply: + description: Supply for speaker drivers 2. + wlf,capless: type: boolean description: @@ -84,5 +99,10 @@ examples: wlf,hp-cfg = <3 2 3>; wlf,gpio-cfg = <1 3>; wlf,shared-lrclk; + DCVDD-supply = <®_audio>; + DBVDD-supply = <®_audio>; + AVDD-supply = <®_audio>; + SPKVDD1-supply = <®_audio>; + SPKVDD2-supply = <®_audio>; }; }; diff --git a/Documentation/devicetree/bindings/sound/wm8904.txt b/Documentation/devicetree/bindings/sound/wm8904.txt deleted file mode 100644 index 66bf261423b9..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8904.txt +++ /dev/null @@ -1,33 +0,0 @@ -WM8904 audio CODEC - -This device supports I2C only. - -Required properties: - - compatible: "wlf,wm8904" or "wlf,wm8912" - - reg: the I2C address of the device. - - clock-names: "mclk" - - clocks: reference to - <Documentation/devicetree/bindings/clock/clock-bindings.txt> - -Pins on the device (for linking into audio routes): - - * IN1L - * IN1R - * IN2L - * IN2R - * IN3L - * IN3R - * HPOUTL - * HPOUTR - * LINEOUTL - * LINEOUTR - * MICBIAS - -Examples: - -codec: wm8904@1a { - compatible = "wlf,wm8904"; - reg = <0x1a>; - clocks = <&pck0>; - clock-names = "mclk"; -}; diff --git a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml index e4dba825ab11..7d60a9654912 100644 --- a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml +++ b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml @@ -21,6 +21,7 @@ properties: - qcom,soundwire-v1.5.1 - qcom,soundwire-v1.6.0 - qcom,soundwire-v1.7.0 + - qcom,soundwire-v2.0.0 reg: maxItems: 1 @@ -80,18 +81,29 @@ properties: or applicable for the respective data port. More info in MIPI Alliance SoundWire 1.0 Specifications. minItems: 3 - maxItems: 8 + maxItems: 16 qcom,ports-sinterval-low: $ref: /schemas/types.yaml#/definitions/uint8-array description: - Sample interval low of each data port. + Sample interval (only lowest byte) of each data port. Out ports followed by In ports. Used for Sample Interval calculation. Value of 0xff indicates that this option is not implemented or applicable for the respective data port. More info in MIPI Alliance SoundWire 1.0 Specifications. minItems: 3 - maxItems: 8 + maxItems: 16 + + qcom,ports-sinterval: + $ref: /schemas/types.yaml#/definitions/uint16-array + description: + Sample interval of each data port. + Out ports followed by In ports. Used for Sample Interval calculation. + Value of 0xffff indicates that this option is not implemented + or applicable for the respective data port. + More info in MIPI Alliance SoundWire 1.0 Specifications. + minItems: 3 + maxItems: 16 qcom,ports-offset1: $ref: /schemas/types.yaml#/definitions/uint8-array @@ -102,7 +114,7 @@ properties: or applicable for the respective data port. More info in MIPI Alliance SoundWire 1.0 Specifications. minItems: 3 - maxItems: 8 + maxItems: 16 qcom,ports-offset2: $ref: /schemas/types.yaml#/definitions/uint8-array @@ -113,7 +125,7 @@ properties: or applicable for the respective data port. More info in MIPI Alliance SoundWire 1.0 Specifications. minItems: 3 - maxItems: 8 + maxItems: 16 qcom,ports-lane-control: $ref: /schemas/types.yaml#/definitions/uint8-array @@ -124,7 +136,7 @@ properties: or applicable for the respective data port. More info in MIPI Alliance SoundWire 1.0 Specifications. minItems: 3 - maxItems: 8 + maxItems: 16 qcom,ports-block-pack-mode: $ref: /schemas/types.yaml#/definitions/uint8-array @@ -137,7 +149,7 @@ properties: or applicable for the respective data port. More info in MIPI Alliance SoundWire 1.0 Specifications. minItems: 3 - maxItems: 8 + maxItems: 16 items: oneOf: - minimum: 0 @@ -147,14 +159,14 @@ properties: qcom,ports-hstart: $ref: /schemas/types.yaml#/definitions/uint8-array description: - Identifying lowerst numbered coloum in SoundWire Frame, + Identifying lowerst numbered column in SoundWire Frame, i.e. left edge of the Transport sub-frame for each port. Out ports followed by In ports. Value of 0xff indicates that this option is not implemented or applicable for the respective data port. More info in MIPI Alliance SoundWire 1.0 Specifications. minItems: 3 - maxItems: 8 + maxItems: 16 items: oneOf: - minimum: 0 @@ -164,14 +176,14 @@ properties: qcom,ports-hstop: $ref: /schemas/types.yaml#/definitions/uint8-array description: - Identifying highest numbered coloum in SoundWire Frame, + Identifying highest numbered column in SoundWire Frame, i.e. the right edge of the Transport sub-frame for each port. Out ports followed by In ports. Value of 0xff indicates that this option is not implemented or applicable for the respective data port. More info in MIPI Alliance SoundWire 1.0 Specifications. minItems: 3 - maxItems: 8 + maxItems: 16 items: oneOf: - minimum: 0 @@ -187,7 +199,7 @@ properties: or applicable for the respective data port. More info in MIPI Alliance SoundWire 1.0 Specifications. minItems: 3 - maxItems: 8 + maxItems: 16 items: oneOf: - minimum: 0 @@ -219,10 +231,15 @@ required: - '#size-cells' - qcom,dout-ports - qcom,din-ports - - qcom,ports-sinterval-low - qcom,ports-offset1 - qcom,ports-offset2 +oneOf: + - required: + - qcom,ports-sinterval-low + - required: + - qcom,ports-sinterval + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml index 2155478bfc4d..a6f34bdd1d3c 100644 --- a/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml +++ b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml @@ -14,9 +14,6 @@ maintainers: - Maxime Ripard <mripard@kernel.org> properties: - "#address-cells": true - "#size-cells": true - compatible: const: allwinner,sun4i-a10-spi @@ -46,12 +43,9 @@ properties: - const: rx - const: tx - num-cs: true - patternProperties: "^.*@[0-9a-f]+": type: object - additionalProperties: true properties: reg: items: @@ -71,7 +65,7 @@ required: - clocks - clock-names -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml index de36c6a34a0f..28b8ace63044 100644 --- a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml +++ b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml @@ -14,11 +14,9 @@ maintainers: - Maxime Ripard <mripard@kernel.org> properties: - "#address-cells": true - "#size-cells": true - compatible: oneOf: + - const: allwinner,sun50i-r329-spi - const: allwinner,sun6i-a31-spi - const: allwinner,sun8i-h3-spi - items: @@ -28,6 +26,15 @@ properties: - allwinner,sun50i-h616-spi - allwinner,suniv-f1c100s-spi - const: allwinner,sun8i-h3-spi + - items: + - enum: + - allwinner,sun20i-d1-spi + - allwinner,sun50i-r329-spi-dbi + - const: allwinner,sun50i-r329-spi + - items: + - const: allwinner,sun20i-d1-spi-dbi + - const: allwinner,sun50i-r329-spi-dbi + - const: allwinner,sun50i-r329-spi reg: maxItems: 1 @@ -58,12 +65,9 @@ properties: - const: rx - const: tx - num-cs: true - patternProperties: "^.*@[0-9a-f]+": type: object - additionalProperties: true properties: reg: items: @@ -83,7 +87,7 @@ required: - clocks - clock-names -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml b/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml index 6c57dd6c3a36..58367587bfbc 100644 --- a/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml +++ b/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml @@ -20,6 +20,10 @@ properties: - items: - const: microchip,sam9x60-spi - const: atmel,at91rm9200-spi + - items: + - const: microchip,sam9x7-spi + - const: microchip,sam9x60-spi + - const: atmel,at91rm9200-spi reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt b/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt index 9887b0724759..d7668f41b03b 100644 --- a/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt +++ b/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt @@ -1,4 +1,4 @@ -Broadcom BCM2835 auxiliar SPI1/2 controller +Broadcom BCM2835 auxiliary SPI1/2 controller The BCM2835 contains two forms of SPI master controller, one known simply as SPI0, and the other known as the "Universal SPI Master"; part of the @@ -9,7 +9,7 @@ Required properties: - reg: Should contain register location and length for the spi block - interrupts: Should contain shared interrupt of the aux block - clocks: The clock feeding the SPI controller - needs to - point to the auxiliar clock driver of the bcm2835, + point to the auxiliary clock driver of the bcm2835, as this clock will enable the output gate for the specific clock. - cs-gpios: the cs-gpios (native cs is NOT supported) diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-spi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-spi.yaml new file mode 100644 index 000000000000..fa03cdd68e70 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-spi.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/brcm,bcm63xx-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM6348/BCM6358 SPI controller + +maintainers: + - Jonas Gorski <jonas.gorski@gmail.com> + +description: | + Broadcom "Low Speed" SPI controller found in many older MIPS based Broadband + SoCs. + + This controller has a limitation that can not keep the chip select line active + between the SPI transfers within the same SPI message. This can terminate the + transaction to some SPI devices prematurely. The issue can be worked around by + the controller's prepend mode. + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + oneOf: + - items: + - enum: + - brcm,bcm6368-spi + - brcm,bcm6362-spi + - brcm,bcm63268-spi + - const: brcm,bcm6358-spi + - enum: + - brcm,bcm6348-spi + - brcm,bcm6358-spi + + reg: + maxItems: 1 + + clocks: + items: + - description: SPI master reference clock + + clock-names: + items: + - const: spi + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +unevaluatedProperties: false + +examples: + - | + spi@10000800 { + compatible = "brcm,bcm6368-spi", "brcm,bcm6358-spi"; + reg = <0x10000800 0x70c>; + interrupts = <1>; + clocks = <&clkctl 9>; + clock-names = "spi"; + num-cs = <5>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml index 28222aae3077..45975f40d943 100644 --- a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml @@ -12,7 +12,7 @@ maintainers: description: | The Broadcom SPI controller is a SPI master found on various SOCs, including - BRCMSTB (BCM7XXX), Cygnus, NSP and NS2. The Broadcom Master SPI hw IP consits + BRCMSTB (BCM7XXX), Cygnus, NSP and NS2. The Broadcom Master SPI hw IP consists of: MSPI : SPI master controller can read and write to a SPI slave device BSPI : Broadcom SPI in combination with the MSPI hw IP provides acceleration @@ -20,7 +20,7 @@ description: | io with 3-byte and 4-byte addressing support. Supported Broadcom SoCs have one instance of MSPI+BSPI controller IP. - MSPI master can be used wihout BSPI. BRCMSTB SoCs have an additional instance + MSPI master can be used without BSPI. BRCMSTB SoCs have an additional instance of a MSPI master without the BSPI to use with non flash slave devices that use SPI protocol. diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml index b310069762dd..cca81f89e252 100644 --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml @@ -46,12 +46,28 @@ allOf: maxItems: 2 items: enum: [ qspi, qspi-ocp ] + - if: + properties: + compatible: + contains: + const: amd,pensando-elba-qspi + then: + properties: + cdns,fifo-depth: + enum: [ 128, 256, 1024 ] + default: 1024 + else: + properties: + cdns,fifo-depth: + enum: [ 128, 256 ] + default: 128 properties: compatible: oneOf: - items: - enum: + - amd,pensando-elba-qspi - ti,k2g-qspi - ti,am654-ospi - intel,lgm-qspi @@ -70,14 +86,22 @@ properties: maxItems: 1 clocks: - maxItems: 1 + minItems: 1 + maxItems: 3 + + clock-names: + oneOf: + - items: + - const: ref + - items: + - const: ref + - const: ahb + - const: apb cdns,fifo-depth: description: Size of the data FIFO in words. $ref: /schemas/types.yaml#/definitions/uint32 - enum: [ 128, 256 ] - default: 128 cdns,fifo-width: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/spi/loongson,ls2k-spi.yaml b/Documentation/devicetree/bindings/spi/loongson,ls2k-spi.yaml new file mode 100644 index 000000000000..de9d32feadf5 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/loongson,ls2k-spi.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/loongson,ls2k-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson SPI controller + +maintainers: + - Yinbo Zhu <zhuyinbo@loongson.cn> + +allOf: + - $ref: /schemas/spi/spi-controller.yaml# + +properties: + compatible: + oneOf: + - enum: + - loongson,ls2k1000-spi + - items: + - enum: + - loongson,ls2k0500-spi + - const: loongson,ls2k1000-spi + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + +unevaluatedProperties: false + +examples: + - | + spi0: spi@1fff0220{ + compatible = "loongson,ls2k1000-spi"; + reg = <0x1fff0220 0x10>; + clocks = <&clk 17>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt deleted file mode 100644 index db8e0d71c5bc..000000000000 --- a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt +++ /dev/null @@ -1,61 +0,0 @@ -NVIDIA Tegra114 SPI controller. - -Required properties: -- compatible : For Tegra114, must contain "nvidia,tegra114-spi". - Otherwise, must contain '"nvidia,<chip>-spi", "nvidia,tegra114-spi"' where - <chip> is tegra124, tegra132, or tegra210. -- reg: Should contain SPI registers location and length. -- interrupts: Should contain SPI interrupts. -- clock-names : Must include the following entries: - - spi -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - spi -- dmas : Must contain an entry for each entry in clock-names. - See ../dma/dma.txt for details. -- dma-names : Must include the following entries: - - rx - - tx -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - -Recommended properties: -- spi-max-frequency: Definition as per - Documentation/devicetree/bindings/spi/spi-bus.txt -Optional properties: -- nvidia,tx-clk-tap-delay: Delays the clock going out to the external device - with this tap value. This property is used to tune the outgoing data from - Tegra SPI master with respect to outgoing Tegra SPI master clock. - Tap values vary based on the platform design trace lengths from Tegra SPI - to corresponding slave devices. Valid tap values are from 0 thru 63. -- nvidia,rx-clk-tap-delay: Delays the clock coming in from the external device - with this tap value. This property is used to adjust the Tegra SPI master - clock with respect to the data from the SPI slave device. - Tap values vary based on the platform design trace lengths from Tegra SPI - to corresponding slave devices. Valid tap values are from 0 thru 63. - -Example: - -spi@7000d600 { - compatible = "nvidia,tegra114-spi"; - reg = <0x7000d600 0x200>; - interrupts = <0 82 0x04>; - spi-max-frequency = <25000000>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&tegra_car 44>; - clock-names = "spi"; - resets = <&tegra_car 44>; - reset-names = "spi"; - dmas = <&apbdma 16>, <&apbdma 16>; - dma-names = "rx", "tx"; - <spi-client>@<bus_num> { - ... - ... - nvidia,rx-clk-tap-delay = <0>; - nvidia,tx-clk-tap-delay = <16>; - ... - }; - -}; diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.yaml new file mode 100644 index 000000000000..58222ffa53d7 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/nvidia,tegra114-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra114 SPI controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + oneOf: + - const: nvidia,tegra114-spi + - items: + - enum: + - nvidia,tegra210-spi + - nvidia,tegra124-spi + - const: nvidia,tegra114-spi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: SPI module clock + + clock-names: + items: + - const: spi + + resets: + items: + - description: SPI module reset + + reset-names: + items: + - const: spi + + dmas: + items: + - description: DMA channel for the reception FIFO + - description: DMA channel for the transmission FIFO + + dma-names: + items: + - const: rx + - const: tx + + spi-max-frequency: + description: Maximum SPI clocking speed of the controller in Hz. + $ref: /schemas/types.yaml#/definitions/uint32 + +allOf: + - $ref: spi-controller.yaml + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + - dmas + - dma-names + +examples: + - | + spi@7000d600 { + compatible = "nvidia,tegra114-spi"; + reg = <0x7000d600 0x200>; + interrupts = <0 82 0x04>; + clocks = <&tegra_car 44>; + clock-names = "spi"; + resets = <&tegra_car 44>; + reset-names = "spi"; + dmas = <&apbdma 16>, <&apbdma 16>; + dma-names = "rx", "tx"; + + spi-max-frequency = <25000000>; + + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + spi-max-frequency = <20000000>; + nvidia,rx-clk-tap-delay = <0>; + nvidia,tx-clk-tap-delay = <16>; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt deleted file mode 100644 index c212491929b5..000000000000 --- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt +++ /dev/null @@ -1,37 +0,0 @@ -NVIDIA Tegra20 SFLASH controller. - -Required properties: -- compatible : should be "nvidia,tegra20-sflash". -- reg: Should contain SFLASH registers location and length. -- interrupts: Should contain SFLASH interrupts. -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - spi -- dmas : Must contain an entry for each entry in clock-names. - See ../dma/dma.txt for details. -- dma-names : Must include the following entries: - - rx - - tx - -Recommended properties: -- spi-max-frequency: Definition as per - Documentation/devicetree/bindings/spi/spi-bus.txt - -Example: - -spi@7000c380 { - compatible = "nvidia,tegra20-sflash"; - reg = <0x7000c380 0x80>; - interrupts = <0 39 0x04>; - spi-max-frequency = <25000000>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&tegra_car 43>; - resets = <&tegra_car 43>; - reset-names = "spi"; - dmas = <&apbdma 11>, <&apbdma 11>; - dma-names = "rx", "tx"; -}; diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.yaml new file mode 100644 index 000000000000..e245bad85a25 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/nvidia,tegra20-sflash.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20 SFLASH controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,tegra20-sflash + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: module clock + + resets: + items: + - description: module reset + + reset-names: + items: + - const: spi + + dmas: + items: + - description: DMA channel used for reception + - description: DMA channel used for transmission + + dma-names: + items: + - const: rx + - const: tx + + spi-max-frequency: + description: Maximum SPI clocking speed of the controller in Hz. + $ref: /schemas/types.yaml#/definitions/uint32 + +allOf: + - $ref: spi-controller.yaml + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - resets + - reset-names + - dmas + - dma-names + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + spi@7000c380 { + compatible = "nvidia,tegra20-sflash"; + reg = <0x7000c380 0x80>; + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>; + spi-max-frequency = <25000000>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&tegra_car TEGRA20_CLK_SPI>; + resets = <&tegra_car 43>; + reset-names = "spi"; + dmas = <&apbdma 11>, <&apbdma 11>; + dma-names = "rx", "tx"; + }; diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt deleted file mode 100644 index 40d80b93e327..000000000000 --- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt +++ /dev/null @@ -1,37 +0,0 @@ -NVIDIA Tegra20/Tegra30 SLINK controller. - -Required properties: -- compatible : should be "nvidia,tegra20-slink", "nvidia,tegra30-slink". -- reg: Should contain SLINK registers location and length. -- interrupts: Should contain SLINK interrupts. -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - spi -- dmas : Must contain an entry for each entry in clock-names. - See ../dma/dma.txt for details. -- dma-names : Must include the following entries: - - rx - - tx - -Recommended properties: -- spi-max-frequency: Definition as per - Documentation/devicetree/bindings/spi/spi-bus.txt - -Example: - -spi@7000d600 { - compatible = "nvidia,tegra20-slink"; - reg = <0x7000d600 0x200>; - interrupts = <0 82 0x04>; - spi-max-frequency = <25000000>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&tegra_car 44>; - resets = <&tegra_car 44>; - reset-names = "spi"; - dmas = <&apbdma 16>, <&apbdma 16>; - dma-names = "rx", "tx"; -}; diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.yaml new file mode 100644 index 000000000000..291c25ec015d --- /dev/null +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/nvidia,tegra20-slink.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20/30 SLINK controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + enum: + - nvidia,tegra20-slink + - nvidia,tegra30-slink + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: module clock + + resets: + items: + - description: module reset + + reset-names: + items: + - const: spi + + dmas: + items: + - description: DMA channel used for reception + - description: DMA channel used for transmission + + dma-names: + items: + - const: rx + - const: tx + + operating-points-v2: + $ref: /schemas/types.yaml#/definitions/phandle + + power-domains: + items: + - description: phandle to the core power domain + + spi-max-frequency: + description: Maximum SPI clocking speed of the controller in Hz. + $ref: /schemas/types.yaml#/definitions/uint32 + +allOf: + - $ref: spi-controller.yaml + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - resets + - reset-names + - dmas + - dma-names + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + spi@7000d600 { + compatible = "nvidia,tegra20-slink"; + reg = <0x7000d600 0x200>; + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>; + spi-max-frequency = <25000000>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&tegra_car TEGRA20_CLK_SBC2>; + resets = <&tegra_car 44>; + reset-names = "spi"; + dmas = <&apbdma 16>, <&apbdma 16>; + dma-names = "rx", "tx"; + }; diff --git a/Documentation/devicetree/bindings/spi/omap-spi.yaml b/Documentation/devicetree/bindings/spi/omap-spi.yaml index 352affa4b7f8..ff4d361707bd 100644 --- a/Documentation/devicetree/bindings/spi/omap-spi.yaml +++ b/Documentation/devicetree/bindings/spi/omap-spi.yaml @@ -68,7 +68,7 @@ properties: dma-names: description: List of DMA request names. These strings correspond 1:1 with - the DMA sepecifiers listed in dmas. The string names is to be + the DMA specifiers listed in dmas. The string names is to be "rxN" and "txN" for RX and TX requests, respectively. Where N is the chip select number. minItems: 1 diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml index ee8f7ea907b0..1696ac46a660 100644 --- a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml @@ -29,6 +29,9 @@ properties: reg: maxItems: 1 + iommus: + maxItems: 1 + interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml b/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml new file mode 100644 index 000000000000..e59183e53690 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/renesas,rzv2m-csi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/V2M Clocked Serial Interface (CSI) + +maintainers: + - Fabrizio Castro <fabrizio.castro.jz@renesas.com> + - Geert Uytterhoeven <geert+renesas@glider.be> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + const: renesas,rzv2m-csi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: The clock used to generate the output clock (CSICLK) + - description: Internal clock to access the registers (PCLK) + + clock-names: + items: + - const: csiclk + - const: pclk + + resets: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - power-domains + - '#address-cells' + - '#size-cells' + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/r9a09g011-cpg.h> + csi4: spi@a4020200 { + compatible = "renesas,rzv2m-csi"; + reg = <0xa4020200 0x80>; + interrupts = <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD R9A09G011_CSI4_CLK>, + <&cpg CPG_MOD R9A09G011_CPERI_GRPH_PCLK>; + clock-names = "csiclk", "pclk"; + resets = <&cpg R9A09G011_CSI_GPH_PRESETN>; + power-domains = <&cpg>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/spi/samsung,spi.yaml b/Documentation/devicetree/bindings/spi/samsung,spi.yaml index e0a465d70b0a..79da99ca0e53 100644 --- a/Documentation/devicetree/bindings/spi/samsung,spi.yaml +++ b/Documentation/devicetree/bindings/spi/samsung,spi.yaml @@ -35,8 +35,6 @@ properties: minItems: 2 maxItems: 3 - cs-gpios: true - dmas: minItems: 2 maxItems: 2 diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml index 12ca108864c6..a47cb144b09f 100644 --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml @@ -74,6 +74,8 @@ properties: const: intel,keembay-ssi - description: Intel Thunder Bay SPI Controller const: intel,thunderbay-ssi + - description: Intel Mount Evans Integrated Management Complex SPI Controller + const: intel,mountevans-imc-ssi - description: AMD Pensando Elba SoC SPI Controller const: amd,pensando-elba-spi - description: Baikal-T1 SPI Controller diff --git a/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml b/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml index 597fc4e6b01c..c96131ebbea1 100644 --- a/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml +++ b/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml @@ -17,9 +17,6 @@ allOf: - $ref: spi-controller.yaml# properties: - "#address-cells": true - "#size-cells": true - compatible: const: socionext,uniphier-scssi diff --git a/Documentation/devicetree/bindings/spi/spi-bcm63xx.txt b/Documentation/devicetree/bindings/spi/spi-bcm63xx.txt deleted file mode 100644 index 1c16f6692613..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-bcm63xx.txt +++ /dev/null @@ -1,33 +0,0 @@ -Binding for Broadcom BCM6348/BCM6358 SPI controller - -Required properties: -- compatible: must contain one of "brcm,bcm6348-spi", "brcm,bcm6358-spi". -- reg: Base address and size of the controllers memory area. -- interrupts: Interrupt for the SPI block. -- clocks: phandle of the SPI clock. -- clock-names: has to be "spi". -- #address-cells: <1>, as required by generic SPI binding. -- #size-cells: <0>, also as required by generic SPI binding. - -Optional properties: -- num-cs: some controllers have less than 8 cs signals. Defaults to 8 - if absent. - -Child nodes as per the generic SPI binding. - -Example: - - spi@10000800 { - compatible = "brcm,bcm6368-spi", "brcm,bcm6358-spi"; - reg = <0x10000800 0x70c>; - - interrupts = <1>; - - clocks = <&clkctl 9>; - clock-names = "spi"; - - num-cs = <5>; - - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.yaml b/Documentation/devicetree/bindings/spi/spi-cadence.yaml index b0f83b5c2cdd..d4b61b0e8301 100644 --- a/Documentation/devicetree/bindings/spi/spi-cadence.yaml +++ b/Documentation/devicetree/bindings/spi/spi-cadence.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence SPI controller maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> allOf: - $ref: spi-controller.yaml# @@ -49,6 +49,12 @@ properties: enum: [ 0, 1 ] default: 0 + power-domains: + maxItems: 1 + + label: + description: Descriptive name of the SPI controller. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 90945f59b7e8..524f6fe8c27b 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -17,7 +17,7 @@ description: | properties: $nodename: - pattern: "^spi(@.*|-[0-9a-f])*$" + pattern: "^spi(@.*|-([0-9]|[1-9][0-9]+))?$" "#address-cells": enum: [0, 1] diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml index e91425012319..727c5346b8ce 100644 --- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml @@ -63,6 +63,9 @@ properties: maximum: 2 default: 1 + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml index a813c971ecf6..7fd591145480 100644 --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml @@ -45,6 +45,9 @@ properties: - const: fspi_en - const: fspi + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/spi/spi-pl022.yaml b/Documentation/devicetree/bindings/spi/spi-pl022.yaml index 91e540a92faf..5e5a704a766e 100644 --- a/Documentation/devicetree/bindings/spi/spi-pl022.yaml +++ b/Documentation/devicetree/bindings/spi/spi-pl022.yaml @@ -11,6 +11,7 @@ maintainers: allOf: - $ref: spi-controller.yaml# + - $ref: /schemas/arm/primecell.yaml# # We need a select here so we don't match all nodes with 'arm,primecell' select: diff --git a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml index 6bd83836eded..4beb3af0416d 100644 --- a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml +++ b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx SPI controller maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> allOf: - $ref: spi-controller.yaml# diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml index 20f77246d365..e5199b109dad 100644 --- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx Zynq UltraScale+ MPSoC GQSPI controller maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> allOf: - $ref: spi-controller.yaml# @@ -32,6 +32,12 @@ properties: clocks: maxItems: 2 + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml index 83e8fb4a548d..7ea8fb42ce2c 100644 --- a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml @@ -14,7 +14,7 @@ allOf: - $ref: spi-controller.yaml# maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> # Everything else is described in the common file properties: diff --git a/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml b/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml index abcbbe13723f..ac99883a3f29 100644 --- a/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml +++ b/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml @@ -14,13 +14,18 @@ description: |+ for multiple SoCs to control a single SPMI master. allOf: - - $ref: "spmi.yaml" + - $ref: spmi.yaml properties: compatible: - enum: - - mediatek,mt6873-spmi - - mediatek,mt8195-spmi + oneOf: + - enum: + - mediatek,mt6873-spmi + - mediatek,mt8195-spmi + - items: + - enum: + - mediatek,mt8186-spmi + - const: mediatek,mt8195-spmi reg: maxItems: 2 diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml index 0548e8e0d30b..8025a852bc9c 100644 --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml @@ -18,8 +18,10 @@ properties: items: - enum: - qcom,apq8064-imem + - qcom,msm8226-imem - qcom,msm8974-imem - qcom,qcs404-imem + - qcom,qdu1000-imem - qcom,sc7180-imem - qcom,sc7280-imem - qcom,sdm630-imem diff --git a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml index 4bbf6db0b6bd..61c784ef7b51 100644 --- a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml +++ b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml @@ -15,7 +15,9 @@ description: | properties: compatible: - const: qcom,msm8974-ocmem + enum: + - qcom,msm8226-ocmem # v1.1.0 + - qcom,msm8974-ocmem # v1.4.0 reg: items: @@ -28,11 +30,13 @@ properties: - const: mem clocks: + minItems: 1 items: - description: Core clock - description: Interface clock clock-names: + minItems: 1 items: - const: core - const: iface @@ -58,6 +62,26 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8974-ocmem + then: + properties: + clocks: + minItems: 2 + clock-names: + minItems: 2 + else: + properties: + clocks: + minItems: 1 + clock-names: + minItems: 1 + patternProperties: "-sram@[0-9a-f]+$": type: object diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index 993430be355b..0922d1f71ba8 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -94,6 +94,7 @@ patternProperties: - samsung,exynos4210-sysram - samsung,exynos4210-sysram-ns - socionext,milbeaut-smp-sram + - stericsson,u8500-esram reg: description: diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt index b0bee7e42038..ab8b8fccc7af 100644 --- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt @@ -8,6 +8,7 @@ Required properties: * marvell,armada380-thermal * marvell,armadaxp-thermal * marvell,armada-ap806-thermal + * marvell,armada-ap807-thermal * marvell,armada-cp110-thermal Note: these bindings are deprecated for AP806/CP110 and should instead diff --git a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt deleted file mode 100644 index a3e9ec5dc7ac..000000000000 --- a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt +++ /dev/null @@ -1,41 +0,0 @@ -Binding for Thermal Sensor driver for BCM2835 SoCs. - -Required parameters: -------------------- - -compatible: should be one of: "brcm,bcm2835-thermal", - "brcm,bcm2836-thermal" or "brcm,bcm2837-thermal" -reg: Address range of the thermal registers. -clocks: Phandle of the clock used by the thermal sensor. -#thermal-sensor-cells: should be 0 (see Documentation/devicetree/bindings/thermal/thermal-sensor.yaml) - -Example: - -thermal-zones { - cpu_thermal: cpu-thermal { - polling-delay-passive = <0>; - polling-delay = <1000>; - - thermal-sensors = <&thermal>; - - trips { - cpu-crit { - temperature = <80000>; - hysteresis = <0>; - type = "critical"; - }; - }; - - coefficients = <(-538) 407000>; - - cooling-maps { - }; - }; -}; - -thermal: thermal@7e212000 { - compatible = "brcm,bcm2835-thermal"; - reg = <0x7e212000 0x8>; - clocks = <&clocks BCM2835_CLOCK_TSENS>; - #thermal-sensor-cells = <0>; -}; diff --git a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.yaml b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.yaml new file mode 100644 index 000000000000..2b6026d9fbcf --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/brcm,bcm2835-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM2835 thermal sensor + +maintainers: + - Stefan Wahren <stefan.wahren@i2se.com> + +allOf: + - $ref: thermal-sensor.yaml# + +properties: + compatible: + enum: + - brcm,bcm2835-thermal + - brcm,bcm2836-thermal + - brcm,bcm2837-thermal + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#thermal-sensor-cells": + const: 0 + +unevaluatedProperties: false + +required: + - compatible + - reg + - clocks + - '#thermal-sensor-cells' + +examples: + - | + #include <dt-bindings/clock/bcm2835.h> + + thermal@7e212000 { + compatible = "brcm,bcm2835-thermal"; + reg = <0x7e212000 0x8>; + clocks = <&clocks BCM2835_CLOCK_TSENS>; + #thermal-sensor-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml new file mode 100644 index 000000000000..7538469997f9 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/loongson,ls2k-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Thermal sensors on Loongson-2 SoCs + +maintainers: + - zhanghongchen <zhanghongchen@loongson.cn> + - Yinbo Zhu <zhuyinbo@loongson.cn> + +properties: + compatible: + oneOf: + - enum: + - loongson,ls2k1000-thermal + - items: + - enum: + - loongson,ls2k2000-thermal + - const: loongson,ls2k1000-thermal + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + thermal: thermal-sensor@1fe01500 { + compatible = "loongson,ls2k1000-thermal"; + reg = <0x1fe01500 0x30>; + interrupt-parent = <&liointc0>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + }; diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt deleted file mode 100644 index aea4a2a178b9..000000000000 --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt +++ /dev/null @@ -1,238 +0,0 @@ -Tegra124 SOCTHERM thermal management system - -The SOCTHERM IP block contains thermal sensors, support for polled -or interrupt-based thermal monitoring, CPU and GPU throttling based -on temperature trip points, and handling external overcurrent -notifications. It is also used to manage emergency shutdown in an -overheating situation. - -Required properties : -- compatible : For Tegra124, must contain "nvidia,tegra124-soctherm". - For Tegra132, must contain "nvidia,tegra132-soctherm". - For Tegra210, must contain "nvidia,tegra210-soctherm". -- reg : Should contain at least 2 entries for each entry in reg-names: - - SOCTHERM register set - - Tegra CAR register set: Required for Tegra124 and Tegra210. - - CCROC register set: Required for Tegra132. -- reg-names : Should contain at least 2 entries: - - soctherm-reg - - car-reg - - ccroc-reg -- interrupts : Defines the interrupt used by SOCTHERM -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - - tsensor - - soctherm -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - soctherm -- #thermal-sensor-cells : Should be 1. For a description of this property, see - Documentation/devicetree/bindings/thermal/thermal-sensor.yaml. - See <dt-bindings/thermal/tegra124-soctherm.h> for a list of valid values - when referring to thermal sensors. -- throttle-cfgs: A sub-node which is a container of configuration for each - hardware throttle events. These events can be set as cooling devices. - * throttle events: Sub-nodes must be named as "light" or "heavy". - Properties: - - nvidia,priority: Each throttles has its own throttle settings, so the - SW need to set priorities for various throttle, the HW arbiter can select - the final throttle settings. - Bigger value indicates higher priority, In general, higher priority - translates to lower target frequency. SW needs to ensure that critical - thermal alarms are given higher priority, and ensure that there is - no race if priority of two vectors is set to the same value. - The range of this value is 1~100. - - nvidia,cpu-throt-percent: This property is for Tegra124 and Tegra210. - It is the throttling depth of pulse skippers, it's the percentage - throttling. - - nvidia,cpu-throt-level: This property is only for Tegra132, it is the - level of pulse skippers, which used to throttle clock frequencies. It - indicates cpu clock throttling depth, and the depth can be programmed. - Must set as following values: - TEGRA_SOCTHERM_THROT_LEVEL_LOW, TEGRA_SOCTHERM_THROT_LEVEL_MED - TEGRA_SOCTHERM_THROT_LEVEL_HIGH, TEGRA_SOCTHERM_THROT_LEVEL_NONE - - nvidia,gpu-throt-level: This property is for Tegra124 and Tegra210. - It is the level of pulse skippers, which used to throttle clock - frequencies. It indicates gpu clock throttling depth and can be - programmed to any of the following values which represent a throttling - percentage: - TEGRA_SOCTHERM_THROT_LEVEL_NONE (0%) - TEGRA_SOCTHERM_THROT_LEVEL_LOW (50%), - TEGRA_SOCTHERM_THROT_LEVEL_MED (75%), - TEGRA_SOCTHERM_THROT_LEVEL_HIGH (85%). - - #cooling-cells: Should be 1. This cooling device only support on/off state. - For a description of this property see: - Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml - - Optional properties: The following properties are T210 specific and - valid only for OCx throttle events. - - nvidia,count-threshold: Specifies the number of OC events that are - required for triggering an interrupt. Interrupts are not triggered if - the property is missing. A value of 0 will interrupt on every OC alarm. - - nvidia,polarity-active-low: Configures the polarity of the OC alaram - signal. If present, this means assert low, otherwise assert high. - - nvidia,alarm-filter: Number of clocks to filter event. When the filter - expires (which means the OC event has not occurred for a long time), - the counter is cleared and filter is rearmed. Default value is 0. - - nvidia,throttle-period-us: Specifies the number of uSec for which - throttling is engaged after the OC event is deasserted. Default value - is 0. - -Optional properties: -- nvidia,thermtrips : When present, this property specifies the temperature at - which the soctherm hardware will assert the thermal trigger signal to the - Power Management IC, which can be configured to reset or shutdown the device. - It is an array of pairs where each pair represents a tsensor id followed by a - temperature in milli Celcius. In the absence of this property the critical - trip point will be used for thermtrip temperature. - -Note: -- the "critical" type trip points will be used to set the temperature at which -the SOC_THERM hardware will assert a thermal trigger if the "nvidia,thermtrips" -property is missing. When the thermtrips property is present, the breach of a -critical trip point is reported back to the thermal framework to implement -software shutdown. - -- the "hot" type trip points will be set to SOC_THERM hardware as the throttle -temperature. Once the temperature of this thermal zone is higher -than it, it will trigger the HW throttle event. - -Example : - - soctherm@700e2000 { - compatible = "nvidia,tegra124-soctherm"; - reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */ - 0x0 0x60006000 0x0 0x400 /* CAR reg_base */ - reg-names = "soctherm-reg", "car-reg"; - interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&tegra_car TEGRA124_CLK_TSENSOR>, - <&tegra_car TEGRA124_CLK_SOC_THERM>; - clock-names = "tsensor", "soctherm"; - resets = <&tegra_car 78>; - reset-names = "soctherm"; - - #thermal-sensor-cells = <1>; - - nvidia,thermtrips = <TEGRA124_SOCTHERM_SENSOR_CPU 102500 - TEGRA124_SOCTHERM_SENSOR_GPU 103000>; - - throttle-cfgs { - /* - * When the "heavy" cooling device triggered, - * the HW will skip cpu clock's pulse in 85% depth, - * skip gpu clock's pulse in 85% level - */ - throttle_heavy: heavy { - nvidia,priority = <100>; - nvidia,cpu-throt-percent = <85>; - nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>; - - #cooling-cells = <1>; - }; - - /* - * When the "light" cooling device triggered, - * the HW will skip cpu clock's pulse in 50% depth, - * skip gpu clock's pulse in 50% level - */ - throttle_light: light { - nvidia,priority = <80>; - nvidia,cpu-throt-percent = <50>; - nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_LOW>; - - #cooling-cells = <1>; - }; - - /* - * If these two devices are triggered in same time, the HW throttle - * arbiter will select the highest priority as the final throttle - * settings to skip cpu pulse. - */ - - throttle_oc1: oc1 { - nvidia,priority = <50>; - nvidia,polarity-active-low; - nvidia,count-threshold = <100>; - nvidia,alarm-filter = <5100000>; - nvidia,throttle-period-us = <0>; - nvidia,cpu-throt-percent = <75>; - nvidia,gpu-throt-level = - <TEGRA_SOCTHERM_THROT_LEVEL_MED>; - }; - }; - }; - -Example: referring to Tegra132's "reg", "reg-names" and "throttle-cfgs" : - - soctherm@700e2000 { - compatible = "nvidia,tegra132-soctherm"; - reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */ - 0x0 0x70040000 0x0 0x200>; /* CCROC reg_base */; - reg-names = "soctherm-reg", "ccroc-reg"; - - throttle-cfgs { - /* - * When the "heavy" cooling device triggered, - * the HW will skip cpu clock's pulse in HIGH level - */ - throttle_heavy: heavy { - nvidia,priority = <100>; - nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>; - - #cooling-cells = <1>; - }; - - /* - * When the "light" cooling device triggered, - * the HW will skip cpu clock's pulse in MED level - */ - throttle_light: light { - nvidia,priority = <80>; - nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_MED>; - - #cooling-cells = <1>; - }; - - /* - * If these two devices are triggered in same time, the HW throttle - * arbiter will select the highest priority as the final throttle - * settings to skip cpu pulse. - */ - - }; - }; - -Example: referring to thermal sensors : - - thermal-zones { - cpu { - polling-delay-passive = <1000>; - polling-delay = <1000>; - - thermal-sensors = - <&soctherm TEGRA124_SOCTHERM_SENSOR_CPU>; - - trips { - cpu_shutdown_trip: shutdown-trip { - temperature = <102500>; - hysteresis = <1000>; - type = "critical"; - }; - - cpu_throttle_trip: throttle-trip { - temperature = <100000>; - hysteresis = <1000>; - type = "hot"; - }; - }; - - cooling-maps { - map0 { - trip = <&cpu_throttle_trip>; - cooling-device = <&throttle_heavy 1 1>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.yaml b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.yaml new file mode 100644 index 000000000000..04a2ba1aa946 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.yaml @@ -0,0 +1,380 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/nvidia,tegra124-soctherm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra124 SOCTHERM Thermal Management System + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: The SOCTHERM IP block contains thermal sensors, support for + polled or interrupt-based thermal monitoring, CPU and GPU throttling based + on temperature trip points, and handling external overcurrent notifications. + It is also used to manage emergency shutdown in an overheating situation. + +properties: + compatible: + enum: + - nvidia,tegra124-soctherm + - nvidia,tegra132-soctherm + - nvidia,tegra210-soctherm + + reg: + maxItems: 2 + + reg-names: + maxItems: 2 + + interrupts: + items: + - description: module interrupt + - description: EDP interrupt + + interrupt-names: + items: + - const: thermal + - const: edp + + clocks: + items: + - description: thermal sensor clock + - description: module clock + + clock-names: + items: + - const: tsensor + - const: soctherm + + resets: + items: + - description: module reset + + reset-names: + items: + - const: soctherm + + "#thermal-sensor-cells": + const: 1 + + throttle-cfgs: + $ref: thermal-cooling-devices.yaml + description: A sub-node which is a container of configuration for each + hardware throttle events. These events can be set as cooling devices. + Throttle event sub-nodes must be named as "light" or "heavy". + unevaluatedProperties: false + patternProperties: + "^(light|heavy|oc1)$": + type: object + properties: + nvidia,priority: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 100 + description: Each throttles has its own throttle settings, so the + SW need to set priorities for various throttle, the HW arbiter + can select the final throttle settings. Bigger value indicates + higher priority, In general, higher priority translates to lower + target frequency. SW needs to ensure that critical thermal + alarms are given higher priority, and ensure that there is no + race if priority of two vectors is set to the same value. + + nvidia,cpu-throt-percent: + description: This property is for Tegra124 and Tegra210. It is the + throttling depth of pulse skippers, it's the percentage + throttling. + minimum: 0 + maximum: 100 + + nvidia,cpu-throt-level: + $ref: /schemas/types.yaml#/definitions/uint32 + description: This property is only for Tegra132, it is the level + of pulse skippers, which used to throttle clock frequencies. It + indicates cpu clock throttling depth, and the depth can be + programmed. + enum: + # none (TEGRA_SOCTHERM_THROT_LEVEL_NONE) + - 0 + # low (TEGRA_SOCTHERM_THROT_LEVEL_LOW) + - 1 + # medium (TEGRA_SOCTHERM_THROT_LEVEL_MED) + - 2 + # high (TEGRA_SOCTHERM_THROT_LEVEL_HIGH) + - 3 + + nvidia,gpu-throt-level: + $ref: /schemas/types.yaml#/definitions/uint32 + description: This property is for Tegra124 and Tegra210. It is the + level of pulse skippers, which used to throttle clock + frequencies. It indicates gpu clock throttling depth and can be + programmed to any of the following values which represent a + throttling percentage. + enum: + # none (0%, TEGRA_SOCTHERM_THROT_LEVEL_NONE) + - 0 + # low (50%, TEGRA_SOCTHERM_THROT_LEVEL_LOW) + - 1 + # medium (75%, TEGRA_SOCTHERM_THROT_LEVEL_MED) + - 2 + # high (85%, TEGRA_SOCTHERM_THROT_LEVEL_HIGH) + - 3 + + # optional + # Tegra210 specific and valid only for OCx throttle events + nvidia,count-threshold: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Specifies the number of OC events that are required + for triggering an interrupt. Interrupts are not triggered if the + property is missing. A value of 0 will interrupt on every OC + alarm. + + nvidia,polarity-active-low: + $ref: /schemas/types.yaml#/definitions/flag + description: Configures the polarity of the OC alaram signal. If + present, this means assert low, otherwise assert high. + + nvidia,alarm-filter: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of clocks to filter event. When the filter + expires (which means the OC event has not occurred for a long + time), the counter is cleared and filter is rearmed. + default: 0 + + nvidia,throttle-period-us: + description: Specifies the number of microseconds for which + throttling is engaged after the OC event is deasserted. + default: 0 + + # optional + nvidia,thermtrips: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + description: | + When present, this property specifies the temperature at which the + SOCTHERM hardware will assert the thermal trigger signal to the Power + Management IC, which can be configured to reset or shutdown the device. + It is an array of pairs where each pair represents a tsensor ID followed + by a temperature in milli Celcius. In the absence of this property the + critical trip point will be used for thermtrip temperature. + + Note: + - the "critical" type trip points will be used to set the temperature at + which the SOCTHERM hardware will assert a thermal trigger if the + "nvidia,thermtrips" property is missing. When the thermtrips property + is present, the breach of a critical trip point is reported back to + the thermal framework to implement software shutdown. + + - the "hot" type trip points will be set to SOCTHERM hardware as the + throttle temperature. Once the temperature of this thermal zone is + higher than it, it will trigger the HW throttle event. + items: + items: + - description: sensor ID + oneOf: + - description: CPU sensor + const: 0 + - description: MEM sensor + const: 1 + - description: GPU sensor + const: 2 + - description: PLLX sensor + const: 3 + - description: temperature threshold (in millidegree Celsius) + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - clocks + - clock-names + - resets + - reset-names + - "#thermal-sensor-cells" + +allOf: + - $ref: thermal-sensor.yaml + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra124-soctherm + - nvidia,tegra210-soctherm + then: + properties: + reg: + items: + - description: SOCTHERM register set + - description: clock and reset controller registers + + reg-names: + items: + - const: soctherm-reg + - const: car-reg + + else: + properties: + reg: + items: + - description: SOCTHERM register set + - description: CCROC registers + + reg-names: + items: + - const: soctherm-reg + - const: ccroc-reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra124-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/thermal/tegra124-soctherm.h> + + soctherm@700e2000 { + compatible = "nvidia,tegra124-soctherm"; + reg = <0x700e2000 0x600>, /* SOC_THERM reg_base */ + <0x60006000 0x400>; /* CAR reg_base */ + reg-names = "soctherm-reg", "car-reg"; + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "thermal", "edp"; + clocks = <&tegra_car TEGRA124_CLK_TSENSOR>, + <&tegra_car TEGRA124_CLK_SOC_THERM>; + clock-names = "tsensor", "soctherm"; + resets = <&tegra_car 78>; + reset-names = "soctherm"; + + #thermal-sensor-cells = <1>; + + nvidia,thermtrips = <TEGRA124_SOCTHERM_SENSOR_CPU 102500>, + <TEGRA124_SOCTHERM_SENSOR_GPU 103000>; + + throttle-cfgs { + /* + * When the "heavy" cooling device triggered, + * the HW will skip cpu clock's pulse in 85% depth, + * skip gpu clock's pulse in 85% level + */ + heavy { + nvidia,priority = <100>; + nvidia,cpu-throt-percent = <85>; + nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>; + + #cooling-cells = <2>; + }; + + /* + * When the "light" cooling device triggered, + * the HW will skip cpu clock's pulse in 50% depth, + * skip gpu clock's pulse in 50% level + */ + light { + nvidia,priority = <80>; + nvidia,cpu-throt-percent = <50>; + nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_LOW>; + + #cooling-cells = <2>; + }; + + /* + * If these two devices are triggered in same time, the HW throttle + * arbiter will select the highest priority as the final throttle + * settings to skip cpu pulse. + */ + + oc1 { + nvidia,priority = <50>; + nvidia,polarity-active-low; + nvidia,count-threshold = <100>; + nvidia,alarm-filter = <5100000>; + nvidia,throttle-period-us = <0>; + nvidia,cpu-throt-percent = <75>; + nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_MED>; + }; + }; + }; + + # referring to Tegra132's "reg", "reg-names" and "throttle-cfgs" + - | + thermal-sensor@700e2000 { + compatible = "nvidia,tegra132-soctherm"; + reg = <0x700e2000 0x600>, /* SOC_THERM reg_base */ + <0x70040000 0x200>; /* CCROC reg_base */ + reg-names = "soctherm-reg", "ccroc-reg"; + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "thermal", "edp"; + clocks = <&tegra_car TEGRA124_CLK_TSENSOR>, + <&tegra_car TEGRA124_CLK_SOC_THERM>; + clock-names = "tsensor", "soctherm"; + resets = <&tegra_car 78>; + reset-names = "soctherm"; + #thermal-sensor-cells = <1>; + + throttle-cfgs { + /* + * When the "heavy" cooling device triggered, + * the HW will skip cpu clock's pulse in HIGH level + */ + heavy { + nvidia,priority = <100>; + nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>; + + #cooling-cells = <2>; + }; + + /* + * When the "light" cooling device triggered, + * the HW will skip cpu clock's pulse in MED level + */ + light { + nvidia,priority = <80>; + nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_MED>; + + #cooling-cells = <2>; + }; + + /* + * If these two devices are triggered in same time, the HW throttle + * arbiter will select the highest priority as the final throttle + * settings to skip cpu pulse. + */ + }; + }; + + # referring to thermal sensors + - | + thermal-zones { + cpu-thermal { + polling-delay-passive = <1000>; + polling-delay = <1000>; + + thermal-sensors = <&soctherm TEGRA124_SOCTHERM_SENSOR_CPU>; + + trips { + cpu_shutdown_trip: shutdown-trip { + temperature = <102500>; + hysteresis = <1000>; + type = "critical"; + }; + + cpu_throttle_trip: throttle-trip { + temperature = <100000>; + hysteresis = <1000>; + type = "hot"; + }; + }; + + cooling-maps { + map0 { + trip = <&cpu_throttle_trip>; + cooling-device = <&throttle_heavy 1 1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml index 92762efc2120..5ff72ce5c887 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Limits Management Hardware(LMh) maintainers: - - Thara Gopinath <thara.gopinath@linaro.org> + - Thara Gopinath <thara.gopinath@gmail.com> description: Limits Management Hardware(LMh) is a hardware infrastructure on some diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index d1ec963a6834..27e9e16e6455 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -29,6 +29,8 @@ properties: items: - enum: - qcom,mdm9607-tsens + - qcom,msm8226-tsens + - qcom,msm8909-tsens - qcom,msm8916-tsens - qcom,msm8939-tsens - qcom,msm8974-tsens @@ -48,6 +50,7 @@ properties: - qcom,msm8953-tsens - qcom,msm8996-tsens - qcom,msm8998-tsens + - qcom,qcm2290-tsens - qcom,sc7180-tsens - qcom,sc7280-tsens - qcom,sc8180x-tsens @@ -56,6 +59,7 @@ properties: - qcom,sdm845-tsens - qcom,sm6115-tsens - qcom,sm6350-tsens + - qcom,sm6375-tsens - qcom,sm8150-tsens - qcom,sm8250-tsens - qcom,sm8350-tsens @@ -67,6 +71,12 @@ properties: enum: - qcom,ipq8074-tsens + - description: v2 of TSENS with combined interrupt + items: + - enum: + - qcom,ipq9574-tsens + - const: qcom,ipq8074-tsens + reg: items: - description: TM registers @@ -223,12 +233,7 @@ allOf: contains: enum: - qcom,ipq8064-tsens - - qcom,mdm9607-tsens - - qcom,msm8916-tsens - qcom,msm8960-tsens - - qcom,msm8974-tsens - - qcom,msm8976-tsens - - qcom,qcs404-tsens - qcom,tsens-v0_1 - qcom,tsens-v1 then: @@ -244,22 +249,7 @@ allOf: properties: compatible: contains: - enum: - - qcom,msm8953-tsens - - qcom,msm8996-tsens - - qcom,msm8998-tsens - - qcom,sc7180-tsens - - qcom,sc7280-tsens - - qcom,sc8180x-tsens - - qcom,sc8280xp-tsens - - qcom,sdm630-tsens - - qcom,sdm845-tsens - - qcom,sm6350-tsens - - qcom,sm8150-tsens - - qcom,sm8250-tsens - - qcom,sm8350-tsens - - qcom,sm8450-tsens - - qcom,tsens-v2 + const: qcom,tsens-v2 then: properties: interrupts: diff --git a/Documentation/devicetree/bindings/timer/brcm,kona-timer.txt b/Documentation/devicetree/bindings/timer/brcm,kona-timer.txt deleted file mode 100644 index 39adf54b4388..000000000000 --- a/Documentation/devicetree/bindings/timer/brcm,kona-timer.txt +++ /dev/null @@ -1,25 +0,0 @@ -Broadcom Kona Family timer ------------------------------------------------------ -This timer is used in the following Broadcom SoCs: - BCM11130, BCM11140, BCM11351, BCM28145, BCM28155 - -Required properties: -- compatible : "brcm,kona-timer" -- DEPRECATED: compatible : "bcm,kona-timer" -- reg : Register range for the timer -- interrupts : interrupt for the timer -- clocks: phandle + clock specifier pair of the external clock -- clock-frequency: frequency that the clock operates - -Only one of clocks or clock-frequency should be specified. - -Refer to clocks/clock-bindings.txt for generic clock consumer properties. - -Example: - timer@35006000 { - compatible = "brcm,kona-timer"; - reg = <0x35006000 0x1000>; - interrupts = <0x0 7 0x4>; - clocks = <&hub_timer_clk>; - }; - diff --git a/Documentation/devicetree/bindings/timer/brcm,kona-timer.yaml b/Documentation/devicetree/bindings/timer/brcm,kona-timer.yaml new file mode 100644 index 000000000000..d6af8383d6fc --- /dev/null +++ b/Documentation/devicetree/bindings/timer/brcm,kona-timer.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/brcm,kona-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Kona family timer + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +properties: + compatible: + const: brcm,kona-timer + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-frequency: true + +oneOf: + - required: + - clocks + - required: + - clock-frequency + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/bcm281xx.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + timer@35006000 { + compatible = "brcm,kona-timer"; + reg = <0x35006000 0x1000>; + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&aon_ccu BCM281XX_AON_CCU_HUB_TIMER>; + }; +... diff --git a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml index bc5e6f226295..dbba780c9b02 100644 --- a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml +++ b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence TTC - Triple Timer Counter maintainers: - - Michal Simek <michal.simek@xilinx.com> + - Michal Simek <michal.simek@amd.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml index 716c6afcca1f..dbe1267af06a 100644 --- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml +++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml @@ -31,9 +31,13 @@ properties: - enum: - fsl,imx6sl-gpt - fsl,imx6sx-gpt + - fsl,imx8mp-gpt - fsl,imxrt1050-gpt - fsl,imxrt1170-gpt - const: fsl,imx6dl-gpt + - items: + - const: fsl,imx6ul-gpt + - const: fsl,imx6sx-gpt reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml index 2d14610888a7..585b5f5217c4 100644 --- a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml @@ -8,7 +8,7 @@ title: Ingenic SoCs Timer/Counter Unit (TCU) description: | For a description of the TCU hardware and drivers, have a look at - Documentation/mips/ingenic-tcu.rst. + Documentation/arch/mips/ingenic-tcu.rst. maintainers: - Paul Cercueil <paul@crapouillou.net> diff --git a/Documentation/devicetree/bindings/timer/loongson,ls1x-pwmtimer.yaml b/Documentation/devicetree/bindings/timer/loongson,ls1x-pwmtimer.yaml new file mode 100644 index 000000000000..ad61ae55850b --- /dev/null +++ b/Documentation/devicetree/bindings/timer/loongson,ls1x-pwmtimer.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/loongson,ls1x-pwmtimer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson-1 PWM timer + +maintainers: + - Keguang Zhang <keguang.zhang@gmail.com> + +description: + Loongson-1 PWM timer can be used for system clock source + and clock event timers. + +properties: + compatible: + const: loongson,ls1b-pwmtimer + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/loongson,ls1x-clk.h> + #include <dt-bindings/interrupt-controller/irq.h> + clocksource: timer@1fe5c030 { + compatible = "loongson,ls1b-pwmtimer"; + reg = <0x1fe5c030 0x10>; + + clocks = <&clkc LS1X_CLKID_APB>; + interrupt-parent = <&intc0>; + interrupts = <20 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/timer/oxsemi,rps-timer.txt b/Documentation/devicetree/bindings/timer/oxsemi,rps-timer.txt deleted file mode 100644 index d191612539e8..000000000000 --- a/Documentation/devicetree/bindings/timer/oxsemi,rps-timer.txt +++ /dev/null @@ -1,17 +0,0 @@ -Oxford Semiconductor OXNAS SoCs Family RPS Timer -================================================ - -Required properties: -- compatible: Should be "oxsemi,ox810se-rps-timer" or "oxsemi,ox820-rps-timer" -- reg : Specifies base physical address and size of the registers. -- interrupts : The interrupts of the two timers -- clocks : The phandle of the timer clock source - -example: - -timer0: timer@200 { - compatible = "oxsemi,ox810se-rps-timer"; - reg = <0x200 0x40>; - clocks = <&rpsclk>; - interrupts = <4 5>; -}; diff --git a/Documentation/devicetree/bindings/timer/ralink,rt2880-timer.yaml b/Documentation/devicetree/bindings/timer/ralink,rt2880-timer.yaml new file mode 100644 index 000000000000..daa7832babe3 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/ralink,rt2880-timer.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/ralink,rt2880-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Timer present in Ralink family SoCs + +maintainers: + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +properties: + compatible: + const: ralink,rt2880-timer + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +additionalProperties: false + +examples: + - | + timer@100 { + compatible = "ralink,rt2880-timer"; + reg = <0x100 0x20>; + + clocks = <&sysc 3>; + + interrupt-parent = <&intc>; + interrupts = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml index 94bef9424df1..a0185e15a42f 100644 --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml @@ -29,14 +29,15 @@ properties: oneOf: - items: - enum: - - sifive,fu540-c000-clint - - starfive,jh7100-clint - - starfive,jh7110-clint - - canaan,k210-clint - - const: sifive,clint0 + - canaan,k210-clint # Canaan Kendryte K210 + - sifive,fu540-c000-clint # SiFive FU540 + - starfive,jh7100-clint # StarFive JH7100 + - starfive,jh7110-clint # StarFive JH7110 + - const: sifive,clint0 # SiFive CLINT v0 IP block - items: - enum: - allwinner,sun20i-d1-clint + - thead,th1520-clint - const: thead,c900-clint - items: - const: sifive,clint0 @@ -45,14 +46,9 @@ properties: description: For the QEMU virt machine only description: - Should be "<vendor>,<chip>-clint" and "sifive,clint<version>". - Supported compatible strings are - - "sifive,fu540-c000-clint" for the SiFive CLINT v0 as integrated - onto the SiFive FU540 chip, "canaan,k210-clint" for the SiFive - CLINT v0 as integrated onto the Canaan Kendryte K210 chip, and - "sifive,clint0" for the SiFive CLINT v0 IP block with no chip - integration tweaks. - Please refer to sifive-blocks-ip-versioning.txt for details + Should be "<vendor>,<chip>-clint", followed by "sifive,clint<version>" + when compatible with a SiFive CLINT. Please refer to + sifive-blocks-ip-versioning.txt for details regarding the latter. reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/timer/snps,arc-timer.txt b/Documentation/devicetree/bindings/timer/snps,arc-timer.txt index 147ef3e74452..b02ab0af10ce 100644 --- a/Documentation/devicetree/bindings/timer/snps,arc-timer.txt +++ b/Documentation/devicetree/bindings/timer/snps,arc-timer.txt @@ -1,7 +1,7 @@ Synopsys ARC Local Timer with Interrupt Capabilities - Found on all ARC CPUs (ARC700/ARCHS) - Can be optionally programmed to interrupt on Limit -- Two idential copies TIMER0 and TIMER1 exist in ARC cores and historically +- Two identical copies TIMER0 and TIMER1 exist in ARC cores and historically TIMER0 used as clockevent provider (true for all ARC cores) TIMER1 used for clocksource (mandatory for ARC700, optional for ARC HS) diff --git a/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml b/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml index fd6a7b51f571..95f42acd0c54 100644 --- a/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml +++ b/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml @@ -17,7 +17,7 @@ description: properties: $nodename: - pattern: "^timestamp(@.*|-[0-9a-f])?$" + pattern: "^timestamp(@.*|-([0-9]|[1-9][0-9]+))?$" "#timestamp-cells": description: diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 246863a9bc7e..cd58179ae337 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -119,6 +119,10 @@ properties: - fsl,mpr121 # Monolithic Power Systems Inc. multi-phase controller mp2888 - mps,mp2888 + # Monolithic Power Systems Inc. multi-phase controller mp2971 + - mps,mp2971 + # Monolithic Power Systems Inc. multi-phase controller mp2973 + - mps,mp2973 # Monolithic Power Systems Inc. multi-phase controller mp2975 - mps,mp2975 # Honeywell Humidicon HIH-6130 humidity/temperature sensor @@ -139,6 +143,8 @@ properties: - infineon,ir38164 # Infineon IR38263 Voltage Regulator - infineon,ir38263 + # Infineon IRPS5401 Voltage Regulator (PMIC) + - infineon,irps5401 # Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) - infineon,slb9635tt # Infineon SLB9645 I2C TPM (new protocol, max 400khz) @@ -191,13 +197,13 @@ properties: - maxim,max1237 # Temperature Sensor, I2C interface - maxim,max1619 - # 10-bit 10 kOhm linear programable voltage divider + # 10-bit 10 kOhm linear programmable voltage divider - maxim,max5481 - # 10-bit 50 kOhm linear programable voltage divider + # 10-bit 50 kOhm linear programmable voltage divider - maxim,max5482 - # 10-bit 10 kOhm linear programable variable resistor + # 10-bit 10 kOhm linear programmable variable resistor - maxim,max5483 - # 10-bit 50 kOhm linear programable variable resistor + # 10-bit 50 kOhm linear programmable variable resistor - maxim,max5484 # PECI-to-I2C translator for PECI-to-SMBus/I2C protocol conversion - maxim,max6621 @@ -289,8 +295,6 @@ properties: - miramems,da311 # Temperature sensor with integrated fan control - national,lm63 - # I2C TEMP SENSOR - - national,lm75 # Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor - national,lm80 # Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor @@ -313,6 +317,8 @@ properties: - plx,pex8648 # Pulsedlight LIDAR range-finding sensor - pulsedlight,lidar-lite-v2 + # Renesas HS3001 Temperature and Relative Humidity Sensors + - renesas,hs3001 # Renesas ISL29501 time-of-flight sensor - renesas,isl29501 # Rohm DH2228FV diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml index c5a06c048389..462ead5a1cec 100644 --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml @@ -26,8 +26,10 @@ properties: - qcom,msm8994-ufshc - qcom,msm8996-ufshc - qcom,msm8998-ufshc + - qcom,sa8775p-ufshc - qcom,sc8280xp-ufshc - qcom,sdm845-ufshc + - qcom,sm6115-ufshc - qcom,sm6350-ufshc - qcom,sm8150-ufshc - qcom,sm8250-ufshc @@ -70,10 +72,19 @@ properties: power-domains: maxItems: 1 + qcom,ice: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the Inline Crypto Engine node + reg: minItems: 1 maxItems: 2 + reg-names: + items: + - const: std + - const: ice + required-opps: maxItems: 1 @@ -105,6 +116,7 @@ allOf: contains: enum: - qcom,msm8998-ufshc + - qcom,sa8775p-ufshc - qcom,sc8280xp-ufshc - qcom,sm8250-ufshc - qcom,sm8350-ufshc @@ -128,6 +140,8 @@ allOf: reg: minItems: 1 maxItems: 1 + reg-names: + maxItems: 1 - if: properties: @@ -156,6 +170,10 @@ allOf: reg: minItems: 2 maxItems: 2 + reg-names: + minItems: 2 + required: + - reg-names - if: properties: @@ -184,9 +202,59 @@ allOf: reg: minItems: 1 maxItems: 1 + reg-names: + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm6115-ufshc + then: + properties: + clocks: + minItems: 8 + maxItems: 8 + clock-names: + items: + - const: core_clk + - const: bus_aggr_clk + - const: iface_clk + - const: core_clk_unipro + - const: ref_clk + - const: tx_lane0_sync_clk + - const: rx_lane0_sync_clk + - const: ice_core_clk + reg: + minItems: 2 + maxItems: 2 + reg-names: + minItems: 2 + required: + - reg-names # TODO: define clock bindings for qcom,msm8994-ufshc + - if: + required: + - qcom,ice + then: + properties: + reg: + maxItems: 1 + clocks: + minItems: 8 + maxItems: 8 + else: + properties: + reg: + minItems: 1 + maxItems: 2 + clocks: + minItems: 8 + maxItems: 11 + unevaluatedProperties: false examples: @@ -249,5 +317,6 @@ examples: <0 0>, <0 0>, <0 0>; + qcom,ice = <&ice>; }; }; diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml index a9988798898d..88cc1e3a0c88 100644 --- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml @@ -54,7 +54,7 @@ properties: const: ufs-phy samsung,sysreg: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array description: Should be phandle/offset pair. The phandle to the syscon node which indicates the FSYSx sysreg interface and the offset of the control register for UFS io coherency setting. diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml index 47a4e9e1a775..bbaee4f5f7b2 100644 --- a/Documentation/devicetree/bindings/ufs/ufs-common.yaml +++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml @@ -74,7 +74,7 @@ properties: Specifies max. load that can be drawn from VCCQ2 supply. dependencies: - freq-table-hz: [ 'clocks' ] + freq-table-hz: [ clocks ] required: - interrupts diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml index b26d26c2b023..1394557517b1 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml @@ -34,6 +34,7 @@ properties: - fsl,imx23-usb - fsl,imx25-usb - fsl,imx28-usb + - fsl,imx35-usb - fsl,imx50-usb - fsl,imx51-usb - fsl,imx53-usb @@ -45,7 +46,9 @@ properties: - fsl,vf610-usb - const: fsl,imx27-usb - items: - - const: fsl,imx8dxl-usb + - enum: + - fsl,imx8dxl-usb + - fsl,imx8ulp-usb - const: fsl,imx7ulp-usb - const: fsl,imx6ul-usb - items: @@ -74,11 +77,11 @@ properties: clocks: minItems: 1 - maxItems: 2 + maxItems: 3 clock-names: minItems: 1 - maxItems: 2 + maxItems: 3 dr_mode: true @@ -165,7 +168,7 @@ properties: at RTL is 0, so this property only affects siTD. If this property is not set, the max packet size is 1023 bytes, and - if the total of packet size for pervious transactions are more than + if the total of packet size for previous transactions are more than 256 bytes, it can't accept any transactions within this frame. The use case is single transaction, but higher frame rate. @@ -290,6 +293,18 @@ properties: minimum: 0x0 maximum: 0xf + fsl,picophy-rise-fall-time-adjust: + description: + HS Transmitter Rise/Fall Time Adjustment. Adjust the rise/fall times + of the high-speed transmitter waveform. It has no unit. The rise/fall + time will be increased or decreased by a certain percentage relative + to design default time. (0:-10%; 1:design default; 2:+15%; 3:+20%) + Details can refer to TXRISETUNE0 bit of USBNC_n_PHY_CFG1. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + default: 1 + usb-phy: description: phandle for the PHY device. Use "phys" instead. $ref: /schemas/types.yaml#/definitions/phandle diff --git a/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml b/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml index 75eec4a9a020..89fc9a434d05 100644 --- a/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml +++ b/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml @@ -43,10 +43,8 @@ properties: patternProperties: '^connector@[01]$': $ref: /schemas/connector/usb-connector.yaml# - unevaluatedProperties: false - properties: - reg: - maxItems: 1 + required: + - reg required: - compatible diff --git a/Documentation/devicetree/bindings/usb/cypress,hx3.yaml b/Documentation/devicetree/bindings/usb/cypress,hx3.yaml new file mode 100644 index 000000000000..47add0d85fb8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/cypress,hx3.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/cypress,hx3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cypress HX3 USB 3.0 hub controller family + +maintainers: + - Benjamin Bara <benjamin.bara@skidata.com> + +allOf: + - $ref: usb-device.yaml# + +properties: + compatible: + enum: + - usb4b4,6504 + - usb4b4,6506 + + reg: true + + reset-gpios: + items: + - description: GPIO specifier for RESETN pin. + + vdd-supply: + description: + 1V2 power supply (VDD_EFUSE, AVDD12, DVDD12). + + vdd2-supply: + description: + 3V3 power supply (AVDD33, VDD_IO). + + peer-hub: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to the peer hub on the controller. + +required: + - compatible + - reg + - peer-hub + - vdd-supply + - vdd2-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + usb { + dr_mode = "host"; + #address-cells = <1>; + #size-cells = <0>; + + /* 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>; + }; + + /* 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>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index d3506090f8b1..0a5c98ea711d 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -53,6 +53,7 @@ properties: - amlogic,meson8b-usb - amlogic,meson-gxbb-usb - amlogic,meson-g12a-usb + - amlogic,meson-a1-usb - intel,socfpga-agilex-hsotg - const: snps,dwc2 - const: amcc,dwc-otg diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml index 098b73134a1b..bb373eb025a5 100644 --- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml +++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx SuperSpeed DWC3 USB SoC controller maintainers: - - Manish Narani <manish.narani@xilinx.com> + - Piyush Mehta <piyush.mehta@amd.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml index 3fb4feb6d3d9..9ea1e4cd0709 100644 --- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml @@ -52,7 +52,7 @@ properties: fsl,permanently-attached: type: boolean description: - Indicates if the device atached to a downstream port is + Indicates if the device attached to a downstream port is permanently attached. fsl,disable-port-power-control: diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8qm-cdns3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8qm-cdns3.yaml new file mode 100644 index 000000000000..ceb76394af60 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/fsl,imx8qm-cdns3.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 NXP +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/fsl,imx8qm-cdns3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP iMX8QM Soc USB Controller + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +properties: + compatible: + const: fsl,imx8qm-usb3 + + reg: + items: + - description: Register set for iMX USB3 Platform Control + + "#address-cells": + enum: [ 1, 2 ] + + "#size-cells": + enum: [ 1, 2 ] + + ranges: true + + clocks: + items: + - description: Standby clock. Used during ultra low power states. + - description: USB bus clock for usb3 controller. + - description: AXI clock for AXI interface. + - description: ipg clock for register access. + - description: Core clock for usb3 controller. + + clock-names: + items: + - const: lpm + - const: bus + - const: aclk + - const: ipg + - const: core + + power-domains: + maxItems: 1 + +# Required child node: + +patternProperties: + "^usb@[0-9a-f]+$": + $ref: cdns,usb3.yaml# + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - ranges + - clocks + - clock-names + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8-lpcg.h> + #include <dt-bindings/firmware/imx/rsrc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + usb@5b110000 { + compatible = "fsl,imx8qm-usb3"; + reg = <0x5b110000 0x10000>; + ranges; + clocks = <&usb3_lpcg IMX_LPCG_CLK_1>, + <&usb3_lpcg IMX_LPCG_CLK_0>, + <&usb3_lpcg IMX_LPCG_CLK_7>, + <&usb3_lpcg IMX_LPCG_CLK_4>, + <&usb3_lpcg IMX_LPCG_CLK_5>; + clock-names = "lpm", "bus", "aclk", "ipg", "core"; + assigned-clocks = <&clk IMX_SC_R_USB_2 IMX_SC_PM_CLK_MST_BUS>; + assigned-clock-rates = <250000000>; + power-domains = <&pd IMX_SC_R_USB_2>; + #address-cells = <1>; + #size-cells = <1>; + + usb@5b120000 { + compatible = "cdns,usb3"; + reg = <0x5b120000 0x10000>, /* memory area for OTG/DRD registers */ + <0x5b130000 0x10000>, /* memory area for HOST registers */ + <0x5b140000 0x10000>; /* memory area for DEVICE registers */ + reg-names = "otg", "xhci", "dev"; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "host", "peripheral", "otg", "wakeup"; + phys = <&usb3_phy>; + phy-names = "cdns3,usb3-phy"; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml index 9445764bd8de..87986c45be88 100644 --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml @@ -38,6 +38,7 @@ properties: - allwinner,sun8i-a83t-ehci - allwinner,sun8i-h3-ehci - allwinner,sun8i-r40-ehci + - allwinner,sun8i-v3s-ehci - allwinner,sun9i-a80-ehci - allwinner,sun20i-d1-ehci - aspeed,ast2400-ehci @@ -61,11 +62,13 @@ properties: - ibm,476gtr-ehci - nxp,lpc1850-ehci - qca,ar7100-ehci + - rockchip,rk3588-ehci - snps,hsdk-v1.0-ehci - socionext,uniphier-ehci - const: generic-ehci - items: - enum: + - atmel,at91sam9g45-ehci - cavium,octeon-6335-ehci - ibm,usb-ehci-440epx - ibm,usb-ehci-460ex diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml index d06d1e7d8876..b9576015736b 100644 --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml @@ -25,6 +25,7 @@ properties: - allwinner,sun8i-a83t-ohci - allwinner,sun8i-h3-ohci - allwinner,sun8i-r40-ohci + - allwinner,sun8i-v3s-ohci - allwinner,sun9i-a80-ohci - allwinner,sun20i-d1-ohci - brcm,bcm3384-ohci @@ -44,6 +45,7 @@ properties: - hpe,gxp-ohci - ibm,476gtr-ohci - ingenic,jz4740-ohci + - rockchip,rk3588-ohci - snps,hsdk-v1.0-ohci - const: generic-ohci - enum: @@ -69,7 +71,7 @@ properties: clocks: minItems: 1 - maxItems: 3 + maxItems: 4 description: | In case the Renesas R-Car Gen3 SoCs: - if a host only channel: first clock should be host. @@ -147,6 +149,20 @@ allOf: then: properties: transceiver: false + - if: + properties: + compatible: + contains: + const: rockchip,rk3588-ohci + then: + properties: + clocks: + minItems: 4 + else: + properties: + clocks: + minItems: 1 + maxItems: 3 unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml b/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml index cc4cf92b70d1..d0927f6768a4 100644 --- a/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml +++ b/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/usb/genesys,gl850g.yaml# @@ -17,6 +17,7 @@ properties: enum: - usb5e3,608 - usb5e3,610 + - usb5e3,620 reg: true diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index 478214ab045e..a59d91243ac8 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -304,7 +304,7 @@ examples: # Dual role switch with type-c - | usb@11201000 { - compatible ="mediatek,mt8183-mtu3", "mediatek,mtu3"; + compatible = "mediatek,mt8183-mtu3", "mediatek,mtu3"; reg = <0x11201000 0x2e00>, <0x11203e00 0x0100>; reg-names = "mac", "ippc"; interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>; diff --git a/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml new file mode 100644 index 000000000000..ff3a1707ef57 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml @@ -0,0 +1,107 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/microchip,usb5744.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip USB5744 4-port Hub Controller + +description: + Microchip's USB5744 SmartHubTM IC is a 4 port, SuperSpeed (SS)/Hi-Speed (HS), + low power, low pin count configurable and fully compliant with the USB 3.1 + Gen 1 specification. The USB5744 also supports Full Speed (FS) and Low Speed + (LS) USB signaling, offering complete coverage of all defined USB operating + speeds. The new SuperSpeed hubs operate in parallel with the USB 2.0 + controller, so 5 Gbps SuperSpeed data transfers are not affected by slower + USB 2.0 traffic. + +maintainers: + - Piyush Mehta <piyush.mehta@amd.com> + - Michal Simek <michal.simek@amd.com> + +properties: + compatible: + enum: + - usb424,2744 + - usb424,5744 + - microchip,usb5744 + + reg: + maxItems: 1 + + reset-gpios: + maxItems: 1 + description: + GPIO controlling the GRST# pin. + + vdd-supply: + description: + VDD power supply to the hub + + peer-hub: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to the peer hub on the controller. + + i2c-bus: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle of an usb hub connected via i2c bus. + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: microchip,usb5744 + then: + properties: + reset-gpios: false + vdd-supply: false + peer-hub: false + i2c-bus: false + else: + $ref: /schemas/usb/usb-device.yaml + required: + - peer-hub + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c: i2c { + #address-cells = <1>; + #size-cells = <0>; + hub: usb-hub@2d { + compatible = "microchip,usb5744"; + reg = <0x2d>; + }; + }; + + usb { + #address-cells = <1>; + #size-cells = <0>; + + /* 2.0 hub on port 1 */ + hub_2_0: hub@1 { + compatible = "usb424,2744"; + reg = <1>; + peer-hub = <&hub_3_0>; + i2c-bus = <&hub>; + reset-gpios = <&gpio 3 GPIO_ACTIVE_LOW>; + }; + + /* 3.0 hub on port 2 */ + hub_3_0: hub@2 { + compatible = "usb424,5744"; + reg = <2>; + peer-hub = <&hub_2_0>; + i2c-bus = <&hub>; + reset-gpios = <&gpio 3 GPIO_ACTIVE_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt index 8654a3ec23e4..afc30e98b123 100644 --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt @@ -53,7 +53,7 @@ Optional properties: - dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg" - switch-gpio: A phandle + gpio-specifier pair. Some boards are using Dual - SPDT USB Switch, witch is cotrolled by GPIO to de/multiplex + SPDT USB Switch, witch is controlled by GPIO to de/multiplex D+/D- USB lines between connectors. - qcom,phy-init-sequence: PHY configuration sequence values. This is related to Device diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml index e2270ce0c56b..c6e661e8915c 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml @@ -91,6 +91,7 @@ properties: phys: minItems: 1 + maxItems: 2 description: Must contain an entry for each entry in phy-names. See ../phy/phy-bindings.txt for details. @@ -99,13 +100,7 @@ properties: minItems: 1 items: - const: usb2-0 - - const: usb2-1 - - const: usb2-2 - - const: usb2-3 - const: usb3-0 - - const: usb3-1 - - const: usb3-2 - - const: usb3-3 avddio-usb-supply: description: PCIe/USB3 analog logic power supply. Must supply 1.05 V. diff --git a/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml b/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml new file mode 100644 index 000000000000..c0201da002f6 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml @@ -0,0 +1,141 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/onnn,nb7vpq904m.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ON Semiconductor Type-C DisplayPort ALT Mode Linear Redriver + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +properties: + compatible: + enum: + - onnn,nb7vpq904m + + reg: + maxItems: 1 + + vcc-supply: + description: power supply (1.8V) + + enable-gpios: true + + retimer-switch: + description: Flag the port as possible handle of SuperSpeed signals retiming + type: boolean + + orientation-switch: + description: Flag the port as possible handler of orientation switching + type: boolean + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Super Speed (SS) Output endpoint to the Type-C connector + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + description: Super Speed (SS) Input endpoint from the Super-Speed PHY + unevaluatedProperties: false + + properties: + endpoint: + $ref: /schemas/graph.yaml#/$defs/endpoint-base + unevaluatedProperties: false + + properties: + data-lanes: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + An array of physical data lane indexes. Position determines how + lanes are connected to the redriver, It is assumed the same order + is kept on the other side of the redriver. + Lane number represents the following + - 0 is RX2 lane + - 1 is TX2 lane + - 2 is TX1 lane + - 3 is RX1 lane + The position determines the physical port of the redriver, in the + order A, B, C & D. + oneOf: + - items: + - const: 0 + - const: 1 + - const: 2 + - const: 3 + description: | + This is the lanes default layout + - Port A to RX2 lane + - Port B to TX2 lane + - Port C to TX1 lane + - Port D to RX1 lane + - items: + - const: 3 + - const: 2 + - const: 1 + - const: 0 + description: | + This is the USBRX2/USBTX2 and USBRX1/USBTX1 swapped lanes layout + - Port A to RX1 lane + - Port B to TX1 lane + - Port C to TX2 lane + - Port D to RX2 lane + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: + Sideband Use (SBU) AUX lines endpoint to the Type-C connector for the purpose of + handling altmode muxing and orientation switching. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + typec-mux@32 { + compatible = "onnn,nb7vpq904m"; + reg = <0x32>; + + vcc-supply = <&vreg_l15b_1p8>; + + retimer-switch; + orientation-switch; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + usb_con_ss: endpoint { + remote-endpoint = <&typec_con_ss>; + }; + }; + port@1 { + reg = <1>; + phy_con_ss: endpoint { + remote-endpoint = <&usb_phy_ss>; + data-lanes = <3 2 1 0>; + }; + }; + port@2 { + reg = <2>; + usb_con_sbu: endpoint { + remote-endpoint = <&typec_dp_aux>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index d84281926f10..67591057f234 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -14,15 +14,18 @@ properties: items: - enum: - qcom,ipq4019-dwc3 + - qcom,ipq5332-dwc3 - qcom,ipq6018-dwc3 - qcom,ipq8064-dwc3 - qcom,ipq8074-dwc3 + - qcom,ipq9574-dwc3 - qcom,msm8953-dwc3 - qcom,msm8994-dwc3 - qcom,msm8996-dwc3 - qcom,msm8998-dwc3 - qcom,qcm2290-dwc3 - qcom,qcs404-dwc3 + - qcom,sa8775p-dwc3 - qcom,sc7180-dwc3 - qcom,sc7280-dwc3 - qcom,sc8280xp-dwc3 @@ -80,15 +83,6 @@ properties: minItems: 1 maxItems: 9 - assigned-clocks: - items: - - description: Phandle and clock specifier of MOCK_UTMI_CLK. - - description: Phandle and clock specifoer of MASTER_CLK. - - assigned-clock-rates: - items: - - description: Must be 19.2MHz (19200000). - - description: Must be >= 60 MHz in HS mode, >= 125 MHz in SS mode. resets: maxItems: 1 @@ -133,7 +127,6 @@ required: - "#address-cells" - "#size-cells" - ranges - - power-domains - clocks - clock-names - interrupts @@ -177,9 +170,11 @@ allOf: compatible: contains: enum: + - qcom,ipq9574-dwc3 - qcom,msm8953-dwc3 - qcom,msm8996-dwc3 - qcom,msm8998-dwc3 + - qcom,sa8775p-dwc3 - qcom,sc7180-dwc3 - qcom,sc7280-dwc3 - qcom,sdm670-dwc3 @@ -243,6 +238,7 @@ allOf: compatible: contains: enum: + - qcom,ipq5332-dwc3 - qcom,msm8994-dwc3 - qcom,qcs404-dwc3 then: @@ -287,15 +283,23 @@ allOf: then: properties: clocks: - minItems: 6 + minItems: 5 + maxItems: 6 clock-names: - items: - - const: cfg_noc - - const: core - - const: iface - - const: sleep - - const: mock_utmi - - const: bus + oneOf: + - items: + - const: cfg_noc + - const: core + - const: iface + - const: sleep + - const: mock_utmi + - const: bus + - items: + - const: cfg_noc + - const: core + - const: sleep + - const: mock_utmi + - const: bus - if: properties: @@ -407,6 +411,7 @@ allOf: compatible: contains: enum: + - qcom,ipq5332-dwc3 - qcom,sdm660-dwc3 then: properties: @@ -455,6 +460,25 @@ allOf: - const: dm_hs_phy_irq - const: ss_phy_irq + - if: + properties: + compatible: + contains: + enum: + - qcom,sa8775p-dwc3 + then: + properties: + interrupts: + minItems: 3 + maxItems: 4 + interrupt-names: + minItems: 3 + items: + - const: pwr_event + - const: dp_hs_phy_irq + - const: dm_hs_phy_irq + - const: ss_phy_irq + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml new file mode 100644 index 000000000000..55df3129a0bc --- /dev/null +++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml @@ -0,0 +1,190 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm PMIC based USB Type-C block + +maintainers: + - Bryan O'Donoghue <bryan.odonoghue@linaro.org> + +description: + Qualcomm PMIC Type-C block + +properties: + compatible: + enum: + - qcom,pm8150b-typec + + connector: + type: object + $ref: /schemas/connector/usb-connector.yaml# + unevaluatedProperties: false + + reg: + description: Type-C port and pdphy SPMI register base offsets + maxItems: 2 + + interrupts: + items: + - description: Type-C CC attach notification, VBUS error, tCCDebounce done + - description: Type-C VCONN powered + - description: Type-C CC state change + - description: Type-C VCONN over-current + - description: Type-C VBUS state change + - description: Type-C Attach/detach notification + - description: Type-C Legacy cable detect + - description: Type-C Try.Src Try.Snk state change + - description: Power Domain Signal TX - HardReset or CableReset signal TX + - description: Power Domain Signal RX - HardReset or CableReset signal RX + - description: Power Domain TX complete + - description: Power Domain RX complete + - description: Power Domain TX fail + - description: Power Domain TX message discard + - description: Power Domain RX message discard + - description: Power Domain Fast Role Swap event + + interrupt-names: + items: + - const: or-rid-detect-change + - const: vpd-detect + - const: cc-state-change + - const: vconn-oc + - const: vbus-change + - const: attach-detach + - const: legacy-cable-detect + - const: try-snk-src-detect + - const: sig-tx + - const: sig-rx + - const: msg-tx + - const: msg-rx + - const: msg-tx-failed + - const: msg-tx-discarded + - const: msg-rx-discarded + - const: fr-swap + + vdd-vbus-supply: + description: VBUS power supply. + + vdd-pdphy-supply: + description: VDD regulator supply to the PDPHY. + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + Contains a port which produces data-role switching messages. + +required: + - compatible + - reg + - interrupts + - interrupt-names + - vdd-vbus-supply + - vdd-pdphy-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/usb/pd.h> + + pmic { + #address-cells = <1>; + #size-cells = <0>; + + pm8150b_typec: typec@1500 { + compatible = "qcom,pm8150b-typec"; + reg = <0x1500>, + <0x1700>; + + interrupts = <0x2 0x15 0x00 IRQ_TYPE_EDGE_RISING>, + <0x2 0x15 0x01 IRQ_TYPE_EDGE_BOTH>, + <0x2 0x15 0x02 IRQ_TYPE_EDGE_RISING>, + <0x2 0x15 0x03 IRQ_TYPE_EDGE_BOTH>, + <0x2 0x15 0x04 IRQ_TYPE_EDGE_RISING>, + <0x2 0x15 0x05 IRQ_TYPE_EDGE_RISING>, + <0x2 0x15 0x06 IRQ_TYPE_EDGE_BOTH>, + <0x2 0x15 0x07 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x00 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x01 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x02 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x03 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x04 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x05 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x06 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x07 IRQ_TYPE_EDGE_RISING>; + + interrupt-names = "or-rid-detect-change", + "vpd-detect", + "cc-state-change", + "vconn-oc", + "vbus-change", + "attach-detach", + "legacy-cable-detect", + "try-snk-src-detect", + "sig-tx", + "sig-rx", + "msg-tx", + "msg-rx", + "msg-tx-failed", + "msg-tx-discarded", + "msg-rx-discarded", + "fr-swap"; + + vdd-vbus-supply = <&pm8150b_vbus>; + vdd-pdphy-supply = <&vreg_l2a_3p1>; + + connector { + compatible = "usb-c-connector"; + + power-role = "source"; + data-role = "dual"; + self-powered; + + source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_DUAL_ROLE | + PDO_FIXED_USB_COMM | PDO_FIXED_DATA_SWAP)>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + pmic_typec_mux_out: endpoint { + remote-endpoint = <&usb_phy_typec_mux_in>; + }; + }; + + port@1 { + reg = <1>; + pmic_typec_role_switch_out: endpoint { + remote-endpoint = <&usb_role_switch_in>; + }; + }; + }; + }; + }; + }; + + usb { + dr_mode = "otg"; + usb-role-switch; + port { + usb_role_switch_in: endpoint { + remote-endpoint = <&pmic_typec_role_switch_out>; + }; + }; + }; + + usb-phy { + orientation-switch; + port { + usb_phy_typec_mux_in: endpoint { + remote-endpoint = <&pmic_typec_mux_out>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml index 9309f003cd07..f0784d2e86da 100644 --- a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml +++ b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/usb/realtek,rts5411.yaml# diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml index 4ced2f68e2a9..07bec1fe6ebf 100644 --- a/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml +++ b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml @@ -10,7 +10,7 @@ maintainers: - ChiYuan Huang <cy_huang@richtek.com> description: | - The RT1719 is a sink-only USB Type-C contoller that complies with the latest + The RT1719 is a sink-only USB Type-C controller that complies with the latest USB Type-C and PD standards. It does the USB Type-C detection including attach and orientation. It integrates the physical layer of the USB BMC power delivery protocol to allow up to 100W of power. The BMC PD block enables full diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml index 42ceaf13cd5d..1ade99e85ba8 100644 --- a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml @@ -15,6 +15,7 @@ properties: - samsung,exynos5250-dwusb3 - samsung,exynos5433-dwusb3 - samsung,exynos7-dwusb3 + - samsung,exynos850-dwusb3 '#address-cells': const: 1 @@ -72,7 +73,7 @@ allOf: properties: compatible: contains: - const: samsung,exynos54333-dwusb3 + const: samsung,exynos5433-dwusb3 then: properties: clocks: @@ -82,8 +83,8 @@ allOf: items: - const: aclk - const: susp_clk - - const: pipe_pclk - const: phyclk + - const: pipe_pclk - if: properties: @@ -101,6 +102,21 @@ allOf: - const: usbdrd30_susp_clk - const: usbdrd30_axius_clk + - if: + properties: + compatible: + contains: + const: samsung,exynos850-dwusb3 + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: bus_early + - const: ref + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt b/Documentation/devicetree/bindings/usb/samsung-hsotg.txt deleted file mode 100644 index 0388634598ce..000000000000 --- a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt +++ /dev/null @@ -1,38 +0,0 @@ -Samsung High Speed USB OTG controller ------------------------------ - -The Samsung HSOTG IP can be found on Samsung SoCs, from S3C6400 onwards. -It gives functionality of OTG-compliant USB 2.0 host and device with -support for USB 2.0 high-speed (480Mbps) and full-speed (12 Mbps) -operation. - -Currently only device mode is supported. - -Binding details ------ - -Required properties: -- compatible: "samsung,s3c6400-hsotg" should be used for all currently - supported SoC, -- interrupts: specifier of interrupt signal of interrupt controller, - according to bindings of interrupt controller, -- clocks: contains an array of clock specifiers: - - first entry: OTG clock -- clock-names: contains array of clock names: - - first entry: must be "otg" -- vusb_d-supply: phandle to voltage regulator of digital section, -- vusb_a-supply: phandle to voltage regulator of analog section. - -Example ------ - - hsotg@12480000 { - compatible = "samsung,s3c6400-hsotg"; - reg = <0x12480000 0x20000>; - interrupts = <0 71 0>; - clocks = <&clock 305>; - clock-names = "otg"; - vusb_d-supply = <&vusb_reg>; - vusb_a-supply = <&vusbdac_reg>; - }; - diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 4f7625955ccc..a696f23730d3 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -44,15 +44,15 @@ properties: It's either a single common DWC3 interrupt (dwc_usb3) or individual interrupts for the host, gadget and DRD modes. minItems: 1 - maxItems: 3 + maxItems: 4 interrupt-names: minItems: 1 - maxItems: 3 + maxItems: 4 oneOf: - const: dwc_usb3 - items: - enum: [host, peripheral, otg] + enum: [host, peripheral, otg, wakeup] clocks: description: diff --git a/Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml b/Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml new file mode 100644 index 000000000000..24aa9c10d6ab --- /dev/null +++ b/Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/starfive,jh7110-usb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 wrapper module for the Cadence USBSS-DRD controller + +maintainers: + - Minda Chen <minda.chen@starfivetech.com> + +properties: + compatible: + const: starfive,jh7110-usb + + ranges: true + + starfive,stg-syscon: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to System Register Controller stg_syscon node. + - description: dr mode register offset of STG_SYSCONSAIF__SYSCFG register for USB. + description: + The phandle to System Register Controller syscon node and the offset + of STG_SYSCONSAIF__SYSCFG register for USB. + + dr_mode: + enum: [host, otg, peripheral] + + "#address-cells": + enum: [1, 2] + + "#size-cells": + enum: [1, 2] + + clocks: + items: + - description: link power management clock + - description: standby clock + - description: APB clock + - description: AXI clock + - description: UTMI APB clock + + clock-names: + items: + - const: lpm + - const: stb + - const: apb + - const: axi + - const: utmi_apb + + resets: + items: + - description: Power up reset + - description: APB clock reset + - description: AXI clock reset + - description: UTMI APB clock reset + + reset-names: + items: + - const: pwrup + - const: apb + - const: axi + - const: utmi_apb + +patternProperties: + "^usb@[0-9a-f]+$": + $ref: cdns,usb3.yaml# + description: Required child node + +required: + - compatible + - ranges + - starfive,stg-syscon + - '#address-cells' + - '#size-cells' + - dr_mode + - clocks + - resets + +additionalProperties: false + +examples: + - | + usb@10100000 { + compatible = "starfive,jh7110-usb"; + ranges = <0x0 0x10100000 0x100000>; + #address-cells = <1>; + #size-cells = <1>; + starfive,stg-syscon = <&stg_syscon 0x4>; + clocks = <&syscrg 4>, + <&stgcrg 5>, + <&stgcrg 1>, + <&stgcrg 3>, + <&stgcrg 2>; + clock-names = "lpm", "stb", "apb", "axi", "utmi_apb"; + resets = <&stgcrg 10>, + <&stgcrg 8>, + <&stgcrg 7>, + <&stgcrg 9>; + reset-names = "pwrup", "apb", "axi", "utmi_apb"; + dr_mode = "host"; + + usb@0 { + compatible = "cdns,usb3"; + reg = <0x0 0x10000>, + <0x10000 0x10000>, + <0x20000 0x10000>; + reg-names = "otg", "xhci", "dev"; + interrupts = <100>, <108>, <110>; + interrupt-names = "host", "peripheral", "otg"; + maximum-speed = "super-speed"; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml index d25fc708e32c..fec5651f5602 100644 --- a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml @@ -92,7 +92,7 @@ examples: usb@31100000 { compatible = "snps,dwc3"; - reg =<0x00 0x31100000 0x00 0x50000>; + reg = <0x00 0x31100000 0x00 0x50000>; interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>, /* irq.0 */ <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>; /* irq.0 */ interrupt-names = "host", "peripheral"; diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml index 88ea6c952c66..c2e29bd61e11 100644 --- a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml +++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/usb/ti,usb8041.yaml# diff --git a/Documentation/devicetree/bindings/usb/usb251xb.yaml b/Documentation/devicetree/bindings/usb/usb251xb.yaml index 4d1530816817..ac5b99710332 100644 --- a/Documentation/devicetree/bindings/usb/usb251xb.yaml +++ b/Documentation/devicetree/bindings/usb/usb251xb.yaml @@ -231,7 +231,7 @@ properties: power-on sequence to a port until the port has adequate power. swap-dx-lanes: - $ref: /schemas/types.yaml#/definitions/uint8-array + $ref: /schemas/types.yaml#/definitions/uint32-array description: | Specifies the ports which will swap the differential-pair (D+/D-), default is not-swapped. diff --git a/Documentation/devicetree/bindings/usb/vialab,vl817.yaml b/Documentation/devicetree/bindings/usb/vialab,vl817.yaml index 23a13e1d5c7a..76db9071b352 100644 --- a/Documentation/devicetree/bindings/usb/vialab,vl817.yaml +++ b/Documentation/devicetree/bindings/usb/vialab,vl817.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- $id: http://devicetree.org/schemas/usb/vialab,vl817.yaml# diff --git a/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml b/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml index 04c123c7252a..868dffe314bc 100644 --- a/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml +++ b/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx udc controller maintainers: - - Manish Narani <manish.narani@xilinx.com> + - Piyush Mehta <piyush.mehta@amd.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 82d39ab0231b..573578db9509 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -190,6 +190,8 @@ patternProperties: description: Compass Electronics Group, LLC "^beagle,.*": description: BeagleBoard.org Foundation + "^belling,.*": + description: Shanghai Belling Co., Ltd. "^bhf,.*": description: Beckhoff Automation GmbH & Co. KG "^bitmain,.*": @@ -388,6 +390,8 @@ patternProperties: description: EDIMAX Technology Co., Ltd "^edt,.*": description: Emerging Display Technologies + "^ees,.*": + description: Emtop Embedded Solutions "^eeti,.*": description: eGalax_eMPIA Technology Inc "^einfochips,.*": @@ -615,8 +619,12 @@ patternProperties: description: Imagination Technologies Ltd. "^imi,.*": description: Integrated Micro-Electronics Inc. + "^inanbo,.*": + description: Shenzhen INANBO Electronic Technology Co., Ltd. "^incircuit,.*": description: In-Circuit GmbH + "^indiedroid,.*": + description: Indiedroid "^inet-tek,.*": description: Shenzhen iNet Mobile Internet Technology Co., Ltd "^infineon,.*": @@ -671,6 +679,8 @@ patternProperties: description: iWave Systems Technologies Pvt. Ltd. "^jadard,.*": description: Jadard Technology Inc. + "^jasonic,.*": + description: Jasonic Technology Ltd. "^jdi,.*": description: Japan Display Inc. "^jedec,.*": @@ -781,6 +791,8 @@ patternProperties: description: Nanjing Loongmasses Ltd. "^lsi,.*": description: LSI Corp. (LSI Logic) + "^lunzn,.*": + description: Shenzhen Lunzn Technology Co., Ltd. "^lwn,.*": description: Liebherr-Werk Nenzing GmbH "^lxa,.*": @@ -1145,6 +1157,8 @@ patternProperties: description: Shenzhen Roofull Technology Co, Ltd "^roseapplepi,.*": description: RoseapplePi.org + "^saef,.*": + description: Saef Technology Limited "^samsung,.*": description: Samsung Semiconductor "^samtec,.*": @@ -1189,6 +1203,8 @@ patternProperties: description: SHIFT GmbH "^shimafuji,.*": description: Shimafuji Electric, Inc. + "^shineworld,.*": + description: ShineWorld Innovations "^shiratech,.*": description: Shiratech Solutions "^si-en,.*": @@ -1267,6 +1283,8 @@ patternProperties: description: SpinalHDL "^sprd,.*": description: Spreadtrum Communications Inc. + "^square,.*": + description: Square "^ssi,.*": description: SSI Computer Corp "^sst,.*": @@ -1339,6 +1357,8 @@ patternProperties: description: Technologic Systems "^techstar,.*": description: Shenzhen Techstar Electronics Co., Ltd. + "^teejet,.*": + description: TeeJet "^teltonika,.*": description: Teltonika Networks "^tempo,.*": diff --git a/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml index f5cc7aa1b93b..443e2e7ab467 100644 --- a/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - amlogic,meson-gxbb-wdt + - amlogic,t7-wdt reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.txt b/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.txt deleted file mode 100644 index 2b86a00e351d..000000000000 --- a/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.txt +++ /dev/null @@ -1,15 +0,0 @@ -Broadcom Kona Family Watchdog Timer ------------------------------------ - -This watchdog timer is used in the following Broadcom SoCs: - BCM11130, BCM11140, BCM11351, BCM28145, BCM28155 - -Required properties: - - compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt"; - - reg: memory address & range - -Example: - watchdog@35002f40 { - compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt"; - reg = <0x35002f40 0x6c>; - }; diff --git a/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.yaml b/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.yaml new file mode 100644 index 000000000000..3d4403b41cbe --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/brcm,kona-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Kona Family Watchdog Timer + +description: | + This watchdog timer is used in the following Broadcom SoCs: + BCM11130, BCM11140, BCM11351, BCM28145, BCM28155 + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + - Ray Jui <rjui@broadcom.com> + - Scott Branden <sbranden@broadcom.com> + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + items: + - const: brcm,bcm11351-wdt + - const: brcm,kona-wdt + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + watchdog@35002f40 { + compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt"; + reg = <0x35002f40 0x6c>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt b/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt deleted file mode 100644 index 750a87657448..000000000000 --- a/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt +++ /dev/null @@ -1,23 +0,0 @@ -Zynq Watchdog Device Tree Bindings -------------------------------------------- - -Required properties: -- compatible : Should be "cdns,wdt-r1p2". -- clocks : This is pclk (APB clock). -- interrupts : This is wd_irq - watchdog timeout interrupt. - -Optional properties -- reset-on-timeout : If this property exists, then a reset is done - when watchdog times out. -- timeout-sec : Watchdog timeout value (in seconds). - -Example: - watchdog@f8005000 { - compatible = "cdns,wdt-r1p2"; - clocks = <&clkc 45>; - interrupt-parent = <&intc>; - interrupts = <0 9 1>; - reg = <0xf8005000 0x1000>; - reset-on-timeout; - timeout-sec = <10>; - }; diff --git a/Documentation/devicetree/bindings/watchdog/cdns,wdt-r1p2.yaml b/Documentation/devicetree/bindings/watchdog/cdns,wdt-r1p2.yaml new file mode 100644 index 000000000000..3c17c5883bce --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/cdns,wdt-r1p2.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/cdns,wdt-r1p2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence watchdog timer controller + +maintainers: + - Neeli Srinivas <srinivas.neeli@amd.com> + +description: + The cadence watchdog timer is used to detect and recover from + system malfunctions. This watchdog contains 24 bit counter and + a programmable reset period. The timeout period varies from 1 ms + to 30 seconds while using a 100Mhz clock. + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + enum: + - cdns,wdt-r1p2 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + reset-on-timeout: + type: boolean + description: | + If this property exists, then a reset is done when watchdog + times out. + +required: + - compatible + - reg + - clocks + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + watchdog@f8005000 { + compatible = "cdns,wdt-r1p2"; + reg = <0xf8005000 0x1000>; + clocks = <&clkc 45>; + interrupt-parent = <&intc>; + interrupts = <GIC_SPI 9 IRQ_TYPE_EDGE_RISING>; + reset-on-timeout; + timeout-sec = <10>; + }; +... diff --git a/Documentation/devicetree/bindings/watchdog/loongson,ls1x-wdt.yaml b/Documentation/devicetree/bindings/watchdog/loongson,ls1x-wdt.yaml new file mode 100644 index 000000000000..81690d4b62a6 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/loongson,ls1x-wdt.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/loongson,ls1x-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson-1 Watchdog Timer + +maintainers: + - Keguang Zhang <keguang.zhang@gmail.com> + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + enum: + - loongson,ls1b-wdt + - loongson,ls1c-wdt + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/loongson,ls1x-clk.h> + watchdog: watchdog@1fe5c060 { + compatible = "loongson,ls1b-wdt"; + reg = <0x1fe5c060 0xc>; + + clocks = <&clkc LS1X_CLKID_APB>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/marvell,cn10624-wdt.yaml b/Documentation/devicetree/bindings/watchdog/marvell,cn10624-wdt.yaml new file mode 100644 index 000000000000..1b583f232e53 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/marvell,cn10624-wdt.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/marvell,cn10624-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Global Timer (GTI) system watchdog + +maintainers: + - Bharat Bhushan <bbhushan2@marvell.com> + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + oneOf: + - enum: + - marvell,cn9670-wdt + - marvell,cn10624-wdt + + - items: + - enum: + - marvell,cn9880-wdt + - marvell,cnf9535-wdt + - const: marvell,cn9670-wdt + + - items: + - enum: + - marvell,cn10308-wdt + - marvell,cnf10518-wdt + - const: marvell,cn10624-wdt + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: refclk + + marvell,wdt-timer-index: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 63 + description: + An SoC have many timers (up to 64), firmware can reserve one or more timer + for some other use case and configures one of the global timer as watchdog + timer. Firmware will update this field with the timer number configured + as watchdog timer. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + soc { + #address-cells = <2>; + #size-cells = <2>; + + watchdog@802000040000 { + compatible = "marvell,cn9670-wdt"; + reg = <0x00008020 0x00040000 0x00000000 0x00020000>; + interrupts = <GIC_SPI 38 IRQ_TYPE_EDGE_RISING>; + clocks = <&sclk>; + clock-names = "refclk"; + marvell,wdt-timer-index = <63>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml index 6d0fe6abd06a..5046dfa55f13 100644 --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml @@ -18,6 +18,7 @@ properties: - items: - enum: - qcom,kpss-wdt-ipq4019 + - qcom,apss-wdt-ipq5018 - qcom,apss-wdt-ipq5332 - qcom,apss-wdt-ipq9574 - qcom,apss-wdt-msm8994 diff --git a/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml b/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml index fc553211e42d..62ddc284a524 100644 --- a/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml @@ -34,6 +34,20 @@ properties: power-domains: maxItems: 1 + memory-region: + maxItems: 1 + description: + Contains the watchdog reserved memory. It is optional. + In the reserved memory, the specified values, which are + PON_REASON_SOF_NUM(0xBBBBCCCC), PON_REASON_MAGIC_NUM(0xDDDDDDDD), + and PON_REASON_EOF_NUM(0xCCCCBBBB), are pre-stored at the first + 3 * 4 bytes to tell that last boot was caused by watchdog reset. + Once the PON reason is captured by driver(rti_wdt.c), the driver + is supposed to wipe the whole memory region. Surely, if this + property is set, at least 12 bytes reserved memory starting from + specific memory address(0xa220000) should be set. More please + refer to example. + required: - compatible - reg @@ -47,7 +61,18 @@ examples: /* * RTI WDT in main domain on J721e SoC. Assigned clocks are used to * select the source clock for the watchdog, forcing it to tick with - * a 32kHz clock in this case. + * a 32kHz clock in this case. Add a reserved memory(optional) to keep + * the watchdog reset cause persistent, which was be written in 12 bytes + * starting from 0xa2200000 by RTI Watchdog Firmware, then make it + * possible to get watchdog reset cause in driver. + * + * Reserved memory should be defined as follows: + * reserved-memory { + * wdt_reset_memory_region: wdt-memory@a2200000 { + * reg = <0x00 0xa2200000 0x00 0x1000>; + * no-map; + * }; + * } */ #include <dt-bindings/soc/ti,sci_pm_domain.h> @@ -58,4 +83,5 @@ examples: power-domains = <&k3_pds 252 TI_SCI_PD_EXCLUSIVE>; assigned-clocks = <&k3_clks 252 1>; assigned-clock-parents = <&k3_clks 252 5>; + memory-region = <&wdt_reset_memory_region>; }; diff --git a/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml b/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml index 51d03d5b08ad..3e9fd49d935e 100644 --- a/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml @@ -2,8 +2,8 @@ # Copyright 2020 Toshiba Electronic Devices & Storage Corporation %YAML 1.2 --- -$id: "http://devicetree.org/schemas/watchdog/toshiba,visconti-wdt.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/watchdog/toshiba,visconti-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Toshiba Visconti SoCs PIUWDT Watchdog timer diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.yaml b/Documentation/devicetree/bindings/watchdog/watchdog.yaml index 519b48889eb1..f0a584af1223 100644 --- a/Documentation/devicetree/bindings/watchdog/watchdog.yaml +++ b/Documentation/devicetree/bindings/watchdog/watchdog.yaml @@ -17,11 +17,11 @@ description: | select: properties: $nodename: - pattern: "^watchdog(@.*|-[0-9a-f])?$" + pattern: "^watchdog(@.*|-([0-9]|[1-9][0-9]+))?$" properties: $nodename: - pattern: "^(timer|watchdog)(@.*|-[0-9a-f])?$" + pattern: "^(timer|watchdog)(@.*|-([0-9]|[1-9][0-9]+))?$" timeout-sec: description: diff --git a/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml b/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml new file mode 100644 index 000000000000..14b069599740 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/xlnx,versal-wwdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Versal window watchdog timer controller + +maintainers: + - Neeli Srinivas <srinivas.neeli@amd.com> + +description: + Versal watchdog intellectual property uses window watchdog mode. + Window watchdog timer(WWDT) contains closed(first) and open(second) + window with 32 bit width. Write to the watchdog timer within + predefined window periods of time. This means a period that is not + too soon and a period that is not too late. The WWDT has to be + restarted within the open window time. If software tries to restart + WWDT outside of the open window time period, it generates a reset. + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + enum: + - xlnx,versal-wwdt + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + +unevaluatedProperties: false + +examples: + - | + watchdog@fd4d0000 { + compatible = "xlnx,versal-wwdt"; + reg = <0xfd4d0000 0x10000>; + clocks = <&clock25>; + timeout-sec = <30>; + }; +... diff --git a/Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml b/Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml index 8444c56dd602..dc1ff39d05a0 100644 --- a/Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml @@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx AXI/PLB softcore and window Watchdog Timer maintainers: - - Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> - - Srinivas Neeli <srinivas.neeli@xilinx.com> + - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> + - Srinivas Neeli <srinivas.neeli@amd.com> description: The Timebase watchdog timer(WDT) is a free-running 32 bit counter. diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst index 1dcbd7332476..6ad72ac6861b 100644 --- a/Documentation/doc-guide/kernel-doc.rst +++ b/Documentation/doc-guide/kernel-doc.rst @@ -151,9 +151,9 @@ named ``Return``. line breaks, so if you try to format some text nicely, as in:: * Return: - * 0 - OK - * -EINVAL - invalid argument - * -ENOMEM - out of memory + * %0 - OK + * %-EINVAL - invalid argument + * %-ENOMEM - out of memory this will all run together and produce:: @@ -163,8 +163,8 @@ named ``Return``. ReST list, e. g.:: * Return: - * * 0 - OK to runtime suspend the device - * * -EBUSY - Device should not be runtime suspended + * * %0 - OK to runtime suspend the device + * * %-EBUSY - Device should not be runtime suspended #) If the descriptive text you provide has lines that begin with some phrase followed by a colon, each of those phrases will be taken diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index 23edb427e76f..cd8ad7904491 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -313,9 +313,18 @@ the documentation build system will automatically turn a reference to function name exists. If you see ``c:func:`` use in a kernel document, please feel free to remove it. +Tables +------ + +ReStructuredText provides several options for table syntax. Kernel style for +tables is to prefer *simple table* syntax or *grid table* syntax. See the +`reStructuredText user reference for table syntax`_ for more details. + +.. _reStructuredText user reference for table syntax: + https://docutils.sourceforge.io/docs/user/rst/quickref.html#tables list tables ------------ +~~~~~~~~~~~ The list-table formats can be useful for tables that are not easily laid out in the usual Sphinx ASCII-art formats. These formats are nearly diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst index 4b4d8e28d3be..d78b7c328ff7 100644 --- a/Documentation/driver-api/basics.rst +++ b/Documentation/driver-api/basics.rst @@ -15,8 +15,8 @@ Driver device table :no-identifiers: pci_device_id -Delaying, scheduling, and timer routines ----------------------------------------- +Delaying and scheduling routines +-------------------------------- .. kernel-doc:: include/linux/sched.h :internal: @@ -33,16 +33,16 @@ Delaying, scheduling, and timer routines .. kernel-doc:: include/linux/completion.h :internal: -.. kernel-doc:: kernel/time/timer.c - :export: - -Wait queues and Wake events ---------------------------- +Time and timer routines +----------------------- -.. kernel-doc:: include/linux/wait.h +.. kernel-doc:: include/linux/jiffies.h :internal: -.. kernel-doc:: kernel/sched/wait.c +.. kernel-doc:: kernel/time/time.c + :export: + +.. kernel-doc:: kernel/time/timer.c :export: High-resolution timers @@ -57,6 +57,15 @@ High-resolution timers .. kernel-doc:: kernel/time/hrtimer.c :export: +Wait queues and Wake events +--------------------------- + +.. kernel-doc:: include/linux/wait.h + :internal: + +.. kernel-doc:: kernel/sched/wait.c + :export: + Internal Functions ------------------ @@ -84,7 +93,13 @@ Reference counting Atomics ------- -.. kernel-doc:: arch/x86/include/asm/atomic.h +.. kernel-doc:: include/linux/atomic/atomic-instrumented.h + :internal: + +.. kernel-doc:: include/linux/atomic/atomic-arch-fallback.h + :internal: + +.. kernel-doc:: include/linux/atomic/atomic-long.h :internal: Kernel objects manipulation diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index 4249eb4239e0..8be086b3f829 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -364,6 +364,7 @@ MEM devm_kmalloc_array() devm_kmemdup() devm_krealloc() + devm_krealloc_array() devm_kstrdup() devm_kstrdup_const() devm_kvasprintf() diff --git a/Documentation/driver-api/edac.rst b/Documentation/driver-api/edac.rst index b8c742aa0a71..f4f044b95c4f 100644 --- a/Documentation/driver-api/edac.rst +++ b/Documentation/driver-api/edac.rst @@ -106,6 +106,16 @@ will occupy those chip-select rows. This term is avoided because it is unclear when needing to distinguish between chip-select rows and socket sets. +* High Bandwidth Memory (HBM) + +HBM is a new memory type with low power consumption and ultra-wide +communication lanes. It uses vertically stacked memory chips (DRAM dies) +interconnected by microscopic wires called "through-silicon vias," or +TSVs. + +Several stacks of HBM chips connect to the CPU or GPU through an ultra-fast +interconnect called the "interposer". Therefore, HBM's characteristics +are nearly indistinguishable from on-chip integrated RAM. Memory Controllers ------------------ @@ -176,3 +186,113 @@ nodes:: the L1 and L2 directories would be "edac_device_block's" .. kernel-doc:: drivers/edac/edac_device.h + + +Heterogeneous system support +---------------------------- + +An AMD heterogeneous system is built by connecting the data fabrics of +both CPUs and GPUs via custom xGMI links. Thus, the data fabric on the +GPU nodes can be accessed the same way as the data fabric on CPU nodes. + +The MI200 accelerators are data center GPUs. They have 2 data fabrics, +and each GPU data fabric contains four Unified Memory Controllers (UMC). +Each UMC contains eight channels. Each UMC channel controls one 128-bit +HBM2e (2GB) channel (equivalent to 8 X 2GB ranks). This creates a total +of 4096-bits of DRAM data bus. + +While the UMC is interfacing a 16GB (8high X 2GB DRAM) HBM stack, each UMC +channel is interfacing 2GB of DRAM (represented as rank). + +Memory controllers on AMD GPU nodes can be represented in EDAC thusly: + + GPU DF / GPU Node -> EDAC MC + GPU UMC -> EDAC CSROW + GPU UMC channel -> EDAC CHANNEL + +For example: a heterogeneous system with 1 AMD CPU is connected to +4 MI200 (Aldebaran) GPUs using xGMI. + +Some more heterogeneous hardware details: + +- The CPU UMC (Unified Memory Controller) is mostly the same as the GPU UMC. + They have chip selects (csrows) and channels. However, the layouts are different + for performance, physical layout, or other reasons. +- CPU UMCs use 1 channel, In this case UMC = EDAC channel. This follows the + marketing speak. CPU has X memory channels, etc. +- CPU UMCs use up to 4 chip selects, So UMC chip select = EDAC CSROW. +- GPU UMCs use 1 chip select, So UMC = EDAC CSROW. +- GPU UMCs use 8 channels, So UMC channel = EDAC channel. + +The EDAC subsystem provides a mechanism to handle AMD heterogeneous +systems by calling system specific ops for both CPUs and GPUs. + +AMD GPU nodes are enumerated in sequential order based on the PCI +hierarchy, and the first GPU node is assumed to have a Node ID value +following those of the CPU nodes after latter are fully populated:: + + $ ls /sys/devices/system/edac/mc/ + mc0 - CPU MC node 0 + mc1 | + mc2 |- GPU card[0] => node 0(mc1), node 1(mc2) + mc3 | + mc4 |- GPU card[1] => node 0(mc3), node 1(mc4) + mc5 | + mc6 |- GPU card[2] => node 0(mc5), node 1(mc6) + mc7 | + mc8 |- GPU card[3] => node 0(mc7), node 1(mc8) + +For example, a heterogeneous system with one AMD CPU is connected to +four MI200 (Aldebaran) GPUs using xGMI. This topology can be represented +via the following sysfs entries:: + + /sys/devices/system/edac/mc/.. + + CPU # CPU node + ├── mc 0 + + GPU Nodes are enumerated sequentially after CPU nodes have been populated + GPU card 1 # Each MI200 GPU has 2 nodes/mcs + ├── mc 1 # GPU node 0 == mc1, Each MC node has 4 UMCs/CSROWs + │ ├── csrow 0 # UMC 0 + │ │ ├── channel 0 # Each UMC has 8 channels + │ │ ├── channel 1 # size of each channel is 2 GB, so each UMC has 16 GB + │ │ ├── channel 2 + │ │ ├── channel 3 + │ │ ├── channel 4 + │ │ ├── channel 5 + │ │ ├── channel 6 + │ │ ├── channel 7 + │ ├── csrow 1 # UMC 1 + │ │ ├── channel 0 + │ │ ├── .. + │ │ ├── channel 7 + │ ├── .. .. + │ ├── csrow 3 # UMC 3 + │ │ ├── channel 0 + │ │ ├── .. + │ │ ├── channel 7 + │ ├── rank 0 + │ ├── .. .. + │ ├── rank 31 # total 32 ranks/dimms from 4 UMCs + ├ + ├── mc 2 # GPU node 1 == mc2 + │ ├── .. # each GPU has total 64 GB + + GPU card 2 + ├── mc 3 + │ ├── .. + ├── mc 4 + │ ├── .. + + GPU card 3 + ├── mc 5 + │ ├── .. + ├── mc 6 + │ ├── .. + + GPU card 4 + ├── mc 7 + │ ├── .. + ├── mc 8 + │ ├── .. diff --git a/Documentation/driver-api/gpio/legacy.rst b/Documentation/driver-api/gpio/legacy.rst index 78372853c6d4..b6505914791c 100644 --- a/Documentation/driver-api/gpio/legacy.rst +++ b/Documentation/driver-api/gpio/legacy.rst @@ -165,8 +165,7 @@ Most GPIO controllers can be accessed with memory read/write instructions. Those don't need to sleep, and can safely be done from inside hard (nonthreaded) IRQ handlers and similar contexts. -Use the following calls to access such GPIOs, -for which gpio_cansleep() will always return false (see below):: +Use the following calls to access such GPIOs:: /* GPIO INPUT: return zero or nonzero */ int gpio_get_value(unsigned gpio); @@ -200,13 +199,6 @@ Some GPIO controllers must be accessed using message based busses like I2C or SPI. Commands to read or write those GPIO values require waiting to get to the head of a queue to transmit a command and get its response. This requires sleeping, which can't be done from inside IRQ handlers. - -Platforms that support this type of GPIO distinguish them from other GPIOs -by returning nonzero from this call (which requires a valid GPIO number, -which should have been previously allocated with gpio_request):: - - int gpio_cansleep(unsigned gpio); - To access such GPIOs, a different set of accessors is defined:: /* GPIO INPUT: return zero or nonzero, might sleep */ @@ -215,7 +207,6 @@ To access such GPIOs, a different set of accessors is defined:: /* GPIO OUTPUT, might sleep */ void gpio_set_value_cansleep(unsigned gpio, int value); - Accessing such GPIOs requires a context which may sleep, for example a threaded IRQ handler, and those accessors must be used instead of spinlock-safe accessors without the cansleep() name suffix. @@ -319,11 +310,6 @@ where 'flags' is currently defined to specify the following properties: * GPIOF_INIT_LOW - as output, set initial level to LOW * GPIOF_INIT_HIGH - as output, set initial level to HIGH - * GPIOF_OPEN_DRAIN - gpio pin is open drain type. - * GPIOF_OPEN_SOURCE - gpio pin is open source type. - - * GPIOF_EXPORT_DIR_FIXED - export gpio to sysfs, keep direction - * GPIOF_EXPORT_DIR_CHANGEABLE - also export, allow changing direction since GPIOF_INIT_* are only valid when configured as output, so group valid combinations as: @@ -332,20 +318,6 @@ combinations as: * GPIOF_OUT_INIT_LOW - configured as output, initial level LOW * GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH -When setting the flag as GPIOF_OPEN_DRAIN then it will assume that pins is -open drain type. Such pins will not be driven to 1 in output mode. It is -require to connect pull-up on such pins. By enabling this flag, gpio lib will -make the direction to input when it is asked to set value of 1 in output mode -to make the pin HIGH. The pin is make to LOW by driving value 0 in output mode. - -When setting the flag as GPIOF_OPEN_SOURCE then it will assume that pins is -open source type. Such pins will not be driven to 0 in output mode. It is -require to connect pull-down on such pin. By enabling this flag, gpio lib will -make the direction to input when it is asked to set value of 0 in output mode -to make the pin LOW. The pin is make to HIGH by driving value 1 in output mode. - -In the future, these flags can be extended to support more properties. - Further more, to ease the claim/release of multiple GPIOs, 'struct gpio' is introduced to encapsulate all three fields as:: @@ -556,7 +528,6 @@ code, which always dispatches through the gpio_chip:: #define gpio_get_value __gpio_get_value #define gpio_set_value __gpio_set_value - #define gpio_cansleep __gpio_cansleep Fancier implementations could instead define those as inline functions with logic optimizing access to specific SOC-based GPIOs. For example, if the diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index ff9aa1afdc62..1e16a40da3ba 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -113,6 +113,7 @@ available subsections can be seen below. xillybus zorro hte/index + wmi .. only:: subproject and html diff --git a/Documentation/driver-api/infrastructure.rst b/Documentation/driver-api/infrastructure.rst index 683bd460e222..3d52dfdfa9fd 100644 --- a/Documentation/driver-api/infrastructure.rst +++ b/Documentation/driver-api/infrastructure.rst @@ -8,12 +8,24 @@ The Basic Device Driver-Model Structures :internal: :no-identifiers: device_link_state +.. kernel-doc:: include/linux/device/bus.h + :identifiers: bus_type bus_notifier_event + +.. kernel-doc:: include/linux/device/class.h + :identifiers: class + +.. kernel-doc:: include/linux/device/driver.h + :identifiers: probe_type device_driver + Device Drivers Base ------------------- .. kernel-doc:: drivers/base/init.c :internal: +.. kernel-doc:: include/linux/device/driver.h + :no-identifiers: probe_type device_driver + .. kernel-doc:: drivers/base/driver.c :export: @@ -23,6 +35,9 @@ Device Drivers Base .. kernel-doc:: drivers/base/syscore.c :export: +.. kernel-doc:: include/linux/device/class.h + :no-identifiers: class + .. kernel-doc:: drivers/base/class.c :export: @@ -41,6 +56,9 @@ Device Drivers Base .. kernel-doc:: drivers/base/platform.c :export: +.. kernel-doc:: include/linux/device/bus.h + :no-identifiers: bus_type bus_notifier_event + .. kernel-doc:: drivers/base/bus.c :export: diff --git a/Documentation/driver-api/interconnect.rst b/Documentation/driver-api/interconnect.rst index 5ed4f57a6bac..a92d0f277a1f 100644 --- a/Documentation/driver-api/interconnect.rst +++ b/Documentation/driver-api/interconnect.rst @@ -113,3 +113,28 @@ through dot to generate diagrams in many graphical formats:: $ cat /sys/kernel/debug/interconnect/interconnect_graph | \ dot -Tsvg > interconnect_graph.svg + +The ``test-client`` directory provides interfaces for issuing BW requests to +any arbitrary path. Note that for safety reasons, this feature is disabled by +default without a Kconfig to enable it. Enabling it requires code changes to +``#define INTERCONNECT_ALLOW_WRITE_DEBUGFS``. Example usage:: + + cd /sys/kernel/debug/interconnect/test-client/ + + # Configure node endpoints for the path from CPU to DDR on + # qcom/sm8550. + echo chm_apps > src_node + echo ebi > dst_node + + # Get path between src_node and dst_node. This is only + # necessary after updating the node endpoints. + echo 1 > get + + # Set desired BW to 1GBps avg and 2GBps peak. + echo 1000000 > avg_bw + echo 2000000 > peak_bw + + # Vote for avg_bw and peak_bw on the latest path from "get". + # Voting for multiple paths is possible by repeating this + # process for different nodes endpoints. + echo 1 > commit diff --git a/Documentation/driver-api/libata.rst b/Documentation/driver-api/libata.rst index 311af516a3fd..5da27a749246 100644 --- a/Documentation/driver-api/libata.rst +++ b/Documentation/driver-api/libata.rst @@ -32,22 +32,6 @@ register blocks. :c:type:`struct ata_port_operations <ata_port_operations>` ---------------------------------------------------------- -Disable ATA port -~~~~~~~~~~~~~~~~ - -:: - - void (*port_disable) (struct ata_port *); - - -Called from :c:func:`ata_bus_probe` error path, as well as when unregistering -from the SCSI module (rmmod, hot unplug). This function should do -whatever needs to be done to take the port out of use. In most cases, -:c:func:`ata_port_disable` can be used as this hook. - -Called from :c:func:`ata_bus_probe` on a failed probe. Called from -:c:func:`ata_scsi_release`. - Post-IDENTIFY device configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -274,14 +258,6 @@ Exception and probe handling (EH) :: - void (*eng_timeout) (struct ata_port *ap); - void (*phy_reset) (struct ata_port *ap); - - -Deprecated. Use ``->error_handler()`` instead. - -:: - void (*freeze) (struct ata_port *ap); void (*thaw) (struct ata_port *ap); @@ -364,8 +340,7 @@ SATA phy read/write u32 val); -Read and write standard SATA phy registers. Currently only used if -``->phy_reset`` hook called the :c:func:`sata_phy_reset` helper function. +Read and write standard SATA phy registers. sc_reg is one of SCR_STATUS, SCR_CONTROL, SCR_ERROR, or SCR_ACTIVE. Init and shutdown @@ -536,13 +511,12 @@ to return without deallocating the qc. This leads us to :c:func:`ata_scsi_error` is the current ``transportt->eh_strategy_handler()`` for libata. As discussed above, this will be entered in two cases - -timeout and ATAPI error completion. This function calls low level libata -driver's :c:func:`eng_timeout` callback, the standard callback for which is -:c:func:`ata_eng_timeout`. It checks if a qc is active and calls -:c:func:`ata_qc_timeout` on the qc if so. Actual error handling occurs in -:c:func:`ata_qc_timeout`. +timeout and ATAPI error completion. This function will check if a qc is active +and has not failed yet. Such a qc will be marked with AC_ERR_TIMEOUT such that +EH will know to handle it later. Then it calls low level libata driver's +:c:func:`error_handler` callback. -If EH is invoked for timeout, :c:func:`ata_qc_timeout` stops BMDMA and +When the :c:func:`error_handler` callback is invoked it stops BMDMA and completes the qc. Note that as we're currently in EH, we cannot call scsi_done. As described in SCSI EH doc, a recovered scmd should be either retried with :c:func:`scsi_queue_insert` or finished with diff --git a/Documentation/driver-api/media/camera-sensor.rst b/Documentation/driver-api/media/camera-sensor.rst index c7d4891bd24e..93f4f2536c25 100644 --- a/Documentation/driver-api/media/camera-sensor.rst +++ b/Documentation/driver-api/media/camera-sensor.rst @@ -151,3 +151,25 @@ used to obtain device's power state after the power state transition: The function returns a non-zero value if it succeeded getting the power count or runtime PM was disabled, in either of which cases the driver may proceed to access the device. + +Rotation, orientation and flipping +---------------------------------- + +Some systems have the camera sensor mounted upside down compared to its natural +mounting rotation. In such cases, drivers shall expose the information to +userspace with the :ref:`V4L2_CID_CAMERA_SENSOR_ROTATION +<v4l2-camera-sensor-rotation>` control. + +Sensor drivers shall also report the sensor's mounting orientation with the +:ref:`V4L2_CID_CAMERA_SENSOR_ORIENTATION <v4l2-camera-sensor-orientation>`. + +Use ``v4l2_fwnode_device_parse()`` to obtain rotation and orientation +information from system firmware and ``v4l2_ctrl_new_fwnode_properties()`` to +register the appropriate controls. + +Sensor drivers that have any vertical or horizontal flips embedded in the +register programming sequences shall initialize the V4L2_CID_HFLIP and +V4L2_CID_VFLIP controls with the values programmed by the register sequences. +The default values of these controls shall be 0 (disabled). Especially these +controls shall not be inverted, independently of the sensor's mounting +rotation. diff --git a/Documentation/driver-api/media/cec-core.rst b/Documentation/driver-api/media/cec-core.rst index ae0d20798edc..f1ffdec388f3 100644 --- a/Documentation/driver-api/media/cec-core.rst +++ b/Documentation/driver-api/media/cec-core.rst @@ -109,9 +109,11 @@ your driver: int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable); int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable); int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); - void (*adap_configured)(struct cec_adapter *adap, bool configured); + void (*adap_unconfigured)(struct cec_adapter *adap); int (*adap_transmit)(struct cec_adapter *adap, u8 attempts, u32 signal_free_time, struct cec_msg *msg); + void (*adap_nb_transmit_canceled)(struct cec_adapter *adap, + const struct cec_msg *msg); void (*adap_status)(struct cec_adapter *adap, struct seq_file *file); void (*adap_free)(struct cec_adapter *adap); @@ -122,8 +124,8 @@ your driver: ... }; -The seven low-level ops deal with various aspects of controlling the CEC adapter -hardware: +These low-level ops deal with various aspects of controlling the CEC adapter +hardware. They are all called with the mutex adap->lock held. To enable/disable the hardware:: @@ -179,14 +181,12 @@ can receive directed messages to that address. Note that adap_log_addr must return 0 if logical_addr is CEC_LOG_ADDR_INVALID. -Called when the adapter is fully configured or unconfigured:: +Called when the adapter is unconfigured:: - void (*adap_configured)(struct cec_adapter *adap, bool configured); + void (*adap_unconfigured)(struct cec_adapter *adap); -If configured == true, then the adapter is fully configured, i.e. all logical -addresses have been successfully claimed. If configured == false, then the -adapter is unconfigured. If the driver has to take specific actions after -(un)configuration, then that can be done through this optional callback. +The adapter is unconfigured. If the driver has to take specific actions after +unconfiguration, then that can be done through this optional callback. To transmit a new message:: @@ -207,6 +207,19 @@ The CEC_FREE_TIME_TO_USEC macro can be used to convert signal_free_time to microseconds (one data bit period is 2.4 ms). +To pass on the result of a canceled non-blocking transmit:: + + void (*adap_nb_transmit_canceled)(struct cec_adapter *adap, + const struct cec_msg *msg); + +This optional callback can be used to obtain the result of a canceled +non-blocking transmit with sequence number msg->sequence. This is +called if the transmit was aborted, the transmit timed out (i.e. the +hardware never signaled that the transmit finished), or the transmit +was successful, but the wait for the expected reply was either aborted +or it timed out. + + To log the current CEC hardware status:: void (*adap_status)(struct cec_adapter *adap, struct seq_file *file); @@ -372,7 +385,8 @@ Implementing the High-Level CEC Adapter --------------------------------------- The low-level operations drive the hardware, the high-level operations are -CEC protocol driven. The following high-level callbacks are available: +CEC protocol driven. The high-level callbacks are called without the adap->lock +mutex being held. The following high-level callbacks are available: .. code-block:: none @@ -384,9 +398,19 @@ CEC protocol driven. The following high-level callbacks are available: ... /* High-level CEC message callback */ + void (*configured)(struct cec_adapter *adap); int (*received)(struct cec_adapter *adap, struct cec_msg *msg); }; +Called when the adapter is configured:: + + void (*configured)(struct cec_adapter *adap); + +The adapter is fully configured, i.e. all logical addresses have been +successfully claimed. If the driver has to take specific actions after +configuration, then that can be done through this optional callback. + + The received() callback allows the driver to optionally handle a newly received CEC message:: diff --git a/Documentation/driver-api/media/dtv-common.rst b/Documentation/driver-api/media/dtv-common.rst index f8b2c4dc8170..207a22bcaf4a 100644 --- a/Documentation/driver-api/media/dtv-common.rst +++ b/Documentation/driver-api/media/dtv-common.rst @@ -3,15 +3,6 @@ Digital TV Common functions --------------------------- -Math functions -~~~~~~~~~~~~~~ - -Provide some commonly-used math functions, usually required in order to -estimate signal strength and signal to noise measurements in dB. - -.. kernel-doc:: include/media/dvb_math.h - - DVB devices ~~~~~~~~~~~ diff --git a/Documentation/driver-api/media/v4l2-cci.rst b/Documentation/driver-api/media/v4l2-cci.rst new file mode 100644 index 000000000000..dd297a40ed20 --- /dev/null +++ b/Documentation/driver-api/media/v4l2-cci.rst @@ -0,0 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + +V4L2 CCI kAPI +^^^^^^^^^^^^^ +.. kernel-doc:: include/media/v4l2-cci.h diff --git a/Documentation/driver-api/media/v4l2-core.rst b/Documentation/driver-api/media/v4l2-core.rst index 1a8c4a5f256b..239045ecc8f4 100644 --- a/Documentation/driver-api/media/v4l2-core.rst +++ b/Documentation/driver-api/media/v4l2-core.rst @@ -22,6 +22,7 @@ Video4Linux devices v4l2-mem2mem v4l2-async v4l2-fwnode + v4l2-cci v4l2-rect v4l2-tuner v4l2-common diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst index 602dadaa81d8..e56b50b3f203 100644 --- a/Documentation/driver-api/media/v4l2-subdev.rst +++ b/Documentation/driver-api/media/v4l2-subdev.rst @@ -157,6 +157,9 @@ below. Using one or the other registration method only affects the probing process, the run-time bridge-subdevice interaction is in both cases the same. +Registering synchronous sub-devices +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + In the **synchronous** case a device (bridge) driver needs to register the :c:type:`v4l2_subdev` with the v4l2_device: @@ -175,10 +178,12 @@ You can unregister a sub-device using: :c:func:`v4l2_device_unregister_subdev <v4l2_device_unregister_subdev>` (:c:type:`sd <v4l2_subdev>`). - Afterwards the subdev module can be unloaded and :c:type:`sd <v4l2_subdev>`->dev == ``NULL``. +Registering asynchronous sub-devices +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + In the **asynchronous** case subdevice probing can be invoked independently of the bridge driver availability. The subdevice driver then has to verify whether all the requirements for a successful probing are satisfied. This can include a @@ -190,64 +195,89 @@ performed using the :c:func:`v4l2_async_unregister_subdev` call. Subdevices registered this way are stored in a global list of subdevices, ready to be picked up by bridge drivers. -Bridge drivers in turn have to register a notifier object. This is -performed using the :c:func:`v4l2_async_nf_register` call. To -unregister the notifier the driver has to call -:c:func:`v4l2_async_nf_unregister`. The former of the two functions -takes two arguments: a pointer to struct :c:type:`v4l2_device` and a -pointer to struct :c:type:`v4l2_async_notifier`. +Asynchronous sub-device notifiers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Bridge drivers in turn have to register a notifier object. This is performed +using the :c:func:`v4l2_async_nf_register` call. To unregister the notifier the +driver has to call :c:func:`v4l2_async_nf_unregister`. Before releasing memory +of an unregister notifier, it must be cleaned up by calling +:c:func:`v4l2_async_nf_cleanup`. Before registering the notifier, bridge drivers must do two things: first, the -notifier must be initialized using the :c:func:`v4l2_async_nf_init`. -Second, bridge drivers can then begin to form a list of subdevice descriptors -that the bridge device needs for its operation. Several functions are available -to add subdevice descriptors to a notifier, depending on the type of device and -the needs of the driver. - -:c:func:`v4l2_async_nf_add_fwnode_remote` and -:c:func:`v4l2_async_nf_add_i2c` are for bridge and ISP drivers for -registering their async sub-devices with the notifier. - -:c:func:`v4l2_async_register_subdev_sensor` is a helper function for -sensor drivers registering their own async sub-device, but it also registers a -notifier and further registers async sub-devices for lens and flash devices -found in firmware. The notifier for the sub-device is unregistered with the -async sub-device. - -These functions allocate an async sub-device descriptor which is of type struct -:c:type:`v4l2_async_subdev` embedded in a driver-specific struct. The &struct -:c:type:`v4l2_async_subdev` shall be the first member of this struct: +notifier must be initialized using the :c:func:`v4l2_async_nf_init`. Second, +bridge drivers can then begin to form a list of async connection descriptors +that the bridge device needs for its +operation. :c:func:`v4l2_async_nf_add_fwnode`, +:c:func:`v4l2_async_nf_add_fwnode_remote` and :c:func:`v4l2_async_nf_add_i2c` + +Async connection descriptors describe connections to external sub-devices the +drivers for which are not yet probed. Based on an async connection, a media data +or ancillary link may be created when the related sub-device becomes +available. There may be one or more async connections to a given sub-device but +this is not known at the time of adding the connections to the notifier. Async +connections are bound as matching async sub-devices are found, one by one. + +Asynchronous sub-device notifier for sub-devices +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A driver that registers an asynchronous sub-device may also register an +asynchronous notifier. This is called an asynchronous sub-device notifier andthe +process is similar to that of a bridge driver apart from that the notifier is +initialised using :c:func:`v4l2_async_subdev_nf_init` instead. A sub-device +notifier may complete only after the V4L2 device becomes available, i.e. there's +a path via async sub-devices and notifiers to a notifier that is not an +asynchronous sub-device notifier. + +Asynchronous sub-device registration helper for camera sensor drivers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +:c:func:`v4l2_async_register_subdev_sensor` is a helper function for sensor +drivers registering their own async connection, but it also registers a notifier +and further registers async connections for lens and flash devices found in +firmware. The notifier for the sub-device is unregistered and cleaned up with +the async sub-device, using :c:func:`v4l2_async_unregister_subdev`. + +Asynchronous sub-device notifier example +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +These functions allocate an async connection descriptor which is of type struct +:c:type:`v4l2_async_connection` embedded in a driver-specific struct. The &struct +:c:type:`v4l2_async_connection` shall be the first member of this struct: .. code-block:: c - struct my_async_subdev { - struct v4l2_async_subdev asd; + struct my_async_connection { + struct v4l2_async_connection asc; ... }; - struct my_async_subdev *my_asd; + struct my_async_connection *my_asc; struct fwnode_handle *ep; ... - my_asd = v4l2_async_nf_add_fwnode_remote(¬ifier, ep, - struct my_async_subdev); + my_asc = v4l2_async_nf_add_fwnode_remote(¬ifier, ep, + struct my_async_connection); fwnode_handle_put(ep); - if (IS_ERR(asd)) - return PTR_ERR(asd); + if (IS_ERR(my_asc)) + return PTR_ERR(my_asc); + +Asynchronous sub-device notifier callbacks +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The V4L2 core will then use these descriptors to match asynchronously -registered subdevices to them. If a match is detected the ``.bound()`` -notifier callback is called. After all subdevices have been located the -.complete() callback is called. When a subdevice is removed from the -system the .unbind() method is called. All three callbacks are optional. +The V4L2 core will then use these connection descriptors to match asynchronously +registered subdevices to them. If a match is detected the ``.bound()`` notifier +callback is called. After all connections have been bound the .complete() +callback is called. When a connection is removed from the system the +``.unbind()`` method is called. All three callbacks are optional. Drivers can store any type of custom data in their driver-specific -:c:type:`v4l2_async_subdev` wrapper. If any of that data requires special +:c:type:`v4l2_async_connection` wrapper. If any of that data requires special handling when the structure is freed, drivers must implement the ``.destroy()`` notifier callback. The framework will call it right before freeing the -:c:type:`v4l2_async_subdev`. +:c:type:`v4l2_async_connection`. Calling subdev operations ~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/driver-api/ntb.rst b/Documentation/driver-api/ntb.rst index 11577c2105c5..e991d92b8b1d 100644 --- a/Documentation/driver-api/ntb.rst +++ b/Documentation/driver-api/ntb.rst @@ -207,9 +207,9 @@ The MSI test client serves to test and debug the MSI library which allows for passing MSI interrupts across NTB memory windows. The test client is interacted with through the debugfs filesystem: -* *debugfs*/ntb\_tool/*hw*/ +* *debugfs*/ntb\_msi\_test/*hw*/ A directory in debugfs will be created for each - NTB device probed by the tool. This directory is shortened to *hw* + NTB device probed by the msi test. This directory is shortened to *hw* below. * *hw*/port This file describes the local port number diff --git a/Documentation/driver-api/ptp.rst b/Documentation/driver-api/ptp.rst index 664838ae7776..5e033c3b11b3 100644 --- a/Documentation/driver-api/ptp.rst +++ b/Documentation/driver-api/ptp.rst @@ -73,6 +73,22 @@ Writing clock drivers class driver, since the lock may also be needed by the clock driver's interrupt service routine. +PTP hardware clock requirements for '.adjphase' +----------------------------------------------- + + The 'struct ptp_clock_info' interface has a '.adjphase' function. + This function has a set of requirements from the PHC in order to be + implemented. + + * The PHC implements a servo algorithm internally that is used to + correct the offset passed in the '.adjphase' call. + * When other PTP adjustment functions are called, the PHC servo + algorithm is disabled. + + **NOTE:** '.adjphase' is not a simple time adjustment functionality + that 'jumps' the PHC clock time based on the provided offset. It + should correct the offset provided using an internal algorithm. + Supported hardware ================== @@ -106,3 +122,16 @@ Supported hardware - LPF settings (bandwidth, phase limiting, automatic holdover, physical layer assist (per ITU-T G.8273.2)) - Programmable output PTP clocks, any frequency up to 1GHz (to other PHY/MAC time stampers, refclk to ASSPs/SoCs/FPGAs) - Lock to GNSS input, automatic switching between GNSS and user-space PHC control (optional) + + * NVIDIA Mellanox + + - GPIO + - Certain variants of ConnectX-6 Dx and later products support one + GPIO which can time stamp external triggers and one GPIO to produce + periodic signals. + - Certain variants of ConnectX-5 and older products support one GPIO, + configured to either time stamp external triggers or produce + periodic signals. + - PHC instances + - All ConnectX devices have a free-running counter + - ConnectX-6 Dx and later devices have a UTC format counter diff --git a/Documentation/driver-api/s390-drivers.rst b/Documentation/driver-api/s390-drivers.rst index 5158577bc29b..8c0845c4eee7 100644 --- a/Documentation/driver-api/s390-drivers.rst +++ b/Documentation/driver-api/s390-drivers.rst @@ -27,7 +27,7 @@ not strictly considered I/O devices. They are considered here as well, although they are not the focus of this document. Some additional information can also be found in the kernel source under -Documentation/s390/driver-model.rst. +Documentation/arch/s390/driver-model.rst. The css bus =========== @@ -38,7 +38,7 @@ into several categories: * Standard I/O subchannels, for use by the system. They have a child device on the ccw bus and are described below. * I/O subchannels bound to the vfio-ccw driver. See - Documentation/s390/vfio-ccw.rst. + Documentation/arch/s390/vfio-ccw.rst. * Message subchannels. No Linux driver currently exists. * CHSC subchannels (at most one). The chsc subchannel driver can be used to send asynchronous chsc commands. diff --git a/Documentation/driver-api/tty/tty_buffer.rst b/Documentation/driver-api/tty/tty_buffer.rst index a39d4781e0d2..4b5ca1776d4f 100644 --- a/Documentation/driver-api/tty/tty_buffer.rst +++ b/Documentation/driver-api/tty/tty_buffer.rst @@ -15,10 +15,13 @@ Flip Buffer Management ====================== .. kernel-doc:: drivers/tty/tty_buffer.c - :identifiers: tty_prepare_flip_string tty_insert_flip_string_fixed_flag - tty_insert_flip_string_flags __tty_insert_flip_char + :identifiers: tty_prepare_flip_string tty_flip_buffer_push tty_ldisc_receive_buf +.. kernel-doc:: include/linux/tty_flip.h + :identifiers: tty_insert_flip_string_fixed_flag tty_insert_flip_string_flags + tty_insert_flip_char + ---- Other Functions diff --git a/Documentation/driver-api/usb/usb.rst b/Documentation/driver-api/usb/usb.rst index 2c94ff2f4385..fb41768696ec 100644 --- a/Documentation/driver-api/usb/usb.rst +++ b/Documentation/driver-api/usb/usb.rst @@ -420,6 +420,12 @@ USBDEVFS_CONNECTINFO know the devnum value already, it's the DDD value of the device file name. +USBDEVFS_GET_SPEED + Returns the speed of the device. The speed is returned as a + nummerical value in accordance with enum usb_device_speed + + File modification time is not updated by this request. + USBDEVFS_GETDRIVER Returns the name of the kernel driver bound to a given interface (a string). Parameter is a pointer to this structure, which is @@ -771,8 +777,7 @@ Speed may be: ======= ====================================================== 1.5 Mbit/s for low speed USB 12 Mbit/s for full speed USB - 480 Mbit/s for high speed USB (added for USB 2.0); - also used for Wireless USB, which has no fixed speed + 480 Mbit/s for high speed USB (added for USB 2.0) 5000 Mbit/s for SuperSpeed USB (added for USB 3.0) ======= ====================================================== diff --git a/Documentation/driver-api/vfio.rst b/Documentation/driver-api/vfio.rst index 68abc089d6dd..633d11c7fa71 100644 --- a/Documentation/driver-api/vfio.rst +++ b/Documentation/driver-api/vfio.rst @@ -239,6 +239,137 @@ group and can access them as follows:: /* Gratuitous device reset and go... */ ioctl(device, VFIO_DEVICE_RESET); +IOMMUFD and vfio_iommu_type1 +---------------------------- + +IOMMUFD is the new user API to manage I/O page tables from userspace. +It intends to be the portal of delivering advanced userspace DMA +features (nested translation [5]_, PASID [6]_, etc.) while also providing +a backwards compatibility interface for existing VFIO_TYPE1v2_IOMMU use +cases. Eventually the vfio_iommu_type1 driver, as well as the legacy +vfio container and group model is intended to be deprecated. + +The IOMMUFD backwards compatibility interface can be enabled two ways. +In the first method, the kernel can be configured with +CONFIG_IOMMUFD_VFIO_CONTAINER, in which case the IOMMUFD subsystem +transparently provides the entire infrastructure for the VFIO +container and IOMMU backend interfaces. The compatibility mode can +also be accessed if the VFIO container interface, ie. /dev/vfio/vfio is +simply symlink'd to /dev/iommu. Note that at the time of writing, the +compatibility mode is not entirely feature complete relative to +VFIO_TYPE1v2_IOMMU (ex. DMA mapping MMIO) and does not attempt to +provide compatibility to the VFIO_SPAPR_TCE_IOMMU interface. Therefore +it is not generally advisable at this time to switch from native VFIO +implementations to the IOMMUFD compatibility interfaces. + +Long term, VFIO users should migrate to device access through the cdev +interface described below, and native access through the IOMMUFD +provided interfaces. + +VFIO Device cdev +---------------- + +Traditionally user acquires a device fd via VFIO_GROUP_GET_DEVICE_FD +in a VFIO group. + +With CONFIG_VFIO_DEVICE_CDEV=y the user can now acquire a device fd +by directly opening a character device /dev/vfio/devices/vfioX where +"X" is the number allocated uniquely by VFIO for registered devices. +cdev interface does not support noiommu devices, so user should use +the legacy group interface if noiommu is wanted. + +The cdev only works with IOMMUFD. Both VFIO drivers and applications +must adapt to the new cdev security model which requires using +VFIO_DEVICE_BIND_IOMMUFD to claim DMA ownership before starting to +actually use the device. Once BIND succeeds then a VFIO device can +be fully accessed by the user. + +VFIO device cdev doesn't rely on VFIO group/container/iommu drivers. +Hence those modules can be fully compiled out in an environment +where no legacy VFIO application exists. + +So far SPAPR does not support IOMMUFD yet. So it cannot support device +cdev either. + +vfio device cdev access is still bound by IOMMU group semantics, ie. there +can be only one DMA owner for the group. Devices belonging to the same +group can not be bound to multiple iommufd_ctx or shared between native +kernel and vfio bus driver or other driver supporting the driver_managed_dma +flag. A violation of this ownership requirement will fail at the +VFIO_DEVICE_BIND_IOMMUFD ioctl, which gates full device access. + +Device cdev Example +------------------- + +Assume user wants to access PCI device 0000:6a:01.0:: + + $ ls /sys/bus/pci/devices/0000:6a:01.0/vfio-dev/ + vfio0 + +This device is therefore represented as vfio0. The user can verify +its existence:: + + $ ls -l /dev/vfio/devices/vfio0 + crw------- 1 root root 511, 0 Feb 16 01:22 /dev/vfio/devices/vfio0 + $ cat /sys/bus/pci/devices/0000:6a:01.0/vfio-dev/vfio0/dev + 511:0 + $ ls -l /dev/char/511\:0 + lrwxrwxrwx 1 root root 21 Feb 16 01:22 /dev/char/511:0 -> ../vfio/devices/vfio0 + +Then provide the user with access to the device if unprivileged +operation is desired:: + + $ chown user:user /dev/vfio/devices/vfio0 + +Finally the user could get cdev fd by:: + + cdev_fd = open("/dev/vfio/devices/vfio0", O_RDWR); + +An opened cdev_fd doesn't give the user any permission of accessing +the device except binding the cdev_fd to an iommufd. After that point +then the device is fully accessible including attaching it to an +IOMMUFD IOAS/HWPT to enable userspace DMA:: + + struct vfio_device_bind_iommufd bind = { + .argsz = sizeof(bind), + .flags = 0, + }; + struct iommu_ioas_alloc alloc_data = { + .size = sizeof(alloc_data), + .flags = 0, + }; + struct vfio_device_attach_iommufd_pt attach_data = { + .argsz = sizeof(attach_data), + .flags = 0, + }; + struct iommu_ioas_map map = { + .size = sizeof(map), + .flags = IOMMU_IOAS_MAP_READABLE | + IOMMU_IOAS_MAP_WRITEABLE | + IOMMU_IOAS_MAP_FIXED_IOVA, + .__reserved = 0, + }; + + iommufd = open("/dev/iommu", O_RDWR); + + bind.iommufd = iommufd; + ioctl(cdev_fd, VFIO_DEVICE_BIND_IOMMUFD, &bind); + + ioctl(iommufd, IOMMU_IOAS_ALLOC, &alloc_data); + attach_data.pt_id = alloc_data.out_ioas_id; + ioctl(cdev_fd, VFIO_DEVICE_ATTACH_IOMMUFD_PT, &attach_data); + + /* Allocate some space and setup a DMA mapping */ + map.user_va = (int64_t)mmap(0, 1024 * 1024, PROT_READ | PROT_WRITE, + MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); + map.iova = 0; /* 1MB starting at 0x0 from device view */ + map.length = 1024 * 1024; + map.ioas_id = alloc_data.out_ioas_id;; + + ioctl(iommufd, IOMMU_IOAS_MAP, &map); + + /* Other device operations as stated in "VFIO Usage Example" */ + VFIO User API ------------------------------------------------------------------------------- @@ -279,6 +410,7 @@ similar to a file operations structure:: struct iommufd_ctx *ictx, u32 *out_device_id); void (*unbind_iommufd)(struct vfio_device *vdev); int (*attach_ioas)(struct vfio_device *vdev, u32 *pt_id); + void (*detach_ioas)(struct vfio_device *vdev); int (*open_device)(struct vfio_device *vdev); void (*close_device)(struct vfio_device *vdev); ssize_t (*read)(struct vfio_device *vdev, char __user *buf, @@ -315,9 +447,10 @@ container_of(). - The [un]bind_iommufd callbacks are issued when the device is bound to and unbound from iommufd. - - The attach_ioas callback is issued when the device is attached to an - IOAS managed by the bound iommufd. The attached IOAS is automatically - detached when the device is unbound from iommufd. + - The [de]attach_ioas callback is issued when the device is attached to + and detached from an IOAS managed by the bound iommufd. However, the + attached IOAS can also be automatically detached when the device is + unbound from iommufd. - The read/write/mmap callbacks implement the device region access defined by the device's own VFIO_DEVICE_GET_REGION_INFO ioctl. @@ -564,3 +697,11 @@ This implementation has some specifics: \-0d.1 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90) + +.. [5] Nested translation is an IOMMU feature which supports two stage + address translations. This improves the address translation efficiency + in IOMMU virtualization. + +.. [6] PASID stands for Process Address Space ID, introduced by PCI + Express. It is a prerequisite for Shared Virtual Addressing (SVA) + and Scalable I/O Virtualization (Scalable IOV). diff --git a/Documentation/driver-api/wmi.rst b/Documentation/driver-api/wmi.rst new file mode 100644 index 000000000000..6ca58c8249e5 --- /dev/null +++ b/Documentation/driver-api/wmi.rst @@ -0,0 +1,21 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +============== +WMI Driver API +============== + +The WMI driver core supports a more modern bus-based interface for interacting +with WMI devices, and an older GUID-based interface. The latter interface is +considered to be deprecated, so new WMI drivers should generally avoid it since +it has some issues with multiple WMI devices and events sharing the same GUIDs +and/or notification IDs. The modern bus-based interface instead maps each +WMI device to a :c:type:`struct wmi_device <wmi_device>`, so it supports +WMI devices sharing GUIDs and/or notification IDs. Drivers can then register +a :c:type:`struct wmi_driver <wmi_driver>`, which will be bound to compatible +WMI devices by the driver core. + +.. kernel-doc:: include/linux/wmi.h + :internal: + +.. kernel-doc:: drivers/platform/x86/wmi.c + :export: diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst index b64809514b0f..70380a2a01b4 100644 --- a/Documentation/fault-injection/fault-injection.rst +++ b/Documentation/fault-injection/fault-injection.rst @@ -243,7 +243,7 @@ proc entries Error Injectable Functions -------------------------- -This part is for the kenrel developers considering to add a function to +This part is for the kernel developers considering to add a function to ALLOW_ERROR_INJECTION() macro. Requirements for the Error Injectable Functions diff --git a/Documentation/fault-injection/provoke-crashes.rst b/Documentation/fault-injection/provoke-crashes.rst index 3abe84225613..1f087e502ca6 100644 --- a/Documentation/fault-injection/provoke-crashes.rst +++ b/Documentation/fault-injection/provoke-crashes.rst @@ -29,7 +29,7 @@ recur_count cpoint_name Where in the kernel to trigger the action. It can be one of INT_HARDWARE_ENTRY, INT_HW_IRQ_EN, INT_TASKLET_ENTRY, - FS_DEVRW, MEM_SWAPOUT, TIMERADD, SCSI_QUEUE_RQ, or DIRECT. + FS_SUBMIT_BH, MEM_SWAPOUT, TIMERADD, SCSI_QUEUE_RQ, or DIRECT. cpoint_type Indicates the action to be taken on hitting the crash point. diff --git a/Documentation/fb/deferred_io.rst b/Documentation/fb/deferred_io.rst index 7300cff255a3..7fc1933b06d9 100644 --- a/Documentation/fb/deferred_io.rst +++ b/Documentation/fb/deferred_io.rst @@ -9,7 +9,7 @@ works: - userspace app like Xfbdev mmaps framebuffer - deferred IO and driver sets up fault and page_mkwrite handlers -- userspace app tries to write to mmaped vaddress +- userspace app tries to write to mmapped vaddress - we get pagefault and reach fault handler - fault handler finds and returns physical page - we get page_mkwrite where we add this page to a list diff --git a/Documentation/fb/sm712fb.rst b/Documentation/fb/sm712fb.rst index 994dad3b0238..8e000f80b5bc 100644 --- a/Documentation/fb/sm712fb.rst +++ b/Documentation/fb/sm712fb.rst @@ -31,5 +31,5 @@ Missing Features ================ (alias TODO list) - * 2D acceleratrion + * 2D acceleration * dual-head support diff --git a/Documentation/fb/sstfb.rst b/Documentation/fb/sstfb.rst index 42466ff49c58..88d5a52b13d8 100644 --- a/Documentation/fb/sstfb.rst +++ b/Documentation/fb/sstfb.rst @@ -73,7 +73,7 @@ Module insertion the device will be /dev/fb0. You can check this by doing a cat /proc/fb. You can find a copy of con2fb in tools/ directory. if you don't have another fb device, this step is superfluous, - as the console subsystem automagicaly binds ttys to the fb. + as the console subsystem automagically binds ttys to the fb. #. switch to the virtual console you just mapped. "tadaaa" ... Module removal diff --git a/Documentation/features/core/jump-labels/arch-support.txt b/Documentation/features/core/jump-labels/arch-support.txt index 2328eada3a49..94d9dece580f 100644 --- a/Documentation/features/core/jump-labels/arch-support.txt +++ b/Documentation/features/core/jump-labels/arch-support.txt @@ -13,7 +13,7 @@ | csky: | ok | | hexagon: | TODO | | ia64: | TODO | - | loongarch: | TODO | + | loongarch: | ok | | m68k: | TODO | | microblaze: | TODO | | mips: | ok | diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt index 9c5d39eebef2..97c65ed2ac23 100644 --- a/Documentation/features/core/thread-info-in-task/arch-support.txt +++ b/Documentation/features/core/thread-info-in-task/arch-support.txt @@ -1,7 +1,7 @@ # # Feature name: thread-info-in-task # Kconfig: THREAD_INFO_IN_TASK -# description: arch makes use of the core kernel facility to embedd thread_info in task_struct +# description: arch makes use of the core kernel facility to embed thread_info in task_struct # ----------------------- | arch |status| diff --git a/Documentation/features/debug/kmemleak/arch-support.txt b/Documentation/features/debug/kmemleak/arch-support.txt index 0cfa5f0e4db1..4e205ef70363 100644 --- a/Documentation/features/debug/kmemleak/arch-support.txt +++ b/Documentation/features/debug/kmemleak/arch-support.txt @@ -13,7 +13,7 @@ | csky: | ok | | hexagon: | TODO | | ia64: | TODO | - | loongarch: | TODO | + | loongarch: | ok | | m68k: | TODO | | microblaze: | ok | | mips: | ok | diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt index bcc29d3aba9a..38a0a54b79f5 100644 --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt @@ -13,7 +13,7 @@ | csky: | ok | | hexagon: | TODO | | ia64: | TODO | - | loongarch: | TODO | + | loongarch: | ok | | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | diff --git a/Documentation/features/debug/kprobes/arch-support.txt b/Documentation/features/debug/kprobes/arch-support.txt index 8a77d62a42c5..aad83b57587a 100644 --- a/Documentation/features/debug/kprobes/arch-support.txt +++ b/Documentation/features/debug/kprobes/arch-support.txt @@ -13,7 +13,7 @@ | csky: | ok | | hexagon: | TODO | | ia64: | ok | - | loongarch: | TODO | + | loongarch: | ok | | m68k: | TODO | | microblaze: | TODO | | mips: | ok | diff --git a/Documentation/features/debug/kretprobes/arch-support.txt b/Documentation/features/debug/kretprobes/arch-support.txt index cf4723c5ac55..61380010a4a7 100644 --- a/Documentation/features/debug/kretprobes/arch-support.txt +++ b/Documentation/features/debug/kretprobes/arch-support.txt @@ -13,7 +13,7 @@ | csky: | ok | | hexagon: | TODO | | ia64: | ok | - | loongarch: | TODO | + | loongarch: | ok | | m68k: | TODO | | microblaze: | TODO | | mips: | ok | diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt index 71cd4ba18f7d..4c64c5d596f7 100644 --- a/Documentation/features/debug/stackprotector/arch-support.txt +++ b/Documentation/features/debug/stackprotector/arch-support.txt @@ -13,7 +13,7 @@ | csky: | ok | | hexagon: | TODO | | ia64: | TODO | - | loongarch: | TODO | + | loongarch: | ok | | m68k: | TODO | | microblaze: | TODO | | mips: | ok | diff --git a/Documentation/features/debug/uprobes/arch-support.txt b/Documentation/features/debug/uprobes/arch-support.txt index d53f2f94fbda..24c8423b0abc 100644 --- a/Documentation/features/debug/uprobes/arch-support.txt +++ b/Documentation/features/debug/uprobes/arch-support.txt @@ -13,7 +13,7 @@ | csky: | ok | | hexagon: | TODO | | ia64: | TODO | - | loongarch: | TODO | + | loongarch: | ok | | m68k: | TODO | | microblaze: | TODO | | mips: | ok | diff --git a/Documentation/features/locking/lockdep/arch-support.txt b/Documentation/features/locking/lockdep/arch-support.txt index ddb945278589..a36e231670d7 100644 --- a/Documentation/features/locking/lockdep/arch-support.txt +++ b/Documentation/features/locking/lockdep/arch-support.txt @@ -19,7 +19,7 @@ | mips: | ok | | nios2: | TODO | | openrisc: | ok | - | parisc: | TODO | + | parisc: | ok | | powerpc: | ok | | riscv: | ok | | s390: | ok | diff --git a/Documentation/features/vm/ELF-ASLR/arch-support.txt b/Documentation/features/vm/ELF-ASLR/arch-support.txt index 15164f36f224..47909c3dd602 100644 --- a/Documentation/features/vm/ELF-ASLR/arch-support.txt +++ b/Documentation/features/vm/ELF-ASLR/arch-support.txt @@ -1,6 +1,7 @@ # # Feature name: ELF-ASLR # Kconfig: ARCH_HAS_ELF_RANDOMIZE +# Kconfig: ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT # description: arch randomizes the stack, heap and binary images of ELF binaries # ----------------------- @@ -10,10 +11,10 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | csky: | TODO | + | csky: | ok | | hexagon: | TODO | | ia64: | TODO | - | loongarch: | TODO | + | loongarch: | ok | | m68k: | TODO | | microblaze: | TODO | | mips: | ok | diff --git a/Documentation/features/vm/TLB/arch-support.txt b/Documentation/features/vm/TLB/arch-support.txt index 7f049c251a79..76208db88f3b 100644 --- a/Documentation/features/vm/TLB/arch-support.txt +++ b/Documentation/features/vm/TLB/arch-support.txt @@ -9,7 +9,7 @@ | alpha: | TODO | | arc: | TODO | | arm: | TODO | - | arm64: | N/A | + | arm64: | ok | | csky: | TODO | | hexagon: | TODO | | ia64: | TODO | diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst index 1b5f0cc3e4ca..1e0e0bb6fdf9 100644 --- a/Documentation/filesystems/9p.rst +++ b/Documentation/filesystems/9p.rst @@ -79,7 +79,7 @@ Options cache=mode specifies a caching policy. By default, no caches are used. The mode can be specified as a bitmask or by using one of the - prexisting common 'shortcuts'. + preexisting common 'shortcuts'. The bitmask is described below: (unspecified bits are reserved) ========== ==================================================== diff --git a/Documentation/filesystems/afs.rst b/Documentation/filesystems/afs.rst index ca062a7f8ee2..f15ba388bbde 100644 --- a/Documentation/filesystems/afs.rst +++ b/Documentation/filesystems/afs.rst @@ -44,7 +44,7 @@ options:: CONFIG_AF_RXRPC - The RxRPC protocol transport CONFIG_RXKAD - The RxRPC Kerberos security handler - CONFIG_AFS - The AFS filesystem + CONFIG_AFS_FS - The AFS filesystem Additionally, the following can be turned on to aid debugging:: diff --git a/Documentation/filesystems/autofs-mount-control.rst b/Documentation/filesystems/autofs-mount-control.rst index bf4b511cdbe8..b5a379d25c40 100644 --- a/Documentation/filesystems/autofs-mount-control.rst +++ b/Documentation/filesystems/autofs-mount-control.rst @@ -196,7 +196,7 @@ information and return operation results:: struct args_ismountpoint ismountpoint; }; - char path[0]; + char path[]; }; The ioctlfd field is a mount point file descriptor of an autofs mount diff --git a/Documentation/filesystems/autofs.rst b/Documentation/filesystems/autofs.rst index 4f490278d22f..3b6e38e646cd 100644 --- a/Documentation/filesystems/autofs.rst +++ b/Documentation/filesystems/autofs.rst @@ -467,7 +467,7 @@ Each ioctl is passed a pointer to an `autofs_dev_ioctl` structure:: struct args_ismountpoint ismountpoint; }; - char path[0]; + char path[]; }; For the **OPEN_MOUNT** and **IS_MOUNTPOINT** commands, the target diff --git a/Documentation/filesystems/befs.rst b/Documentation/filesystems/befs.rst index 79f9740d76ff..a22f603b2938 100644 --- a/Documentation/filesystems/befs.rst +++ b/Documentation/filesystems/befs.rst @@ -106,8 +106,8 @@ iocharset=xxx Use xxx as the name of the NLS translation table. debug The driver will output debugging information to the syslog. ============= =========================================================== -How to Get Lastest Version -========================== +How to Get Latest Version +========================= The latest version is currently available at: <http://befs-driver.sourceforge.net/> diff --git a/Documentation/filesystems/caching/cachefiles.rst b/Documentation/filesystems/caching/cachefiles.rst index fc7abf712315..e04a27bdbe19 100644 --- a/Documentation/filesystems/caching/cachefiles.rst +++ b/Documentation/filesystems/caching/cachefiles.rst @@ -416,7 +416,7 @@ process is the target of an operation by some other process (SIGKILL for example). The subjective security holds the active security properties of a process, and -may be overridden. This is not seen externally, and is used whan a process +may be overridden. This is not seen externally, and is used when a process acts upon another object, for example SIGKILLing another process or opening a file. diff --git a/Documentation/filesystems/caching/netfs-api.rst b/Documentation/filesystems/caching/netfs-api.rst index 1d18e9def183..665b27f1556e 100644 --- a/Documentation/filesystems/caching/netfs-api.rst +++ b/Documentation/filesystems/caching/netfs-api.rst @@ -59,7 +59,7 @@ A filesystem would typically have a volume cookie for each superblock. The filesystem then acquires a cookie for each file within that volume using an object key. Object keys are binary blobs and only need to be unique within -their parent volume. The cache backend is reponsible for rendering the binary +their parent volume. The cache backend is responsible for rendering the binary blob into something it can use and may employ hash tables, trees or whatever to improve its ability to find an object. This is transparent to the network filesystem. @@ -91,7 +91,7 @@ actually required and it can use the fscache I/O API directly. Volume Registration =================== -The first step for a network filsystem is to acquire a volume cookie for the +The first step for a network filesystem is to acquire a volume cookie for the volume it wants to access:: struct fscache_volume * @@ -119,7 +119,7 @@ is provided. If the coherency data doesn't match, the entire cache volume will be invalidated. This function can return errors such as EBUSY if the volume key is already in -use by an acquired volume or ENOMEM if an allocation failure occured. It may +use by an acquired volume or ENOMEM if an allocation failure occurred. It may also return a NULL volume cookie if fscache is not enabled. It is safe to pass a NULL cookie to any function that takes a volume cookie. This will cause that function to do nothing. diff --git a/Documentation/filesystems/configfs.rst b/Documentation/filesystems/configfs.rst index 8c9342ed6d25..ac22138de6a4 100644 --- a/Documentation/filesystems/configfs.rst +++ b/Documentation/filesystems/configfs.rst @@ -253,7 +253,7 @@ to be used. If binary attribute is readable and the config_item provides a ct_item_ops->read_bin_attribute() method, that method will be called whenever userspace asks for a read(2) on the attribute. The converse -will happen for write(2). The reads/writes are bufferred so only a +will happen for write(2). The reads/writes are buffered so only a single read/write will occur; the attributes' need not concern itself with it. diff --git a/Documentation/filesystems/dax.rst b/Documentation/filesystems/dax.rst index c04609d8ee24..719e90f1988e 100644 --- a/Documentation/filesystems/dax.rst +++ b/Documentation/filesystems/dax.rst @@ -291,7 +291,7 @@ The DAX code does not work correctly on architectures which have virtually mapped caches such as ARM, MIPS and SPARC. Calling :c:func:`get_user_pages()` on a range of user memory that has been -mmaped from a `DAX` file will fail when there are no 'struct page' to describe +mmapped from a `DAX` file will fail when there are no 'struct page' to describe those pages. This problem has been addressed in some device drivers by adding optional struct page support for pages under the control of the driver (see `CONFIG_NVDIMM_PFN` in ``drivers/nvdimm`` for an example of diff --git a/Documentation/filesystems/devpts.rst b/Documentation/filesystems/devpts.rst index a03248ddfb4c..b6324ab1960d 100644 --- a/Documentation/filesystems/devpts.rst +++ b/Documentation/filesystems/devpts.rst @@ -5,8 +5,8 @@ The Devpts Filesystem ===================== Each mount of the devpts filesystem is now distinct such that ptys -and their indicies allocated in one mount are independent from ptys -and their indicies in all other mounts. +and their indices allocated in one mount are independent from ptys +and their indices in all other mounts. All mounts of the devpts filesystem now create a ``/dev/pts/ptmx`` node with permissions ``0000``. diff --git a/Documentation/filesystems/directory-locking.rst b/Documentation/filesystems/directory-locking.rst index 504ba940c36c..dccd61c7c5c3 100644 --- a/Documentation/filesystems/directory-locking.rst +++ b/Documentation/filesystems/directory-locking.rst @@ -22,12 +22,11 @@ exclusive. 3) object removal. Locking rules: caller locks parent, finds victim, locks victim and calls the method. Locks are exclusive. -4) rename() that is _not_ cross-directory. Locking rules: caller locks -the parent and finds source and target. In case of exchange (with -RENAME_EXCHANGE in flags argument) lock both. In any case, -if the target already exists, lock it. If the source is a non-directory, -lock it. If we need to lock both, lock them in inode pointer order. -Then call the method. All locks are exclusive. +4) rename() that is _not_ cross-directory. Locking rules: caller locks the +parent and finds source and target. We lock both (provided they exist). If we +need to lock two inodes of different type (dir vs non-dir), we lock directory +first. If we need to lock two inodes of the same type, lock them in inode +pointer order. Then call the method. All locks are exclusive. NB: we might get away with locking the source (and target in exchange case) shared. @@ -44,15 +43,17 @@ All locks are exclusive. rules: * lock the filesystem - * lock parents in "ancestors first" order. + * lock parents in "ancestors first" order. If one is not ancestor of + the other, lock them in inode pointer order. * find source and target. * if old parent is equal to or is a descendent of target fail with -ENOTEMPTY * if new parent is equal to or is a descendent of source fail with -ELOOP - * If it's an exchange, lock both the source and the target. - * If the target exists, lock it. If the source is a non-directory, - lock it. If we need to lock both, do so in inode pointer order. + * Lock both the source and the target provided they exist. If we + need to lock two inodes of different type (dir vs non-dir), we lock + the directory first. If we need to lock two inodes of the same type, + lock them in inode pointer order. * call the method. All ->i_rwsem are taken exclusive. Again, we might get away with locking @@ -66,8 +67,9 @@ If no directory is its own ancestor, the scheme above is deadlock-free. Proof: - First of all, at any moment we have a partial ordering of the - objects - A < B iff A is an ancestor of B. + First of all, at any moment we have a linear ordering of the + objects - A < B iff (A is an ancestor of B) or (B is not an ancestor + of A and ptr(A) < ptr(B)). That ordering can change. However, the following is true: diff --git a/Documentation/filesystems/dlmfs.rst b/Documentation/filesystems/dlmfs.rst index 28dd41a63be2..7e2b1fd471d7 100644 --- a/Documentation/filesystems/dlmfs.rst +++ b/Documentation/filesystems/dlmfs.rst @@ -12,7 +12,7 @@ dlmfs is built with OCFS2 as it requires most of its infrastructure. :Project web page: http://ocfs2.wiki.kernel.org :Tools web page: https://github.com/markfasheh/ocfs2-tools -:OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/ +:OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html All code copyright 2005 Oracle except when otherwise noted. diff --git a/Documentation/filesystems/ext4/journal.rst b/Documentation/filesystems/ext4/journal.rst index a6bef5293a60..6e8fb2d4b46f 100644 --- a/Documentation/filesystems/ext4/journal.rst +++ b/Documentation/filesystems/ext4/journal.rst @@ -260,8 +260,13 @@ which is 1024 bytes long: - s_num_fc_blocks - Number of fast commit blocks in the journal. * - 0x58 + - __be32 + - s_head + - Block number of the head (first unused block) of the journal, only + up-to-date when the journal is empty. + * - 0x5C - __u32 - - s_padding[42] + - s_padding[40] - * - 0xFC - __be32 diff --git a/Documentation/filesystems/ext4/super.rst b/Documentation/filesystems/ext4/super.rst index 0152888cac29..a1eb4a11a1d0 100644 --- a/Documentation/filesystems/ext4/super.rst +++ b/Documentation/filesystems/ext4/super.rst @@ -772,7 +772,7 @@ The ``s_default_mount_opts`` field is any combination of the following: * - 0x0010 - Do not support 32-bit UIDs. (EXT4_DEFM_UID16) * - 0x0020 - - All data and metadata are commited to the journal. + - All data and metadata are committed to the journal. (EXT4_DEFM_JMODE_DATA) * - 0x0040 - All data are flushed to the disk before metadata are committed to the diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index c57745375edb..d32c6209685d 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -351,6 +351,22 @@ age_extent_cache Enable an age extent cache based on rb-tree. It records data block update frequency of the extent per inode, in order to provide better temperature hints for data block allocation. +errors=%s Specify f2fs behavior on critical errors. This supports modes: + "panic", "continue" and "remount-ro", respectively, trigger + panic immediately, continue without doing anything, and remount + the partition in read-only mode. By default it uses "continue" + mode. + ====================== =============== =============== ======== + mode continue remount-ro panic + ====================== =============== =============== ======== + access ops normal normal N/A + syscall errors -EIO -EROFS N/A + mount option rw ro N/A + pending dir write keep keep N/A + pending non-dir write drop keep N/A + pending node write drop keep N/A + pending meta write keep keep N/A + ====================== =============== =============== ======== ======================== ============================================================ Debugfs Entries @@ -464,7 +480,7 @@ Note: please refer to the manpage of dump.f2fs(8) to get full option list. sload.f2fs ---------- -The sload.f2fs gives a way to insert files and directories in the exisiting disk +The sload.f2fs gives a way to insert files and directories in the existing disk image. This tool is useful when building f2fs images given compiled files. Note: please refer to the manpage of sload.f2fs(8) to get full option list. @@ -776,7 +792,7 @@ Allocating disk space as a method of optimally implementing that function. However, once F2FS receives ioctl(fd, F2FS_IOC_SET_PIN_FILE) in prior to -fallocate(fd, DEFAULT_MODE), it allocates on-disk block addressess having +fallocate(fd, DEFAULT_MODE), it allocates on-disk block addresses having zero or random data, which is useful to the below scenario where: 1. create(fd) diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index eccd327e6df5..a624e92f2687 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -332,54 +332,121 @@ Encryption modes and usage fscrypt allows one encryption mode to be specified for file contents and one encryption mode to be specified for filenames. Different directory trees are permitted to use different encryption modes. + +Supported modes +--------------- + Currently, the following pairs of encryption modes are supported: - AES-256-XTS for contents and AES-256-CTS-CBC for filenames -- AES-128-CBC for contents and AES-128-CTS-CBC for filenames +- AES-256-XTS for contents and AES-256-HCTR2 for filenames - Adiantum for both contents and filenames -- AES-256-XTS for contents and AES-256-HCTR2 for filenames (v2 policies only) -- SM4-XTS for contents and SM4-CTS-CBC for filenames (v2 policies only) - -If unsure, you should use the (AES-256-XTS, AES-256-CTS-CBC) pair. - -AES-128-CBC was added only for low-powered embedded devices with -crypto accelerators such as CAAM or CESA that do not support XTS. To -use AES-128-CBC, CONFIG_CRYPTO_ESSIV and CONFIG_CRYPTO_SHA256 (or -another SHA-256 implementation) must be enabled so that ESSIV can be -used. - -Adiantum is a (primarily) stream cipher-based mode that is fast even -on CPUs without dedicated crypto instructions. It's also a true -wide-block mode, unlike XTS. It can also eliminate the need to derive -per-file encryption keys. However, it depends on the security of two -primitives, XChaCha12 and AES-256, rather than just one. See the -paper "Adiantum: length-preserving encryption for entry-level -processors" (https://eprint.iacr.org/2018/720.pdf) for more details. -To use Adiantum, CONFIG_CRYPTO_ADIANTUM must be enabled. Also, fast -implementations of ChaCha and NHPoly1305 should be enabled, e.g. -CONFIG_CRYPTO_CHACHA20_NEON and CONFIG_CRYPTO_NHPOLY1305_NEON for ARM. - -AES-256-HCTR2 is another true wide-block encryption mode that is intended for -use on CPUs with dedicated crypto instructions. AES-256-HCTR2 has the property -that a bitflip in the plaintext changes the entire ciphertext. This property -makes it desirable for filename encryption since initialization vectors are -reused within a directory. For more details on AES-256-HCTR2, see the paper -"Length-preserving encryption with HCTR2" -(https://eprint.iacr.org/2021/1441.pdf). To use AES-256-HCTR2, -CONFIG_CRYPTO_HCTR2 must be enabled. Also, fast implementations of XCTR and -POLYVAL should be enabled, e.g. CRYPTO_POLYVAL_ARM64_CE and -CRYPTO_AES_ARM64_CE_BLK for ARM64. - -SM4 is a Chinese block cipher that is an alternative to AES. It has -not seen as much security review as AES, and it only has a 128-bit key -size. It may be useful in cases where its use is mandated. -Otherwise, it should not be used. For SM4 support to be available, it -also needs to be enabled in the kernel crypto API. - -New encryption modes can be added relatively easily, without changes -to individual filesystems. However, authenticated encryption (AE) -modes are not currently supported because of the difficulty of dealing -with ciphertext expansion. +- AES-128-CBC-ESSIV for contents and AES-128-CTS-CBC for filenames +- SM4-XTS for contents and SM4-CTS-CBC for filenames + +Authenticated encryption modes are not currently supported because of +the difficulty of dealing with ciphertext expansion. Therefore, +contents encryption uses a block cipher in `XTS mode +<https://en.wikipedia.org/wiki/Disk_encryption_theory#XTS>`_ or +`CBC-ESSIV mode +<https://en.wikipedia.org/wiki/Disk_encryption_theory#Encrypted_salt-sector_initialization_vector_(ESSIV)>`_, +or a wide-block cipher. Filenames encryption uses a +block cipher in `CTS-CBC mode +<https://en.wikipedia.org/wiki/Ciphertext_stealing>`_ or a wide-block +cipher. + +The (AES-256-XTS, AES-256-CTS-CBC) pair is the recommended default. +It is also the only option that is *guaranteed* to always be supported +if the kernel supports fscrypt at all; see `Kernel config options`_. + +The (AES-256-XTS, AES-256-HCTR2) pair is also a good choice that +upgrades the filenames encryption to use a wide-block cipher. (A +*wide-block cipher*, also called a tweakable super-pseudorandom +permutation, has the property that changing one bit scrambles the +entire result.) As described in `Filenames encryption`_, a wide-block +cipher is the ideal mode for the problem domain, though CTS-CBC is the +"least bad" choice among the alternatives. For more information about +HCTR2, see `the HCTR2 paper <https://eprint.iacr.org/2021/1441.pdf>`_. + +Adiantum is recommended on systems where AES is too slow due to lack +of hardware acceleration for AES. Adiantum is a wide-block cipher +that uses XChaCha12 and AES-256 as its underlying components. Most of +the work is done by XChaCha12, which is much faster than AES when AES +acceleration is unavailable. For more information about Adiantum, see +`the Adiantum paper <https://eprint.iacr.org/2018/720.pdf>`_. + +The (AES-128-CBC-ESSIV, AES-128-CTS-CBC) pair exists only to support +systems whose only form of AES acceleration is an off-CPU crypto +accelerator such as CAAM or CESA that does not support XTS. + +The remaining mode pairs are the "national pride ciphers": + +- (SM4-XTS, SM4-CTS-CBC) + +Generally speaking, these ciphers aren't "bad" per se, but they +receive limited security review compared to the usual choices such as +AES and ChaCha. They also don't bring much new to the table. It is +suggested to only use these ciphers where their use is mandated. + +Kernel config options +--------------------- + +Enabling fscrypt support (CONFIG_FS_ENCRYPTION) automatically pulls in +only the basic support from the crypto API needed to use AES-256-XTS +and AES-256-CTS-CBC encryption. For optimal performance, it is +strongly recommended to also enable any available platform-specific +kconfig options that provide acceleration for the algorithm(s) you +wish to use. Support for any "non-default" encryption modes typically +requires extra kconfig options as well. + +Below, some relevant options are listed by encryption mode. Note, +acceleration options not listed below may be available for your +platform; refer to the kconfig menus. File contents encryption can +also be configured to use inline encryption hardware instead of the +kernel crypto API (see `Inline encryption support`_); in that case, +the file contents mode doesn't need to supported in the kernel crypto +API, but the filenames mode still does. + +- AES-256-XTS and AES-256-CTS-CBC + - Recommended: + - arm64: CONFIG_CRYPTO_AES_ARM64_CE_BLK + - x86: CONFIG_CRYPTO_AES_NI_INTEL + +- AES-256-HCTR2 + - Mandatory: + - CONFIG_CRYPTO_HCTR2 + - Recommended: + - arm64: CONFIG_CRYPTO_AES_ARM64_CE_BLK + - arm64: CONFIG_CRYPTO_POLYVAL_ARM64_CE + - x86: CONFIG_CRYPTO_AES_NI_INTEL + - x86: CONFIG_CRYPTO_POLYVAL_CLMUL_NI + +- Adiantum + - 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 + +- AES-128-CBC-ESSIV and AES-128-CTS-CBC: + - Mandatory: + - CONFIG_CRYPTO_ESSIV + - CONFIG_CRYPTO_SHA256 or another SHA-256 implementation + - Recommended: + - AES-CBC acceleration + +fscrypt also uses HMAC-SHA512 for key derivation, so enabling SHA-512 +acceleration is recommended: + +- SHA-512 + - Recommended: + - arm64: CONFIG_CRYPTO_SHA512_ARM64_CE + - x86: CONFIG_CRYPTO_SHA512_SSSE3 Contents encryption ------------------- @@ -493,7 +560,14 @@ This structure must be initialized as follows: be set to constants from ``<linux/fscrypt.h>`` which identify the encryption modes to use. If unsure, use FSCRYPT_MODE_AES_256_XTS (1) for ``contents_encryption_mode`` and FSCRYPT_MODE_AES_256_CTS - (4) for ``filenames_encryption_mode``. + (4) for ``filenames_encryption_mode``. For details, see `Encryption + modes and usage`_. + + v1 encryption policies only support three combinations of modes: + (FSCRYPT_MODE_AES_256_XTS, FSCRYPT_MODE_AES_256_CTS), + (FSCRYPT_MODE_AES_128_CBC, FSCRYPT_MODE_AES_128_CTS), and + (FSCRYPT_MODE_ADIANTUM, FSCRYPT_MODE_ADIANTUM). v2 policies support + all combinations documented in `Supported modes`_. - ``flags`` contains optional flags from ``<linux/fscrypt.h>``: diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst index ede672dedf11..13e4b18e5dbb 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -38,20 +38,14 @@ fail at runtime. Use cases ========= -By itself, the base fs-verity feature only provides integrity -protection, i.e. detection of accidental (non-malicious) corruption. +By itself, fs-verity only provides integrity protection, i.e. +detection of accidental (non-malicious) corruption. However, because fs-verity makes retrieving the file hash extremely efficient, it's primarily meant to be used as a tool to support authentication (detection of malicious modifications) or auditing (logging file hashes before use). -Trusted userspace code (e.g. operating system code running on a -read-only partition that is itself authenticated by dm-verity) can -authenticate the contents of an fs-verity file by using the -`FS_IOC_MEASURE_VERITY`_ ioctl to retrieve its hash, then verifying a -digital signature of it. - A standard file hash could be used instead of fs-verity. However, this is inefficient if the file is large and only a small portion may be accessed. This is often the case for Android application package @@ -69,24 +63,31 @@ still be used on read-only filesystems. fs-verity is for files that must live on a read-write filesystem because they are independently updated and potentially user-installed, so dm-verity cannot be used. -The base fs-verity feature is a hashing mechanism only; actually -authenticating the files may be done by: - -* Userspace-only - -* Builtin signature verification + userspace policy - - fs-verity optionally supports a simple signature verification - mechanism where users can configure the kernel to require that - all fs-verity files be signed by a key loaded into a keyring; - see `Built-in signature verification`_. - -* Integrity Measurement Architecture (IMA) - - IMA supports including fs-verity file digests and signatures in the - IMA measurement list and verifying fs-verity based file signatures - stored as security.ima xattrs, based on policy. - +fs-verity does not mandate a particular scheme for authenticating its +file hashes. (Similarly, dm-verity does not mandate a particular +scheme for authenticating its block device root hashes.) Options for +authenticating fs-verity file hashes include: + +- Trusted userspace code. Often, the userspace code that accesses + files can be trusted to authenticate them. Consider e.g. an + application that wants to authenticate data files before using them, + or an application loader that is part of the operating system (which + is already authenticated in a different way, such as by being loaded + from a read-only partition that uses dm-verity) and that wants to + authenticate applications before loading them. In these cases, this + trusted userspace code can authenticate a file's contents by + retrieving its fs-verity digest using `FS_IOC_MEASURE_VERITY`_, then + verifying a signature of it using any userspace cryptographic + library that supports digital signatures. + +- Integrity Measurement Architecture (IMA). IMA supports fs-verity + file digests as an alternative to its traditional full file digests. + "IMA appraisal" enforces that files contain a valid, matching + signature in their "security.ima" extended attribute, as controlled + by the IMA policy. For more information, see the IMA documentation. + +- Trusted userspace code in combination with `Built-in signature + verification`_. This approach should be used only with great care. User API ======== @@ -111,8 +112,7 @@ follows:: }; This structure contains the parameters of the Merkle tree to build for -the file, and optionally contains a signature. It must be initialized -as follows: +the file. It must be initialized as follows: - ``version`` must be 1. - ``hash_algorithm`` must be the identifier for the hash algorithm to @@ -129,12 +129,14 @@ as follows: file or device. Currently the maximum salt size is 32 bytes. - ``salt_ptr`` is the pointer to the salt, or NULL if no salt is provided. -- ``sig_size`` is the size of the signature in bytes, or 0 if no - signature is provided. Currently the signature is (somewhat - arbitrarily) limited to 16128 bytes. See `Built-in signature - verification`_ for more information. -- ``sig_ptr`` is the pointer to the signature, or NULL if no - signature is provided. +- ``sig_size`` is the size of the builtin signature in bytes, or 0 if no + builtin signature is provided. Currently the builtin signature is + (somewhat arbitrarily) limited to 16128 bytes. +- ``sig_ptr`` is the pointer to the builtin signature, or NULL if no + builtin signature is provided. A builtin signature is only needed + if the `Built-in signature verification`_ feature is being used. It + is not needed for IMA appraisal, and it is not needed if the file + signature is being handled entirely in userspace. - All reserved fields must be zeroed. FS_IOC_ENABLE_VERITY causes the filesystem to build a Merkle tree for @@ -158,7 +160,7 @@ fatal signal), no changes are made to the file. FS_IOC_ENABLE_VERITY can fail with the following errors: - ``EACCES``: the process does not have write access to the file -- ``EBADMSG``: the signature is malformed +- ``EBADMSG``: the builtin signature is malformed - ``EBUSY``: this ioctl is already running on the file - ``EEXIST``: the file already has verity enabled - ``EFAULT``: the caller provided inaccessible memory @@ -168,10 +170,10 @@ FS_IOC_ENABLE_VERITY can fail with the following errors: reserved bits are set; or the file descriptor refers to neither a regular file nor a directory. - ``EISDIR``: the file descriptor refers to a directory -- ``EKEYREJECTED``: the signature doesn't match the file -- ``EMSGSIZE``: the salt or signature is too long -- ``ENOKEY``: the fs-verity keyring doesn't contain the certificate - needed to verify the signature +- ``EKEYREJECTED``: the builtin signature doesn't match the file +- ``EMSGSIZE``: the salt or builtin signature is too long +- ``ENOKEY``: the ".fs-verity" keyring doesn't contain the certificate + needed to verify the builtin signature - ``ENOPKG``: fs-verity recognizes the hash algorithm, but it's not available in the kernel's crypto API as currently configured (e.g. for SHA-512, missing CONFIG_CRYPTO_SHA512). @@ -180,8 +182,8 @@ FS_IOC_ENABLE_VERITY can fail with the following errors: support; or the filesystem superblock has not had the 'verity' feature enabled on it; or the filesystem does not support fs-verity on this file. (See `Filesystem support`_.) -- ``EPERM``: the file is append-only; or, a signature is required and - one was not provided. +- ``EPERM``: the file is append-only; or, a builtin signature is + required and one was not provided. - ``EROFS``: the filesystem is read-only - ``ETXTBSY``: someone has the file open for writing. This can be the caller's file descriptor, another open file descriptor, or the file @@ -270,9 +272,9 @@ This ioctl takes in a pointer to the following structure:: - ``FS_VERITY_METADATA_TYPE_DESCRIPTOR`` reads the fs-verity descriptor. See `fs-verity descriptor`_. -- ``FS_VERITY_METADATA_TYPE_SIGNATURE`` reads the signature which was - passed to FS_IOC_ENABLE_VERITY, if any. See `Built-in signature - verification`_. +- ``FS_VERITY_METADATA_TYPE_SIGNATURE`` reads the builtin signature + which was passed to FS_IOC_ENABLE_VERITY, if any. See `Built-in + signature verification`_. The semantics are similar to those of ``pread()``. ``offset`` specifies the offset in bytes into the metadata item to read from, and @@ -299,7 +301,7 @@ FS_IOC_READ_VERITY_METADATA can fail with the following errors: overflowed - ``ENODATA``: the file is not a verity file, or FS_VERITY_METADATA_TYPE_SIGNATURE was requested but the file doesn't - have a built-in signature + have a builtin signature - ``ENOTTY``: this type of filesystem does not implement fs-verity, or this ioctl is not yet implemented on it - ``EOPNOTSUPP``: the kernel was not configured with fs-verity @@ -324,6 +326,8 @@ the file has fs-verity enabled. This can perform better than FS_IOC_GETFLAGS and FS_IOC_MEASURE_VERITY because it doesn't require opening the file, and opening verity files can be expensive. +.. _accessing_verity_files: + Accessing verity files ====================== @@ -347,8 +351,8 @@ non-verity one, with the following exceptions: with EIO (for read()) or SIGBUS (for mmap() reads). - If the sysctl "fs.verity.require_signatures" is set to 1 and the - file is not signed by a key in the fs-verity keyring, then opening - the file will fail. See `Built-in signature verification`_. + file is not signed by a key in the ".fs-verity" keyring, then + opening the file will fail. See `Built-in signature verification`_. Direct access to the Merkle tree is not supported. Therefore, if a verity file is copied, or is backed up and restored, then it will lose @@ -433,20 +437,25 @@ root hash as well as other fields such as the file size:: Built-in signature verification =============================== -With CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y, fs-verity supports putting -a portion of an authentication policy (see `Use cases`_) in the -kernel. Specifically, it adds support for: +CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y adds supports for in-kernel +verification of fs-verity builtin signatures. + +**IMPORTANT**! Please take great care before using this feature. +It is not the only way to do signatures with fs-verity, and the +alternatives (such as userspace signature verification, and IMA +appraisal) can be much better. It's also easy to fall into a trap +of thinking this feature solves more problems than it actually does. + +Enabling this option adds the following: -1. At fs-verity module initialization time, a keyring ".fs-verity" is - created. The root user can add trusted X.509 certificates to this - keyring using the add_key() system call, then (when done) - optionally use keyctl_restrict_keyring() to prevent additional - certificates from being added. +1. At boot time, the kernel creates a keyring named ".fs-verity". The + root user can add trusted X.509 certificates to this keyring using + the add_key() system call. 2. `FS_IOC_ENABLE_VERITY`_ accepts a pointer to a PKCS#7 formatted detached signature in DER format of the file's fs-verity digest. - On success, this signature is persisted alongside the Merkle tree. - Then, any time the file is opened, the kernel will verify the + On success, the ioctl persists the signature alongside the Merkle + tree. Then, any time the file is opened, the kernel verifies the file's actual digest against this signature, using the certificates in the ".fs-verity" keyring. @@ -454,8 +463,8 @@ kernel. Specifically, it adds support for: When set to 1, the kernel requires that all verity files have a correctly signed digest as described in (2). -fs-verity file digests must be signed in the following format, which -is similar to the structure used by `FS_IOC_MEASURE_VERITY`_:: +The data that the signature as described in (2) must be a signature of +is the fs-verity file digest in the following format:: struct fsverity_formatted_digest { char magic[8]; /* must be "FSVerity" */ @@ -464,13 +473,66 @@ is similar to the structure used by `FS_IOC_MEASURE_VERITY`_:: __u8 digest[]; }; -fs-verity's built-in signature verification support is meant as a -relatively simple mechanism that can be used to provide some level of -authenticity protection for verity files, as an alternative to doing -the signature verification in userspace or using IMA-appraisal. -However, with this mechanism, userspace programs still need to check -that the verity bit is set, and there is no protection against verity -files being swapped around. +That's it. It should be emphasized again that fs-verity builtin +signatures are not the only way to do signatures with fs-verity. See +`Use cases`_ for an overview of ways in which fs-verity can be used. +fs-verity builtin signatures have some major limitations that should +be carefully considered before using them: + +- Builtin signature verification does *not* make the kernel enforce + that any files actually have fs-verity enabled. Thus, it is not a + complete authentication policy. Currently, if it is used, the only + way to complete the authentication policy is for trusted userspace + code to explicitly check whether files have fs-verity enabled with a + signature before they are accessed. (With + fs.verity.require_signatures=1, just checking whether fs-verity is + enabled suffices.) But, in this case the trusted userspace code + could just store the signature alongside the file and verify it + itself using a cryptographic library, instead of using this feature. + +- A file's builtin signature can only be set at the same time that + fs-verity is being enabled on the file. Changing or deleting the + builtin signature later requires re-creating the file. + +- Builtin signature verification uses the same set of public keys for + all fs-verity enabled files on the system. Different keys cannot be + trusted for different files; each key is all or nothing. + +- The sysctl fs.verity.require_signatures applies system-wide. + Setting it to 1 only works when all users of fs-verity on the system + agree that it should be set to 1. This limitation can prevent + fs-verity from being used in cases where it would be helpful. + +- Builtin signature verification can only use signature algorithms + that are supported by the kernel. For example, the kernel does not + yet support Ed25519, even though this is often the signature + algorithm that is recommended for new cryptographic designs. + +- fs-verity builtin signatures are in PKCS#7 format, and the public + keys are in X.509 format. These formats are commonly used, + including by some other kernel features (which is why the fs-verity + builtin signatures use them), and are very feature rich. + Unfortunately, history has shown that code that parses and handles + these formats (which are from the 1990s and are based on ASN.1) + often has vulnerabilities as a result of their complexity. This + complexity is not inherent to the cryptography itself. + + fs-verity users who do not need advanced features of X.509 and + PKCS#7 should strongly consider using simpler formats, such as plain + Ed25519 keys and signatures, and verifying signatures in userspace. + + fs-verity users who choose to use X.509 and PKCS#7 anyway should + still consider that verifying those signatures in userspace is more + flexible (for other reasons mentioned earlier in this document) and + eliminates the need to enable CONFIG_FS_VERITY_BUILTIN_SIGNATURES + and its associated increase in kernel attack surface. In some cases + it can even be necessary, since advanced X.509 and PKCS#7 features + do not always work as intended with the kernel. For example, the + kernel does not check X.509 certificate validity times. + + Note: IMA appraisal, which supports fs-verity, does not use PKCS#7 + for its signatures, so it partially avoids the issues discussed + here. IMA appraisal does use X.509. Filesystem support ================== diff --git a/Documentation/filesystems/gfs2-glocks.rst b/Documentation/filesystems/gfs2-glocks.rst index d14f230f0b12..8a5842929b60 100644 --- a/Documentation/filesystems/gfs2-glocks.rst +++ b/Documentation/filesystems/gfs2-glocks.rst @@ -20,8 +20,7 @@ The gl_holders list contains all the queued lock requests (not just the holders) associated with the glock. If there are any held locks, then they will be contiguous entries at the head of the list. Locks are granted in strictly the order that they -are queued, except for those marked LM_FLAG_PRIORITY which are -used only during recovery, and even then only for journal locks. +are queued. There are three lock states that users of the glock layer can request, namely shared (SH), deferred (DF) and exclusive (EX). Those translate @@ -78,7 +77,7 @@ The minimum hold time for each lock is the time after a remote lock grant for which we ignore remote demote requests. This is in order to prevent a situation where locks are being bounced around the cluster from node to node with none of the nodes making any progress. This -tends to show up most with shared mmaped files which are being written +tends to show up most with shared mmapped files which are being written to by multiple nodes. By delaying the demotion in response to a remote callback, that gives the userspace program time to make some progress before the pages are unmapped. diff --git a/Documentation/filesystems/idmappings.rst b/Documentation/filesystems/idmappings.rst index ad6d21640576..ac0af679e61e 100644 --- a/Documentation/filesystems/idmappings.rst +++ b/Documentation/filesystems/idmappings.rst @@ -36,7 +36,7 @@ and write down the mappings it will generate:: From a mathematical viewpoint ``U`` and ``K`` are well-ordered sets and an idmapping is an order isomorphism from ``U`` into ``K``. So ``U`` and ``K`` are order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of -the set of all possible ids useable on a given system. +the set of all possible ids usable on a given system. Looking at this mathematically briefly will help us highlight some properties that make it easier to understand how we can translate between idmappings. For @@ -47,7 +47,7 @@ example, we know that the inverse idmapping is an order isomorphism as well:: k10002 -> u24 Given that we are dealing with order isomorphisms plus the fact that we're -dealing with subsets we can embedd idmappings into each other, i.e. we can +dealing with subsets we can embed idmappings into each other, i.e. we can sensibly translate between different idmappings. For example, assume we've been given the three idmappings:: @@ -60,7 +60,7 @@ and id ``k11000`` which has been generated by the first idmapping by mapping Because we're dealing with order isomorphic subsets it is meaningful to ask what id ``k11000`` corresponds to in the second or third idmapping. The -straightfoward algorithm to use is to apply the inverse of the first idmapping, +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 @@ -146,9 +146,10 @@ For the rest of this document we will prefix all userspace ids with ``u`` and all kernel ids with ``k``. Ranges of idmappings will be prefixed with ``r``. So an idmapping will be written as ``u0:k10000:r10000``. -For example, the id ``u1000`` is an id in the upper idmapset or "userspace -idmapset" starting with ``u1000``. And it is mapped to ``k11000`` which is a -kernel id in the lower idmapset or "kernel idmapset" starting with ``k10000``. +For example, within this idmapping, the id ``u1000`` is an id in the upper +idmapset or "userspace idmapset" starting with ``u0``. And it is mapped to +``k11000`` which is a kernel id in the lower idmapset or "kernel idmapset" +starting with ``k10000``. A kernel id is always created by an idmapping. Such idmappings are associated with user namespaces. Since we mainly care about how idmappings work we're not @@ -367,12 +368,19 @@ So with the second step the kernel guarantees that a valid userspace id can be written to disk. If it can't the kernel will refuse the creation request to not even remotely risk filesystem corruption. -The astute reader will have realized that this is simply a varation of the +The astute reader will have realized that this is simply a variation of the crossmapping algorithm we mentioned above in a previous section. First, the kernel maps the caller's userspace id down into a kernel id according to the caller's idmapping and then maps that kernel id up according to the filesystem's idmapping. +From the implementation point it's worth mentioning how idmappings are represented. +All idmappings are taken from the corresponding user namespace. + + - caller's idmapping (usually taken from ``current_user_ns()``) + - filesystem's idmapping (``sb->s_user_ns``) + - mount's idmapping (``mnt_idmap(vfsmnt)``) + Let's see some examples with caller/filesystem idmapping but without mount idmappings. This will exhibit some problems we can hit. After that we will revisit/reconsider these examples, this time using mount idmappings, to see how @@ -458,7 +466,7 @@ the kernel id that was created in the caller's idmapping. This has mainly two consequences. First, that we can't allow a caller to ultimately write to disk with another -userspace id. We could only do this if we were to mount the whole fileystem +userspace id. We could only do this if we were to mount the whole filesystem with the caller's or another idmapping. But that solution is limited to a few filesystems and not very flexible. But this is a use-case that is pretty important in containerized workloads. @@ -589,7 +597,7 @@ on their work machine. In both cases changing ownership recursively has grave implications. The most obvious one is that ownership is changed globally and permanently. In the home -directory case this change in ownership would even need to happen everytime the +directory case this change in ownership would even need to happen every time the user switches from their home to their work machine. For really large sets of files this becomes increasingly costly. @@ -662,7 +670,7 @@ use the ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()`` helpers. To illustrate why this helper currently exists, consider what happens when we change ownership of an inode from an idmapped mount. After we generated a ``vfsuid_t`` or ``vfsgid_t`` based on the mount idmapping we later commit to -this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesytem wide ownership. +this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesystem wide ownership. Thus, we are turning the ``vfsuid_t`` or ``vfsgid_t`` into a global ``kuid_t`` or ``kgid_t``. And this can be done by using ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()``. diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index eb252fc972aa..09cade7eaefc 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -122,6 +122,7 @@ Documentation for filesystem implementations. virtiofs vfat xfs-delayed-logging-design + xfs-maintainer-entry-profile xfs-self-describing-metadata xfs-online-fsck-design zonefs diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index aa1a233b0fa8..7be2900806c8 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -85,13 +85,14 @@ prototypes:: struct dentry *dentry, struct fileattr *fa); int (*fileattr_get)(struct dentry *dentry, struct fileattr *fa); struct posix_acl * (*get_acl)(struct mnt_idmap *, struct dentry *, int); + struct offset_ctx *(*get_offset_ctx)(struct inode *inode); locking rules: all may block -============== ============================================= +============== ================================================== ops i_rwsem(inode) -============== ============================================= +============== ================================================== lookup: shared create: exclusive link: exclusive (both) @@ -115,7 +116,8 @@ atomic_open: shared (exclusive if O_CREAT is set in open flags) tmpfile: no fileattr_get: no or exclusive fileattr_set: exclusive -============== ============================================= +get_offset_ctx no +============== ================================================== Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_rwsem @@ -374,10 +376,17 @@ invalidate_lock before invalidating page cache in truncate / hole punch path (and thus calling into ->invalidate_folio) to block races between page cache invalidation and page cache filling functions (fault, read, ...). -->release_folio() is called when the kernel is about to try to drop the -buffers from the folio in preparation for freeing it. It returns false to -indicate that the buffers are (or may be) freeable. If ->release_folio is -NULL, the kernel assumes that the fs has no private interest in the buffers. +->release_folio() is called when the MM wants to make a change to the +folio that would invalidate the filesystem's private data. For example, +it may be about to be removed from the address_space or split. The folio +is locked and not under writeback. It may be dirty. The gfp parameter +is not usually used for allocation, but rather to indicate what the +filesystem may do to attempt to free the private data. The filesystem may +return false to indicate that the folio's private data cannot be freed. +If it returns true, it should have already removed the private data from +the folio. If a filesystem does not provide a ->release_folio method, +the pagecache will assume that private data is buffer_heads and call +try_to_free_buffers(). ->free_folio() is called when the kernel has dropped the folio from the page cache. @@ -509,7 +518,6 @@ prototypes:: ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); int (*iopoll) (struct kiocb *kiocb, bool spin); - int (*iterate) (struct file *, struct dir_context *); int (*iterate_shared) (struct file *, struct dir_context *); __poll_t (*poll) (struct file *, struct poll_table_struct *); long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); @@ -521,8 +529,6 @@ prototypes:: int (*fsync) (struct file *, loff_t start, loff_t end, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); - ssize_t (*sendpage) (struct file *, struct page *, int, size_t, - loff_t *, int); unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long); int (*check_flags)(int); @@ -553,9 +559,8 @@ mutex or just to use i_size_read() instead. Note: this does not protect the file->f_pos against concurrent modifications since this is something the userspace has to take care about. -->iterate() is called with i_rwsem exclusive. - -->iterate_shared() is called with i_rwsem at least shared. +->iterate_shared() is called with i_rwsem held for reading, and with the +file f_pos_lock held exclusively ->fasync() is responsible for maintaining the FASYNC bit in filp->f_flags. Most instances call fasync_helper(), which does that maintenance, so it's @@ -630,26 +635,29 @@ vm_operations_struct prototypes:: - void (*open)(struct vm_area_struct*); - void (*close)(struct vm_area_struct*); - vm_fault_t (*fault)(struct vm_area_struct*, struct vm_fault *); + void (*open)(struct vm_area_struct *); + void (*close)(struct vm_area_struct *); + vm_fault_t (*fault)(struct vm_fault *); + vm_fault_t (*huge_fault)(struct vm_fault *, unsigned int order); + vm_fault_t (*map_pages)(struct vm_fault *, pgoff_t start, pgoff_t end); vm_fault_t (*page_mkwrite)(struct vm_area_struct *, struct vm_fault *); vm_fault_t (*pfn_mkwrite)(struct vm_area_struct *, struct vm_fault *); int (*access)(struct vm_area_struct *, unsigned long, void*, int, int); locking rules: -============= ========= =========================== +============= ========== =========================== ops mmap_lock PageLocked(page) -============= ========= =========================== -open: yes -close: yes -fault: yes can return with page locked -map_pages: read -page_mkwrite: yes can return with page locked -pfn_mkwrite: yes -access: yes -============= ========= =========================== +============= ========== =========================== +open: write +close: read/write +fault: read can return with page locked +huge_fault: maybe-read +map_pages: maybe-read +page_mkwrite: read can return with page locked +pfn_mkwrite: read +access: read +============= ========== =========================== ->fault() is called when a previously not present pte is about to be faulted in. The filesystem must find and return the page associated with the passed in @@ -659,11 +667,18 @@ then ensure the page is not already truncated (invalidate_lock will block subsequent truncate), and then return with VM_FAULT_LOCKED, and the page locked. The VM will unlock the page. +->huge_fault() is called when there is no PUD or PMD entry present. This +gives the filesystem the opportunity to install a PUD or PMD sized page. +Filesystems can also use the ->fault method to return a PMD sized page, +so implementing this function may not be necessary. In particular, +filesystems should not call filemap_fault() from ->huge_fault(). +The mmap_lock may not be held when this method is called. + ->map_pages() is called when VM asks to map easy accessible pages. Filesystem should find and map pages associated with offsets from "start_pgoff" till "end_pgoff". ->map_pages() is called with the RCU lock held and must not block. If it's not possible to reach a page without blocking, -filesystem should skip it. Filesystem should use do_set_pte() to setup +filesystem should skip it. Filesystem should use set_pte_range() to setup page table entry. Pointer to entry associated with the page is passed in "pte" field in vm_fault structure. Pointers to entries for other offsets should be calculated relative to "pte". diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 73a4176144b3..48b95d04f72d 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -155,7 +155,7 @@ conflicting writes or track dirty data and needs to put the acquired folio if an error occurs after calling the helper. The helpers manage the read request, calling back into the network filesystem -through the suppplied table of operations. Waits will be performed as +through the supplied table of operations. Waits will be performed as necessary before returning for helpers that are meant to be synchronous. If an error occurs, the ->free_request() will be called to clean up the diff --git a/Documentation/filesystems/nfs/client-identifier.rst b/Documentation/filesystems/nfs/client-identifier.rst index a94c7a9748d7..4804441155f5 100644 --- a/Documentation/filesystems/nfs/client-identifier.rst +++ b/Documentation/filesystems/nfs/client-identifier.rst @@ -131,7 +131,7 @@ deployments, this construction is usually adequate. Often, however, the node name by itself is not adequately unique, and can change unexpectedly. Problematic situations include: - - NFS-root (diskless) clients, where the local DCHP server (or + - NFS-root (diskless) clients, where the local DHCP server (or equivalent) does not provide a unique host name. - "Containers" within a single Linux host. If each container has diff --git a/Documentation/filesystems/nfs/exporting.rst b/Documentation/filesystems/nfs/exporting.rst index 0e98edd353b5..4b30daee399a 100644 --- a/Documentation/filesystems/nfs/exporting.rst +++ b/Documentation/filesystems/nfs/exporting.rst @@ -122,8 +122,8 @@ are exportable by setting the s_export_op field in the struct super_block. This field must point to a "struct export_operations" struct which has the following members: - encode_fh (optional) - Takes a dentry and creates a filehandle fragment which can later be used + encode_fh (optional) + Takes a dentry and creates a filehandle fragment which may later be used to find or create a dentry for the same object. The default implementation creates a filehandle fragment that encodes a 32bit inode and generation number for the inode encoded, and if necessary the @@ -215,3 +215,29 @@ following flags are defined: This flag causes nfsd to close any open files for this inode _before_ calling into the vfs to do an unlink or a rename that would replace an existing file. + + EXPORT_OP_REMOTE_FS - Backing storage for this filesystem is remote + PF_LOCAL_THROTTLE exists for loopback NFSD, where a thread needs to + write to one bdi (the final bdi) in order to free up writes queued + to another bdi (the client bdi). Such threads get a private balance + of dirty pages so that dirty pages for the client bdi do not imact + the daemon writing to the final bdi. For filesystems whose durable + storage is not local (such as exported NFS filesystems), this + constraint has negative consequences. EXPORT_OP_REMOTE_FS enables + an export to disable writeback throttling. + + EXPORT_OP_NOATOMIC_ATTR - Filesystem does not update attributes atomically + EXPORT_OP_NOATOMIC_ATTR indicates that the exported filesystem + cannot provide the semantics required by the "atomic" boolean in + NFSv4's change_info4. This boolean indicates to a client whether the + returned before and after change attributes were obtained atomically + with the respect to the requested metadata operation (UNLINK, + OPEN/CREATE, MKDIR, etc). + + EXPORT_OP_FLUSH_ON_CLOSE - Filesystem flushes file data on close(2) + On most filesystems, inodes can remain under writeback after the + file is closed. NFSD relies on client activity or local flusher + threads to handle writeback. Certain filesystems, such as NFS, flush + all of an inode's dirty data on last close. Exports that behave this + way should set EXPORT_OP_FLUSH_ON_CLOSE so that NFSD knows to skip + waiting for writeback when closing such files. diff --git a/Documentation/filesystems/nfs/rpc-cache.rst b/Documentation/filesystems/nfs/rpc-cache.rst index bb164eea969b..339efd75016a 100644 --- a/Documentation/filesystems/nfs/rpc-cache.rst +++ b/Documentation/filesystems/nfs/rpc-cache.rst @@ -78,7 +78,7 @@ Creating a Cache include taking references to shared objects. void update(struct cache_head \*orig, struct cache_head \*new) - Set the 'content' fileds in 'new' from 'orig'. + Set the 'content' fields in 'new' from 'orig'. int cache_show(struct seq_file \*m, struct cache_detail \*cd, struct cache_head \*h) Optional. Used to provide a /proc file that lists the diff --git a/Documentation/filesystems/nfs/rpc-server-gss.rst b/Documentation/filesystems/nfs/rpc-server-gss.rst index ccaea9e7cea2..5c1a1c58fc27 100644 --- a/Documentation/filesystems/nfs/rpc-server-gss.rst +++ b/Documentation/filesystems/nfs/rpc-server-gss.rst @@ -29,7 +29,7 @@ The Linux kernel, at the moment, supports only the KRB5 mechanism, and depends on GSSAPI extensions that are KRB5 specific. GSSAPI is a complex library, and implementing it completely in kernel is -unwarranted. However GSSAPI operations are fundementally separable in 2 +unwarranted. However GSSAPI operations are fundamentally separable in 2 parts: - initial context establishment diff --git a/Documentation/filesystems/nilfs2.rst b/Documentation/filesystems/nilfs2.rst index 6c49f04e9e0a..e3a5c8977f2c 100644 --- a/Documentation/filesystems/nilfs2.rst +++ b/Documentation/filesystems/nilfs2.rst @@ -231,7 +231,7 @@ file structures (nilfs_finfo), and per block structures (nilfs_binfo):: The logs include regular files, directory files, symbolic link files -and several meta data files. The mata data files are the files used +and several meta data files. The meta data files are the files used to maintain file system meta data. The current version of NILFS2 uses the following meta data files:: diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst index f0cf05cad2ba..2b86a9b3a6de 100644 --- a/Documentation/filesystems/ntfs3.rst +++ b/Documentation/filesystems/ntfs3.rst @@ -112,7 +112,7 @@ this table marked with no it means default is without **no**. Todo list ========= - Full journaling support over JBD. Currently journal replaying is supported - which is not necessarily as effectice as JBD would be. + which is not necessarily as effective as JBD would be. References ========== diff --git a/Documentation/filesystems/ocfs2.rst b/Documentation/filesystems/ocfs2.rst index 42ca9a3d4c6e..5827062995cb 100644 --- a/Documentation/filesystems/ocfs2.rst +++ b/Documentation/filesystems/ocfs2.rst @@ -14,7 +14,7 @@ get "mount.ocfs2" and "ocfs2_hb_ctl". Project web page: http://ocfs2.wiki.kernel.org Tools git tree: https://github.com/markfasheh/ocfs2-tools -OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/ +OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html All code copyright 2005 Oracle except when otherwise noted. diff --git a/Documentation/filesystems/orangefs.rst b/Documentation/filesystems/orangefs.rst index 463e37694250..931159e61796 100644 --- a/Documentation/filesystems/orangefs.rst +++ b/Documentation/filesystems/orangefs.rst @@ -274,7 +274,7 @@ then contains: of kcalloced memory. This memory is used as an array of pointers to each of the pages in the IO buffer through a call to get_user_pages. * desc_array - a pointer to ``desc_count * (sizeof(struct orangefs_bufmap_desc))`` - bytes of kcalloced memory. This memory is further intialized: + bytes of kcalloced memory. This memory is further initialized: user_desc is the kernel's copy of the IO buffer's ORANGEFS_dev_map_desc structure. user_desc->ptr points to the IO buffer. diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index 4c76fda07645..cdefbe73d85c 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst @@ -195,7 +195,7 @@ handle it in two different ways: 1. return EXDEV error: this error is returned by rename(2) when trying to move a file or directory across filesystem boundaries. Hence - applications are usually prepared to hande this error (mv(1) for example + applications are usually prepared to handle this error (mv(1) for example recursively copies the directory tree). This is the default behavior. 2. If the "redirect_dir" feature is enabled, then the directory will be @@ -231,12 +231,11 @@ Mount options: Redirects are enabled. - "redirect_dir=follow": Redirects are not created, but followed. -- "redirect_dir=off": - Redirects are not created and only followed if "redirect_always_follow" - feature is enabled in the kernel/module config. - "redirect_dir=nofollow": - Redirects are not created and not followed (equivalent to "redirect_dir=off" - if "redirect_always_follow" feature is not enabled). + Redirects are not created and not followed. +- "redirect_dir=off": + If "redirect_always_follow" is enabled in the kernel/module config, + this "off" translates to "follow", otherwise it translates to "nofollow". When the NFS export feature is enabled, every copied up directory is indexed by the file handle of the lower inode and a file handle of the @@ -371,6 +370,88 @@ conflict with metacopy=on, and will result in an error. [*] redirect_dir=follow only conflicts with metacopy=on if upperdir=... is given. + +Data-only lower layers +---------------------- + +With "metacopy" feature enabled, an overlayfs regular file may be a composition +of information from up to three different layers: + + 1) metadata from a file in the upper layer + + 2) st_ino and st_dev object identifier from a file in a lower layer + + 3) data from a file in another lower layer (further below) + +The "lower data" file can be on any lower layer, except from the top most +lower layer. + +Below the top most lower layer, any number of lower most layers may be defined +as "data-only" lower layers, using double colon ("::") separators. +A normal lower layer is not allowed to be below a data-only layer, so single +colon separators are not allowed to the right of double colon ("::") separators. + + +For example: + + mount -t overlay overlay -olowerdir=/l1:/l2:/l3::/do1::/do2 /merged + +The paths of files in the "data-only" lower layers are not visible in the +merged overlayfs directories and the metadata and st_ino/st_dev of files +in the "data-only" lower layers are not visible in overlayfs inodes. + +Only the data of the files in the "data-only" lower layers may be visible +when a "metacopy" file in one of the lower layers above it, has a "redirect" +to the absolute path of the "lower data" file in the "data-only" lower layer. + + +fs-verity support +---------------------- + +During metadata copy up of a lower file, if the source file has +fs-verity enabled and overlay verity support is enabled, then the +digest of the lower file is added to the "trusted.overlay.metacopy" +xattr. This is then used to verify the content of the lower file +each the time the metacopy file is opened. + +When a layer containing verity xattrs is used, it means that any such +metacopy file in the upper layer is guaranteed to match the content +that was in the lower at the time of the copy-up. If at any time +(during a mount, after a remount, etc) such a file in the lower is +replaced or modified in any way, access to the corresponding file in +overlayfs will result in EIO errors (either on open, due to overlayfs +digest check, or from a later read due to fs-verity) and a detailed +error is printed to the kernel logs. For more details of how fs-verity +file access works, see :ref:`Documentation/filesystems/fsverity.rst +<accessing_verity_files>`. + +Verity can be used as a general robustness check to detect accidental +changes in the overlayfs directories in use. But, with additional care +it can also give more powerful guarantees. For example, if the upper +layer is fully trusted (by using dm-verity or something similar), then +an untrusted lower layer can be used to supply validated file content +for all metacopy files. If additionally the untrusted lower +directories are specified as "Data-only", then they can only supply +such file content, and the entire mount can be trusted to match the +upper layer. + +This feature is controlled by the "verity" mount option, which +supports these values: + +- "off": + The metacopy digest is never generated or used. This is the + default if verity option is not specified. +- "on": + Whenever a metacopy files specifies an expected digest, the + corresponding data file must match the specified digest. When + generating a metacopy file the verity digest will be set in it + based on the source file (if it has one). +- "require": + Same as "on", but additionally all metacopy files must specify a + digest (or EIO is returned on open). This means metadata copy up + will only be used if the data file has fs-verity enabled, + otherwise a full copy-up is used. + Sharing and copying layers -------------------------- @@ -576,6 +657,31 @@ can be useful in case the underlying disk is copied and the UUID of this copy is changed. This is only applicable if all lower/upper/work directories are on the same filesystem, otherwise it will fallback to normal behaviour. + +UUID and fsid +------------- + +The UUID of overlayfs instance itself and the fsid reported by statfs(2) are +controlled by the "uuid" mount option, which supports these values: + +- "null": + UUID of overlayfs is null. fsid is taken from upper most filesystem. +- "off": + UUID of overlayfs is null. fsid is taken from upper most filesystem. + UUID of underlying layers is ignored. +- "on": + UUID of overlayfs is generated and used to report a unique fsid. + UUID is stored in xattr "trusted.overlay.uuid", making overlayfs fsid + unique and persistent. This option requires an overlayfs with upper + filesystem that supports xattrs. +- "auto": (default) + UUID is taken from xattr "trusted.overlay.uuid" if it exists. + Upgrade to "uuid=on" on first time mount of new overlay filesystem that + meets the prerequites. + Downgrade to "uuid=null" for existing overlay filesystems that were never + mounted with "uuid=on". + + Volatile mount -------------- diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index d2d684ae7798..deac4e973ddc 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -177,7 +177,7 @@ settles down a bit. **mandatory** s_export_op is now required for exporting a filesystem. -isofs, ext2, ext3, resierfs, fat +isofs, ext2, ext3, reiserfs, fat can be used as examples of very different filesystems. --- @@ -470,7 +470,7 @@ has been taken to VFS and filesystems need to provide a non-NULL **mandatory** If you implement your own ->llseek() you must handle SEEK_HOLE and -SEEK_DATA. You can hanle this by returning -EINVAL, but it would be nicer to +SEEK_DATA. You can handle this by returning -EINVAL, but it would be nicer to support it in some way. The generic handler assumes that the entire file is data and there is a virtual hole at the end of the file. So if the provided offset is less than i_size and SEEK_DATA is specified, return the same offset. @@ -517,7 +517,7 @@ The witch is dead! Well, 2/3 of it, anyway. ->d_revalidate() and ->create() doesn't take ``struct nameidata *``; unlike the previous two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that -local filesystems can ignore tha argument - they are guaranteed that the +local filesystems can ignore this argument - they are guaranteed that the object doesn't exist. It's remote/distributed ones that might care... --- @@ -537,7 +537,7 @@ vfs_readdir() is gone; switch to iterate_dir() instead **mandatory** -->readdir() is gone now; switch to ->iterate() +->readdir() is gone now; switch to ->iterate_shared() **mandatory** @@ -693,24 +693,19 @@ parallel now. --- -**recommended** +**mandatory** -->iterate_shared() is added; it's a parallel variant of ->iterate(). +->iterate_shared() is added. Exclusion on struct file level is still provided (as well as that between it and lseek on the same struct file), but if your directory has been opened several times, you can get these called in parallel. Exclusion between that method and all directory-modifying ones is still provided, of course. -Often enough ->iterate() can serve as ->iterate_shared() without any -changes - it is a read-only operation, after all. If you have any -per-inode or per-dentry in-core data structures modified by ->iterate(), -you might need something to serialize the access to them. If you -do dcache pre-seeding, you'll need to switch to d_alloc_parallel() for -that; look for in-tree examples. - -Old method is only used if the new one is absent; eventually it will -be removed. Switch while you still can; the old one won't stay. +If you have any per-inode or per-dentry in-core data structures modified +by ->iterate_shared(), you might need something to serialize the access +to them. If you do dcache pre-seeding, you'll need to switch to +d_alloc_parallel() for that; look for in-tree examples. --- @@ -930,9 +925,9 @@ should be done by looking at FMODE_LSEEK in file->f_mode. filldir_t (readdir callbacks) calling conventions have changed. Instead of returning 0 or -E... it returns bool now. false means "no more" (as -E... used to) and true - "keep going" (as 0 in old calling conventions). Rationale: -callers never looked at specific -E... values anyway. ->iterate() and -->iterate_shared() instance require no changes at all, all filldir_t ones in -the tree converted. +callers never looked at specific -E... values anyway. -> iterate_shared() +instances require no changes at all, all filldir_t ones in the tree +converted. --- @@ -943,3 +938,14 @@ file pointer instead of struct dentry pointer. d_tmpfile() is similarly changed to simplify callers. The passed file is in a non-open state and on success must be opened before returning (e.g. by calling finish_open_simple()). + +--- + +**mandatory** + +Calling convention for ->huge_fault has changed. It now takes a page +order instead of an enum page_entry_size, and it may be called without the +mmap_lock held. All in-tree users have been audited and do not seem to +depend on the mmap_lock being held, but out of tree users should verify +for themselves. If they do need it, they can return VM_FAULT_RETRY to +be called with the mmap_lock held. diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 7897a7dafcbc..2b59cff8be17 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -461,6 +461,7 @@ Memory Area, or VMA) there is a series of lines such as the following:: Private_Dirty: 0 kB Referenced: 892 kB Anonymous: 0 kB + KSM: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB @@ -501,18 +502,21 @@ accessed. a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE and a page is modified, the file page is replaced by a private anonymous copy. +"KSM" reports how many of the pages are KSM pages. Note that KSM-placed zeropages +are not included, only actual KSM pages. + "LazyFree" shows the amount of memory which is marked by madvise(MADV_FREE). The memory isn't freed immediately with madvise(). It's freed in memory pressure if the memory is clean. Please note that the printed value might be lower than the real value due to optimizations used in the current implementation. If this is not desirable please file a bug report. -"AnonHugePages" shows the ammount of memory backed by transparent hugepage. +"AnonHugePages" shows the amount of memory backed by transparent hugepage. -"ShmemPmdMapped" shows the ammount of shared (shmem/tmpfs) memory backed by +"ShmemPmdMapped" shows the amount of shared (shmem/tmpfs) memory backed by huge pages. -"Shared_Hugetlb" and "Private_Hugetlb" show the ammounts of memory backed by +"Shared_Hugetlb" and "Private_Hugetlb" show the amounts of memory backed by hugetlbfs page which is *not* counted in "RSS" or "PSS" field for historical reasons. And these are not included in {Shared,Private}_{Clean,Dirty} field. @@ -561,11 +565,12 @@ encoded manner. The codes are the following: mm mixed map area hg huge page advise flag nh no huge page advise flag - mg mergable advise flag + mg mergeable advise flag bt arm64 BTI guarded page mt arm64 MTE allocation tags are enabled um userfaultfd missing tracking uw userfaultfd wr-protect tracking + ss shadow stack page == ======================================= Note that there is no guarantee that every flag and associated mnemonic will @@ -1081,7 +1086,7 @@ Writeback AnonPages Non-file backed pages mapped into userspace page tables Mapped - files which have been mmaped, such as libraries + files which have been mmapped, such as libraries Shmem Total memory used by shared memory (shmem) and tmpfs KReclaimable @@ -2229,7 +2234,7 @@ are not related to tasks. Chapter 5: Filesystem behavior ============================== -Originally, before the advent of pid namepsace, procfs was a global file +Originally, before the advent of pid namespace, procfs was a global file system. It means that there was only one procfs instance in the system. When pid namespace was added, a separate procfs instance was mounted in diff --git a/Documentation/filesystems/qnx6.rst b/Documentation/filesystems/qnx6.rst index 523b798f04e7..560f3d470422 100644 --- a/Documentation/filesystems/qnx6.rst +++ b/Documentation/filesystems/qnx6.rst @@ -135,7 +135,7 @@ inode. Character and block special devices do not exist in QNX as those files are handled by the QNX kernel/drivers and created in /dev independent of the -underlaying filesystem. +underlying filesystem. Long filenames -------------- diff --git a/Documentation/filesystems/seq_file.rst b/Documentation/filesystems/seq_file.rst index a6726082a7c2..1e1713d00010 100644 --- a/Documentation/filesystems/seq_file.rst +++ b/Documentation/filesystems/seq_file.rst @@ -130,7 +130,7 @@ called SEQ_START_TOKEN; it can be used if you wish to instruct your show() function (described below) to print a header at the top of the output. SEQ_START_TOKEN should only be used if the offset is zero, however. SEQ_START_TOKEN has no special meaning to the core seq_file -code. It is provided as a convenience for a start() funciton to +code. It is provided as a convenience for a start() function to communicate with the next() and show() functions. The next function to implement is called, amazingly, next(); its job is to @@ -217,7 +217,7 @@ between the calls to start() and stop(), so holding a lock during that time is a reasonable thing to do. The seq_file code will also avoid taking any other locks while the iterator is active. -The iterater value returned by start() or next() is guaranteed to be +The iterator value returned by start() or next() is guaranteed to be passed to a subsequent next() or stop() call. This allows resources such as locks that were taken to be reliably released. There is *no* guarantee that the iterator will be passed to show(), though in practice diff --git a/Documentation/filesystems/tmpfs.rst b/Documentation/filesystems/tmpfs.rst index f18f46be5c0c..56a26c843dbe 100644 --- a/Documentation/filesystems/tmpfs.rst +++ b/Documentation/filesystems/tmpfs.rst @@ -21,8 +21,8 @@ explained further below, some of which can be reconfigured dynamically on the fly using a remount ('mount -o remount ...') of the filesystem. A tmpfs filesystem can be resized but it cannot be resized to a size below its current usage. tmpfs also supports POSIX ACLs, and extended attributes for the -trusted.* and security.* namespaces. ramfs does not use swap and you cannot -modify any parameter for a ramfs filesystem. The size limit of a ramfs +trusted.*, security.* and user.* namespaces. ramfs does not use swap and you +cannot modify any parameter for a ramfs filesystem. The size limit of a ramfs filesystem is how much memory you have available, and so care must be taken if used so to not run out of memory. @@ -84,8 +84,6 @@ nr_inodes The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is the lower. -noswap Disables swap. Remounts must respect the original settings. - By default swap is enabled. ========= ============================================================ These parameters accept a suffix k, m or g for kilo, mega and giga and @@ -99,36 +97,65 @@ mount with such options, since it allows any user with write access to use up all the memory on the machine; but enhances the scalability of that instance in a system with many CPUs making intensive use of it. +If nr_inodes is not 0, that limited space for inodes is also used up by +extended attributes: "df -i"'s IUsed and IUse% increase, IFree decreases. + +tmpfs blocks may be swapped out, when there is a shortage of memory. +tmpfs has a mount option to disable its use of swap: + +====== =========================================================== +noswap Disables swap. Remounts must respect the original settings. + By default swap is enabled. +====== =========================================================== + tmpfs also supports Transparent Huge Pages which requires a kernel configured with CONFIG_TRANSPARENT_HUGEPAGE and with huge supported for your system (has_transparent_hugepage(), which is architecture specific). The mount options for this are: -====== ============================================================ -huge=0 never: disables huge pages for the mount -huge=1 always: enables huge pages for the mount -huge=2 within_size: only allocate huge pages if the page will be - fully within i_size, also respect fadvise()/madvise() hints. -huge=3 advise: only allocate huge pages if requested with - fadvise()/madvise() -====== ============================================================ - -There is a sysfs file which you can also use to control system wide THP -configuration for all tmpfs mounts, the file is: - -/sys/kernel/mm/transparent_hugepage/shmem_enabled - -This sysfs file is placed on top of THP sysfs directory and so is registered -by THP code. It is however only used to control all tmpfs mounts with one -single knob. Since it controls all tmpfs mounts it should only be used either -for emergency or testing purposes. The values you can set for shmem_enabled are: - -== ============================================================ --1 deny: disables huge on shm_mnt and all mounts, for - emergency use --2 force: enables huge on shm_mnt and all mounts, w/o needing - option, for testing -== ============================================================ +================ ============================================================== +huge=never Do not allocate huge pages. This is the default. +huge=always Attempt to allocate huge page every time a new page is needed. +huge=within_size Only allocate huge page if it will be fully within i_size. + Also respect madvise(2) hints. +huge=advise Only allocate huge page if requested with madvise(2). +================ ============================================================== + +See also Documentation/admin-guide/mm/transhuge.rst, which describes the +sysfs file /sys/kernel/mm/transparent_hugepage/shmem_enabled: which can +be used to deny huge pages on all tmpfs mounts in an emergency, or to +force huge pages on all tmpfs mounts for testing. + +tmpfs also supports quota with the following mount options + +======================== ================================================= +quota User and group quota accounting and enforcement + is enabled on the mount. Tmpfs is using hidden + system quota files that are initialized on mount. +usrquota User quota accounting and enforcement is enabled + on the mount. +grpquota Group quota accounting and enforcement is enabled + on the mount. +usrquota_block_hardlimit Set global user quota block hard limit. +usrquota_inode_hardlimit Set global user quota inode hard limit. +grpquota_block_hardlimit Set global group quota block hard limit. +grpquota_inode_hardlimit Set global group quota inode hard limit. +======================== ================================================= + +None of the quota related mount options can be set or changed on remount. + +Quota limit parameters accept a suffix k, m or g for kilo, mega and giga +and can't be changed on remount. Default global quota limits are taking +effect for any and all user/group/project except root the first time the +quota entry for user/group/project id is being accessed - typically the +first time an inode with a particular id ownership is being created after +the mount. In other words, instead of the limits being initialized to zero, +they are initialized with the particular value provided with these mount +options. The limits can be changed for any user/group id at any time as they +normally can be. + +Note that tmpfs quotas do not support user namespaces so no uid/gid +translation is done if quotas are enabled inside user namespaces. tmpfs has a mount option to set the NUMA memory allocation policy for all files in that instance (if CONFIG_NUMA is enabled) - which can be diff --git a/Documentation/filesystems/ubifs-authentication.rst b/Documentation/filesystems/ubifs-authentication.rst index 5210aed2afbc..3d85ee88719a 100644 --- a/Documentation/filesystems/ubifs-authentication.rst +++ b/Documentation/filesystems/ubifs-authentication.rst @@ -130,7 +130,7 @@ marked as dirty are written to the flash to update the persisted index. Journal ~~~~~~~ -To avoid wearing out the flash, the index is only persisted (*commited*) when +To avoid wearing out the flash, the index is only persisted (*committed*) when certain conditions are met (eg. ``fsync(2)``). The journal is used to record any changes (in form of inode nodes, data nodes etc.) between commits of the index. During mount, the journal is read from the flash and replayed diff --git a/Documentation/filesystems/vfat.rst b/Documentation/filesystems/vfat.rst index 760a4d83fdf9..b289c4449cd0 100644 --- a/Documentation/filesystems/vfat.rst +++ b/Documentation/filesystems/vfat.rst @@ -50,7 +50,7 @@ VFAT MOUNT OPTIONS Normally utime(2) checks current process is owner of the file, or it has CAP_FOWNER capability. But FAT filesystem doesn't have uid/gid on disk, so normal - check is too unflexible. With this option you can + check is too inflexible. With this option you can relax it. **codepage=###** diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index 769be5230210..99acc2e98673 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -260,9 +260,11 @@ filesystem. The following members are defined: void (*evict_inode) (struct inode *); void (*put_super) (struct super_block *); int (*sync_fs)(struct super_block *sb, int wait); - int (*freeze_super) (struct super_block *); + int (*freeze_super) (struct super_block *sb, + enum freeze_holder who); int (*freeze_fs) (struct super_block *); - int (*thaw_super) (struct super_block *); + int (*thaw_super) (struct super_block *sb, + enum freeze_wholder who); int (*unfreeze_fs) (struct super_block *); int (*statfs) (struct dentry *, struct kstatfs *); int (*remount_fs) (struct super_block *, int *, char *); @@ -515,6 +517,7 @@ As of kernel 2.6.22, the following members are defined: int (*fileattr_set)(struct mnt_idmap *idmap, struct dentry *dentry, struct fileattr *fa); int (*fileattr_get)(struct dentry *dentry, struct fileattr *fa); + struct offset_ctx *(*get_offset_ctx)(struct inode *inode); }; Again, all methods are called without any locks being held, unless @@ -675,7 +678,10 @@ otherwise noted. called on ioctl(FS_IOC_SETFLAGS) and ioctl(FS_IOC_FSSETXATTR) to change miscellaneous file flags and attributes. Callers hold i_rwsem exclusive. If unset, then fall back to f_op->ioctl(). - +``get_offset_ctx`` + called to get the offset context for a directory inode. A + filesystem must define this operation to use + simple_offset_dir_operations. The Address Space Object ======================== @@ -761,7 +767,7 @@ is an error during writeback, they expect that error to be reported when a file sync request is made. After an error has been reported on one request, subsequent requests on the same file descriptor should return 0, unless further writeback errors have occurred since the previous file -syncronization. +synchronization. Ideally, the kernel would report errors only on file descriptions on which writes were done that subsequently failed to be written back. The @@ -1074,7 +1080,6 @@ This describes how the VFS can manipulate an open file. As of kernel ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); int (*iopoll)(struct kiocb *kiocb, bool spin); - int (*iterate) (struct file *, struct dir_context *); int (*iterate_shared) (struct file *, struct dir_context *); __poll_t (*poll) (struct file *, struct poll_table_struct *); long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); @@ -1086,7 +1091,6 @@ This describes how the VFS can manipulate an open file. As of kernel int (*fsync) (struct file *, loff_t, loff_t, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); - ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int); unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long); int (*check_flags)(int); int (*flock) (struct file *, int, struct file_lock *); @@ -1127,12 +1131,8 @@ otherwise noted. ``iopoll`` called when aio wants to poll for completions on HIPRI iocbs -``iterate`` - called when the VFS needs to read the directory contents - ``iterate_shared`` - called when the VFS needs to read the directory contents when - filesystem supports concurrent dir iterators + called when the VFS needs to read the directory contents ``poll`` called by the VFS when a process wants to check if there is diff --git a/Documentation/filesystems/xfs-maintainer-entry-profile.rst b/Documentation/filesystems/xfs-maintainer-entry-profile.rst new file mode 100644 index 000000000000..32b6ac4ca9d6 --- /dev/null +++ b/Documentation/filesystems/xfs-maintainer-entry-profile.rst @@ -0,0 +1,194 @@ +XFS Maintainer Entry Profile +============================ + +Overview +-------- +XFS is a well known high-performance filesystem in the Linux kernel. +The aim of this project is to provide and maintain a robust and +performant filesystem. + +Patches are generally merged to the for-next branch of the appropriate +git repository. +After a testing period, the for-next branch is merged to the master +branch. + +Kernel code are merged to the xfs-linux tree[0]. +Userspace code are merged to the xfsprogs tree[1]. +Test cases are merged to the xfstests tree[2]. +Ondisk format documentation are merged to the xfs-documentation tree[3]. + +All patchsets involving XFS *must* be cc'd in their entirety to the mailing +list linux-xfs@vger.kernel.org. + +Roles +----- +There are eight key roles in the XFS project. +A person can take on multiple roles, and a role can be filled by +multiple people. +Anyone taking on a role is advised to check in with themselves and +others on a regular basis about burnout. + +- **Outside Contributor**: Anyone who sends a patch but is not involved + in the XFS project on a regular basis. + These folks are usually people who work on other filesystems or + elsewhere in the kernel community. + +- **Developer**: Someone who is familiar with the XFS codebase enough to + write new code, documentation, and tests. + + Developers can often be found in the IRC channel mentioned by the ``C:`` + entry in the kernel MAINTAINERS file. + +- **Senior Developer**: A developer who is very familiar with at least + some part of the XFS codebase and/or other subsystems in the kernel. + These people collectively decide the long term goals of the project + and nudge the community in that direction. + They should help prioritize development and review work for each release + cycle. + + Senior developers tend to be more active participants in the IRC channel. + +- **Reviewer**: Someone (most likely also a developer) who reads code + submissions to decide: + + 0. Is the idea behind the contribution sound? + 1. Does the idea fit the goals of the project? + 2. Is the contribution designed correctly? + 3. Is the contribution polished? + 4. Can the contribution be tested effectively? + + Reviewers should identify themselves with an ``R:`` entry in the kernel + and fstests MAINTAINERS files. + +- **Testing Lead**: This person is responsible for setting the test + coverage goals of the project, negotiating with developers to decide + on new tests for new features, and making sure that developers and + release managers execute on the testing. + + The testing lead should identify themselves with an ``M:`` entry in + the XFS section of the fstests MAINTAINERS file. + +- **Bug Triager**: Someone who examines incoming bug reports in just + enough detail to identify the person to whom the report should be + forwarded. + + The bug triagers should identify themselves with a ``B:`` entry in + the kernel MAINTAINERS file. + +- **Release Manager**: This person merges reviewed patchsets into an + integration branch, tests the result locally, pushes the branch to a + public git repository, and sends pull requests further upstream. + The release manager is not expected to work on new feature patchsets. + If a developer and a reviewer fail to reach a resolution on some point, + the release manager must have the ability to intervene to try to drive a + resolution. + + The release manager should identify themselves with an ``M:`` entry in + the kernel MAINTAINERS file. + +- **Community Manager**: This person calls and moderates meetings of as many + XFS participants as they can get when mailing list discussions prove + insufficient for collective decisionmaking. + They may also serve as liaison between managers of the organizations + sponsoring work on any part of XFS. + +- **LTS Maintainer**: Someone who backports and tests bug fixes from + uptream 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 + ``M:`` entry in the MAINTAINERS file for that LTS tree. + Unmaintained LTS kernels should be marked with status ``S: Orphan`` in that + same file. + +Submission Checklist Addendum +----------------------------- +Please follow these additional rules when submitting to XFS: + +- Patches affecting only the filesystem itself should be based against + the latest -rc or the for-next branch. + These patches will be merged back to the for-next branch. + +- Authors of patches touching other subsystems need to coordinate with + the maintainers of XFS and the relevant subsystems to decide how to + proceed with a merge. + +- Any patchset changing XFS should be cc'd in its entirety to linux-xfs. + Do not send partial patchsets; that makes analysis of the broader + context of the changes unnecessarily difficult. + +- Anyone making kernel changes that have corresponding changes to the + userspace utilities should send the userspace changes as separate + patchsets immediately after the kernel patchsets. + +- Authors of bug fix patches are expected to use fstests[2] to perform + an A/B test of the patch to determine that there are no regressions. + When possible, a new regression test case should be written for + fstests. + +- Authors of new feature patchsets must ensure that fstests will have + appropriate functional and input corner-case test cases for the new + feature. + +- When implementing a new feature, it is strongly suggested that the + developers write a design document to answer the following questions: + + * **What** problem is this trying to solve? + + * **Who** will benefit from this solution, and **where** will they + access it? + + * **How** will this new feature work? This should touch on major data + structures and algorithms supporting the solution at a higher level + than code comments. + + * **What** userspace interfaces are necessary to build off of the new + features? + + * **How** will this work be tested to ensure that it solves the + problems laid out in the design document without causing new + problems? + + The design document should be committed in the kernel documentation + directory. + It may be omitted if the feature is already well known to the + community. + +- Patchsets for the new tests should be submitted as separate patchsets + immediately after the kernel and userspace code patchsets. + +- Changes to the on-disk format of XFS must be described in the ondisk + format document[3] and submitted as a patchset after the fstests + patchsets. + +- Patchsets implementing bug fixes and further code cleanups should put + the bug fixes at the beginning of the series to ease backporting. + +Key Release Cycle Dates +----------------------- +Bug fixes may be sent at any time, though the release manager may decide to +defer a patch when the next merge window is close. + +Code submissions targeting the next merge window should be sent between +-rc1 and -rc6. +This gives the community time to review the changes, to suggest other changes, +and for the author to retest those changes. + +Code submissions also requiring changes to fs/iomap and targeting the +next merge window should be sent between -rc1 and -rc4. +This allows the broader kernel community adequate time to test the +infrastructure changes. + +Review Cadence +-------------- +In general, please wait at least one week before pinging for feedback. +To find reviewers, either consult the MAINTAINERS file, or ask +developers that have Reviewed-by tags for XFS changes to take a look and +offer their opinion. + +References +---------- +| [0] https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/ +| [1] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/ +| [2] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/ +| [3] https://git.kernel.org/pub/scm/fs/xfs/xfs-documentation.git/ diff --git a/Documentation/filesystems/xfs-online-fsck-design.rst b/Documentation/filesystems/xfs-online-fsck-design.rst index 791ab264b77e..1625d1131093 100644 --- a/Documentation/filesystems/xfs-online-fsck-design.rst +++ b/Documentation/filesystems/xfs-online-fsck-design.rst @@ -293,7 +293,7 @@ The seven phases are as follows: Before starting repairs, the summary counters are checked and any necessary repairs are performed so that subsequent repairs will not fail the resource reservation step due to wildly incorrect summary counters. - Unsuccesful repairs are requeued as long as forward progress on repairs is + Unsuccessful repairs are requeued as long as forward progress on repairs is made somewhere in the filesystem. Free space in the filesystem is trimmed at the end of phase 4 if the filesystem is clean. @@ -542,7 +542,7 @@ ondisk structure. Inspiration for quota and file link count repair strategies were drawn from sections 2.12 ("Online Index Operations") through 2.14 ("Incremental View -Maintenace") of G. Graefe, `"Concurrent Queries and Updates in Summary Views +Maintenance") of G. Graefe, `"Concurrent Queries and Updates in Summary Views and Their Indexes" <http://www.odbms.org/wp-content/uploads/2014/06/Increment-locks.pdf>`_, 2011. @@ -605,7 +605,7 @@ functionality. The cron job does not have this protection. - **Fuzz Kiddiez**: There are many people now who seem to think that running - automated fuzz testing of ondisk artifacts to find mischevious behavior and + automated fuzz testing of ondisk artifacts to find mischievous behavior and spraying exploit code onto the public mailing list for instant zero-day disclosure is somehow of some social benefit. In the view of this author, the benefit is realized only when the fuzz @@ -1351,7 +1351,7 @@ If the leaf information exceeds a single filesystem block, a dabtree (also rooted at block 0) is created to map hashes of the attribute names to leaf blocks in the attr fork. -Checking an extended attribute structure is not so straightfoward due to the +Checking an extended attribute structure is not so straightforward due to the lack of separation between attr blocks and index blocks. Scrub must read each block mapped by the attr fork and ignore the non-leaf blocks: @@ -1401,7 +1401,7 @@ If the free space has been separated and the second partition grows again beyond one block, then a dabtree is used to map hashes of dirent names to directory data blocks. -Checking a directory is pretty straightfoward: +Checking a directory is pretty straightforward: 1. Walk the dabtree in the second partition (if present) to ensure that there are no irregularities in the blocks or dabtree mappings that do not point to @@ -1524,7 +1524,7 @@ Only online fsck has this requirement of total consistency of AG metadata, and should be relatively rare as compared to filesystem change operations. Online fsck coordinates with transaction chains as follows: -* For each AG, maintain a count of intent items targetting that AG. +* For each AG, maintain a count of intent items targeting that AG. The count should be bumped whenever a new item is added to the chain. The count should be dropped when the filesystem has locked the AG header buffers and finished the work. @@ -2102,7 +2102,7 @@ quicksort and a heapsort subalgorithm in the spirit of kernel. To sort records in a reasonably short amount of time, ``xfarray`` takes advantage of the binary subpartitioning offered by quicksort, but it also uses -heapsort to hedge aginst performance collapse if the chosen quicksort pivots +heapsort to hedge against performance collapse if the chosen quicksort pivots are poor. Both algorithms are (in general) O(n * lg(n)), but there is a wide performance gulf between the two implementations. @@ -2566,8 +2566,8 @@ old metadata blocks: The transaction rolling in steps 2c and 3 represent a weakness in the repair algorithm, because a log flush and a crash before the end of the reap step can result in space leaking. -Online repair functions minimize the chances of this occuring by using very -large transactions, which each can accomodate many thousands of block freeing +Online repair functions minimize the chances of this occurring by using very +large transactions, which each can accommodate many thousands of block freeing instructions. Repair moves on to reaping the old blocks, which will be presented in a subsequent :ref:`section<reaping>` after a few case studies of bulk loading. @@ -5090,7 +5090,7 @@ This scan after validation of all filesystem metadata (except for the summary counters) as phase 6. The scan starts by calling ``FS_IOC_GETFSMAP`` to scan the filesystem space map to find areas that are allocated to file data fork extents. -Gaps betweeen data fork extents that are smaller than 64k are treated as if +Gaps between data fork extents that are smaller than 64k are treated as if they were data fork extents to reduce the command setup overhead. When the space map scan accumulates a region larger than 32MB, a media verification request is sent to the disk as a directio read of the raw block diff --git a/Documentation/filesystems/zonefs.rst b/Documentation/filesystems/zonefs.rst index 394b9f15dce0..c22124c2213d 100644 --- a/Documentation/filesystems/zonefs.rst +++ b/Documentation/filesystems/zonefs.rst @@ -378,7 +378,7 @@ The attributes defined are as follows. sequential zone files. Failure to do so can result in write errors. * **max_active_seq_files**: This attribute reports the maximum number of sequential zone files that are in an active state, that is, sequential zone - files that are partially writen (not empty nor full) or that have a zone that + files that are partially written (not empty nor full) or that have a zone that is explicitly open (which happens only if the *explicit-open* mount option is used). This number is always equal to the maximum number of active zones that the device supports. A value of 0 means that the mounted device has no limit diff --git a/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst b/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst index f37fc90ce340..89419e116413 100644 --- a/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst +++ b/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst @@ -5,9 +5,8 @@ Chrome OS ACPI Device ===================== Hardware functionality specific to Chrome OS is exposed through a Chrome OS ACPI device. -The plug and play ID of a Chrome OS ACPI device is GGL0001. GGL is a valid PNP ID of Google. -PNP ID can be used with the ACPI devices according to the guidelines. The following ACPI -objects are supported: +The plug and play ID of a Chrome OS ACPI device is GGL0001 and the hardware ID is +GOOG0016. The following ACPI objects are supported: .. flat-table:: Supported ACPI Objects :widths: 1 2 diff --git a/Documentation/firmware-guide/acpi/osi.rst b/Documentation/firmware-guide/acpi/osi.rst index 784850adfcb6..868a0a40bb76 100644 --- a/Documentation/firmware-guide/acpi/osi.rst +++ b/Documentation/firmware-guide/acpi/osi.rst @@ -55,7 +55,7 @@ quirk, a bug, or a bug-fix. However this was discovered to be abused by other BIOS vendors to change completely unrelated code on completely unrelated systems. This prompted -an evaluation of all of it's uses. This uncovered that they aren't needed +an evaluation of all of its uses. This uncovered that they aren't needed for any of the original reasons. As such, the kernel will not respond to any custom Linux-* strings by default. diff --git a/Documentation/gpu/amdgpu/apu-asic-info-table.csv b/Documentation/gpu/amdgpu/apu-asic-info-table.csv index 395a7b7bfaef..2e76b427ba1e 100644 --- a/Documentation/gpu/amdgpu/apu-asic-info-table.csv +++ b/Documentation/gpu/amdgpu/apu-asic-info-table.csv @@ -5,6 +5,8 @@ Ryzen 4000 series, RENOIR, DCN 2.1, 9.3, VCN 2.2, 4.1.2, 11.0.3 Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN2, DCN 1.0, 9.2.2, VCN 1.0.1, 4.1.1, 10.0.1 SteamDeck, VANGOGH, DCN 3.0.1, 10.3.1, VCN 3.1.0, 5.2.1, 11.5.0 Ryzen 5000 series / Ryzen 7x30 series, GREEN SARDINE / Cezanne / Barcelo / Barcelo-R, DCN 2.1, 9.3, VCN 2.2, 4.1.1, 12.0.1 -Ryzen 6000 series / Ryzen 7x35 series, YELLOW CARP / Rembrandt / Rembrandt+, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3, 13.0.3 +Ryzen 6000 series / Ryzen 7x35 series / Ryzen 7x36 series, YELLOW CARP / Rembrandt / Rembrandt-R, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3, 13.0.3 Ryzen 7000 series (AM5), Raphael, 3.1.5, 10.3.6, 3.1.2, 5.2.6, 13.0.5 +Ryzen 7x45 series (FL1), / Dragon Range, 3.1.5, 10.3.6, 3.1.2, 5.2.6, 13.0.5 Ryzen 7x20 series, Mendocino, 3.1.6, 10.3.7, 3.1.1, 5.2.7, 13.0.8 +Ryzen 7x40 series, Phoenix, 3.1.4, 11.0.1 / 11.0.4, 4.0.2, 6.0.1, 13.0.4 / 13.0.11
\ No newline at end of file diff --git a/Documentation/gpu/amdgpu/display/mpo-overview.rst b/Documentation/gpu/amdgpu/display/mpo-overview.rst index 0499aa92d08d..59a4f54a3ac7 100644 --- a/Documentation/gpu/amdgpu/display/mpo-overview.rst +++ b/Documentation/gpu/amdgpu/display/mpo-overview.rst @@ -178,7 +178,7 @@ Multiple Display MPO AMDGPU supports display MPO when using multiple displays; however, this feature behavior heavily relies on the compositor implementation. Keep in mind that -usespace can define different policies. For example, some OSes can use MPO to +userspace can define different policies. For example, some OSes can use MPO to protect the plane that handles the video playback; notice that we don't have many limitations for a single display. Nonetheless, this manipulation can have many more restrictions for a multi-display scenario. The below example shows a diff --git a/Documentation/gpu/amdgpu/flashing.rst b/Documentation/gpu/amdgpu/flashing.rst new file mode 100644 index 000000000000..bd745c42a538 --- /dev/null +++ b/Documentation/gpu/amdgpu/flashing.rst @@ -0,0 +1,33 @@ +======================= + dGPU firmware flashing +======================= + +IFWI +---- +Flashing the dGPU integrated firmware image (IFWI) is supported by GPUs that +use the PSP to orchestrate the update (Navi3x or newer GPUs). +For supported GPUs, `amdgpu` will export a series of sysfs files that can be +used for the flash process. + +The IFWI flash process is: + +1. Ensure the IFWI image is intended for the dGPU on the system. +2. "Write" the IFWI image to the sysfs file `psp_vbflash`. This will stage the IFWI in memory. +3. "Read" from the `psp_vbflash` sysfs file to initiate the flash process. +4. Poll the `psp_vbflash_status` sysfs file to determine when the flash process completes. + +USB-C PD F/W +------------ +On GPUs that support flashing an updated USB-C PD firmware image, the process +is done using the `usbc_pd_fw` sysfs file. + +* Reading the file will provide the current firmware version. +* Writing the name of a firmware payload stored in `/lib/firmware/amdgpu` to the sysfs file will initiate the flash process. + +The firmware payload stored in `/lib/firmware/amdgpu` can be named any name +as long as it doesn't conflict with other existing binaries that are used by +`amdgpu`. + +sysfs files +----------- +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c diff --git a/Documentation/gpu/amdgpu/index.rst b/Documentation/gpu/amdgpu/index.rst index 03c2966cae79..912e699fd373 100644 --- a/Documentation/gpu/amdgpu/index.rst +++ b/Documentation/gpu/amdgpu/index.rst @@ -10,6 +10,7 @@ Next (GCN), Radeon DNA (RDNA), and Compute DNA (CDNA) architectures. module-parameters driver-core display/index + flashing xgmi ras thermal diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst index 4411e6919a3d..c08bcbb95fb3 100644 --- a/Documentation/gpu/driver-uapi.rst +++ b/Documentation/gpu/driver-uapi.rst @@ -6,3 +6,14 @@ drm/i915 uAPI ============= .. kernel-doc:: include/uapi/drm/i915_drm.h + +drm/nouveau uAPI +================ + +VM_BIND / EXEC uAPI +------------------- + +.. kernel-doc:: drivers/gpu/drm/nouveau/nouveau_exec.c + :doc: Overview + +.. kernel-doc:: include/uapi/drm/nouveau_drm.h diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index b8ab05e42dbb..b748b8ae70b2 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -378,7 +378,7 @@ SCDC Helper Functions Reference HDMI Infoframes Helper Reference ================================ -Strictly speaking this is not a DRM helper library but generally useable +Strictly speaking this is not a DRM helper library but generally usable by any driver interfacing with HDMI outputs like v4l or alsa drivers. But it nicely fits into the overall topic of mode setting helper libraries and hence is also included here. diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index c92d425cb2dd..a0c83fc48126 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -66,11 +66,11 @@ Composition Properties`_ and related chapters. For the output routing the first step is encoders (represented by :c:type:`struct drm_encoder <drm_encoder>`, see `Encoder Abstraction`_). Those are really just internal artifacts of the helper libraries used to implement KMS -drivers. Besides that they make it unecessarily more complicated for userspace +drivers. Besides that they make it unnecessarily more complicated for userspace to figure out which connections between a CRTC and a connector are possible, and what kind of cloning is supported, they serve no purpose in the userspace API. Unfortunately encoders have been exposed to userspace, hence can't remove them -at this point. Futhermore the exposed restrictions are often wrongly set by +at this point. Furthermore the exposed restrictions are often wrongly set by drivers, and in many cases not powerful enough to express the real restrictions. A CRTC can be connected to multiple encoders, and for an active CRTC there must be at least one encoder. @@ -260,7 +260,7 @@ Taken all together there's two consequences for the atomic design: drm_crtc_state <drm_crtc_state>` for CRTCs and :c:type:`struct drm_connector_state <drm_connector_state>` for connectors. These are the only objects with userspace-visible and settable state. For internal state drivers - can subclass these structures through embeddeding, or add entirely new state + can subclass these structures through embedding, or add entirely new state structures for their globally shared hardware functions, see :c:type:`struct drm_private_state<drm_private_state>`. diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index a79fd3549ff8..c19b34b1c0ed 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -466,6 +466,42 @@ DRM MM Range Allocator Function References .. kernel-doc:: drivers/gpu/drm/drm_mm.c :export: +DRM GPU VA Manager +================== + +Overview +-------- + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Overview + +Split and Merge +--------------- + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Split and Merge + +Locking +------- + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Locking + +Examples +-------- + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Examples + +DRM GPU VA Manager Function References +-------------------------------------- + +.. kernel-doc:: include/drm/drm_gpuva_mgr.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :export: + DRM Buddy Allocator =================== @@ -481,8 +517,10 @@ DRM Cache Handling and Fast WC memcpy() .. kernel-doc:: drivers/gpu/drm/drm_cache.c :export: +.. _drm_sync_objects: + DRM Sync Objects -=========================== +================ .. kernel-doc:: drivers/gpu/drm/drm_syncobj.c :doc: Overview @@ -493,6 +531,18 @@ DRM Sync Objects .. kernel-doc:: drivers/gpu/drm/drm_syncobj.c :export: +DRM Execution context +===================== + +.. kernel-doc:: drivers/gpu/drm/drm_exec.c + :doc: Overview + +.. kernel-doc:: include/drm/drm_exec.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_exec.c + :export: + GPU Scheduler ============= diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index b46327356e80..044e6b2ed1be 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -8,7 +8,7 @@ DRM drivers can choose to export partly standardised text output via the `fops->show_fdinfo()` as part of the driver specific file operations registered in the `struct drm_driver` object registered with the DRM core. -One purpose of this output is to enable writing as generic as practicaly +One purpose of this output is to enable writing as generic as practically feasible `top(1)` like userspace monitoring tools. Given the differences between various DRM drivers the specification of the @@ -24,7 +24,7 @@ File format specification - All keys shall be prefixed with `drm-`. - Whitespace between the delimiter and first non-whitespace character shall be ignored when parsing. -- Neither keys or values are allowed to contain whitespace characters. +- Keys are not allowed to contain whitespace characters. - Numerical key value pairs can end with optional unit string. - Data type of the value is fixed as defined in the specification. @@ -39,12 +39,13 @@ Data types ---------- - <uint> - Unsigned integer without defining the maximum value. -- <str> - String excluding any above defined reserved characters or whitespace. +- <keystr> - String excluding any above defined reserved characters or whitespace. +- <valstr> - String. Mandatory fully standardised keys --------------------------------- -- drm-driver: <str> +- drm-driver: <valstr> String shall contain the name this driver registered as via the respective `struct drm_driver` data structure. @@ -52,6 +53,9 @@ String shall contain the name this driver registered as via the respective Optional fully standardised keys -------------------------------- +Identification +^^^^^^^^^^^^^^ + - drm-pdev: <aaaa:bb.cc.d> For PCI devices this should contain the PCI slot address of the device in @@ -69,10 +73,13 @@ scope of each device, in which case `drm-pdev` shall be present as well. Userspace should make sure to not double account any usage statistics by using the above described criteria in order to associate data to individual clients. -- drm-engine-<str>: <uint> ns +Utilization +^^^^^^^^^^^ + +- drm-engine-<keystr>: <uint> ns GPUs usually contain multiple execution engines. Each shall be given a stable -and unique name (str), with possible values documented in the driver specific +and unique name (keystr), with possible values documented in the driver specific documentation. Value shall be in specified time units which the respective GPU engine spent @@ -84,31 +91,19 @@ larger value within a reasonable period. Upon observing a value lower than what was previously read, userspace is expected to stay with that larger previous value until a monotonic update is seen. -- drm-engine-capacity-<str>: <uint> +- drm-engine-capacity-<keystr>: <uint> Engine identifier string must be the same as the one specified in the -drm-engine-<str> tag and shall contain a greater than zero number in case the +drm-engine-<keystr> tag and shall contain a greater than zero number in case the exported engine corresponds to a group of identical hardware engines. In the absence of this tag parser shall assume capacity of one. Zero capacity is not allowed. -- drm-memory-<str>: <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. - -Value shall reflect the amount of storage currently consumed by the buffer -object 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. - -- drm-cycles-<str> <uint> +- drm-cycles-<keystr>: <uint> Engine identifier string must be the same as the one specified in the -drm-engine-<str> tag and shall contain the number of busy cycles for the given +drm-engine-<keystr> tag and shall contain the number of busy cycles for the given engine. Values are not required to be constantly monotonic if it makes the driver @@ -117,16 +112,60 @@ larger value within a reasonable period. Upon observing a value lower than what was previously read, userspace is expected to stay with that larger previous value until a monotonic update is seen. -- drm-maxfreq-<str> <uint> [Hz|MHz|KHz] +- drm-maxfreq-<keystr>: <uint> [Hz|MHz|KHz] Engine identifier string must be the same as the one specified in the -drm-engine-<str> tag and shall contain the maximum frequency for the given -engine. Taken together with drm-cycles-<str>, this can be used to calculate -percentage utilization of the engine, whereas drm-engine-<str> only reflects +drm-engine-<keystr> tag and shall contain the maximum frequency for the given +engine. Taken together with drm-cycles-<keystr>, this can be used to calculate +percentage utilization of the engine, whereas drm-engine-<keystr> only reflects time active without considering what frequency the engine is operating as a -percentage of it's maximum frequency. +percentage of its maximum frequency. + +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. The name "memory" is reserved to refer to normal system memory. + +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. + +- drm-shared-<region>: <uint> [KiB|MiB] + +The total size of buffers that are shared with another file (ie. have more +than a single handle). + +- drm-total-<region>: <uint> [KiB|MiB] + +The total size of buffers that including shared and private memory. + +- drm-resident-<region>: <uint> [KiB|MiB] + +The total size of buffers that are resident in the specified region. + +- drm-purgeable-<region>: <uint> [KiB|MiB] + +The total size of buffers that are purgeable. + +- drm-active-<region>: <uint> [KiB|MiB] + +The total size of buffers that are active on one or more engines. + +Implementation Details +====================== + +Drivers should use drm_show_fdinfo() in their `struct file_operations`, and +implement &drm_driver.show_fdinfo if they wish to provide any stats which +are not provided by drm_show_fdinfo(). But even driver specific stats should +be documented above and where possible, aligned with other drivers. Driver specific implementations -=============================== +------------------------------- :ref:`i915-usage-stats` diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 60ea21734902..378e825754d5 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -304,10 +304,10 @@ reads of following commands. Actions issued between different contexts and the only way to synchronize across contexts (even from the same file descriptor) is through the use of fences. At least as far back as Gen4, also have that a context carries with it a GPU HW context; -the HW context is essentially (most of atleast) the state of a GPU. +the HW context is essentially (most of at least) the state of a GPU. In addition to the ordering guarantees, the kernel will restore GPU state via HW context when commands are issued to a context, this saves -user space the need to restore (most of atleast) the GPU state at the +user space the need to restore (most of at least) the GPU state at the start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1) to identify what context to use with the command. diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv index 07ed22ea3bd6..0f9590834829 100644 --- a/Documentation/gpu/kms-properties.csv +++ b/Documentation/gpu/kms-properties.csv @@ -17,7 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,De ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an X offset for a connector ,,“suggested Y”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an Y offset for a connector ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB -i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normaly in the range 0..1.0 are remapped to the range 16/255..235/255." +i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normally in the range 0..1.0 are remapped to the range 16/255..235/255." ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst index eb693c857e2d..633a016563ae 100644 --- a/Documentation/gpu/komeda-kms.rst +++ b/Documentation/gpu/komeda-kms.rst @@ -328,7 +328,7 @@ of course we’d better share as much as possible between different products. To achieve this, split the komeda device into two layers: CORE and CHIP. - CORE: for common features and capabilities handling. -- CHIP: for register programing and HW specific feature (limitation) handling. +- CHIP: for register programming and HW specific feature (limitation) handling. CORE can access CHIP by three chip function structures: @@ -481,7 +481,7 @@ Build komeda to be a Linux module driver Now we have two level devices: - komeda_dev: describes the real display hardware. -- komeda_kms_dev: attachs or connects komeda_dev to DRM-KMS. +- komeda_kms_dev: attaches or connects komeda_dev to DRM-KMS. All komeda operations are supplied or operated by komeda_dev or komeda_kms_dev, the module driver is only a simple wrapper to pass the Linux command diff --git a/Documentation/gpu/msm-crash-dump.rst b/Documentation/gpu/msm-crash-dump.rst index 240ef200f76c..9509cc4224f4 100644 --- a/Documentation/gpu/msm-crash-dump.rst +++ b/Documentation/gpu/msm-crash-dump.rst @@ -23,7 +23,7 @@ module The module that generated the crashdump. time - The kernel time at crash formated as seconds.microseconds. + The kernel time at crash formatted as seconds.microseconds. comm Comm string for the binary that generated the fault. diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst index d630f15ab795..c237ebc024cd 100644 --- a/Documentation/gpu/rfc/i915_scheduler.rst +++ b/Documentation/gpu/rfc/i915_scheduler.rst @@ -37,7 +37,7 @@ i915 with the DRM scheduler is: * Watchdog hooks into DRM scheduler * Lots of complexity of the GuC backend can be pulled out once integrated with DRM scheduler (e.g. state machine gets - simplier, locking gets simplier, etc...) + simpler, locking gets simpler, etc...) * Execlists backend will minimum required to hook in the DRM scheduler * Legacy interface * Features like timeslicing / preemption / virtual engines would @@ -135,9 +135,13 @@ Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and drm_i915_context_engines_parallel_submit to the uAPI to implement this extension. +.. c:namespace-push:: rfc + .. kernel-doc:: include/uapi/drm/i915_drm.h :functions: i915_context_engines_parallel_submit +.. c:namespace-pop:: + Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL ------------------------------------------------------------------- Contexts that have been configured with the 'set_parallel' extension can only diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst index 9a1dcdf2799e..0b3b525ac620 100644 --- a/Documentation/gpu/rfc/i915_vm_bind.rst +++ b/Documentation/gpu/rfc/i915_vm_bind.rst @@ -90,7 +90,7 @@ submission, they need only one dma-resv fence list updated. Thus, the fast path (where required mappings are already bound) submission latency is O(1) w.r.t the number of VM private BOs. -VM_BIND locking hirarchy +VM_BIND locking hierarchy ------------------------- The locking design here supports the older (execlist based) execbuf mode, the newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index 476719771eef..e4f7b005138d 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -31,3 +31,7 @@ host such documentation: .. toctree:: i915_vm_bind.rst + +.. toctree:: + + xe.rst diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst new file mode 100644 index 000000000000..2516fe141db6 --- /dev/null +++ b/Documentation/gpu/rfc/xe.rst @@ -0,0 +1,235 @@ +========================== +Xe – Merge Acceptance Plan +========================== +Xe is a new driver for Intel GPUs that supports both integrated and +discrete platforms starting with Tiger Lake (first Intel Xe Architecture). + +This document aims to establish a merge plan for the Xe, by writing down clear +pre-merge goals, in order to avoid unnecessary delays. + +Xe – Overview +============= +The main motivation of Xe is to have a fresh base to work from that is +unencumbered by older platforms, whilst also taking the opportunity to +rearchitect our driver to increase sharing across the drm subsystem, both +leveraging and allowing us to contribute more towards other shared components +like TTM and drm/scheduler. + +This is also an opportunity to start from the beginning with a clean uAPI that is +extensible by design and already aligned with the modern userspace needs. For +this reason, the memory model is solely based on GPU Virtual Address space +bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only supporting +explicit synchronization. With persistent mapping across the execution, the +userspace does not need to provide a list of all required mappings during each +submission. + +The new driver leverages a lot from i915. As for display, the intent is to share +the display code with the i915 driver so that there is maximum reuse there. + +As for the power management area, the goal is to have a much-simplified support +for the system suspend states (S-states), PCI device suspend states (D-states), +GPU/Render suspend states (R-states) and frequency management. It should leverage +as much as possible all the existent PCI-subsystem infrastructure (pm and +runtime_pm) and underlying firmware components such PCODE and GuC for the power +states and frequency decisions. + +Repository: + +https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next) + +Xe – Platforms +============== +Currently, Xe is already functional and has experimental support for multiple +platforms starting from Tiger Lake, with initial support in userspace implemented +in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO +(for OpenCL and Level0). + +During a transition period, platforms will be supported by both Xe and i915. +However, the force_probe mechanism existent in both drivers will allow only one +official and by-default probe at a given time. + +For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of +i915, the following set of parameters need to be used: + +``` +i915.force_probe=!5690 xe.force_probe=5690 +``` + +In both drivers, the ‘.require_force_probe’ protection forces the user to use the +force_probe parameter while the driver is under development. This protection is +only removed when the support for the platform and the uAPI are stable. Stability +which needs to be demonstrated by CI results. + +In order to avoid user space regressions, i915 will continue to support all the +current platforms that are already out of this protection. Xe support will be +forever experimental and dependent on the usage of force_probe for these +platforms. + +When the time comes for Xe, the protection will be lifted on Xe and kept in i915. + +Xe driver will be protected with both STAGING Kconfig and force_probe. Changes in +the uAPI are expected while the driver is behind these protections. STAGING will +be removed when the driver uAPI gets to a mature state where we can guarantee the +‘no regression’ rule. Then force_probe will be lifted only for future platforms +that will be productized with Xe driver, but not with i915. + +Xe – Pre-Merge Goals +==================== + +Drm_scheduler +------------- +Xe primarily uses Firmware based scheduling (GuC FW). However, it will use +drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to +resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is +not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and +drm_sched_entity. + +Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but +some consensus needs to be reached between Xe and other community drivers that +could also benefit from this work, for coupling FW based/assisted submission such +as the ARM’s new Mali GPU driver, and others. + +As a key measurable result, the patch series introducing Xe itself shall not +depend on any other patch touching drm_scheduler itself that was not yet merged +through drm-misc. This, by itself, already includes the reach of an agreement for +uniform 1 to 1 relationship implementation / usage across drivers. + +GPU VA +------ +Two main goals of Xe are meeting together here: + +1) Have an uAPI that aligns with modern UMD needs. + +2) Early upstream engagement. + +RedHat engineers working on Nouveau proposed a new DRM feature to handle keeping +track of GPU virtual address mappings. This is still not merged upstream, but +this aligns very well with our goals and with our VM_BIND. The engagement with +upstream and the port of Xe towards GPUVA is already ongoing. + +As a key measurable result, Xe needs to be aligned with the GPU VA and working in +our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA +related patch should be independent and present on dri-devel or acked by +maintainers to go along with the first Xe pull request towards drm-next. + +DRM_VM_BIND +----------- +Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to +fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the +development of a common new drm_infrastructure. However, the Xe team needs to +engage with the community to explore the options of a common API. + +As a key measurable result, the DRM_VM_BIND needs to be documented in this file +below, or this entire block deleted if the consensus is for independent drivers +vm_bind ioctls. + +Although having a common DRM level IOCTL for VM_BIND is not a requirement to get +Xe merged, it is mandatory to enforce the overall locking scheme for all major +structs and list (so vm and vma). So, a consensus is needed, and possibly some +common helpers. If helpers are needed, they should be also documented in this +document. + +ASYNC VM_BIND +------------- +Although having a common DRM level IOCTL for VM_BIND is not a requirement to get +Xe merged, it is mandatory to have a consensus with other drivers and Mesa. +It needs to be clear how to handle async VM_BIND and interactions with userspace +memory fences. Ideally with helper support so people don't get it wrong in all +possible ways. + +As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of +various flavors, error handling and a sample API should be documented here or in +a separate document pointed to by this document. + +Userptr integration and vm_bind +------------------------------- +Different drivers implement different ways of dealing with execution of userptr. +With multiple drivers currently introducing support to VM_BIND, the goal is to +aim for a DRM consensus on what’s the best way to have that support. To some +extent this is already getting addressed itself with the GPUVA where likely the +userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr. +However, there are more aspects around the rules for that and the usage of +mmu_notifiers, locking and other aspects. + +This task here has the goal of introducing a documentation of the basic rules. + +The documentation *needs* to first live in this document (API session below) and +then moved to another more specific document or at Xe level or at DRM level. + +Documentation should include: + + * The userptr part of the VM_BIND api. + + * Locking, including the page-faulting case. + + * O(1) complexity under VM_BIND. + +Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when +the second driver supporting VM_BIND+userptr appears. Details to be defined when +the time comes. + +Long running compute: minimal data structure/scaffolding +-------------------------------------------------------- +The generic scheduler code needs to include the handling of endless compute +contexts, with the minimal scaffolding for preempt-ctx fences (probably on the +drm_sched_entity) and making sure drm_scheduler can cope with the lack of job +completion fence. + +The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with +this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any +drm driver, including Xe, could re-use and add their own individual needs on top +in a next stage. However, this should not block the initial merge. + +This is a non-blocker item since the driver without the support for the long +running compute enabled is not a showstopper. + +Display integration with i915 +----------------------------- +In order to share the display code with the i915 driver so that there is maximum +reuse, the i915/display/ code is built twice, once for i915.ko and then for +xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs' +depending on the build target. The goal is to refactor both Xe and i915/display +code simultaneously in order to get a clean result before they land upstream, so +that display can already be part of the initial pull request towards drm-next. + +However, display code should not gate the acceptance of Xe in upstream. Xe +patches will be refactored in a way that display code can be removed, if needed, +from the first pull request of Xe towards drm-next. The expectation is that when +both drivers are part of the drm-tip, the introduction of cleaner patches will be +easier and speed up. + +Drm_exec +-------- +Helper to make dma_resv locking for a big number of buffers is getting removed in +the drm_exec series proposed in https://patchwork.freedesktop.org/patch/524376/ +If that happens, Xe needs to change and incorporate the changes in the driver. +The goal is to engage with the Community to understand if the best approach is to +move that to the drivers that are using it or if we should keep the helpers in +place waiting for Xe to get merged. + +This item ties into the GPUVA, VM_BIND, and even long-running compute support. + +As a key measurable result, we need to have a community consensus documented in +this document and the Xe driver prepared for the changes, if necessary. + +Dev_coredump +------------ + +Xe needs to align with other drivers on the way that the error states are +dumped, avoiding a Xe only error_state solution. The goal is to use devcoredump +infrastructure to report error states, since it produces a standardized way +by exposing a virtual and temporary /sys/class/devcoredump device. + +As the key measurable result, Xe driver needs to provide GPU snapshots captured +at hang time through devcoredump, but without depending on any core modification +of devcoredump infrastructure itself. + +Later, when we are in-tree, the goal is to collaborate with devcoredump +infrastructure with overall possible improvements, like multiple file support +for better organization of the dumps, snapshot support, dmesg extra print, +and whatever may make sense and help the overall infrastructure. + +Xe – uAPI high level overview +============================= + +...Warning: To be done in follow up patches after/when/where the main consensus in various items are individually reached. diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 1f8a5ebe188e..03fe5d1247be 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -49,14 +49,18 @@ converted over. Modern compositors like Wayland or Surfaceflinger on Android really want an atomic modeset interface, so this is all about the bright future. -There is a conversion guide for atomic and all you need is a GPU for a -non-converted driver (again virtual HW drivers for KVM are still all -suitable). +There is a conversion guide for atomic [1]_ and all you need is a GPU for a +non-converted driver. The "Atomic mode setting design overview" series [2]_ +[3]_ at LWN.net can also be helpful. As part of this drivers also need to convert to universal plane (which means exposing primary & cursor as proper plane objects). But that's much easier to do by directly using the new atomic helper driver callbacks. + .. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html + .. [2] https://lwn.net/Articles/653071/ + .. [3] https://lwn.net/Articles/653466/ + Contact: Daniel Vetter, respective driver maintainers Level: Advanced @@ -65,7 +69,7 @@ Clean up the clipped coordination confusion around planes --------------------------------------------------------- We have a helper to get this right with drm_plane_helper_check_update(), but -it's not consistently used. This should be fixed, preferrably in the atomic +it's not consistently used. This should be fixed, preferably in the atomic helpers (and drivers then moved over to clipped coordinates). Probably the helper should also be moved from drm_plane_helper.c to the atomic helpers, to avoid confusion - the other helpers in that file are all deprecated legacy @@ -181,13 +185,13 @@ reversed. To solve this we need one standard per-object locking mechanism, which is dma_resv_lock(). This lock needs to be called as the outermost lock, with all -other driver specific per-object locks removed. The problem is tha rolling out +other driver specific per-object locks removed. The problem is that rolling out the actual change to the locking contract is a flag day, due to struct dma_buf buffer sharing. Level: Expert -Convert logging to drm_* functions with drm_device paramater +Convert logging to drm_* functions with drm_device parameter ------------------------------------------------------------ For drivers which could have multiple instances, it is necessary to @@ -244,7 +248,7 @@ Level: Advanced Benchmark and optimize blitting and format-conversion function -------------------------------------------------------------- -Drawing to dispay memory quickly is crucial for many applications' +Drawing to display memory quickly is crucial for many applications' performance. On at least x86-64, sys_imageblit() is significantly slower than @@ -276,11 +280,8 @@ Various hold-ups: - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb setup code can't be deleted. -- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For - atomic drivers we could check for valid formats by calling - drm_plane_check_pixel_format() against all planes, and pass if any plane - supports the format. For non-atomic that's not possible since like the format - list for the primary plane is fake and we'd therefor reject valid formats. +- Need to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for + valid formats for atomic drivers. - Many drivers subclass drm_framebuffer, we'd need a embedding compatible version of the varios drm_gem_fb_create functions. Maybe called @@ -322,15 +323,6 @@ Contact: Daniel Vetter, Noralf Tronnes Level: Advanced -struct drm_gem_object_funcs ---------------------------- - -GEM objects can now have a function table instead of having the callbacks on the -DRM driver struct. This is now the preferred way. Callbacks in drivers have been -converted, except for struct drm_driver.gem_prime_mmap. - -Level: Intermediate - connector register/unregister fixes ----------------------------------- @@ -455,6 +447,44 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de> Level: Starter +Remove driver dependencies on FB_DEVICE +--------------------------------------- + +A number of fbdev drivers provide attributes via sysfs and therefore depend +on CONFIG_FB_DEVICE to be selected. Review each driver and attempt to make +any dependencies on CONFIG_FB_DEVICE optional. At the minimum, the respective +code in the driver could be conditionalized via ifdef CONFIG_FB_DEVICE. Not +all drivers might be able to drop CONFIG_FB_DEVICE. + +Contact: Thomas Zimmermann <tzimmermann@suse.de> + +Level: Starter + +Clean up checks for already prepared/enabled in panels +------------------------------------------------------ + +In a whole pile of panel drivers, we have code to make the +prepare/unprepare/enable/disable callbacks behave as no-ops if they've already +been called. To get some idea of the duplicated code, try:: + + git grep 'if.*>prepared' -- drivers/gpu/drm/panel + git grep 'if.*>enabled' -- drivers/gpu/drm/panel + +In the patch ("drm/panel: Check for already prepared/enabled in drm_panel") +we've moved this check to the core. Now we can most definitely remove the +check from the individual panels and save a pile of code. + +In adition to removing the check from the individual panels, it is believed +that even the core shouldn't need this check and that should be considered +an error if other code ever relies on this check. The check in the core +currently prints a warning whenever something is relying on this check with +dev_warn(). After a little while, we likely want to promote this to a +WARN(1) to help encourage folks not to rely on this behavior. + +Contact: Douglas Anderson <dianders@chromium.org> + +Level: Starter/Intermediate + Core refactorings ================= @@ -752,16 +782,16 @@ existing hardware. The new driver's call-back functions are filled from existing fbdev code. More complex fbdev drivers can be refactored step-by-step into a DRM -driver with the help of the DRM fbconv helpers. [1] These helpers provide +driver with the help of the DRM fbconv helpers [4]_. These helpers provide the transition layer between the DRM core infrastructure and the fbdev driver interface. Create a new DRM driver on top of the fbconv helpers, copy over the fbdev driver, and hook it up to the DRM code. Examples for -several fbdev drivers are available at [1] and a tutorial of this process -available at [2]. The result is a primitive DRM driver that can run X11 -and Weston. +several fbdev drivers are available in Thomas Zimmermann's fbconv tree +[4]_, as well as a tutorial of this process [5]_. The result is a primitive +DRM driver that can run X11 and Weston. - - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv - - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c + .. [4] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv + .. [5] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c Contact: Thomas Zimmermann <tzimmermann@suse.de> diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 49db221c0f52..ba04ac7c2167 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -118,14 +118,9 @@ Add Plane Features There's lots of plane features we could add support for: -- ARGB format on primary plane: blend the primary plane into background with - translucent alpha. - - Add background color KMS property[Good to get started]. -- Full alpha blending on all planes. - -- Rotation, scaling. +- Scaling. - Additional buffer formats, especially YUV formats for video like NV12. Low/high bpp RGB formats would also be interesting. diff --git a/Documentation/hid/hidintro.rst b/Documentation/hid/hidintro.rst new file mode 100644 index 000000000000..73523e315ebd --- /dev/null +++ b/Documentation/hid/hidintro.rst @@ -0,0 +1,524 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +Introduction to HID report descriptors +====================================== + +This chapter is meant to give a broad overview of what HID report +descriptors are, and of how a casual (non-kernel) programmer can deal +with HID devices that are not working well with Linux. + +.. contents:: + :local: + :depth: 2 + +.. toctree:: + :maxdepth: 2 + + hidreport-parsing + + +Introduction +============ + +HID stands for Human Interface Device, and can be whatever device you +are using to interact with a computer, be it a mouse, a touchpad, a +tablet, a microphone. + +Many HID devices work out the box, even if their hardware is different. +For example, mice can have any number of buttons; they may have a +wheel; movement sensitivity differs between different models, and so +on. Nonetheless, most of the time everything just works, without the +need to have specialized code in the kernel for every mouse model +developed since 1970. + +This is because modern HID devices do advertise their capabilities +through the *HID report descriptor*, a fixed set of bytes describing +exactly what *HID reports* may be sent between the device and the host +and the meaning of each individual bit in those reports. For example, +a HID Report Descriptor may specify that "in a report with ID 3 the +bits from 8 to 15 is the delta x coordinate of a mouse". + +The HID report itself then merely carries the actual data values +without any extra meta information. Note that HID reports may be sent +from the device ("Input Reports", i.e. input events), to the device +("Output Reports" to e.g. change LEDs) or used for device configuration +("Feature reports"). A device may support one or more HID reports. + +The HID subsystem is in charge of parsing the HID report descriptors, +and converts HID events into normal input device interfaces (see +Documentation/hid/hid-transport.rst). Devices may misbehave because the +HID report descriptor provided by the device is wrong, or because it +needs to be dealt with in a special way, or because some special +device or interaction mode is not handled by the default code. + +The format of HID report descriptors is described by two documents, +available from the `USB Implementers Forum <https://www.usb.org/>`_ +`HID web page <https://www.usb.org/hid>`_ address: + + * the `HID USB Device Class Definition + <https://www.usb.org/document-library/device-class-definition-hid-111>`_ (HID Spec from now on) + * the `HID Usage Tables <https://usb.org/document-library/hid-usage-tables-14>`_ (HUT from now on) + +The HID subsystem can deal with different transport drivers +(USB, I2C, Bluetooth, etc.). See Documentation/hid/hid-transport.rst. + +Parsing HID report descriptors +============================== + +The current list of HID devices can be found at ``/sys/bus/hid/devices/``. +For each device, say ``/sys/bus/hid/devices/0003\:093A\:2510.0002/``, +one can read the corresponding report descriptor:: + + $ hexdump -C /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor + 00000000 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 |..............).| + 00000010 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 |..%.u.....u.....| + 00000020 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 |...0.1.8..%.u...| + 00000030 81 06 c0 c0 |....| + 00000034 + +Optional: the HID report descriptor can be read also by +directly accessing the hidraw driver [#hidraw]_. + +The basic structure of HID report descriptors is defined in the HID +spec, while HUT "defines constants that can be interpreted by an +application to identify the purpose and meaning of a data field in a +HID report". Each entry is defined by at least two bytes, where the +first one defines what type of value is following and is described in +the HID spec, while the second one carries the actual value and is +described in the HUT. + +HID report descriptors can, in principle, be painstakingly parsed by +hand, byte by byte. + +A short introduction on how to do this is sketched in +Documentation/hid/hidreport-parsing.rst; you only need to understand it +if you need to patch HID report descriptors. + +In practice you should not parse HID report descriptors by hand; rather, +you should use an existing parser. Among all the available ones + + * the online `USB Descriptor and Request Parser + <http://eleccelerator.com/usbdescreqparser/>`_; + * `hidrdd <https://github.com/abend0c1/hidrdd>`_, + that provides very detailed and somewhat verbose descriptions + (verbosity can be useful if you are not familiar with HID report + descriptors); + * `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_, + a complete utility set that allows, among other things, + to record and replay the raw HID reports and to debug + and replay HID devices. + It is being actively developed by the Linux HID subsystem maintainers. + +Parsing the mouse HID report descriptor with `hid-tools +<https://gitlab.freedesktop.org/libevdev/hid-tools>`_ leads to +(explanations interposed):: + + $ ./hid-decode /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor + # device 0:0 + # 0x05, 0x01, // Usage Page (Generic Desktop) 0 + # 0x09, 0x02, // Usage (Mouse) 2 + # 0xa1, 0x01, // Collection (Application) 4 + # 0x09, 0x01, // Usage (Pointer) 6 + # 0xa1, 0x00, // Collection (Physical) 8 + # 0x05, 0x09, // Usage Page (Button) 10 + +what follows is a button :: + + # 0x19, 0x01, // Usage Minimum (1) 12 + # 0x29, 0x03, // Usage Maximum (3) 14 + +first button is button number 1, last button is button number 3 :: + + # 0x15, 0x00, // Logical Minimum (0) 16 + # 0x25, 0x01, // Logical Maximum (1) 18 + +each button can send values from 0 up to including 1 +(i.e. they are binary buttons) :: + + # 0x75, 0x01, // Report Size (1) 20 + +each button is sent as exactly one bit :: + + # 0x95, 0x03, // Report Count (3) 22 + +and there are three of those bits (matching the three buttons) :: + + # 0x81, 0x02, // Input (Data,Var,Abs) 24 + +it's actual Data (not constant padding), they represent +a single variable (Var) and their values are Absolute (not relative); +See HID spec Sec. 6.2.2.5 "Input, Output, and Feature Items" :: + + # 0x75, 0x05, // Report Size (5) 26 + +five additional padding bits, needed to reach a byte :: + + # 0x95, 0x01, // Report Count (1) 28 + +those five bits are repeated only once :: + + # 0x81, 0x01, // Input (Cnst,Arr,Abs) 30 + +and take Constant (Cnst) values i.e. they can be ignored. :: + + # 0x05, 0x01, // Usage Page (Generic Desktop) 32 + # 0x09, 0x30, // Usage (X) 34 + # 0x09, 0x31, // Usage (Y) 36 + # 0x09, 0x38, // Usage (Wheel) 38 + +The mouse has also two physical positions (Usage (X), Usage (Y)) +and a wheel (Usage (Wheel)) :: + + # 0x15, 0x81, // Logical Minimum (-127) 40 + # 0x25, 0x7f, // Logical Maximum (127) 42 + +each of them can send values ranging from -127 up to including 127 :: + + # 0x75, 0x08, // Report Size (8) 44 + +which is represented by eight bits :: + + # 0x95, 0x03, // Report Count (3) 46 + +and there are three of those eight bits, matching X, Y and Wheel. :: + + # 0x81, 0x06, // Input (Data,Var,Rel) 48 + +This time the data values are Relative (Rel), i.e. they represent +the change from the previously sent report (event) :: + + # 0xc0, // End Collection 50 + # 0xc0, // End Collection 51 + # + R: 52 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 c0 c0 + N: device 0:0 + I: 3 0001 0001 + + +This Report Descriptor tells us that the mouse input will be +transmitted using four bytes: the first one for the buttons (three +bits used, five for padding), the last three for the mouse X, Y and +wheel changes, respectively. + +Indeed, for any event, the mouse will send a *report* of four bytes. +We can check the values sent by resorting e.g. to the `hid-recorder` +tool, from `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_: +The sequence of bytes sent by clicking and releasing button 1, then button 2, then button 3 is:: + + $ sudo ./hid-recorder /dev/hidraw1 + + .... + output of hid-decode + .... + + # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0 + E: 000000.000000 4 01 00 00 00 + # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0 + E: 000000.183949 4 00 00 00 00 + # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0 + E: 000001.959698 4 02 00 00 00 + # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0 + E: 000002.103899 4 00 00 00 00 + # Button: 0 0 1 | # | X: 0 | Y: 0 | Wheel: 0 + E: 000004.855799 4 04 00 00 00 + # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0 + E: 000005.103864 4 00 00 00 00 + +This example shows that when button 2 is clicked, +the bytes ``02 00 00 00`` are sent, and the immediately subsequent +event (``00 00 00 00``) is the release of button 2 (no buttons are +pressed, remember that the data values are *absolute*). + +If instead one clicks and holds button 1, then clicks and holds button +2, releases button 1, and finally releases button 2, the reports are:: + + # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0 + E: 000044.175830 4 01 00 00 00 + # Button: 1 1 0 | # | X: 0 | Y: 0 | Wheel: 0 + E: 000045.975997 4 03 00 00 00 + # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0 + E: 000047.407930 4 02 00 00 00 + # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0 + E: 000049.199919 4 00 00 00 00 + +where with ``03 00 00 00`` both buttons are pressed, and with the +subsequent ``02 00 00 00`` button 1 is released while button 2 is still +active. + +Output, Input and Feature Reports +--------------------------------- + +HID devices can have Input Reports, like in the mouse example, Output +Reports, and Feature Reports. "Output" means that the information is +sent to the device. For example, a joystick with force feedback will +have some output; the led of a keyboard would need an output as well. +"Input" means that data come from the device. + +"Feature"s are not meant to be consumed by the end user and define +configuration options for the device. They can be queried from the host; +when declared as *Volatile* they should be changed by the host. + + +Collections, Report IDs and Evdev events +======================================== + +A single device can logically group data into different independent +sets, called a *Collection*. Collections can be nested and there are +different types of collections (see the HID spec 6.2.2.6 +"Collection, End Collection Items" for details). + +Different reports are identified by means of different *Report ID* +fields, i.e. a number identifying the structure of the immediately +following report. +Whenever a Report ID is needed it is transmitted as the first byte of +any report. A device with only one supported HID report (like the mouse +example above) may omit the report ID. + +Consider the following HID report descriptor:: + + 05 01 09 02 A1 01 85 01 05 09 19 01 29 05 15 00 + 25 01 95 05 75 01 81 02 95 01 75 03 81 01 05 01 + 09 30 09 31 16 00 F8 26 FF 07 75 0C 95 02 81 06 + 09 38 15 80 25 7F 75 08 95 01 81 06 05 0C 0A 38 + 02 15 80 25 7F 75 08 95 01 81 06 C0 05 01 09 02 + A1 01 85 02 05 09 19 01 29 05 15 00 25 01 95 05 + 75 01 81 02 95 01 75 03 81 01 05 01 09 30 09 31 + 16 00 F8 26 FF 07 75 0C 95 02 81 06 09 38 15 80 + 25 7F 75 08 95 01 81 06 05 0C 0A 38 02 15 80 25 + 7F 75 08 95 01 81 06 C0 05 01 09 07 A1 01 85 05 + 05 07 15 00 25 01 09 29 09 3E 09 4B 09 4E 09 E3 + 09 E8 09 E8 09 E8 75 01 95 08 81 02 95 00 81 01 + C0 05 0C 09 01 A1 01 85 06 15 00 25 01 75 01 95 + 01 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81 + 06 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81 + 06 C0 05 0C 09 01 A1 01 85 03 09 05 15 00 26 FF + 00 75 08 95 02 B1 02 C0 + +After parsing it (try to parse it on your own using the suggested +tools!) one can see that the device presents two ``Mouse`` Application +Collections (with reports identified by Reports IDs 1 and 2, +respectively), a ``Keypad`` Application Collection (whose report is +identified by the Report ID 5) and two ``Consumer Controls`` Application +Collections, (with Report IDs 6 and 3, respectively). Note, however, +that a device can have different Report IDs for the same Application +Collection. + +The data sent will begin with the Report ID byte, and will be followed +by the corresponding information. For example, the data transmitted for +the last consumer control:: + + 0x05, 0x0C, // Usage Page (Consumer) + 0x09, 0x01, // Usage (Consumer Control) + 0xA1, 0x01, // Collection (Application) + 0x85, 0x03, // Report ID (3) + 0x09, 0x05, // Usage (Headphone) + 0x15, 0x00, // Logical Minimum (0) + 0x26, 0xFF, 0x00, // Logical Maximum (255) + 0x75, 0x08, // Report Size (8) + 0x95, 0x02, // Report Count (2) + 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) + 0xC0, // End Collection + +will be of three bytes: the first for the Report ID (3), the next two +for the headphone, with two (``Report Count (2)``) bytes +(``Report Size (8)``), each ranging from 0 (``Logical Minimum (0)``) +to 255 (``Logical Maximum (255)``). + +All the Input data sent by the device should be translated into +corresponding Evdev events, so that the remaining part of the stack can +know what is going on, e.g. the bit for the first button translates into +the ``EV_KEY/BTN_LEFT`` evdev event and relative X movement translates +into the ``EV_REL/REL_X`` evdev event". + +Events +====== + +In Linux, one ``/dev/input/event*`` is created for each ``Application +Collection``. Going back to the mouse example, and repeating the +sequence where one clicks and holds button 1, then clicks and holds +button 2, releases button 1, and finally releases button 2, one gets:: + + $ sudo libinput record /dev/input/event1 + # libinput record + version: 1 + ndevices: 1 + libinput: + version: "1.23.0" + git: "unknown" + system: + os: "opensuse-tumbleweed:20230619" + kernel: "6.3.7-1-default" + dmi: "dmi:bvnHP:bvrU77Ver.01.05.00:bd03/24/2022:br5.0:efr20.29:svnHP:pnHPEliteBook64514inchG9NotebookPC:pvr:rvnHP:rn89D2:rvrKBCVersion14.1D.00:cvnHP:ct10:cvr:sku5Y3J1EA#ABZ:" + devices: + - node: /dev/input/event1 + evdev: + # Name: PixArt HP USB Optical Mouse + # ID: bus 0x3 vendor 0x3f0 product 0x94a version 0x111 + # Supported Events: + # Event type 0 (EV_SYN) + # Event type 1 (EV_KEY) + # Event code 272 (BTN_LEFT) + # Event code 273 (BTN_RIGHT) + # Event code 274 (BTN_MIDDLE) + # Event type 2 (EV_REL) + # Event code 0 (REL_X) + # Event code 1 (REL_Y) + # Event code 8 (REL_WHEEL) + # Event code 11 (REL_WHEEL_HI_RES) + # Event type 4 (EV_MSC) + # Event code 4 (MSC_SCAN) + # Properties: + name: "PixArt HP USB Optical Mouse" + id: [3, 1008, 2378, 273] + codes: + 0: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] # EV_SYN + 1: [272, 273, 274] # EV_KEY + 2: [0, 1, 8, 11] # EV_REL + 4: [4] # EV_MSC + properties: [] + hid: [ + 0x05, 0x01, 0x09, 0x02, 0xa1, 0x01, 0x09, 0x01, 0xa1, 0x00, 0x05, 0x09, 0x19, 0x01, 0x29, 0x03, + 0x15, 0x00, 0x25, 0x01, 0x95, 0x08, 0x75, 0x01, 0x81, 0x02, 0x05, 0x01, 0x09, 0x30, 0x09, 0x31, + 0x09, 0x38, 0x15, 0x81, 0x25, 0x7f, 0x75, 0x08, 0x95, 0x03, 0x81, 0x06, 0xc0, 0xc0 + ] + udev: + properties: + - ID_INPUT=1 + - ID_INPUT_MOUSE=1 + - LIBINPUT_DEVICE_GROUP=3/3f0/94a:usb-0000:05:00.3-2 + quirks: + events: + # Current time is 12:31:56 + - evdev: + - [ 0, 0, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated) + - [ 0, 0, 1, 272, 1] # EV_KEY / BTN_LEFT 1 + - [ 0, 0, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms + - evdev: + - [ 1, 207892, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated) + - [ 1, 207892, 1, 273, 1] # EV_KEY / BTN_RIGHT 1 + - [ 1, 207892, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1207ms + - evdev: + - [ 2, 367823, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated) + - [ 2, 367823, 1, 272, 0] # EV_KEY / BTN_LEFT 0 + - [ 2, 367823, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1160ms + # Current time is 12:32:00 + - evdev: + - [ 3, 247617, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated) + - [ 3, 247617, 1, 273, 0] # EV_KEY / BTN_RIGHT 0 + - [ 3, 247617, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +880ms + +Note: if ``libinput record`` is not available on your system try using +``evemu-record``. + +When something does not work +============================ + +There can be a number of reasons why a device does not behave +correctly. For example + +* The HID report descriptor provided by the HID device may be wrong + because e.g. + + * it does not follow the standard, so that the kernel + will not able to make sense of the HID report descriptor; + * the HID report descriptor *does not match* what is actually + sent by the device (this can be verified by reading the raw HID + data); +* the HID report descriptor may need some "quirks" (see later on). + +As a consequence, a ``/dev/input/event*`` may not be created +for each Application Collection, and/or the events +there may not match what you would expect. + + +Quirks +------ + +There are some known peculiarities of HID devices that the kernel +knows how to fix - these are called the HID quirks and a list of those +is available in `include/linux/hid.h`. + +Should this be the case, it should be enough to add the required quirk +in the kernel, for the HID device at hand. This can be done in the file +`drivers/hid/hid-quirks.c`. How to do it should be relatively +straightforward after looking into the file. + +The list of currently defined quirks, from `include/linux/hid.h`, is + +.. kernel-doc:: include/linux/hid.h + :doc: HID quirks + +Quirks for USB devices can be specified while loading the usbhid module, +see ``modinfo usbhid``, although the proper fix should go into +hid-quirks.c and **be submitted upstream**. +See Documentation/process/submitting-patches.rst for guidelines on how +to submit a patch. Quirks for other busses need to go into hid-quirks.c. + +Fixing HID report descriptors +----------------------------- + +Should you need to patch HID report descriptors the easiest way is to +resort to eBPF, as described in Documentation/hid/hid-bpf.rst. + +Basically, you can change any byte of the original HID report +descriptor. The examples in samples/hid should be a good starting point +for your code, see e.g. `samples/hid/hid_mouse.bpf.c`:: + + SEC("fmod_ret/hid_bpf_rdesc_fixup") + int BPF_PROG(hid_rdesc_fixup, struct hid_bpf_ctx *hctx) + { + .... + data[39] = 0x31; + data[41] = 0x30; + return 0; + } + +Of course this can be also done within the kernel source code, see e.g. +`drivers/hid/hid-aureal.c` or `drivers/hid/hid-samsung.c` for a slightly +more complex file. + +Check Documentation/hid/hidreport-parsing.rst if you need any help +navigating the HID manuals and understanding the exact meaning of +the HID report descriptor hex numbers. + +Whatever solution you come up with, please remember to **submit the +fix to the HID maintainers**, so that it can be directly integrated in +the kernel and that particular HID device will start working for +everyone else. See Documentation/process/submitting-patches.rst for +guidelines on how to do this. + + +Modifying the transmitted data on the fly +----------------------------------------- + +Using eBPF it is also possible to modify the data exchanged with the +device. See again the examples in `samples/hid`. + +Again, **please post your fix**, so that it can be integrated in the +kernel! + +Writing a specialized driver +---------------------------- + +This should really be your last resort. + + +.. rubric:: Footnotes + +.. [#hidraw] read hidraw: see Documentation/hid/hidraw.rst and + file `samples/hidraw/hid-example.c` for an example. + The output of ``hid-example`` would be, for the same mouse:: + + $ sudo ./hid-example + Report Descriptor Size: 52 + Report Descriptor: + 5 1 9 2 a1 1 9 1 a1 0 5 9 19 1 29 3 15 0 25 1 75 1 95 3 81 2 75 5 95 1 81 1 5 1 9 30 9 31 9 38 15 81 25 7f 75 8 95 3 81 6 c0 c0 + + Raw Name: PixArt USB Optical Mouse + Raw Phys: usb-0000:05:00.4-2.3/input0 + Raw Info: + bustype: 3 (USB) + vendor: 0x093a + product: 0x2510 + ... diff --git a/Documentation/hid/hidreport-parsing.rst b/Documentation/hid/hidreport-parsing.rst new file mode 100644 index 000000000000..1d3c17f29f2b --- /dev/null +++ b/Documentation/hid/hidreport-parsing.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================== +Manual parsing of HID report descriptors +======================================== + +Consider again the mouse HID report descriptor +introduced in Documentation/hid/hidintro.rst:: + + $ hexdump -C /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor + 00000000 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 |..............).| + 00000010 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 |..%.u.....u.....| + 00000020 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 |...0.1.8..%.u...| + 00000030 81 06 c0 c0 |....| + 00000034 + +and try to parse it by hand. + +Start with the first number, 0x05: it carries 2 bits for the +length of the item, 2 bits for the type of the item and 4 bits for the +function:: + + +----------+ + | 00000101 | + +----------+ + ^^ + ---- Length of data (see HID spec 6.2.2.2) + ^^ + ------ Type of the item (see HID spec 6.2.2.2, then jump to 6.2.2.7) + ^^^^ + --------- Function of the item (see HID spec 6.2.2.7, then HUT Sec 3) + +In our case, the length is 1 byte, the type is ``Global`` and the +function is ``Usage Page``, thus for parsing the value 0x01 in the second byte +we need to refer to HUT Sec 3. + +The second number is the actual data, and its meaning can be found in +the HUT. We have a ``Usage Page``, thus we need to refer to HUT +Sec. 3, "Usage Pages"; from there, one sees that ``0x01`` stands for +``Generic Desktop Page``. + +Moving now to the second two bytes, and following the same scheme, +``0x09`` (i.e. ``00001001``) will be followed by one byte (``01``) +and is a ``Local`` item (``10``). Thus, the meaning of the remaining four bits +(``0000``) is given in the HID spec Sec. 6.2.2.8 "Local Items", so that +we have a ``Usage``. From HUT, Sec. 4, "Generic Desktop Page", we see that +0x02 stands for ``Mouse``. + +The following numbers can be parsed in the same way. diff --git a/Documentation/hid/index.rst b/Documentation/hid/index.rst index b2028f382f11..af02cf7cfa82 100644 --- a/Documentation/hid/index.rst +++ b/Documentation/hid/index.rst @@ -7,6 +7,7 @@ Human Interface Devices (HID) .. toctree:: :maxdepth: 1 + hidintro hiddev hidraw hid-sensor diff --git a/Documentation/hwmon/aht10.rst b/Documentation/hwmon/aht10.rst index 4e198c5eb683..213644b4ecba 100644 --- a/Documentation/hwmon/aht10.rst +++ b/Documentation/hwmon/aht10.rst @@ -5,32 +5,42 @@ Kernel driver aht10 Supported chips: - * Aosong AHT10 + * Aosong AHT10/AHT20 Prefix: 'aht10' Addresses scanned: None - Datasheet: + Datasheet(AHT10): Chinese: http://www.aosong.com/userfiles/files/media/AHT10%E4%BA%A7%E5%93%81%E6%89%8B%E5%86%8C%20A3%2020201210.pdf English: https://server4.eca.ir/eshop/AHT10/Aosong_AHT10_en_draft_0c.pdf + Datasheet(AHT20): + + English: http://www.aosong.com/userfiles/files/media/Data%20Sheet%20AHT20.pdf + Author: Johannes Cornelis Draaijer <jcdra1@gmail.com> Description ----------- -The AHT10 is a Temperature and Humidity sensor +The AHT10/AHT20 is a Temperature and Humidity sensor The address of this i2c device may only be 0x38 +Special Features +---------------- + +AHT20 has additional CRC8 support which is sent as the last byte of the sensor +values. + Usage Notes ----------- -This driver does not probe for AHT10 devices, as there is no reliable -way to determine if an i2c chip is or isn't an AHT10. The device has +This driver does not probe for AHT10/ATH20 devices, as there is no reliable +way to determine if an i2c chip is or isn't an AHT10/AHT20. The device has to be instantiated explicitly with the address 0x38. See Documentation/i2c/instantiating-devices.rst for details. diff --git a/Documentation/hwmon/aquacomputer_d5next.rst b/Documentation/hwmon/aquacomputer_d5next.rst index 14b37851af0c..94dc2d93d180 100644 --- a/Documentation/hwmon/aquacomputer_d5next.rst +++ b/Documentation/hwmon/aquacomputer_d5next.rst @@ -12,6 +12,7 @@ Supported devices: * Aquacomputer Octo fan controller * Aquacomputer Quadro fan controller * Aquacomputer High Flow Next sensor +* Aquacomputer Leakshield leak prevention system * Aquacomputer Aquastream XT watercooling pump * Aquacomputer Aquastream Ultimate watercooling pump * Aquacomputer Poweradjust 3 fan controller @@ -57,6 +58,11 @@ The High Flow Next exposes +5V voltages, water quality, conductivity and flow re A temperature sensor can be connected to it, in which case it provides its reading and an estimation of the dissipated/absorbed power in the liquid cooling loop. +The Leakshield exposes two temperature sensors and coolant pressure (current, min, max and +target readings). It also exposes the estimated reservoir volume and how much of it is +filled with coolant. Pump RPM and flow can be set to enhance on-device calculations, +but this is not yet implemented here. + The Aquastream XT pump exposes temperature readings for the coolant, external sensor and fan IC. It also exposes pump and fan speeds (in RPM), voltages, as well as pump current. @@ -83,6 +89,9 @@ Sysfs entries temp[1-20]_input Physical/virtual temperature sensors (in millidegrees Celsius) temp[1-8]_offset Temperature sensor correction offset (in millidegrees Celsius) fan[1-8]_input Pump/fan speed (in RPM) / Flow speed (in dL/h) +fan1_min Minimal fan speed (in RPM) +fan1_max Maximal fan speed (in RPM) +fan1_target Target fan speed (in RPM) fan5_pulses Quadro flow sensor pulses power[1-8]_input Pump/fan power (in micro Watts) in[0-7]_input Pump/fan voltage (in milli Volts) diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst index c92c1d3839e4..7e3cd5b6686f 100644 --- a/Documentation/hwmon/asus_ec_sensors.rst +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -14,6 +14,7 @@ Supported boards: * ROG CROSSHAIR VIII FORMULA * ROG CROSSHAIR VIII HERO * ROG CROSSHAIR VIII IMPACT + * ROG CROSSHAIR X670E HERO * ROG MAXIMUS XI HERO * ROG MAXIMUS XI HERO (WI-FI) * ROG STRIX B550-E GAMING diff --git a/Documentation/hwmon/corsair-psu.rst b/Documentation/hwmon/corsair-psu.rst index c389bd21f4f2..16db34d464dd 100644 --- a/Documentation/hwmon/corsair-psu.rst +++ b/Documentation/hwmon/corsair-psu.rst @@ -15,11 +15,11 @@ Supported devices: Corsair HX850i - Corsair HX1000i (revision 1 and 2) + Corsair HX1000i (Series 2022 and 2023) Corsair HX1200i - Corsair HX1500i + Corsair HX1500i (Series 2022 and 2023) Corsair RM550i @@ -69,6 +69,8 @@ power1_input Total power usage power2_input Power usage of the 12v psu rail power3_input Power usage of the 5v psu rail power4_input Power usage of the 3.3v psu rail +pwm1 PWM value, read only +pwm1_enable PWM mode, read only temp1_input Temperature of the psu vrm component temp1_crit Temperature max cirtical value of the psu vrm component temp2_input Temperature of the psu case @@ -78,11 +80,14 @@ temp2_crit Temperature max critical value of psu case Usage Notes ----------- -It is an USB HID device, so it is auto-detected and supports hot-swapping. +It is an USB HID device, so it is auto-detected, supports hot-swapping and +several devices at once. Flickering values in the rail voltage levels can be an indicator for a failing -PSU. The driver also provides some additional useful values via debugfs, which -do not fit into the hwmon class. +PSU. Accordingly to the default automatic fan speed plan the fan starts at about +30% of the wattage rating. If this does not happen, a fan failure is likely. The +driver also provides some additional useful values via debugfs, which do not fit +into the hwmon class. Debugfs entries --------------- diff --git a/Documentation/hwmon/hp-wmi-sensors.rst b/Documentation/hwmon/hp-wmi-sensors.rst new file mode 100644 index 000000000000..a6bca9aecdde --- /dev/null +++ b/Documentation/hwmon/hp-wmi-sensors.rst @@ -0,0 +1,140 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +.. include:: <isonum.txt> + +=========================== +Linux HP WMI Sensors Driver +=========================== + +:Copyright: |copy| 2023 James Seo <james@equiv.tech> + +Description +=========== + +Hewlett-Packard (and some HP Compaq) business-class computers report hardware +monitoring information via Windows Management Instrumentation (WMI). +This driver exposes that information to the Linux hwmon subsystem, allowing +userspace utilities like ``sensors`` to gather numeric sensor readings. + +sysfs interface +=============== + +When the driver is loaded, it discovers the sensors available on the +system and creates the following sysfs attributes as necessary within +``/sys/class/hwmon/hwmon[X]``: + +(``[X]`` is some number that depends on other system components.) + +======================= ======= =================================== +Name Perm Description +======================= ======= =================================== +``curr[X]_input`` RO Current in milliamperes (mA). +``curr[X]_label`` RO Current sensor label. +``fan[X]_input`` RO Fan speed in RPM. +``fan[X]_label`` RO Fan sensor label. +``fan[X]_fault`` RO Fan sensor fault indicator. +``fan[X]_alarm`` RO Fan sensor alarm indicator. +``in[X]_input`` RO Voltage in millivolts (mV). +``in[X]_label`` RO Voltage sensor label. +``temp[X]_input`` RO Temperature in millidegrees Celsius + (m\ |deg|\ C). +``temp[X]_label`` RO Temperature sensor label. +``temp[X]_fault`` RO Temperature sensor fault indicator. +``temp[X]_alarm`` RO Temperature sensor alarm indicator. +``intrusion[X]_alarm`` RW Chassis intrusion alarm indicator. +======================= ======= =================================== + +``fault`` attributes + Reading ``1`` instead of ``0`` as the ``fault`` attribute for a sensor + indicates that it has encountered some issue during operation such that + measurements from it should not be trusted. If a sensor with the fault + condition recovers later, reading this attribute will return ``0`` again. + +``alarm`` attributes + Reading ``1`` instead of ``0`` as the ``alarm`` attribute for a sensor + indicates that one of the following has occurred, depending on its type: + + - ``fan``: The fan has stalled or has been disconnected while running. + - ``temp``: The sensor reading has reached a critical threshold. + The exact threshold is system-dependent. + - ``intrusion``: The system's chassis has been opened. + + After ``1`` is read from an ``alarm`` attribute, the attribute resets itself + and returns ``0`` on subsequent reads. As an exception, an + ``intrusion[X]_alarm`` can only be manually reset by writing ``0`` to it. + +debugfs interface +================= + +.. warning:: The debugfs interface is subject to change without notice + and is only available when the kernel is compiled with + ``CONFIG_DEBUG_FS`` defined. + +The standard hwmon interface in sysfs exposes sensors of several common types +that are connected as of driver initialization. However, there are usually +other sensors in WMI that do not meet these criteria. In addition, a number of +system-dependent "platform events objects" used for ``alarm`` attributes may +be present. A debugfs interface is therefore provided for read-only access to +all available HP WMI sensors and platform events objects. + +``/sys/kernel/debug/hp-wmi-sensors-[X]/sensor`` +contains one numbered entry per sensor with the following attributes: + +=============================== ======================================= +Name Example +=============================== ======================================= +``name`` ``CPU0 Fan`` +``description`` ``Reports CPU0 fan speed`` +``sensor_type`` ``12`` +``other_sensor_type`` (an empty string) +``operational_status`` ``2`` +``possible_states`` ``Normal,Caution,Critical,Not Present`` +``current_state`` ``Normal`` +``base_units`` ``19`` +``unit_modifier`` ``0`` +``current_reading`` ``1008`` +``rate_units`` ``0`` (only exists on some systems) +=============================== ======================================= + +If platform events objects are available, +``/sys/kernel/debug/hp-wmi-sensors-[X]/platform_events`` +contains one numbered entry per object with the following attributes: + +=============================== ==================== +Name Example +=============================== ==================== +``name`` ``CPU0 Fan Stall`` +``description`` ``CPU0 Fan Speed`` +``source_namespace`` ``root\wmi`` +``source_class`` ``HPBIOS_BIOSEvent`` +``category`` ``3`` +``possible_severity`` ``25`` +``possible_status`` ``5`` +=============================== ==================== + +These represent the properties of the underlying ``HPBIOS_BIOSNumericSensor`` +and ``HPBIOS_PlatformEvents`` WMI objects, which vary between systems. +See [#]_ for more details and Managed Object Format (MOF) definitions. + +Known issues and limitations +============================ + +- If the existing hp-wmi driver for non-business-class HP systems is already + loaded, ``alarm`` attributes will be unavailable even on systems that + support them. This is because the same WMI event GUID used by this driver + for ``alarm`` attributes is used on those systems for e.g. laptop hotkeys. +- Dubious sensor hardware and inconsistent BIOS WMI implementations have been + observed to cause inaccurate readings and peculiar behavior, such as alarms + failing to occur or occurring only once per boot. +- Only temperature, fan speed, and intrusion sensor types have been seen in + the wild so far. Support for voltage and current sensors is therefore + provisional. +- Although HP WMI sensors may claim to be of any type, any oddball sensor + types unknown to hwmon will not be supported. + +References +========== + +.. [#] Hewlett-Packard Development Company, L.P., + "HP Client Management Interface Technical White Paper", 2005. [Online]. + Available: https://h20331.www2.hp.com/hpsub/downloads/cmi_whitepaper.pdf diff --git a/Documentation/hwmon/hs3001.rst b/Documentation/hwmon/hs3001.rst new file mode 100644 index 000000000000..9f59dfc212d9 --- /dev/null +++ b/Documentation/hwmon/hs3001.rst @@ -0,0 +1,37 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver HS3001 +==================== + +Supported chips: + + * Renesas HS3001, HS3002, HS3003, HS3004 + + Prefix: 'hs3001' + + Addresses scanned: - + + Datasheet: https://www.renesas.com/us/en/document/dst/hs300x-datasheet?r=417401 + +Author: + + - Andre Werner <andre.werner@systec-electronic.com> + +Description +----------- + +This driver implements support for the Renesas HS3001 chips, a humidity +and temperature family. Temperature is measured in degrees celsius, relative +humidity is expressed as a percentage. In the sysfs interface, all values are +scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500. + +The device communicates with the I2C protocol. Sensors have the I2C +address 0x44 by default. + +sysfs-Interface +--------------- + +=================== ================= +temp1_input: temperature input +humidity1_input: humidity input +=================== ================= diff --git a/Documentation/hwmon/hwmon-kernel-api.rst b/Documentation/hwmon/hwmon-kernel-api.rst index c2d1e0299d8d..6cacf7daf25c 100644 --- a/Documentation/hwmon/hwmon-kernel-api.rst +++ b/Documentation/hwmon/hwmon-kernel-api.rst @@ -66,7 +66,7 @@ hwmon_device_register_with_info. devm_hwmon_device_unregister does not normally have to be called. It is only needed for error handling, and only needed if the driver probe fails after -the call to hwmon_device_register_with_info and if the automatic (device +the call to devm_hwmon_device_register_with_info and if the automatic (device managed) removal would be too late. All supported hwmon device registration functions only accept valid device diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index fa1208c62855..88dadea85cfc 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -9,7 +9,6 @@ Hardware Monitoring hwmon-kernel-api pmbus-core - inspur-ipsps1 submitting-patches sysfs-interface userspace-tools @@ -78,6 +77,8 @@ Hardware Monitoring Kernel Drivers gl518sm gxp-fan-ctrl hih6130 + hp-wmi-sensors + hs3001 ibmaem ibm-cffps ibmpowernv @@ -85,6 +86,7 @@ Hardware Monitoring Kernel Drivers ina2xx ina238 ina3221 + inspur-ipsps1 intel-m10-bmc-hwmon ir35221 ir38064 @@ -140,6 +142,7 @@ Hardware Monitoring Kernel Drivers max31760 max31785 max31790 + max31827 max34440 max6620 max6639 @@ -193,7 +196,6 @@ Hardware Monitoring Kernel Drivers shtc1 sis5595 sl28cpld - smm665 smpro-hwmon smsc47b397 smsc47m192 diff --git a/Documentation/hwmon/max31827.rst b/Documentation/hwmon/max31827.rst new file mode 100644 index 000000000000..b0971d05b8a4 --- /dev/null +++ b/Documentation/hwmon/max31827.rst @@ -0,0 +1,90 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver max31827 +====================== + +Supported chips: + + * Maxim MAX31827 + + Prefix: 'max31827' + + Addresses scanned: I2C 0x40 - 0x5f + + Datasheet: Publicly available at the Analog Devices website + + * Maxim MAX31828 + + Prefix: 'max31828' + + Addresses scanned: I2C 0x40 - 0x5f + + Datasheet: Publicly available at the Analog Devices website + + * Maxim MAX31829 + + Prefix: 'max31829' + + Addresses scanned: I2C 0x40 - 0x5f + + Datasheet: Publicly available at the Analog Devices website + + +Authors: + - Daniel Matyas <daniel.matyas@analog.com> + +Description +----------- + +The chips supported by this driver are quite similar. The only difference +between them is found in the default power-on behaviour of the chips. While the +MAX31827's fault queue is set to 1, the other two chip's fault queue is set to +4. Besides this, the MAX31829's alarm active state is high, while the other two +chip's alarms are active on low. It is important to note that the chips can be +configured to operate in the same manner with 1 write operation to the +configuration register. From here on, we will refer to all these chips as +MAX31827. + +MAX31827 implements a temperature sensor with a 6 WLP packaging scheme. This +sensor measures the temperature of the chip itself. + +MAX31827 has low and over temperature alarms with an effective value and a +hysteresis value: -40 and -30 degrees for under temperature alarm and +100 and ++90 degrees for over temperature alarm. + +The alarm can be configured in comparator and interrupt mode. Currently only +comparator mode is implemented. In Comparator mode, the OT/UT status bits have a +value of 1 when the temperature rises above the TH value or falls below TL, +which is also subject to the Fault Queue selection. OT status returns to 0 when +the temperature drops below the TH_HYST value or when shutdown mode is entered. +Similarly, UT status returns to 0 when the temperature rises above TL_HYST value +or when shutdown mode is entered. + +Putting the MAX31827 into shutdown mode also resets the OT/UT status bits. Note +that if the mode is changed while OT/UT status bits are set, an OT/UT status +reset may be required before it begins to behave normally. To prevent this, +it is recommended to perform a read of the configuration/status register to +clear the status bits before changing the operating mode. + +The conversions can be manual with the one-shot functionality and automatic with +a set frequency. When powered on, the chip measures temperatures with 1 conv/s. +Enabling the device when it is already enabled has the side effect of setting +the conversion frequency to 1 conv/s. The conversion time varies depending on +the resolution. The conversion time doubles with every bit of increased +resolution. For 10 bit resolution 35ms are needed, while for 12 bit resolution +(default) 140ms. When chip is in shutdown mode and a read operation is +requested, one-shot is triggered, the device waits for 140 (conversion time) + 1 +(error) ms, and only after that is the temperature value register read. + +The LSB of the temperature values is 0.0625 degrees Celsius, but the values of +the temperatures are displayed in milli-degrees. This means, that some data is +lost. The step between 2 consecutive values is 62 or 63. This effect can be seen +in the writing of alarm values too. For positive numbers the user-input value +will always be rounded down to the nearest possible value, for negative numbers +the user-input will always be rounded up to the nearest possible value. + +Notes +----- + +Currently fault queue, alarm polarity and resolution cannot be modified. +PEC is not implemented either. diff --git a/Documentation/hwmon/nct6775.rst b/Documentation/hwmon/nct6775.rst index 5ba8276aad4b..9d7a10de61a7 100644 --- a/Documentation/hwmon/nct6775.rst +++ b/Documentation/hwmon/nct6775.rst @@ -80,7 +80,13 @@ Supported chips: Datasheet: Available from Nuvoton upon request + * Nuvoton NCT6796D-S/NCT6799D-R + Prefix: 'nct6799' + + Addresses scanned: ISA address retrieved from Super I/O registers + + Datasheet: Available from Nuvoton upon request Authors: @@ -277,4 +283,7 @@ will not reflect a usable value. It often reports unreasonably high temperatures, and in some cases the reported temperature declines if the actual temperature increases (similar to the raw PECI temperature value - see PECI specification for details). CPUTIN should therefore be ignored on ASUS -boards. The CPU temperature on ASUS boards is reported from PECI 0. +boards. The CPU temperature on ASUS boards is reported from PECI 0 or TSI 0. + +NCT6796D-S and NCT6799D-R chips are very similar and their chip_id indicates +they are different versions. This driver treats them the same way. diff --git a/Documentation/hwmon/oxp-sensors.rst b/Documentation/hwmon/oxp-sensors.rst index 566a8d5bde08..3adeb7406243 100644 --- a/Documentation/hwmon/oxp-sensors.rst +++ b/Documentation/hwmon/oxp-sensors.rst @@ -19,18 +19,32 @@ out the EC registers and values to write to since the EC layout and model is different. Aya Neo devices preceding the AIR may not be supportable as the EC model is different and do not appear to have manual control capabilities. +Some models have a toggle for changing the behaviour of the "Turbo/Silent" +button of the device. It will change the key event that it triggers with +a flip of the `tt_toggle` attribute. See below for boards that support this +function. + Supported devices ----------------- Currently the driver supports the following handhelds: - AOK ZOE A1 + - AOK ZOE A1 PRO + - Aya Neo 2 - Aya Neo AIR - Aya Neo AIR Pro + - Aya Neo Geek - OneXPlayer AMD - OneXPlayer mini AMD - OneXPlayer mini AMD PRO +"Turbo/Silent" button behaviour toggle is only supported on: + - AOK ZOE A1 + - AOK ZOE A1 PRO + - OneXPlayer mini AMD (only with updated alpha BIOS) + - OneXPlayer mini AMD PRO + Sysfs entries ------------- @@ -47,3 +61,10 @@ pwm1 Read Write. Read this attribute to see current duty cycle in the range [0-255]. When pwm1_enable is set to "1" (manual) write any value in the range [0-255] to set fan speed. + +tt_toggle + Read Write. Read this attribute to check the status of the turbo/silent + button behaviour function. Write "1" to activate the switch and "0" to + deactivate it. The specific keycodes and behaviour is specific to the device + both with this function on and off. This attribute is attached to the platform + driver and not to the hwmon driver (/sys/devices/platform/oxp-platform/tt_toggle) diff --git a/Documentation/hwmon/pmbus-core.rst b/Documentation/hwmon/pmbus-core.rst index cff93adf6e42..1eaf2b015837 100644 --- a/Documentation/hwmon/pmbus-core.rst +++ b/Documentation/hwmon/pmbus-core.rst @@ -345,7 +345,7 @@ PMBUS_NO_CAPABILITY Some PMBus chips don't respond with valid data when reading the CAPABILITY register. For such chips, this flag should be set so that the PMBus core -driver doesn't use CAPABILITY to determine it's behavior. +driver doesn't use CAPABILITY to determine its behavior. PMBUS_READ_STATUS_AFTER_FAILED_CHECK diff --git a/Documentation/hwmon/pmbus.rst b/Documentation/hwmon/pmbus.rst index 7ecfec6ca2db..eb1569bfa676 100644 --- a/Documentation/hwmon/pmbus.rst +++ b/Documentation/hwmon/pmbus.rst @@ -163,7 +163,7 @@ Emerson DS1200 power modules might look as follows:: .driver = { .name = "ds1200", }, - .probe_new = ds1200_probe, + .probe = ds1200_probe, .id_table = ds1200_id, }; diff --git a/Documentation/hwmon/sht3x.rst b/Documentation/hwmon/sht3x.rst index 95a850d5b2c1..87864ffd1777 100644 --- a/Documentation/hwmon/sht3x.rst +++ b/Documentation/hwmon/sht3x.rst @@ -28,15 +28,8 @@ The device communicates with the I2C protocol. Sensors can have the I2C addresses 0x44 or 0x45, depending on the wiring. See Documentation/i2c/instantiating-devices.rst for methods to instantiate the device. -There are two options configurable by means of sht3x_platform_data: - -1. blocking (pull the I2C clock line down while performing the measurement) or - non-blocking mode. Blocking mode will guarantee the fastest result but - the I2C bus will be busy during that time. By default, non-blocking mode - is used. Make sure clock-stretching works properly on your device if you - want to use blocking mode. -2. high or low accuracy. High accuracy is used by default and using it is - strongly recommended. +Even if sht3x sensor supports clock-strech(blocking mode) and non-strench +(non-blocking mode) in single-shot mode, this driver only supports the latter. The sht3x sensor supports a single shot mode as well as 5 periodic measure modes, which can be controlled with the update_interval sysfs interface. @@ -85,4 +78,11 @@ heater_enable: heater enable, heating element removes excess humidity from update_interval: update interval, 0 for single shot, interval in msec for periodic measurement. If the interval is not supported by the sensor, the next faster interval is chosen +repeatability: write or read repeatability, higher repeatability means + longer measurement duration, lower noise level and + larger energy consumption: + + - 0: low repeatability + - 1: medium repeatability + - 2: high repeatability =================== ============================================================ diff --git a/Documentation/hwmon/smm665.rst b/Documentation/hwmon/smm665.rst deleted file mode 100644 index 481e69d8bf39..000000000000 --- a/Documentation/hwmon/smm665.rst +++ /dev/null @@ -1,187 +0,0 @@ -Kernel driver smm665 -==================== - -Supported chips: - - * Summit Microelectronics SMM465 - - Prefix: 'smm465' - - Addresses scanned: - - - Datasheet: - - http://www.summitmicro.com/prod_select/summary/SMM465/SMM465DS.pdf - - * Summit Microelectronics SMM665, SMM665B - - Prefix: 'smm665' - - Addresses scanned: - - - Datasheet: - - http://www.summitmicro.com/prod_select/summary/SMM665/SMM665B_2089_20.pdf - - * Summit Microelectronics SMM665C - - Prefix: 'smm665c' - - Addresses scanned: - - - Datasheet: - - http://www.summitmicro.com/prod_select/summary/SMM665C/SMM665C_2125.pdf - - * Summit Microelectronics SMM764 - - Prefix: 'smm764' - - Addresses scanned: - - - Datasheet: - - http://www.summitmicro.com/prod_select/summary/SMM764/SMM764_2098.pdf - - * Summit Microelectronics SMM766, SMM766B - - Prefix: 'smm766' - - Addresses scanned: - - - Datasheets: - - http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf - - http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf - -Author: Guenter Roeck <linux@roeck-us.net> - - -Module Parameters ------------------ - -* vref: int - Default: 1250 (mV) - - Reference voltage on VREF_ADC pin in mV. It should not be necessary to set - this parameter unless a non-default reference voltage is used. - - -Description ------------ - -[From datasheet] The SMM665 is an Active DC Output power supply Controller -that monitors, margins and cascade sequences power. The part monitors six -power supply channels as well as VDD, 12V input, two general-purpose analog -inputs and an internal temperature sensor using a 10-bit ADC. - -Each monitored channel has its own high and low limits, plus a critical -limit. - -Support for SMM465, SMM764, and SMM766 has been implemented but is untested. - - -Usage Notes ------------ - -This driver does not probe for devices, since there is no register which -can be safely used to identify the chip. You will have to instantiate -the devices explicitly. When instantiating the device, you have to specify -its configuration register address. - -Example: the following will load the driver for an SMM665 at address 0x57 -on I2C bus #1:: - - $ modprobe smm665 - $ echo smm665 0x57 > /sys/bus/i2c/devices/i2c-1/new_device - - -Sysfs entries -------------- - -This driver uses the values in the datasheet to convert ADC register values -into the values specified in the sysfs-interface document. All attributes are -read only. - -Min, max, lcrit, and crit values are used by the chip to trigger external signals -and/or other activity. Triggered signals can include HEALTHY, RST, Power Off, -or Fault depending on the chip configuration. The driver reports values as lcrit -or crit if exceeding the limits triggers RST, Power Off, or Fault, and as min or -max otherwise. For details please see the SMM665 datasheet. - -For SMM465 and SMM764, values for Channel E and F are reported but undefined. - -======================= ======================================================= -in1_input 12V input voltage (mV) -in2_input 3.3V (VDD) input voltage (mV) -in3_input Channel A voltage (mV) -in4_input Channel B voltage (mV) -in5_input Channel C voltage (mV) -in6_input Channel D voltage (mV) -in7_input Channel E voltage (mV) -in8_input Channel F voltage (mV) -in9_input AIN1 voltage (mV) -in10_input AIN2 voltage (mV) - -in1_min 12v input minimum voltage (mV) -in2_min 3.3V (VDD) input minimum voltage (mV) -in3_min Channel A minimum voltage (mV) -in4_min Channel B minimum voltage (mV) -in5_min Channel C minimum voltage (mV) -in6_min Channel D minimum voltage (mV) -in7_min Channel E minimum voltage (mV) -in8_min Channel F minimum voltage (mV) -in9_min AIN1 minimum voltage (mV) -in10_min AIN2 minimum voltage (mV) - -in1_max 12v input maximum voltage (mV) -in2_max 3.3V (VDD) input maximum voltage (mV) -in3_max Channel A maximum voltage (mV) -in4_max Channel B maximum voltage (mV) -in5_max Channel C maximum voltage (mV) -in6_max Channel D maximum voltage (mV) -in7_max Channel E maximum voltage (mV) -in8_max Channel F maximum voltage (mV) -in9_max AIN1 maximum voltage (mV) -in10_max AIN2 maximum voltage (mV) - -in1_lcrit 12v input critical minimum voltage (mV) -in2_lcrit 3.3V (VDD) input critical minimum voltage (mV) -in3_lcrit Channel A critical minimum voltage (mV) -in4_lcrit Channel B critical minimum voltage (mV) -in5_lcrit Channel C critical minimum voltage (mV) -in6_lcrit Channel D critical minimum voltage (mV) -in7_lcrit Channel E critical minimum voltage (mV) -in8_lcrit Channel F critical minimum voltage (mV) -in9_lcrit AIN1 critical minimum voltage (mV) -in10_lcrit AIN2 critical minimum voltage (mV) - -in1_crit 12v input critical maximum voltage (mV) -in2_crit 3.3V (VDD) input critical maximum voltage (mV) -in3_crit Channel A critical maximum voltage (mV) -in4_crit Channel B critical maximum voltage (mV) -in5_crit Channel C critical maximum voltage (mV) -in6_crit Channel D critical maximum voltage (mV) -in7_crit Channel E critical maximum voltage (mV) -in8_crit Channel F critical maximum voltage (mV) -in9_crit AIN1 critical maximum voltage (mV) -in10_crit AIN2 critical maximum voltage (mV) - -in1_crit_alarm 12v input critical alarm -in2_crit_alarm 3.3V (VDD) input critical alarm -in3_crit_alarm Channel A critical alarm -in4_crit_alarm Channel B critical alarm -in5_crit_alarm Channel C critical alarm -in6_crit_alarm Channel D critical alarm -in7_crit_alarm Channel E critical alarm -in8_crit_alarm Channel F critical alarm -in9_crit_alarm AIN1 critical alarm -in10_crit_alarm AIN2 critical alarm - -temp1_input Chip temperature -temp1_min Minimum chip temperature -temp1_max Maximum chip temperature -temp1_crit Critical chip temperature -temp1_crit_alarm Temperature critical alarm -======================= ======================================================= diff --git a/Documentation/i2c/busses/i2c-i801.rst b/Documentation/i2c/busses/i2c-i801.rst index ab9e850e8fe0..e76e68ccf718 100644 --- a/Documentation/i2c/busses/i2c-i801.rst +++ b/Documentation/i2c/busses/i2c-i801.rst @@ -46,7 +46,7 @@ Supported adapters: * Intel Emmitsburg (PCH) * Intel Alder Lake (PCH) * Intel Raptor Lake (PCH) - * Intel Meteor Lake (SOC) + * Intel Meteor Lake (SOC and PCH) Datasheets: Publicly available at the Intel website diff --git a/Documentation/i2c/i2c-address-translators.rst b/Documentation/i2c/i2c-address-translators.rst new file mode 100644 index 000000000000..b22ce9f41ecf --- /dev/null +++ b/Documentation/i2c/i2c-address-translators.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================= +I2C Address Translators +======================= + +Author: Luca Ceresoli <luca@lucaceresoli.net> +Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> + +Description +----------- + +An I2C Address Translator (ATR) is a device with an I2C slave parent +("upstream") port and N I2C master child ("downstream") ports, and +forwards transactions from upstream to the appropriate downstream port +with a modified slave address. The address used on the parent bus is +called the "alias" and is (potentially) different from the physical +slave address of the child bus. Address translation is done by the +hardware. + +An ATR looks similar to an i2c-mux except: + - the address on the parent and child busses can be different + - there is normally no need to select the child port; the alias used on the + parent bus implies it + +The ATR functionality can be provided by a chip with many other features. +The kernel i2c-atr provides a helper to implement an ATR within a driver. + +The ATR creates a new I2C "child" adapter on each child bus. Adding +devices on the child bus ends up in invoking the driver code to select +an available alias. Maintaining an appropriate pool of available aliases +and picking one for each new device is up to the driver implementer. The +ATR maintains a table of currently assigned alias and uses it to modify +all I2C transactions directed to devices on the child buses. + +A typical example follows. + +Topology:: + + Slave X @ 0x10 + .-----. | + .-----. | |---+---- B + | CPU |--A--| ATR | + `-----' | |---+---- C + `-----' | + Slave Y @ 0x10 + +Alias table: + +A, B and C are three physical I2C busses, electrically independent from +each other. The ATR receives the transactions initiated on bus A and +propagates them on bus B or bus C or none depending on the device address +in the transaction and based on the alias table. + +Alias table: + +.. table:: + + =============== ===== + Client Alias + =============== ===== + X (bus B, 0x10) 0x20 + Y (bus C, 0x10) 0x30 + =============== ===== + +Transaction: + + - Slave X driver requests a transaction (on adapter B), slave address 0x10 + - ATR driver finds slave X is on bus B and has alias 0x20, rewrites + messages with address 0x20, forwards to adapter A + - Physical I2C transaction on bus A, slave address 0x20 + - ATR chip detects transaction on address 0x20, finds it in table, + propagates transaction on bus B with address translated to 0x10, + keeps clock streched on bus A waiting for reply + - Slave X chip (on bus B) detects transaction at its own physical + address 0x10 and replies normally + - ATR chip stops clock stretching and forwards reply on bus A, + with address translated back to 0x20 + - ATR driver receives the reply, rewrites messages with address 0x10 + as they were initially + - Slave X driver gets back the msgs[], with reply and address 0x10 + +Usage: + + 1. In the driver (typically in the probe function) add an ATR by + calling i2c_atr_new() passing attach/detach callbacks + 2. When the attach callback is called pick an appropriate alias, + configure it in the chip and return the chosen alias in the + alias_id parameter + 3. When the detach callback is called, deconfigure the alias from + the chip and put the alias back in the pool for later usage + +I2C ATR functions and data structures +------------------------------------- + +.. kernel-doc:: include/linux/i2c-atr.h diff --git a/Documentation/i2c/index.rst b/Documentation/i2c/index.rst index 6270f1fd7d4e..2b213d4ce89c 100644 --- a/Documentation/i2c/index.rst +++ b/Documentation/i2c/index.rst @@ -18,6 +18,7 @@ Introduction i2c-topology muxes/i2c-mux-gpio i2c-sysfs + i2c-address-translators Writing device drivers ====================== diff --git a/Documentation/i2c/writing-clients.rst b/Documentation/i2c/writing-clients.rst index b7d3ae7458f8..41ddc10f1ac7 100644 --- a/Documentation/i2c/writing-clients.rst +++ b/Documentation/i2c/writing-clients.rst @@ -46,7 +46,7 @@ driver model device node, and its I2C address. }, .id_table = foo_idtable, - .probe_new = foo_probe, + .probe = foo_probe, .remove = foo_remove, /* if device autodetection is needed: */ .class = I2C_CLASS_SOMETHING, diff --git a/Documentation/input/devices/iforce-protocol.rst b/Documentation/input/devices/iforce-protocol.rst index 8634beac3fdb..52c1e0dd0ab7 100644 --- a/Documentation/input/devices/iforce-protocol.rst +++ b/Documentation/input/devices/iforce-protocol.rst @@ -49,7 +49,7 @@ OP DATA == ==== The 2B, LEN and CS fields have disappeared, probably because USB handles -frames and data corruption is handled or unsignificant. +frames and data corruption is handled or insignificant. First, I describe effects that are sent by the device to the computer diff --git a/Documentation/input/devices/pxrc.rst b/Documentation/input/devices/pxrc.rst index ca11f646bae8..5a86df4ad079 100644 --- a/Documentation/input/devices/pxrc.rst +++ b/Documentation/input/devices/pxrc.rst @@ -5,7 +5,7 @@ pxrc - PhoenixRC Flight Controller Adapter :Author: Marcus Folkesson <marcus.folkesson@gmail.com> This driver let you use your own RC controller plugged into the -adapter that comes with PhoenixRC [1]_ or other compatible adapters. +adapter that comes with PhoenixRC or other compatible adapters. The adapter supports 7 analog channels and 1 digital input switch. @@ -41,7 +41,7 @@ Manual Testing ============== To test this driver's functionality you may use `input-event` which is part of -the `input layer utilities` suite [2]_. +the `input layer utilities` suite [1]_. For example:: @@ -53,5 +53,4 @@ To print all input events from input `devnr`. References ========== -.. [1] http://www.phoenix-sim.com/ -.. [2] https://www.kraxel.org/cgit/input/ +.. [1] https://www.kraxel.org/cgit/input/ diff --git a/Documentation/input/multi-touch-protocol.rst b/Documentation/input/multi-touch-protocol.rst index 1085cbee4ee7..47d3dcb5d44b 100644 --- a/Documentation/input/multi-touch-protocol.rst +++ b/Documentation/input/multi-touch-protocol.rst @@ -383,7 +383,7 @@ Finger Tracking --------------- The process of finger tracking, i.e., to assign a unique trackingID to each -initiated contact on the surface, is a Euclidian Bipartite Matching +initiated contact on the surface, is a Euclidean Bipartite Matching problem. At each event synchronization, the set of actual contacts is matched to the set of contacts from the previous synchronization. A full implementation can be found in [#f3]_. diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst index 2a22ddb1b848..bd906407e307 100644 --- a/Documentation/kbuild/kbuild.rst +++ b/Documentation/kbuild/kbuild.rst @@ -150,6 +150,12 @@ the UTS_MACHINE variable, and on some architectures also the kernel config. The value of KBUILD_DEBARCH is assumed (not checked) to be a valid Debian architecture. +KDOCFLAGS +--------- +Specify extra (warning/error) flags for kernel-doc checks during the build, +see scripts/kernel-doc for which flags are supported. Note that this doesn't +(currently) apply to documentation builds. + ARCH ---- Set ARCH to the architecture to be built. diff --git a/Documentation/kbuild/kconfig.rst b/Documentation/kbuild/kconfig.rst index 5967c79c3baa..c946eb44bd13 100644 --- a/Documentation/kbuild/kconfig.rst +++ b/Documentation/kbuild/kconfig.rst @@ -10,6 +10,8 @@ The xconfig ('qconf'), menuconfig ('mconf'), and nconfig ('nconf') programs also have embedded help text. Be sure to check that for navigation, search, and other general help text. +The gconfig ('gconf') program has limited help text. + General ------- @@ -54,6 +56,15 @@ KCONFIG_OVERWRITECONFIG If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not break symlinks when .config is a symlink to somewhere else. +KCONFIG_WARN_UNKNOWN_SYMBOLS +---------------------------- +This environment variable makes Kconfig warn about all unrecognized +symbols in the config input. + +KCONFIG_WERROR +-------------- +If set, Kconfig treats warnings as errors. + `CONFIG_` --------- If you set `CONFIG_` in the environment, Kconfig will prefix all symbols @@ -210,6 +221,10 @@ Searching in menuconfig: first (and in alphabetical order), then come all other symbols, sorted in alphabetical order. + In this menu, pressing the key in the (#) prefix will jump + directly to that location. You will be returned to the current + search results after exiting this new menu. + ---------------------------------------------------------------------- User interface options for 'menuconfig' @@ -262,6 +277,10 @@ Searching in nconfig: F8 (SymSearch) searches the configuration symbols for the given string or regular expression (regex). + In the SymSearch, pressing the key in the (#) prefix will + jump directly to that location. You will be returned to the + current search results after exiting this new menu. + NCONFIG_MODE ------------ This mode shows all sub-menus in one large tree. diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index c3851fe1900d..b1d97fafddcf 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -25,50 +25,38 @@ objects <https://www.aosabook.org/en/llvm.html>`_. Clang is a front-end to LLVM that supports C and the GNU C extensions required by the kernel, and is pronounced "klang," not "see-lang." -Clang ------ - -The compiler used can be swapped out via ``CC=`` command line argument to ``make``. -``CC=`` should be set when selecting a config and during a build. :: - - make CC=clang defconfig - - make CC=clang +Building with LLVM +------------------ -Cross Compiling ---------------- +Invoke ``make`` via:: -A single Clang compiler binary will typically contain all supported backends, -which can help simplify cross compiling. :: - - make ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- + make LLVM=1 -``CROSS_COMPILE`` is not used to prefix the Clang compiler binary, instead -``CROSS_COMPILE`` is used to set a command line flag: ``--target=<triple>``. For -example: :: +to compile for the host target. For cross compiling:: - clang --target=aarch64-linux-gnu foo.c + make LLVM=1 ARCH=arm64 -LLVM Utilities --------------- +The LLVM= argument +------------------ -LLVM has substitutes for GNU binutils utilities. They can be enabled individually. -The full list of supported make variables:: +LLVM has substitutes for GNU binutils utilities. They can be enabled +individually. The full list of supported make variables:: make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \ OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \ HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld -To simplify the above command, Kbuild supports the ``LLVM`` variable:: - - make LLVM=1 +``LLVM=1`` expands to the above. If your LLVM tools are not available in your PATH, you can supply their location using the LLVM variable with a trailing slash:: make LLVM=/path/to/llvm/ -which will use ``/path/to/llvm/clang``, ``/path/to/llvm/ld.lld``, etc. +which will use ``/path/to/llvm/clang``, ``/path/to/llvm/ld.lld``, etc. The +following may also be used:: + + PATH=/path/to/llvm:$PATH make LLVM=1 If your LLVM tools have a version suffix and you want to test with that explicit version rather than the unsuffixed executables like ``LLVM=1``, you @@ -78,31 +66,72 @@ can pass the suffix using the ``LLVM`` variable:: which will use ``clang-14``, ``ld.lld-14``, etc. +To support combinations of out of tree paths with version suffixes, we +recommend:: + + PATH=/path/to/llvm/:$PATH make LLVM=-14 + ``LLVM=0`` is not the same as omitting ``LLVM`` altogether, it will behave like -``LLVM=1``. If you only wish to use certain LLVM utilities, use their respective -make variables. +``LLVM=1``. If you only wish to use certain LLVM utilities, use their +respective make variables. + +The same value used for ``LLVM=`` should be set for each invocation of ``make`` +if configuring and building via distinct commands. ``LLVM=`` should also be set +as an environment variable when running scripts that will eventually run +``make``. -The integrated assembler is enabled by default. You can pass ``LLVM_IAS=0`` to -disable it. +Cross Compiling +--------------- -Omitting CROSS_COMPILE +A single Clang compiler binary (and corresponding LLVM utilities) will +typically contain all supported back ends, which can help simplify cross +compiling especially when ``LLVM=1`` is used. If you use only LLVM tools, +``CROSS_COMPILE`` or target-triple-prefixes become unnecessary. Example:: + + make LLVM=1 ARCH=arm64 + +As an example of mixing LLVM and GNU utilities, for a target like ``ARCH=s390`` +which does not yet have ``ld.lld`` or ``llvm-objcopy`` support, you could +invoke ``make`` via:: + + make LLVM=1 ARCH=s390 LD=s390x-linux-gnu-ld.bfd \ + OBJCOPY=s390x-linux-gnu-objcopy + +This example will invoke ``s390x-linux-gnu-ld.bfd`` as the linker and +``s390x-linux-gnu-objcopy``, so ensure those are reachable in your ``$PATH``. + +``CROSS_COMPILE`` is not used to prefix the Clang compiler binary (or +corresponding LLVM utilities) as is the case for GNU utilities when ``LLVM=1`` +is not set. + +The LLVM_IAS= argument ---------------------- -As explained above, ``CROSS_COMPILE`` is used to set ``--target=<triple>``. +Clang can assemble assembler code. You can pass ``LLVM_IAS=0`` to disable this +behavior and have Clang invoke the corresponding non-integrated assembler +instead. Example:: + + make LLVM=1 LLVM_IAS=0 + +``CROSS_COMPILE`` is necessary when cross compiling and ``LLVM_IAS=0`` +is used in order to set ``--prefix=`` for the compiler to find the +corresponding non-integrated assembler (typically, you don't want to use the +system assembler when targeting another architecture). Example:: -If ``CROSS_COMPILE`` is not specified, the ``--target=<triple>`` is inferred -from ``ARCH``. + make LLVM=1 ARCH=arm LLVM_IAS=0 CROSS_COMPILE=arm-linux-gnueabi- -That means if you use only LLVM tools, ``CROSS_COMPILE`` becomes unnecessary. -For example, to cross-compile the arm64 kernel:: +Ccache +------ - make ARCH=arm64 LLVM=1 +``ccache`` can be used with ``clang`` to improve subsequent builds, (though +KBUILD_BUILD_TIMESTAMP_ should be set to a deterministic value between builds +in order to avoid 100% cache misses, see Reproducible_builds_ for more info): -If ``LLVM_IAS=0`` is specified, ``CROSS_COMPILE`` is also used to derive -``--prefix=<path>`` to search for the GNU assembler and linker. :: + KBUILD_BUILD_TIMESTAMP='' make LLVM=1 CC="ccache clang" - make ARCH=arm64 LLVM=1 LLVM_IAS=0 CROSS_COMPILE=aarch64-linux-gnu- +.. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp +.. _Reproducible_builds: reproducible-builds.html#timestamps Supported Architectures ----------------------- @@ -135,14 +164,17 @@ yet. Bug reports are always welcome at the issue tracker below! * - hexagon - Maintained - ``LLVM=1`` + * - loongarch + - Maintained + - ``LLVM=1`` * - mips - Maintained - ``LLVM=1`` * - powerpc - Maintained - - ``CC=clang`` + - ``LLVM=1`` * - riscv - - Maintained + - Supported - ``LLVM=1`` * - s390 - Maintained @@ -171,7 +203,11 @@ Getting Help Getting LLVM ------------- -We provide prebuilt stable versions of LLVM on `kernel.org <https://kernel.org/pub/tools/llvm/>`_. +We provide prebuilt stable versions of LLVM on `kernel.org +<https://kernel.org/pub/tools/llvm/>`_. These have been optimized with profile +data for building Linux kernels, which should improve kernel build times +relative to other distributions of LLVM. + Below are links that may be useful for building LLVM from source or procuring it through a distribution's package manager. diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst index ce57254cb871..3ade16c18328 100644 --- a/Documentation/leds/index.rst +++ b/Documentation/leds/index.rst @@ -17,6 +17,7 @@ LEDs uleds leds-blinkm + leds-cht-wcove leds-el15203000 leds-lm3556 leds-lp3944 diff --git a/Documentation/leds/leds-cht-wcove.rst b/Documentation/leds/leds-cht-wcove.rst new file mode 100644 index 000000000000..5ec7cb60c4aa --- /dev/null +++ b/Documentation/leds/leds-cht-wcove.rst @@ -0,0 +1,38 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================================================== +Kernel driver for Intel Cherry Trail Whiskey Cove PMIC LEDs +=========================================================== + +/sys/class/leds/<led>/hw_pattern +-------------------------------- + +Specify a hardware pattern for the Whiskey Cove PMIC LEDs. + +The only supported pattern is hardware breathing mode:: + + "0 2000 1 2000" + + ^ + | + Max-| --- + | / \ + | / \ + | / \ / + | / \ / + Min-|- --- + | + 0------2------4--> time (sec) + +The rise and fall times must be the same value. +Supported values are 2000, 1000, 500 and 250 for +breathing frequencies of 1/4, 1/2, 1 and 2 Hz. + +The set pattern only controls the timing. For max brightness the last +set brightness is used and the max brightness can be changed +while breathing by writing the brightness attribute. + +This is just like how blinking works in the LED subsystem, +for both sw and hw blinking the brightness can also be changed +while blinking. Breathing on this hw really is just a variant +mode of blinking. diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst index cd155ead8703..5db620ed27aa 100644 --- a/Documentation/leds/leds-class.rst +++ b/Documentation/leds/leds-class.rst @@ -169,6 +169,87 @@ Setting the brightness to zero with brightness_set() callback function should completely turn off the LED and cancel the previously programmed hardware blinking function, if any. +Hardware driven LEDs +==================== + +Some LEDs can be programmed to be driven by hardware. This is not +limited to blink but also to turn off or on autonomously. +To support this feature, a LED needs to implement various additional +ops and needs to declare specific support for the supported triggers. + +With hw control we refer to the LED driven by hardware. + +LED driver must define the following value to support hw control: + + - hw_control_trigger: + unique trigger name supported by the LED in hw control + mode. + +LED driver must implement the following API to support hw control: + - hw_control_is_supported: + check if the flags passed by the supported trigger can + be parsed and activate hw control on the LED. + + Return 0 if the passed flags mask is supported and + can be set with hw_control_set(). + + If the passed flags mask is not supported -EOPNOTSUPP + must be returned, the LED trigger will use software + fallback in this case. + + Return a negative error in case of any other error like + device not ready or timeouts. + + - hw_control_set: + activate hw control. LED driver will use the provided + flags passed from the supported trigger, parse them to + a set of mode and setup the LED to be driven by hardware + following the requested modes. + + Set LED_OFF via the brightness_set to deactivate hw control. + + Return 0 on success, a negative error number on failing to + apply flags. + + - hw_control_get: + get active modes from a LED already in hw control, parse + them and set in flags the current active flags for the + supported trigger. + + Return 0 on success, a negative error number on failing + parsing the initial mode. + Error from this function is NOT FATAL as the device may + be in a not supported initial state by the attached LED + trigger. + + - hw_control_get_device: + return the device associated with the LED driver in + hw control. A trigger might use this to match the + returned device from this function with a configured + device for the trigger as the source for blinking + events and correctly enable hw control. + (example a netdev trigger configured to blink for a + particular dev match the returned dev from get_device + to set hw control) + + Returns a pointer to a struct device or NULL if nothing + is currently attached. + +LED driver can activate additional modes by default to workaround the +impossibility of supporting each different mode on the supported trigger. +Examples are hardcoding the blink speed to a set interval, enable special +feature like bypassing blink if some requirements are not met. + +A trigger should first check if the hw control API are supported by the LED +driver and check if the trigger is supported to verify if hw control is possible, +use hw_control_is_supported to check if the flags are supported and only at +the end use hw_control_set to activate hw control. + +A trigger can use hw_control_get to check if a LED is already in hw control +and init their flags. + +When the LED is in hw control, no software blink is possible and doing so +will effectively disable hw control. Known Issues ============ diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt index e9c30dc75884..67b44704801f 100644 --- a/Documentation/leds/well-known-leds.txt +++ b/Documentation/leds/well-known-leds.txt @@ -58,6 +58,7 @@ LEDs on notebook body, indicating that sound input / output is muted. * System notification +Good: "rgb:status" Legacy: "status-led:{red,green,blue}" (Motorola Droid 4) Legacy: "lp5523:{r,g,b}" (Nokia N900) @@ -65,7 +66,7 @@ Phones usually have multi-color status LED. * Power management -Good: "platform:*:charging" (allwinner sun50i) +Good: "platform:*:charging" (allwinner sun50i, leds-cht-wcove) * Screen diff --git a/Documentation/livepatch/reliable-stacktrace.rst b/Documentation/livepatch/reliable-stacktrace.rst index d56bb706172f..8d950f3ffedd 100644 --- a/Documentation/livepatch/reliable-stacktrace.rst +++ b/Documentation/livepatch/reliable-stacktrace.rst @@ -40,7 +40,7 @@ Principally, the reliable stacktrace function must ensure that either: .. note:: In some cases it is legitimate to omit specific functions from the trace, but all other functions must be reported. These cases are described in - futher detail below. + further detail below. Secondly, the reliable stacktrace function must be robust to cases where the stack or other unwind state is corrupt or otherwise unreliable. The diff --git a/Documentation/locking/lockdep-design.rst b/Documentation/locking/lockdep-design.rst index 82f36cab61bd..56b90eea2731 100644 --- a/Documentation/locking/lockdep-design.rst +++ b/Documentation/locking/lockdep-design.rst @@ -29,7 +29,7 @@ the validator will shoot a splat if incorrect. A lock-class's behavior is constructed by its instances collectively: when the first instance of a lock-class is used after bootup the class gets registered, then all (subsequent) instances will be mapped to the -class and hence their usages and dependecies will contribute to those of +class and hence their usages and dependencies will contribute to those of the class. A lock-class does not go away when a lock instance does, but it can be removed if the memory space of the lock class (static or dynamic) is reclaimed, this happens for example when a module is @@ -105,7 +105,7 @@ exact case is for the lock as of the reporting time. +--------------+-------------+--------------+ The character '-' suggests irq is disabled because if otherwise the -charactor '?' would have been shown instead. Similar deduction can be +character '?' would have been shown instead. Similar deduction can be applied for '+' too. Unused locks (e.g., mutexes) cannot be part of the cause of an error. diff --git a/Documentation/locking/locktorture.rst b/Documentation/locking/locktorture.rst index 7f56fc0d7c31..3e763f77a620 100644 --- a/Documentation/locking/locktorture.rst +++ b/Documentation/locking/locktorture.rst @@ -113,7 +113,7 @@ stutter without pausing. shuffle_interval - The number of seconds to keep the test threads affinitied + The number of seconds to keep the test threads affinitized to a particular subset of the CPUs, defaults to 3 seconds. Used in conjunction with test_no_idle_hz. diff --git a/Documentation/locking/locktypes.rst b/Documentation/locking/locktypes.rst index 9933faad4771..80c914f6eae7 100644 --- a/Documentation/locking/locktypes.rst +++ b/Documentation/locking/locktypes.rst @@ -500,7 +500,7 @@ caveats also apply to bit spinlocks. Some bit spinlocks are replaced with regular spinlock_t for PREEMPT_RT using conditional (#ifdef'ed) code changes at the usage site. In contrast, usage-site changes are not needed for the spinlock_t substitution. -Instead, conditionals in header files and the core locking implemementation +Instead, conditionals in header files and the core locking implementation enable the compiler to do the substitution transparently. diff --git a/Documentation/maintainer/configure-git.rst b/Documentation/maintainer/configure-git.rst index 80ae5030a590..0a36831814ea 100644 --- a/Documentation/maintainer/configure-git.rst +++ b/Documentation/maintainer/configure-git.rst @@ -1,35 +1,31 @@ -.. _configuregit: - -Configure Git -============= +Configuring Git +=============== This chapter describes maintainer level git configuration. -Tagged branches used in :ref:`Documentation/maintainer/pull-requests.rst -<pullrequests>` should be signed with the developers public GPG key. Signed -tags can be created by passing the ``-u`` flag to ``git tag``. However, -since you would *usually* use the same key for the same project, you can -set it once with -:: +Tagged branches used in pull requests (see +Documentation/maintainer/pull-requests.rst) should be signed with the +developers public GPG key. Signed tags can be created by passing +``-u <key-id>`` to ``git tag``. However, since you would *usually* use the same +key for the project, you can set it in the configuration and use the ``-s`` +flag. To set the default ``key-id`` use:: git config user.signingkey "keyname" -Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by hand: -:: +Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by hand:: [user] name = Jane Developer email = jd@domain.org signingkey = jd@domain.org -You may need to tell ``git`` to use ``gpg2`` -:: +You may need to tell ``git`` to use ``gpg2``:: [gpg] program = /path/to/gpg2 -You may also like to tell ``gpg`` which ``tty`` to use (add to your shell rc file) -:: +You may also like to tell ``gpg`` which ``tty`` to use (add to your shell +rc file):: export GPG_TTY=$(tty) @@ -37,26 +33,24 @@ You may also like to tell ``gpg`` which ``tty`` to use (add to your shell rc fil Creating commit links to lore.kernel.org ---------------------------------------- -The web site http://lore.kernel.org is meant as a grand archive of all mail +The web site https://lore.kernel.org is meant as a grand archive of all mail list traffic concerning or influencing the kernel development. Storing archives of patches here is a recommended practice, and when a maintainer applies a patch to a subsystem tree, it is a good idea to provide a Link: tag with a reference back to the lore archive so that people that browse the commit history can find related discussions and rationale behind a certain change. -The link tag will look like this: +The link tag will look like this:: Link: https://lore.kernel.org/r/<message-id> This can be configured to happen automatically any time you issue ``git am`` -by adding the following hook into your git: - -.. code-block:: none +by adding the following hook into your git:: $ git config am.messageid true $ cat >.git/hooks/applypatch-msg <<'EOF' #!/bin/sh . git-sh-setup - perl -pi -e 's|^Message-Id:\s*<?([^>]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1" + perl -pi -e 's|^Message-I[dD]:\s*<?([^>]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1" test -x "$GIT_DIR/hooks/commit-msg" && exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"} : diff --git a/Documentation/maintainer/feature-and-driver-maintainers.rst b/Documentation/maintainer/feature-and-driver-maintainers.rst new file mode 100644 index 000000000000..f04cc183e1de --- /dev/null +++ b/Documentation/maintainer/feature-and-driver-maintainers.rst @@ -0,0 +1,155 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================== +Feature and driver maintainers +============================== + +The term "maintainer" spans a very wide range of levels of engagement +from people handling patches and pull requests as almost a full time job +to people responsible for a small feature or a driver. + +Unlike most of the chapter, this section is meant for the latter (more +populous) group. It provides tips and describes the expectations and +responsibilities of maintainers of a small(ish) section of the code. + +Drivers and alike most often do not have their own mailing lists and +git trees but instead send and review patches on the list of a larger +subsystem. + +Responsibilities +================ + +The amount of maintenance work is usually proportional to the size +and popularity of the code base. Small features and drivers should +require relatively small amount of care and feeding. Nonetheless +when the work does arrive (in form of patches which need review, +user bug reports etc.) it has to be acted upon promptly. +Even when a particular driver only sees one patch a month, or a quarter, +a subsystem could well have a hundred such drivers. Subsystem +maintainers cannot afford to wait a long time to hear from reviewers. + +The exact expectations on the response time will vary by subsystem. +The patch review SLA the subsystem had set for itself can sometimes +be found in the subsystem documentation. Failing that as a rule of thumb +reviewers should try to respond quicker than what is the usual patch +review delay of the subsystem maintainer. The resulting expectations +may range from two working days for fast-paced subsystems (e.g. networking) +to as long as a few weeks in slower moving parts of the kernel. + +Mailing list participation +-------------------------- + +Linux kernel uses mailing lists as the primary form of communication. +Maintainers must be subscribed and follow the appropriate subsystem-wide +mailing list. Either by subscribing to the whole list or using more +modern, selective setup like +`lei <https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started>`_. + +Maintainers must know how to communicate on the list (plain text, no invasive +legal footers, no top posting, etc.) + +Reviews +------- + +Maintainers must review *all* patches touching exclusively their drivers, +no matter how trivial. If the patch is a tree wide change and modifies +multiple drivers - whether to provide a review is left to the maintainer. + +When there are multiple maintainers for a piece of code an ``Acked-by`` +or ``Reviewed-by`` tag (or review comments) from a single maintainer is +enough to satisfy this requirement. + +If the review process or validation for a particular change will take longer +than the expected review timeline for the subsystem, maintainer should +reply to the submission indicating that the work is being done, and when +to expect full results. + +Refactoring and core changes +---------------------------- + +Occasionally core code needs to be changed to improve the maintainability +of the kernel as a whole. Maintainers are expected to be present and +help guide and test changes to their code to fit the new infrastructure. + +Bug reports +----------- + +Maintainers must ensure severe problems in their code reported to them +are resolved in a timely manner: regressions, kernel crashes, kernel warnings, +compilation errors, lockups, data loss, and other bugs of similar scope. + +Maintainers furthermore should respond to reports about other kinds of +bugs as well, if the report is of reasonable quality or indicates a +problem that might be severe -- especially if they have *Supported* +status of the codebase in the MAINTAINERS file. + +Selecting the maintainer +======================== + +The previous section described the expectations of the maintainer, +this section provides guidance on selecting one and describes common +misconceptions. + +The author +---------- + +Most natural and common choice of a maintainer is the author of the code. +The author is intimately familiar with the code, so it is the best person +to take care of it on an ongoing basis. + +That said, being a maintainer is an active role. The MAINTAINERS file +is not a list of credits (in fact a separate CREDITS file exists), +it is a list of those who will actively help with the code. +If the author does not have the time, interest or ability to maintain +the code, a different maintainer must be selected. + +Multiple maintainers +-------------------- + +Modern best practices dictate that there should be at least two maintainers +for any piece of code, no matter how trivial. It spreads the burden, helps +people take vacations and prevents burnout, trains new members of +the community etc. etc. Even when there is clearly one perfect candidate, +another maintainer should be found. + +Maintainers must be human, therefore, it is not acceptable to add a mailing +list or a group email as a maintainer. Trust and understanding are the +foundation of kernel maintenance and one cannot build trust with a mailing +list. Having a mailing list *in addition* to humans is perfectly fine. + +Corporate structures +-------------------- + +To an outsider the Linux kernel may resemble a hierarchical organization +with Linus as the CEO. While the code flows in a hierarchical fashion, +the corporate template does not apply here. Linux is an anarchy held +together by (rarely expressed) mutual respect, trust and convenience. + +All that is to say that managers almost never make good maintainers. +The maintainer position more closely matches an on-call rotation +than a position of power. + +The following characteristics of a person selected as a maintainer +are clear red flags: + + - unknown to the community, never sent an email to the list before + - did not author any of the code + - (when development is contracted) works for a company which paid + for the development rather than the company which did the work + +Non compliance +============== + +Subsystem maintainers may remove inactive maintainers from the MAINTAINERS +file. If the maintainer was a significant author or played an important +role in the development of the code, they should be moved to the CREDITS file. + +Removing an inactive maintainer should not be seen as a punitive action. +Having an inactive maintainer has a real cost as all developers have +to remember to include the maintainers in discussions and subsystem +maintainers spend brain power figuring out how to solicit feedback. + +Subsystem maintainers may remove code for lacking maintenance. + +Subsystem maintainers may refuse accepting code from companies +which repeatedly neglected their maintainership duties. diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst index 3e03283c144e..eeee27f8b18c 100644 --- a/Documentation/maintainer/index.rst +++ b/Documentation/maintainer/index.rst @@ -9,6 +9,7 @@ additions to this manual. .. toctree:: :maxdepth: 2 + feature-and-driver-maintainers configure-git rebasing-and-merging pull-requests diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst index cfd37f31077f..6b64072d4bf2 100644 --- a/Documentation/maintainer/maintainer-entry-profile.rst +++ b/Documentation/maintainer/maintainer-entry-profile.rst @@ -105,3 +105,4 @@ to do something different in the near future. ../driver-api/media/maintainer-entry-profile ../driver-api/vfio-pci-device-specific-driver-acceptance ../nvme/feature-and-quirk-policy + ../filesystems/xfs-maintainer-entry-profile diff --git a/Documentation/maintainer/pull-requests.rst b/Documentation/maintainer/pull-requests.rst index e072de60ccb0..00b200facf67 100644 --- a/Documentation/maintainer/pull-requests.rst +++ b/Documentation/maintainer/pull-requests.rst @@ -1,5 +1,3 @@ -.. _pullrequests: - Creating Pull Requests ====================== @@ -41,7 +39,7 @@ named ``char-misc-next``, you would be using the following command:: that will create a signed tag called ``char-misc-4.15-rc1`` based on the last commit in the ``char-misc-next`` branch, and sign it with your gpg key -(see :ref:`Documentation/maintainer/configure-git.rst <configuregit>`). +(see Documentation/maintainer/configure-git.rst). Linus will only accept pull requests based on a signed tag. Other maintainers may differ. diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst index 756be15a49a4..ecc40fbbcfb8 100644 --- a/Documentation/misc-devices/index.rst +++ b/Documentation/misc-devices/index.rst @@ -28,5 +28,6 @@ fit into other categories. oxsemi-tornado pci-endpoint-test spear-pcie-gadget + tps6594-pfsm uacce xilinx_sdfec diff --git a/Documentation/misc-devices/tps6594-pfsm.rst b/Documentation/misc-devices/tps6594-pfsm.rst new file mode 100644 index 000000000000..4ada37ccdcba --- /dev/null +++ b/Documentation/misc-devices/tps6594-pfsm.rst @@ -0,0 +1,87 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================== +Texas Instruments TPS6594 PFSM driver +===================================== + +Author: Julien Panis (jpanis@baylibre.com) + +Overview +======== + +Strictly speaking, PFSM (Pre-configurable Finite State Machine) is not +hardware. It is a piece of code. + +The TPS6594 PMIC (Power Management IC) integrates a state machine which +manages operational modes. Depending on the current operational mode, +some voltage domains remain energized while others can be off. + +The PFSM driver can be used to trigger transitions between configured +states. It also provides R/W access to the device registers. + +Supported chips +--------------- + +- tps6594-q1 +- tps6593-q1 +- lp8764-q1 + +Driver location +=============== + +drivers/misc/tps6594-pfsm.c + +Driver type definitions +======================= + +include/uapi/linux/tps6594_pfsm.h + +Driver IOCTLs +============= + +:c:macro::`PMIC_GOTO_STANDBY` +All device resources are powered down. The processor is off, and +no voltage domains are energized. + +:c:macro::`PMIC_GOTO_LP_STANDBY` +The digital and analog functions of the PMIC, which are not +required to be always-on, are turned off (low-power). + +:c:macro::`PMIC_UPDATE_PGM` +Triggers a firmware update. + +:c:macro::`PMIC_SET_ACTIVE_STATE` +One of the operational modes. +The PMICs are fully functional and supply power to all PDN loads. +All voltage domains are energized in both MCU and Main processor +sections. + +:c:macro::`PMIC_SET_MCU_ONLY_STATE` +One of the operational modes. +Only the power resources assigned to the MCU Safety Island are on. + +:c:macro::`PMIC_SET_RETENTION_STATE` +One of the operational modes. +Depending on the triggers set, some DDR/GPIO voltage domains can +remain energized, while all other domains are off to minimize +total system power. + +Driver usage +============ + +See available PFSMs:: + + # ls /dev/pfsm* + +Dump the registers of pages 0 and 1:: + + # hexdump -C /dev/pfsm-0-0x48 + +See PFSM events:: + + # cat /proc/interrupts + +Userspace code example +---------------------- + +samples/pfsm/pfsm-wakeup.c diff --git a/Documentation/mm/arch_pgtable_helpers.rst b/Documentation/mm/arch_pgtable_helpers.rst index af3891f895b0..c82e3ee20e51 100644 --- a/Documentation/mm/arch_pgtable_helpers.rst +++ b/Documentation/mm/arch_pgtable_helpers.rst @@ -46,7 +46,11 @@ PTE Page Table Helpers +---------------------------+--------------------------------------------------+ | pte_mkclean | Creates a clean PTE | +---------------------------+--------------------------------------------------+ -| pte_mkwrite | Creates a writable PTE | +| pte_mkwrite | Creates a writable PTE of the type specified by | +| | the VMA. | ++---------------------------+--------------------------------------------------+ +| pte_mkwrite_novma | Creates a writable PTE, of the conventional type | +| | of writable. | +---------------------------+--------------------------------------------------+ | pte_wrprotect | Creates a write protected PTE | +---------------------------+--------------------------------------------------+ @@ -118,7 +122,11 @@ PMD Page Table Helpers +---------------------------+--------------------------------------------------+ | pmd_mkclean | Creates a clean PMD | +---------------------------+--------------------------------------------------+ -| pmd_mkwrite | Creates a writable PMD | +| pmd_mkwrite | Creates a writable PMD of the type specified by | +| | the VMA. | ++---------------------------+--------------------------------------------------+ +| pmd_mkwrite_novma | Creates a writable PMD, of the conventional type | +| | of writable. | +---------------------------+--------------------------------------------------+ | pmd_wrprotect | Creates a write protected PMD | +---------------------------+--------------------------------------------------+ diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst index 0cff6fac6b7e..a20383d01a95 100644 --- a/Documentation/mm/damon/design.rst +++ b/Documentation/mm/damon/design.rst @@ -4,31 +4,55 @@ Design ====== -Configurable Layers -=================== - -DAMON provides data access monitoring functionality while making the accuracy -and the overhead controllable. The fundamental access monitorings require -primitives that dependent on and optimized for the target address space. On -the other hand, the accuracy and overhead tradeoff mechanism, which is the core -of DAMON, is in the pure logic space. DAMON separates the two parts in -different layers and defines its interface to allow various low level -primitives implementations configurable with the core logic. We call the low -level primitives implementations monitoring operations. - -Due to this separated design and the configurable interface, users can extend -DAMON for any address space by configuring the core logics with appropriate -monitoring operations. If appropriate one is not provided, users can implement -the operations on their own. + +Overall Architecture +==================== + +DAMON subsystem is configured with three layers including + +- Operations Set: Implements fundamental operations for DAMON that depends on + the given monitoring target address-space and available set of + software/hardware primitives, +- Core: Implements core logics including monitoring overhead/accurach control + and access-aware system operations on top of the operations set layer, and +- Modules: Implements kernel modules for various purposes that provides + interfaces for the user space, on top of the core layer. + + +Configurable Operations Set +--------------------------- + +For data access monitoring and additional low level work, DAMON needs a set of +implementations for specific operations that are dependent on and optimized for +the given target address space. On the other hand, the accuracy and overhead +tradeoff mechanism, which is the core logic of DAMON, is in the pure logic +space. DAMON separates the two parts in different layers, namely DAMON +Operations Set and DAMON Core Logics Layers, respectively. It further defines +the interface between the layers to allow various operations sets to be +configured with the core logic. + +Due to this design, users can extend DAMON for any address space by configuring +the core logic to use the appropriate operations set. If any appropriate set +is unavailable, users can implement one on their own. For example, physical memory, virtual memory, swap space, those for specific processes, NUMA nodes, files, and backing memory devices would be supportable. -Also, if some architectures or devices support special optimized access check -primitives, those will be easily configurable. +Also, if some architectures or devices supporting special optimized access +check primitives, those will be easily configurable. + + +Programmable Modules +-------------------- + +Core layer of DAMON is implemented as a framework, and exposes its application +programming interface to all kernel space components such as subsystems and +modules. For common use cases of DAMON, DAMON subsystem provides kernel +modules that built on top of the core layer using the API, which can be easily +used by the user space end users. -Reference Implementations of Address Space Specific Monitoring Operations -========================================================================= +Operations Set Layer +==================== The monitoring operations are defined in two parts: @@ -90,8 +114,12 @@ conflict with the reclaim logic using ``PG_idle`` and ``PG_young`` page flags, as Idle page tracking does. -Address Space Independent Core Mechanisms -========================================= +Core Logics +=========== + + +Monitoring +---------- Below four sections describe each of the DAMON core mechanisms and the five monitoring attributes, ``sampling interval``, ``aggregation interval``, @@ -100,7 +128,7 @@ regions``. Access Frequency Monitoring ---------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~ The output of DAMON says what pages are how frequently accessed for a given duration. The resolution of the access frequency is controlled by setting @@ -127,7 +155,7 @@ size of the target workload grows. Region Based Sampling ---------------------- +~~~~~~~~~~~~~~~~~~~~~ To avoid the unbounded increase of the overhead, DAMON groups adjacent pages that assumed to have the same access frequencies into a region. As long as the @@ -144,7 +172,7 @@ assumption is not guaranteed. Adaptive Regions Adjustment ---------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~ Even somehow the initial monitoring target regions are well constructed to fulfill the assumption (pages in same region have similar access frequencies), @@ -162,8 +190,22 @@ In this way, DAMON provides its best-effort quality and minimal overhead while keeping the bounds users set for their trade-off. +Age Tracking +~~~~~~~~~~~~ + +By analyzing the monitoring results, users can also find how long the current +access pattern of a region has maintained. That could be used for good +understanding of the access pattern. For example, page placement algorithm +utilizing both the frequency and the recency could be implemented using that. +To make such access pattern maintained period analysis easier, DAMON maintains +yet another counter called ``age`` in each region. For each ``aggregation +interval``, DAMON checks if the region's size and access frequency +(``nr_accesses``) has significantly changed. If so, the counter is reset to +zero. Otherwise, the counter is increased. + + Dynamic Target Space Updates Handling -------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The monitoring target address range could dynamically changed. For example, virtual memory could be dynamically mapped and unmapped. Physical memory could @@ -174,3 +216,258 @@ monitoring operations to check dynamic changes including memory mapping changes and applies it to monitoring operations-related data structures such as the abstracted monitoring target memory area only for each of a user-specified time interval (``update interval``). + + +.. _damon_design_damos: + +Operation Schemes +----------------- + +One common purpose of data access monitoring is access-aware system efficiency +optimizations. For example, + + paging out memory regions that are not accessed for more than two minutes + +or + + using THP for memory regions that are larger than 2 MiB and showing a high + access frequency for more than one minute. + +One straightforward approach for such schemes would be profile-guided +optimizations. That is, getting data access monitoring results of the +workloads or the system using DAMON, finding memory regions of special +characteristics by profiling the monitoring results, and making system +operation changes for the regions. The changes could be made by modifying or +providing advice to the software (the application and/or the kernel), or +reconfiguring the hardware. Both offline and online approaches could be +available. + +Among those, providing advice to the kernel at runtime would be flexible and +effective, and therefore widely be used. However, implementing such schemes +could impose unnecessary redundancy and inefficiency. The profiling could be +redundant if the type of interest is common. Exchanging the information +including monitoring results and operation advice between kernel and user +spaces could be inefficient. + +To allow users to reduce such redundancy and inefficiencies by offloading the +works, DAMON provides a feature called Data Access Monitoring-based Operation +Schemes (DAMOS). It lets users specify their desired schemes at a high +level. For such specifications, DAMON starts monitoring, finds regions having +the access pattern of interest, and applies the user-desired operation actions +to the regions as soon as found. + + +.. _damon_design_damos_action: + +Operation Action +~~~~~~~~~~~~~~~~ + +The management action that the users desire to apply to the regions of their +interest. For example, paging out, prioritizing for next reclamation victim +selection, advising ``khugepaged`` to collapse or split, or doing nothing but +collecting statistics of the regions. + +The list of supported actions is defined in DAMOS, but the implementation of +each action is in the DAMON operations set layer because the implementation +normally depends on the monitoring target address space. For example, the code +for paging specific virtual address ranges out would be different from that for +physical address ranges. And the monitoring operations implementation sets are +not mandated to support all actions of the list. Hence, the availability of +specific DAMOS action depends on what operations set is selected to be used +together. + +Applying an action to a region is considered as changing the region's +characteristics. Hence, DAMOS resets the age of regions when an action is +applied to those. + + +.. _damon_design_damos_access_pattern: + +Target Access Pattern +~~~~~~~~~~~~~~~~~~~~~ + +The access pattern of the schemes' interest. The patterns are constructed with +the properties that DAMON's monitoring results provide, specifically the size, +the access frequency, and the age. Users can describe their access pattern of +interest by setting minimum and maximum values of the three properties. If a +region's three properties are in the ranges, DAMOS classifies it as one of the +regions that the scheme is having an interest in. + + +.. _damon_design_damos_quotas: + +Quotas +~~~~~~ + +DAMOS upper-bound overhead control feature. DAMOS could incur high overhead if +the target access pattern is not properly tuned. For example, if a huge memory +region having the access pattern of interest is found, applying the scheme's +action to all pages of the huge region could consume unacceptably large system +resources. Preventing such issues by tuning the access pattern could be +challenging, especially if the access patterns of the workloads are highly +dynamic. + +To mitigate that situation, DAMOS provides an upper-bound overhead control +feature called quotas. It lets users specify an upper limit of time that DAMOS +can use for applying the action, and/or a maximum bytes of memory regions that +the action can be applied within a user-specified time duration. + + +.. _damon_design_damos_quotas_prioritization: + +Prioritization +^^^^^^^^^^^^^^ + +A mechanism for making a good decision under the quotas. When the action +cannot be applied to all regions of interest due to the quotas, DAMOS +prioritizes regions and applies the action to only regions having high enough +priorities so that it will not exceed the quotas. + +The prioritization mechanism should be different for each action. For example, +rarely accessed (colder) memory regions would be prioritized for page-out +scheme action. In contrast, the colder regions would be deprioritized for huge +page collapse scheme action. Hence, the prioritization mechanisms for each +action are implemented in each DAMON operations set, together with the actions. + +Though the implementation is up to the DAMON operations set, it would be common +to calculate the priority using the access pattern properties of the regions. +Some users would want the mechanisms to be personalized for their specific +case. For example, some users would want the mechanism to weigh the recency +(``age``) more than the access frequency (``nr_accesses``). DAMOS allows users +to specify the weight of each access pattern property and passes the +information to the underlying mechanism. Nevertheless, how and even whether +the weight will be respected are up to the underlying prioritization mechanism +implementation. + + +.. _damon_design_damos_watermarks: + +Watermarks +~~~~~~~~~~ + +Conditional DAMOS (de)activation automation. Users might want DAMOS to run +only under certain situations. For example, when a sufficient amount of free +memory is guaranteed, running a scheme for proactive reclamation would only +consume unnecessary system resources. To avoid such consumption, the user would +need to manually monitor some metrics such as free memory ratio, and turn +DAMON/DAMOS on or off. + +DAMOS allows users to offload such works using three watermarks. It allows the +users to configure the metric of their interest, and three watermark values, +namely high, middle, and low. If the value of the metric becomes above the +high watermark or below the low watermark, the scheme is deactivated. If the +metric becomes below the mid watermark but above the low watermark, the scheme +is activated. If all schemes are deactivated by the watermarks, the monitoring +is also deactivated. In this case, the DAMON worker thread only periodically +checks the watermarks and therefore incurs nearly zero overhead. + + +.. _damon_design_damos_filters: + +Filters +~~~~~~~ + +Non-access pattern-based target memory regions filtering. If users run +self-written programs or have good profiling tools, they could know something +more than the kernel, such as future access patterns or some special +requirements for specific types of memory. For example, some users may know +only anonymous pages can impact their program's performance. They can also +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). + +Currently, anonymous page, memory cgroup, address range, and DAMON monitoring +target type filters are supported by the feature. Some filter target types +require additional arguments. The memory cgroup filter type asks users to +specify the file path of the memory cgroup for the filter. The address range +type asks the start and end addresses of the range. The DAMON monitoring +target type asks the index of the target from the context's monitoring targets +list. Hence, users can apply specific schemes to only anonymous pages, +non-anonymous pages, pages of specific cgroups, all pages excluding those of +specific cgroups, pages in specific address range, pages in specific DAMON +monitoring targets, and any combination of those. + +To handle filters efficiently, the address range and DAMON monitoring target +type filters are handled by the core layer, while others are handled by +operations set. If a memory region is filtered by a core layer-handled filter, +it is 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. The difference in accounting leads to changes +in the statistics. + + +Application Programming Interface +--------------------------------- + +The programming interface for kernel space data access-aware applications. +DAMON is a framework, so it does nothing by itself. Instead, it only helps +other kernel components such as subsystems and modules building their data +access-aware applications using DAMON's core features. For this, DAMON exposes +its all features to other kernel components via its application programming +interface, namely ``include/linux/damon.h``. Please refer to the API +:doc:`document </mm/damon/api>` for details of the interface. + + +Modules +======= + +Because the core of DAMON is a framework for kernel components, it doesn't +provide any direct interface for the user space. Such interfaces should be +implemented by each DAMON API user kernel components, instead. DAMON subsystem +itself implements such DAMON API user modules, which are supposed to be used +for general purpose DAMON control and special purpose data access-aware system +operations, and provides stable application binary interfaces (ABI) for the +user space. The user space can build their efficient data access-aware +applications using the interfaces. + + +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. + +The ABIs are designed to be used for user space applications development, +rather than human beings' fingers. Human users are recommended to use such +user space tools. One such Python-written user space tool is available at +Github (https://github.com/awslabs/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. + + +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 +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 +control parameters for the usage would also need to be optimized for the +purpose. + +To support such cases, yet more DAMON API user kernel modules that provide more +simple and optimized user space interfaces are available. Currently, two +modules for proactive reclamation and LRU lists manipulation are provided. For +more detail, please read the usage documents for those +(:doc:`/admin-guide/mm/damon/reclaim` and +:doc:`/admin-guide/mm/damon/lru_sort`). diff --git a/Documentation/mm/damon/faq.rst b/Documentation/mm/damon/faq.rst index dde7e2414ee6..3279dc7a8211 100644 --- a/Documentation/mm/damon/faq.rst +++ b/Documentation/mm/damon/faq.rst @@ -4,29 +4,6 @@ Frequently Asked Questions ========================== -Why a new subsystem, instead of extending perf or other user space tools? -========================================================================= - -First, because it needs to be lightweight as much as possible so that it can be -used online, any unnecessary overhead such as kernel - user space context -switching cost should be avoided. Second, DAMON aims to be used by other -programs including the kernel. Therefore, having a dependency on specific -tools like perf is not desirable. These are the two biggest reasons why DAMON -is implemented in the kernel space. - - -Can 'idle pages tracking' or 'perf mem' substitute DAMON? -========================================================= - -Idle page tracking is a low level primitive for access check of the physical -address space. 'perf mem' is similar, though it can use sampling to minimize -the overhead. On the other hand, DAMON is a higher-level framework for the -monitoring of various address spaces. It is focused on memory management -optimization and provides sophisticated accuracy/overhead handling mechanisms. -Therefore, 'idle pages tracking' and 'perf mem' could provide a subset of -DAMON's output, but cannot substitute DAMON. - - Does DAMON support virtual memory only? ======================================= diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst index 24a202f03de8..a84c14e59053 100644 --- a/Documentation/mm/damon/maintainer-profile.rst +++ b/Documentation/mm/damon/maintainer-profile.rst @@ -3,7 +3,7 @@ DAMON Maintainer Entry Profile ============================== -The DAMON subsystem covers the files that listed in 'DATA ACCESS MONITOR' +The DAMON subsystem covers the files that are listed in 'DATA ACCESS MONITOR' section of 'MAINTAINERS' file. The mailing lists for the subsystem are damon@lists.linux.dev and @@ -15,7 +15,7 @@ SCM Trees There are multiple Linux trees for DAMON development. Patches under development or testing are queued in damon/next [2]_ by the DAMON maintainer. -Suffieicntly reviewed patches will be queued in mm-unstable [1]_ by the memory +Sufficiently reviewed patches will be queued in mm-unstable [1]_ by the memory management subsystem maintainer. After more sufficient tests, the patches will be queued in mm-stable [3]_ , and finally pull-requested to the mainline by the memory management subsystem maintainer. diff --git a/Documentation/mm/frontswap.rst b/Documentation/mm/frontswap.rst deleted file mode 100644 index c892412988af..000000000000 --- a/Documentation/mm/frontswap.rst +++ /dev/null @@ -1,264 +0,0 @@ -========= -Frontswap -========= - -Frontswap provides a "transcendent memory" interface for swap pages. -In some environments, dramatic performance savings may be obtained because -swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk. - -.. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/ - -Frontswap is so named because it can be thought of as the opposite of -a "backing" store for a swap device. The storage is assumed to be -a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming -to the requirements of transcendent memory (such as Xen's "tmem", or -in-kernel compressed memory, aka "zcache", or future RAM-like devices); -this pseudo-RAM device is not directly accessible or addressable by the -kernel and is of unknown and possibly time-varying size. The driver -links itself to frontswap by calling frontswap_register_ops to set the -frontswap_ops funcs appropriately and the functions it provides must -conform to certain policies as follows: - -An "init" prepares the device to receive frontswap pages associated -with the specified swap device number (aka "type"). A "store" will -copy the page to transcendent memory and associate it with the type and -offset associated with the page. A "load" will copy the page, if found, -from transcendent memory into kernel memory, but will NOT remove the page -from transcendent memory. An "invalidate_page" will remove the page -from transcendent memory and an "invalidate_area" will remove ALL pages -associated with the swap type (e.g., like swapoff) and notify the "device" -to refuse further stores with that swap type. - -Once a page is successfully stored, a matching load on the page will normally -succeed. So when the kernel finds itself in a situation where it needs -to swap out a page, it first attempts to use frontswap. If the store returns -success, the data has been successfully saved to transcendent memory and -a disk write and, if the data is later read back, a disk read are avoided. -If a store returns failure, transcendent memory has rejected the data, and the -page can be written to swap as usual. - -Note that if a page is stored and the page already exists in transcendent memory -(a "duplicate" store), either the store succeeds and the data is overwritten, -or the store fails AND the page is invalidated. This ensures stale data may -never be obtained from frontswap. - -If properly configured, monitoring of frontswap is done via debugfs in -the `/sys/kernel/debug/frontswap` directory. The effectiveness of -frontswap can be measured (across all swap devices) with: - -``failed_stores`` - how many store attempts have failed - -``loads`` - how many loads were attempted (all should succeed) - -``succ_stores`` - how many store attempts have succeeded - -``invalidates`` - how many invalidates were attempted - -A backend implementation may provide additional metrics. - -FAQ -=== - -* Where's the value? - -When a workload starts swapping, performance falls through the floor. -Frontswap significantly increases performance in many such workloads by -providing a clean, dynamic interface to read and write swap pages to -"transcendent memory" that is otherwise not directly addressable to the kernel. -This interface is ideal when data is transformed to a different form -and size (such as with compression) or secretly moved (as might be -useful for write-balancing for some RAM-like devices). Swap pages (and -evicted page-cache pages) are a great use for this kind of slower-than-RAM- -but-much-faster-than-disk "pseudo-RAM device". - -Frontswap with a fairly small impact on the kernel, -provides a huge amount of flexibility for more dynamic, flexible RAM -utilization in various system configurations: - -In the single kernel case, aka "zcache", pages are compressed and -stored in local memory, thus increasing the total anonymous pages -that can be safely kept in RAM. Zcache essentially trades off CPU -cycles used in compression/decompression for better memory utilization. -Benchmarks have shown little or no impact when memory pressure is -low while providing a significant performance improvement (25%+) -on some workloads under high memory pressure. - -"RAMster" builds on zcache by adding "peer-to-peer" transcendent memory -support for clustered systems. Frontswap pages are locally compressed -as in zcache, but then "remotified" to another system's RAM. This -allows RAM to be dynamically load-balanced back-and-forth as needed, -i.e. when system A is overcommitted, it can swap to system B, and -vice versa. RAMster can also be configured as a memory server so -many servers in a cluster can swap, dynamically as needed, to a single -server configured with a large amount of RAM... without pre-configuring -how much of the RAM is available for each of the clients! - -In the virtual case, the whole point of virtualization is to statistically -multiplex physical resources across the varying demands of multiple -virtual machines. This is really hard to do with RAM and efforts to do -it well with no kernel changes have essentially failed (except in some -well-publicized special-case workloads). -Specifically, the Xen Transcendent Memory backend allows otherwise -"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple -virtual machines, but the pages can be compressed and deduplicated to -optimize RAM utilization. And when guest OS's are induced to surrender -underutilized RAM (e.g. with "selfballooning"), sudden unexpected -memory pressure may result in swapping; frontswap allows those pages -to be swapped to and from hypervisor RAM (if overall host system memory -conditions allow), thus mitigating the potentially awful performance impact -of unplanned swapping. - -A KVM implementation is underway and has been RFC'ed to lkml. And, -using frontswap, investigation is also underway on the use of NVM as -a memory extension technology. - -* Sure there may be performance advantages in some situations, but - what's the space/time overhead of frontswap? - -If CONFIG_FRONTSWAP is disabled, every frontswap hook compiles into -nothingness and the only overhead is a few extra bytes per swapon'ed -swap device. If CONFIG_FRONTSWAP is enabled but no frontswap "backend" -registers, there is one extra global variable compared to zero for -every swap page read or written. If CONFIG_FRONTSWAP is enabled -AND a frontswap backend registers AND the backend fails every "store" -request (i.e. provides no memory despite claiming it might), -CPU overhead is still negligible -- and since every frontswap fail -precedes a swap page write-to-disk, the system is highly likely -to be I/O bound and using a small fraction of a percent of a CPU -will be irrelevant anyway. - -As for space, if CONFIG_FRONTSWAP is enabled AND a frontswap backend -registers, one bit is allocated for every swap page for every swap -device that is swapon'd. This is added to the EIGHT bits (which -was sixteen until about 2.6.34) that the kernel already allocates -for every swap page for every swap device that is swapon'd. (Hugh -Dickins has observed that frontswap could probably steal one of -the existing eight bits, but let's worry about that minor optimization -later.) For very large swap disks (which are rare) on a standard -4K pagesize, this is 1MB per 32GB swap. - -When swap pages are stored in transcendent memory instead of written -out to disk, there is a side effect that this may create more memory -pressure that can potentially outweigh the other advantages. A -backend, such as zcache, must implement policies to carefully (but -dynamically) manage memory limits to ensure this doesn't happen. - -* OK, how about a quick overview of what this frontswap patch does - in terms that a kernel hacker can grok? - -Let's assume that a frontswap "backend" has registered during -kernel initialization; this registration indicates that this -frontswap backend has access to some "memory" that is not directly -accessible by the kernel. Exactly how much memory it provides is -entirely dynamic and random. - -Whenever a swap-device is swapon'd frontswap_init() is called, -passing the swap device number (aka "type") as a parameter. -This notifies frontswap to expect attempts to "store" swap pages -associated with that number. - -Whenever the swap subsystem is readying a page to write to a swap -device (c.f swap_writepage()), frontswap_store is called. Frontswap -consults with the frontswap backend and if the backend says it does NOT -have room, frontswap_store returns -1 and the kernel swaps the page -to the swap device as normal. Note that the response from the frontswap -backend is unpredictable to the kernel; it may choose to never accept a -page, it could accept every ninth page, or it might accept every -page. But if the backend does accept a page, the data from the page -has already been copied and associated with the type and offset, -and the backend guarantees the persistence of the data. In this case, -frontswap sets a bit in the "frontswap_map" for the swap device -corresponding to the page offset on the swap device to which it would -otherwise have written the data. - -When the swap subsystem needs to swap-in a page (swap_readpage()), -it first calls frontswap_load() which checks the frontswap_map to -see if the page was earlier accepted by the frontswap backend. If -it was, the page of data is filled from the frontswap backend and -the swap-in is complete. If not, the normal swap-in code is -executed to obtain the page of data from the real swap device. - -So every time the frontswap backend accepts a page, a swap device read -and (potentially) a swap device write are replaced by a "frontswap backend -store" and (possibly) a "frontswap backend loads", which are presumably much -faster. - -* Can't frontswap be configured as a "special" swap device that is - just higher priority than any real swap device (e.g. like zswap, - or maybe swap-over-nbd/NFS)? - -No. First, the existing swap subsystem doesn't allow for any kind of -swap hierarchy. Perhaps it could be rewritten to accommodate a hierarchy, -but this would require fairly drastic changes. Even if it were -rewritten, the existing swap subsystem uses the block I/O layer which -assumes a swap device is fixed size and any page in it is linearly -addressable. Frontswap barely touches the existing swap subsystem, -and works around the constraints of the block I/O subsystem to provide -a great deal of flexibility and dynamicity. - -For example, the acceptance of any swap page by the frontswap backend is -entirely unpredictable. This is critical to the definition of frontswap -backends because it grants completely dynamic discretion to the -backend. In zcache, one cannot know a priori how compressible a page is. -"Poorly" compressible pages can be rejected, and "poorly" can itself be -defined dynamically depending on current memory constraints. - -Further, frontswap is entirely synchronous whereas a real swap -device is, by definition, asynchronous and uses block I/O. The -block I/O layer is not only unnecessary, but may perform "optimizations" -that are inappropriate for a RAM-oriented device including delaying -the write of some pages for a significant amount of time. Synchrony is -required to ensure the dynamicity of the backend and to avoid thorny race -conditions that would unnecessarily and greatly complicate frontswap -and/or the block I/O subsystem. That said, only the initial "store" -and "load" operations need be synchronous. A separate asynchronous thread -is free to manipulate the pages stored by frontswap. For example, -the "remotification" thread in RAMster uses standard asynchronous -kernel sockets to move compressed frontswap pages to a remote machine. -Similarly, a KVM guest-side implementation could do in-guest compression -and use "batched" hypercalls. - -In a virtualized environment, the dynamicity allows the hypervisor -(or host OS) to do "intelligent overcommit". For example, it can -choose to accept pages only until host-swapping might be imminent, -then force guests to do their own swapping. - -There is a downside to the transcendent memory specifications for -frontswap: Since any "store" might fail, there must always be a real -slot on a real swap device to swap the page. Thus frontswap must be -implemented as a "shadow" to every swapon'd device with the potential -capability of holding every page that the swap device might have held -and the possibility that it might hold no pages at all. This means -that frontswap cannot contain more pages than the total of swapon'd -swap devices. For example, if NO swap device is configured on some -installation, frontswap is useless. Swapless portable devices -can still use frontswap but a backend for such devices must configure -some kind of "ghost" swap device and ensure that it is never used. - -* Why this weird definition about "duplicate stores"? If a page - has been previously successfully stored, can't it always be - successfully overwritten? - -Nearly always it can, but no, sometimes it cannot. Consider an example -where data is compressed and the original 4K page has been compressed -to 1K. Now an attempt is made to overwrite the page with data that -is non-compressible and so would take the entire 4K. But the backend -has no more space. In this case, the store must be rejected. Whenever -frontswap rejects a store that would overwrite, it also must invalidate -the old data and ensure that it is no longer accessible. Since the -swap subsystem then writes the new data to the read swap device, -this is the correct course of action to ensure coherency. - -* Why does the frontswap patch create the new include file swapfile.h? - -The frontswap code depends on some swap-subsystem-internal data -structures that have, over the years, moved back and forth between -static and global. This seemed a reasonable compromise: Define -them as global but declare them in a new include file that isn't -included by the large number of source files that include swap.h. - -Dan Magenheimer, last updated April 9, 2012 diff --git a/Documentation/mm/highmem.rst b/Documentation/mm/highmem.rst index c964e0848702..9d92e3f2b3d6 100644 --- a/Documentation/mm/highmem.rst +++ b/Documentation/mm/highmem.rst @@ -51,11 +51,14 @@ Temporary Virtual Mappings The kernel contains several ways of creating temporary mappings. The following list shows them in order of preference of use. -* kmap_local_page(). This function is used to require short term mappings. - It can be invoked from any context (including interrupts) but the mappings - can only be used in the context which acquired them. - - This function should always be used, whereas kmap_atomic() and kmap() have +* kmap_local_page(), kmap_local_folio() - These functions are used to create + short term mappings. They can be invoked from any context (including + interrupts) but the mappings can only be used in the context which acquired + them. The only differences between them consist in the first taking a pointer + to a struct page and the second taking a pointer to struct folio and the byte + offset within the folio which identifies the page. + + These functions should always be used, whereas kmap_atomic() and kmap() have been deprecated. These mappings are thread-local and CPU-local, meaning that the mapping @@ -72,17 +75,17 @@ list shows them in order of preference of use. maps of the outgoing task are saved and those of the incoming one are restored. - kmap_local_page() always returns a valid virtual address and it is assumed - that kunmap_local() will never fail. + kmap_local_page(), as well as kmap_local_folio() always returns valid virtual + kernel addresses and it is assumed that kunmap_local() will never fail. - On CONFIG_HIGHMEM=n kernels and for low memory pages this returns the + On CONFIG_HIGHMEM=n kernels and for low memory pages they return the virtual address of the direct mapping. Only real highmem pages are temporarily mapped. Therefore, users may call a plain page_address() for pages which are known to not come from ZONE_HIGHMEM. However, it is - always safe to use kmap_local_page() / kunmap_local(). + always safe to use kmap_local_{page,folio}() / kunmap_local(). - While it is significantly faster than kmap(), for the highmem case it - comes with restrictions about the pointers validity. Contrary to kmap() + While they are significantly faster than kmap(), for the highmem case they + come with restrictions about the pointers validity. Contrary to kmap() mappings, the local mappings are only valid in the context of the caller and cannot be handed to other contexts. This implies that users must be absolutely sure to keep the use of the return address local to the @@ -91,7 +94,7 @@ list shows them in order of preference of use. Most code can be designed to use thread local mappings. User should therefore try to design their code to avoid the use of kmap() by mapping pages in the same thread the address will be used and prefer - kmap_local_page(). + kmap_local_page() or kmap_local_folio(). Nesting kmap_local_page() and kmap_atomic() mappings is allowed to a certain extent (up to KMAP_TYPE_NR) but their invocations have to be strictly ordered @@ -206,4 +209,5 @@ Functions ========= .. kernel-doc:: include/linux/highmem.h +.. kernel-doc:: mm/highmem.c .. kernel-doc:: include/linux/highmem-internal.h diff --git a/Documentation/mm/hmm.rst b/Documentation/mm/hmm.rst index 9aa512c3a12c..0595098a74d9 100644 --- a/Documentation/mm/hmm.rst +++ b/Documentation/mm/hmm.rst @@ -163,16 +163,7 @@ use:: It will trigger a page fault on missing or read-only entries if write access is requested (see below). Page faults use the generic mm page fault code path just -like a CPU page fault. - -Both functions copy CPU page table entries into their pfns array argument. Each -entry in that array corresponds to an address in the virtual range. HMM -provides a set of flags to help the driver identify special CPU page table -entries. - -Locking within the sync_cpu_device_pagetables() callback is the most important -aspect the driver must respect in order to keep things properly synchronized. -The usage pattern is:: +like a CPU page fault. The usage pattern is:: int driver_populate_range(...) { @@ -417,7 +408,7 @@ entries. Any attempt to access the swap entry results in a fault which is resovled by replacing the entry with the original mapping. A driver gets notified that the mapping has been changed by MMU notifiers, after which point it will no longer have exclusive access to the page. Exclusive access is -guranteed to last until the driver drops the page lock and page reference, at +guaranteed to last until the driver drops the page lock and page reference, at which point any CPU faults on the page may proceed as described. Memory cgroup (memcg) and rss accounting diff --git a/Documentation/mm/hugetlbfs_reserv.rst b/Documentation/mm/hugetlbfs_reserv.rst index d9c2b0f01dcd..4914fbf07966 100644 --- a/Documentation/mm/hugetlbfs_reserv.rst +++ b/Documentation/mm/hugetlbfs_reserv.rst @@ -271,12 +271,12 @@ to the global reservation count (resv_huge_pages). Freeing Huge Pages ================== -Huge page freeing is performed by the routine free_huge_page(). This routine -is the destructor for hugetlbfs compound pages. As a result, it is only -passed a pointer to the page struct. When a huge page is freed, reservation -accounting may need to be performed. This would be the case if the page was -associated with a subpool that contained reserves, or the page is being freed -on an error path where a global reserve count must be restored. +Huge pages are freed by free_huge_folio(). It is only passed a pointer +to the folio as it is called from the generic MM code. When a huge page +is freed, reservation accounting may need to be performed. This would +be the case if the page was associated with a subpool that contained +reserves, or the page is being freed on an error path where a global +reserve count must be restored. The page->private field points to any subpool associated with the page. If the PagePrivate flag is set, it indicates the global reserve count should @@ -525,7 +525,7 @@ However, there are several instances where errors are encountered after a huge page is allocated but before it is instantiated. In this case, the page allocation has consumed the reservation and made the appropriate subpool, reservation map and global count adjustments. If the page is freed at this -time (before instantiation and clearing of PagePrivate), then free_huge_page +time (before instantiation and clearing of PagePrivate), then free_huge_folio will increment the global reservation count. However, the reservation map indicates the reservation was consumed. This resulting inconsistent state will cause the 'leak' of a reserved huge page. The global reserve count will diff --git a/Documentation/mm/hwpoison.rst b/Documentation/mm/hwpoison.rst index ba48a441feed..483b72aa7c11 100644 --- a/Documentation/mm/hwpoison.rst +++ b/Documentation/mm/hwpoison.rst @@ -48,7 +48,7 @@ of applications. KVM support requires a recent qemu-kvm release. For the KVM use there was need for a new signal type so that KVM can inject the machine check into the guest with the proper address. This in theory allows other applications to handle -memory failures too. The expection is that near all applications +memory failures too. The expectation is that most applications won't do that, but some very specialized ones might. Failure recovery modes diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst index 5a94a921ea40..31d2ac306438 100644 --- a/Documentation/mm/index.rst +++ b/Documentation/mm/index.rst @@ -44,7 +44,6 @@ above structured documentation, or deleted if it has served its purpose. balance damon/index free_page_reporting - frontswap hmm hwpoison hugetlbfs_reserv diff --git a/Documentation/mm/page_migration.rst b/Documentation/mm/page_migration.rst index 313dce18893e..f1ce67a26615 100644 --- a/Documentation/mm/page_migration.rst +++ b/Documentation/mm/page_migration.rst @@ -73,14 +73,13 @@ In kernel use of migrate_pages() It also prevents the swapper or other scans from encountering the page. -2. We need to have a function of type new_page_t that can be +2. We need to have a function of type new_folio_t that can be passed to migrate_pages(). This function should figure out - how to allocate the correct new page given the old page. + how to allocate the correct new folio given the old folio. 3. The migrate_pages() function is called which attempts to do the migration. It will call the function to allocate - the new page for each page that is considered for - moving. + the new folio for each folio that is considered for moving. How migrate_pages() works ========================= @@ -181,7 +180,7 @@ The following events (counters) can be used to monitor page migration. 4. THP_MIGRATION_FAIL: A THP could not be migrated nor it could be split. 5. THP_MIGRATION_SPLIT: A THP was migrated, but not as such: first, the THP had - to be split. After splitting, a migration retry was used for it's sub-pages. + to be split. After splitting, a migration retry was used for its sub-pages. THP_MIGRATION_* events also update the appropriate PGMIGRATE_SUCCESS or PGMIGRATE_FAIL events. For example, a THP migration failure will cause both diff --git a/Documentation/mm/page_tables.rst b/Documentation/mm/page_tables.rst index 96939571d7bc..7840c1891751 100644 --- a/Documentation/mm/page_tables.rst +++ b/Documentation/mm/page_tables.rst @@ -3,3 +3,152 @@ =========== Page Tables =========== + +Paged virtual memory was invented along with virtual memory as a concept in +1962 on the Ferranti Atlas Computer which was the first computer with paged +virtual memory. The feature migrated to newer computers and became a de facto +feature of all Unix-like systems as time went by. In 1985 the feature was +included in the Intel 80386, which was the CPU Linux 1.0 was developed on. + +Page tables map virtual addresses as seen by the CPU into physical addresses +as seen on the external memory bus. + +Linux defines page tables as a hierarchy which is currently five levels in +height. The architecture code for each supported architecture will then +map this to the restrictions of the hardware. + +The physical address corresponding to the virtual address is often referenced +by the underlying physical page frame. The **page frame number** or **pfn** +is the physical address of the page (as seen on the external memory bus) +divided by `PAGE_SIZE`. + +Physical memory address 0 will be *pfn 0* and the highest pfn will be +the last page of physical memory the external address bus of the CPU can +address. + +With a page granularity of 4KB and a address range of 32 bits, pfn 0 is at +address 0x00000000, pfn 1 is at address 0x00001000, pfn 2 is at 0x00002000 +and so on until we reach pfn 0xfffff at 0xfffff000. With 16KB pages pfs are +at 0x00004000, 0x00008000 ... 0xffffc000 and pfn goes from 0 to 0x3fffff. + +As you can see, with 4KB pages the page base address uses bits 12-31 of the +address, and this is why `PAGE_SHIFT` in this case is defined as 12 and +`PAGE_SIZE` is usually defined in terms of the page shift as `(1 << PAGE_SHIFT)` + +Over time a deeper hierarchy has been developed in response to increasing memory +sizes. When Linux was created, 4KB pages and a single page table called +`swapper_pg_dir` with 1024 entries was used, covering 4MB which coincided with +the fact that Torvald's first computer had 4MB of physical memory. Entries in +this single table were referred to as *PTE*:s - page table entries. + +The software page table hierarchy reflects the fact that page table hardware has +become hierarchical and that in turn is done to save page table memory and +speed up mapping. + +One could of course imagine a single, linear page table with enormous amounts +of entries, breaking down the whole memory into single pages. Such a page table +would be very sparse, because large portions of the virtual memory usually +remains unused. By using hierarchical page tables large holes in the virtual +address space does not waste valuable page table memory, because it will suffice +to mark large areas as unmapped at a higher level in the page table hierarchy. + +Additionally, on modern CPUs, a higher level page table entry can point directly +to a physical memory range, which allows mapping a contiguous range of several +megabytes or even gigabytes in a single high-level page table entry, taking +shortcuts in mapping virtual memory to physical memory: there is no need to +traverse deeper in the hierarchy when you find a large mapped range like this. + +The page table hierarchy has now developed into this:: + + +-----+ + | PGD | + +-----+ + | + | +-----+ + +-->| P4D | + +-----+ + | + | +-----+ + +-->| PUD | + +-----+ + | + | +-----+ + +-->| PMD | + +-----+ + | + | +-----+ + +-->| PTE | + +-----+ + + +Symbols on the different levels of the page table hierarchy have the following +meaning beginning from the bottom: + +- **pte**, `pte_t`, `pteval_t` = **Page Table Entry** - mentioned earlier. + The *pte* is an array of `PTRS_PER_PTE` elements of the `pteval_t` type, each + mapping a single page of virtual memory to a single page of physical memory. + The architecture defines the size and contents of `pteval_t`. + + A typical example is that the `pteval_t` is a 32- or 64-bit value with the + upper bits being a **pfn** (page frame number), and the lower bits being some + architecture-specific bits such as memory protection. + + The **entry** part of the name is a bit confusing because while in Linux 1.0 + this did refer to a single page table entry in the single top level page + table, it was retrofitted to be an array of mapping elements when two-level + page tables were first introduced, so the *pte* is the lowermost page + *table*, not a page table *entry*. + +- **pmd**, `pmd_t`, `pmdval_t` = **Page Middle Directory**, the hierarchy right + above the *pte*, with `PTRS_PER_PMD` references to the *pte*:s. + +- **pud**, `pud_t`, `pudval_t` = **Page Upper Directory** was introduced after + the other levels to handle 4-level page tables. It is potentially unused, + or *folded* as we will discuss later. + +- **p4d**, `p4d_t`, `p4dval_t` = **Page Level 4 Directory** was introduced to + handle 5-level page tables after the *pud* was introduced. Now it was clear + that we needed to replace *pgd*, *pmd*, *pud* etc with a figure indicating the + directory level and that we cannot go on with ad hoc names any more. This + is only used on systems which actually have 5 levels of page tables, otherwise + it is folded. + +- **pgd**, `pgd_t`, `pgdval_t` = **Page Global Directory** - the Linux kernel + main page table handling the PGD for the kernel memory is still found in + `swapper_pg_dir`, but each userspace process in the system also has its own + memory context and thus its own *pgd*, found in `struct mm_struct` which + in turn is referenced to in each `struct task_struct`. So tasks have memory + context in the form of a `struct mm_struct` and this in turn has a + `struct pgt_t *pgd` pointer to the corresponding page global directory. + +To repeat: each level in the page table hierarchy is a *array of pointers*, so +the **pgd** contains `PTRS_PER_PGD` pointers to the next level below, **p4d** +contains `PTRS_PER_P4D` pointers to **pud** items and so on. The number of +pointers on each level is architecture-defined.:: + + PMD + --> +-----+ PTE + | ptr |-------> +-----+ + | ptr |- | ptr |-------> PAGE + | ptr | \ | ptr | + | ptr | \ ... + | ... | \ + | ptr | \ PTE + +-----+ +----> +-----+ + | ptr |-------> PAGE + | ptr | + ... + + +Page Table Folding +================== + +If the architecture does not use all the page table levels, they can be *folded* +which means skipped, and all operations performed on page tables will be +compile-time augmented to just skip a level when accessing the next lower +level. + +Page table handling code that wishes to be architecture-neutral, such as the +virtual memory manager, will need to be written so that it traverses all of the +currently five levels. This style should also be preferred for +architecture-specific code, so as to be robust to future changes. diff --git a/Documentation/mm/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst index 50ee0dfc95be..e4f6972eb6c0 100644 --- a/Documentation/mm/split_page_table_lock.rst +++ b/Documentation/mm/split_page_table_lock.rst @@ -14,15 +14,20 @@ tables. Access to higher level tables protected by mm->page_table_lock. There are helpers to lock/unlock a table and other accessor functions: - pte_offset_map_lock() - maps pte and takes PTE table lock, returns pointer to the taken - lock; + maps PTE and takes PTE table lock, returns pointer to PTE with + pointer to its PTE table lock, or returns NULL if no PTE table; + - pte_offset_map_nolock() + maps PTE, returns pointer to PTE with pointer to its PTE table + lock (not taken), or returns NULL if no PTE table; + - pte_offset_map() + maps PTE, returns pointer to PTE, or returns NULL if no PTE table; + - pte_unmap() + unmaps PTE table; - pte_unmap_unlock() unlocks and unmaps PTE table; - pte_alloc_map_lock() - allocates PTE table if needed and take the lock, returns pointer - to taken lock or NULL if allocation failed; - - pte_lockptr() - returns pointer to PTE table lock; + allocates PTE table if needed and takes its lock, returns pointer to + PTE with pointer to its lock, or returns NULL if allocation failed; - pmd_lock() takes PMD table lock, returns pointer to taken lock; - pmd_lockptr() @@ -53,7 +58,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 pgtable_pte_page_ctor() and pgtable_pte_page_dtor(), which +required is done by pagetable_pte_ctor() and pagetable_pte_dtor(), which must be called on PTE table allocation / freeing. Make sure the architecture doesn't use slab allocator for page table @@ -63,8 +68,8 @@ This field shares storage with page->ptl. PMD split lock only makes sense if you have more than two page table levels. -PMD split lock enabling requires pgtable_pmd_page_ctor() call on PMD table -allocation and pgtable_pmd_page_dtor() on freeing. +PMD split lock enabling requires pagetable_pmd_ctor() call on PMD table +allocation and pagetable_pmd_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 @@ -72,7 +77,7 @@ paths: i.e X86_PAE preallocate few PMDs on pgd_alloc(). With everything in place you can set CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK. -NOTE: pgtable_pte_page_ctor() and pgtable_pmd_page_ctor() can fail -- it must +NOTE: pagetable_pte_ctor() and pagetable_pmd_ctor() can fail -- it must be handled properly. page->ptl @@ -92,7 +97,7 @@ trick: split lock with enabled DEBUG_SPINLOCK or DEBUG_LOCK_ALLOC, but costs one more cache line for indirect access; -The spinlock_t allocated in pgtable_pte_page_ctor() for PTE table and in -pgtable_pmd_page_ctor() for PMD table. +The spinlock_t allocated in pagetable_pte_ctor() for PTE table and in +pagetable_pmd_ctor() for PMD table. Please, never access page->ptl directly -- use appropriate helper. diff --git a/Documentation/mm/unevictable-lru.rst b/Documentation/mm/unevictable-lru.rst index d5ac8511eb67..67f1338440a5 100644 --- a/Documentation/mm/unevictable-lru.rst +++ b/Documentation/mm/unevictable-lru.rst @@ -463,7 +463,7 @@ can request that a region of memory be mlocked by supplying the MAP_LOCKED flag to the mmap() call. There is one important and subtle difference here, though. mmap() + mlock() will fail if the range cannot be faulted in (e.g. because mm_populate fails) and returns with ENOMEM while mmap(MAP_LOCKED) will not fail. -The mmaped area will still have properties of the locked area - pages will not +The mmapped area will still have properties of the locked area - pages will not get swapped out - but major page faults to fault memory in might still happen. Furthermore, any mmap() call or brk() call that expands the heap by a task diff --git a/Documentation/mm/vmemmap_dedup.rst b/Documentation/mm/vmemmap_dedup.rst index a4b12ff906c4..59891f72420e 100644 --- a/Documentation/mm/vmemmap_dedup.rst +++ b/Documentation/mm/vmemmap_dedup.rst @@ -1,3 +1,4 @@ + .. SPDX-License-Identifier: GPL-2.0 ========================================= @@ -10,14 +11,14 @@ HugeTLB This section is to explain how HugeTLB Vmemmap Optimization (HVO) works. The ``struct page`` structures are used to describe a physical page frame. By -default, there is a one-to-one mapping from a page frame to it's corresponding +default, there is a one-to-one mapping from a page frame to its corresponding ``struct page``. HugeTLB pages consist of multiple base page size pages and is supported by many architectures. See Documentation/admin-guide/mm/hugetlbpage.rst for more details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB are currently supported. Since the base page size on x86 is 4KB, a 2MB HugeTLB page -consists of 512 base pages and a 1GB HugeTLB page consists of 4096 base pages. +consists of 512 base pages and a 1GB HugeTLB page consists of 262144 base pages. For each base page, there is a corresponding ``struct page``. Within the HugeTLB subsystem, only the first 4 ``struct page`` are used to @@ -210,6 +211,7 @@ the device (altmap). The following page sizes are supported in DAX: PAGE_SIZE (4K on x86_64), PMD_SIZE (2M on x86_64) and PUD_SIZE (1G on x86_64). +For powerpc equivalent details see Documentation/powerpc/vmemmap_dedup.rst The differences with HugeTLB are relatively minor. diff --git a/Documentation/mm/zsmalloc.rst b/Documentation/mm/zsmalloc.rst index a3c26d587752..76902835e68e 100644 --- a/Documentation/mm/zsmalloc.rst +++ b/Documentation/mm/zsmalloc.rst @@ -263,3 +263,8 @@ is heavy internal fragmentation and zspool compaction is unable to relocate objects and release zspages. In these cases, it is recommended to decrease the limit on the size of the zspage chains (as specified by the CONFIG_ZSMALLOC_CHAIN_SIZE option). + +Functions +========= + +.. kernel-doc:: mm/zsmalloc.c diff --git a/Documentation/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml index 8e8c17b0a6c6..9806c44f604c 100644 --- a/Documentation/netlink/genetlink-c.yaml +++ b/Documentation/netlink/genetlink-c.yaml @@ -41,7 +41,7 @@ properties: description: Name of the define for the family name. type: string c-version-name: - description: Name of the define for the verion of the family. + description: Name of the define for the version of the family. type: string max-by-define: description: Makes the number of attributes and commands be specified by a define, not an enum value. @@ -195,6 +195,16 @@ properties: description: Max length for a string or a binary attribute. $ref: '#/$defs/len-or-define' sub-type: *attr-type + display-hint: &display-hint + description: | + Optional format indicator that is intended only for choosing + the right formatting mechanism when displaying values of this + type. + enum: [ hex, mac, fddi, ipv4, ipv6, uuid ] + # Start genetlink-c + name-prefix: + type: string + # End genetlink-c # Make sure name-prefix does not appear in subsets (subsets inherit naming) dependencies: @@ -264,7 +274,7 @@ properties: description: Kernel attribute validation flags. type: array items: - enum: [ strict, dump ] + enum: [ strict, dump, dump-strict ] do: &subop-type description: Main command handler. type: object diff --git a/Documentation/netlink/genetlink-legacy.yaml b/Documentation/netlink/genetlink-legacy.yaml index b33541a51d6b..12a0a045605d 100644 --- a/Documentation/netlink/genetlink-legacy.yaml +++ b/Documentation/netlink/genetlink-legacy.yaml @@ -41,7 +41,7 @@ properties: description: Name of the define for the family name. type: string c-version-name: - description: Name of the define for the verion of the family. + description: Name of the define for the version of the family. type: string max-by-define: description: Makes the number of attributes and commands be specified by a define, not an enum value. @@ -119,9 +119,24 @@ properties: name: type: string type: - enum: [ u8, u16, u32, u64, s8, s16, s32, s64, string ] + description: The netlink attribute type + enum: [ u8, u16, u32, u64, s8, s16, s32, s64, string, binary ] len: $ref: '#/$defs/len-or-define' + byte-order: + enum: [ little-endian, big-endian ] + doc: + description: Documentation for the struct member attribute. + type: string + enum: + description: Name of the enum type used for the attribute. + type: string + display-hint: &display-hint + description: | + Optional format indicator that is intended only for choosing + the right formatting mechanism when displaying values of this + type. + enum: [ hex, mac, fddi, ipv4, ipv6, uuid ] # End genetlink-legacy attribute-sets: @@ -171,6 +186,7 @@ properties: name: type: string type: &attr-type + description: The netlink attribute type enum: [ unused, pad, flag, binary, u8, u16, u32, u64, s32, s64, string, nest, array-nest, nest-type-value ] doc: @@ -218,6 +234,11 @@ properties: description: Max length for a string or a binary attribute. $ref: '#/$defs/len-or-define' sub-type: *attr-type + display-hint: *display-hint + # Start genetlink-c + name-prefix: + type: string + # End genetlink-c # Start genetlink-legacy struct: description: Name of the struct type used for the attribute. @@ -300,7 +321,7 @@ properties: description: Kernel attribute validation flags. type: array items: - enum: [ strict, dump ] + enum: [ strict, dump, dump-strict ] # Start genetlink-legacy fixed-header: *fixed-header # End genetlink-legacy diff --git a/Documentation/netlink/genetlink.yaml b/Documentation/netlink/genetlink.yaml index d8b2cdeba058..3d338c48bf21 100644 --- a/Documentation/netlink/genetlink.yaml +++ b/Documentation/netlink/genetlink.yaml @@ -168,6 +168,12 @@ properties: description: Max length for a string or a binary attribute. $ref: '#/$defs/len-or-define' sub-type: *attr-type + display-hint: &display-hint + description: | + Optional format indicator that is intended only for choosing + the right formatting mechanism when displaying values of this + type. + enum: [ hex, mac, fddi, ipv4, ipv6, uuid ] # Make sure name-prefix does not appear in subsets (subsets inherit naming) dependencies: @@ -237,7 +243,7 @@ properties: description: Kernel attribute validation flags. type: array items: - enum: [ strict, dump ] + enum: [ strict, dump, dump-strict ] do: &subop-type description: Main command handler. type: object diff --git a/Documentation/netlink/netlink-raw.yaml b/Documentation/netlink/netlink-raw.yaml new file mode 100644 index 000000000000..896797876414 --- /dev/null +++ b/Documentation/netlink/netlink-raw.yaml @@ -0,0 +1,410 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) +%YAML 1.2 +--- +$id: http://kernel.org/schemas/netlink/netlink-raw.yaml# +$schema: https://json-schema.org/draft-07/schema + +# Common defines +$defs: + uint: + type: integer + minimum: 0 + len-or-define: + type: [ string, integer ] + pattern: ^[0-9A-Za-z_]+( - 1)?$ + minimum: 0 + +# Schema for specs +title: Protocol +description: Specification of a raw netlink protocol +type: object +required: [ name, doc, attribute-sets, operations ] +additionalProperties: False +properties: + name: + description: Name of the netlink family. + type: string + doc: + type: string + protocol: + description: Schema compatibility level. + enum: [ netlink-raw ] # Trim + # Start netlink-raw + protonum: + description: Protocol number to use for netlink-raw + type: integer + # End netlink-raw + uapi-header: + description: Path to the uAPI header, default is linux/${family-name}.h + type: string + # Start genetlink-c + c-family-name: + description: Name of the define for the family name. + type: string + c-version-name: + description: Name of the define for the version of the family. + type: string + max-by-define: + description: Makes the number of attributes and commands be specified by a define, not an enum value. + type: boolean + # End genetlink-c + # Start genetlink-legacy + kernel-policy: + description: | + Defines if the input policy in the kernel is global, per-operation, or split per operation type. + Default is split. + enum: [ split, per-op, global ] + # End genetlink-legacy + + definitions: + description: List of type and constant definitions (enums, flags, defines). + type: array + items: + type: object + required: [ type, name ] + additionalProperties: False + properties: + name: + type: string + header: + description: For C-compatible languages, header which already defines this value. + type: string + type: + enum: [ const, enum, flags, struct ] # Trim + doc: + type: string + # For const + value: + description: For const - the value. + type: [ string, integer ] + # For enum and flags + value-start: + description: For enum or flags the literal initializer for the first value. + type: [ string, integer ] + entries: + description: For enum or flags array of values. + type: array + items: + oneOf: + - type: string + - type: object + required: [ name ] + additionalProperties: False + properties: + name: + type: string + value: + type: integer + doc: + type: string + render-max: + description: Render the max members for this enum. + type: boolean + # Start genetlink-c + enum-name: + description: Name for enum, if empty no name will be used. + type: [ string, "null" ] + name-prefix: + description: For enum the prefix of the values, optional. + type: string + # End genetlink-c + # Start genetlink-legacy + members: + description: List of struct members. Only scalars and strings members allowed. + type: array + items: + type: object + required: [ name, type ] + additionalProperties: False + properties: + name: + type: string + type: + description: The netlink attribute type + enum: [ u8, u16, u32, u64, s8, s16, s32, s64, string, binary ] + len: + $ref: '#/$defs/len-or-define' + byte-order: + enum: [ little-endian, big-endian ] + doc: + description: Documentation for the struct member attribute. + type: string + enum: + description: Name of the enum type used for the attribute. + type: string + enum-as-flags: + description: | + Treat the enum as flags. In most cases enum is either used as flags or as values. + Sometimes, however, both forms are necessary, in which case header contains the enum + form while specific attributes may request to convert the values into a bitfield. + type: boolean + display-hint: &display-hint + description: | + Optional format indicator that is intended only for choosing + the right formatting mechanism when displaying values of this + type. + enum: [ hex, mac, fddi, ipv4, ipv6, uuid ] + # End genetlink-legacy + + attribute-sets: + description: Definition of attribute spaces for this family. + type: array + items: + description: Definition of a single attribute space. + type: object + required: [ name, attributes ] + additionalProperties: False + properties: + name: + description: | + Name used when referring to this space in other definitions, not used outside of the spec. + type: string + name-prefix: + description: | + Prefix for the C enum name of the attributes. Default family[name]-set[name]-a- + type: string + enum-name: + description: Name for the enum type of the attribute. + type: string + doc: + description: Documentation of the space. + type: string + subset-of: + description: | + Name of another space which this is a logical part of. Sub-spaces can be used to define + a limited group of attributes which are used in a nest. + type: string + # Start genetlink-c + attr-cnt-name: + description: The explicit name for constant holding the count of attributes (last attr + 1). + type: string + attr-max-name: + description: The explicit name for last member of attribute enum. + type: string + # End genetlink-c + attributes: + description: List of attributes in the space. + type: array + items: + type: object + required: [ name, type ] + additionalProperties: False + properties: + name: + type: string + type: &attr-type + description: The netlink attribute type + enum: [ unused, pad, flag, binary, u8, u16, u32, u64, s32, s64, + string, nest, array-nest, nest-type-value ] + doc: + description: Documentation of the attribute. + type: string + value: + description: Value for the enum item representing this attribute in the uAPI. + $ref: '#/$defs/uint' + type-value: + description: Name of the value extracted from the type of a nest-type-value attribute. + type: array + items: + type: string + byte-order: + enum: [ little-endian, big-endian ] + multi-attr: + type: boolean + nested-attributes: + description: Name of the space (sub-space) used inside the attribute. + type: string + enum: + description: Name of the enum type used for the attribute. + type: string + enum-as-flags: + description: | + Treat the enum as flags. In most cases enum is either used as flags or as values. + Sometimes, however, both forms are necessary, in which case header contains the enum + form while specific attributes may request to convert the values into a bitfield. + type: boolean + checks: + description: Kernel input validation. + type: object + additionalProperties: False + properties: + flags-mask: + description: Name of the flags constant on which to base mask (unsigned scalar types only). + type: string + min: + description: Min value for an integer attribute. + type: integer + min-len: + description: Min length for a binary attribute. + $ref: '#/$defs/len-or-define' + max-len: + description: Max length for a string or a binary attribute. + $ref: '#/$defs/len-or-define' + sub-type: *attr-type + display-hint: *display-hint + # Start genetlink-c + name-prefix: + type: string + # End genetlink-c + # Start genetlink-legacy + struct: + description: Name of the struct type used for the attribute. + type: string + # End genetlink-legacy + + # Make sure name-prefix does not appear in subsets (subsets inherit naming) + dependencies: + name-prefix: + not: + required: [ subset-of ] + subset-of: + not: + required: [ name-prefix ] + + operations: + description: Operations supported by the protocol. + type: object + required: [ list ] + additionalProperties: False + properties: + enum-model: + description: | + The model of assigning values to the operations. + "unified" is the recommended model where all message types belong + to a single enum. + "directional" has the messages sent to the kernel and from the kernel + enumerated separately. + enum: [ unified, directional ] # Trim + name-prefix: + description: | + Prefix for the C enum name of the command. The name is formed by concatenating + the prefix with the upper case name of the command, with dashes replaced by underscores. + type: string + enum-name: + description: Name for the enum type with commands. + type: string + async-prefix: + description: Same as name-prefix but used to render notifications and events to separate enum. + type: string + async-enum: + description: Name for the enum type with notifications/events. + type: string + # Start genetlink-legacy + fixed-header: &fixed-header + description: | + Name of the structure defining the optional fixed-length protocol + header. This header is placed in a message after the netlink and + genetlink headers and before any attributes. + type: string + # End genetlink-legacy + list: + description: List of commands + type: array + items: + type: object + additionalProperties: False + required: [ name, doc ] + properties: + name: + description: Name of the operation, also defining its C enum value in uAPI. + type: string + doc: + description: Documentation for the command. + type: string + value: + description: Value for the enum in the uAPI. + $ref: '#/$defs/uint' + attribute-set: + description: | + Attribute space from which attributes directly in the requests and replies + to this command are defined. + type: string + flags: &cmd_flags + description: Command flags. + type: array + items: + enum: [ admin-perm ] + dont-validate: + description: Kernel attribute validation flags. + type: array + items: + enum: [ strict, dump ] + # Start genetlink-legacy + fixed-header: *fixed-header + # End genetlink-legacy + do: &subop-type + description: Main command handler. + type: object + additionalProperties: False + properties: + request: &subop-attr-list + description: Definition of the request message for a given command. + type: object + additionalProperties: False + properties: + attributes: + description: | + Names of attributes from the attribute-set (not full attribute + definitions, just names). + type: array + items: + type: string + # Start genetlink-legacy + value: + description: | + ID of this message if value for request and response differ, + i.e. requests and responses have different message enums. + $ref: '#/$defs/uint' + # End genetlink-legacy + reply: *subop-attr-list + pre: + description: Hook for a function to run before the main callback (pre_doit or start). + type: string + post: + description: Hook for a function to run after the main callback (post_doit or done). + type: string + dump: *subop-type + notify: + description: Name of the command sharing the reply type with this notification. + type: string + event: + type: object + additionalProperties: False + properties: + attributes: + description: Explicit list of the attributes for the notification. + type: array + items: + type: string + mcgrp: + description: Name of the multicast group generating given notification. + type: string + mcast-groups: + description: List of multicast groups. + type: object + required: [ list ] + additionalProperties: False + properties: + list: + description: List of groups. + type: array + items: + type: object + required: [ name ] + additionalProperties: False + properties: + name: + description: | + The name for the group, used to form the define and the value of the define. + type: string + # Start genetlink-c + c-define-name: + description: Override for the name of the define in C uAPI. + type: string + # End genetlink-c + flags: *cmd_flags + # Start netlink-raw + value: + description: Value of the netlink multicast group in the uAPI. + type: integer + # End netlink-raw diff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netlink/specs/devlink.yaml index 90641668232e..d1ebcd927149 100644 --- a/Documentation/netlink/specs/devlink.yaml +++ b/Documentation/netlink/specs/devlink.yaml @@ -6,9 +6,20 @@ protocol: genetlink-legacy doc: Partial family for Devlink. +definitions: + - + type: enum + name: sb-pool-type + entries: + - + name: ingress + - + name: egress + attribute-sets: - name: devlink + name-prefix: devlink-attr- attributes: - name: bus-name @@ -24,6 +35,46 @@ attribute-sets: # TODO: fill in the attributes in between - + name: sb-index + type: u32 + value: 11 + + # TODO: fill in the attributes in between + + - + name: sb-pool-index + type: u16 + value: 17 + + - + name: sb-pool-type + type: u8 + enum: sb-pool-type + + # TODO: fill in the attributes in between + + - + name: sb-tc-index + type: u16 + value: 22 + + # TODO: fill in the attributes in between + + - + name: param-name + type: string + value: 81 + + # TODO: fill in the attributes in between + + - + name: region-name + type: string + value: 88 + + # TODO: fill in the attributes in between + + - name: info-driver-name type: string value: 98 @@ -55,9 +106,34 @@ attribute-sets: # TODO: fill in the attributes in between - + name: health-reporter-name + type: string + value: 115 + + # TODO: fill in the attributes in between + + - + name: trap-name + type: string + value: 130 + + # TODO: fill in the attributes in between + + - + name: trap-group-name + type: string + value: 135 + + - name: reload-failed type: u8 - value: 136 + + # TODO: fill in the attributes in between + + - + name: trap-policer-id + type: u32 + value: 142 # TODO: fill in the attributes in between @@ -95,11 +171,28 @@ attribute-sets: - name: reload-action-info type: nest + multi-attr: true nested-attributes: dl-reload-act-info - name: reload-action-stats type: nest + multi-attr: true nested-attributes: dl-reload-act-stats + + # TODO: fill in the attributes in between + + - + name: rate-node-name + type: string + value: 168 + + # TODO: fill in the attributes in between + + - + name: linecard-index + type: u32 + value: 171 + - name: dl-dev-stats subset-of: devlink @@ -162,8 +255,13 @@ operations: name: get doc: Get devlink instances. attribute-set: devlink + dont-validate: + - strict + - dump do: + pre: devlink-nl-pre-doit + post: devlink-nl-post-doit request: value: 1 attributes: &dev-id-attrs @@ -180,19 +278,396 @@ operations: dump: reply: *get-reply + - + name: port-get + doc: Get devlink port instances. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit-port + post: devlink-nl-post-doit + request: + value: 5 + attributes: &port-id-attrs + - bus-name + - dev-name + - port-index + reply: + value: 7 + attributes: *port-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: + value: 3 # due to a bug, port dump returns DEVLINK_CMD_NEW + attributes: *port-id-attrs + + # TODO: fill in the operations in between + + - + name: sb-get + doc: Get shared buffer instances. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit + post: devlink-nl-post-doit + request: + value: 11 + attributes: &sb-id-attrs + - bus-name + - dev-name + - sb-index + reply: &sb-get-reply + value: 11 + attributes: *sb-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: *sb-get-reply + + # TODO: fill in the operations in between + + - + name: sb-pool-get + doc: Get shared buffer pool instances. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit + post: devlink-nl-post-doit + request: + value: 15 + attributes: &sb-pool-id-attrs + - bus-name + - dev-name + - sb-index + - sb-pool-index + reply: &sb-pool-get-reply + value: 15 + attributes: *sb-pool-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: *sb-pool-get-reply + + # TODO: fill in the operations in between + + - + name: sb-port-pool-get + doc: Get shared buffer port-pool combinations and threshold. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit-port + post: devlink-nl-post-doit + request: + value: 19 + attributes: &sb-port-pool-id-attrs + - bus-name + - dev-name + - port-index + - sb-index + - sb-pool-index + reply: &sb-port-pool-get-reply + value: 19 + attributes: *sb-port-pool-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: *sb-port-pool-get-reply + + # TODO: fill in the operations in between + + - + name: sb-tc-pool-bind-get + doc: Get shared buffer port-TC to pool bindings and threshold. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit-port + post: devlink-nl-post-doit + request: + value: 23 + attributes: &sb-tc-pool-bind-id-attrs + - bus-name + - dev-name + - port-index + - sb-index + - sb-pool-type + - sb-tc-index + reply: &sb-tc-pool-bind-get-reply + value: 23 + attributes: *sb-tc-pool-bind-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: *sb-tc-pool-bind-get-reply + + # TODO: fill in the operations in between + + - + name: param-get + doc: Get param instances. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit + post: devlink-nl-post-doit + request: + value: 38 + attributes: ¶m-id-attrs + - bus-name + - dev-name + - param-name + reply: ¶m-get-reply + value: 38 + attributes: *param-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: *param-get-reply + + # TODO: fill in the operations in between + + - + name: region-get + doc: Get region instances. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit-port-optional + post: devlink-nl-post-doit + request: + value: 42 + attributes: ®ion-id-attrs + - bus-name + - dev-name + - port-index + - region-name + reply: ®ion-get-reply + value: 42 + attributes: *region-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: *region-get-reply + # TODO: fill in the operations in between - name: info-get doc: Get device information, like driver name, hardware and firmware versions etc. attribute-set: devlink + dont-validate: + - strict + - dump do: + pre: devlink-nl-pre-doit + post: devlink-nl-post-doit request: value: 51 attributes: *dev-id-attrs - reply: + reply: &info-get-reply value: 51 attributes: - bus-name - dev-name + - info-driver-name + - info-serial-number + - info-version-fixed + - info-version-running + - info-version-stored + dump: + reply: *info-get-reply + + - + name: health-reporter-get + doc: Get health reporter instances. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit-port-optional + post: devlink-nl-post-doit + request: + attributes: &health-reporter-id-attrs + - bus-name + - dev-name + - port-index + - health-reporter-name + reply: &health-reporter-get-reply + attributes: *health-reporter-id-attrs + dump: + request: + attributes: *port-id-attrs + reply: *health-reporter-get-reply + + # TODO: fill in the operations in between + + - + name: trap-get + doc: Get trap instances. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit + post: devlink-nl-post-doit + request: + value: 61 + attributes: &trap-id-attrs + - bus-name + - dev-name + - trap-name + reply: &trap-get-reply + value: 61 + attributes: *trap-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: *trap-get-reply + + # TODO: fill in the operations in between + + - + name: trap-group-get + doc: Get trap group instances. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit + post: devlink-nl-post-doit + request: + value: 65 + attributes: &trap-group-id-attrs + - bus-name + - dev-name + - trap-group-name + reply: &trap-group-get-reply + value: 65 + attributes: *trap-group-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: *trap-group-get-reply + + # TODO: fill in the operations in between + + - + name: trap-policer-get + doc: Get trap policer instances. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit + post: devlink-nl-post-doit + request: + value: 69 + attributes: &trap-policer-id-attrs + - bus-name + - dev-name + - trap-policer-id + reply: &trap-policer-get-reply + value: 69 + attributes: *trap-policer-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: *trap-policer-get-reply + + # TODO: fill in the operations in between + + - + name: rate-get + doc: Get rate instances. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit + post: devlink-nl-post-doit + request: + value: 74 + attributes: &rate-id-attrs + - bus-name + - dev-name + - port-index + - rate-node-name + reply: &rate-get-reply + value: 74 + attributes: *rate-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: *rate-get-reply + + # TODO: fill in the operations in between + + - + name: linecard-get + doc: Get line card instances. + attribute-set: devlink + dont-validate: + - strict + + do: + pre: devlink-nl-pre-doit + post: devlink-nl-post-doit + request: + value: 78 + attributes: &linecard-id-attrs + - bus-name + - dev-name + - linecard-index + reply: &linecard-get-reply + value: 78 + attributes: *linecard-id-attrs + dump: + request: + attributes: *dev-id-attrs + reply: *linecard-get-reply + + # TODO: fill in the operations in between + + - + name: selftests-get + doc: Get device selftest instances. + attribute-set: devlink + dont-validate: + - strict + - dump + + do: + pre: devlink-nl-pre-doit + post: devlink-nl-post-doit + request: + value: 82 + attributes: *dev-id-attrs + reply: &selftests-get-reply + value: 82 + attributes: *dev-id-attrs + dump: + reply: *selftests-get-reply diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml index 4846345bade4..837b565577ca 100644 --- a/Documentation/netlink/specs/ethtool.yaml +++ b/Documentation/netlink/specs/ethtool.yaml @@ -9,8 +9,13 @@ doc: Partial family for Ethtool Netlink. definitions: - name: udp-tunnel-type + enum-name: type: enum entries: [ vxlan, geneve, vxlan-gpe ] + - + name: stringset + type: enum + entries: [] attribute-sets: - @@ -497,7 +502,7 @@ attribute-sets: attributes: - name: pad - type: u32 + type: pad - name: tx-frames type: u64 @@ -577,7 +582,7 @@ attribute-sets: name: phc-index type: u32 - - name: cable-test-ntf-nest-result + name: cable-result attributes: - name: pair @@ -586,7 +591,7 @@ attribute-sets: name: code type: u8 - - name: cable-test-ntf-nest-fault-length + name: cable-fault-length attributes: - name: pair @@ -595,16 +600,16 @@ attribute-sets: name: cm type: u32 - - name: cable-test-ntf-nest + name: cable-nest attributes: - name: result type: nest - nested-attributes: cable-test-ntf-nest-result + nested-attributes: cable-result - name: fault-length type: nest - nested-attributes: cable-test-ntf-nest-fault-length + nested-attributes: cable-fault-length - name: cable-test attributes: @@ -612,13 +617,20 @@ attribute-sets: name: header type: nest nested-attributes: header + - + name: cable-test-ntf + attributes: + - + name: header + type: nest + nested-attributes: header - name: status type: u8 - name: nest type: nest - nested-attributes: cable-test-ntf-nest + nested-attributes: cable-nest - name: cable-test-tdr-cfg attributes: @@ -632,9 +644,23 @@ attribute-sets: name: step type: u32 - - name: pari + name: pair type: u8 - + name: cable-test-tdr-ntf + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: status + type: u8 + - + name: nest + type: nest + nested-attributes: cable-nest + - name: cable-test-tdr attributes: - @@ -646,7 +672,7 @@ attribute-sets: type: nest nested-attributes: cable-test-tdr-cfg - - name: tunnel-info-udp-entry + name: tunnel-udp-entry attributes: - name: port @@ -657,7 +683,7 @@ attribute-sets: type: u32 enum: udp-tunnel-type - - name: tunnel-info-udp-table + name: tunnel-udp-table attributes: - name: size @@ -667,9 +693,17 @@ attribute-sets: type: nest nested-attributes: bitset - - name: udp-ports + name: entry type: nest - nested-attributes: tunnel-info-udp-entry + multi-attr: true + nested-attributes: tunnel-udp-entry + - + name: tunnel-udp + attributes: + - + name: table + type: nest + nested-attributes: tunnel-udp-table - name: tunnel-info attributes: @@ -680,13 +714,13 @@ attribute-sets: - name: udp-ports type: nest - nested-attributes: tunnel-info-udp-table + nested-attributes: tunnel-udp - name: fec-stat attributes: - name: pad - type: u8 + type: pad - name: corrected type: binary @@ -750,7 +784,7 @@ attribute-sets: attributes: - name: pad - type: u32 + type: pad - name: id type: u32 @@ -759,16 +793,29 @@ attribute-sets: type: u32 - name: stat - type: nest - nested-attributes: u64 + type: u64 + type-value: [ id ] - name: hist-rx type: nest - nested-attributes: u64 + nested-attributes: stats-grp-hist - name: hist-tx type: nest - nested-attributes: u64 + nested-attributes: stats-grp-hist + - + name: hist-bkt-low + type: u32 + - + name: hist-bkt-hi + type: u32 + - + name: hist-val + type: u64 + - + name: stats-grp-hist + subset-of: stats-grp + attributes: - name: hist-bkt-low type: u32 @@ -783,7 +830,7 @@ attribute-sets: attributes: - name: pad - type: u32 + type: pad - name: header type: nest @@ -836,12 +883,15 @@ attribute-sets: - name: admin-state type: u32 + name-prefix: ethtool-a-podl-pse- - name: admin-control type: u32 + name-prefix: ethtool-a-podl-pse- - name: pw-d-status type: u32 + name-prefix: ethtool-a-podl-pse- - name: rss attributes: @@ -895,6 +945,7 @@ attribute-sets: operations: enum-model: directional + name-prefix: ethtool-msg- list: - name: strset-get @@ -1348,10 +1399,16 @@ operations: request: attributes: - header - reply: - attributes: - - header - - cable-test-ntf-nest + - + name: cable-test-ntf + doc: Cable test notification. + + attribute-set: cable-test-ntf + + event: + attributes: + - header + - status - name: cable-test-tdr-act doc: Cable test TDR. @@ -1362,10 +1419,17 @@ operations: request: attributes: - header - reply: - attributes: - - header - - cable-test-tdr-cfg + - + name: cable-test-tdr-ntf + doc: Cable test TDR notification. + + attribute-set: cable-test-tdr-ntf + + event: + attributes: + - header + - status + - nest - name: tunnel-info-get doc: Get tsinfo params. diff --git a/Documentation/netlink/specs/fou.yaml b/Documentation/netlink/specs/fou.yaml index 3e13826a3fdf..0af5ab842c04 100644 --- a/Documentation/netlink/specs/fou.yaml +++ b/Documentation/netlink/specs/fou.yaml @@ -107,16 +107,16 @@ operations: flags: [ admin-perm ] do: - request: &select_attrs + request: &select_attrs attributes: - - af - - ifindex - - port - - peer_port - - local_v4 - - peer_v4 - - local_v6 - - peer_v6 + - af + - ifindex + - port + - peer_port + - local_v4 + - peer_v4 + - local_v6 + - peer_v6 - name: get diff --git a/Documentation/netlink/specs/netdev.yaml b/Documentation/netlink/specs/netdev.yaml index b99e7ffef7a1..1c7284fd535b 100644 --- a/Documentation/netlink/specs/netdev.yaml +++ b/Documentation/netlink/specs/netdev.yaml @@ -14,7 +14,7 @@ definitions: - name: basic doc: - XDP feautues set supported by all drivers + XDP features set supported by all drivers (XDP_ABORTED, XDP_DROP, XDP_PASS, XDP_TX) - name: redirect @@ -62,6 +62,12 @@ attribute-sets: type: u64 enum: xdp-act enum-as-flags: true + - + name: xdp-zc-max-segs + doc: max fragment count supported by ZC driver + type: u32 + checks: + min: 1 operations: list: @@ -77,6 +83,7 @@ operations: attributes: - ifindex - xdp-features + - xdp-zc-max-segs dump: reply: *dev-all - diff --git a/Documentation/netlink/specs/ovs_datapath.yaml b/Documentation/netlink/specs/ovs_datapath.yaml index 6d71db8c4416..f709c26c3e92 100644 --- a/Documentation/netlink/specs/ovs_datapath.yaml +++ b/Documentation/netlink/specs/ovs_datapath.yaml @@ -3,6 +3,7 @@ name: ovs_datapath version: 2 protocol: genetlink-legacy +uapi-header: linux/openvswitch.h doc: OVS datapath configuration over generic netlink. @@ -18,6 +19,7 @@ definitions: - name: user-features type: flags + name-prefix: ovs-dp-f- entries: - name: unaligned @@ -33,35 +35,37 @@ definitions: doc: Allow per-cpu dispatch of upcalls - name: datapath-stats + enum-name: ovs-dp-stats type: struct members: - - name: hit + name: n-hit type: u64 - - name: missed + name: n-missed type: u64 - - name: lost + name: n-lost type: u64 - - name: flows + name: n-flows type: u64 - name: megaflow-stats + enum-name: ovs-dp-megaflow-stats type: struct members: - - name: mask-hit + name: n-mask-hit type: u64 - - name: masks + name: n-masks type: u32 - name: padding type: u32 - - name: cache-hits + name: n-cache-hit type: u64 - name: pad1 @@ -70,6 +74,8 @@ definitions: attribute-sets: - name: datapath + name-prefix: ovs-dp-attr- + enum-name: ovs-datapath-attrs attributes: - name: name @@ -101,12 +107,16 @@ attribute-sets: name: per-cpu-pids type: binary sub-type: u32 + - + name: ifindex + type: u32 operations: fixed-header: ovs-header + name-prefix: ovs-dp-cmd- list: - - name: dp-get + name: get doc: Get / dump OVS data path configuration and state value: 3 attribute-set: datapath @@ -125,7 +135,7 @@ operations: - per-cpu-pids dump: *dp-get-op - - name: dp-new + name: new doc: Create new OVS data path value: 1 attribute-set: datapath @@ -137,7 +147,7 @@ operations: - upcall-pid - user-features - - name: dp-del + name: del doc: Delete existing OVS data path value: 2 attribute-set: datapath diff --git a/Documentation/netlink/specs/ovs_flow.yaml b/Documentation/netlink/specs/ovs_flow.yaml new file mode 100644 index 000000000000..109ca1f57b6c --- /dev/null +++ b/Documentation/netlink/specs/ovs_flow.yaml @@ -0,0 +1,980 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: ovs_flow +version: 1 +protocol: genetlink-legacy +uapi-header: linux/openvswitch.h + +doc: + OVS flow configuration over generic netlink. + +definitions: + - + name: ovs-header + type: struct + doc: | + Header for OVS Generic Netlink messages. + members: + - + name: dp-ifindex + type: u32 + doc: | + ifindex of local port for datapath (0 to make a request not specific + to a datapath). + - + name: ovs-flow-stats + type: struct + members: + - + name: n-packets + type: u64 + doc: Number of matched packets. + - + name: n-bytes + type: u64 + doc: Number of matched bytes. + - + name: ovs-key-ethernet + type: struct + members: + - + name: eth-src + type: binary + len: 6 + display-hint: mac + - + name: eth-dst + type: binary + len: 6 + display-hint: mac + - + name: ovs-key-mpls + type: struct + members: + - + name: mpls-lse + type: u32 + byte-order: big-endian + - + name: ovs-key-ipv4 + type: struct + members: + - + name: ipv4-src + type: u32 + byte-order: big-endian + display-hint: ipv4 + - + name: ipv4-dst + type: u32 + byte-order: big-endian + display-hint: ipv4 + - + name: ipv4-proto + type: u8 + - + name: ipv4-tos + type: u8 + - + name: ipv4-ttl + type: u8 + - + name: ipv4-frag + type: u8 + enum: ovs-frag-type + - + name: ovs-key-ipv6 + type: struct + members: + - + name: ipv6-src + type: binary + len: 16 + byte-order: big-endian + display-hint: ipv6 + - + name: ipv6-dst + type: binary + len: 16 + byte-order: big-endian + display-hint: ipv6 + - + name: ipv6-label + type: u32 + byte-order: big-endian + - + name: ipv6-proto + type: u8 + - + name: ipv6-tclass + type: u8 + - + name: ipv6-hlimit + type: u8 + - + name: ipv6-frag + type: u8 + - + name: ovs-key-ipv6-exthdrs + type: struct + members: + - + name: hdrs + type: u16 + - + name: ovs-frag-type + name-prefix: ovs-frag-type- + type: enum + entries: + - + name: none + doc: Packet is not a fragment. + - + name: first + doc: Packet is a fragment with offset 0. + - + name: later + doc: Packet is a fragment with nonzero offset. + - + name: any + value: 255 + - + name: ovs-key-tcp + type: struct + members: + - + name: tcp-src + type: u16 + byte-order: big-endian + - + name: tcp-dst + type: u16 + byte-order: big-endian + - + name: ovs-key-udp + type: struct + members: + - + name: udp-src + type: u16 + byte-order: big-endian + - + name: udp-dst + type: u16 + byte-order: big-endian + - + name: ovs-key-sctp + type: struct + members: + - + name: sctp-src + type: u16 + byte-order: big-endian + - + name: sctp-dst + type: u16 + byte-order: big-endian + - + name: ovs-key-icmp + type: struct + members: + - + name: icmp-type + type: u8 + - + name: icmp-code + type: u8 + - + name: ovs-key-arp + type: struct + members: + - + name: arp-sip + type: u32 + byte-order: big-endian + - + name: arp-tip + type: u32 + byte-order: big-endian + - + name: arp-op + type: u16 + byte-order: big-endian + - + name: arp-sha + type: binary + len: 6 + display-hint: mac + - + name: arp-tha + type: binary + len: 6 + display-hint: mac + - + name: ovs-key-nd + type: struct + members: + - + name: nd_target + type: binary + len: 16 + byte-order: big-endian + - + name: nd-sll + type: binary + len: 6 + display-hint: mac + - + name: nd-tll + type: binary + len: 6 + display-hint: mac + - + name: ovs-key-ct-tuple-ipv4 + type: struct + members: + - + name: ipv4-src + type: u32 + byte-order: big-endian + - + name: ipv4-dst + type: u32 + byte-order: big-endian + - + name: src-port + type: u16 + byte-order: big-endian + - + name: dst-port + type: u16 + byte-order: big-endian + - + name: ipv4-proto + type: u8 + - + name: ovs-action-push-vlan + type: struct + members: + - + name: vlan_tpid + type: u16 + byte-order: big-endian + doc: Tag protocol identifier (TPID) to push. + - + name: vlan_tci + type: u16 + byte-order: big-endian + doc: Tag control identifier (TCI) to push. + - + name: ovs-ufid-flags + name-prefix: ovs-ufid-f- + type: flags + entries: + - omit-key + - omit-mask + - omit-actions + - + name: ovs-action-hash + type: struct + members: + - + name: hash-alg + type: u32 + doc: Algorithm used to compute hash prior to recirculation. + - + name: hash-basis + type: u32 + doc: Basis used for computing hash. + - + name: ovs-hash-alg + type: enum + doc: | + Data path hash algorithm for computing Datapath hash. The algorithm type only specifies + the fields in a flow will be used as part of the hash. Each datapath is free to use its + own hash algorithm. The hash value will be opaque to the user space daemon. + entries: + - ovs-hash-alg-l4 + + - + name: ovs-action-push-mpls + type: struct + members: + - + name: mpls-lse + type: u32 + byte-order: big-endian + doc: | + MPLS label stack entry to push + - + name: mpls-ethertype + type: u32 + byte-order: big-endian + doc: | + Ethertype to set in the encapsulating ethernet frame. The only values + ethertype should ever be given are ETH_P_MPLS_UC and ETH_P_MPLS_MC, + indicating MPLS unicast or multicast. Other are rejected. + - + name: ovs-action-add-mpls + type: struct + members: + - + name: mpls-lse + type: u32 + byte-order: big-endian + doc: | + MPLS label stack entry to push + - + name: mpls-ethertype + type: u32 + byte-order: big-endian + doc: | + Ethertype to set in the encapsulating ethernet frame. The only values + ethertype should ever be given are ETH_P_MPLS_UC and ETH_P_MPLS_MC, + indicating MPLS unicast or multicast. Other are rejected. + - + name: tun-flags + type: u16 + doc: | + MPLS tunnel attributes. + - + name: ct-state-flags + type: flags + name-prefix: ovs-cs-f- + entries: + - + name: new + doc: Beginning of a new connection. + - + name: established + doc: Part of an existing connenction + - + name: related + doc: Related to an existing connection. + - + name: reply-dir + doc: Flow is in the reply direction. + - + name: invalid + doc: Could not track the connection. + - + name: tracked + doc: Conntrack has occurred. + - + name: src-nat + doc: Packet's source address/port was mangled by NAT. + - + name: dst-nat + doc: Packet's destination address/port was mangled by NAT. + +attribute-sets: + - + name: flow-attrs + enum-name: ovs-flow-attr + name-prefix: ovs-flow-attr- + attributes: + - + name: key + type: nest + nested-attributes: key-attrs + doc: | + Nested attributes specifying the flow key. Always present in + notifications. Required for all requests (except dumps). + - + name: actions + type: nest + nested-attributes: action-attrs + doc: | + Nested attributes specifying the actions to take for packets that + match the key. Always present in notifications. Required for + OVS_FLOW_CMD_NEW requests, optional for OVS_FLOW_CMD_SET requests. An + OVS_FLOW_CMD_SET without OVS_FLOW_ATTR_ACTIONS will not modify the + actions. To clear the actions, an OVS_FLOW_ATTR_ACTIONS without any + nested attributes must be given. + - + name: stats + type: binary + struct: ovs-flow-stats + doc: | + Statistics for this flow. Present in notifications if the stats would + be nonzero. Ignored in requests. + - + name: tcp-flags + type: u8 + doc: | + An 8-bit value giving the ORed value of all of the TCP flags seen on + packets in this flow. Only present in notifications for TCP flows, and + only if it would be nonzero. Ignored in requests. + - + name: used + type: u64 + doc: | + A 64-bit integer giving the time, in milliseconds on the system + monotonic clock, at which a packet was last processed for this + flow. Only present in notifications if a packet has been processed for + this flow. Ignored in requests. + - + name: clear + type: flag + doc: | + If present in a OVS_FLOW_CMD_SET request, clears the last-used time, + accumulated TCP flags, and statistics for this flow. Otherwise + ignored in requests. Never present in notifications. + - + name: mask + type: nest + nested-attributes: key-attrs + doc: | + Nested attributes specifying the mask bits for wildcarded flow + match. Mask bit value '1' specifies exact match with corresponding + flow key bit, while mask bit value '0' specifies a wildcarded + match. Omitting attribute is treated as wildcarding all corresponding + fields. Optional for all requests. If not present, all flow key bits + are exact match bits. + - + name: probe + type: binary + doc: | + Flow operation is a feature probe, error logging should be suppressed. + - + name: ufid + type: binary + doc: | + A value between 1-16 octets specifying a unique identifier for the + flow. Causes the flow to be indexed by this value rather than the + value of the OVS_FLOW_ATTR_KEY attribute. Optional for all + requests. Present in notifications if the flow was created with this + attribute. + display-hint: uuid + - + name: ufid-flags + type: u32 + enum: ovs-ufid-flags + doc: | + A 32-bit value of ORed flags that provide alternative semantics for + flow installation and retrieval. Optional for all requests. + - + name: pad + type: binary + + - + name: key-attrs + enum-name: ovs-key-attr + name-prefix: ovs-key-attr- + attributes: + - + name: encap + type: nest + nested-attributes: key-attrs + - + name: priority + type: u32 + - + name: in-port + type: u32 + - + name: ethernet + type: binary + struct: ovs-key-ethernet + doc: struct ovs_key_ethernet + - + name: vlan + type: u16 + byte-order: big-endian + - + name: ethertype + type: u16 + byte-order: big-endian + - + name: ipv4 + type: binary + struct: ovs-key-ipv4 + - + name: ipv6 + type: binary + struct: ovs-key-ipv6 + doc: struct ovs_key_ipv6 + - + name: tcp + type: binary + struct: ovs-key-tcp + - + name: udp + type: binary + struct: ovs-key-udp + - + name: icmp + type: binary + struct: ovs-key-icmp + - + name: icmpv6 + type: binary + struct: ovs-key-icmp + - + name: arp + type: binary + struct: ovs-key-arp + doc: struct ovs_key_arp + - + name: nd + type: binary + struct: ovs-key-nd + doc: struct ovs_key_nd + - + name: skb-mark + type: u32 + - + name: tunnel + type: nest + nested-attributes: tunnel-key-attrs + - + name: sctp + type: binary + struct: ovs-key-sctp + - + name: tcp-flags + type: u16 + byte-order: big-endian + - + name: dp-hash + type: u32 + doc: Value 0 indicates the hash is not computed by the datapath. + - + name: recirc-id + type: u32 + - + name: mpls + type: binary + struct: ovs-key-mpls + - + name: ct-state + type: u32 + enum: ct-state-flags + enum-as-flags: true + - + name: ct-zone + type: u16 + doc: connection tracking zone + - + name: ct-mark + type: u32 + doc: connection tracking mark + - + name: ct-labels + type: binary + display-hint: hex + doc: 16-octet connection tracking label + - + name: ct-orig-tuple-ipv4 + type: binary + struct: ovs-key-ct-tuple-ipv4 + - + name: ct-orig-tuple-ipv6 + type: binary + doc: struct ovs_key_ct_tuple_ipv6 + - + name: nsh + type: nest + nested-attributes: ovs-nsh-key-attrs + - + name: packet-type + type: u32 + byte-order: big-endian + doc: Should not be sent to the kernel + - + name: nd-extensions + type: binary + doc: Should not be sent to the kernel + - + name: tunnel-info + type: binary + doc: struct ip_tunnel_info + - + name: ipv6-exthdrs + type: binary + struct: ovs-key-ipv6-exthdrs + doc: struct ovs_key_ipv6_exthdr + - + name: action-attrs + enum-name: ovs-action-attr + name-prefix: ovs-action-attr- + attributes: + - + name: output + type: u32 + doc: ovs port number in datapath + - + name: userspace + type: nest + nested-attributes: userspace-attrs + - + name: set + type: nest + nested-attributes: key-attrs + doc: Replaces the contents of an existing header. The single nested attribute specifies a header to modify and its value. + - + name: push-vlan + type: binary + struct: ovs-action-push-vlan + doc: Push a new outermost 802.1Q or 802.1ad header onto the packet. + - + name: pop-vlan + type: flag + doc: Pop the outermost 802.1Q or 802.1ad header from the packet. + - + name: sample + type: nest + nested-attributes: sample-attrs + doc: | + Probabilistically executes actions, as specified in the nested attributes. + - + name: recirc + type: u32 + doc: recirc id + - + name: hash + type: binary + struct: ovs-action-hash + - + name: push-mpls + type: binary + struct: ovs-action-push-mpls + doc: | + Push a new MPLS label stack entry onto the top of the packets MPLS + label stack. Set the ethertype of the encapsulating frame to either + ETH_P_MPLS_UC or ETH_P_MPLS_MC to indicate the new packet contents. + - + name: pop-mpls + type: u16 + byte-order: big-endian + doc: ethertype + - + name: set-masked + type: nest + nested-attributes: key-attrs + doc: | + Replaces the contents of an existing header. A nested attribute + specifies a header to modify, its value, and a mask. For every bit set + in the mask, the corresponding bit value is copied from the value to + the packet header field, rest of the bits are left unchanged. The + non-masked value bits must be passed in as zeroes. Masking is not + supported for the OVS_KEY_ATTR_TUNNEL attribute. + - + name: ct + type: nest + nested-attributes: ct-attrs + doc: | + Track the connection. Populate the conntrack-related entries + in the flow key. + - + name: trunc + type: u32 + doc: struct ovs_action_trunc is a u32 max length + - + name: push-eth + type: binary + doc: struct ovs_action_push_eth + - + name: pop-eth + type: flag + - + name: ct-clear + type: flag + - + name: push-nsh + type: nest + nested-attributes: ovs-nsh-key-attrs + doc: | + Push NSH header to the packet. + - + name: pop-nsh + type: flag + doc: | + Pop the outermost NSH header off the packet. + - + name: meter + type: u32 + doc: | + Run packet through a meter, which may drop the packet, or modify the + packet (e.g., change the DSCP field) + - + name: clone + type: nest + nested-attributes: action-attrs + doc: | + Make a copy of the packet and execute a list of actions without + affecting the original packet and key. + - + name: check-pkt-len + type: nest + nested-attributes: check-pkt-len-attrs + doc: | + Check the packet length and execute a set of actions if greater than + the specified packet length, else execute another set of actions. + - + name: add-mpls + type: binary + struct: ovs-action-add-mpls + doc: | + Push a new MPLS label stack entry at the start of the packet or at the + start of the l3 header depending on the value of l3 tunnel flag in the + tun_flags field of this OVS_ACTION_ATTR_ADD_MPLS argument. + - + name: dec-ttl + type: nest + nested-attributes: dec-ttl-attrs + - + name: tunnel-key-attrs + enum-name: ovs-tunnel-key-attr + name-prefix: ovs-tunnel-key-attr- + attributes: + - + name: id + type: u64 + byte-order: big-endian + value: 0 + - + name: ipv4-src + type: u32 + byte-order: big-endian + - + name: ipv4-dst + type: u32 + byte-order: big-endian + - + name: tos + type: u8 + - + name: ttl + type: u8 + - + name: dont-fragment + type: flag + - + name: csum + type: flag + - + name: oam + type: flag + - + name: geneve-opts + type: binary + sub-type: u32 + - + name: tp-src + type: u16 + byte-order: big-endian + - + name: tp-dst + type: u16 + byte-order: big-endian + - + name: vxlan-opts + type: nest + nested-attributes: vxlan-ext-attrs + - + name: ipv6-src + type: binary + doc: | + struct in6_addr source IPv6 address + - + name: ipv6-dst + type: binary + doc: | + struct in6_addr destination IPv6 address + - + name: pad + type: binary + - + name: erspan-opts + type: binary + doc: | + struct erspan_metadata + - + name: ipv4-info-bridge + type: flag + - + name: check-pkt-len-attrs + enum-name: ovs-check-pkt-len-attr + name-prefix: ovs-check-pkt-len-attr- + attributes: + - + name: pkt-len + type: u16 + - + name: actions-if-greater + type: nest + nested-attributes: action-attrs + - + name: actions-if-less-equal + type: nest + nested-attributes: action-attrs + - + name: sample-attrs + enum-name: ovs-sample-attr + name-prefix: ovs-sample-attr- + attributes: + - + name: probability + type: u32 + - + name: actions + type: nest + nested-attributes: action-attrs + - + name: userspace-attrs + enum-name: ovs-userspace-attr + name-prefix: ovs-userspace-attr- + attributes: + - + name: pid + type: u32 + - + name: userdata + type: binary + - + name: egress-tun-port + type: u32 + - + name: actions + type: flag + - + name: ovs-nsh-key-attrs + enum-name: ovs-nsh-key-attr + name-prefix: ovs-nsh-key-attr- + attributes: + - + name: base + type: binary + - + name: md1 + type: binary + - + name: md2 + type: binary + - + name: ct-attrs + enum-name: ovs-ct-attr + name-prefix: ovs-ct-attr- + attributes: + - + name: commit + type: flag + - + name: zone + type: u16 + - + name: mark + type: binary + - + name: labels + type: binary + - + name: helper + type: string + - + name: nat + type: nest + nested-attributes: nat-attrs + - + name: force-commit + type: flag + - + name: eventmask + type: u32 + - + name: timeout + type: string + - + name: nat-attrs + enum-name: ovs-nat-attr + name-prefix: ovs-nat-attr- + attributes: + - + name: src + type: flag + - + name: dst + type: flag + - + name: ip-min + type: binary + - + name: ip-max + type: binary + - + name: proto-min + type: u16 + - + name: proto-max + type: u16 + - + name: persistent + type: flag + - + name: proto-hash + type: flag + - + name: proto-random + type: flag + - + name: dec-ttl-attrs + enum-name: ovs-dec-ttl-attr + name-prefix: ovs-dec-ttl-attr- + attributes: + - + name: action + type: nest + nested-attributes: action-attrs + - + name: vxlan-ext-attrs + enum-name: ovs-vxlan-ext- + name-prefix: ovs-vxlan-ext- + attributes: + - + name: gbp + type: u32 + +operations: + name-prefix: ovs-flow-cmd- + fixed-header: ovs-header + list: + - + name: get + doc: Get / dump OVS flow configuration and state + value: 3 + attribute-set: flow-attrs + do: &flow-get-op + request: + attributes: + - dp-ifindex + - key + - ufid + - ufid-flags + reply: + attributes: + - dp-ifindex + - key + - ufid + - mask + - stats + - actions + dump: *flow-get-op + - + name: new + doc: Create OVS flow configuration in a data path + value: 1 + attribute-set: flow-attrs + do: + request: + attributes: + - dp-ifindex + - key + - ufid + - mask + - actions + +mcast-groups: + list: + - + name: ovs_flow diff --git a/Documentation/netlink/specs/ovs_vport.yaml b/Documentation/netlink/specs/ovs_vport.yaml index 8e55622ddf11..f65ce62cd60d 100644 --- a/Documentation/netlink/specs/ovs_vport.yaml +++ b/Documentation/netlink/specs/ovs_vport.yaml @@ -3,6 +3,7 @@ name: ovs_vport version: 2 protocol: genetlink-legacy +uapi-header: linux/openvswitch.h doc: OVS vport configuration over generic netlink. @@ -18,10 +19,13 @@ definitions: - name: vport-type type: enum + enum-name: ovs-vport-type + name-prefix: ovs-vport-type- entries: [ unspec, netdev, internal, gre, vxlan, geneve ] - name: vport-stats type: struct + enum-name: ovs-vport-stats members: - name: rx-packets @@ -51,6 +55,8 @@ definitions: attribute-sets: - name: vport-options + enum-name: ovs-vport-options + name-prefix: ovs-tunnel-attr- attributes: - name: dst-port @@ -60,6 +66,8 @@ attribute-sets: type: u32 - name: upcall-stats + enum-name: ovs-vport-upcall-attr + name-prefix: ovs-vport-upcall-attr- attributes: - name: success @@ -70,8 +78,14 @@ attribute-sets: type: u64 - name: vport + name-prefix: ovs-vport-attr- + enum-name: ovs-vport-attr attributes: - + name: unspec + type: unused + value: 0 + - name: port-no type: u32 - @@ -108,11 +122,37 @@ attribute-sets: nested-attributes: upcall-stats operations: + name-prefix: ovs-vport-cmd- list: - - name: vport-get + name: new + doc: Create a new OVS vport + attribute-set: vport + fixed-header: ovs-header + do: + request: + attributes: + - name + - type + - upcall-pid + - dp-ifindex + - ifindex + - options + - + name: del + doc: Delete existing OVS vport from a data path + attribute-set: vport + fixed-header: ovs-header + do: + request: + attributes: + - dp-ifindex + - port-no + - type + - name + - + name: get doc: Get / dump OVS vport configuration and state - value: 3 attribute-set: vport fixed-header: ovs-header do: &vport-get-op diff --git a/Documentation/netlink/specs/rt_addr.yaml b/Documentation/netlink/specs/rt_addr.yaml new file mode 100644 index 000000000000..cbee1cedb177 --- /dev/null +++ b/Documentation/netlink/specs/rt_addr.yaml @@ -0,0 +1,179 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: rt-addr +protocol: netlink-raw +protonum: 0 + +doc: + Address configuration over rtnetlink. + +definitions: + - + name: ifaddrmsg + type: struct + members: + - + name: ifa-family + type: u8 + - + name: ifa-prefixlen + type: u8 + - + name: ifa-flags + type: u8 + enum: ifa-flags + enum-as-flags: true + - + name: ifa-scope + type: u8 + - + name: ifa-index + type: u32 + - + name: ifa-cacheinfo + type: struct + members: + - + name: ifa-prefered + type: u32 + - + name: ifa-valid + type: u32 + - + name: cstamp + type: u32 + - + name: tstamp + type: u32 + + - + name: ifa-flags + type: flags + entries: + - + name: secondary + - + name: nodad + - + name: optimistic + - + name: dadfailed + - + name: homeaddress + - + name: deprecated + - + name: tentative + - + name: permanent + - + name: managetempaddr + - + name: noprefixroute + - + name: mcautojoin + - + name: stable-privacy + +attribute-sets: + - + name: addr-attrs + attributes: + - + name: ifa-address + type: binary + display-hint: ipv4 + - + name: ifa-local + type: binary + display-hint: ipv4 + - + name: ifa-label + type: string + - + name: ifa-broadcast + type: binary + display-hint: ipv4 + - + name: ifa-anycast + type: binary + - + name: ifa-cacheinfo + type: binary + struct: ifa-cacheinfo + - + name: ifa-multicast + type: binary + - + name: ifa-flags + type: u32 + enum: ifa-flags + enum-as-flags: true + - + name: ifa-rt-priority + type: u32 + - + name: ifa-target-netnsid + type: binary + - + name: ifa-proto + type: u8 + + +operations: + fixed-header: ifaddrmsg + enum-model: directional + list: + - + name: newaddr + doc: Add new address + attribute-set: addr-attrs + do: + request: + value: 20 + attributes: &ifaddr-all + - ifa-family + - ifa-flags + - ifa-prefixlen + - ifa-scope + - ifa-index + - ifa-address + - ifa-label + - ifa-local + - ifa-cacheinfo + - + name: deladdr + doc: Remove address + attribute-set: addr-attrs + do: + request: + value: 21 + attributes: + - ifa-family + - ifa-flags + - ifa-prefixlen + - ifa-scope + - ifa-index + - ifa-address + - ifa-local + - + name: getaddr + doc: Dump address information. + attribute-set: addr-attrs + dump: + request: + value: 22 + attributes: + - ifa-index + reply: + value: 20 + attributes: *ifaddr-all + +mcast-groups: + list: + - + name: rtnlgrp-ipv4-ifaddr + value: 5 + - + name: rtnlgrp-ipv6-ifaddr + value: 9 diff --git a/Documentation/netlink/specs/rt_link.yaml b/Documentation/netlink/specs/rt_link.yaml new file mode 100644 index 000000000000..d86a68f8475c --- /dev/null +++ b/Documentation/netlink/specs/rt_link.yaml @@ -0,0 +1,1432 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: rt-link +protocol: netlink-raw +protonum: 0 + +doc: + Link configuration over rtnetlink. + +definitions: + - + name: ifinfo-flags + type: flags + entries: + - + name: up + - + name: broadcast + - + name: debug + - + name: loopback + - + name: point-to-point + - + name: no-trailers + - + name: running + - + name: no-arp + - + name: promisc + - + name: all-multi + - + name: master + - + name: slave + - + name: multicast + - + name: portsel + - + name: auto-media + - + name: dynamic + - + name: lower-up + - + name: dormant + - + name: echo + + - + name: rtgenmsg + type: struct + members: + - + name: family + type: u8 + - + name: ifinfomsg + type: struct + members: + - + name: ifi-family + type: u8 + - + name: padding + type: u8 + - + name: ifi-type + type: u16 + - + name: ifi-index + type: s32 + - + name: ifi-flags + type: u32 + enum: ifinfo-flags + enum-as-flags: true + - + name: ifi-change + type: u32 + - + name: ifla-cacheinfo + type: struct + members: + - + name: max-reasm-len + type: u32 + - + name: tstamp + type: u32 + - + name: reachable-time + type: s32 + - + name: retrans-time + type: u32 + - + name: rtnl-link-stats + type: struct + members: + - + name: rx-packets + type: u32 + - + name: tx-packets + type: u32 + - + name: rx-bytes + type: u32 + - + name: tx-bytes + type: u32 + - + name: rx-errors + type: u32 + - + name: tx-errors + type: u32 + - + name: rx-dropped + type: u32 + - + name: tx-dropped + type: u32 + - + name: multicast + type: u32 + - + name: collisions + type: u32 + - + name: rx-length-errors + type: u32 + - + name: rx-over-errors + type: u32 + - + name: rx-crc-errors + type: u32 + - + name: rx-frame-errors + type: u32 + - + name: rx-fifo-errors + type: u32 + - + name: rx-missed-errors + type: u32 + - + name: tx-aborted-errors + type: u32 + - + name: tx-carrier-errors + type: u32 + - + name: tx-fifo-errors + type: u32 + - + name: tx-heartbeat-errors + type: u32 + - + name: tx-window-errors + type: u32 + - + name: rx-compressed + type: u32 + - + name: tx-compressed + type: u32 + - + name: rx-nohandler + type: u32 + - + name: rtnl-link-stats64 + type: struct + members: + - + name: rx-packets + type: u64 + - + name: tx-packets + type: u64 + - + name: rx-bytes + type: u64 + - + name: tx-bytes + type: u64 + - + name: rx-errors + type: u64 + - + name: tx-errors + type: u64 + - + name: rx-dropped + type: u64 + - + name: tx-dropped + type: u64 + - + name: multicast + type: u64 + - + name: collisions + type: u64 + - + name: rx-length-errors + type: u64 + - + name: rx-over-errors + type: u64 + - + name: rx-crc-errors + type: u64 + - + name: rx-frame-errors + type: u64 + - + name: rx-fifo-errors + type: u64 + - + name: rx-missed-errors + type: u64 + - + name: tx-aborted-errors + type: u64 + - + name: tx-carrier-errors + type: u64 + - + name: tx-fifo-errors + type: u64 + - + name: tx-heartbeat-errors + type: u64 + - + name: tx-window-errors + type: u64 + - + name: rx-compressed + type: u64 + - + name: tx-compressed + type: u64 + - + name: rx-nohandler + type: u64 + - + name: rx-otherhost-dropped + type: u64 + - + name: rtnl-link-ifmap + type: struct + members: + - + name: mem-start + type: u64 + - + name: mem-end + type: u64 + - + name: base-addr + type: u64 + - + name: irq + type: u16 + - + name: dma + type: u8 + - + name: port + type: u8 + - + name: ipv4-devconf + type: struct + members: + - + name: forwarding + type: u32 + - + name: mc-forwarding + type: u32 + - + name: proxy-arp + type: u32 + - + name: accept-redirects + type: u32 + - + name: secure-redirects + type: u32 + - + name: send-redirects + type: u32 + - + name: shared-media + type: u32 + - + name: rp-filter + type: u32 + - + name: accept-source-route + type: u32 + - + name: bootp-relay + type: u32 + - + name: log-martians + type: u32 + - + name: tag + type: u32 + - + name: arpfilter + type: u32 + - + name: medium-id + type: u32 + - + name: noxfrm + type: u32 + - + name: nopolicy + type: u32 + - + name: force-igmp-version + type: u32 + - + name: arp-announce + type: u32 + - + name: arp-ignore + type: u32 + - + name: promote-secondaries + type: u32 + - + name: arp-accept + type: u32 + - + name: arp-notify + type: u32 + - + name: accept-local + type: u32 + - + name: src-vmark + type: u32 + - + name: proxy-arp-pvlan + type: u32 + - + name: route-localnet + type: u32 + - + name: igmpv2-unsolicited-report-interval + type: u32 + - + name: igmpv3-unsolicited-report-interval + type: u32 + - + name: ignore-routes-with-linkdown + type: u32 + - + name: drop-unicast-in-l2-multicast + type: u32 + - + name: drop-gratuitous-arp + type: u32 + - + name: bc-forwarding + type: u32 + - + name: arp-evict-nocarrier + type: u32 + - + name: ipv6-devconf + type: struct + members: + - + name: forwarding + type: u32 + - + name: hoplimit + type: u32 + - + name: mtu6 + type: u32 + - + name: accept-ra + type: u32 + - + name: accept-redirects + type: u32 + - + name: autoconf + type: u32 + - + name: dad-transmits + type: u32 + - + name: rtr-solicits + type: u32 + - + name: rtr-solicit-interval + type: u32 + - + name: rtr-solicit-delay + type: u32 + - + name: use-tempaddr + type: u32 + - + name: temp-valid-lft + type: u32 + - + name: temp-prefered-lft + type: u32 + - + name: regen-max-retry + type: u32 + - + name: max-desync-factor + type: u32 + - + name: max-addresses + type: u32 + - + name: force-mld-version + type: u32 + - + name: accept-ra-defrtr + type: u32 + - + name: accept-ra-pinfo + type: u32 + - + name: accept-ra-rtr-pref + type: u32 + - + name: rtr-probe-interval + type: u32 + - + name: accept-ra-rt-info-max-plen + type: u32 + - + name: proxy-ndp + type: u32 + - + name: optimistic-dad + type: u32 + - + name: accept-source-route + type: u32 + - + name: mc-forwarding + type: u32 + - + name: disable-ipv6 + type: u32 + - + name: accept-dad + type: u32 + - + name: force-tllao + type: u32 + - + name: ndisc-notify + type: u32 + - + name: mldv1-unsolicited-report-interval + type: u32 + - + name: mldv2-unsolicited-report-interval + type: u32 + - + name: suppress-frag-ndisc + type: u32 + - + name: accept-ra-from-local + type: u32 + - + name: use-optimistic + type: u32 + - + name: accept-ra-mtu + type: u32 + - + name: stable-secret + type: u32 + - + name: use-oif-addrs-only + type: u32 + - + name: accept-ra-min-hop-limit + type: u32 + - + name: ignore-routes-with-linkdown + type: u32 + - + name: drop-unicast-in-l2-multicast + type: u32 + - + name: drop-unsolicited-na + type: u32 + - + name: keep-addr-on-down + type: u32 + - + name: rtr-solicit-max-interval + type: u32 + - + name: seg6-enabled + type: u32 + - + name: seg6-require-hmac + type: u32 + - + name: enhanced-dad + type: u32 + - + name: addr-gen-mode + type: u8 + - + name: disable-policy + type: u32 + - + name: accept-ra-rt-info-min-plen + type: u32 + - + name: ndisc-tclass + type: u32 + - + name: rpl-seg-enabled + type: u32 + - + name: ra-defrtr-metric + type: u32 + - + name: ioam6-enabled + type: u32 + - + name: ioam6-id + type: u32 + - + name: ioam6-id-wide + type: u32 + - + name: ndisc-evict-nocarrier + type: u32 + - + name: accept-untracked-na + type: u32 + - + name: ifla-icmp6-stats + type: struct + members: + - + name: inmsgs + type: u64 + - + name: inerrors + type: u64 + - + name: outmsgs + type: u64 + - + name: outerrors + type: u64 + - + name: csumerrors + type: u64 + - + name: ratelimithost + type: u64 + - + name: ifla-inet6-stats + type: struct + members: + - + name: inpkts + type: u64 + - + name: inoctets + type: u64 + - + name: indelivers + type: u64 + - + name: outforwdatagrams + type: u64 + - + name: outpkts + type: u64 + - + name: outoctets + type: u64 + - + name: inhdrerrors + type: u64 + - + name: intoobigerrors + type: u64 + - + name: innoroutes + type: u64 + - + name: inaddrerrors + type: u64 + - + name: inunknownprotos + type: u64 + - + name: intruncatedpkts + type: u64 + - + name: indiscards + type: u64 + - + name: outdiscards + type: u64 + - + name: outnoroutes + type: u64 + - + name: reasmtimeout + type: u64 + - + name: reasmreqds + type: u64 + - + name: reasmoks + type: u64 + - + name: reasmfails + type: u64 + - + name: fragoks + type: u64 + - + name: fragfails + type: u64 + - + name: fragcreates + type: u64 + - + name: inmcastpkts + type: u64 + - + name: outmcastpkts + type: u64 + - + name: inbcastpkts + type: u64 + - + name: outbcastpkts + type: u64 + - + name: inmcastoctets + type: u64 + - + name: outmcastoctets + type: u64 + - + name: inbcastoctets + type: u64 + - + name: outbcastoctets + type: u64 + - + name: csumerrors + type: u64 + - + name: noectpkts + type: u64 + - + name: ect1-pkts + type: u64 + - + name: ect0-pkts + type: u64 + - + name: cepkts + type: u64 + - + name: reasm-overlaps + type: u64 + - name: br-boolopt-multi + type: struct + members: + - + name: optval + type: u32 + - + name: optmask + type: u32 + - + name: if_stats_msg + type: struct + members: + - + name: family + type: u8 + - + name: pad1 + type: u8 + - + name: pad2 + type: u16 + - + name: ifindex + type: u32 + - + name: filter-mask + type: u32 + + +attribute-sets: + - + name: link-attrs + name-prefix: ifla- + attributes: + - + name: address + type: binary + display-hint: mac + - + name: broadcast + type: binary + display-hint: mac + - + name: ifname + type: string + - + name: mtu + type: u32 + - + name: link + type: u32 + - + name: qdisc + type: string + - + name: stats + type: binary + struct: rtnl-link-stats + - + name: cost + type: string + - + name: priority + type: string + - + name: master + type: u32 + - + name: wireless + type: string + - + name: protinfo + type: string + - + name: txqlen + type: u32 + - + name: map + type: binary + struct: rtnl-link-ifmap + - + name: weight + type: u32 + - + name: operstate + type: u8 + - + name: linkmode + type: u8 + - + name: linkinfo + type: nest + nested-attributes: linkinfo-attrs + - + name: net-ns-pid + type: u32 + - + name: ifalias + type: string + - + name: num-vf + type: u32 + - + name: vfinfo-list + type: nest + nested-attributes: vfinfo-attrs + - + name: stats64 + type: binary + struct: rtnl-link-stats64 + - + name: vf-ports + type: nest + nested-attributes: vf-ports-attrs + - + name: port-self + type: nest + nested-attributes: port-self-attrs + - + name: af-spec + type: nest + nested-attributes: af-spec-attrs + - + name: group + type: u32 + - + name: net-ns-fd + type: u32 + - + name: ext-mask + type: u32 + - + name: promiscuity + type: u32 + - + name: num-tx-queues + type: u32 + - + name: num-rx-queues + type: u32 + - + name: carrier + type: u8 + - + name: phys-port-id + type: binary + - + name: carrier-changes + type: u32 + - + name: phys-switch-id + type: binary + - + name: link-netnsid + type: s32 + - + name: phys-port-name + type: string + - + name: proto-down + type: u8 + - + name: gso-max-segs + type: u32 + - + name: gso-max-size + type: u32 + - + name: pad + type: pad + - + name: xdp + type: nest + nested-attributes: xdp-attrs + - + name: event + type: u32 + - + name: new-netnsid + type: s32 + - + name: target-netnsid + type: s32 + - + name: carrier-up-count + type: u32 + - + name: carrier-down-count + type: u32 + - + name: new-ifindex + type: s32 + - + name: min-mtu + type: u32 + - + name: max-mtu + type: u32 + - + name: prop-list + type: nest + nested-attributes: link-attrs + - + name: alt-ifname + type: string + multi-attr: true + - + name: perm-address + type: binary + display-hint: mac + - + name: proto-down-reason + type: string + - + name: parent-dev-name + type: string + - + name: parent-dev-bus-name + type: string + - + name: gro-max-size + type: u32 + - + name: tso-max-size + type: u32 + - + name: tso-max-segs + type: u32 + - + name: allmulti + type: u32 + - + name: devlink-port + type: binary + - + name: gso-ipv4-max-size + type: u32 + - + name: gro-ipv4-max-size + type: u32 + - + name: af-spec-attrs + attributes: + - + name: "inet" + type: nest + value: 2 + nested-attributes: ifla-attrs + - + name: "inet6" + type: nest + value: 10 + nested-attributes: ifla6-attrs + - + name: "mctp" + type: nest + value: 45 + nested-attributes: mctp-attrs + - + name: vfinfo-attrs + attributes: [] + - + name: vf-ports-attrs + attributes: [] + - + name: port-self-attrs + attributes: [] + - + name: linkinfo-attrs + attributes: + - + name: kind + type: string + - + name: data + type: binary + # kind specific nest, e.g. linkinfo-bridge-attrs + - + name: xstats + type: binary + - + name: slave-kind + type: string + - + name: slave-data + type: binary + # kind specific nest + - + name: linkinfo-bridge-attrs + attributes: + - + name: forward-delay + type: u32 + - + name: hello-time + type: u32 + - + name: max-age + type: u32 + - + name: ageing-time + type: u32 + - + name: stp-state + type: u32 + - + name: priority + type: u16 + - + name: vlan-filtering + type: u8 + - + name: vlan-protocol + type: u16 + - + name: group-fwd-mask + type: u16 + - + name: root-id + type: binary + - + name: bridge-id + type: binary + - + name: root-port + type: u16 + - + name: root-path-cost + type: u32 + - + name: topology-change + type: u8 + - + name: topology-change-detected + type: u8 + - + name: hello-timer + type: u64 + - + name: tcn-timer + type: u64 + - + name: topology-change-timer + type: u64 + - + name: gc-timer + type: u64 + - + name: group-addr + type: binary + - + name: fdb-flush + type: binary + - + name: mcast-router + type: u8 + - + name: mcast-snooping + type: u8 + - + name: mcast-query-use-ifaddr + type: u8 + - + name: mcast-querier + type: u8 + - + name: mcast-hash-elasticity + type: u32 + - + name: mcast-hash-max + type: u32 + - + name: mcast-last-member-cnt + type: u32 + - + name: mcast-startup-query-cnt + type: u32 + - + name: mcast-last-member-intvl + type: u64 + - + name: mcast-membership-intvl + type: u64 + - + name: mcast-querier-intvl + type: u64 + - + name: mcast-query-intvl + type: u64 + - + name: mcast-query-response-intvl + type: u64 + - + name: mcast-startup-query-intvl + type: u64 + - + name: nf-call-iptables + type: u8 + - + name: nf-call-ip6-tables + type: u8 + - + name: nf-call-arptables + type: u8 + - + name: vlan-default-pvid + type: u16 + - + name: pad + type: pad + - + name: vlan-stats-enabled + type: u8 + - + name: mcast-stats-enabled + type: u8 + - + name: mcast-igmp-version + type: u8 + - + name: mcast-mld-version + type: u8 + - + name: vlan-stats-per-port + type: u8 + - + name: multi-boolopt + type: binary + struct: br-boolopt-multi + - + name: mcast-querier-state + type: binary + - + name: xdp-attrs + attributes: + - + name: fd + type: s32 + - + name: attached + type: u8 + - + name: flags + type: u32 + - + name: prog-id + type: u32 + - + name: drv-prog-id + type: u32 + - + name: skb-prog-id + type: u32 + - + name: hw-prog-id + type: u32 + - + name: expected-fd + type: s32 + - + name: ifla-attrs + attributes: + - + name: conf + type: binary + struct: ipv4-devconf + - + name: ifla6-attrs + attributes: + - + name: flags + type: u32 + - + name: conf + type: binary + struct: ipv6-devconf + - + name: stats + type: binary + struct: ifla-inet6-stats + - + name: mcast + type: binary + - + name: cacheinfo + type: binary + struct: ifla-cacheinfo + - + name: icmp6-stats + type: binary + struct: ifla-icmp6-stats + - + name: token + type: binary + - + name: addr-gen-mode + type: u8 + - + name: ra-mtu + type: u32 + - + name: mctp-attrs + attributes: + - + name: mctp-net + type: u32 + - + name: stats-attrs + name-prefix: ifla-stats- + attributes: + - + name: link-64 + type: binary + struct: rtnl-link-stats64 + - + name: link-xstats + type: binary + - + name: link-xstats-slave + type: binary + - + name: link-offload-xstats + type: nest + nested-attributes: link-offload-xstats + - + name: af-spec + type: binary + - + name: link-offload-xstats + attributes: + - + name: cpu-hit + type: binary + - + name: hw-s-info + type: array-nest + nested-attributes: hw-s-info-one + - + name: l3-stats + type: binary + - + name: hw-s-info-one + attributes: + - + name: request + type: u8 + - + name: used + type: u8 + +operations: + enum-model: directional + list: + - + name: newlink + doc: Create a new link. + attribute-set: link-attrs + fixed-header: ifinfomsg + do: + request: + value: 16 + attributes: &link-new-attrs + - ifi-index + - ifname + - net-ns-pid + - net-ns-fd + - target-netnsid + - link-netnsid + - linkinfo + - group + - num-tx-queues + - num-rx-queues + - address + - broadcast + - mtu + - txqlen + - operstate + - linkmode + - group + - gso-max-size + - gso-max-segs + - gro-max-size + - gso-ipv4-max-size + - gro-ipv4-max-size + - af-spec + - + name: dellink + doc: Delete an existing link. + attribute-set: link-attrs + fixed-header: ifinfomsg + do: + request: + value: 17 + attributes: + - ifi-index + - ifname + - + name: getlink + doc: Get / dump information about a link. + attribute-set: link-attrs + fixed-header: ifinfomsg + do: + request: + value: 18 + attributes: + - ifi-index + - ifname + - alt-ifname + - ext-mask + - target-netnsid + reply: + value: 16 + attributes: &link-all-attrs + - ifi-family + - ifi-type + - ifi-index + - ifi-flags + - ifi-change + - address + - broadcast + - ifname + - mtu + - link + - qdisc + - stats + - cost + - priority + - master + - wireless + - protinfo + - txqlen + - map + - weight + - operstate + - linkmode + - linkinfo + - net-ns-pid + - ifalias + - num-vf + - vfinfo-list + - stats64 + - vf-ports + - port-self + - af-spec + - group + - net-ns-fd + - ext-mask + - promiscuity + - num-tx-queues + - num-rx-queues + - carrier + - phys-port-id + - carrier-changes + - phys-switch-id + - link-netnsid + - phys-port-name + - proto-down + - gso-max-segs + - gso-max-size + - pad + - xdp + - event + - new-netnsid + - if-netnsid + - target-netnsid + - carrier-up-count + - carrier-down-count + - new-ifindex + - min-mtu + - max-mtu + - prop-list + - alt-ifname + - perm-address + - proto-down-reason + - parent-dev-name + - parent-dev-bus-name + - gro-max-size + - tso-max-size + - tso-max-segs + - allmulti + - devlink-port + - gso-ipv4-max-size + - gro-ipv4-max-size + dump: + request: + value: 18 + attributes: + - target-netnsid + - ext-mask + - master + - linkinfo + reply: + value: 16 + attributes: *link-all-attrs + - + name: setlink + doc: Set information about a link. + attribute-set: link-attrs + fixed-header: ifinfomsg + do: + request: + value: 19 + attributes: *link-all-attrs + - + name: getstats + doc: Get / dump link stats. + attribute-set: stats-attrs + fixed-header: if_stats_msg + do: + request: + value: 94 + attributes: + - ifindex + reply: + value: 92 + attributes: &link-stats-attrs + - family + - ifindex + - filter-mask + - link-64 + - link-xstats + - link-xstats-slave + - link-offload-xstats + - af-spec + dump: + request: + value: 94 + reply: + value: 92 + attributes: *link-stats-attrs + +mcast-groups: + list: + - + name: rtnlgrp-link + value: 1 + - + name: rtnlgrp-stats + value: 36 diff --git a/Documentation/netlink/specs/rt_route.yaml b/Documentation/netlink/specs/rt_route.yaml new file mode 100644 index 000000000000..f4368be0caed --- /dev/null +++ b/Documentation/netlink/specs/rt_route.yaml @@ -0,0 +1,327 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: rt-route +protocol: netlink-raw +protonum: 0 + +doc: + Route configuration over rtnetlink. + +definitions: + - + name: rtm-type + name-prefix: rtn- + type: enum + entries: + - unspec + - unicast + - local + - broadcast + - anycast + - multicast + - blackhole + - unreachable + - prohibit + - throw + - nat + - xresolve + - + name: rtmsg + type: struct + members: + - + name: rtm-family + type: u8 + - + name: rtm-dst-len + type: u8 + - + name: rtm-src-len + type: u8 + - + name: rtm-tos + type: u8 + - + name: rtm-table + type: u8 + - + name: rtm-protocol + type: u8 + - + name: rtm-scope + type: u8 + - + name: rtm-type + type: u8 + enum: rtm-type + - + name: rtm-flags + type: u32 + - + name: rta-cacheinfo + type: struct + members: + - + name: rta-clntref + type: u32 + - + name: rta-lastuse + type: u32 + - + name: rta-expires + type: u32 + - + name: rta-error + type: u32 + - + name: rta-used + type: u32 + +attribute-sets: + - + name: route-attrs + attributes: + - + name: rta-dst + type: binary + display-hint: ipv4 + - + name: rta-src + type: binary + display-hint: ipv4 + - + name: rta-iif + type: u32 + - + name: rta-oif + type: u32 + - + name: rta-gateway + type: binary + display-hint: ipv4 + - + name: rta-priority + type: u32 + - + name: rta-prefsrc + type: binary + display-hint: ipv4 + - + name: rta-metrics + type: nest + nested-attributes: rta-metrics + - + name: rta-multipath + type: binary + - + name: rta-protoinfo # not used + type: binary + - + name: rta-flow + type: u32 + - + name: rta-cacheinfo + type: binary + struct: rta-cacheinfo + - + name: rta-session # not used + type: binary + - + name: rta-mp-algo # not used + type: binary + - + name: rta-table + type: u32 + - + name: rta-mark + type: u32 + - + name: rta-mfc-stats + type: binary + - + name: rta-via + type: binary + - + name: rta-newdst + type: binary + - + name: rta-pref + type: u8 + - + name: rta-encap-type + type: u16 + - + name: rta-encap + type: binary # tunnel specific nest + - + name: rta-expires + type: u32 + - + name: rta-pad + type: binary + - + name: rta-uid + type: u32 + - + name: rta-ttl-propagate + type: u8 + - + name: rta-ip-proto + type: u8 + - + name: rta-sport + type: u16 + - + name: rta-dport + type: u16 + - + name: rta-nh-id + type: u32 + - + name: rta-metrics + attributes: + - + name: rtax-unspec + type: unused + value: 0 + - + name: rtax-lock + type: u32 + - + name: rtax-mtu + type: u32 + - + name: rtax-window + type: u32 + - + name: rtax-rtt + type: u32 + - + name: rtax-rttvar + type: u32 + - + name: rtax-ssthresh + type: u32 + - + name: rtax-cwnd + type: u32 + - + name: rtax-advmss + type: u32 + - + name: rtax-reordering + type: u32 + - + name: rtax-hoplimit + type: u32 + - + name: rtax-initcwnd + type: u32 + - + name: rtax-features + type: u32 + - + name: rtax-rto-min + type: u32 + - + name: rtax-initrwnd + type: u32 + - + name: rtax-quickack + type: u32 + - + name: rtax-cc-algo + type: string + - + name: rtax-fastopen-no-cookie + type: u32 + +operations: + enum-model: directional + list: + - + name: getroute + doc: Dump route information. + attribute-set: route-attrs + fixed-header: rtmsg + do: + request: + value: 26 + attributes: + - rtm-family + - rta-src + - rtm-src-len + - rta-dst + - rtm-dst-len + - rta-iif + - rta-oif + - rta-ip-proto + - rta-sport + - rta-dport + - rta-mark + - rta-uid + reply: + value: 24 + attributes: &all-route-attrs + - rtm-family + - rtm-dst-len + - rtm-src-len + - rtm-tos + - rtm-table + - rtm-protocol + - rtm-scope + - rtm-type + - rtm-flags + - rta-dst + - rta-src + - rta-iif + - rta-oif + - rta-gateway + - rta-priority + - rta-prefsrc + - rta-metrics + - rta-multipath + - rta-flow + - rta-cacheinfo + - rta-table + - rta-mark + - rta-mfc-stats + - rta-via + - rta-newdst + - rta-pref + - rta-encap-type + - rta-encap + - rta-expires + - rta-pad + - rta-uid + - rta-ttl-propagate + - rta-ip-proto + - rta-sport + - rta-dport + - rta-nh-id + dump: + request: + value: 26 + attributes: + - rtm-family + reply: + value: 24 + attributes: *all-route-attrs + - + name: newroute + doc: Create a new route + attribute-set: route-attrs + fixed-header: rtmsg + do: + request: + value: 24 + attributes: *all-route-attrs + - + name: delroute + doc: Delete an existing route + attribute-set: route-attrs + fixed-header: rtmsg + do: + request: + value: 25 + attributes: *all-route-attrs diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst index 247c6c4127e9..dceeb0d763aa 100644 --- a/Documentation/networking/af_xdp.rst +++ b/Documentation/networking/af_xdp.rst @@ -433,6 +433,15 @@ start N bytes into the buffer leaving the first N bytes for the application to use. The final option is the flags field, but it will be dealt with in separate sections for each UMEM flag. +SO_BINDTODEVICE setsockopt +-------------------------- + +This is a generic SOL_SOCKET option that can be used to tie AF_XDP +socket to a particular network interface. It is useful when a socket +is created by a privileged process and passed to a non-privileged one. +Once the option is set, kernel will refuse attempts to bind that socket +to a different interface. Updating the value requires CAP_NET_RAW. + XDP_STATISTICS getsockopt ------------------------- @@ -453,8 +462,92 @@ XDP_OPTIONS getsockopt Gets options from an XDP socket. The only one supported so far is XDP_OPTIONS_ZEROCOPY which tells you if zero-copy is on or not. +Multi-Buffer Support +==================== + +With multi-buffer support, programs using AF_XDP sockets can receive +and transmit packets consisting of multiple buffers both in copy and +zero-copy mode. For example, a packet can consist of two +frames/buffers, one with the header and the other one with the data, +or a 9K Ethernet jumbo frame can be constructed by chaining together +three 4K frames. + +Some definitions: + +* A packet consists of one or more frames + +* A descriptor in one of the AF_XDP rings always refers to a single + frame. In the case the packet consists of a single frame, the + descriptor refers to the whole packet. + +To enable multi-buffer support for an AF_XDP socket, use the new bind +flag XDP_USE_SG. If this is not provided, all multi-buffer packets +will be dropped just as before. Note that the XDP program loaded also +needs to be in multi-buffer mode. This can be accomplished by using +"xdp.frags" as the section name of the XDP program used. + +To represent a packet consisting of multiple frames, a new flag called +XDP_PKT_CONTD is introduced in the options field of the Rx and Tx +descriptors. If it is true (1) the packet continues with the next +descriptor and if it is false (0) it means this is the last descriptor +of the packet. Why the reverse logic of end-of-packet (eop) flag found +in many NICs? Just to preserve compatibility with non-multi-buffer +applications that have this bit set to false for all packets on Rx, +and the apps set the options field to zero for Tx, as anything else +will be treated as an invalid descriptor. + +These are the semantics for producing packets onto AF_XDP Tx ring +consisting of multiple frames: + +* When an invalid descriptor is found, all the other + descriptors/frames of this packet are marked as invalid and not + completed. The next descriptor is treated as the start of a new + packet, even if this was not the intent (because we cannot guess + the intent). As before, if your program is producing invalid + descriptors you have a bug that must be fixed. + +* Zero length descriptors are treated as invalid descriptors. + +* For copy mode, the maximum supported number of frames in a packet is + equal to CONFIG_MAX_SKB_FRAGS + 1. If it is exceeded, all + descriptors accumulated so far are dropped and treated as + invalid. To produce an application that will work on any system + regardless of this config setting, limit the number of frags to 18, + as the minimum value of the config is 17. + +* For zero-copy mode, the limit is up to what the NIC HW + supports. Usually at least five on the NICs we have checked. We + consciously chose to not enforce a rigid limit (such as + CONFIG_MAX_SKB_FRAGS + 1) for zero-copy mode, as it would have + resulted in copy actions under the hood to fit into what limit the + NIC supports. Kind of defeats the purpose of zero-copy mode. How to + probe for this limit is explained in the "probe for multi-buffer + support" section. + +On the Rx path in copy-mode, the xsk core copies the XDP data into +multiple descriptors, if needed, and sets the XDP_PKT_CONTD flag as +detailed before. Zero-copy mode works the same, though the data is not +copied. When the application gets a descriptor with the XDP_PKT_CONTD +flag set to one, it means that the packet consists of multiple buffers +and it continues with the next buffer in the following +descriptor. When a descriptor with XDP_PKT_CONTD == 0 is received, it +means that this is the last buffer of the packet. AF_XDP guarantees +that only a complete packet (all frames in the packet) is sent to the +application. If there is not enough space in the AF_XDP Rx ring, all +frames of the packet will be dropped. + +If application reads a batch of descriptors, using for example the libxdp +interfaces, it is not guaranteed that the batch will end with a full +packet. It might end in the middle of a packet and the rest of the +buffers of that packet will arrive at the beginning of the next batch, +since the libxdp interface does not read the whole ring (unless you +have an enormous batch size or a very small ring size). + +An example program each for Rx and Tx multi-buffer support can be found +later in this document. + Usage -===== +----- In order to use AF_XDP sockets two parts are needed. The user-space application and the XDP program. For a complete setup and @@ -532,6 +625,131 @@ like this: But please use the libbpf functions as they are optimized and ready to use. Will make your life easier. +Usage Multi-Buffer Rx +--------------------- + +Here is a simple Rx path pseudo-code example (using libxdp interfaces +for simplicity). Error paths have been excluded to keep it short: + +.. code-block:: c + + void rx_packets(struct xsk_socket_info *xsk) + { + static bool new_packet = true; + u32 idx_rx = 0, idx_fq = 0; + static char *pkt; + + int rcvd = xsk_ring_cons__peek(&xsk->rx, opt_batch_size, &idx_rx); + + xsk_ring_prod__reserve(&xsk->umem->fq, rcvd, &idx_fq); + + for (int i = 0; i < rcvd; i++) { + struct xdp_desc *desc = xsk_ring_cons__rx_desc(&xsk->rx, idx_rx++); + char *frag = xsk_umem__get_data(xsk->umem->buffer, desc->addr); + bool eop = !(desc->options & XDP_PKT_CONTD); + + if (new_packet) + pkt = frag; + else + add_frag_to_pkt(pkt, frag); + + if (eop) + process_pkt(pkt); + + new_packet = eop; + + *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) = desc->addr; + } + + xsk_ring_prod__submit(&xsk->umem->fq, rcvd); + xsk_ring_cons__release(&xsk->rx, rcvd); + } + +Usage Multi-Buffer Tx +--------------------- + +Here is an example Tx path pseudo-code (using libxdp interfaces for +simplicity) ignoring that the umem is finite in size, and that we +eventually will run out of packets to send. Also assumes pkts.addr +points to a valid location in the umem. + +.. code-block:: c + + void tx_packets(struct xsk_socket_info *xsk, struct pkt *pkts, + int batch_size) + { + u32 idx, i, pkt_nb = 0; + + xsk_ring_prod__reserve(&xsk->tx, batch_size, &idx); + + for (i = 0; i < batch_size;) { + u64 addr = pkts[pkt_nb].addr; + u32 len = pkts[pkt_nb].size; + + do { + struct xdp_desc *tx_desc; + + tx_desc = xsk_ring_prod__tx_desc(&xsk->tx, idx + i++); + tx_desc->addr = addr; + + if (len > xsk_frame_size) { + tx_desc->len = xsk_frame_size; + tx_desc->options = XDP_PKT_CONTD; + } else { + tx_desc->len = len; + tx_desc->options = 0; + pkt_nb++; + } + len -= tx_desc->len; + addr += xsk_frame_size; + + if (i == batch_size) { + /* Remember len, addr, pkt_nb for next iteration. + * Skipped for simplicity. + */ + break; + } + } while (len); + } + + xsk_ring_prod__submit(&xsk->tx, i); + } + +Probing for Multi-Buffer Support +-------------------------------- + +To discover if a driver supports multi-buffer AF_XDP in SKB or DRV +mode, use the XDP_FEATURES feature of netlink in linux/netdev.h to +query for NETDEV_XDP_ACT_RX_SG support. This is the same flag as for +querying for XDP multi-buffer support. If XDP supports multi-buffer in +a driver, then AF_XDP will also support that in SKB and DRV mode. + +To discover if a driver supports multi-buffer AF_XDP in zero-copy +mode, use XDP_FEATURES and first check the NETDEV_XDP_ACT_XSK_ZEROCOPY +flag. If it is set, it means that at least zero-copy is supported and +you should go and check the netlink attribute +NETDEV_A_DEV_XDP_ZC_MAX_SEGS in linux/netdev.h. An unsigned integer +value will be returned stating the max number of frags that are +supported by this device in zero-copy mode. These are the possible +return values: + +1: Multi-buffer for zero-copy is not supported by this device, as max + one fragment supported means that multi-buffer is not possible. + +>=2: Multi-buffer is supported in zero-copy mode for this device. The + returned number signifies the max number of frags supported. + +For an example on how these are used through libbpf, please take a +look at tools/testing/selftests/bpf/xskxceiver.c. + +Multi-Buffer Support for Zero-Copy Drivers +------------------------------------------ + +Zero-copy drivers usually use the batched APIs for Rx and Tx +processing. Note that the Tx batch API guarantees that it will provide +a batch of Tx descriptors that ends with full packet at the end. This +to facilitate extending a zero-copy driver with multi-buffer support. + Sample application ================== diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst index 28925e19622d..f7a73421eb76 100644 --- a/Documentation/networking/bonding.rst +++ b/Documentation/networking/bonding.rst @@ -1636,7 +1636,7 @@ your init script:: ----------------------------------------- This section applies to distros which use /etc/network/interfaces file -to describe network interface configuration, most notably Debian and it's +to describe network interface configuration, most notably Debian and its derivatives. The ifup and ifdown commands on Debian don't support bonding out of diff --git a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst index 4118384cf8eb..289c146a8291 100644 --- a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst +++ b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst @@ -190,8 +190,7 @@ MAP header|IP Packet|Optional padding|MAP header|Command Packet|Optional pad... 3. Userspace configuration ========================== -rmnet userspace configuration is done through netlink library librmnetctl -and command line utility rmnetcli. Utility is hosted in codeaurora forum git. -The driver uses rtnl_link_ops for communication. +rmnet userspace configuration is done through netlink using iproute2 +https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/ -https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/dataservices/tree/rmnetctl +The driver uses rtnl_link_ops for communication. diff --git a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst index 8bcb173e0353..5eaa3ab6c73e 100644 --- a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst +++ b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst @@ -38,6 +38,7 @@ debug logs. Some of the ENA devices support a working mode called Low-latency Queue (LLQ), which saves several more microseconds. + ENA Source Code Directory Structure =================================== @@ -205,6 +206,8 @@ Adaptive coalescing can be switched on/off through `ethtool(8)`'s More information about Adaptive Interrupt Moderation (DIM) can be found in Documentation/networking/net_dim.rst +.. _`RX copybreak`: + RX copybreak ============ The rx_copybreak is initialized by default to ENA_DEFAULT_RX_COPYBREAK @@ -315,3 +318,34 @@ Rx - The new SKB is updated with the necessary information (protocol, checksum hw verify result, etc), and then passed to the network stack, using the NAPI interface function :code:`napi_gro_receive()`. + +Dynamic RX Buffers (DRB) +------------------------ + +Each RX descriptor in the RX ring is a single memory page (which is either 4KB +or 16KB long depending on system's configurations). +To reduce the memory allocations required when dealing with a high rate of small +packets, the driver tries to reuse the remaining RX descriptor's space if more +than 2KB of this page remain unused. + +A simple example of this mechanism is the following sequence of events: + +:: + + 1. Driver allocates page-sized RX buffer and passes it to hardware + +----------------------+ + |4KB RX Buffer | + +----------------------+ + + 2. A 300Bytes packet is received on this buffer + + 3. The driver increases the ref count on this page and returns it back to + HW as an RX buffer of size 4KB - 300Bytes = 3796 Bytes + +----+--------------------+ + |****|3796 Bytes RX Buffer| + +----+--------------------+ + +This mechanism isn't used when an XDP program is loaded, or when the +RX packet is less than rx_copybreak bytes (in which case the packet is +copied out of the RX buffer into the linear part of a new skb allocated +for it and the RX buffer remains the same size, see `RX copybreak`_). diff --git a/Documentation/networking/device_drivers/ethernet/amd/pds_vdpa.rst b/Documentation/networking/device_drivers/ethernet/amd/pds_vdpa.rst new file mode 100644 index 000000000000..587927d3de92 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/amd/pds_vdpa.rst @@ -0,0 +1,85 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. note: can be edited and viewed with /usr/bin/formiko-vim + +========================================================== +PCI vDPA driver for the AMD/Pensando(R) DSC adapter family +========================================================== + +AMD/Pensando vDPA VF Device Driver + +Copyright(c) 2023 Advanced Micro Devices, Inc + +Overview +======== + +The ``pds_vdpa`` driver is an auxiliary bus driver that supplies +a vDPA device for use by the virtio network stack. It is used with +the Pensando Virtual Function devices that offer vDPA and virtio queue +services. It depends on the ``pds_core`` driver and hardware for the PF +and VF PCI handling as well as for device configuration services. + +Using the device +================ + +The ``pds_vdpa`` device is enabled via multiple configuration steps and +depends on the ``pds_core`` driver to create and enable SR-IOV Virtual +Function devices. After the VFs are enabled, we enable the vDPA service +in the ``pds_core`` device to create the auxiliary devices used by pds_vdpa. + +Example steps: + +.. code-block:: bash + + #!/bin/bash + + modprobe pds_core + modprobe vdpa + modprobe pds_vdpa + + PF_BDF=`ls /sys/module/pds_core/drivers/pci\:pds_core/*/sriov_numvfs | awk -F / '{print $7}'` + + # Enable vDPA VF auxiliary device(s) in the PF + devlink dev param set pci/$PF_BDF name enable_vnet cmode runtime value true + + # Create a VF for vDPA use + echo 1 > /sys/bus/pci/drivers/pds_core/$PF_BDF/sriov_numvfs + + # Find the vDPA services/devices available + PDS_VDPA_MGMT=`vdpa mgmtdev show | grep vDPA | head -1 | cut -d: -f1` + + # Create a vDPA device for use in virtio network configurations + vdpa dev add name vdpa1 mgmtdev $PDS_VDPA_MGMT mac 00:11:22:33:44:55 + + # Set up an ethernet interface on the vdpa device + modprobe virtio_vdpa + + + +Enabling the driver +=================== + +The driver is enabled via the standard kernel configuration system, +using the make command:: + + make oldconfig/menuconfig/etc. + +The driver is located in the menu structure at: + + -> Device Drivers + -> Network device support (NETDEVICES [=y]) + -> Ethernet driver support + -> Pensando devices + -> Pensando Ethernet PDS_VDPA Support + +Support +======= + +For general Linux networking support, please use the netdev mailing +list, which is monitored by Pensando personnel:: + + netdev@vger.kernel.org + +For more specific support needs, please use the Pensando driver support +email:: + + drivers@pensando.io diff --git a/Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst b/Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst new file mode 100644 index 000000000000..7a6bc848a2b2 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst @@ -0,0 +1,79 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. note: can be edited and viewed with /usr/bin/formiko-vim + +========================================================== +PCI VFIO driver for the AMD/Pensando(R) DSC adapter family +========================================================== + +AMD/Pensando Linux VFIO PCI Device Driver +Copyright(c) 2023 Advanced Micro Devices, Inc. + +Overview +======== + +The ``pds-vfio-pci`` module is a PCI driver that supports Live Migration +capable Virtual Function (VF) devices in the DSC hardware. + +Using the device +================ + +The pds-vfio-pci device is enabled via multiple configuration steps and +depends on the ``pds_core`` driver to create and enable SR-IOV Virtual +Function devices. + +Shown below are the steps to bind the driver to a VF and also to the +associated auxiliary device created by the ``pds_core`` driver. This +example assumes the pds_core and pds-vfio-pci modules are already +loaded. + +.. code-block:: bash + :name: example-setup-script + + #!/bin/bash + + PF_BUS="0000:60" + PF_BDF="0000:60:00.0" + VF_BDF="0000:60:00.1" + + # Prevent non-vfio VF driver from probing the VF device + echo 0 > /sys/class/pci_bus/$PF_BUS/device/$PF_BDF/sriov_drivers_autoprobe + + # Create single VF for Live Migration via pds_core + echo 1 > /sys/bus/pci/drivers/pds_core/$PF_BDF/sriov_numvfs + + # Allow the VF to be bound to the pds-vfio-pci driver + echo "pds-vfio-pci" > /sys/class/pci_bus/$PF_BUS/device/$VF_BDF/driver_override + + # Bind the VF to the pds-vfio-pci driver + echo "$VF_BDF" > /sys/bus/pci/drivers/pds-vfio-pci/bind + +After performing the steps above, a file in /dev/vfio/<iommu_group> +should have been created. + + +Enabling the driver +=================== + +The driver is enabled via the standard kernel configuration system, +using the make command:: + + make oldconfig/menuconfig/etc. + +The driver is located in the menu structure at: + + -> Device Drivers + -> VFIO Non-Privileged userspace driver framework + -> VFIO support for PDS PCI devices + +Support +======= + +For general Linux networking support, please use the netdev mailing +list, which is monitored by Pensando personnel:: + + netdev@vger.kernel.org + +For more specific support needs, please use the Pensando driver support +email:: + + drivers@pensando.io diff --git a/Documentation/networking/device_drivers/ethernet/google/gve.rst b/Documentation/networking/device_drivers/ethernet/google/gve.rst index 6d73ee78f3d7..31d621bca82e 100644 --- a/Documentation/networking/device_drivers/ethernet/google/gve.rst +++ b/Documentation/networking/device_drivers/ethernet/google/gve.rst @@ -52,6 +52,15 @@ Descriptor Formats GVE supports two descriptor formats: GQI and DQO. These two formats have entirely different descriptors, which will be described below. +Addressing Mode +------------------ +GVE supports two addressing modes: QPL and RDA. +QPL ("queue-page-list") mode communicates data through a set of +pre-registered pages. + +For RDA ("raw DMA addressing") mode, the set of pages is dynamic. +Therefore, the packet buffers can be anywhere in guest memory. + Registers --------- All registers are MMIO. diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst index 417ca514a4d0..9827e816084b 100644 --- a/Documentation/networking/device_drivers/ethernet/index.rst +++ b/Documentation/networking/device_drivers/ethernet/index.rst @@ -15,6 +15,8 @@ Contents: amazon/ena altera/altera_tse amd/pds_core + amd/pds_vdpa + amd/pds_vfio_pci aquantia/atlantic chelsio/cxgb cirrus/cs89x0 diff --git a/Documentation/networking/device_drivers/ethernet/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst index 69695e5511f4..e4d065c55ea8 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/ice.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst @@ -84,24 +84,6 @@ Once the VM shuts down, or otherwise releases the VF, the command will complete. -Important notes for SR-IOV and Link Aggregation ------------------------------------------------ -Link Aggregation is mutually exclusive with SR-IOV. - -- If Link Aggregation is active, SR-IOV VFs cannot be created on the PF. -- If SR-IOV is active, you cannot set up Link Aggregation on the interface. - -Bridging and MACVLAN are also affected by this. If you wish to use bridging or -MACVLAN with SR-IOV, you must set up bridging or MACVLAN before enabling -SR-IOV. If you are using bridging or MACVLAN in conjunction with SR-IOV, and -you want to remove the interface from the bridge or MACVLAN, you must follow -these steps: - -1. Destroy SR-IOV VFs if they exist -2. Remove the interface from the bridge or MACVLAN -3. Recreate SRIOV VFs as needed - - Additional Features and Configurations ====================================== diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst index 5ba9015336e2..1e196cb9ce25 100644 --- a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst +++ b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst @@ -13,6 +13,7 @@ Contents - `Drivers`_ - `Basic packet flow`_ - `Devlink health reporters`_ +- `Quality of service`_ Overview ======== @@ -287,3 +288,55 @@ For example:: NIX_AF_ERR: NIX Error Interrupt Reg : 64 Rx on unmapped PF_FUNC + + +Quality of service +================== + + +Hardware algorithms used in scheduling +-------------------------------------- + +octeontx2 silicon and CN10K transmit interface consists of five transmit levels +starting from SMQ/MDQ, TL4 to TL1. Each packet will traverse MDQ, TL4 to TL1 +levels. Each level contains an array of queues to support scheduling and shaping. +The hardware uses the below algorithms depending on the priority of scheduler queues. +once the usercreates tc classes with different priorities, the driver configures +schedulers allocated to the class with specified priority along with rate-limiting +configuration. + +1. Strict Priority + + - Once packets are submitted to MDQ, hardware picks all active MDQs having different priority + using strict priority. + +2. Round Robin + + - Active MDQs having the same priority level are chosen using round robin. + + +Setup HTB offload +----------------- + +1. Enable HW TC offload on the interface:: + + # ethtool -K <interface> hw-tc-offload on + +2. Crate htb root:: + + # tc qdisc add dev <interface> clsact + # tc qdisc replace dev <interface> root handle 1: htb offload + +3. Create tc classes with different priorities:: + + # tc class add dev <interface> parent 1: classid 1:1 htb rate 10Gbit prio 1 + + # tc class add dev <interface> parent 1: classid 1:2 htb rate 10Gbit prio 7 + +4. Create tc classes with same priorities and different quantum:: + + # tc class add dev <interface> parent 1: classid 1:1 htb rate 10Gbit prio 2 quantum 409600 + + # tc class add dev <interface> parent 1: classid 1:2 htb rate 10Gbit prio 2 quantum 188416 + + # tc class add dev <interface> parent 1: classid 1:3 htb rate 10Gbit prio 2 quantum 32768 diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst index 6b2d1fe74ecf..f69ee1ebee01 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst @@ -346,6 +346,24 @@ the software port. - The number of receive packets with CQE compression on ring i [#accel]_. - Acceleration + * - `rx[i]_arfs_add` + - The number of aRFS flow rules added to the device for direct RQ steering + on ring i [#accel]_. + - Acceleration + + * - `rx[i]_arfs_request_in` + - Number of flow rules that have been requested to move into ring i for + direct RQ steering [#accel]_. + - Acceleration + + * - `rx[i]_arfs_request_out` + - Number of flow rules that have been requested to move out of ring i [#accel]_. + - Acceleration + + * - `rx[i]_arfs_expired` + - Number of flow rules that have been expired and removed [#accel]_. + - Acceleration + * - `rx[i]_arfs_err` - Number of flow rules that failed to be added to the flow table. - Error @@ -445,11 +463,6 @@ the software port. context. - Error - * - `rx[i]_xsk_arfs_err` - - aRFS (accelerated Receive Flow Steering) does not occur in the XSK RQ - context, so this counter should never increment. - - Error - * - `rx[i]_xdp_tx_xmit` - The number of packets forwarded back to the port due to XDP program `XDP_TX` action (bouncing). these packets are not counted by other @@ -683,6 +696,12 @@ the software port. time protocol. - Error + * - `ptp_cq[i]_late_cqe` + - Number of times a CQE has been delivered on the PTP timestamping CQ when + the CQE was not expected since a certain amount of time had elapsed where + the device typically ensures not posting the CQE. + - Error + .. [#ring_global] The corresponding ring and global counters do not share the same name (i.e. do not follow the common naming scheme). @@ -797,6 +816,16 @@ Counters on the NIC port that is connected to a eSwitch. RoCE/UD/RC traffic) [#accel]_. - Acceleration + * - `vport_loopback_packets` + - Unicast, multicast and broadcast packets that were loop-back (received + and transmitted), IB/Eth [#accel]_. + - Acceleration + + * - `vport_loopback_bytes` + - Unicast, multicast and broadcast bytes that were loop-back (received + and transmitted), IB/Eth [#accel]_. + - Acceleration + * - `rx_steer_missed_packets` - Number of packets that was received by the NIC, however was discarded because it did not match any flow in the NIC flow table. diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst deleted file mode 100644 index 3354ca3608ee..000000000000 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst +++ /dev/null @@ -1,306 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB -.. include:: <isonum.txt> - -======= -Devlink -======= - -:Copyright: |copy| 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved. - -Contents -======== - -- `Info`_ -- `Parameters`_ -- `Health reporters`_ - -Info -==== - -The devlink info reports the running and stored firmware versions on device. -It also prints the device PSID which represents the HCA board type ID. - -User command example:: - - $ devlink dev info pci/0000:00:06.0 - pci/0000:00:06.0: - driver mlx5_core - versions: - fixed: - fw.psid MT_0000000009 - running: - fw.version 16.26.0100 - stored: - fw.version 16.26.0100 - -Parameters -========== - -flow_steering_mode: Device flow steering mode ---------------------------------------------- -The flow steering mode parameter controls the flow steering mode of the driver. -Two modes are supported: - -1. 'dmfs' - Device managed flow steering. -2. 'smfs' - Software/Driver managed flow steering. - -In DMFS mode, the HW steering entities are created and managed through the -Firmware. -In SMFS mode, the HW steering entities are created and managed though by -the driver directly into hardware without firmware intervention. - -SMFS mode is faster and provides better rule insertion rate compared to default DMFS mode. - -User command examples: - -- Set SMFS flow steering mode:: - - $ devlink dev param set pci/0000:06:00.0 name flow_steering_mode value "smfs" cmode runtime - -- Read device flow steering mode:: - - $ devlink dev param show pci/0000:06:00.0 name flow_steering_mode - pci/0000:06:00.0: - name flow_steering_mode type driver-specific - values: - cmode runtime value smfs - -enable_roce: RoCE enablement state ----------------------------------- -If the device supports RoCE disablement, RoCE enablement state controls device -support for RoCE capability. Otherwise, the control occurs in the driver stack. -When RoCE is disabled at the driver level, only raw ethernet QPs are supported. - -To change RoCE enablement state, a user must change the driverinit cmode value -and run devlink reload. - -User command examples: - -- Disable RoCE:: - - $ devlink dev param set pci/0000:06:00.0 name enable_roce value false cmode driverinit - $ devlink dev reload pci/0000:06:00.0 - -- Read RoCE enablement state:: - - $ devlink dev param show pci/0000:06:00.0 name enable_roce - pci/0000:06:00.0: - name enable_roce type generic - values: - cmode driverinit value true - -esw_port_metadata: Eswitch port metadata state ----------------------------------------------- -When applicable, disabling eswitch metadata can increase packet rate -up to 20% depending on the use case and packet sizes. - -Eswitch port metadata state controls whether to internally tag packets with -metadata. Metadata tagging must be enabled for multi-port RoCE, failover -between representors and stacked devices. -By default metadata is enabled on the supported devices in E-switch. -Metadata is applicable only for E-switch in switchdev mode and -users may disable it when NONE of the below use cases will be in use: - -1. HCA is in Dual/multi-port RoCE mode. -2. VF/SF representor bonding (Usually used for Live migration) -3. Stacked devices - -When metadata is disabled, the above use cases will fail to initialize if -users try to enable them. - -- Show eswitch port metadata:: - - $ devlink dev param show pci/0000:06:00.0 name esw_port_metadata - pci/0000:06:00.0: - name esw_port_metadata type driver-specific - values: - cmode runtime value true - -- Disable eswitch port metadata:: - - $ devlink dev param set pci/0000:06:00.0 name esw_port_metadata value false cmode runtime - -- Change eswitch mode to switchdev mode where after choosing the metadata value:: - - $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev - -hairpin_num_queues: Number of hairpin queues --------------------------------------------- -We refer to a TC NIC rule that involves forwarding as "hairpin". - -Hairpin queues are mlx5 hardware specific implementation for hardware -forwarding of such packets. - -- Show the number of hairpin queues:: - - $ devlink dev param show pci/0000:06:00.0 name hairpin_num_queues - pci/0000:06:00.0: - name hairpin_num_queues type driver-specific - values: - cmode driverinit value 2 - -- Change the number of hairpin queues:: - - $ devlink dev param set pci/0000:06:00.0 name hairpin_num_queues value 4 cmode driverinit - -hairpin_queue_size: Size of the hairpin queues ----------------------------------------------- -Control the size of the hairpin queues. - -- Show the size of the hairpin queues:: - - $ devlink dev param show pci/0000:06:00.0 name hairpin_queue_size - pci/0000:06:00.0: - name hairpin_queue_size type driver-specific - values: - cmode driverinit value 1024 - -- Change the size (in packets) of the hairpin queues:: - - $ devlink dev param set pci/0000:06:00.0 name hairpin_queue_size value 512 cmode driverinit - -Health reporters -================ - -tx reporter ------------ -The tx reporter is responsible for reporting and recovering of the following two error scenarios: - -- tx timeout - Report on kernel tx timeout detection. - Recover by searching lost interrupts. -- tx error completion - Report on error tx completion. - Recover by flushing the tx queue and reset it. - -tx reporter also support on demand diagnose callback, on which it provides -real time information of its send queues status. - -User commands examples: - -- Diagnose send queues status:: - - $ devlink health diagnose pci/0000:82:00.0 reporter tx - -.. note:: - This command has valid output only when interface is up, otherwise the command has empty output. - -- Show number of tx errors indicated, number of recover flows ended successfully, - is autorecover enabled and graceful period from last recover:: - - $ devlink health show pci/0000:82:00.0 reporter tx - -rx reporter ------------ -The rx reporter is responsible for reporting and recovering of the following two error scenarios: - -- rx queues' initialization (population) timeout - Population of rx queues' descriptors on ring initialization is done - in napi context via triggering an irq. In case of a failure to get - the minimum amount of descriptors, a timeout would occur, and - descriptors could be recovered by polling the EQ (Event Queue). -- rx completions with errors (reported by HW on interrupt context) - Report on rx completion error. - Recover (if needed) by flushing the related queue and reset it. - -rx reporter also supports on demand diagnose callback, on which it -provides real time information of its receive queues' status. - -- Diagnose rx queues' status and corresponding completion queue:: - - $ devlink health diagnose pci/0000:82:00.0 reporter rx - -NOTE: This command has valid output only when interface is up. Otherwise, the command has empty output. - -- Show number of rx errors indicated, number of recover flows ended successfully, - is autorecover enabled, and graceful period from last recover:: - - $ devlink health show pci/0000:82:00.0 reporter rx - -fw reporter ------------ -The fw reporter implements `diagnose` and `dump` callbacks. -It follows symptoms of fw error such as fw syndrome by triggering -fw core dump and storing it into the dump buffer. -The fw reporter diagnose command can be triggered any time by the user to check -current fw status. - -User commands examples: - -- Check fw heath status:: - - $ devlink health diagnose pci/0000:82:00.0 reporter fw - -- Read FW core dump if already stored or trigger new one:: - - $ devlink health dump show pci/0000:82:00.0 reporter fw - -.. note:: - This command can run only on the PF which has fw tracer ownership, - running it on other PF or any VF will return "Operation not permitted". - -fw fatal reporter ------------------ -The fw fatal reporter implements `dump` and `recover` callbacks. -It follows fatal errors indications by CR-space dump and recover flow. -The CR-space dump uses vsc interface which is valid even if the FW command -interface is not functional, which is the case in most FW fatal errors. -The recover function runs recover flow which reloads the driver and triggers fw -reset if needed. -On firmware error, the health buffer is dumped into the dmesg. The log -level is derived from the error's severity (given in health buffer). - -User commands examples: - -- Run fw recover flow manually:: - - $ devlink health recover pci/0000:82:00.0 reporter fw_fatal - -- Read FW CR-space dump if already stored or trigger new one:: - - $ devlink health dump show pci/0000:82:00.1 reporter fw_fatal - -.. note:: - This command can run only on PF. - -vnic reporter -------------- -The vnic reporter implements only the `diagnose` callback. -It is responsible for querying the vnic diagnostic counters from fw and displaying -them in realtime. - -Description of the vnic counters: - -- total_q_under_processor_handle - number of queues in an error state due to - an async error or errored command. -- send_queue_priority_update_flow - number of QP/SQ priority/SL update events. -- cq_overrun - number of times CQ entered an error state due to an overflow. -- async_eq_overrun - number of times an EQ mapped to async events was overrun. - comp_eq_overrun number of times an EQ mapped to completion events was - overrun. -- quota_exceeded_command - number of commands issued and failed due to quota exceeded. -- invalid_command - number of commands issued and failed dues to any reason other than quota - exceeded. -- nic_receive_steering_discard - number of packets that completed RX flow - steering but were discarded due to a mismatch in flow table. - -User commands examples: - -- Diagnose PF/VF vnic counters:: - - $ devlink health diagnose pci/0000:82:00.1 reporter vnic - -- Diagnose representor vnic counters (performed by supplying devlink port of the - representor, which can be obtained via devlink port command):: - - $ devlink health diagnose pci/0000:82:00.1/65537 reporter vnic - -.. note:: - This command can run over all interfaces such as PF/VF and representor ports. diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst index 3fdcd6b61ccf..581a91caa579 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst @@ -13,7 +13,6 @@ Contents: :maxdepth: 2 kconfig - devlink switchdev tracepoints counters diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst index 43b1f7e87ec4..0a42c3395ffa 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst @@ -36,7 +36,7 @@ Enabling the driver and kconfig options **CONFIG_MLX5_CORE_EN_DCB=(y/n)**: -| Enables `Data Center Bridging (DCB) Support <https://community.mellanox.com/s/article/howto-auto-config-pfc-and-ets-on-connectx-4-via-lldp-dcbx>`_. +| Enables `Data Center Bridging (DCB) Support <https://enterprise-support.nvidia.com/s/article/howto-auto-config-pfc-and-ets-on-connectx-4-via-lldp-dcbx>`_. **CONFIG_MLX5_CORE_IPOIB=(y/n)** @@ -59,12 +59,12 @@ Enabling the driver and kconfig options **CONFIG_MLX5_EN_ARFS=(y/n)** | Enables Hardware-accelerated receive flow steering (arfs) support, and ntuple filtering. -| https://community.mellanox.com/s/article/howto-configure-arfs-on-connectx-4 +| https://enterprise-support.nvidia.com/s/article/howto-configure-arfs-on-connectx-4 **CONFIG_MLX5_EN_IPSEC=(y/n)** -| Enables `IPSec XFRM cryptography-offload acceleration <https://support.mellanox.com/s/article/ConnectX-6DX-Bluefield-2-IPsec-HW-Full-Offload-Configuration-Guide>`_. +| Enables :ref:`IPSec XFRM cryptography-offload acceleration <xfrm_device>`. **CONFIG_MLX5_EN_MACSEC=(y/n)** @@ -87,8 +87,8 @@ Enabling the driver and kconfig options | Ethernet SRIOV E-Switch support in ConnectX NIC. E-Switch provides internal SRIOV packet steering | and switching for the enabled VFs and PF in two available modes: -| 1) `Legacy SRIOV mode (L2 mac vlan steering based) <https://community.mellanox.com/s/article/howto-configure-sr-iov-for-connectx-4-connectx-5-with-kvm--ethernet-x>`_. -| 2) `Switchdev mode (eswitch offloads) <https://www.mellanox.com/related-docs/prod_software/ASAP2_Hardware_Offloading_for_vSwitches_User_Manual_v4.4.pdf>`_. +| 1) `Legacy SRIOV mode (L2 mac vlan steering based) <https://enterprise-support.nvidia.com/s/article/HowTo-Configure-SR-IOV-for-ConnectX-4-ConnectX-5-ConnectX-6-with-KVM-Ethernet>`_. +| 2) :ref:`Switchdev mode (eswitch offloads) <switchdev>`. **CONFIG_MLX5_FPGA=(y/n)** @@ -101,13 +101,13 @@ Enabling the driver and kconfig options **CONFIG_MLX5_INFINIBAND=(y/n/m)** (module mlx5_ib.ko) -| Provides low-level InfiniBand/RDMA and `RoCE <https://community.mellanox.com/s/article/recommended-network-configuration-examples-for-roce-deployment>`_ support. +| Provides low-level InfiniBand/RDMA and `RoCE <https://enterprise-support.nvidia.com/s/article/recommended-network-configuration-examples-for-roce-deployment>`_ support. **CONFIG_MLX5_MPFS=(y/n)** | Ethernet Multi-Physical Function Switch (MPFS) support in ConnectX NIC. -| MPFs is required for when `Multi-Host <http://www.mellanox.com/page/multihost>`_ configuration is enabled to allow passing +| MPFs is required for when `Multi-Host <https://www.nvidia.com/en-us/networking/multi-host/>`_ configuration is enabled to allow passing | user configured unicast MAC addresses to the requesting PF. diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst index 01deedb71597..b617e93d7c2c 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst @@ -45,6 +45,28 @@ Following bridge VLAN functions are supported by mlx5: Subfunction =========== +Subfunction which are spawned over the E-switch are created only with devlink +device, and by default all the SF auxiliary devices are disabled. +This will allow user to configure the SF before the SF have been fully probed, +which will save time. + +Usage example: + +- Create SF:: + + $ devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 11 + $ devlink port function set pci/0000:08:00.0/32768 hw_addr 00:00:00:00:00:11 state active + +- Enable ETH auxiliary device:: + + $ devlink dev param set auxiliary/mlx5_core.sf.1 name enable_eth value true cmode driverinit + +- Now, in order to fully probe the SF, use devlink reload:: + + $ devlink dev reload auxiliary/mlx5_core.sf.1 + +mlx5 supports ETH,rdma and vdpa (vnet) auxiliary devices devlink params (see :ref:`Documentation/networking/devlink/devlink-params.rst <devlink_params_generic>`). + mlx5 supports subfunction management using devlink port (see :ref:`Documentation/networking/devlink/devlink-port.rst <devlink_port>`) interface. A subfunction has its own function capabilities and its own resources. This @@ -168,6 +190,26 @@ explicitly enable the VF migratable capability. mlx5 driver support devlink port function attr mechanism to setup migratable capability. (refer to Documentation/networking/devlink/devlink-port.rst) +IPsec crypto capability setup +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +User who wants mlx5 PCI VFs to be able to perform IPsec crypto offloading need +to explicitly enable the VF ipsec_crypto capability. Enabling IPsec capability +for VFs is supported starting with ConnectX6dx devices and above. When a VF has +IPsec capability enabled, any IPsec offloading is blocked on the PF. + +mlx5 driver support devlink port function attr mechanism to setup ipsec_crypto +capability. (refer to Documentation/networking/devlink/devlink-port.rst) + +IPsec packet capability setup +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +User who wants mlx5 PCI VFs to be able to perform IPsec packet offloading need +to explicitly enable the VF ipsec_packet capability. Enabling IPsec capability +for VFs is supported starting with ConnectX6dx devices and above. When a VF has +IPsec capability enabled, any IPsec offloading is blocked on the PF. + +mlx5 driver support devlink port function attr mechanism to setup ipsec_packet +capability. (refer to Documentation/networking/devlink/devlink-port.rst) + SF state setup -------------- diff --git a/Documentation/networking/devlink/devlink-port.rst b/Documentation/networking/devlink/devlink-port.rst index 3da590953ce8..e33ad2401ad7 100644 --- a/Documentation/networking/devlink/devlink-port.rst +++ b/Documentation/networking/devlink/devlink-port.rst @@ -128,6 +128,12 @@ Users may also set the RoCE capability of the function using Users may also set the function as migratable using 'devlink port function set migratable' command. +Users may also set the IPsec crypto capability of the function using +`devlink port function set ipsec_crypto` command. + +Users may also set the IPsec packet capability of the function using +`devlink port function set ipsec_packet` command. + Function attributes =================== @@ -240,6 +246,55 @@ Attach VF to the VM. Start the VM. Perform live migration. +IPsec crypto capability setup +----------------------------- +When user enables IPsec crypto capability for a VF, user application can offload +XFRM state crypto operation (Encrypt/Decrypt) to this VF. + +When IPsec crypto capability is disabled (default) for a VF, the XFRM state is +processed in software by the kernel. + +- Get IPsec crypto capability of the VF device:: + + $ devlink port show pci/0000:06:00.0/2 + pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1 + function: + hw_addr 00:00:00:00:00:00 ipsec_crypto disabled + +- Set IPsec crypto capability of the VF device:: + + $ devlink port function set pci/0000:06:00.0/2 ipsec_crypto enable + + $ devlink port show pci/0000:06:00.0/2 + pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1 + function: + hw_addr 00:00:00:00:00:00 ipsec_crypto enabled + +IPsec packet capability setup +----------------------------- +When user enables IPsec packet capability for a VF, user application can offload +XFRM state and policy crypto operation (Encrypt/Decrypt) to this VF, as well as +IPsec encapsulation. + +When IPsec packet capability is disabled (default) for a VF, the XFRM state and +policy is processed in software by the kernel. + +- Get IPsec packet capability of the VF device:: + + $ devlink port show pci/0000:06:00.0/2 + pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1 + function: + hw_addr 00:00:00:00:00:00 ipsec_packet disabled + +- Set IPsec packet capability of the VF device:: + + $ devlink port function set pci/0000:06:00.0/2 ipsec_packet enable + + $ devlink port show pci/0000:06:00.0/2 + pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1 + function: + hw_addr 00:00:00:00:00:00 ipsec_packet enabled + Subfunction ============ @@ -321,9 +376,9 @@ API allows to configure following rate object's parameters: Allows for usage of Weighted Fair Queuing arbitration scheme among siblings. This arbitration scheme can be used simultaneously with the strict priority. As a node is configured with a higher rate it gets more - BW relative to it's siblings. Values are relative like a percentage + BW relative to its siblings. Values are relative like a percentage points, they basically tell how much BW should node take relative to - it's siblings. + its siblings. ``parent`` Parent node name. Parent node rate limits are considered as additional limits @@ -343,7 +398,7 @@ Arbitration flow from the high level: #. If group of nodes have the same priority perform WFQ arbitration on that subgroup. Use ``tx_weight`` as a parameter for this arbitration. -#. Select the winner node, and continue arbitration flow among it's children, +#. Select the winner node, and continue arbitration flow among its children, until leaf node is reached, and the winner is established. #. If all the nodes from the highest priority sub-group are satisfied, or diff --git a/Documentation/networking/devlink/mlx5.rst b/Documentation/networking/devlink/mlx5.rst index 202798d6501e..702f204a3dbd 100644 --- a/Documentation/networking/devlink/mlx5.rst +++ b/Documentation/networking/devlink/mlx5.rst @@ -18,6 +18,11 @@ Parameters * - ``enable_roce`` - driverinit - Type: Boolean + + If the device supports RoCE disablement, RoCE enablement state controls + device support for RoCE capability. Otherwise, the control occurs in the + driver stack. When RoCE is disabled at the driver level, only raw + ethernet QPs are supported. * - ``io_eq_size`` - driverinit - The range is between 64 and 4096. @@ -48,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. + + SMFS mode is faster and provides better rule insertion rate compared to + default DMFS mode. * - ``fdb_large_groups`` - u32 - driverinit @@ -71,7 +79,24 @@ parameters. deprecated. Default: disabled + * - ``esw_port_metadata`` + - Boolean + - runtime + - When applicable, disabling eswitch metadata can increase packet rate up + to 20% depending on the use case and packet sizes. + + Eswitch port metadata state controls whether to internally tag packets + with metadata. Metadata tagging must be enabled for multi-port RoCE, + failover between representors and stacked devices. By default metadata is + enabled on the supported devices in E-switch. Metadata is applicable only + for E-switch in switchdev mode and users may disable it when NONE of the + below use cases will be in use: + 1. HCA is in Dual/multi-port RoCE mode. + 2. VF/SF representor bonding (Usually used for Live migration) + 3. Stacked devices + When metadata is disabled, the above use cases will fail to initialize if + users try to enable them. * - ``hairpin_num_queues`` - u32 - driverinit @@ -104,3 +129,160 @@ The ``mlx5`` driver reports the following versions * - ``fw.version`` - stored, running - Three digit major.minor.subminor firmware version number. + +Health reporters +================ + +tx reporter +----------- +The tx reporter is responsible for reporting and recovering of the following three error scenarios: + +- tx timeout + Report on kernel tx timeout detection. + Recover by searching lost interrupts. +- tx error completion + Report on error tx completion. + Recover by flushing the tx queue and reset it. +- tx PTP port timestamping CQ unhealthy + Report too many CQEs never delivered on port ts CQ. + Recover by flushing and re-creating all PTP channels. + +tx reporter also support on demand diagnose callback, on which it provides +real time information of its send queues status. + +User commands examples: + +- Diagnose send queues status:: + + $ devlink health diagnose pci/0000:82:00.0 reporter tx + +.. note:: + This command has valid output only when interface is up, otherwise the command has empty output. + +- Show number of tx errors indicated, number of recover flows ended successfully, + is autorecover enabled and graceful period from last recover:: + + $ devlink health show pci/0000:82:00.0 reporter tx + +rx reporter +----------- +The rx reporter is responsible for reporting and recovering of the following two error scenarios: + +- rx queues' initialization (population) timeout + Population of rx queues' descriptors on ring initialization is done + in napi context via triggering an irq. In case of a failure to get + the minimum amount of descriptors, a timeout would occur, and + descriptors could be recovered by polling the EQ (Event Queue). +- rx completions with errors (reported by HW on interrupt context) + Report on rx completion error. + Recover (if needed) by flushing the related queue and reset it. + +rx reporter also supports on demand diagnose callback, on which it +provides real time information of its receive queues' status. + +- Diagnose rx queues' status and corresponding completion queue:: + + $ devlink health diagnose pci/0000:82:00.0 reporter rx + +.. note:: + This command has valid output only when interface is up. Otherwise, the command has empty output. + +- Show number of rx errors indicated, number of recover flows ended successfully, + is autorecover enabled, and graceful period from last recover:: + + $ devlink health show pci/0000:82:00.0 reporter rx + +fw reporter +----------- +The fw reporter implements `diagnose` and `dump` callbacks. +It follows symptoms of fw error such as fw syndrome by triggering +fw core dump and storing it into the dump buffer. +The fw reporter diagnose command can be triggered any time by the user to check +current fw status. + +User commands examples: + +- Check fw heath status:: + + $ devlink health diagnose pci/0000:82:00.0 reporter fw + +- Read FW core dump if already stored or trigger new one:: + + $ devlink health dump show pci/0000:82:00.0 reporter fw + +.. note:: + This command can run only on the PF which has fw tracer ownership, + running it on other PF or any VF will return "Operation not permitted". + +fw fatal reporter +----------------- +The fw fatal reporter implements `dump` and `recover` callbacks. +It follows fatal errors indications by CR-space dump and recover flow. +The CR-space dump uses vsc interface which is valid even if the FW command +interface is not functional, which is the case in most FW fatal errors. +The recover function runs recover flow which reloads the driver and triggers fw +reset if needed. +On firmware error, the health buffer is dumped into the dmesg. The log +level is derived from the error's severity (given in health buffer). + +User commands examples: + +- Run fw recover flow manually:: + + $ devlink health recover pci/0000:82:00.0 reporter fw_fatal + +- Read FW CR-space dump if already stored or trigger new one:: + + $ devlink health dump show pci/0000:82:00.1 reporter fw_fatal + +.. note:: + This command can run only on PF. + +vnic reporter +------------- +The vnic reporter implements only the `diagnose` callback. +It is responsible for querying the vnic diagnostic counters from fw and displaying +them in realtime. + +Description of the vnic counters: + +- total_q_under_processor_handle + number of queues in an error state due to + an async error or errored command. +- send_queue_priority_update_flow + number of QP/SQ priority/SL update events. +- cq_overrun + number of times CQ entered an error state due to an overflow. +- async_eq_overrun + number of times an EQ mapped to async events was overrun. + comp_eq_overrun number of times an EQ mapped to completion events was + overrun. +- quota_exceeded_command + number of commands issued and failed due to quota exceeded. +- invalid_command + number of commands issued and failed dues to any reason other than quota + exceeded. +- nic_receive_steering_discard + number of packets that completed RX flow + steering but were discarded due to a mismatch in flow table. +- generated_pkt_steering_fail + number of packets generated by the VNIC experiencing unexpected steering + failure (at any point in steering flow). +- handled_pkt_steering_fail + number of packets handled by the VNIC experiencing unexpected steering + failure (at any point in steering flow owned by the VNIC, including the FDB + for the eswitch owner). + +User commands examples: + +- Diagnose PF/VF vnic counters:: + + $ devlink health diagnose pci/0000:82:00.1 reporter vnic + +- Diagnose representor vnic counters (performed by supplying devlink port of the + representor, which can be obtained via devlink port command):: + + $ devlink health diagnose pci/0000:82:00.1/65537 reporter vnic + +.. note:: + This command can run over all interfaces such as PF/VF and representor ports. diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 80b8f73a0244..a66054d0763a 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -321,6 +321,7 @@ tcp_abort_on_overflow - BOOLEAN option can harm clients of your server. tcp_adv_win_scale - INTEGER + Obsolete since linux-6.6 Count buffering overhead as bytes/2^tcp_adv_win_scale (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale), if it is <= 0. @@ -881,9 +882,10 @@ tcp_fastopen_key - list of comma separated 32-digit hexadecimal INTEGERs tcp_syn_retries - INTEGER Number of times initial SYNs for an active TCP connection attempt will be retransmitted. Should not be higher than 127. Default value - is 6, which corresponds to 63seconds till the last retransmission - with the current initial RTO of 1second. With this the final timeout - for an active TCP connection attempt will happen after 127seconds. + is 6, which corresponds to 67seconds (with tcp_syn_linear_timeouts = 4) + till the last retransmission with the current initial RTO of 1second. + With this the final timeout for an active TCP connection attempt + will happen after 131seconds. tcp_timestamps - INTEGER Enable timestamps as defined in RFC1323. @@ -946,6 +948,16 @@ tcp_pacing_ca_ratio - INTEGER Default: 120 +tcp_syn_linear_timeouts - INTEGER + The number of times for an active TCP connection to retransmit SYNs with + a linear backoff timeout before defaulting to an exponential backoff + timeout. This has no effect on SYNACK at the passive TCP side. + + With an initial RTO of 1 and tcp_syn_linear_timeouts = 4 we would + expect SYN RTOs to be: 1, 1, 1, 1, 1, 2, 4, ... (4 linear timeouts, + and the first exponential backoff using 2^0 * initial_RTO). + Default: 4 + tcp_tso_win_divisor - INTEGER This allows control over what percentage of the congestion window can be consumed by a single TSO frame. @@ -970,6 +982,21 @@ tcp_tw_reuse - INTEGER tcp_window_scaling - BOOLEAN Enable window scaling as defined in RFC1323. +tcp_shrink_window - BOOLEAN + This changes how the TCP receive window is calculated. + + RFC 7323, section 2.4, says there are instances when a retracted + window can be offered, and that TCP implementations MUST ensure + that they handle a shrinking window, as specified in RFC 1122. + + - 0 - Disabled. The window is never shrunk. + - 1 - Enabled. The window is shrunk when necessary to remain within + the memory limit set by autotuning (sk_rcvbuf). + This only occurs if a non-zero receive window + scaling factor is also in effect. + + Default: 0 + tcp_wmem - vector of 3 INTEGERs: min, default, max min: Amount of memory reserved for send buffers for TCP sockets. Each TCP socket has rights to use it due to fact of its birth. @@ -2261,6 +2288,14 @@ accept_ra_min_hop_limit - INTEGER Default: 1 +accept_ra_min_lft - INTEGER + Minimum acceptable lifetime value in Router Advertisement. + + RA sections with a lifetime less than this value shall be + ignored. Zero lifetimes stay unaffected. + + Default: 0 + accept_ra_pinfo - BOOLEAN Learn Prefix Information in Router Advertisement. diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index 213510698014..15f1919d640c 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -74,3 +74,11 @@ stale_loss_cnt - INTEGER This is a per-namespace sysctl. Default: 4 + +scheduler - STRING + Select the scheduler of your choice. + + Support for selection of different schedulers. This is a per-namespace + sysctl. + + Default: "default" diff --git a/Documentation/networking/napi.rst b/Documentation/networking/napi.rst index a7a047742e93..7bf7b95c4f7a 100644 --- a/Documentation/networking/napi.rst +++ b/Documentation/networking/napi.rst @@ -65,15 +65,16 @@ argument - drivers can process completions for any number of Tx packets but should only process up to ``budget`` number of Rx packets. Rx processing is usually much more expensive. -In other words, it is recommended to ignore the budget argument when -performing TX buffer reclamation to ensure that the reclamation is not -arbitrarily bounded; however, it is required to honor the budget argument -for RX processing. +In other words for Rx processing the ``budget`` argument limits how many +packets driver can process in a single poll. Rx specific APIs like page +pool or XDP cannot be used at all when ``budget`` is 0. +skb Tx processing should happen regardless of the ``budget``, but if +the argument is 0 driver cannot call any XDP (or page pool) APIs. .. warning:: - The ``budget`` argument may be 0 if core tries to only process Tx completions - and no Rx packets. + The ``budget`` argument may be 0 if core tries to only process + skb Tx completions and no Rx or XDP packets. The poll method returns the amount of work done. If the driver still has outstanding work to do (e.g. ``budget`` was exhausted) diff --git a/Documentation/networking/netconsole.rst b/Documentation/networking/netconsole.rst index dd0518e002f6..7a9de0568e84 100644 --- a/Documentation/networking/netconsole.rst +++ b/Documentation/networking/netconsole.rst @@ -13,6 +13,8 @@ IPv6 support by Cong Wang <xiyou.wangcong@gmail.com>, Jan 1 2013 Extended console support by Tejun Heo <tj@kernel.org>, May 1 2015 +Release prepend support by Breno Leitao <leitao@debian.org>, Jul 7 2023 + Please send bug reports to Matt Mackall <mpm@selenic.com> Satyam Sharma <satyam.sharma@gmail.com>, and Cong Wang <xiyou.wangcong@gmail.com> @@ -34,10 +36,11 @@ Sender and receiver configuration: It takes a string configuration parameter "netconsole" in the following format:: - netconsole=[+][src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr] + netconsole=[+][r][src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr] where + if present, enable extended console support + r if present, prepend kernel version (release) to the message src-port source for UDP packets (defaults to 6665) src-ip source IP to use (interface address) dev network interface (eth0) @@ -125,6 +128,7 @@ 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) dev_name Local network interface name (read-write) local_port Source UDP port to use (read-write) remote_port Remote agent's UDP port (read-write) @@ -165,6 +169,11 @@ following format which is the same as /dev/kmsg:: <level>,<sequnum>,<timestamp>,<contflag>;<message text> +If 'r' (release) feature is enabled, the kernel release version is +prepended to the start of the message. Example:: + + 6.4.0,6,444,501151268,-;netconsole: network logging started + Non printable characters in <message text> are escaped using "\xff" notation. If the message contains optional dictionary, verbatim newline is used as the delimiter. diff --git a/Documentation/networking/nf_conntrack-sysctl.rst b/Documentation/networking/nf_conntrack-sysctl.rst index 8b1045c3b59e..c383a394c665 100644 --- a/Documentation/networking/nf_conntrack-sysctl.rst +++ b/Documentation/networking/nf_conntrack-sysctl.rst @@ -178,10 +178,10 @@ nf_conntrack_sctp_timeout_established - INTEGER (seconds) Default is set to (hb_interval * path_max_retrans + rto_max) nf_conntrack_sctp_timeout_shutdown_sent - INTEGER (seconds) - default 0.3 + default 3 nf_conntrack_sctp_timeout_shutdown_recd - INTEGER (seconds) - default 0.3 + default 3 nf_conntrack_sctp_timeout_shutdown_ack_sent - INTEGER (seconds) default 3 diff --git a/Documentation/networking/packet_mmap.rst b/Documentation/networking/packet_mmap.rst index c5da1a5d93de..30a3be3c48f3 100644 --- a/Documentation/networking/packet_mmap.rst +++ b/Documentation/networking/packet_mmap.rst @@ -755,7 +755,7 @@ AF_PACKET TPACKET_V3 example ============================ AF_PACKET's TPACKET_V3 ring buffer can be configured to use non-static frame -sizes by doing it's own memory management. It is based on blocks where polling +sizes by doing its own memory management. It is based on blocks where polling works on a per block basis instead of per ring as in TPACKET_V2 and predecessor. It is said that TPACKET_V3 brings the following benefits: diff --git a/Documentation/networking/page_pool.rst b/Documentation/networking/page_pool.rst index 873efd97f822..215ebc92752c 100644 --- a/Documentation/networking/page_pool.rst +++ b/Documentation/networking/page_pool.rst @@ -4,22 +4,8 @@ Page Pool API ============= -The page_pool allocator is optimized for the XDP mode that uses one frame -per-page, but it can fallback on the regular page allocator APIs. - -Basic use involves replacing alloc_pages() calls with the -page_pool_alloc_pages() call. Drivers should use page_pool_dev_alloc_pages() -replacing dev_alloc_pages(). - -API keeps track of in-flight pages, in order to let API user know -when it is safe to free a page_pool object. Thus, API users -must run page_pool_release_page() when a page is leaving the page_pool or -call page_pool_put_page() where appropriate in order to maintain correct -accounting. - -API user must call page_pool_put_page() once on a page, as it -will either recycle the page, or in case of refcnt > 1, it will -release the DMA mapping and in-flight state accounting. +.. kernel-doc:: include/net/page_pool/helpers.h + :doc: page_pool allocator Architecture overview ===================== @@ -64,87 +50,68 @@ This lockless guarantee naturally comes from running under a NAPI softirq. The protection doesn't strictly have to be NAPI, any guarantee that allocating a page will cause no race conditions is enough. -* page_pool_create(): Create a pool. - * flags: PP_FLAG_DMA_MAP, PP_FLAG_DMA_SYNC_DEV - * order: 2^order pages on allocation - * pool_size: size of the ptr_ring - * nid: preferred NUMA node for allocation - * dev: struct device. Used on DMA operations - * dma_dir: DMA direction - * max_len: max DMA sync memory size - * offset: DMA address offset - -* page_pool_put_page(): The outcome of this depends on the page refcnt. If the - driver bumps the refcnt > 1 this will unmap the page. If the page refcnt is 1 - the allocator owns the page and will try to recycle it in one of the pool - caches. If PP_FLAG_DMA_SYNC_DEV is set, the page will be synced for_device - using dma_sync_single_range_for_device(). - -* page_pool_put_full_page(): Similar to page_pool_put_page(), but will DMA sync - for the entire memory area configured in area pool->max_len. - -* page_pool_recycle_direct(): Similar to page_pool_put_full_page() but caller - must guarantee safe context (e.g NAPI), since it will recycle the page - directly into the pool fast cache. - -* page_pool_release_page(): Unmap the page (if mapped) and account for it on - in-flight counters. - -* page_pool_dev_alloc_pages(): Get a page from the page allocator or page_pool - caches. - -* page_pool_get_dma_addr(): Retrieve the stored DMA address. - -* page_pool_get_dma_dir(): Retrieve the stored DMA direction. - -* page_pool_put_page_bulk(): Tries to refill a number of pages into the - ptr_ring cache holding ptr_ring producer lock. If the ptr_ring is full, - page_pool_put_page_bulk() will release leftover pages to the page allocator. - page_pool_put_page_bulk() is suitable to be run inside the driver NAPI tx - completion loop for the XDP_REDIRECT use case. - Please note the caller must not use data area after running - page_pool_put_page_bulk(), as this function overwrites it. - -* page_pool_get_stats(): Retrieve statistics about the page_pool. This API - is only available if the kernel has been configured with - ``CONFIG_PAGE_POOL_STATS=y``. A pointer to a caller allocated ``struct - page_pool_stats`` structure is passed to this API which is filled in. The - caller can then report those stats to the user (perhaps via ethtool, - debugfs, etc.). See below for an example usage of this API. +.. kernel-doc:: net/core/page_pool.c + :identifiers: page_pool_create + +.. kernel-doc:: include/net/page_pool/types.h + :identifiers: struct page_pool_params + +.. kernel-doc:: include/net/page_pool/helpers.h + :identifiers: page_pool_put_page page_pool_put_full_page + page_pool_recycle_direct page_pool_dev_alloc_pages + page_pool_get_dma_addr page_pool_get_dma_dir + +.. kernel-doc:: net/core/page_pool.c + :identifiers: page_pool_put_page_bulk page_pool_get_stats + +DMA sync +-------- +Driver is always responsible for syncing the pages for the CPU. +Drivers may choose to take care of syncing for the device as well +or set the ``PP_FLAG_DMA_SYNC_DEV`` flag to request that pages +allocated from the page pool are already synced for the device. + +If ``PP_FLAG_DMA_SYNC_DEV`` is set, the driver must inform the core what portion +of the buffer has to be synced. This allows the core to avoid syncing the entire +page when the drivers knows that the device only accessed a portion of the page. + +Most drivers will reserve headroom in front of the frame. This part +of the buffer is not touched by the device, so to avoid syncing +it drivers can set the ``offset`` field in struct page_pool_params +appropriately. + +For pages recycled on the XDP xmit and skb paths the page pool will +use the ``max_len`` member of struct page_pool_params to decide how +much of the page needs to be synced (starting at ``offset``). +When directly freeing pages in the driver (page_pool_put_page()) +the ``dma_sync_size`` argument specifies how much of the buffer needs +to be synced. + +If in doubt set ``offset`` to 0, ``max_len`` to ``PAGE_SIZE`` and +pass -1 as ``dma_sync_size``. That combination of arguments is always +correct. + +Note that the syncing parameters are for the entire page. +This is important to remember when using fragments (``PP_FLAG_PAGE_FRAG``), +where allocated buffers may be smaller than a full page. +Unless the driver author really understands page pool internals +it's recommended to always use ``offset = 0``, ``max_len = PAGE_SIZE`` +with fragmented page pools. Stats API and structures ------------------------ If the kernel is configured with ``CONFIG_PAGE_POOL_STATS=y``, the API -``page_pool_get_stats()`` and structures described below are available. It -takes a pointer to a ``struct page_pool`` and a pointer to a ``struct -page_pool_stats`` allocated by the caller. +page_pool_get_stats() and structures described below are available. +It takes a pointer to a ``struct page_pool`` and a pointer to a struct +page_pool_stats allocated by the caller. -The API will fill in the provided ``struct page_pool_stats`` with +The API will fill in the provided struct page_pool_stats with statistics about the page_pool. -The stats structure has the following fields:: - - struct page_pool_stats { - struct page_pool_alloc_stats alloc_stats; - struct page_pool_recycle_stats recycle_stats; - }; - - -The ``struct page_pool_alloc_stats`` has the following fields: - * ``fast``: successful fast path allocations - * ``slow``: slow path order-0 allocations - * ``slow_high_order``: slow path high order allocations - * ``empty``: ptr ring is empty, so a slow path allocation was forced. - * ``refill``: an allocation which triggered a refill of the cache - * ``waive``: pages obtained from the ptr ring that cannot be added to - the cache due to a NUMA mismatch. - -The ``struct page_pool_recycle_stats`` has the following fields: - * ``cached``: recycling placed page in the page pool cache - * ``cache_full``: page pool cache was full - * ``ring``: page placed into the ptr ring - * ``ring_full``: page released from page pool because the ptr ring was full - * ``released_refcnt``: page released (and not recycled) because refcnt > 1 +.. kernel-doc:: include/net/page_pool/types.h + :identifiers: struct page_pool_recycle_stats + struct page_pool_alloc_stats + struct page_pool_stats Coding examples =============== @@ -194,7 +161,7 @@ NAPI poller if XDP_DROP: page_pool_recycle_direct(page_pool, page); } else (packet_is_skb) { - page_pool_release_page(page_pool, page); + skb_mark_for_recycle(skb); new_page = page_pool_dev_alloc_pages(page_pool); } } diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst index b7ac4c64cf67..1283240d7620 100644 --- a/Documentation/networking/phy.rst +++ b/Documentation/networking/phy.rst @@ -323,6 +323,10 @@ Some of the interface modes are described below: contrast with the 1000BASE-X phy mode used for Clause 38 and 39 PMDs, this interface mode has different autonegotiation and only supports full duplex. +``PHY_INTERFACE_MODE_PSGMII`` + This is the Penta SGMII mode, it is similar to QSGMII but it combines 5 + SGMII lines into a single link compared to 4 on QSGMII. + Pause frames / flow control =========================== diff --git a/Documentation/networking/scaling.rst b/Documentation/networking/scaling.rst index 3d435caa3ef2..92c9fb46d6a2 100644 --- a/Documentation/networking/scaling.rst +++ b/Documentation/networking/scaling.rst @@ -269,8 +269,8 @@ a single application thread handles flows with many different flow hashes. rps_sock_flow_table is a global flow table that contains the *desired* CPU for flows: the CPU that is currently processing the flow in userspace. Each table value is a CPU index that is updated during calls to recvmsg -and sendmsg (specifically, inet_recvmsg(), inet_sendmsg(), inet_sendpage() -and tcp_splice_read()). +and sendmsg (specifically, inet_recvmsg(), inet_sendmsg() and +tcp_splice_read()). When the scheduler moves a thread to a new CPU while it has outstanding receive packets on the old CPU, packets may arrive out of order. To diff --git a/Documentation/networking/xfrm_device.rst b/Documentation/networking/xfrm_device.rst index 83abdfef4ec3..535077cbeb07 100644 --- a/Documentation/networking/xfrm_device.rst +++ b/Documentation/networking/xfrm_device.rst @@ -1,4 +1,5 @@ .. SPDX-License-Identifier: GPL-2.0 +.. _xfrm_device: =============================================== XFRM device - offloading the IPsec computations diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index ef341be2882b..13225965c9a4 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -87,9 +87,9 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM framework. Registration of 'advanced' EM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The 'advanced' EM gets it's name due to the fact that the driver is allowed +The 'advanced' EM gets its name due to the fact that the driver is allowed to provide more precised power model. It's not limited to some implemented math -formula in the framework (like it's in 'simple' EM case). It can better reflect +formula in the framework (like it is in 'simple' EM case). It can better reflect the real power measurements performed for each performance state. Thus, this registration method should be preferred in case considering EM static power (leakage) is important. diff --git a/Documentation/powerpc/dexcr.rst b/Documentation/powerpc/dexcr.rst new file mode 100644 index 000000000000..615a631f51fa --- /dev/null +++ b/Documentation/powerpc/dexcr.rst @@ -0,0 +1,58 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +========================================== +DEXCR (Dynamic Execution Control Register) +========================================== + +Overview +======== + +The DEXCR is a privileged special purpose register (SPR) introduced in +PowerPC ISA 3.1B (Power10) that allows per-cpu control over several dynamic +execution behaviours. These behaviours include speculation (e.g., indirect +branch target prediction) and enabling return-oriented programming (ROP) +protection instructions. + +The execution control is exposed in hardware as up to 32 bits ('aspects') in +the DEXCR. Each aspect controls a certain behaviour, and can be set or cleared +to enable/disable the aspect. There are several variants of the DEXCR for +different purposes: + +DEXCR + A privileged SPR that can control aspects for userspace and kernel space +HDEXCR + A hypervisor-privileged SPR that can control aspects for the hypervisor and + enforce aspects for the kernel and userspace. +UDEXCR + An optional ultravisor-privileged SPR that can control aspects for the ultravisor. + +Userspace can examine the current DEXCR state using a dedicated SPR that +provides a non-privileged read-only view of the userspace DEXCR aspects. +There is also an SPR that provides a read-only view of the hypervisor enforced +aspects, which ORed with the userspace DEXCR view gives the effective DEXCR +state for a process. + + +Configuration +============= + +The DEXCR is currently unconfigurable. All threads are run with the +NPHIE aspect enabled. + + +coredump and ptrace +=================== + +The userspace values of the DEXCR and HDEXCR (in this order) are exposed under +``NT_PPC_DEXCR``. These are each 64 bits and readonly, and are intended to +assist with core dumps. The DEXCR may be made writable in future. The top 32 +bits of both registers (corresponding to the non-userspace bits) are masked off. + +If the kernel config ``CONFIG_CHECKPOINT_RESTORE`` is enabled, then +``NT_PPC_HASHKEYR`` is available and exposes the HASHKEYR value of the process +for reading and writing. This is a tradeoff between increased security and +checkpoint/restore support: a process should normally have no need to know its +secret key, but restoring a process requires setting its original key. The key +therefore appears in core dumps, and an attacker may be able to retrieve it from +a coredump and effectively bypass ROP protection on any threads that share this +key (potentially all threads from the same parent that have not run ``exec()``). diff --git a/Documentation/powerpc/dscr.rst b/Documentation/powerpc/dscr.rst index 2ab99006014c..f735ec5375d5 100644 --- a/Documentation/powerpc/dscr.rst +++ b/Documentation/powerpc/dscr.rst @@ -6,7 +6,7 @@ DSCR register in powerpc allows user to have some control of prefetch of data stream in the processor. Please refer to the ISA documents or related manual for more detailed information regarding how to use this DSCR to attain this control of the prefetches . This document here provides an overview of kernel -support for DSCR, related kernel objects, it's functionalities and exported +support for DSCR, related kernel objects, its functionalities and exported user interface. (A) Data Structures: diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst index 85e80e30160b..a50834798454 100644 --- a/Documentation/powerpc/index.rst +++ b/Documentation/powerpc/index.rst @@ -15,6 +15,7 @@ powerpc cxl cxlflash dawr-power9 + dexcr dscr eeh-pci-error-recovery elf_hwcaps @@ -35,6 +36,7 @@ powerpc ultravisor vas-api vcpudispatch_stats + vmemmap_dedup features diff --git a/Documentation/powerpc/kasan.txt b/Documentation/powerpc/kasan.txt index f032b4eaf205..a4f647e4fffa 100644 --- a/Documentation/powerpc/kasan.txt +++ b/Documentation/powerpc/kasan.txt @@ -40,7 +40,7 @@ checks can be delayed until after the MMU is set is up, and we can just not instrument any code that runs with translations off after booting. This is the current approach. -To avoid this limitiation, the KASAN shadow would have to be placed inside the +To avoid this limitation, the KASAN shadow would have to be placed inside the linear mapping, using the same high-bits trick we use for the rest of the linear mapping. This is tricky: diff --git a/Documentation/powerpc/papr_hcalls.rst b/Documentation/powerpc/papr_hcalls.rst index fce8bc793660..80d2c0aadab5 100644 --- a/Documentation/powerpc/papr_hcalls.rst +++ b/Documentation/powerpc/papr_hcalls.rst @@ -22,7 +22,7 @@ privileged operations. Currently there are two PAPR compliant hypervisors: On PPC64 arch a guest kernel running on top of a PAPR hypervisor is called a *pSeries guest*. A pseries guest runs in a supervisor mode (HV=0) and must issue hypercalls to the hypervisor whenever it needs to perform an action -that is hypervisor priviledged [3]_ or for other services managed by the +that is hypervisor privileged [3]_ or for other services managed by the hypervisor. Hence a Hypercall (hcall) is essentially a request by the pseries guest diff --git a/Documentation/powerpc/ptrace.rst b/Documentation/powerpc/ptrace.rst index 77725d69eb4a..5629edf4d56e 100644 --- a/Documentation/powerpc/ptrace.rst +++ b/Documentation/powerpc/ptrace.rst @@ -15,7 +15,7 @@ that's extendable and that covers both BookE and server processors, so that GDB doesn't need to special-case each of them. We added the following 3 new ptrace requests. -1. PTRACE_PPC_GETHWDEBUGINFO +1. PPC_PTRACE_GETHWDBGINFO ============================ Query for GDB to discover the hardware debug features. The main info to @@ -48,7 +48,7 @@ features will have bits indicating whether there is support for:: #define PPC_DEBUG_FEATURE_DATA_BP_DAWR 0x10 #define PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 0x20 -2. PTRACE_SETHWDEBUG +2. PPC_PTRACE_SETHWDEBUG Sets a hardware breakpoint or watchpoint, according to the provided structure:: @@ -88,7 +88,7 @@ that the BookE supports. COMEFROM breakpoints available in server processors are not contemplated, but that is out of the scope of this work. ptrace will return an integer (handle) uniquely identifying the breakpoint or -watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG +watchpoint just created. This integer will be used in the PPC_PTRACE_DELHWDEBUG request to ask for its removal. Return -ENOSPC if the requested breakpoint can't be allocated on the registers. @@ -150,7 +150,7 @@ Some examples of using the structure to: p.addr2 = (uint64_t) end_range; p.condition_value = 0; -3. PTRACE_DELHWDEBUG +3. PPC_PTRACE_DELHWDEBUG Takes an integer which identifies an existing breakpoint or watchpoint (i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the diff --git a/Documentation/powerpc/qe_firmware.rst b/Documentation/powerpc/qe_firmware.rst index 42f5103140c9..a358f152b7e7 100644 --- a/Documentation/powerpc/qe_firmware.rst +++ b/Documentation/powerpc/qe_firmware.rst @@ -232,11 +232,11 @@ For example, to match the 8323, revision 1.0:: 'extended_modes' is a bitfield that defines special functionality which has an impact on the device drivers. Each bit has its own impact and has special instructions for the driver associated with it. This field is stored in -the QE library and available to any driver that calles qe_get_firmware_info(). +the QE library and available to any driver that calls qe_get_firmware_info(). 'vtraps' is an array of 8 words that contain virtual trap values for each virtual traps. As with 'extended_modes', this field is stored in the QE -library and available to any driver that calles qe_get_firmware_info(). +library and available to any driver that calls qe_get_firmware_info(). 'microcode' (type: struct qe_microcode): For each RISC processor there is one 'microcode' structure. The first diff --git a/Documentation/powerpc/vas-api.rst b/Documentation/powerpc/vas-api.rst index bdb50fed903e..a9625a2fa0c6 100644 --- a/Documentation/powerpc/vas-api.rst +++ b/Documentation/powerpc/vas-api.rst @@ -46,7 +46,7 @@ request queue into the application's virtual address space. The application can then submit one or more requests to the engine by using copy/paste instructions and pasting the CRBs to the virtual address (aka paste_address) returned by mmap(). User space can close the -established connection or send window by closing the file descriptior +established connection or send window by closing the file descriptor (close(fd)) or upon the process exit. Note that applications can send several requests with the same window or @@ -240,7 +240,7 @@ issued. This signal returns with the following siginfo struct:: siginfo.si_signo = SIGSEGV; siginfo.si_errno = EFAULT; siginfo.si_code = SEGV_MAPERR; - siginfo.si_addr = CSB adress; + siginfo.si_addr = CSB address; In the case of multi-thread applications, NX send windows can be shared across all threads. For example, a child thread can open a send window, diff --git a/Documentation/powerpc/vmemmap_dedup.rst b/Documentation/powerpc/vmemmap_dedup.rst new file mode 100644 index 000000000000..dc4db59fdf87 --- /dev/null +++ b/Documentation/powerpc/vmemmap_dedup.rst @@ -0,0 +1,101 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========== +Device DAX +========== + +The device-dax interface uses the tail deduplication technique explained in +Documentation/mm/vmemmap_dedup.rst + +On powerpc, vmemmap deduplication is only used with radix MMU translation. Also +with a 64K page size, only the devdax namespace with 1G alignment uses vmemmap +deduplication. + +With 2M PMD level mapping, we require 32 struct pages and a single 64K vmemmap +page can contain 1024 struct pages (64K/sizeof(struct page)). Hence there is no +vmemmap deduplication possible. + +With 1G PUD level mapping, we require 16384 struct pages and a single 64K +vmemmap page can contain 1024 struct pages (64K/sizeof(struct page)). Hence we +require 16 64K pages in vmemmap to map the struct page for 1G PUD level mapping. + +Here's how things look like on device-dax after the sections are populated:: + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | -------------> | 1 | + | | +-----------+ +-----------+ + | | | 2 | ----------------^ ^ ^ ^ ^ ^ + | | +-----------+ | | | | | + | | | 3 | ------------------+ | | | | + | | +-----------+ | | | | + | | | 4 | --------------------+ | | | + | PUD | +-----------+ | | | + | level | | . | ----------------------+ | | + | mapping | +-----------+ | | + | | | . | ------------------------+ | + | | +-----------+ | + | | | 15 | --------------------------+ + | | +-----------+ + | | + | | + | | + +-----------+ + + +With 4K page size, 2M PMD level mapping requires 512 struct pages and a single +4K vmemmap page contains 64 struct pages(4K/sizeof(struct page)). Hence we +require 8 4K pages in vmemmap to map the struct page for 2M pmd level mapping. + +Here's how things look like on device-dax after the sections are populated:: + + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | -------------> | 1 | + | | +-----------+ +-----------+ + | | | 2 | ----------------^ ^ ^ ^ ^ ^ + | | +-----------+ | | | | | + | | | 3 | ------------------+ | | | | + | | +-----------+ | | | | + | | | 4 | --------------------+ | | | + | PMD | +-----------+ | | | + | level | | 5 | ----------------------+ | | + | mapping | +-----------+ | | + | | | 6 | ------------------------+ | + | | +-----------+ | + | | | 7 | --------------------------+ + | | +-----------+ + | | + | | + | | + +-----------+ + +With 1G PUD level mapping, we require 262144 struct pages and a single 4K +vmemmap page can contain 64 struct pages (4K/sizeof(struct page)). Hence we +require 4096 4K pages in vmemmap to map the struct pages for 1G PUD level +mapping. + +Here's how things look like on device-dax after the sections are populated:: + + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | -------------> | 1 | + | | +-----------+ +-----------+ + | | | 2 | ----------------^ ^ ^ ^ ^ ^ + | | +-----------+ | | | | | + | | | 3 | ------------------+ | | | | + | | +-----------+ | | | | + | | | 4 | --------------------+ | | | + | PUD | +-----------+ | | | + | level | | . | ----------------------+ | | + | mapping | +-----------+ | | + | | | . | ------------------------+ | + | | +-----------+ | + | | | 4095 | --------------------------+ + | | +-----------+ + | | + | | + | | + +-----------+ diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst index 6a919cffcbfd..613a01da4717 100644 --- a/Documentation/process/2.Process.rst +++ b/Documentation/process/2.Process.rst @@ -434,9 +434,10 @@ There are a few hints which can help with linux-kernel survival: questions. Some developers can get impatient with people who clearly have not done their homework. -- Avoid top-posting (the practice of putting your answer above the quoted - text you are responding to). It makes your response harder to read and - makes a poor impression. +- Use interleaved ("inline") replies, which makes your response easier to + read. (i.e. avoid top-posting -- the practice of putting your answer above + the quoted text you are responding to.) For more details, see + :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>`. - Ask on the correct mailing list. Linux-kernel may be the general meeting point, but it is not the best place to find developers from all diff --git a/Documentation/process/6.Followthrough.rst b/Documentation/process/6.Followthrough.rst index a173cd5f93d2..66fa400c6d94 100644 --- a/Documentation/process/6.Followthrough.rst +++ b/Documentation/process/6.Followthrough.rst @@ -51,6 +51,13 @@ mind: working toward the creation of the best kernel they can; they are not trying to create discomfort for their employers' competitors. + - Be prepared for seemingly silly requests for coding style changes + and requests to factor out some of your code to shared parts of + the kernel. One job the maintainers do is to keep things looking + the same. Sometimes this means that the clever hack in your driver + to get around a problem actually needs to become a generalized + kernel feature ready for next time. + What all of this comes down to is that, when reviewers send you comments, you need to pay attention to the technical observations that they are making. Do not let their form of expression or your own pride keep that diff --git a/Documentation/process/botching-up-ioctls.rst b/Documentation/process/botching-up-ioctls.rst index 9739b88463a5..a05e8401de1c 100644 --- a/Documentation/process/botching-up-ioctls.rst +++ b/Documentation/process/botching-up-ioctls.rst @@ -208,7 +208,7 @@ Not every problem needs a new ioctl: it's much quicker to push a driver-private interface than engaging in lengthy discussions for a more generic solution. And occasionally doing a private interface to spearhead a new concept is what's required. But in the - end, once the generic interface comes around you'll end up maintainer two + end, once the generic interface comes around you'll end up maintaining two interfaces. Indefinitely. * Consider other interfaces than ioctls. A sysfs attribute is much better for diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index ef540865ad22..b48da698d6f2 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -31,8 +31,8 @@ you probably needn't concern yourself with pcmciautils. ====================== =============== ======================================== GNU C 5.1 gcc --version Clang/LLVM (optional) 11.0.0 clang --version -Rust (optional) 1.62.0 rustc --version -bindgen (optional) 0.56.0 bindgen --version +Rust (optional) 1.71.1 rustc --version +bindgen (optional) 0.65.1 bindgen --version GNU make 3.82 make --version bash 4.2 bash --version binutils 2.25 ld -v @@ -60,6 +60,8 @@ openssl & libcrypto 1.0.0 openssl version bc 1.06.95 bc --version Sphinx\ [#f1]_ 1.7 sphinx-build --version cpio any cpio --version +GNU tar 1.28 tar --version +gtags (optional) 6.6.5 gtags --version ====================== =============== ======================================== .. [#f1] Sphinx is needed only to build the Kernel documentation @@ -174,6 +176,18 @@ You will need openssl to build kernels 3.7 and higher if module signing is enabled. You will also need openssl development packages to build kernels 4.3 and higher. +Tar +--- + +GNU tar is needed if you want to enable access to the kernel headers via sysfs +(CONFIG_IKHEADERS). + +gtags / GNU GLOBAL (optional) +----------------------------- + +The kernel build requires GNU GLOBAL version 6.6.5 or later to generate +tag files through ``make gtags``. This is due to its use of the gtags +``-C (--directory)`` flag. System utilities **************** @@ -468,7 +482,7 @@ E2fsprogs JFSutils -------- -- <http://jfs.sourceforge.net/> +- <https://jfs.sourceforge.net/> Reiserfsprogs ------------- @@ -489,7 +503,7 @@ Pcmciautils Quota-tools ----------- -- <http://sourceforge.net/projects/linuxquota/> +- <https://sourceforge.net/projects/linuxquota/> Intel P6 microcode @@ -510,7 +524,7 @@ FUSE mcelog ------ -- <http://www.mcelog.org/> +- <https://www.mcelog.org/> cpio ---- @@ -530,7 +544,8 @@ PPP NFS-utils --------- -- <http://sourceforge.net/project/showfiles.php?group_id=14> +- <https://sourceforge.net/project/showfiles.php?group_id=14> +- <https://nfs.sourceforge.net/> Iptables -------- @@ -545,12 +560,7 @@ Ip-route2 OProfile -------- -- <http://oprofile.sf.net/download/> - -NFS-Utils ---------- - -- <http://nfs.sourceforge.net/> +- <https://oprofile.sf.net/download/> Kernel documentation ******************** diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst index f91b8441f2ef..1f7f3e6c9cda 100644 --- a/Documentation/process/deprecated.rst +++ b/Documentation/process/deprecated.rst @@ -77,7 +77,7 @@ kzalloc() can be replaced with kcalloc(). If no 2-factor form is available, the saturate-on-overflow helpers should be used:: - bar = vmalloc(array_size(count, size)); + bar = dma_alloc_coherent(dev, array_size(count, size), &dma, GFP_KERNEL); Another common case to avoid is calculating the size of a structure with a trailing array of others structures, as in:: diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst index df978127f2d7..cb686238f21d 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -254,7 +254,6 @@ an involved disclosed party. The current ambassadors list: Samsung Javier González <javier.gonz@samsung.com> Microsoft James Morris <jamorris@linux.microsoft.com> - VMware Xen Andrew Cooper <andrew.cooper3@citrix.com> Canonical John Johansen <john.johansen@canonical.com> @@ -263,10 +262,8 @@ an involved disclosed party. The current ambassadors list: Red Hat Josh Poimboeuf <jpoimboe@redhat.com> SUSE Jiri Kosina <jkosina@suse.cz> - Amazon Google Kees Cook <keescook@chromium.org> - GCC LLVM Nick Desaulniers <ndesaulniers@google.com> ============= ======================================================== diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst index abb741b1aeee..5d3c3de3f4ec 100644 --- a/Documentation/process/handling-regressions.rst +++ b/Documentation/process/handling-regressions.rst @@ -129,88 +129,132 @@ tools and scripts used by other kernel developers or Linux distributions; one of these tools is regzbot, which heavily relies on the "Link:" tags to associate reports for regression with changes resolving them. -Prioritize work on fixing regressions -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You should fix any reported regression as quickly as possible, to provide -affected users with a solution in a timely manner and prevent more users from -running into the issue; nevertheless developers need to take enough time and -care to ensure regression fixes do not cause additional damage. - -In the end though, developers should give their best to prevent users from -running into situations where a regression leaves them only three options: "run -a kernel with a regression that seriously impacts usage", "continue running an -outdated and thus potentially insecure kernel version for more than two weeks -after a regression's culprit was identified", and "downgrade to a still -supported kernel series that lack required features". - -How to realize this depends a lot on the situation. Here are a few rules of -thumb for you, in order or importance: - - * Prioritize work on handling regression reports and fixing regression over all - other Linux kernel work, unless the latter concerns acute security issues or - bugs causing data loss or damage. - - * Always consider reverting the culprit commits and reapplying them later - together with necessary fixes, as this might be the least dangerous and - quickest way to fix a regression. - - * Developers should handle regressions in all supported kernel series, but are - free to delegate the work to the stable team, if the issue probably at no - point in time occurred with mainline. - - * Try to resolve any regressions introduced in the current development before - its end. If you fear a fix might be too risky to apply only days before a new - mainline release, let Linus decide: submit the fix separately to him as soon - as possible with the explanation of the situation. He then can make a call - and postpone the release if necessary, for example if multiple such changes - show up in his inbox. - - * Address regressions in stable, longterm, or proper mainline releases with - more urgency than regressions in mainline pre-releases. That changes after - the release of the fifth pre-release, aka "-rc5": mainline then becomes as - important, to ensure all the improvements and fixes are ideally tested - together for at least one week before Linus releases a new mainline version. - - * Fix regressions within two or three days, if they are critical for some - reason -- for example, if the issue is likely to affect many users of the - kernel series in question on all or certain architectures. Note, this - includes mainline, as issues like compile errors otherwise might prevent many - testers or continuous integration systems from testing the series. - - * Aim to fix regressions within one week after the culprit was identified, if - the issue was introduced in either: - - * a recent stable/longterm release - - * the development cycle of the latest proper mainline release - - In the latter case (say Linux v5.14), try to address regressions even - quicker, if the stable series for the predecessor (v5.13) will be abandoned - soon or already was stamped "End-of-Life" (EOL) -- this usually happens about - three to four weeks after a new mainline release. - - * Try to fix all other regressions within two weeks after the culprit was - found. Two or three additional weeks are acceptable for performance - regressions and other issues which are annoying, but don't prevent anyone - from running Linux (unless it's an issue in the current development cycle, - as those should ideally be addressed before the release). A few weeks in - total are acceptable if a regression can only be fixed with a risky change - and at the same time is affecting only a few users; as much time is - also okay if the regression is already present in the second newest longterm - kernel series. - -Note: The aforementioned time frames for resolving regressions are meant to -include getting the fix tested, reviewed, and merged into mainline, ideally with -the fix being in linux-next at least briefly. This leads to delays you need to -account for. - -Subsystem maintainers are expected to assist in reaching those periods by doing -timely reviews and quick handling of accepted patches. They thus might have to -send git-pull requests earlier or more often than usual; depending on the fix, -it might even be acceptable to skip testing in linux-next. Especially fixes for -regressions in stable and longterm kernels need to be handled quickly, as fixes -need to be merged in mainline before they can be backported to older series. +Expectations and best practices for fixing regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As a Linux kernel developer, you are expected to give your best to prevent +situations where a regression caused by a recent change of yours leaves users +only these options: + + * Run a kernel with a regression that impacts usage. + + * Switch to an older or newer kernel series. + + * Continue running an outdated and thus potentially insecure kernel for more + than three weeks after the regression's culprit was identified. Ideally it + should be less than two. And it ought to be just a few days, if the issue is + severe or affects many users -- either in general or in prevalent + environments. + +How to realize that in practice depends on various factors. Use the following +rules of thumb as a guide. + +In general: + + * Prioritize work on regressions over all other Linux kernel work, unless the + latter concerns a severe issue (e.g. acute security vulnerability, data loss, + bricked hardware, ...). + + * Expedite fixing mainline regressions that recently made it into a proper + mainline, stable, or longterm release (either directly or via backport). + + * Do not consider regressions from the current cycle as something that can wait + till the end of the cycle, as the issue might discourage or prevent users and + CI systems from testing mainline now or generally. + + * Work with the required care to avoid additional or bigger damage, even if + resolving an issue then might take longer than outlined below. + +On timing once the culprit of a regression is known: + + * Aim to mainline a fix within two or three days, if the issue is severe or + bothering many users -- either in general or in prevalent conditions like a + particular hardware environment, distribution, or stable/longterm series. + + * Aim to mainline a fix by Sunday after the next, if the culprit made it + into a recent mainline, stable, or longterm release (either directly or via + backport); if the culprit became known early during a week and is simple to + resolve, try to mainline the fix within the same week. + + * For other regressions, aim to mainline fixes before the hindmost Sunday + within the next three weeks. One or two Sundays later are acceptable, if the + regression is something people can live with easily for a while -- like a + mild performance regression. + + * It's strongly discouraged to delay mainlining regression fixes till the next + merge window, except when the fix is extraordinarily risky or when the + culprit was mainlined more than a year ago. + +On procedure: + + * Always consider reverting the culprit, as it's often the quickest and least + dangerous way to fix a regression. Don't worry about mainlining a fixed + variant later: that should be straight-forward, as most of the code went + through review once already. + + * Try to resolve any regressions introduced in mainline during the past + twelve months before the current development cycle ends: Linus wants such + regressions to be handled like those from the current cycle, unless fixing + bears unusual risks. + + * Consider CCing Linus on discussions or patch review, if a regression seems + tangly. Do the same in precarious or urgent cases -- especially if the + subsystem maintainer might be unavailable. Also CC the stable team, when you + know such a regression made it into a mainline, stable, or longterm release. + + * For urgent regressions, consider asking Linus to pick up the fix straight + from the mailing list: he is totally fine with that for uncontroversial + fixes. Ideally though such requests should happen in accordance with the + subsystem maintainers or come directly from them. + + * In case you are unsure if a fix is worth the risk applying just days before + a new mainline release, send Linus a mail with the usual lists and people in + CC; in it, summarize the situation while asking him to consider picking up + the fix straight from the list. He then himself can make the call and when + needed even postpone the release. Such requests again should ideally happen + in accordance with the subsystem maintainers or come directly from them. + +Regarding stable and longterm kernels: + + * You are free to leave regressions to the stable team, if they at no point in + time occurred with mainline or were fixed there already. + + * If a regression made it into a proper mainline release during the past + twelve months, ensure to tag the fix with "Cc: stable@vger.kernel.org", as a + "Fixes:" tag alone does not guarantee a backport. Please add the same tag, + in case you know the culprit was backported to stable or longterm kernels. + + * When receiving reports about regressions in recent stable or longterm kernel + series, please evaluate at least briefly if the issue might happen in current + mainline as well -- and if that seems likely, take hold of the report. If in + doubt, ask the reporter to check mainline. + + * Whenever you want to swiftly resolve a regression that recently also made it + into a proper mainline, stable, or longterm release, fix it quickly in + mainline; when appropriate thus involve Linus to fast-track the fix (see + above). That's because the stable team normally does neither revert nor fix + any changes that cause the same problems in mainline. + + * In case of urgent regression fixes you might want to ensure prompt + backporting by dropping the stable team a note once the fix was mainlined; + this is especially advisable during merge windows and shortly thereafter, as + the fix otherwise might land at the end of a huge patch queue. + +On patch flow: + + * Developers, when trying to reach the time periods mentioned above, remember + to account for the time it takes to get fixes tested, reviewed, and merged by + Linus, ideally with them being in linux-next at least briefly. Hence, if a + fix is urgent, make it obvious to ensure others handle it appropriately. + + * Reviewers, you are kindly asked to assist developers in reaching the time + periods mentioned above by reviewing regression fixes in a timely manner. + + * Subsystem maintainers, you likewise are encouraged to expedite the handling + of regression fixes. Thus evaluate if skipping linux-next is an option for + the particular fix. Also consider sending git pull requests more often than + usual when needed. And try to avoid holding onto regression fixes over + weekends -- especially when the fix is marked for backporting. More aspects regarding regressions developers should be aware of diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst index 46f927aae6eb..8660493b91d0 100644 --- a/Documentation/process/kernel-docs.rst +++ b/Documentation/process/kernel-docs.rst @@ -29,7 +29,7 @@ All documents are cataloged with the following fields: the document's The documents on each section of this document are ordered by its published date, from the newest to the oldest. The maintainer(s) should - periodically retire resources as they become obsolte or outdated; with + periodically retire resources as they become obsolete or outdated; with the exception of foundational books. Docs at the Linux Kernel tree @@ -118,6 +118,15 @@ Published books :ISBN: 978-0672329463 :Notes: Foundational book + * Title: **Practical Linux System Administration: A Guide to Installation, Configuration, and Management, 1st Edition** + + :Author: Kenneth Hess + :Publisher: O'Reilly Media + :Date: May, 2023 + :Pages: 246 + :ISBN: 978-1098109035 + :Notes: System administration + .. _ldd3_published: * Title: **Linux Device Drivers, 3rd Edition** diff --git a/Documentation/process/maintainer-handbooks.rst b/Documentation/process/maintainer-handbooks.rst index d783060b4cc6..976391cec528 100644 --- a/Documentation/process/maintainer-handbooks.rst +++ b/Documentation/process/maintainer-handbooks.rst @@ -15,5 +15,8 @@ Contents: :numbered: :maxdepth: 2 - maintainer-tip maintainer-netdev + maintainer-soc + maintainer-soc-clean-dts + maintainer-tip + maintainer-kvm-x86 diff --git a/Documentation/process/maintainer-kvm-x86.rst b/Documentation/process/maintainer-kvm-x86.rst new file mode 100644 index 000000000000..9183bd449762 --- /dev/null +++ b/Documentation/process/maintainer-kvm-x86.rst @@ -0,0 +1,390 @@ +.. SPDX-License-Identifier: GPL-2.0 + +KVM x86 +======= + +Foreword +-------- +KVM strives to be a welcoming community; contributions from newcomers are +valued and encouraged. Please do not be discouraged or intimidated by the +length of this document and the many rules/guidelines it contains. Everyone +makes mistakes, and everyone was a newbie at some point. So long as you make +an honest effort to follow KVM x86's guidelines, are receptive to feedback, +and learn from any mistakes you make, you will be welcomed with open arms, not +torches and pitchforks. + +TL;DR +----- +Testing is mandatory. Be consistent with established styles and patterns. + +Trees +----- +KVM x86 is currently in a transition period from being part of the main KVM +tree, to being "just another KVM arch". As such, KVM x86 is split across the +main KVM tree, ``git.kernel.org/pub/scm/virt/kvm/kvm.git``, and a KVM x86 +specific tree, ``github.com/kvm-x86/linux.git``. + +Generally speaking, fixes for the current cycle are applied directly to the +main KVM tree, while all development for the next cycle is routed through the +KVM x86 tree. In the unlikely event that a fix for the current cycle is routed +through the KVM x86 tree, it will be applied to the ``fixes`` branch before +making its way to the main KVM tree. + +Note, this transition period is expected to last quite some time, i.e. will be +the status quo for the foreseeable future. + +Branches +~~~~~~~~ +The KVM x86 tree is organized into multiple topic branches. The purpose of +using finer-grained topic branches is to make it easier to keep tabs on an area +of development, and to limit the collateral damage of human errors and/or buggy +commits, e.g. dropping the HEAD commit of a topic branch has no impact on other +in-flight commits' SHA1 hashes, and having to reject a pull request due to bugs +delays only that topic branch. + +All topic branches, except for ``next`` and ``fixes``, are rolled into ``next`` +via a Cthulhu merge on an as-needed basis, i.e. when a topic branch is updated. +As a result, force pushes to ``next`` are common. + +Lifecycle +~~~~~~~~~ +Fixes that target the current release, a.k.a. mainline, are typically applied +directly to the main KVM tree, i.e. do not route through the KVM x86 tree. + +Changes that target the next release are routed through the KVM x86 tree. Pull +requests (from KVM x86 to main KVM) are sent for each KVM x86 topic branch, +typically the week before Linus' opening of the merge window, e.g. the week +following rc7 for "normal" releases. If all goes well, the topic branches are +rolled into the main KVM pull request sent during Linus' merge window. + +The KVM x86 tree doesn't have its own official merge window, but there's a soft +close around rc5 for new features, and a soft close around rc6 for fixes (for +the next release; see above for fixes that target the current release). + +Timeline +~~~~~~~~ +Submissions are typically reviewed and applied in FIFO order, with some wiggle +room for the size of a series, patches that are "cache hot", etc. Fixes, +especially for the current release and or stable trees, get to jump the queue. +Patches that will be taken through a non-KVM tree (most often through the tip +tree) and/or have other acks/reviews also jump the queue to some extent. + +Note, the vast majority of review is done between rc1 and rc6, give or take. +The period between rc6 and the next rc1 is used to catch up on other tasks, +i.e. radio silence during this period isn't unusual. + +Pings to get a status update are welcome, but keep in mind the timing of the +current release cycle and have realistic expectations. If you are pinging for +acceptance, i.e. not just for feedback or an update, please do everything you +can, within reason, to ensure that your patches are ready to be merged! Pings +on series that break the build or fail tests lead to unhappy maintainers! + +Development +----------- + +Base Tree/Branch +~~~~~~~~~~~~~~~~ +Fixes that target the current release, a.k.a. mainline, should be based on +``git://git.kernel.org/pub/scm/virt/kvm/kvm.git master``. Note, fixes do not +automatically warrant inclusion in the current release. There is no singular +rule, but typically only fixes for bugs that are urgent, critical, and/or were +introduced in the current release should target the current release. + +Everything else should be based on ``kvm-x86/next``, i.e. there is no need to +select a specific topic branch as the base. If there are conflicts and/or +dependencies across topic branches, it is the maintainer's job to sort them +out. + +The only exception to using ``kvm-x86/next`` as the base is if a patch/series +is a multi-arch series, i.e. has non-trivial modifications to common KVM code +and/or has more than superficial changes to other architectures' code. Multi- +arch patch/series should instead be based on a common, stable point in KVM's +history, e.g. the release candidate upon which ``kvm-x86 next`` is based. If +you're unsure whether a patch/series is truly multi-arch, err on the side of +caution and treat it as multi-arch, i.e. use a common base. + +Coding Style +~~~~~~~~~~~~ +When it comes to style, naming, patterns, etc., consistency is the number one +priority in KVM x86. If all else fails, match what already exists. + +With a few caveats listed below, follow the tip tree maintainers' preferred +:ref:`maintainer-tip-coding-style`, as patches/series often touch both KVM and +non-KVM x86 files, i.e. draw the attention of KVM *and* tip tree maintainers. + +Using reverse fir tree, a.k.a. reverse Christmas tree or reverse XMAS tree, for +variable declarations isn't strictly required, though it is still preferred. + +Except for a handful of special snowflakes, do not use kernel-doc comments for +functions. The vast majority of "public" KVM functions aren't truly public as +they are intended only for KVM-internal consumption (there are plans to +privatize KVM's headers and exports to enforce this). + +Comments +~~~~~~~~ +Write comments using imperative mood and avoid pronouns. Use comments to +provide a high level overview of the code, and/or to explain why the code does +what it does. Do not reiterate what the code literally does; let the code +speak for itself. If the code itself is inscrutable, comments will not help. + +SDM and APM References +~~~~~~~~~~~~~~~~~~~~~~ +Much of KVM's code base is directly tied to architectural behavior defined in +Intel's Software Development Manual (SDM) and AMD's Architecture Programmer’s +Manual (APM). Use of "Intel's SDM" and "AMD's APM", or even just "SDM" or +"APM", without additional context is a-ok. + +Do not reference specific sections, tables, figures, etc. by number, especially +not in comments. Instead, if necessary (see below), copy-paste the relevant +snippet and reference sections/tables/figures by name. The layouts of the SDM +and APM are constantly changing, and so the numbers/labels aren't stable. + +Generally speaking, do not explicitly reference or copy-paste from the SDM or +APM in comments. With few exceptions, KVM *must* honor architectural behavior, +therefore it's implied that KVM behavior is emulating SDM and/or APM behavior. +Note, referencing the SDM/APM in changelogs to justify the change and provide +context is perfectly ok and encouraged. + +Shortlog +~~~~~~~~ +The preferred prefix format is ``KVM: <topic>:``, where ``<topic>`` is one of:: + + - x86 + - x86/mmu + - x86/pmu + - x86/xen + - selftests + - SVM + - nSVM + - VMX + - nVMX + +**DO NOT use x86/kvm!** ``x86/kvm`` is used exclusively for Linux-as-a-KVM-guest +changes, i.e. for arch/x86/kernel/kvm.c. Do not use file names or complete file +paths as the subject/shortlog prefix. + +Note, these don't align with the topics branches (the topic branches care much +more about code conflicts). + +All names are case sensitive! ``KVM: x86:`` is good, ``kvm: vmx:`` is not. + +Capitalize the first word of the condensed patch description, but omit ending +punctionation. E.g.:: + + KVM: x86: Fix a null pointer dereference in function_xyz() + +not:: + + kvm: x86: fix a null pointer dereference in function_xyz. + +If a patch touches multiple topics, traverse up the conceptual tree to find the +first common parent (which is often simply ``x86``). When in doubt, +``git log path/to/file`` should provide a reasonable hint. + +New topics do occasionally pop up, but please start an on-list discussion if +you want to propose introducing a new topic, i.e. don't go rogue. + +See :ref:`the_canonical_patch_format` for more information, with one amendment: +do not treat the 70-75 character limit as an absolute, hard limit. Instead, +use 75 characters as a firm-but-not-hard limit, and use 80 characters as a hard +limit. I.e. let the shortlog run a few characters over the standard limit if +you have good reason to do so. + +Changelog +~~~~~~~~~ +Most importantly, write changelogs using imperative mood and avoid pronouns. + +See :ref:`describe_changes` for more information, with one amendment: lead with +a short blurb on the actual changes, and then follow up with the context and +background. Note! This order directly conflicts with the tip tree's preferred +approach! Please follow the tip tree's preferred style when sending patches +that primarily target arch/x86 code that is _NOT_ KVM code. + +Stating what a patch does before diving into details is preferred by KVM x86 +for several reasons. First and foremost, what code is actually being changed +is arguably the most important information, and so that info should be easy to +find. Changelogs that bury the "what's actually changing" in a one-liner after +3+ paragraphs of background make it very hard to find that information. + +For initial review, one could argue the "what's broken" is more important, but +for skimming logs and git archaeology, the gory details matter less and less. +E.g. when doing a series of "git blame", the details of each change along the +way are useless, the details only matter for the culprit. Providing the "what +changed" makes it easy to quickly determine whether or not a commit might be of +interest. + +Another benefit of stating "what's changing" first is that it's almost always +possible to state "what's changing" in a single sentence. Conversely, all but +the most simple bugs require multiple sentences or paragraphs to fully describe +the problem. If both the "what's changing" and "what's the bug" are super +short then the order doesn't matter. But if one is shorter (almost always the +"what's changing), then covering the shorter one first is advantageous because +it's less of an inconvenience for readers/reviewers that have a strict ordering +preference. E.g. having to skip one sentence to get to the context is less +painful than having to skip three paragraphs to get to "what's changing". + +Fixes +~~~~~ +If a change fixes a KVM/kernel bug, add a Fixes: tag even if the change doesn't +need to be backported to stable kernels, and even if the change fixes a bug in +an older release. + +Conversely, if a fix does need to be backported, explicitly tag the patch with +"Cc: stable@vger.kernel" (though the email itself doesn't need to Cc: stable); +KVM x86 opts out of backporting Fixes: by default. Some auto-selected patches +do get backported, but require explicit maintainer approval (search MANUALSEL). + +Function References +~~~~~~~~~~~~~~~~~~~ +When a function is mentioned in a comment, changelog, or shortlog (or anywhere +for that matter), use the format ``function_name()``. The parentheses provide +context and disambiguate the reference. + +Testing +------- +At a bare minimum, *all* patches in a series must build cleanly for KVM_INTEL=m +KVM_AMD=m, and KVM_WERROR=y. Building every possible combination of Kconfigs +isn't feasible, but the more the merrier. KVM_SMM, KVM_XEN, PROVE_LOCKING, and +X86_64 are particularly interesting knobs to turn. + +Running KVM selftests and KVM-unit-tests is also mandatory (and stating the +obvious, the tests need to pass). The only exception is for changes that have +negligible probability of affecting runtime behavior, e.g. patches that only +modify comments. When possible and relevant, testing on both Intel and AMD is +strongly preferred. Booting an actual VM is encouraged, but not mandatory. + +For changes that touch KVM's shadow paging code, running with TDP (EPT/NPT) +disabled is mandatory. For changes that affect common KVM MMU code, running +with TDP disabled is strongly encouraged. For all other changes, if the code +being modified depends on and/or interacts with a module param, testing with +the relevant settings is mandatory. + +Note, KVM selftests and KVM-unit-tests do have known failures. If you suspect +a failure is not due to your changes, verify that the *exact same* failure +occurs with and without your changes. + +Changes that touch reStructured Text documentation, i.e. .rst files, must build +htmldocs cleanly, i.e. with no new warnings or errors. + +If you can't fully test a change, e.g. due to lack of hardware, clearly state +what level of testing you were able to do, e.g. in the cover letter. + +New Features +~~~~~~~~~~~~ +With one exception, new features *must* come with test coverage. KVM specific +tests aren't strictly required, e.g. if coverage is provided by running a +sufficiently enabled guest VM, or by running a related kernel selftest in a VM, +but dedicated KVM tests are preferred in all cases. Negative testcases in +particular are mandatory for enabling of new hardware features as error and +exception flows are rarely exercised simply by running a VM. + +The only exception to this rule is if KVM is simply advertising support for a +feature via KVM_GET_SUPPORTED_CPUID, i.e. for instructions/features that KVM +can't prevent a guest from using and for which there is no true enabling. + +Note, "new features" does not just mean "new hardware features"! New features +that can't be well validated using existing KVM selftests and/or KVM-unit-tests +must come with tests. + +Posting new feature development without tests to get early feedback is more +than welcome, but such submissions should be tagged RFC, and the cover letter +should clearly state what type of feedback is requested/expected. Do not abuse +the RFC process; RFCs will typically not receive in-depth review. + +Bug Fixes +~~~~~~~~~ +Except for "obvious" found-by-inspection bugs, fixes must be accompanied by a +reproducer for the bug being fixed. In many cases the reproducer is implicit, +e.g. for build errors and test failures, but it should still be clear to +readers what is broken and how to verify the fix. Some leeway is given for +bugs that are found via non-public workloads/tests, but providing regression +tests for such bugs is strongly preferred. + +In general, regression tests are preferred for any bug that is not trivial to +hit. E.g. even if the bug was originally found by a fuzzer such as syzkaller, +a targeted regression test may be warranted if the bug requires hitting a +one-in-a-million type race condition. + +Note, KVM bugs are rarely urgent *and* non-trivial to reproduce. Ask yourself +if a bug is really truly the end of the world before posting a fix without a +reproducer. + +Posting +------- + +Links +~~~~~ +Do not explicitly reference bug reports, prior versions of a patch/series, etc. +via ``In-Reply-To:`` headers. Using ``In-Reply-To:`` becomes an unholy mess +for large series and/or when the version count gets high, and ``In-Reply-To:`` +is useless for anyone that doesn't have the original message, e.g. if someone +wasn't Cc'd on the bug report or if the list of recipients changes between +versions. + +To link to a bug report, previous version, or anything of interest, use lore +links. For referencing previous version(s), generally speaking do not include +a Link: in the changelog as there is no need to record the history in git, i.e. +put the link in the cover letter or in the section git ignores. Do provide a +formal Link: for bug reports and/or discussions that led to the patch. The +context of why a change was made is highly valuable for future readers. + +Git Base +~~~~~~~~ +If you are using git version 2.9.0 or later (Googlers, this is all of you!), +use ``git format-patch`` with the ``--base`` flag to automatically include the +base tree information in the generated patches. + +Note, ``--base=auto`` works as expected if and only if a branch's upstream is +set to the base topic branch, e.g. it will do the wrong thing if your upstream +is set to your personal repository for backup purposes. An alternative "auto" +solution is to derive the names of your development branches based on their +KVM x86 topic, and feed that into ``--base``. E.g. ``x86/pmu/my_branch_name``, +and then write a small wrapper to extract ``pmu`` from the current branch name +to yield ``--base=x/pmu``, where ``x`` is whatever name your repository uses to +track the KVM x86 remote. + +Co-Posting Tests +~~~~~~~~~~~~~~~~ +KVM selftests that are associated with KVM changes, e.g. regression tests for +bug fixes, should be posted along with the KVM changes as a single series. The +standard kernel rules for bisection apply, i.e. KVM changes that result in test +failures should be ordered after the selftests updates, and vice versa, new +tests that fail due to KVM bugs should be ordered after the KVM fixes. + +KVM-unit-tests should *always* be posted separately. Tools, e.g. b4 am, don't +know that KVM-unit-tests is a separate repository and get confused when patches +in a series apply on different trees. To tie KVM-unit-tests patches back to +KVM patches, first post the KVM changes and then provide a lore Link: to the +KVM patch/series in the KVM-unit-tests patch(es). + +Notifications +------------- +When a patch/series is officially accepted, a notification email will be sent +in reply to the original posting (cover letter for multi-patch series). The +notification will include the tree and topic branch, along with the SHA1s of +the commits of applied patches. + +If a subset of patches is applied, this will be clearly stated in the +notification. Unless stated otherwise, it's implied that any patches in the +series that were not accepted need more work and should be submitted in a new +version. + +If for some reason a patch is dropped after officially being accepted, a reply +will be sent to the notification email explaining why the patch was dropped, as +well as the next steps. + +SHA1 Stability +~~~~~~~~~~~~~~ +SHA1s are not 100% guaranteed to be stable until they land in Linus' tree! A +SHA1 is *usually* stable once a notification has been sent, but things happen. +In most cases, an update to the notification email be provided if an applied +patch's SHA1 changes. However, in some scenarios, e.g. if all KVM x86 branches +need to be rebased, individual notifications will not be given. + +Vulnerabilities +--------------- +Bugs that can be exploited by the guest to attack the host (kernel or +userspace), or that can be exploited by a nested VM to *its* host (L2 attacking +L1), are of particular interest to KVM. Please follow the protocol for +:ref:`securitybugs` if you suspect a bug can lead to an escape, data leak, etc. + diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index 83614cec9328..c1c732e9748b 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -98,7 +98,7 @@ If you aren't subscribed to netdev and/or are simply unsure if repository link above for any new networking-related commits. You may also check the following website for the current status: - http://vger.kernel.org/~davem/net-next.html + https://patchwork.hopto.org/net-next.html The ``net`` tree continues to collect fixes for the vX.Y content, and is fed back to Linus at regular (~weekly) intervals. Meaning that the @@ -149,8 +149,11 @@ themselves. No email should ever be sent to the list with the main purpose of communicating with the bot, the bot commands should be seen as metadata. The use of the bot is restricted to authors of the patches (the ``From:`` -header on patch submission and command must match!), maintainers themselves -and a handful of senior reviewers. Bot records its activity here: +header on patch submission and command must match!), maintainers of +the modified code according to the MAINTAINERS file (again, ``From:`` +must match the MAINTAINERS entry) and a handful of senior reviewers. + +Bot records its activity here: https://patchwork.hopto.org/pw-bot.html @@ -164,6 +167,8 @@ Asking the maintainer for status updates on your patch is a good way to ensure your patch is ignored or pushed to the bottom of the priority list. +.. _Changes requested: + Changes requested ~~~~~~~~~~~~~~~~~ @@ -356,6 +361,10 @@ Make sure you address all the feedback in your new posting. Do not post a new version of the code if the discussion about the previous version is still ongoing, unless directly instructed by a reviewer. +The new version of patches should be posted as a separate thread, +not as a reply to the previous posting. Change log should include a link +to the previous posting (see :ref:`Changes requested`). + Testing ------- diff --git a/Documentation/process/maintainer-soc-clean-dts.rst b/Documentation/process/maintainer-soc-clean-dts.rst new file mode 100644 index 000000000000..1b32430d0cfc --- /dev/null +++ b/Documentation/process/maintainer-soc-clean-dts.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================== +SoC Platforms with DTS Compliance Requirements +============================================== + +Overview +-------- + +SoC platforms or subarchitectures should follow all the rules from +Documentation/process/maintainer-soc.rst. This document referenced in +MAINTAINERS impose additional requirements listed below. + +Strict DTS DT Schema and dtc Compliance +--------------------------------------- + +No changes to the SoC platform Devicetree sources (DTS files) should introduce +new ``make dtbs_check W=1`` warnings. Warnings in a new board DTS, which are +results of issues in an included DTSI file, are considered existing, not new +warnings. The platform maintainers have automation in place which should point +out any new warnings. + +If a commit introducing new warnings gets accepted somehow, the resulting +issues shall be fixed in reasonable time (e.g. within one release) or the +commit reverted. diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst new file mode 100644 index 000000000000..12637530d68f --- /dev/null +++ b/Documentation/process/maintainer-soc.rst @@ -0,0 +1,177 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +SoC Subsystem +============= + +Overview +-------- + +The SoC subsystem is a place of aggregation for SoC-specific code. +The main components of the subsystem are: + +* devicetrees for 32- & 64-bit ARM and RISC-V +* 32-bit ARM board files (arch/arm/mach*) +* 32- & 64-bit ARM defconfigs +* SoC-specific drivers across architectures, in particular for 32- & 64-bit + ARM, RISC-V and Loongarch + +These "SoC-specific drivers" do not include clock, GPIO etc drivers that have +other top-level maintainers. The drivers/soc/ directory is generally meant +for kernel-internal drivers that are used by other drivers to provide SoC- +specific functionality like identifying an SoC revision or interfacing with +power domains. + +The SoC subsystem also serves as an intermediate location for changes to +drivers/bus, drivers/firmware, drivers/reset and drivers/memory. The addition +of new platforms, or the removal of existing ones, often go through the SoC +tree as a dedicated branch covering multiple subsystems. + +The main SoC tree is housed on git.kernel.org: + https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/ + +Clearly this is quite a wide range of topics, which no one person, or even +small group of people are capable of maintaining. Instead, the SoC subsystem +is comprised of many submaintainers, each taking care of individual platforms +and driver subdirectories. +In this regard, "platform" usually refers to a series of SoCs from a given +vendor, for example, Nvidia's series of Tegra SoCs. Many submaintainers operate +on a vendor level, responsible for multiple product lines. For several reasons, +including acquisitions/different business units in a company, things vary +significantly here. The various submaintainers are documented in the +MAINTAINERS file. + +Most of these submaintainers have their own trees where they stage patches, +sending pull requests to the main SoC tree. These trees are usually, but not +always, listed in MAINTAINERS. The main SoC maintainers can be reached via the +alias soc@kernel.org if there is no platform-specific maintainer, or if they +are unresponsive. + +What the SoC tree is not, however, is a location for architecture-specific code +changes. Each architecture has its own maintainers that are responsible for +architectural details, CPU errata and the like. + +Information for (new) Submaintainers +------------------------------------ + +As new platforms spring up, they often bring with them new submaintainers, +many of whom work for the silicon vendor, and may not be familiar with the +process. + +Devicetree ABI Stability +~~~~~~~~~~~~~~~~~~~~~~~~ + +Perhaps one of the most important things to highlight is that dt-bindings +document the ABI between the devicetree and the kernel. +Please read Documentation/devicetree/bindings/ABI.rst. + +If changes are being made to a devicetree that are incompatible with old +kernels, the devicetree patch should not be applied until the driver is, or an +appropriate time later. Most importantly, any incompatible changes should be +clearly pointed out in the patch description and pull request, along with the +expected impact on existing users, such as bootloaders or other operating +systems. + +Driver Branch Dependencies +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A common problem is synchronizing changes between device drivers and devicetree +files. Even if a change is compatible in both directions, this may require +coordinating how the changes get merged through different maintainer trees. + +Usually the branch that includes a driver change will also include the +corresponding change to the devicetree binding description, to ensure they are +in fact compatible. This means that the devicetree branch can end up causing +warnings in the "make dtbs_check" step. If a devicetree change depends on +missing additions to a header file in include/dt-bindings/, it will fail the +"make dtbs" step and not get merged. + +There are multiple ways to deal with this: + +* Avoid defining custom macros in include/dt-bindings/ for hardware constants + that can be derived from a datasheet -- binding macros in header files should + only be used as a last resort if there is no natural way to define a binding + +* Use literal values in the devicetree file in place of macros even when a + header is required, and change them to the named representation in a + following release + +* Defer the devicetree changes to a release after the binding and driver have + already been merged + +* Change the bindings in a shared immutable branch that is used as the base for + both the driver change and the devicetree changes + +* Add duplicate defines in the devicetree file guarded by an #ifndef section, + removing them in a later release + +Devicetree Naming Convention +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The general naming scheme for devicetree files is as follows. The aspects of a +platform that are set at the SoC level, like CPU cores, are contained in a file +named $soc.dtsi, for example, jh7100.dtsi. Integration details, that will vary +from board to board, are described in $soc-$board.dts. An example of this is +jh7100-beaglev-starlight.dts. Often many boards are variations on a theme, and +frequently there are intermediate files, such as jh7100-common.dtsi, which sit +between the $soc.dtsi and $soc-$board.dts files, containing the descriptions of +common hardware. + +Some platforms also have System on Modules, containing an SoC, which are then +integrated into several different boards. For these platforms, $soc-$som.dtsi +and $soc-$som-$board.dts are typical. + +Directories are usually named after the vendor of the SoC at the time of its +inclusion, leading to some historical directory names in the tree. + +Validating Devicetree Files +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +``make dtbs_check`` can be used to validate that devicetree files are compliant +with the dt-bindings that describe the ABI. Please read the section +"Running checks" of Documentation/devicetree/bindings/writing-schema.rst for +more information on the validation of devicetrees. + +For new platforms, or additions to existing ones, ``make dtbs_check`` should not +add any new warnings. For RISC-V and Samsung SoC, ``make dtbs_check W=1`` is +required to not add any new warnings. +If in any doubt about a devicetree change, reach out to the devicetree +maintainers. + +Branches and Pull Requests +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Just as the main SoC tree has several branches, it is expected that +submaintainers will do the same. Driver, defconfig and devicetree changes should +all be split into separate branches and appear in separate pull requests to the +SoC maintainers. Each branch should be usable by itself and avoid +regressions that originate from dependencies on other branches. + +Small sets of patches can also be sent as separate emails to soc@kernel.org, +grouped into the same categories. + +If changes do not fit into the normal patterns, there can be additional +top-level branches, e.g. for a treewide rework, or the addition of new SoC +platforms including dts files and drivers. + +Branches with a lot of changes can benefit from getting split up into separate +topics branches, even if they end up getting merged into the same branch of the +SoC tree. An example here would be one branch for devicetree warning fixes, one +for a rework and one for newly added boards. + +Another common way to split up changes is to send an early pull request with the +majority of the changes at some point between rc1 and rc4, following up with one +or more smaller pull requests towards the end of the cycle that can add late +changes or address problems identified while testing the first set. + +While there is no cut-off time for late pull requests, it helps to only send +small branches as time gets closer to the merge window. + +Pull requests for bugfixes for the current release can be sent at any time, but +again having multiple smaller branches is better than trying to combine too many +patches into one pull request. + +The subject line of a pull request should begin with "[GIT PULL]" and made using +a signed tag, rather than a branch. This tag should contain a short description +summarising the changes in the pull request. For more detail on sending pull +requests, please see Documentation/maintainer/pull-requests.rst. diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst index 178c95fd17dc..08dd0f804410 100644 --- a/Documentation/process/maintainer-tip.rst +++ b/Documentation/process/maintainer-tip.rst @@ -421,6 +421,9 @@ allowing themselves a breath. Please respect that. The release candidate -rc1 is the starting point for new patches to be applied which are targeted for the next merge window. +So called _urgent_ branches will be merged into mainline during the +stabilization phase of each release. + Git ^^^ @@ -452,6 +455,8 @@ and can be added to an existing kernel config by running: Some of these options are x86-specific and can be left out when testing on other architectures. +.. _maintainer-tip-coding-style: + Coding style notes ------------------ diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst index 9fcfed3c350b..d159cd4f5e5b 100644 --- a/Documentation/process/researcher-guidelines.rst +++ b/Documentation/process/researcher-guidelines.rst @@ -44,6 +44,33 @@ explicit agreement of, and full disclosure to, the individual developers involved. Developers cannot be interacted with/experimented on without consent; this, too, is standard research ethics. +Surveys +======= + +Research often takes the form of surveys sent to maintainers or +contributors. As a general rule, though, the kernel community derives +little value from these surveys. The kernel development process works +because every developer benefits from their participation, even working +with others who have different goals. Responding to a survey, though, is a +one-way demand placed on busy developers with no corresponding benefit to +themselves or to the kernel community as a whole. For this reason, this +method of research is discouraged. + +Kernel community members already receive far too much email and are likely +to perceive survey requests as just another demand on their time. Sending +such requests deprives the community of valuable contributor time and is +unlikely to yield a statistically useful response. + +As an alternative, researchers should consider attending developer events, +hosting sessions where the research project and its benefits to the +participants can be explained, and interacting directly with the community +there. The information received will be far richer than that obtained from +an email survey, and the community will gain from the ability to learn from +your insights as well. + +Patches +======= + To help clarify: sending patches to developers *is* interacting with them, but they have already consented to receiving *good faith contributions*. Sending intentionally flawed/vulnerable patches or diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst index 82e29837d589..5a6993795bd2 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -63,31 +63,28 @@ information submitted to the security list and any followup discussions of the report are treated confidentially even after the embargo has been lifted, in perpetuity. -Coordination ------------- - -Fixes for sensitive bugs, such as those that might lead to privilege -escalations, may need to be coordinated with the private -<linux-distros@vs.openwall.org> mailing list so that distribution vendors -are well prepared to issue a fixed kernel upon public disclosure of the -upstream fix. Distros will need some time to test the proposed patch and -will generally request at least a few days of embargo, and vendor update -publication prefers to happen Tuesday through Thursday. When appropriate, -the security team can assist with this coordination, or the reporter can -include linux-distros from the start. In this case, remember to prefix -the email Subject line with "[vs]" as described in the linux-distros wiki: -<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists> +Coordination with other groups +------------------------------ + +The kernel security team strongly recommends that reporters of potential +security issues NEVER contact the "linux-distros" mailing list until +AFTER discussing it with the kernel security team. Do not Cc: both +lists at once. You may contact the linux-distros mailing list after a +fix has been agreed on and you fully understand the requirements that +doing so will impose on you and the kernel community. + +The different lists have different goals and the linux-distros rules do +not contribute to actually fixing any potential security problems. CVE assignment -------------- -The security team does not normally assign CVEs, nor do we require them -for reports or fixes, as this can needlessly complicate the process and -may delay the bug handling. If a reporter wishes to have a CVE identifier -assigned ahead of public disclosure, they will need to contact the private -linux-distros list, described above. When such a CVE identifier is known -before a patch is provided, it is desirable to mention it in the commit -message if the reporter agrees. +The security team does not assign CVEs, nor do we require them for +reports or fixes, as this can needlessly complicate the process and may +delay the bug handling. If a reporter wishes to have a CVE identifier +assigned, they should find one by themselves, for example by contacting +MITRE directly. However under no circumstances will a patch inclusion +be delayed to wait for a CVE identifier to arrive. Non-disclosure agreements ------------------------- diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 51df1197d5ab..41f1e07abfdf 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -6,30 +6,29 @@ Everything you ever wanted to know about Linux -stable releases Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree: + - It or an equivalent fix must already exist in Linus' tree (upstream). - It must be obviously correct and tested. - It cannot be bigger than 100 lines, with context. - - It must fix only one thing. - - It must fix a real bug that bothers people (not a, "This could be a - problem..." type thing). - - It must fix a problem that causes a build error (but not for things - marked CONFIG_BROKEN), an oops, a hang, data corruption, a real - security issue, or some "oh, that's not good" issue. In short, something - critical. - - Serious issues as reported by a user of a distribution kernel may also - be considered if they fix a notable performance or interactivity issue. - As these fixes are not as obvious and have a higher risk of a subtle - regression they should only be submitted by a distribution kernel - maintainer and include an addendum linking to a bugzilla entry if it - exists and additional information on the user-visible impact. - - New device IDs and quirks are also accepted. - - No "theoretical race condition" issues, unless an explanation of how the - race can be exploited is also provided. - - It cannot contain any "trivial" fixes in it (spelling changes, - whitespace cleanups, etc). - It must follow the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` rules. - - It or an equivalent fix must already exist in Linus' tree (upstream). + - It must either fix a real bug that bothers people or just add a device ID. + To elaborate on the former: + + - It fixes a problem like an oops, a hang, data corruption, a real security + issue, a hardware quirk, a build error (but not for things marked + CONFIG_BROKEN), or some "oh, that's not good" issue. + - Serious issues as reported by a user of a distribution kernel may also + be considered if they fix a notable performance or interactivity issue. + As these fixes are not as obvious and have a higher risk of a subtle + regression they should only be submitted by a distribution kernel + maintainer and include an addendum linking to a bugzilla entry if it + exists and additional information on the user-visible impact. + - No "This could be a problem..." type of things like a "theoretical race + condition", unless an explanation of how the bug can be exploited is also + provided. + - No "trivial" fixes without benefit for users (spelling changes, whitespace + cleanups, etc). Procedure for submitting patches to the -stable tree @@ -41,111 +40,142 @@ Procedure for submitting patches to the -stable tree process but should follow the procedures in :ref:`Documentation/process/security-bugs.rst <securitybugs>`. -For all other submissions, choose one of the following procedures ------------------------------------------------------------------ +There are three options to submit a change to -stable trees: + + 1. Add a 'stable tag' to the description of a patch you then submit for + mainline inclusion. + 2. Ask the stable team to pick up a patch already mainlined. + 3. Submit a patch to the stable team that is equivalent to a change already + mainlined. + +The sections below describe each of the options in more detail. + +:ref:`option_1` is **strongly** preferred, it is the easiest and most common. +:ref:`option_2` is mainly meant for changes where backporting was not considered +at the time of submission. :ref:`option_3` is an alternative to the two earlier +options for cases where a mainlined patch needs adjustments to apply in older +series (for example due to API changes). + +When using option 2 or 3 you can ask for your change to be included in specific +stable series. When doing so, ensure the fix or an equivalent is applicable, +submitted, or already present in all newer stable trees still supported. This is +meant to prevent regressions that users might later encounter on updating, if +e.g. a fix merged for 5.19-rc1 would be backported to 5.10.y, but not to 5.15.y. .. _option_1: Option 1 ******** -To have the patch automatically included in the stable tree, add the tag +To have a patch you submit for mainline inclusion later automatically picked up +for stable trees, add the tag .. code-block:: none Cc: stable@vger.kernel.org -in the sign-off area. Once the patch is merged it will be applied to -the stable tree without anything else needing to be done by the author -or subsystem maintainer. +in the sign-off area. Once the patch is mainlined it will be applied to the +stable tree without anything else needing to be done by the author or +subsystem maintainer. -.. _option_2: +To sent additional instructions to the stable team, use a shell-style inline +comment: -Option 2 -******** + * To specify any additional patch prerequisites for cherry picking use the + following format in the sign-off area: -After the patch has been merged to Linus' tree, send an email to -stable@vger.kernel.org containing the subject of the patch, the commit ID, -why you think it should be applied, and what kernel version you wish it to -be applied to. + .. code-block:: none -.. _option_3: + Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle + Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle + Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic + Cc: <stable@vger.kernel.org> # 3.3.x + Signed-off-by: Ingo Molnar <mingo@elte.hu> -Option 3 -******** + The tag sequence has the meaning of: -Send the patch, after verifying that it follows the above rules, to -stable@vger.kernel.org. You must note the upstream commit ID in the -changelog of your submission, as well as the kernel version you wish -it to be applied to. + .. code-block:: none -:ref:`option_1` is **strongly** preferred, is the easiest and most common. -:ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed -worthy at the time it is applied to a public git tree (for instance, because -it deserves more regression testing first). :ref:`option_3` is especially -useful if the original upstream patch needs to be backported (for example -the backport needs some special handling due to e.g. API changes). + git cherry-pick a1f84a3 + git cherry-pick 1b9508f + git cherry-pick fd21073 + git cherry-pick <this commit> -Note that for :ref:`option_3`, if the patch deviates from the original -upstream patch (for example because it had to be backported) this must be very -clearly documented and justified in the patch description. + * For patches that may have kernel version prerequisites specify them using + the following format in the sign-off area: -The upstream commit ID must be specified with a separate line above the commit -text, like this: + .. code-block:: none -.. code-block:: none + Cc: <stable@vger.kernel.org> # 3.3.x - commit <sha1> upstream. + The tag has the meaning of: -or alternatively: + .. code-block:: none -.. code-block:: none + git cherry-pick <this commit> - [ Upstream commit <sha1> ] + For each "-stable" tree starting with the specified version. -Additionally, some patches submitted via :ref:`option_1` may have additional -patch prerequisites which can be cherry-picked. This can be specified in the -following format in the sign-off area: + Note, such tagging is unnecessary if the stable team can derive the + appropriate versions from Fixes: tags. -.. code-block:: none + * To delay pick up of patches, use the following format: - Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle - Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle - Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic - Cc: <stable@vger.kernel.org> # 3.3.x - Signed-off-by: Ingo Molnar <mingo@elte.hu> + .. code-block:: none -The tag sequence has the meaning of: + Cc: <stable@vger.kernel.org> # after 4 weeks in mainline -.. code-block:: none + * For any other requests, just add a note to the stable tag. This for example + can be used to point out known problems: - git cherry-pick a1f84a3 - git cherry-pick 1b9508f - git cherry-pick fd21073 - git cherry-pick <this commit> + .. code-block:: none + + Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3 + +.. _option_2: + +Option 2 +******** + +If the patch already has been merged to mainline, send an email to +stable@vger.kernel.org containing the subject of the patch, the commit ID, +why you think it should be applied, and what kernel versions you wish it to +be applied to. + +.. _option_3: -Also, some patches may have kernel version prerequisites. This can be -specified in the following format in the sign-off area: +Option 3 +******** + +Send the patch, after verifying that it follows the above rules, to +stable@vger.kernel.org and mention the kernel versions you wish it to be applied +to. When doing so, you must note the upstream commit ID in the changelog of your +submission with a separate line above the commit text, like this: .. code-block:: none - Cc: <stable@vger.kernel.org> # 3.3.x + commit <sha1> upstream. -The tag has the meaning of: +or alternatively: .. code-block:: none - git cherry-pick <this commit> + [ Upstream commit <sha1> ] + +If the submitted patch deviates from the original upstream patch (for example +because it had to be adjusted for the older API), this must be very clearly +documented and justified in the patch description. -For each "-stable" tree starting with the specified version. -Following the submission: +Following the submission +------------------------ - - The sender will receive an ACK when the patch has been accepted into the - queue, or a NAK if the patch is rejected. This response might take a few - days, according to the developer's schedules. - - If accepted, the patch will be added to the -stable queue, for review by - other developers and by the relevant subsystem maintainer. +The sender will receive an ACK when the patch has been accepted into the +queue, or a NAK if the patch is rejected. This response might take a few +days, according to the schedules of the stable team members. + +If accepted, the patch will be added to the -stable queue, for review by other +developers and by the relevant subsystem maintainer. Review cycle @@ -174,6 +204,7 @@ Review cycle security kernel team, and not go through the normal review cycle. Contact the kernel security team for more details on this procedure. + Trees ----- diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 486875fd73c0..efac910e2659 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -331,6 +331,31 @@ explaining difference against previous submission (see See Documentation/process/email-clients.rst for recommendations on email clients and mailing list etiquette. +.. _interleaved_replies: + +Use trimmed interleaved replies in email discussions +---------------------------------------------------- +Top-posting is strongly discouraged in Linux kernel development +discussions. Interleaved (or "inline") replies make conversations much +easier to follow. For more details see: +https://en.wikipedia.org/wiki/Posting_style#Interleaved_style + +As is frequently quoted on the mailing list:: + + A: http://en.wikipedia.org/wiki/Top_post + Q: Were do I find info about this thing called top-posting? + A: Because it messes up the order in which people normally read text. + Q: Why is top-posting such a bad thing? + A: Top-posting. + Q: What is the most annoying thing in e-mail? + +Similarly, please trim all unneeded quotations that aren't relevant +to your reply. This makes responses easier to find, and saves time and +space. For more details see: http://daringfireball.net/2007/07/on_top :: + + A: No. + Q: Should I include quotations after my reply? + .. _resend_reminders: Don't get discouraged - or impatient diff --git a/Documentation/riscv/acpi.rst b/Documentation/riscv/acpi.rst new file mode 100644 index 000000000000..9870a282815b --- /dev/null +++ b/Documentation/riscv/acpi.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +ACPI on RISC-V +============== + +The ISA string parsing rules for ACPI are defined by `Version ASCIIDOC +Conversion, 12/2022 of the RISC-V specifications, as defined by tag +"riscv-isa-release-1239329-2023-05-23" (commit 1239329 +) <https://github.com/riscv/riscv-isa-manual/releases/tag/riscv-isa-release-1239329-2023-05-23>`_ diff --git a/Documentation/riscv/boot-image-header.rst b/Documentation/riscv/boot-image-header.rst index d7752533865f..df2ffc173e80 100644 --- a/Documentation/riscv/boot-image-header.rst +++ b/Documentation/riscv/boot-image-header.rst @@ -7,9 +7,6 @@ Boot image header in RISC-V Linux This document only describes the boot image header details for RISC-V Linux. -TODO: - Write a complete booting guide. - The following 64-byte header is present in decompressed Linux kernel image:: u32 code0; /* Executable code */ @@ -31,11 +28,11 @@ header in future. Notes ===== -- This header can also be reused to support EFI stub for RISC-V in future. EFI - specification needs PE/COFF image header in the beginning of the kernel image - in order to load it as an EFI application. In order to support EFI stub, - code0 should be replaced with "MZ" magic string and res3(at offset 0x3c) should - point to the rest of the PE/COFF header. +- This header is also reused to support EFI stub for RISC-V. EFI specification + needs PE/COFF image header in the beginning of the kernel image in order to + load it as an EFI application. In order to support EFI stub, code0 is replaced + with "MZ" magic string and res3(at offset 0x3c) points to the rest of the + PE/COFF header. - version field indicate header version number diff --git a/Documentation/riscv/boot.rst b/Documentation/riscv/boot.rst new file mode 100644 index 000000000000..6077b587a842 --- /dev/null +++ b/Documentation/riscv/boot.rst @@ -0,0 +1,169 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============================================== +RISC-V Kernel Boot Requirements and Constraints +=============================================== + +:Author: Alexandre Ghiti <alexghiti@rivosinc.com> +:Date: 23 May 2023 + +This document describes what the RISC-V kernel expects from bootloaders and +firmware, and also the constraints that any developer must have in mind when +touching the early boot process. For the purposes of this document, the +``early boot process`` refers to any code that runs before the final virtual +mapping is set up. + +Pre-kernel Requirements and Constraints +======================================= + +The RISC-V kernel expects the following of bootloaders and platform firmware: + +Register state +-------------- + +The RISC-V kernel expects: + + * ``$a0`` to contain the hartid of the current core. + * ``$a1`` to contain the address of the devicetree in memory. + +CSR state +--------- + +The RISC-V kernel expects: + + * ``$satp = 0``: the MMU, if present, must be disabled. + +Reserved memory for resident firmware +------------------------------------- + +The RISC-V kernel must not map any resident memory, or memory protected with +PMPs, in the direct mapping, so the firmware must correctly mark those regions +as per the devicetree specification and/or the UEFI specification. + +Kernel location +--------------- + +The RISC-V kernel expects to be placed at a PMD boundary (2MB aligned for rv64 +and 4MB aligned for rv32). Note that the EFI stub will physically relocate the +kernel if that's not the case. + +Hardware description +-------------------- + +The firmware can pass either a devicetree or ACPI tables to the RISC-V kernel. + +The devicetree is either passed directly to the kernel from the previous stage +using the ``$a1`` register, or when booting with UEFI, it can be passed using the +EFI configuration table. + +The ACPI tables are passed to the kernel using the EFI configuration table. In +this case, a tiny devicetree is still created by the EFI stub. Please refer to +"EFI stub and devicetree" section below for details about this devicetree. + +Kernel entry +------------ + +On SMP systems, there are 2 methods to enter the kernel: + +- ``RISCV_BOOT_SPINWAIT``: the firmware releases all harts in the kernel, one hart + wins a lottery and executes the early boot code while the other harts are + parked waiting for the initialization to finish. This method is mostly used to + support older firmwares without SBI HSM extension and M-mode RISC-V kernel. +- ``Ordered booting``: the firmware releases only one hart that will execute the + initialization phase and then will start all other harts using the SBI HSM + extension. The ordered booting method is the preferred booting method for + booting the RISC-V kernel because it can support CPU hotplug and kexec. + +UEFI +---- + +UEFI memory map +~~~~~~~~~~~~~~~ + +When booting with UEFI, the RISC-V kernel will use only the EFI memory map to +populate the system memory. + +The UEFI firmware must parse the subnodes of the ``/reserved-memory`` devicetree +node and abide by the devicetree specification to convert the attributes of +those subnodes (``no-map`` and ``reusable``) into their correct EFI equivalent +(refer to section "3.5.4 /reserved-memory and UEFI" of the devicetree +specification v0.4-rc1). + +RISCV_EFI_BOOT_PROTOCOL +~~~~~~~~~~~~~~~~~~~~~~~ + +When booting with UEFI, the EFI stub requires the boot hartid in order to pass +it to the RISC-V kernel in ``$a1``. The EFI stub retrieves the boot hartid using +one of the following methods: + +- ``RISCV_EFI_BOOT_PROTOCOL`` (**preferred**). +- ``boot-hartid`` devicetree subnode (**deprecated**). + +Any new firmware must implement ``RISCV_EFI_BOOT_PROTOCOL`` as the devicetree +based approach is deprecated now. + +Early Boot Requirements and Constraints +======================================= + +The RISC-V kernel's early boot process operates under the following constraints: + +EFI stub and devicetree +----------------------- + +When booting with UEFI, the devicetree is supplemented (or created) by the EFI +stub with the same parameters as arm64 which are described at the paragraph +"UEFI kernel support on ARM" in Documentation/arch/arm/uefi.rst. + +Virtual mapping installation +---------------------------- + +The installation of the virtual mapping is done in 2 steps in the RISC-V kernel: + +1. ``setup_vm()`` installs a temporary kernel mapping in ``early_pg_dir`` which + allows discovery of the system memory. Only the kernel text/data are mapped + at this point. When establishing this mapping, no allocation can be done + (since the system memory is not known yet), so ``early_pg_dir`` page table is + statically allocated (using only one table for each level). + +2. ``setup_vm_final()`` creates the final kernel mapping in ``swapper_pg_dir`` + and takes advantage of the discovered system memory to create the linear + mapping. When establishing this mapping, the kernel can allocate memory but + cannot access it directly (since the direct mapping is not present yet), so + it uses temporary mappings in the fixmap region to be able to access the + newly allocated page table levels. + +For ``virt_to_phys()`` and ``phys_to_virt()`` to be able to correctly convert +direct mapping addresses to physical addresses, they need to know the start of +the DRAM. This happens after step 1, right before step 2 installs the direct +mapping (see ``setup_bootmem()`` function in arch/riscv/mm/init.c). Any usage of +those macros before the final virtual mapping is installed must be carefully +examined. + +Devicetree mapping via fixmap +----------------------------- + +As the ``reserved_mem`` array is initialized with virtual addresses established +by ``setup_vm()``, and used with the mapping established by +``setup_vm_final()``, the RISC-V kernel uses the fixmap region to map the +devicetree. This ensures that the devicetree remains accessible by both virtual +mappings. + +Pre-MMU execution +----------------- + +A few pieces of code need to run before even the first virtual mapping is +established. These are the installation of the first virtual mapping itself, +patching of early alternatives and the early parsing of the kernel command line. +That code must be very carefully compiled as: + +- ``-fno-pie``: This is needed for relocatable kernels which use ``-fPIE``, + since otherwise, any access to a global symbol would go through the GOT which + is only relocated virtually. +- ``-mcmodel=medany``: Any access to a global symbol must be PC-relative to + avoid any relocations to happen before the MMU is setup. +- *all* instrumentation must also be disabled (that includes KASAN, ftrace and + others). + +As using a symbol from a different compilation unit requires this unit to be +compiled with those flags, we advise, as much as possible, not to use external +symbols. diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst index 9f0dd62dcb5d..20eff9650da9 100644 --- a/Documentation/riscv/hwprobe.rst +++ b/Documentation/riscv/hwprobe.rst @@ -49,7 +49,7 @@ The following keys are defined: privileged ISA, with the following known exceptions (more exceptions may be added, but only if it can be demonstrated that the user ABI is not broken): - * The :fence.i: instruction cannot be directly executed by userspace + * The ``fence.i`` instruction cannot be directly executed by userspace programs (it may still be executed in userspace via a kernel-controlled mechanism such as the vDSO). @@ -64,6 +64,19 @@ The following keys are defined: * :c:macro:`RISCV_HWPROBE_IMA_C`: The C extension is supported, as defined by version 2.2 of the RISC-V ISA manual. + * :c:macro:`RISCV_HWPROBE_IMA_V`: The V extension is supported, as defined by + version 1.0 of the RISC-V Vector extension manual. + + * :c:macro:`RISCV_HWPROBE_EXT_ZBA`: The Zba address generation extension is + supported, as defined in version 1.0 of the Bit-Manipulation ISA + extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, as defined + in version 1.0 of the Bit-Manipulation ISA extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined + in version 1.0 of the Bit-Manipulation ISA extensions. + * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance information about the selected set of processors. @@ -75,11 +88,11 @@ The following keys are defined: always extremely slow. * :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are supported - in hardware, but are slower than the cooresponding aligned accesses + in hardware, but are slower than the corresponding aligned accesses sequences. * :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are supported - in hardware and are faster than the cooresponding aligned accesses + in hardware and are faster than the corresponding aligned accesses sequences. * :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst index 175a91db0200..4dab0cb4b900 100644 --- a/Documentation/riscv/index.rst +++ b/Documentation/riscv/index.rst @@ -5,11 +5,14 @@ RISC-V architecture .. toctree:: :maxdepth: 1 + acpi + boot boot-image-header vm-layout hwprobe patch-acceptance uabi + vector features diff --git a/Documentation/riscv/vector.rst b/Documentation/riscv/vector.rst new file mode 100644 index 000000000000..75dd88a62e1d --- /dev/null +++ b/Documentation/riscv/vector.rst @@ -0,0 +1,140 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================================= +Vector Extension Support for RISC-V Linux +========================================= + +This document briefly outlines the interface provided to userspace by Linux in +order to support the use of the RISC-V Vector Extension. + +1. prctl() Interface +--------------------- + +Two new prctl() calls are added to allow programs to manage the enablement +status for the use of Vector in userspace. The intended usage guideline for +these interfaces is to give init systems a way to modify the availability of V +for processes running under its domain. Calling these interfaces is not +recommended in libraries routines because libraries should not override policies +configured from the parant process. Also, users must noted that these interfaces +are not portable to non-Linux, nor non-RISC-V environments, so it is discourage +to use in a portable code. To get the availability of V in an ELF program, +please read :c:macro:`COMPAT_HWCAP_ISA_V` bit of :c:macro:`ELF_HWCAP` in the +auxiliary vector. + +* prctl(PR_RISCV_V_SET_CONTROL, unsigned long arg) + + Sets the Vector enablement status of the calling thread, where the control + argument consists of two 2-bit enablement statuses and a bit for inheritance + mode. Other threads of the calling process are unaffected. + + Enablement status is a tri-state value each occupying 2-bit of space in + the control argument: + + * :c:macro:`PR_RISCV_V_VSTATE_CTRL_DEFAULT`: Use the system-wide default + enablement status on execve(). The system-wide default setting can be + controlled via sysctl interface (see sysctl section below). + + * :c:macro:`PR_RISCV_V_VSTATE_CTRL_ON`: Allow Vector to be run for the + thread. + + * :c:macro:`PR_RISCV_V_VSTATE_CTRL_OFF`: Disallow Vector. Executing Vector + instructions under such condition will trap and casuse the termination of the thread. + + arg: The control argument is a 5-bit value consisting of 3 parts, and + accessed by 3 masks respectively. + + The 3 masks, PR_RISCV_V_VSTATE_CTRL_CUR_MASK, + PR_RISCV_V_VSTATE_CTRL_NEXT_MASK, and PR_RISCV_V_VSTATE_CTRL_INHERIT + represents bit[1:0], bit[3:2], and bit[4]. bit[1:0] accounts for the + enablement status of current thread, and the setting at bit[3:2] takes place + at next execve(). bit[4] defines the inheritance mode of the setting in + bit[3:2]. + + * :c:macro:`PR_RISCV_V_VSTATE_CTRL_CUR_MASK`: bit[1:0]: Account for the + Vector enablement status for the calling thread. The calling thread is + not able to turn off Vector once it has been enabled. The prctl() call + fails with EPERM if the value in this mask is PR_RISCV_V_VSTATE_CTRL_OFF + but the current enablement status is not off. Setting + PR_RISCV_V_VSTATE_CTRL_DEFAULT here takes no effect but to set back + the original enablement status. + + * :c:macro:`PR_RISCV_V_VSTATE_CTRL_NEXT_MASK`: bit[3:2]: Account for the + Vector enablement setting for the calling thread at the next execve() + system call. If PR_RISCV_V_VSTATE_CTRL_DEFAULT is used in this mask, + then the enablement status will be decided by the system-wide + enablement status when execve() happen. + + * :c:macro:`PR_RISCV_V_VSTATE_CTRL_INHERIT`: bit[4]: the inheritance + mode for the setting at PR_RISCV_V_VSTATE_CTRL_NEXT_MASK. If the bit + is set then the following execve() will not clear the setting in both + PR_RISCV_V_VSTATE_CTRL_NEXT_MASK and PR_RISCV_V_VSTATE_CTRL_INHERIT. + This setting persists across changes in the system-wide default value. + + Return value: + * 0 on success; + * EINVAL: Vector not supported, invalid enablement status for current or + next mask; + * EPERM: Turning off Vector in PR_RISCV_V_VSTATE_CTRL_CUR_MASK if Vector + was enabled for the calling thread. + + On success: + * A valid setting for PR_RISCV_V_VSTATE_CTRL_CUR_MASK takes place + immediately. The enablement status specified in + PR_RISCV_V_VSTATE_CTRL_NEXT_MASK happens at the next execve() call, or + all following execve() calls if PR_RISCV_V_VSTATE_CTRL_INHERIT bit is + set. + * Every successful call overwrites a previous setting for the calling + thread. + +* prctl(PR_RISCV_V_GET_CONTROL) + + Gets the same Vector enablement status for the calling thread. Setting for + next execve() call and the inheritance bit are all OR-ed together. + + Note that ELF programs are able to get the availability of V for itself by + reading :c:macro:`COMPAT_HWCAP_ISA_V` bit of :c:macro:`ELF_HWCAP` in the + auxiliary vector. + + Return value: + * a nonnegative value on success; + * EINVAL: Vector not supported. + +2. System runtime configuration (sysctl) +----------------------------------------- + +To mitigate the ABI impact of expansion of the signal stack, a +policy mechanism is provided to the administrators, distro maintainers, and +developers to control the default Vector enablement status for userspace +processes in form of sysctl knob: + +* /proc/sys/abi/riscv_v_default_allow + + Writing the text representation of 0 or 1 to this file sets the default + system enablement status for new starting userspace programs. Valid values + are: + + * 0: Do not allow Vector code to be executed as the default for new processes. + * 1: Allow Vector code to be executed as the default for new processes. + + Reading this file returns the current system default enablement status. + + At every execve() call, a new enablement status of the new process is set to + the system default, unless: + + * PR_RISCV_V_VSTATE_CTRL_INHERIT is set for the calling process, and the + setting in PR_RISCV_V_VSTATE_CTRL_NEXT_MASK is not + PR_RISCV_V_VSTATE_CTRL_DEFAULT. Or, + + * The setting in PR_RISCV_V_VSTATE_CTRL_NEXT_MASK is not + PR_RISCV_V_VSTATE_CTRL_DEFAULT. + + Modifying the system default enablement status does not affect the enablement + status of any existing process of thread that do not make an execve() call. + +3. Vector Register State Across System Calls +--------------------------------------------- + +As indicated by version 1.0 of the V extension [1], vector registers are +clobbered by system calls. + +1: https://github.com/riscv/riscv-v-spec/blob/master/calling-convention.adoc diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst index 5462c84f4723..69ff6da1dbf8 100644 --- a/Documentation/riscv/vm-layout.rst +++ b/Documentation/riscv/vm-layout.rst @@ -133,3 +133,25 @@ RISC-V Linux Kernel SV57 ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel __________________|____________|__________________|_________|____________________________________________________________ + + +Userspace VAs +-------------------- +To maintain compatibility with software that relies on the VA space with a +maximum of 48 bits the kernel will, by default, return virtual addresses to +userspace from a 48-bit range (sv48). This default behavior is achieved by +passing 0 into the hint address parameter of mmap. On CPUs with an address space +smaller than sv48, the CPU maximum supported address space will be the default. + +Software can "opt-in" to receiving VAs from another VA space by providing +a hint address to mmap. A hint address passed to mmap will cause the largest +address space that fits entirely into the hint to be used, unless there is no +space left in the address space. If there is no space available in the requested +address space, an address in the next smallest available address space will be +returned. + +For example, in order to obtain 48-bit VA space, a hint address greater than +:code:`1 << 47` must be provided. Note that this is 47 due to sv48 userspace +ending at :code:`1 << 47` and the addresses beyond this are reserved for the +kernel. Similarly, to obtain 57-bit VA space addresses, a hint address greater +than or equal to :code:`1 << 56` must be provided. diff --git a/Documentation/rust/index.rst b/Documentation/rust/index.rst index 4ae8c66b94fa..e599be2cec9b 100644 --- a/Documentation/rust/index.rst +++ b/Documentation/rust/index.rst @@ -6,6 +6,14 @@ Rust Documentation related to Rust within the kernel. To start using Rust in the kernel, please read the quick-start.rst guide. +.. only:: rustdoc and html + + You can also browse `rustdoc documentation <rustdoc/kernel/index.html>`_. + +.. only:: not rustdoc and html + + This documentation does not include rustdoc generated information. + .. toctree:: :maxdepth: 1 diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst index 13b7744b1e27..f382914f4191 100644 --- a/Documentation/rust/quick-start.rst +++ b/Documentation/rust/quick-start.rst @@ -38,9 +38,11 @@ and run:: rustup override set $(scripts/min-tool-version.sh rustc) -Otherwise, fetch a standalone installer or install ``rustup`` from: +This will configure your working directory to use the correct version of +``rustc`` without affecting your default toolchain. If you are not using +``rustup``, fetch a standalone installer from: - https://www.rust-lang.org + https://forge.rust-lang.org/infra/other-installation-methods.html#standalone Rust standard library source @@ -56,16 +58,17 @@ If ``rustup`` is being used, run:: The components are installed per toolchain, thus upgrading the Rust compiler version later on requires re-adding the component. -Otherwise, if a standalone installer is used, the Rust repository may be cloned -into the installation folder of the toolchain:: +Otherwise, if a standalone installer is used, the Rust source tree may be +downloaded into the toolchain's installation folder:: - git clone --recurse-submodules \ - --branch $(scripts/min-tool-version.sh rustc) \ - https://github.com/rust-lang/rust \ - $(rustc --print sysroot)/lib/rustlib/src/rust + curl -L "https://static.rust-lang.org/dist/rust-src-$(scripts/min-tool-version.sh rustc).tar.gz" | + tar -xzf - -C "$(rustc --print sysroot)/lib" \ + "rust-src-$(scripts/min-tool-version.sh rustc)/rust-src/lib/" \ + --strip-components=3 In this case, upgrading the Rust compiler version later on requires manually -updating this clone. +updating the source tree (this can be done by removing ``$(rustc --print +sysroot)/lib/rustlib/src/rust`` then rerunning the above command). libclang @@ -98,7 +101,24 @@ the ``bindgen`` tool. A particular version is required. Install it via (note that this will download and build the tool from source):: - cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen + cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen-cli + +``bindgen`` needs to find a suitable ``libclang`` in order to work. If it is +not found (or a different ``libclang`` than the one found should be used), +the process can be tweaked using the environment variables understood by +``clang-sys`` (the Rust bindings crate that ``bindgen`` uses to access +``libclang``): + +* ``LLVM_CONFIG_PATH`` can be pointed to an ``llvm-config`` executable. + +* Or ``LIBCLANG_PATH`` can be pointed to a ``libclang`` shared library + or to the directory containing it. + +* Or ``CLANG_PATH`` can be pointed to a ``clang`` executable. + +For details, please see ``clang-sys``'s documentation at: + + https://github.com/KyleMayes/clang-sys#environment-variables Requirements: Developing @@ -179,7 +199,9 @@ be used with many editors to enable syntax highlighting, completion, go to definition, and other features. ``rust-analyzer`` needs a configuration file, ``rust-project.json``, which -can be generated by the ``rust-analyzer`` Make target. +can be generated by the ``rust-analyzer`` Make target:: + + make LLVM=1 rust-analyzer Configuration diff --git a/Documentation/scheduler/completion.rst b/Documentation/scheduler/completion.rst index 9f039b4f4b09..f19aca2062bd 100644 --- a/Documentation/scheduler/completion.rst +++ b/Documentation/scheduler/completion.rst @@ -157,7 +157,7 @@ A typical usage scenario is:: /* run non-dependent code */ /* do setup */ - wait_for_completion(&setup_done); complete(setup_done); + wait_for_completion(&setup_done); complete(&setup_done); This is not implying any particular order between wait_for_completion() and the call to complete() - if the call to complete() happened before the call diff --git a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst index f166b182ff95..41ed2ceafc92 100644 --- a/Documentation/scheduler/sched-bwc.rst +++ b/Documentation/scheduler/sched-bwc.rst @@ -186,7 +186,7 @@ average usage, albeit over a longer time window than a single period. This also limits the burst ability to no more than 1ms per cpu. This provides better more predictable user experience for highly threaded applications with small quota limits on high core count machines. It also eliminates the -propensity to throttle these applications while simultanously using less than +propensity to throttle these applications while simultaneously using less than quota amounts of cpu. Another way to say this, is that by allowing the unused portion of a slice to remain valid across periods we have decreased the possibility of wastefully expiring quota on cpu-local silos that don't need a diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst index 9d9be52f221a..9fe4846079bb 100644 --- a/Documentation/scheduler/sched-deadline.rst +++ b/Documentation/scheduler/sched-deadline.rst @@ -203,12 +203,15 @@ Deadline Task Scheduling - Total bandwidth (this_bw): this is the sum of all tasks "belonging" to the runqueue, including the tasks in Inactive state. + - Maximum usable bandwidth (max_bw): This is the maximum bandwidth usable by + deadline tasks and is currently set to the RT capacity. + The algorithm reclaims the bandwidth of the tasks in Inactive state. It does so by decrementing the runtime of the executing task Ti at a pace equal to - dq = -max{ Ui / Umax, (1 - Uinact - Uextra) } dt + dq = -(max{ Ui, (Umax - Uinact - Uextra) } / Umax) dt where: diff --git a/Documentation/scheduler/sched-design-CFS.rst b/Documentation/scheduler/sched-design-CFS.rst index 03db55504515..f68919800f05 100644 --- a/Documentation/scheduler/sched-design-CFS.rst +++ b/Documentation/scheduler/sched-design-CFS.rst @@ -94,7 +94,7 @@ 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): - /sys/kernel/debug/sched/min_granularity_ns + /sys/kernel/debug/sched/base_slice_ns which can be used to tune the scheduler from "desktop" (i.e., low latencies) to "server" (i.e., good batching) workloads. It defaults to a setting suitable diff --git a/Documentation/scheduler/sched-energy.rst b/Documentation/scheduler/sched-energy.rst index 8fbce5e767d9..fc853c8cc346 100644 --- a/Documentation/scheduler/sched-energy.rst +++ b/Documentation/scheduler/sched-energy.rst @@ -82,7 +82,7 @@ through the arch_scale_cpu_capacity() callback. The rest of platform knowledge used by EAS is directly read from the Energy Model (EM) framework. The EM of a platform is composed of a power cost table per 'performance domain' in the system (see Documentation/power/energy-model.rst -for futher details about performance domains). +for further details about performance domains). The scheduler manages references to the EM objects in the topology code when the scheduling domains are built, or re-built. For each root domain (rd), the @@ -281,7 +281,7 @@ mechanism called 'over-utilization'. From a general standpoint, the use-cases where EAS can help the most are those involving a light/medium CPU utilization. Whenever long CPU-bound tasks are being run, they will require all of the available CPU capacity, and there isn't -much that can be done by the scheduler to save energy without severly harming +much that can be done by the scheduler to save energy without severely harming throughput. In order to avoid hurting performance with EAS, CPUs are flagged as 'over-utilized' as soon as they are used at more than 80% of their compute capacity. As long as no CPUs are over-utilized in a root domain, load balancing diff --git a/Documentation/scsi/ChangeLog.lpfc b/Documentation/scsi/ChangeLog.lpfc index d16e6874d223..ccc48b8359bf 100644 --- a/Documentation/scsi/ChangeLog.lpfc +++ b/Documentation/scsi/ChangeLog.lpfc @@ -427,7 +427,7 @@ Changes from 20041207 to 20041213 * Changed version number to 8.0.17 * Fix sparse warnings by adding __iomem markers to lpfc_compat.h. * Fix some sparse warnings -- 0 used as NULL pointer. - * Make sure there's a space between every if and it's (. + * Make sure there's a space between every if and its (. * Fix some overly long lines and make sure hard tabs are used for indentation. * Remove all trailing whitespace. diff --git a/Documentation/scsi/arcmsr_spec.rst b/Documentation/scsi/arcmsr_spec.rst index 83dd53bcff78..792c731b6570 100644 --- a/Documentation/scsi/arcmsr_spec.rst +++ b/Documentation/scsi/arcmsr_spec.rst @@ -1,3 +1,4 @@ +=================== ARECA FIRMWARE SPEC =================== diff --git a/Documentation/scsi/dc395x.rst b/Documentation/scsi/dc395x.rst index d779e782b1cb..d92947c175a5 100644 --- a/Documentation/scsi/dc395x.rst +++ b/Documentation/scsi/dc395x.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -====================================== -README file for the dc395x SCSI driver -====================================== +================== +dc395x SCSI driver +================== Status ------ @@ -11,13 +11,10 @@ be safe to use. Testing with hard disks has not been done to any great degree and caution should be exercised if you want to attempt to use this driver with hard disks. -This is a 2.5 only driver. For a 2.4 driver please see the original -driver (which this driver started from) at -http://www.garloff.de/kurt/linux/dc395/ - -Problems, questions and patches should be submitted to the mailing -list. Details on the list, including archives, are available at -http://lists.twibble.org/mailman/listinfo/dc395x/ +This driver is evolved from `the original 2.4 driver +<https://web.archive.org/web/20140129181343/http://www.garloff.de/kurt/linux/dc395/>`_. +Problems, questions and patches should be submitted to the `Linux SCSI +mailing list <linux-scsi@vger.kernel.org>`_. Parameters ---------- diff --git a/Documentation/scsi/g_NCR5380.rst b/Documentation/scsi/g_NCR5380.rst index a282059fec43..b250c24fc760 100644 --- a/Documentation/scsi/g_NCR5380.rst +++ b/Documentation/scsi/g_NCR5380.rst @@ -1,9 +1,9 @@ .. SPDX-License-Identifier: GPL-2.0 .. include:: <isonum.txt> -========================================== -README file for the Linux g_NCR5380 driver -========================================== +================ +g_NCR5380 driver +================ Copyright |copy| 1993 Drew Eckhard diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 919f3edfe1bf..f15a0f348ae4 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -7,6 +7,38 @@ SCSI Subsystem .. toctree:: :maxdepth: 1 +Introduction +============ + +.. toctree:: + :maxdepth: 1 + + scsi + +SCSI driver APIs +================ + +.. toctree:: + :maxdepth: 1 + + scsi_mid_low_api + scsi_eh + +SCSI driver parameters +====================== + +.. toctree:: + :maxdepth: 1 + + scsi-parameters + link_power_management_policy + +SCSI host adapter drivers +========================= + +.. toctree:: + :maxdepth: 1 + 53c700 aacraid advansys @@ -25,7 +57,6 @@ SCSI Subsystem hpsa hptiop libsas - link_power_management_policy lpfc megaraid ncr53c8xx @@ -33,12 +64,8 @@ SCSI Subsystem ppa qlogicfas scsi-changer - scsi_eh scsi_fc_transport scsi-generic - scsi_mid_low_api - scsi-parameters - scsi sd-parameters smartpqi st diff --git a/Documentation/scsi/megaraid.rst b/Documentation/scsi/megaraid.rst index 22b75a86ba72..10a6b05fc7c4 100644 --- a/Documentation/scsi/megaraid.rst +++ b/Documentation/scsi/megaraid.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -========================== -Notes on Management Module -========================== +================================= +Megaraid Common Management Module +================================= Overview -------- diff --git a/Documentation/scsi/ncr53c8xx.rst b/Documentation/scsi/ncr53c8xx.rst index 1c79e08ec964..fd8d26dc5dab 100644 --- a/Documentation/scsi/ncr53c8xx.rst +++ b/Documentation/scsi/ncr53c8xx.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -================================================= -The Linux NCR53C8XX/SYM53C8XX drivers README file -================================================= +=========================== +NCR53C8XX/SYM53C8XX drivers +=========================== Written by Gerard Roudier <groudier@free.fr> diff --git a/Documentation/scsi/scsi-changer.rst b/Documentation/scsi/scsi-changer.rst index ab60e7e61a6c..5d828c7f492d 100644 --- a/Documentation/scsi/scsi-changer.rst +++ b/Documentation/scsi/scsi-changer.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -======================================== -README for the SCSI media changer driver -======================================== +========================= +SCSI media changer driver +========================= This is a driver for SCSI Medium Changer devices, which are listed with "Type: Medium Changer" in /proc/scsi/scsi. diff --git a/Documentation/scsi/scsi-generic.rst b/Documentation/scsi/scsi-generic.rst index 258505e557a6..b82ffe4d8892 100644 --- a/Documentation/scsi/scsi-generic.rst +++ b/Documentation/scsi/scsi-generic.rst @@ -1,15 +1,15 @@ .. SPDX-License-Identifier: GPL-2.0 -======================================= -Notes on Linux SCSI Generic (sg) driver -======================================= +======================== +SCSI Generic (sg) driver +======================== 20020126 Introduction ============ The SCSI Generic driver (sg) is one of the four "high level" SCSI device -drivers along with sd, st and sr (disk, tape and CDROM respectively). Sg +drivers along with sd, st and sr (disk, tape and CD-ROM respectively). Sg is more generalized (but lower level) than its siblings and tends to be used on SCSI devices that don't fit into the already serviced categories. Thus sg is used for scanners, CD writers and reading audio CDs digitally @@ -22,7 +22,7 @@ and examples. Major versions of the sg driver =============================== -There are three major versions of sg found in the linux kernel (lk): +There are three major versions of sg found in the Linux kernel (lk): - sg version 1 (original) from 1992 to early 1999 (lk 2.2.5) . It is based in the sg_header interface structure. - sg version 2 from lk 2.2.6 in the 2.2 series. It is based on @@ -33,34 +33,24 @@ There are three major versions of sg found in the linux kernel (lk): Sg driver documentation ======================= -The most recent documentation of the sg driver is kept at the Linux -Documentation Project's (LDP) site: +The most recent documentation of the sg driver is kept at -- http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO +- https://sg.danny.cz/sg/ This describes the sg version 3 driver found in the lk 2.4 series. -The LDP renders documents in single and multiple page HTML, postscript -and pdf. This document can also be found at: +Documentation (large version) for the version 2 sg driver found in the +lk 2.2 series can be found at -- http://sg.danny.cz/sg/p/sg_v3_ho.html - -Documentation for the version 2 sg driver found in the lk 2.2 series can -be found at http://sg.danny.cz/sg/. A larger version -is at: http://sg.danny.cz/sg/p/scsi-generic_long.txt. +- https://sg.danny.cz/sg/p/scsi-generic_long.txt. The original documentation for the sg driver (prior to lk 2.2.6) can be -found at http://www.torque.net/sg/p/original/SCSI-Programming-HOWTO.txt -and in the LDP archives. +found in the LDP archives at -A changelog with brief notes can be found in the -/usr/src/linux/include/scsi/sg.h file. Note that the glibc maintainers copy -and edit this file (removing its changelog for example) before placing it -in /usr/include/scsi/sg.h . Driver debugging information and other notes -can be found at the top of the /usr/src/linux/drivers/scsi/sg.c file. +- https://tldp.org/HOWTO/archived/SCSI-Programming-HOWTO/index.html A more general description of the Linux SCSI subsystem of which sg is a -part can be found at http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . +part can be found at https://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . Example code and utilities @@ -73,8 +63,8 @@ There are two packages of sg utilities: and earlier ========= ========================================================== -Both packages will work in the lk 2.4 series however sg3_utils offers more -capabilities. They can be found at: http://sg.danny.cz/sg/sg3_utils.html and +Both packages will work in the lk 2.4 series. However, sg3_utils offers more +capabilities. They can be found at: https://sg.danny.cz/sg/sg3_utils.html and freecode.com Another approach is to look at the applications that use the sg driver. @@ -83,7 +73,7 @@ These include cdrecord, cdparanoia, SANE and cdrdao. Mapping of Linux kernel versions to sg driver versions ====================================================== -Here is a list of linux kernels in the 2.4 series that had new version +Here is a list of Linux kernels in the 2.4 series that had the new version of the sg driver: - lk 2.4.0 : sg version 3.1.17 @@ -92,10 +82,10 @@ of the sg driver: - lk 2.4.17 : sg version 3.1.22 .. [#] There were 3 changes to sg version 3.1.20 by third parties in the - next six linux kernel versions. + next six Linux kernel versions. -For reference here is a list of linux kernels in the 2.2 series that had -new version of the sg driver: +For reference here is a list of Linux kernels in the 2.2 series that had +the new version of the sg driver: - lk 2.2.0 : original sg version [with no version number] - lk 2.2.6 : sg version 2.1.31 @@ -106,9 +96,8 @@ new version of the sg driver: - lk 2.2.17 : sg version 2.1.39 - lk 2.2.20 : sg version 2.1.40 -The lk 2.5 development series has recently commenced and it currently -contains sg version 3.5.23 which is functionally equivalent to sg -version 3.1.22 found in lk 2.4.17. +The lk 2.5 development series currently contains sg version 3.5.23 +which is functionally equivalent to sg version 3.1.22 found in lk 2.4.17. Douglas Gilbert diff --git a/Documentation/scsi/scsi.rst b/Documentation/scsi/scsi.rst index 276918eb4d74..8556846b9f63 100644 --- a/Documentation/scsi/scsi.rst +++ b/Documentation/scsi/scsi.rst @@ -6,30 +6,28 @@ SCSI subsystem documentation The Linux Documentation Project (LDP) maintains a document describing the SCSI subsystem in the Linux kernel (lk) 2.4 series. See: -http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . The LDP has single +https://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . The LDP has single and multiple page HTML renderings as well as postscript and pdf. -It can also be found at: -http://web.archive.org/web/%2E/http://www.torque.net/scsi/SCSI-2.4-HOWTO Notes on using modules in the SCSI subsystem ============================================ -The scsi support in the linux kernel can be modularized in a number of +The SCSI support in the Linux kernel can be modularized in a number of different ways depending upon the needs of the end user. To understand your options, we should first define a few terms. -The scsi-core (also known as the "mid level") contains the core of scsi -support. Without it you can do nothing with any of the other scsi drivers. -The scsi core support can be a module (scsi_mod.o), or it can be built into -the kernel. If the core is a module, it must be the first scsi module +The scsi-core (also known as the "mid level") contains the core of SCSI +support. Without it you can do nothing with any of the other SCSI drivers. +The SCSI core support can be a module (scsi_mod.o), or it can be built into +the kernel. If the core is a module, it must be the first SCSI module loaded, and if you unload the modules, it will have to be the last one -unloaded. In practice the modprobe and rmmod commands (and "autoclean") +unloaded. In practice the modprobe and rmmod commands will enforce the correct ordering of loading and unloading modules in the SCSI subsystem. The individual upper and lower level drivers can be loaded in any order -once the scsi core is present in the kernel (either compiled in or loaded -as a module). The disk driver (sd_mod.o), cdrom driver (sr_mod.o), -tape driver [1]_ (st.o) and scsi generics driver (sg.o) represent the upper +once the SCSI core is present in the kernel (either compiled in or loaded +as a module). The disk driver (sd_mod.o), CD-ROM driver (sr_mod.o), +tape driver [1]_ (st.o) and SCSI generics driver (sg.o) represent the upper level drivers to support the various assorted devices which can be controlled. You can for example load the tape driver to use the tape drive, and then unload it once you have no further need for the driver (and release @@ -44,4 +42,3 @@ built into the kernel. .. [1] There is a variant of the st driver for controlling OnStream tape devices. Its module name is osst.o . - diff --git a/Documentation/scsi/scsi_fc_transport.rst b/Documentation/scsi/scsi_fc_transport.rst index 176c1862cb9b..e3ddcfb7f8fd 100644 --- a/Documentation/scsi/scsi_fc_transport.rst +++ b/Documentation/scsi/scsi_fc_transport.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -================ -SCSI FC Tansport -================ +================= +SCSI FC Transport +================= Date: 11/18/2008 @@ -556,5 +556,5 @@ The following people have contributed to this document: James Smart -james.smart@emulex.com +james.smart@broadcom.com diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst index 6fa3a6279501..022198c51350 100644 --- a/Documentation/scsi/scsi_mid_low_api.rst +++ b/Documentation/scsi/scsi_mid_low_api.rst @@ -1190,11 +1190,11 @@ Members of interest: - pointer to scsi_device object that this command is associated with. resid - - an LLD should set this signed integer to the requested + - 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 preset to 0 so an LLD can ignore it if it cannot detect - underruns (overruns should be rare). If possible an LLD + underruns (overruns should not be reported). An LLD should set 'resid' prior to invoking 'done'. The most interesting case is data transfers from a SCSI target device (e.g. READs) that underrun. diff --git a/Documentation/scsi/sym53c8xx_2.rst b/Documentation/scsi/sym53c8xx_2.rst index 004f1a750e7d..4eb047921dce 100644 --- a/Documentation/scsi/sym53c8xx_2.rst +++ b/Documentation/scsi/sym53c8xx_2.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -========================================= -The Linux SYM-2 driver documentation file -========================================= +============ +SYM-2 driver +============ Written by Gerard Roudier <groudier@free.fr> diff --git a/Documentation/security/digsig.rst b/Documentation/security/digsig.rst index f6a8902d3ef7..de035f282196 100644 --- a/Documentation/security/digsig.rst +++ b/Documentation/security/digsig.rst @@ -82,7 +82,7 @@ The signing and key management utilities evm-utils provide functionality to generate signatures, to load keys into the kernel keyring. Keys can be in PEM or converted to the kernel format. When the key is added to the kernel keyring, the keyid defines the name -of the key: 5D2B05FC633EE3E8 in the example bellow. +of the key: 5D2B05FC633EE3E8 in the example below. Here is example output of the keyctl utility:: diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst index 811b905b56bf..326b8a973828 100644 --- a/Documentation/security/keys/core.rst +++ b/Documentation/security/keys/core.rst @@ -869,7 +869,7 @@ The keyctl syscall functions are: - ``char *hashname`` specifies the NUL terminated string identifying the hash used from the kernel crypto API and applied for the KDF - operation. The KDF implemenation complies with SP800-56A as well + operation. The KDF implementation complies with SP800-56A as well as with SP800-108 (the counter KDF). - ``char *otherinfo`` specifies the OtherInfo data as documented in diff --git a/Documentation/security/secrets/coco.rst b/Documentation/security/secrets/coco.rst index 087e2d1ae38b..a1210db8ec07 100644 --- a/Documentation/security/secrets/coco.rst +++ b/Documentation/security/secrets/coco.rst @@ -34,7 +34,7 @@ be use it for its own purposes. During the VM's launch, the virtual machine manager may inject a secret to that area. In AMD SEV and SEV-ES this is performed using the -``KVM_SEV_LAUNCH_SECRET`` command (see [sev]_). The strucutre of the injected +``KVM_SEV_LAUNCH_SECRET`` command (see [sev]_). The structure of the injected Guest Owner secret data should be a GUIDed table of secret values; the binary format is described in ``drivers/virt/coco/efi_secret/efi_secret.c`` under "Structure of the EFI secret area". diff --git a/Documentation/sound/cards/audigy-mixer.rst b/Documentation/sound/cards/audigy-mixer.rst index aa176451d5b5..7ebaacb6df3d 100644 --- a/Documentation/sound/cards/audigy-mixer.rst +++ b/Documentation/sound/cards/audigy-mixer.rst @@ -46,157 +46,158 @@ FX-bus name='PCM Front Playback Volume',index=0 ---------------------------------------- -This control is used to attenuate samples for left and right front PCM FX-bus +This control is used to attenuate samples from left and right front PCM FX-bus accumulators. ALSA uses accumulators 8 and 9 for left and right front PCM -samples for 5.1 playback. The result samples are forwarded to the front DAC PCM -slots of the Philips DAC. +samples for 5.1 playback. The result samples are forwarded to the front speakers. name='PCM Surround Playback Volume',index=0 ------------------------------------------- -This control is used to attenuate samples for left and right surround PCM FX-bus +This control is used to attenuate samples from left and right surround PCM FX-bus accumulators. ALSA uses accumulators 2 and 3 for left and right surround PCM -samples for 5.1 playback. The result samples are forwarded to the surround DAC PCM -slots of the Philips DAC. +samples for 5.1 playback. The result samples are forwarded to the surround (rear) +speakers. + +name='PCM Side Playback Volume',index=0 +--------------------------------------- +This control is used to attenuate samples from left and right side PCM FX-bus +accumulators. ALSA uses accumulators 14 and 15 for left and right side PCM +samples for 7.1 playback. The result samples are forwarded to the side speakers. name='PCM Center Playback Volume',index=0 ----------------------------------------- -This control is used to attenuate samples for center PCM FX-bus accumulator. -ALSA uses accumulator 6 for center PCM sample for 5.1 playback. The result sample -is forwarded to the center DAC PCM slot of the Philips DAC. +This control is used to attenuate samples from center PCM FX-bus accumulator. +ALSA uses accumulator 6 for center PCM samples for 5.1 playback. The result +samples are forwarded to the center speaker. name='PCM LFE Playback Volume',index=0 -------------------------------------- This control is used to attenuate sample for LFE PCM FX-bus accumulator. -ALSA uses accumulator 7 for LFE PCM sample for 5.1 playback. The result sample -is forwarded to the LFE DAC PCM slot of the Philips DAC. +ALSA uses accumulator 7 for LFE PCM samples for 5.1 playback. The result +samples are forwarded to the subwoofer. name='PCM Playback Volume',index=0 ---------------------------------- -This control is used to attenuate samples for left and right PCM FX-bus +This control is used to attenuate samples from left and right PCM FX-bus accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples for -stereo playback. The result samples are forwarded to the front DAC PCM slots -of the Philips DAC. +stereo playback. The result samples are forwarded to the front speakers. name='PCM Capture Volume',index=0 --------------------------------- -This control is used to attenuate samples for left and right PCM FX-bus -accumulator. ALSA uses accumulators 0 and 1 for left and right PCM. -The result is forwarded to the ADC capture FIFO (thus to the standard capture -PCM device). +This control is used to attenuate samples from left and right PCM FX-bus +accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples for +stereo playback. The result is forwarded to the standard capture PCM device. name='Music Playback Volume',index=0 ------------------------------------ -This control is used to attenuate samples for left and right MIDI FX-bus +This control is used to attenuate samples from left and right MIDI FX-bus accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples. -The result samples are forwarded to the front DAC PCM slots of the AC97 codec. +The result samples are forwarded to the virtual stereo mixer. name='Music Capture Volume',index=0 ----------------------------------- -These controls are used to attenuate samples for left and right MIDI FX-bus -accumulator. ALSA uses accumulators 4 and 5 for left and right PCM. -The result is forwarded to the ADC capture FIFO (thus to the standard capture -PCM device). +These controls are used to attenuate samples from left and right MIDI FX-bus +accumulator. ALSA uses accumulators 4 and 5 for left and right MIDI samples. +The result is forwarded to the standard capture PCM device. name='Mic Playback Volume',index=0 ---------------------------------- -This control is used to attenuate samples for left and right Mic input. -For Mic input is used AC97 codec. The result samples are forwarded to -the front DAC PCM slots of the Philips DAC. Samples are forwarded to Mic -capture FIFO (device 1 - 16bit/8KHz mono) too without volume control. +This control is used to attenuate samples from left and right Mic input of +the AC97 codec. The result samples are forwarded to the virtual stereo mixer. name='Mic Capture Volume',index=0 --------------------------------- -This control is used to attenuate samples for left and right Mic input. -The result is forwarded to the ADC capture FIFO (thus to the standard capture -PCM device). +This control is used to attenuate samples from left and right Mic input of +the AC97 codec. The result is forwarded to the standard capture PCM device. + +The original samples are also forwarded to the Mic capture PCM device (device 1; +16bit/8KHz mono) without volume control. name='Audigy CD Playback Volume',index=0 ---------------------------------------- This control is used to attenuate samples from left and right IEC958 TTL digital inputs (usually used by a CDROM drive). The result samples are -forwarded to the front DAC PCM slots of the Philips DAC. +forwarded to the virtual stereo mixer. name='Audigy CD Capture Volume',index=0 --------------------------------------- This control is used to attenuate samples from left and right IEC958 TTL -digital inputs (usually used by a CDROM drive). The result samples are -forwarded to the ADC capture FIFO (thus to the standard capture PCM device). +digital inputs (usually used by a CDROM drive). The result is forwarded +to the standard capture PCM device. name='IEC958 Optical Playback Volume',index=0 --------------------------------------------- This control is used to attenuate samples from left and right IEC958 optical -digital input. The result samples are forwarded to the front DAC PCM slots -of the Philips DAC. +digital input. The result samples are forwarded to the virtual stereo mixer. name='IEC958 Optical Capture Volume',index=0 -------------------------------------------- This control is used to attenuate samples from left and right IEC958 optical -digital inputs. The result samples are forwarded to the ADC capture FIFO -(thus to the standard capture PCM device). +digital inputs. The result is forwarded to the standard capture PCM device. name='Line2 Playback Volume',index=0 ------------------------------------ This control is used to attenuate samples from left and right I2S ADC -inputs (on the AudigyDrive). The result samples are forwarded to the front -DAC PCM slots of the Philips DAC. +inputs (on the AudigyDrive). The result samples are forwarded to the virtual +stereo mixer. name='Line2 Capture Volume',index=1 ----------------------------------- This control is used to attenuate samples from left and right I2S ADC -inputs (on the AudigyDrive). The result samples are forwarded to the ADC -capture FIFO (thus to the standard capture PCM device). +inputs (on the AudigyDrive). The result is forwarded to the standard capture +PCM device. name='Analog Mix Playback Volume',index=0 ----------------------------------------- This control is used to attenuate samples from left and right I2S ADC -inputs from Philips ADC. The result samples are forwarded to the front -DAC PCM slots of the Philips DAC. This contains mix from analog sources -like CD, Line In, Aux, .... +inputs from Philips ADC. The result samples are forwarded to the virtual +stereo mixer. This contains mix from analog sources like CD, Line In, Aux, .... name='Analog Mix Capture Volume',index=1 ---------------------------------------- This control is used to attenuate samples from left and right I2S ADC -inputs Philips ADC. The result samples are forwarded to the ADC -capture FIFO (thus to the standard capture PCM device). +inputs Philips ADC. The result is forwarded to the standard capture PCM device. name='Aux2 Playback Volume',index=0 ----------------------------------- This control is used to attenuate samples from left and right I2S ADC -inputs (on the AudigyDrive). The result samples are forwarded to the front -DAC PCM slots of the Philips DAC. +inputs (on the AudigyDrive). The result samples are forwarded to the virtual +stereo mixer. name='Aux2 Capture Volume',index=1 ---------------------------------- This control is used to attenuate samples from left and right I2S ADC -inputs (on the AudigyDrive). The result samples are forwarded to the ADC -capture FIFO (thus to the standard capture PCM device). +inputs (on the AudigyDrive). The result is forwarded to the standard capture +PCM device. name='Front Playback Volume',index=0 ------------------------------------ -All stereo signals are mixed together and mirrored to surround, center and LFE. -This control is used to attenuate samples for left and right front speakers of -this mix. +This control is used to attenuate samples from the virtual stereo mixer. +The result samples are forwarded to the front speakers. name='Surround Playback Volume',index=0 --------------------------------------- -All stereo signals are mixed together and mirrored to surround, center and LFE. -This control is used to attenuate samples for left and right surround speakers of -this mix. +This control is used to attenuate samples from the virtual stereo mixer. +The result samples are forwarded to the surround (rear) speakers. + +name='Side Playback Volume',index=0 +----------------------------------- +This control is used to attenuate samples from the virtual stereo mixer. +The result samples are forwarded to the side speakers. name='Center Playback Volume',index=0 ------------------------------------- -All stereo signals are mixed together and mirrored to surround, center and LFE. -This control is used to attenuate sample for center speaker of this mix. +This control is used to attenuate samples from the virtual stereo mixer. +The result samples are forwarded to the center speaker. name='LFE Playback Volume',index=0 ---------------------------------- -All stereo signals are mixed together and mirrored to surround, center and LFE. -This control is used to attenuate sample for LFE speaker of this mix. +This control is used to attenuate samples from the virtual stereo mixer. +The result samples are forwarded to the subwoofer. name='Tone Control - Switch',index=0 ------------------------------------ -This control turns the tone control on or off. The samples for front, rear -and center / LFE outputs are affected. +This control turns the tone control on or off. The samples forwarded to +the speaker outputs are affected. name='Tone Control - Bass',index=0 ---------------------------------- @@ -212,8 +213,7 @@ The closest value to pure signal is 20. name='Master Playback Volume',index=0 ------------------------------------- -This control is used to attenuate samples for front, surround, center and -LFE outputs. +This control is used to attenuate samples forwarded to the speaker outputs. name='IEC958 Optical Raw Playback Switch',index=0 ------------------------------------------------- @@ -227,7 +227,7 @@ PCM stream related controls name='EMU10K1 PCM Volume',index 0-31 ------------------------------------ -Channel volume attenuation in range 0-0xffff. The maximum value (no +Channel volume attenuation in range 0-0x1fffd. The middle value (no attenuation) is default. The channel mapping for three values is as follows: @@ -240,30 +240,30 @@ name='EMU10K1 PCM Send Routing',index 0-31 This control specifies the destination - FX-bus accumulators. There are 24 values in this mapping: -* 0 - mono, A destination (FX-bus 0-63), default 0 -* 1 - mono, B destination (FX-bus 0-63), default 1 -* 2 - mono, C destination (FX-bus 0-63), default 2 -* 3 - mono, D destination (FX-bus 0-63), default 3 -* 4 - mono, E destination (FX-bus 0-63), default 0 -* 5 - mono, F destination (FX-bus 0-63), default 0 -* 6 - mono, G destination (FX-bus 0-63), default 0 -* 7 - mono, H destination (FX-bus 0-63), default 0 -* 8 - left, A destination (FX-bus 0-63), default 0 -* 9 - left, B destination (FX-bus 0-63), default 1 +* 0 - mono, A destination (FX-bus 0-63), default 0 +* 1 - mono, B destination (FX-bus 0-63), default 1 +* 2 - mono, C destination (FX-bus 0-63), default 2 +* 3 - mono, D destination (FX-bus 0-63), default 3 +* 4 - mono, E destination (FX-bus 0-63), default 4 +* 5 - mono, F destination (FX-bus 0-63), default 5 +* 6 - mono, G destination (FX-bus 0-63), default 6 +* 7 - mono, H destination (FX-bus 0-63), default 7 +* 8 - left, A destination (FX-bus 0-63), default 0 +* 9 - left, B destination (FX-bus 0-63), default 1 * 10 - left, C destination (FX-bus 0-63), default 2 * 11 - left, D destination (FX-bus 0-63), default 3 -* 12 - left, E destination (FX-bus 0-63), default 0 -* 13 - left, F destination (FX-bus 0-63), default 0 -* 14 - left, G destination (FX-bus 0-63), default 0 -* 15 - left, H destination (FX-bus 0-63), default 0 +* 12 - left, E destination (FX-bus 0-63), default 4 +* 13 - left, F destination (FX-bus 0-63), default 5 +* 14 - left, G destination (FX-bus 0-63), default 6 +* 15 - left, H destination (FX-bus 0-63), default 7 * 16 - right, A destination (FX-bus 0-63), default 0 * 17 - right, B destination (FX-bus 0-63), default 1 * 18 - right, C destination (FX-bus 0-63), default 2 * 19 - right, D destination (FX-bus 0-63), default 3 -* 20 - right, E destination (FX-bus 0-63), default 0 -* 21 - right, F destination (FX-bus 0-63), default 0 -* 22 - right, G destination (FX-bus 0-63), default 0 -* 23 - right, H destination (FX-bus 0-63), default 0 +* 20 - right, E destination (FX-bus 0-63), default 4 +* 21 - right, F destination (FX-bus 0-63), default 5 +* 22 - right, G destination (FX-bus 0-63), default 6 +* 23 - right, H destination (FX-bus 0-63), default 7 Don't forget that it's illegal to assign a channel to the same FX-bus accumulator more than once (it means 0=0 && 1=0 is an invalid combination). @@ -303,69 +303,4 @@ The channel mapping is following: MANUALS/PATENTS =============== -ftp://opensource.creative.com/pub/doc -------------------------------------- - -Note that the site is defunct, but the documents are available -from various other locations. - -LM4545.pdf - AC97 Codec - -m2049.pdf - The EMU10K1 Digital Audio Processor - -hog63.ps - FX8010 - A DSP Chip Architecture for Audio Effects - - -WIPO Patents ------------- - -WO 9901813 (A1) - Audio Effects Processor with multiple asynchronous streams - (Jan. 14, 1999) - -WO 9901814 (A1) - Processor with Instruction Set for Audio Effects (Jan. 14, 1999) - -WO 9901953 (A1) - Audio Effects Processor having Decoupled Instruction - Execution and Audio Data Sequencing (Jan. 14, 1999) - - -US Patents (https://www.uspto.gov/) ------------------------------------ - -US 5925841 - Digital Sampling Instrument employing cache memory (Jul. 20, 1999) - -US 5928342 - Audio Effects Processor integrated on a single chip - with a multiport memory onto which multiple asynchronous - digital sound samples can be concurrently loaded - (Jul. 27, 1999) - -US 5930158 - Processor with Instruction Set for Audio Effects (Jul. 27, 1999) - -US 6032235 - Memory initialization circuit (Tram) (Feb. 29, 2000) - -US 6138207 - Interpolation looping of audio samples in cache connected to - system bus with prioritization and modification of bus transfers - in accordance with loop ends and minimum block sizes - (Oct. 24, 2000) - -US 6151670 - Method for conserving memory storage using a - pool of short term memory registers - (Nov. 21, 2000) - -US 6195715 - Interrupt control for multiple programs communicating with - a common interrupt by associating programs to GP registers, - defining interrupt register, polling GP registers, and invoking - callback routine associated with defined interrupt register - (Feb. 27, 2001) +See sb-live-mixer.rst. diff --git a/Documentation/sound/cards/emu-mixer.rst b/Documentation/sound/cards/emu-mixer.rst new file mode 100644 index 000000000000..d87a6338d3d8 --- /dev/null +++ b/Documentation/sound/cards/emu-mixer.rst @@ -0,0 +1,226 @@ +================================================== +E-MU Digital Audio System mixer / default DSP code +================================================== + +This document covers the E-MU 0404/1010/1212/1616/1820 PCI/PCI-e/CardBus +cards. + +These cards use regular EMU10K2 (SoundBlaster Audigy) chips, but with an +alternative front-end geared towards semi-professional studio recording. + +This document is based on audigy-mixer.rst. + + +Hardware compatibility +====================== + +The EMU10K2 chips have a very short capture FIFO, which makes recording +unreliable if the card's PCI bus requests are not handled with the +appropriate priority. +This is the case on more modern motherboards, where the PCI bus is only a +secondary peripheral, rather than the actual arbiter of device access. +In particular, I got recording glitches during simultaneous playback on an +Intel DP55 board (memory controller in the CPU), but had success with an +Intel DP45 board (memory controller in the north bridge). + +The PCI Express variants of these cards (which have a PCI bridge on board, +but are otherwise identical) may be less problematic. + + +Driver capabilities +=================== + +This driver supports only 16-bit 44.1/48 kHz operation. The multi-channel +device (see emu10k1-jack.rst) additionally supports 24-bit capture. + +A patchset to enhance the driver is available from `a GitHub repository +<https://github.com/ossilator/linux/tree/ossis-emu10k1>`_. +Its multi-channel device supports 24-bit for both playback and capture, +and also supports full 88.2/96/176.4/192 kHz operation. +It is not going to be upstreamed due to a fundamental disagreement about +what constitutes a good user experience. + + +Digital mixer controls +====================== + +Note that the controls work as attenuators: the maximum value is the neutral +position leaving the signal unchanged. Note that if the same destination is +mentioned in multiple controls, the signal is accumulated and can be clipped +(set to maximal or minimal value without checking for overflow). + +Explanation of used abbreviations: + +DAC + digital to analog converter +ADC + analog to digital converter +LFE + low frequency effects (used as subwoofer signal) +IEC958 + S/PDIF +FX-bus + the EMU10K2 chip has an effect bus containing 64 accumulators. + Each of the synthesizer voices can feed its output to these accumulators + and the DSP microcontroller can operate with the resulting sum. + +name='Clock Source',index=0 +--------------------------- +This control allows switching the word clock between interally generated +44.1 or 48 kHz, or a number of external sources. + +Note: the sources for the 1616 CardBus card are unclear. Please report your +findings. + +name='Clock Fallback',index=0 +----------------------------- +This control determines the internal clock which the card switches to when +the selected external clock source is/becomes invalid. + +name='DAC1 0202 14dB PAD',index=0, etc. +--------------------------------------- +Output attenuation controls. Not available on 0404 cards. + +name='ADC1 14dB PAD 0202',index=0, etc. +--------------------------------------- +Input attenuation controls. Not available on 0404 cards. + +name='Optical Output Mode',index=0 +---------------------------------- +Switches the TOSLINK output port between S/PDIF and ADAT. +Not available on 0404 cards (fixed to S/PDIF). + +name='Optical Input Mode',index=0 +--------------------------------- +Switches the TOSLINK input port between S/PDIF and ADAT. +Not available on 0404 cards (fixed to S/PDIF). + +name='PCM Front Playback Volume',index=0 +---------------------------------------- +This control is used to attenuate samples from left and right front PCM FX-bus +accumulators. ALSA uses accumulators 8 and 9 for left and right front PCM +samples for 5.1 playback. The result samples are forwarded to the DSP 0 & 1 +playback channels. + +name='PCM Surround Playback Volume',index=0 +------------------------------------------- +This control is used to attenuate samples from left and right surround PCM FX-bus +accumulators. ALSA uses accumulators 2 and 3 for left and right surround PCM +samples for 5.1 playback. The result samples are forwarded to the DSP 2 & 3 +playback channels. + +name='PCM Side Playback Volume',index=0 +--------------------------------------- +This control is used to attenuate samples from left and right side PCM FX-bus +accumulators. ALSA uses accumulators 14 and 15 for left and right side PCM +samples for 7.1 playback. The result samples are forwarded to the DSP 6 & 7 +playback channels. + +name='PCM Center Playback Volume',index=0 +----------------------------------------- +This control is used to attenuate samples from the center PCM FX-bus accumulator. +ALSA uses accumulator 6 for center PCM samples for 5.1 playback. The result samples +are forwarded to the DSP 4 playback channel. + +name='PCM LFE Playback Volume',index=0 +-------------------------------------- +This control is used to attenuate samples from the LFE PCM FX-bus accumulator. +ALSA uses accumulator 7 for LFE PCM samples for 5.1 playback. The result samples +are forwarded to the DSP 5 playback channel. + +name='PCM Playback Volume',index=0 +---------------------------------- +This control is used to attenuate samples from left and right PCM FX-bus +accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples for +stereo playback. The result samples are forwarded to the virtual stereo mixer. + +name='PCM Capture Volume',index=0 +--------------------------------- +This control is used to attenuate samples from left and right PCM FX-bus +accumulators. ALSA uses accumulators 0 and 1 for left and right PCM. +The result is forwarded to the standard capture PCM device. + +name='Music Playback Volume',index=0 +------------------------------------ +This control is used to attenuate samples from left and right MIDI FX-bus +accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples. +The result samples are forwarded to the virtual stereo mixer. + +name='Music Capture Volume',index=0 +----------------------------------- +These controls are used to attenuate samples from left and right MIDI FX-bus +accumulator. ALSA uses accumulators 4 and 5 for left and right MIDI samples. +The result is forwarded to the standard capture PCM device. + +name='Front Playback Volume',index=0 +------------------------------------ +This control is used to attenuate samples from the virtual stereo mixer. +The result samples are forwarded to the DSP 0 & 1 playback channels. + +name='Surround Playback Volume',index=0 +--------------------------------------- +This control is used to attenuate samples from the virtual stereo mixer. +The result samples are forwarded to the DSP 2 & 3 playback channels. + +name='Side Playback Volume',index=0 +----------------------------------- +This control is used to attenuate samples from the virtual stereo mixer. +The result samples are forwarded to the DSP 6 & 7 playback channels. + +name='Center Playback Volume',index=0 +------------------------------------- +This control is used to attenuate samples from the virtual stereo mixer. +The result samples are forwarded to the DSP 4 playback channel. + +name='LFE Playback Volume',index=0 +---------------------------------- +This control is used to attenuate samples from the virtual stereo mixer. +The result samples are forwarded to the DSP 5 playback channel. + +name='Tone Control - Switch',index=0 +------------------------------------ +This control turns the tone control on or off. The samples forwarded to +the DSP playback channels are affected. + +name='Tone Control - Bass',index=0 +---------------------------------- +This control sets the bass intensity. There is no neutral value!! +When the tone control code is activated, the samples are always modified. +The closest value to pure signal is 20. + +name='Tone Control - Treble',index=0 +------------------------------------ +This control sets the treble intensity. There is no neutral value!! +When the tone control code is activated, the samples are always modified. +The closest value to pure signal is 20. + +name='Master Playback Volume',index=0 +------------------------------------- +This control is used to attenuate samples for all DSP playback channels. + +name='EMU Capture Volume',index=0 +---------------------------------- +This control is used to attenuate samples from the DSP 0 & 1 capture channels. +The result is forwarded to the standard capture PCM device. + +name='DAC Left',index=0, etc. +----------------------------- +Select the source for the given physical audio output. These may be physical +inputs, playback channels (DSP xx, specified as a decimal number), or silence. + +name='DSP x',index=0 +-------------------- +Select the source for the given capture channel (specified as a hexadecimal +digit). Same options as for the physical audio outputs. + + +PCM stream related controls +=========================== + +These controls are described in audigy-mixer.rst. + + +MANUALS/PATENTS +=============== + +See sb-live-mixer.rst. diff --git a/Documentation/sound/cards/index.rst b/Documentation/sound/cards/index.rst index c016f8c3b88b..e68bbb13c384 100644 --- a/Documentation/sound/cards/index.rst +++ b/Documentation/sound/cards/index.rst @@ -8,6 +8,7 @@ Card-Specific Information cmipci sb-live-mixer audigy-mixer + emu-mixer emu10k1-jack via82xx-mixer audiophile-usb @@ -17,3 +18,4 @@ Card-Specific Information hdspm serial-u16550 img-spdif-in + pcmtest diff --git a/Documentation/sound/cards/pcmtest.rst b/Documentation/sound/cards/pcmtest.rst new file mode 100644 index 000000000000..e163522f3205 --- /dev/null +++ b/Documentation/sound/cards/pcmtest.rst @@ -0,0 +1,120 @@ +.. SPDX-License-Identifier: GPL-2.0 + +The Virtual PCM Test Driver +=========================== + +The Virtual PCM Test Driver emulates a generic PCM device, and can be used for +testing/fuzzing of the userspace ALSA applications, as well as for testing/fuzzing of +the PCM middle layer. Additionally, it can be used for simulating hard to reproduce +problems with PCM devices. + +What can this driver do? +~~~~~~~~~~~~~~~~~~~~~~~~ + +At this moment the driver can do the following things: + * Simulate both capture and playback processes + * Generate random or pattern-based capturing data + * Inject delays into the playback and capturing processes + * Inject errors during the PCM callbacks + +It supports up to 8 substreams and 4 channels. Also it supports both interleaved and +non-interleaved access modes. + +Also, this driver can check the playback stream for containing the predefined pattern, +which is used in the corresponding selftest (alsa/pcmtest-test.sh) to check the PCM middle +layer data transferring functionality. Additionally, this driver redefines the default +RESET ioctl, and the selftest covers this PCM API functionality as well. + +Configuration +------------- + +The driver has several parameters besides the common ALSA module parameters: + + * fill_mode (bool) - Buffer fill mode (see below) + * inject_delay (int) + * inject_hwpars_err (bool) + * inject_prepare_err (bool) + * inject_trigger_err (bool) + + +Capture Data Generation +----------------------- + +The driver has two modes of data generation: the first (0 in the fill_mode parameter) +means random data generation, the second (1 in the fill_mode) - pattern-based +data generation. Let's look at the second mode. + +First of all, you may want to specify the pattern for data generation. You can do it +by writing the pattern to the debugfs file. There are pattern buffer debugfs entries +for each channel, as well as entries which contain the pattern buffer length. + + * /sys/kernel/debug/pcmtest/fill_pattern[0-3] + * /sys/kernel/debug/pcmtest/fill_pattern[0-3]_len + +To set the pattern for the channel 0 you can execute the following command: + +.. code-block:: bash + + echo -n mycoolpattern > /sys/kernel/debug/pcmtest/fill_pattern0 + +Then, after every capture action performed on the 'pcmtest' device the buffer for the +channel 0 will contain 'mycoolpatternmycoolpatternmycoolpatternmy...'. + +The pattern itself can be up to 4096 bytes long. + +Delay injection +--------------- + +The driver has 'inject_delay' parameter, which has very self-descriptive name and +can be used for time delay/speedup simulations. The parameter has integer type, and +it means the delay added between module's internal timer ticks. + +If the 'inject_delay' value is positive, the buffer will be filled slower, if it is +negative - faster. You can try it yourself by starting a recording in any +audiorecording application (like Audacity) and selecting the 'pcmtest' device as a +source. + +This parameter can be also used for generating a huge amount of sound data in a very +short period of time (with the negative 'inject_delay' value). + +Errors injection +---------------- + +This module can be used for injecting errors into the PCM communication process. This +action can help you to figure out how the userspace ALSA program behaves under unusual +circumstances. + +For example, you can make all 'hw_params' PCM callback calls return EBUSY error by +writing '1' to the 'inject_hwpars_err' module parameter: + +.. code-block:: bash + + echo 1 > /sys/module/snd_pcmtest/parameters/inject_hwpars_err + +Errors can be injected into the following PCM callbacks: + + * hw_params (EBUSY) + * prepare (EINVAL) + * trigger (EINVAL) + +Playback test +------------- + +This driver can be also used for the playback functionality testing - every time you +write the playback data to the 'pcmtest' PCM device and close it, the driver checks the +buffer for containing the looped pattern (which is specified in the fill_pattern +debugfs file for each channel). If the playback buffer content represents the looped +pattern, 'pc_test' debugfs entry is set into '1'. Otherwise, the driver sets it to '0'. + +ioctl redefinition test +----------------------- + +The driver redefines the 'reset' ioctl, which is default for all PCM devices. To test +this functionality, we can trigger the reset ioctl and check the 'ioctl_test' debugfs +entry: + +.. code-block:: bash + + cat /sys/kernel/debug/pcmtest/ioctl_test + +If the ioctl is triggered successfully, this file will contain '1', and '0' otherwise. diff --git a/Documentation/sound/cards/sb-live-mixer.rst b/Documentation/sound/cards/sb-live-mixer.rst index 819886634400..27667f58aae1 100644 --- a/Documentation/sound/cards/sb-live-mixer.rst +++ b/Documentation/sound/cards/sb-live-mixer.rst @@ -61,61 +61,61 @@ FX-bus ``name='Wave Playback Volume',index=0`` --------------------------------------- -This control is used to attenuate samples for left and right PCM FX-bus +This control is used to attenuate samples from left and right PCM FX-bus accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples. The result samples are forwarded to the front DAC PCM slots of the AC97 codec. ``name='Wave Surround Playback Volume',index=0`` ------------------------------------------------ -This control is used to attenuate samples for left and right PCM FX-bus +This control is used to attenuate samples from left and right PCM FX-bus accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples. The result samples are forwarded to the rear I2S DACs. These DACs operates separately (they are not inside the AC97 codec). ``name='Wave Center Playback Volume',index=0`` ---------------------------------------------- -This control is used to attenuate samples for left and right PCM FX-bus +This control is used to attenuate samples from left and right PCM FX-bus accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples. The result is mixed to mono signal (single channel) and forwarded to the ??rear?? right DAC PCM slot of the AC97 codec. ``name='Wave LFE Playback Volume',index=0`` ------------------------------------------- -This control is used to attenuate samples for left and right PCM FX-bus +This control is used to attenuate samples from left and right PCM FX-bus accumulators. ALSA uses accumulators 0 and 1 for left and right PCM. The result is mixed to mono signal (single channel) and forwarded to the ??rear?? left DAC PCM slot of the AC97 codec. ``name='Wave Capture Volume',index=0``, ``name='Wave Capture Switch',index=0`` ------------------------------------------------------------------------------ -These controls are used to attenuate samples for left and right PCM FX-bus +These controls are used to attenuate samples from left and right PCM FX-bus accumulator. ALSA uses accumulators 0 and 1 for left and right PCM. The result is forwarded to the ADC capture FIFO (thus to the standard capture PCM device). ``name='Synth Playback Volume',index=0`` ---------------------------------------- -This control is used to attenuate samples for left and right MIDI FX-bus +This control is used to attenuate samples from left and right MIDI FX-bus accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples. The result samples are forwarded to the front DAC PCM slots of the AC97 codec. ``name='Synth Capture Volume',index=0``, ``name='Synth Capture Switch',index=0`` -------------------------------------------------------------------------------- -These controls are used to attenuate samples for left and right MIDI FX-bus -accumulator. ALSA uses accumulators 4 and 5 for left and right PCM. +These controls are used to attenuate samples from left and right MIDI FX-bus +accumulator. ALSA uses accumulators 4 and 5 for left and right MIDI samples. The result is forwarded to the ADC capture FIFO (thus to the standard capture PCM device). ``name='Surround Playback Volume',index=0`` ------------------------------------------- -This control is used to attenuate samples for left and right rear PCM FX-bus +This control is used to attenuate samples from left and right rear PCM FX-bus accumulators. ALSA uses accumulators 2 and 3 for left and right rear PCM samples. The result samples are forwarded to the rear I2S DACs. These DACs operate separately (they are not inside the AC97 codec). ``name='Surround Capture Volume',index=0``, ``name='Surround Capture Switch',index=0`` -------------------------------------------------------------------------------------- -These controls are used to attenuate samples for left and right rear PCM FX-bus +These controls are used to attenuate samples from left and right rear PCM FX-bus accumulators. ALSA uses accumulators 2 and 3 for left and right rear PCM samples. The result is forwarded to the ADC capture FIFO (thus to the standard capture PCM device). @@ -134,7 +134,7 @@ to the ??rear?? left DAC PCM slot of the AC97 codec. ``name='AC97 Playback Volume',index=0`` --------------------------------------- -This control is used to attenuate samples for left and right front ADC PCM slots +This control is used to attenuate samples from left and right front ADC PCM slots of the AC97 codec. The result samples are forwarded to the front DAC PCM slots of the AC97 codec. @@ -145,7 +145,7 @@ slots of the AC97 codec. ``name='AC97 Capture Volume',index=0`` -------------------------------------- -This control is used to attenuate samples for left and right front ADC PCM slots +This control is used to attenuate samples from left and right front ADC PCM slots of the AC97 codec. The result is forwarded to the ADC capture FIFO (thus to the standard capture PCM device). @@ -258,7 +258,7 @@ PCM stream related controls ``name='EMU10K1 PCM Volume',index 0-31`` ---------------------------------------- -Channel volume attenuation in range 0-0xffff. The maximum value (no +Channel volume attenuation in range 0-0x1fffd. The middle value (no attenuation) is default. The channel mapping for three values is as follows: diff --git a/Documentation/sound/designs/compress-offload.rst b/Documentation/sound/designs/compress-offload.rst index 935f325dbc77..655624f77092 100644 --- a/Documentation/sound/designs/compress-offload.rst +++ b/Documentation/sound/designs/compress-offload.rst @@ -268,11 +268,12 @@ with setting of meta_data and signalling for next track :: | | | V | +----------+ - | | | - | |NEXT_TRACK| - | | | - | +----------+ - | | + | compr_set_params() | | + | +-----------|NEXT_TRACK| + | | | | + | | +--+-------+ + | | | | + | +--------------+ | | | | | compr_partial_drain() | | diff --git a/Documentation/sound/designs/index.rst b/Documentation/sound/designs/index.rst index 1eb08e7bae52..b79db9ad8732 100644 --- a/Documentation/sound/designs/index.rst +++ b/Documentation/sound/designs/index.rst @@ -15,3 +15,4 @@ Designs and Implementations oss-emulation seq-oss jack-injection + midi-2.0 diff --git a/Documentation/sound/designs/midi-2.0.rst b/Documentation/sound/designs/midi-2.0.rst new file mode 100644 index 000000000000..45987f256b97 --- /dev/null +++ b/Documentation/sound/designs/midi-2.0.rst @@ -0,0 +1,566 @@ +================= +MIDI 2.0 on Linux +================= + +General +======= + +MIDI 2.0 is an extended protocol for providing higher resolutions and +more fine controls over the legacy MIDI 1.0. The fundamental changes +introduced for supporting MIDI 2.0 are: + +- Support of Universal MIDI Packet (UMP) +- Support of MIDI 2.0 protocol messages +- Transparent conversions between UMP and legacy MIDI 1.0 byte stream +- MIDI-CI for property and profile configurations + +UMP is a new container format to hold all MIDI protocol 1.0 and MIDI +2.0 protocol messages. Unlike the former byte stream, it's 32bit +aligned, and each message can be put in a single packet. UMP can send +the events up to 16 "UMP Groups", where each UMP Group contain up to +16 MIDI channels. + +MIDI 2.0 protocol is an extended protocol to achieve the higher +resolution and more controls over the old MIDI 1.0 protocol. + +MIDI-CI is a high-level protocol that can talk with the MIDI device +for the flexible profiles and configurations. It's represented in the +form of special SysEx. + +For Linux implementations, the kernel supports the UMP transport and +the encoding/decoding of MIDI protocols on UMP, while MIDI-CI is +supported in user-space over the standard SysEx. + +As of this writing, only USB MIDI device supports the UMP and Linux +2.0 natively. The UMP support itself is pretty generic, hence it +could be used by other transport layers, although it could be +implemented differently (e.g. as a ALSA sequencer client), too. + +The access to UMP devices are provided in two ways: the access via +rawmidi device and the access via ALSA sequencer API. + +ALSA sequencer API was extended to allow the payload of UMP packets. +It's allowed to connect freely between MIDI 1.0 and MIDI 2.0 sequencer +clients, and the events are converted transparently. + + +Kernel Configuration +==================== + +The following new configs are added for supporting MIDI 2.0: +`CONFIG_SND_UMP`, `CONFIG_SND_UMP_LEGACY_RAWMIDI`, +`CONFIG_SND_SEQ_UMP`, `CONFIG_SND_SEQ_UMP_CLIENT`, and +`CONFIG_SND_USB_AUDIO_MIDI_V2`. The first visible one is +`CONFIG_SND_USB_AUDIO_MIDI_V2`, and when you choose it (to set `=y`), +the core support for UMP (`CONFIG_SND_UMP`) and the sequencer binding +(`CONFIG_SND_SEQ_UMP_CLIENT`) will be automatically selected. + +Additionally, `CONFIG_SND_UMP_LEGACY_RAWMIDI=y` will enable the +support for the legacy raw MIDI device for UMP Endpoints. + + +Rawmidi Device with USB MIDI 2.0 +================================ + +When a device supports MIDI 2.0, the USB-audio driver probes and uses +the MIDI 2.0 interface (that is found always at the altset 1) as +default instead of the MIDI 1.0 interface (at altset 0). You can +switch back to the binding with the old MIDI 1.0 interface by passing +`midi2_enable=0` option to snd-usb-audio driver module, too. + +The USB audio driver tries to query the UMP Endpoint and UMP Function +Block information that are provided since UMP v1.1, and builds up the +topology based on those information. When the device is older and +doesn't respond to the new UMP inquiries, the driver falls back and +builds the topology based on Group Terminal Block (GTB) information +from the USB descriptor. Some device might be screwed up by the +unexpected UMP command; in such a case, pass `midi2_probe=0` option to +snd-usb-audio driver for skipping the UMP v1.1 inquiries. + +When the MIDI 2.0 device is probed, the kernel creates a rawmidi +device for each UMP Endpoint of the device. Its device name is +`/dev/snd/umpC*D*` and different from the standard rawmidi device name +`/dev/snd/midiC*D*` for MIDI 1.0, in order to avoid confusing the +legacy applications accessing mistakenly to UMP devices. + +You can read and write UMP packet data directly from/to this UMP +rawmidi device. For example, reading via `hexdump` like below will +show the incoming UMP packets of the card 0 device 0 in the hex +format:: + + % hexdump -C /dev/snd/umpC0D0 + 00000000 01 07 b0 20 00 07 b0 20 64 3c 90 20 64 3c 80 20 |... ... d<. d<. | + +Unlike the MIDI 1.0 byte stream, UMP is a 32bit packet, and the size +for reading or writing the device is also aligned to 32bit (which is 4 +bytes). + +The 32-bit words in the UMP packet payload are always in CPU native +endianness. Transport drivers are responsible to convert UMP words +from / to system endianness to required transport endianness / byte +order. + +When `CONFIG_SND_UMP_LEGACY_RAWMIDI` is set, the driver creates +another standard raw MIDI device additionally as `/dev/snd/midiC*D*`. +This contains 16 substreams, and each substream corresponds to a +(0-based) UMP Group. Legacy applications can access to the specified +group via each substream in MIDI 1.0 byte stream format. With the +ALSA rawmidi API, you can open the arbitrary substream, while just +opening `/dev/snd/midiC*D*` will end up with opening the first +substream. + +Each UMP Endpoint can provide the additional information, constructed +from the information inquired via UMP 1.1 Stream messages or USB MIDI +2.0 descriptors. And a UMP Endpoint may contain one or more UMP +Blocks, where UMP Block is an abstraction introduced in the ALSA UMP +implementations to represent the associations among UMP Groups. UMP +Block corresponds to Function Block in UMP 1.1 specification. When +UMP 1.1 Function Block information isn't available, it's filled +partially from Group Terminal Block (GTB) as defined in USB MIDI 2.0 +specifications. + +The information of UMP Endpoints and UMP Blocks are found in the proc +file `/proc/asound/card*/midi*`. For example:: + + % cat /proc/asound/card1/midi0 + ProtoZOA MIDI + + Type: UMP + EP Name: ProtoZOA + EP Product ID: ABCD12345678 + UMP Version: 0x0000 + Protocol Caps: 0x00000100 + Protocol: 0x00000100 + Num Blocks: 3 + + Block 0 (ProtoZOA Main) + Direction: bidirection + Active: Yes + Groups: 1-1 + Is MIDI1: No + + Block 1 (ProtoZOA Ext IN) + Direction: output + Active: Yes + Groups: 2-2 + Is MIDI1: Yes (Low Speed) + .... + +Note that `Groups` field shown in the proc file above indicates the +1-based UMP Group numbers (from-to). + +Those additional UMP Endpoint and UMP Block information can be +obtained via the new ioctls `SNDRV_UMP_IOCTL_ENDPOINT_INFO` and +`SNDRV_UMP_IOCTL_BLOCK_INFO`, respectively. + +The rawmidi name and the UMP Endpoint name are usually identical, and +in the case of USB MIDI, it's taken from `iInterface` of the +corresponding USB MIDI interface descriptor. If it's not provided, +it's copied from `iProduct` of the USB device descriptor as a +fallback. + +The Endpoint Product ID is a string field and supposed to be unique. +It's copied from `iSerialNumber` of the device for USB MIDI. + +The protocol capabilities and the actual protocol bits are defined in +`asound.h`. + + +ALSA Sequencer with USB MIDI 2.0 +================================ + +In addition to the rawmidi interfaces, ALSA sequencer interface +supports the new UMP MIDI 2.0 device, too. Now, each ALSA sequencer +client may set its MIDI version (0, 1 or 2) to declare itself being +either the legacy, UMP MIDI 1.0 or UMP MIDI 2.0 device, respectively. +The first, legacy client is the one that sends/receives the old +sequencer event as was. Meanwhile, UMP MIDI 1.0 and 2.0 clients send +and receive in the extended event record for UMP. The MIDI version is +seen in the new `midi_version` field of `snd_seq_client_info`. + +A UMP packet can be sent/received in a sequencer event embedded by +specifying the new event flag bit `SNDRV_SEQ_EVENT_UMP`. When this +flag is set, the event has 16 byte (128 bit) data payload for holding +the UMP packet. Without the `SNDRV_SEQ_EVENT_UMP` bit flag, the event +is treated as a legacy event as it was (with max 12 byte data +payload). + +With `SNDRV_SEQ_EVENT_UMP` flag set, the type field of a UMP sequencer +event is ignored (but it should be set to 0 as default). + +The type of each client can be seen in `/proc/asound/seq/clients`. +For example:: + + % cat /proc/asound/seq/clients + Client info + cur clients : 3 + .... + Client 14 : "Midi Through" [Kernel Legacy] + Port 0 : "Midi Through Port-0" (RWe-) + Client 20 : "ProtoZOA" [Kernel UMP MIDI1] + UMP Endpoint: ProtoZOA + UMP Block 0: ProtoZOA Main [Active] + Groups: 1-1 + UMP Block 1: ProtoZOA Ext IN [Active] + Groups: 2-2 + UMP Block 2: ProtoZOA Ext OUT [Active] + Groups: 3-3 + Port 0 : "MIDI 2.0" (RWeX) [In/Out] + Port 1 : "ProtoZOA Main" (RWeX) [In/Out] + Port 2 : "ProtoZOA Ext IN" (-We-) [Out] + Port 3 : "ProtoZOA Ext OUT" (R-e-) [In] + +Here you can find two types of kernel clients, "Legacy" for client 14, +and "UMP MIDI1" for client 20, which is a USB MIDI 2.0 device. +A USB MIDI 2.0 client gives always the port 0 as "MIDI 2.0" and the +rest ports from 1 for each UMP Group (e.g. port 1 for Group 1). +In this example, the device has three active groups (Main, Ext IN and +Ext OUT), and those are exposed as sequencer ports from 1 to 3. +The "MIDI 2.0" port is for a UMP Endpoint, and its difference from +other UMP Group ports is that UMP Endpoint port sends the events from +the all ports on the device ("catch-all"), while each UMP Group port +sends only the events from the given UMP Group. +Also, UMP groupless messages (such as the UMP message type 0x0f) are +sent only to the UMP Endpoint port. + +Note that, although each UMP sequencer client usually creates 16 +ports, those ports that don't belong to any UMP Blocks (or belonging +to inactive UMP Blocks) are marked as inactive, and they don't appear +in the proc outputs. In the example above, the sequencer ports from 4 +to 16 are present but not shown there. + +The proc file above shows the UMP Block information, too. The same +entry (but with more detailed information) is found in the rawmidi +proc output. + +When clients are connected between different MIDI versions, the events +are translated automatically depending on the client's version, not +only between the legacy and the UMP MIDI 1.0/2.0 types, but also +between UMP MIDI 1.0 and 2.0 types, too. For example, running +`aseqdump` program on the ProtoZOA Main port in the legacy mode will +give you the output like:: + + % aseqdump -p 20:1 + Waiting for data. Press Ctrl+C to end. + Source Event Ch Data + 20:1 Note on 0, note 60, velocity 100 + 20:1 Note off 0, note 60, velocity 100 + 20:1 Control change 0, controller 11, value 4 + +When you run `aseqdump` in MIDI 2.0 mode, it'll receive the high +precision data like:: + + % aseqdump -u 2 -p 20:1 + Waiting for data. Press Ctrl+C to end. + Source Event Ch Data + 20:1 Note on 0, note 60, velocity 0xc924, attr type = 0, data = 0x0 + 20:1 Note off 0, note 60, velocity 0xc924, attr type = 0, data = 0x0 + 20:1 Control change 0, controller 11, value 0x2000000 + +while the data is automatically converted by ALSA sequencer core. + + +Rawmidi API Extensions +====================== + +* The additional UMP Endpoint information can be obtained via the new + ioctl `SNDRV_UMP_IOCTL_ENDPOINT_INFO`. It contains the associated + card and device numbers, the bit flags, the protocols, the number of + UMP Blocks, the name string of the endpoint, etc. + + The protocols are specified in two field, the protocol capabilities + and the current protocol. Both contain the bit flags specifying the + MIDI protocol version (`SNDRV_UMP_EP_INFO_PROTO_MIDI1` or + `SNDRV_UMP_EP_INFO_PROTO_MIDI2`) in the upper byte and the jitter + reduction timestamp (`SNDRV_UMP_EP_INFO_PROTO_JRTS_TX` and + `SNDRV_UMP_EP_INFO_PROTO_JRTS_RX`) in the lower byte. + + A UMP Endpoint may contain up to 32 UMP Blocks, and the number of + the currently assigned blocks are shown in the Endpoint information. + +* Each UMP Block information can be obtained via another new ioctl + `SNDRV_UMP_IOCTL_BLOCK_INFO`. The block ID number (0-based) has to + be passed for the block to query. The received data contains the + associated the direction of the block, the first associated group ID + (0-based) and the number of groups, the name string of the block, + etc. + + The direction is either `SNDRV_UMP_DIR_INPUT`, + `SNDRV_UMP_DIR_OUTPUT` or `SNDRV_UMP_DIR_BIDIRECTION`. + +* For the device supports UMP v1.1, the UMP MIDI protocol can be + switched via "Stream Configuration Request" message (UMP type 0x0f, + status 0x05). When UMP core receives such a message, it updates the + UMP EP info and the corresponding sequencer clients as well. + + +Control API Extensions +====================== + +* The new ioctl `SNDRV_CTL_IOCTL_UMP_NEXT_DEVICE` is introduced for + querying the next UMP rawmidi device, while the existing ioctl + `SNDRV_CTL_IOCTL_RAWMIDI_NEXT_DEVICE` queries only the legacy + rawmidi devices. + + For setting the subdevice (substream number) to be opened, use the + ioctl `SNDRV_CTL_IOCTL_RAWMIDI_PREFER_SUBDEVICE` like the normal + rawmidi. + +* Two new ioctls `SNDRV_CTL_IOCTL_UMP_ENDPOINT_INFO` and + `SNDRV_CTL_IOCTL_UMP_BLOCK_INFO` provide the UMP Endpoint and UMP + Block information of the specified UMP device via ALSA control API + without opening the actual (UMP) rawmidi device. + The `card` field is ignored upon inquiry, always tied with the card + of the control interface. + + +Sequencer API Extensions +======================== + +* `midi_version` field is added to `snd_seq_client_info` to indicate + the current MIDI version (either 0, 1 or 2) of each client. + When `midi_version` is 1 or 2, the alignment of read from a UMP + sequencer client is also changed from the former 28 bytes to 32 + bytes for the extended payload. The alignment size for the write + isn't changed, but each event size may differ depending on the new + bit flag below. + +* `SNDRV_SEQ_EVENT_UMP` flag bit is added for each sequencer event + flags. When this bit flag is set, the sequencer event is extended + to have a larger payload of 16 bytes instead of the legacy 12 + bytes, and the event contains the UMP packet in the payload. + +* The new sequencer port type bit (`SNDRV_SEQ_PORT_TYPE_MIDI_UMP`) + indicates the port being UMP-capable. + +* The sequencer ports have new capability bits to indicate the + inactive ports (`SNDRV_SEQ_PORT_CAP_INACTIVE`) and the UMP Endpoint + port (`SNDRV_SEQ_PORT_CAP_UMP_ENDPOINT`). + +* The event conversion of ALSA sequencer clients can be suppressed the + new filter bit `SNDRV_SEQ_FILTER_NO_CONVERT` set to the client info. + For example, the kernel pass-through client (`snd-seq-dummy`) sets + this flag internally. + +* The port information gained the new field `direction` to indicate + the direction of the port (either `SNDRV_SEQ_PORT_DIR_INPUT`, + `SNDRV_SEQ_PORT_DIR_OUTPUT` or `SNDRV_SEQ_PORT_DIR_BIDIRECTION`). + +* Another additional field for the port information is `ump_group` + which specifies the associated UMP Group Number (1-based). + When it's non-zero, the UMP group field in the UMP packet updated + upon delivery to the specified group (corrected to be 0-based). + Each sequencer port is supposed to set this field if it's a port to + specific to a certain UMP group. + +* Each client may set the additional event filter for UMP Groups in + `group_filter` bitmap. The filter consists of bitmap from 1-based + Group numbers. For example, when the bit 1 is set, messages from + Group 1 (i.e. the very first group) are filtered and not delivered. + The bit 0 is used for filtering UMP groupless messages. + +* Two new ioctls are added for UMP-capable clients: + `SNDRV_SEQ_IOCTL_GET_CLIENT_UMP_INFO` and + `SNDRV_SEQ_IOCTL_SET_CLIENT_UMP_INFO`. They are used to get and set + either `snd_ump_endpoint_info` or `snd_ump_block_info` data + associated with the sequencer client. The USB MIDI driver provides + those information from the underlying UMP rawmidi, while a + user-space client may provide its own data via `*_SET` ioctl. + For an Endpoint data, pass 0 to the `type` field, while for a Block + data, pass the block number + 1 to the `type` field. + Setting the data for a kernel client shall result in an error. + +* With UMP 1.1, Function Block information may be changed + dynamically. When the update of Function Block is received from the + device, ALSA sequencer core changes the corresponding sequencer port + name and attributes accordingly, and notifies the changes via the + announcement to the ALSA sequencer system port, similarly like the + normal port change notification. + + +MIDI2 USB Gadget Function Driver +================================ + +The latest kernel contains the support for USB MIDI 2.0 gadget +function driver, which can be used for prototyping and debugging MIDI +2.0 features. + +`CONFIG_USB_GADGET`, `CONFIG_USB_CONFIGFS` and +`CONFIG_USB_CONFIGFS_F_MIDI2` need to be enabled for the MIDI2 gadget +driver. + +In addition, for using a gadget driver, you need a working UDC driver. +In the example below, we use `dummy_hcd` driver (enabled via +`CONFIG_USB_DUMMY_HCD`) that is available on PC and VM for debugging +purpose. There are other UDC drivers depending on the platform, and +those can be used for a real device, instead, too. + +At first, on a system to run the gadget, load `libcomposite` module:: + + % modprobe libcomposite + +and you'll have `usb_gadget` subdirectory under configfs space +(typically `/sys/kernel/config` on modern OS). Then create a gadget +instance and add configurations there, for example:: + + % cd /sys/kernel/config + % mkdir usb_gadget/g1 + + % cd usb_gadget/g1 + % mkdir configs/c.1 + % mkdir functions/midi2.usb0 + + % echo 0x0004 > idProduct + % echo 0x17b3 > idVendor + % mkdir strings/0x409 + % echo "ACME Enterprises" > strings/0x409/manufacturer + % echo "ACMESynth" > strings/0x409/product + % echo "ABCD12345" > strings/0x409/serialnumber + + % mkdir configs/c.1/strings/0x409 + % echo "Monosynth" > configs/c.1/strings/0x409/configuration + % echo 120 > configs/c.1/MaxPower + +At this point, there must be a subdirectory `ep.0`, and that is the +configuration for a UMP Endpoint. You can fill the Endpoint +information like:: + + % echo "ACMESynth" > functions/midi2.usb0/iface_name + % echo "ACMESynth" > functions/midi2.usb0/ep.0/ep_name + % echo "ABCD12345" > functions/midi2.usb0/ep.0/product_id + % echo 0x0123 > functions/midi2.usb0/ep.0/family + % echo 0x4567 > functions/midi2.usb0/ep.0/model + % echo 0x123456 > functions/midi2.usb0/ep.0/manufacturer + % echo 0x12345678 > functions/midi2.usb0/ep.0/sw_revision + +The default MIDI protocol can be set either 1 or 2:: + + % echo 2 > functions/midi2.usb0/ep.0/protocol + +And, you can find a subdirectory `block.0` under this Endpoint +subdirectory. This defines the Function Block information:: + + % echo "Monosynth" > functions/midi2.usb0/ep.0/block.0/name + % echo 0 > functions/midi2.usb0/ep.0/block.0/first_group + % echo 1 > functions/midi2.usb0/ep.0/block.0/num_groups + +Finally, link the configuration and enable it:: + + % ln -s functions/midi2.usb0 configs/c.1 + % echo dummy_udc.0 > UDC + +where `dummy_udc.0` is an example case and it differs depending on the +system. You can find the UDC instances in `/sys/class/udc` and pass +the found name instead:: + + % ls /sys/class/udc + dummy_udc.0 + +Now, the MIDI 2.0 gadget device is enabled, and the gadget host +creates a new sound card instance containing a UMP rawmidi device by +`f_midi2` driver:: + + % cat /proc/asound/cards + .... + 1 [Gadget ]: f_midi2 - MIDI 2.0 Gadget + MIDI 2.0 Gadget + +And on the connected host, a similar card should appear, too, but with +the card and device names given in the configfs above:: + + % cat /proc/asound/cards + .... + 2 [ACMESynth ]: USB-Audio - ACMESynth + ACME Enterprises ACMESynth at usb-dummy_hcd.0-1, high speed + +You can play a MIDI file on the gadget side:: + + % aplaymidi -p 20:1 to_host.mid + +and this will appear as an input from a MIDI device on the connected +host:: + + % aseqdump -p 20:0 -u 2 + +Vice versa, a playback on the connected host will work as an input on +the gadget, too. + +Each Function Block may have different direction and UI-hint, +specified via `direction` and `ui_hint` attributes. +Passing `1` is for input-only, `2` for out-only and `3` for +bidirectional (the default value). For example:: + + % echo 2 > functions/midi2.usb0/ep.0/block.0/direction + % echo 2 > functions/midi2.usb0/ep.0/block.0/ui_hint + +When you need more than one Function Blocks, you can create +subdirectories `block.1`, `block.2`, etc dynamically, and configure +them in the configuration procedure above before linking. +For example, to create a second Function Block for a keyboard:: + + % mkdir functions/midi2.usb0/ep.0/block.1 + % echo "Keyboard" > functions/midi2.usb0/ep.0/block.1/name + % echo 1 > functions/midi2.usb0/ep.0/block.1/first_group + % echo 1 > functions/midi2.usb0/ep.0/block.1/num_groups + % echo 1 > functions/midi2.usb0/ep.0/block.1/direction + % echo 1 > functions/midi2.usb0/ep.0/block.1/ui_hint + +The `block.*` subdirectories can be removed dynamically, too (except +for `block.0` which is persistent). + +For assigning a Function Block for MIDI 1.0 I/O, set up in `is_midi1` +attribute. 1 is for MIDI 1.0, and 2 is for MIDI 1.0 with low speed +connection:: + + % echo 2 > functions/midi2.usb0/ep.0/block.1/is_midi1 + +For disabling the processing of UMP Stream messages in the gadget +driver, pass `0` to `process_ump` attribute in the top-level config:: + + % echo 0 > functions/midi2.usb0/process_ump + +The MIDI 1.0 interface at altset 0 is supported by the gadget driver, +too. When MIDI 1.0 interface is selected by the connected host, the +UMP I/O on the gadget is translated from/to USB MIDI 1.0 packets +accordingly while the gadget driver keeps communicating with the +user-space over UMP rawmidi. + +MIDI 1.0 ports are set up from the config in each Function Block. +For example:: + + % echo 0 > functions/midi2.usb0/ep.0/block.0/midi1_first_group + % echo 1 > functions/midi2.usb0/ep.0/block.0/midi1_num_groups + +The configuration above will enable the Group 1 (the index 0) for MIDI +1.0 interface. Note that those groups must be in the groups defined +for the Function Block itself. + +The gadget driver supports more than one UMP Endpoints, too. +Similarly like the Function Blocks, you can create a new subdirectory +`ep.1` (but under the card top-level config) to enable a new Endpoint:: + + % mkdir functions/midi2.usb0/ep.1 + +and create a new Function Block there. For example, to create 4 +Groups for the Function Block of this new Endpoint:: + + % mkdir functions/midi2.usb0/ep.1/block.0 + % echo 4 > functions/midi2.usb0/ep.1/block.0/num_groups + +Now, you'll have 4 rawmidi devices in total: the first two are UMP +rawmidi devices for Endpoint 0 and Endpoint 1, and other two for the +legacy MIDI 1.0 rawmidi devices corresponding to both EP 0 and EP 1. + +The current altsetting on the gadget can be informed via a control +element "Operation Mode" with `RAWMIDI` iface. e.g. you can read it +via `amixer` program running on the gadget host like:: + + % amixer -c1 cget iface=RAWMIDI,name='Operation Mode' + ; type=INTEGER,access=r--v----,values=1,min=0,max=2,step=0 + : values=2 + +The value (shown in the second returned line with `: values=`) +indicates 1 for MIDI 1.0 (altset 0), 2 for MIDI 2.0 (altset 1) and 0 +for unset. + +As of now, the configurations can't be changed after binding. diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 4335c98b3d82..cd421856409e 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -2018,8 +2018,8 @@ sleeping poll threads, etc. This callback is also atomic by default. -copy_user, copy_kernel and fill_silence ops -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +copy and fill_silence ops +~~~~~~~~~~~~~~~~~~~~~~~~~ These callbacks are not mandatory, and can be omitted in most cases. These callbacks are used when the hardware buffer cannot be in the @@ -3444,8 +3444,8 @@ external hardware buffer in interrupts (or in tasklets, preferably). The first case works fine if the external hardware buffer is large enough. This method doesn't need any extra buffers and thus is more -efficient. You need to define the ``copy_user`` and ``copy_kernel`` -callbacks for the data transfer, in addition to the ``fill_silence`` +efficient. You need to define the ``copy`` callback +for the data transfer, in addition to the ``fill_silence`` callback for playback. However, there is a drawback: it cannot be mmapped. The examples are GUS's GF1 PCM or emu8000's wavetable PCM. @@ -3458,22 +3458,22 @@ Another case is when the chip uses a PCI memory-map region for the buffer instead of the host memory. In this case, mmap is available only on certain architectures like the Intel one. In non-mmap mode, the data cannot be transferred as in the normal way. Thus you need to define the -``copy_user``, ``copy_kernel`` and ``fill_silence`` callbacks as well, +``copy`` and ``fill_silence`` callbacks as well, as in the cases above. Examples are found in ``rme32.c`` and ``rme96.c``. -The implementation of the ``copy_user``, ``copy_kernel`` and +The implementation of the ``copy`` and ``silence`` callbacks depends upon whether the hardware supports -interleaved or non-interleaved samples. The ``copy_user`` callback is +interleaved or non-interleaved samples. The ``copy`` callback is defined like below, a bit differently depending on whether the direction is playback or capture:: - static int playback_copy_user(struct snd_pcm_substream *substream, + static int playback_copy(struct snd_pcm_substream *substream, int channel, unsigned long pos, - void __user *src, unsigned long count); - static int capture_copy_user(struct snd_pcm_substream *substream, + struct iov_iter *src, unsigned long count); + static int capture_copy(struct snd_pcm_substream *substream, int channel, unsigned long pos, - void __user *dst, unsigned long count); + struct iov_iter *dst, unsigned long count); In the case of interleaved samples, the second argument (``channel``) is not used. The third argument (``pos``) specifies the position in bytes. @@ -3490,18 +3490,17 @@ of data (``count``) at the specified pointer (``src``) to the specified offset (``pos``) in the hardware buffer. When coded like memcpy-like way, the copy would look like:: - my_memcpy_from_user(my_buffer + pos, src, count); + my_memcpy_from_iter(my_buffer + pos, src, count); For the capture direction, you copy the given amount of data (``count``) at the specified offset (``pos``) in the hardware buffer to the specified pointer (``dst``):: - my_memcpy_to_user(dst, my_buffer + pos, count); + my_memcpy_to_iter(dst, my_buffer + pos, count); -Here the functions are named ``from_user`` and ``to_user`` because -it's the user-space buffer that is passed to these callbacks. That -is, the callback is supposed to copy data from/to the user-space -directly to/from the hardware buffer. +The given ``src`` or ``dst`` a struct iov_iter pointer containing the +pointer and the size. Use the existing helpers to copy or access the +data as defined in ``linux/uio.h``. Careful readers might notice that these callbacks receive the arguments in bytes, not in frames like other callbacks. It's because @@ -3519,25 +3518,6 @@ the given user-space buffer, but only for the given channel. For details, please check ``isa/gus/gus_pcm.c`` or ``pci/rme9652/rme9652.c`` as examples. -The above callbacks are the copies from/to the user-space buffer. There -are some cases where we want to copy from/to the kernel-space buffer -instead. In such a case, the ``copy_kernel`` callback is called. It'd -look like:: - - static int playback_copy_kernel(struct snd_pcm_substream *substream, - int channel, unsigned long pos, - void *src, unsigned long count); - static int capture_copy_kernel(struct snd_pcm_substream *substream, - int channel, unsigned long pos, - void *dst, unsigned long count); - -As found easily, the only difference is that the buffer pointer is -without a ``__user`` prefix; that is, a kernel-buffer pointer is passed -in the fourth argument. Correspondingly, the implementation would be -a version without the user-copy, such as:: - - my_memcpy(my_buffer + pos, src, count); - Usually for the playback, another callback ``fill_silence`` is defined. It's implemented in a similar way as the copy callbacks above:: @@ -3545,10 +3525,10 @@ above:: static int silence(struct snd_pcm_substream *substream, int channel, unsigned long pos, unsigned long count); -The meanings of arguments are the same as in the ``copy_user`` and -``copy_kernel`` callbacks, although there is no buffer pointer +The meanings of arguments are the same as in the ``copy`` callback, +although there is no buffer pointer argument. In the case of interleaved samples, the channel argument has -no meaning, as for the ``copy_*`` callbacks. +no meaning, as for the ``copy`` callback. The role of the ``fill_silence`` callback is to set the given amount (``count``) of silence data at the specified offset (``pos``) in the diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py index ca8ac9e59ded..a99716bf44b5 100644 --- a/Documentation/sphinx/cdomain.py +++ b/Documentation/sphinx/cdomain.py @@ -178,7 +178,7 @@ class CObject(Base_CObject): if len(arglist[0].split(" ")) > 1: return False - # This is a function-like macro, it's arguments are typeless! + # This is a function-like macro, its arguments are typeless! signode += addnodes.desc_name(fullname, fullname) paramlist = addnodes.desc_parameterlist() signode += paramlist diff --git a/Documentation/spi/spi-lm70llp.rst b/Documentation/spi/spi-lm70llp.rst index 0144e12d95bb..2f20e5b405e6 100644 --- a/Documentation/spi/spi-lm70llp.rst +++ b/Documentation/spi/spi-lm70llp.rst @@ -69,7 +69,7 @@ Interpreting this circuit, when the LM70 SI/O line is High (or tristate and not grounded by the host via D7), the transistor conducts and switches the collector to zero, which is reflected on pin 13 of the DB25 parport connector. When SI/O is Low (driven by the LM70 or the host) on the other -hand, the transistor is cut off and the voltage tied to it's collector is +hand, the transistor is cut off and the voltage tied to its collector is reflected on pin 13 as a High level. So: the getmiso inline routine in this driver takes this fact into account, diff --git a/Documentation/subsystem-apis.rst b/Documentation/subsystem-apis.rst index b51f38527e14..90a0535a932a 100644 --- a/Documentation/subsystem-apis.rst +++ b/Documentation/subsystem-apis.rst @@ -10,50 +10,79 @@ is taken directly from the kernel source, with supplemental material added as needed (or at least as we managed to add it — probably *not* all that is needed). -**Fixme**: much more organizational work is needed here. +Core subsystems +--------------- .. toctree:: :maxdepth: 1 - driver-api/index core-api/index + driver-api/index + mm/index + power/index + scheduler/index + timers/index locking/index - accounting/index + +Human interfaces +---------------- + +.. toctree:: + :maxdepth: 1 + + input/index + hid/index + sound/index + gpu/index + fb/index + +Networking interfaces +--------------------- + +.. toctree:: + :maxdepth: 1 + + networking/index + netlabel/index + infiniband/index + isdn/index + mhi/index + +Storage interfaces +------------------ + +.. toctree:: + :maxdepth: 1 + + filesystems/index block/index cdrom/index + scsi/index + target/index + +**Fixme**: much more organizational work is needed here. + +.. toctree:: + :maxdepth: 1 + + accounting/index cpu-freq/index - fb/index fpga/index - hid/index i2c/index iio/index - isdn/index - infiniband/index leds/index - netlabel/index - networking/index pcmcia/index - power/index - target/index - timers/index spi/index w1/index watchdog/index virt/index - input/index hwmon/index - gpu/index accel/index security/index - sound/index crypto/index - filesystems/index - mm/index bpf/index usb/index PCI/index - scsi/index misc-devices/index - scheduler/index - mhi/index peci/index + wmi/index diff --git a/Documentation/target/scripts.rst b/Documentation/target/scripts.rst index 172d42b522e4..aa7b9c62c1b3 100644 --- a/Documentation/target/scripts.rst +++ b/Documentation/target/scripts.rst @@ -1,9 +1,3 @@ -TCM mod builder script ----------------------- - -.. literalinclude:: tcm_mod_builder.py - :language: perl - Target export device script --------------------------- diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py deleted file mode 100755 index 54492aa813b9..000000000000 --- a/Documentation/target/tcm_mod_builder.py +++ /dev/null @@ -1,656 +0,0 @@ -#!/usr/bin/env python -# The TCM v4 multi-protocol fabric module generation script for drivers/target/$NEW_MOD -# -# Copyright (c) 2010 Rising Tide Systems -# Copyright (c) 2010 Linux-iSCSI.org -# -# Author: nab@kernel.org -# -import os, sys -import subprocess as sub -import string -import re -import optparse - -tcm_dir = "" - -fabric_ops = [] -fabric_mod_dir = "" -fabric_mod_port = "" -fabric_mod_init_port = "" - -def tcm_mod_err(msg): - print msg - sys.exit(1) - -def tcm_mod_create_module_subdir(fabric_mod_dir_var): - - if os.path.isdir(fabric_mod_dir_var) == True: - return 1 - - print "Creating fabric_mod_dir: " + fabric_mod_dir_var - ret = os.mkdir(fabric_mod_dir_var) - if ret: - tcm_mod_err("Unable to mkdir " + fabric_mod_dir_var) - - return - -def tcm_mod_build_FC_include(fabric_mod_dir_var, fabric_mod_name): - global fabric_mod_port - global fabric_mod_init_port - buf = "" - - f = fabric_mod_dir_var + "/" + fabric_mod_name + "_base.h" - print "Writing file: " + f - - p = open(f, 'w'); - if not p: - tcm_mod_err("Unable to open file: " + f) - - buf = "#define " + fabric_mod_name.upper() + "_VERSION \"v0.1\"\n" - buf += "#define " + fabric_mod_name.upper() + "_NAMELEN 32\n" - buf += "\n" - buf += "struct " + fabric_mod_name + "_tpg {\n" - buf += " /* FC lport target portal group tag for TCM */\n" - buf += " u16 lport_tpgt;\n" - buf += " /* Pointer back to " + fabric_mod_name + "_lport */\n" - buf += " struct " + fabric_mod_name + "_lport *lport;\n" - buf += " /* Returned by " + fabric_mod_name + "_make_tpg() */\n" - buf += " struct se_portal_group se_tpg;\n" - buf += "};\n" - buf += "\n" - buf += "struct " + fabric_mod_name + "_lport {\n" - buf += " /* Binary World Wide unique Port Name for FC Target Lport */\n" - buf += " u64 lport_wwpn;\n" - buf += " /* ASCII formatted WWPN for FC Target Lport */\n" - buf += " char lport_name[" + fabric_mod_name.upper() + "_NAMELEN];\n" - buf += " /* Returned by " + fabric_mod_name + "_make_lport() */\n" - buf += " struct se_wwn lport_wwn;\n" - buf += "};\n" - - ret = p.write(buf) - if ret: - tcm_mod_err("Unable to write f: " + f) - - p.close() - - fabric_mod_port = "lport" - fabric_mod_init_port = "nport" - - return - -def tcm_mod_build_SAS_include(fabric_mod_dir_var, fabric_mod_name): - global fabric_mod_port - global fabric_mod_init_port - buf = "" - - f = fabric_mod_dir_var + "/" + fabric_mod_name + "_base.h" - print "Writing file: " + f - - p = open(f, 'w'); - if not p: - tcm_mod_err("Unable to open file: " + f) - - buf = "#define " + fabric_mod_name.upper() + "_VERSION \"v0.1\"\n" - buf += "#define " + fabric_mod_name.upper() + "_NAMELEN 32\n" - buf += "\n" - buf += "struct " + fabric_mod_name + "_tpg {\n" - buf += " /* SAS port target portal group tag for TCM */\n" - buf += " u16 tport_tpgt;\n" - buf += " /* Pointer back to " + fabric_mod_name + "_tport */\n" - buf += " struct " + fabric_mod_name + "_tport *tport;\n" - buf += " /* Returned by " + fabric_mod_name + "_make_tpg() */\n" - buf += " struct se_portal_group se_tpg;\n" - buf += "};\n\n" - buf += "struct " + fabric_mod_name + "_tport {\n" - buf += " /* Binary World Wide unique Port Name for SAS Target port */\n" - buf += " u64 tport_wwpn;\n" - buf += " /* ASCII formatted WWPN for SAS Target port */\n" - buf += " char tport_name[" + fabric_mod_name.upper() + "_NAMELEN];\n" - buf += " /* Returned by " + fabric_mod_name + "_make_tport() */\n" - buf += " struct se_wwn tport_wwn;\n" - buf += "};\n" - - ret = p.write(buf) - if ret: - tcm_mod_err("Unable to write f: " + f) - - p.close() - - fabric_mod_port = "tport" - fabric_mod_init_port = "iport" - - return - -def tcm_mod_build_iSCSI_include(fabric_mod_dir_var, fabric_mod_name): - global fabric_mod_port - global fabric_mod_init_port - buf = "" - - f = fabric_mod_dir_var + "/" + fabric_mod_name + "_base.h" - print "Writing file: " + f - - p = open(f, 'w'); - if not p: - tcm_mod_err("Unable to open file: " + f) - - buf = "#define " + fabric_mod_name.upper() + "_VERSION \"v0.1\"\n" - buf += "#define " + fabric_mod_name.upper() + "_NAMELEN 32\n" - buf += "\n" - buf += "struct " + fabric_mod_name + "_tpg {\n" - buf += " /* iSCSI target portal group tag for TCM */\n" - buf += " u16 tport_tpgt;\n" - buf += " /* Pointer back to " + fabric_mod_name + "_tport */\n" - buf += " struct " + fabric_mod_name + "_tport *tport;\n" - buf += " /* Returned by " + fabric_mod_name + "_make_tpg() */\n" - buf += " struct se_portal_group se_tpg;\n" - buf += "};\n\n" - buf += "struct " + fabric_mod_name + "_tport {\n" - buf += " /* ASCII formatted TargetName for IQN */\n" - buf += " char tport_name[" + fabric_mod_name.upper() + "_NAMELEN];\n" - buf += " /* Returned by " + fabric_mod_name + "_make_tport() */\n" - buf += " struct se_wwn tport_wwn;\n" - buf += "};\n" - - ret = p.write(buf) - if ret: - tcm_mod_err("Unable to write f: " + f) - - p.close() - - fabric_mod_port = "tport" - fabric_mod_init_port = "iport" - - return - -def tcm_mod_build_base_includes(proto_ident, fabric_mod_dir_val, fabric_mod_name): - - if proto_ident == "FC": - tcm_mod_build_FC_include(fabric_mod_dir_val, fabric_mod_name) - elif proto_ident == "SAS": - tcm_mod_build_SAS_include(fabric_mod_dir_val, fabric_mod_name) - elif proto_ident == "iSCSI": - tcm_mod_build_iSCSI_include(fabric_mod_dir_val, fabric_mod_name) - else: - print "Unsupported proto_ident: " + proto_ident - sys.exit(1) - - return - -def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): - buf = "" - - f = fabric_mod_dir_var + "/" + fabric_mod_name + "_configfs.c" - print "Writing file: " + f - - p = open(f, 'w'); - if not p: - tcm_mod_err("Unable to open file: " + f) - - buf = "#include <linux/module.h>\n" - buf += "#include <linux/moduleparam.h>\n" - buf += "#include <linux/version.h>\n" - buf += "#include <generated/utsrelease.h>\n" - buf += "#include <linux/utsname.h>\n" - buf += "#include <linux/init.h>\n" - buf += "#include <linux/slab.h>\n" - buf += "#include <linux/kthread.h>\n" - buf += "#include <linux/types.h>\n" - buf += "#include <linux/string.h>\n" - buf += "#include <linux/configfs.h>\n" - buf += "#include <linux/ctype.h>\n" - buf += "#include <asm/unaligned.h>\n" - buf += "#include <scsi/scsi_proto.h>\n\n" - buf += "#include <target/target_core_base.h>\n" - buf += "#include <target/target_core_fabric.h>\n" - buf += "#include \"" + fabric_mod_name + "_base.h\"\n" - buf += "#include \"" + fabric_mod_name + "_fabric.h\"\n\n" - - buf += "static const struct target_core_fabric_ops " + fabric_mod_name + "_ops;\n\n" - - buf += "static struct se_portal_group *" + fabric_mod_name + "_make_tpg(\n" - buf += " struct se_wwn *wwn,\n" - buf += " struct config_group *group,\n" - buf += " const char *name)\n" - buf += "{\n" - buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + "*" + fabric_mod_port + " = container_of(wwn,\n" - buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + ", " + fabric_mod_port + "_wwn);\n\n" - buf += " struct " + fabric_mod_name + "_tpg *tpg;\n" - buf += " unsigned long tpgt;\n" - buf += " int ret;\n\n" - buf += " if (strstr(name, \"tpgt_\") != name)\n" - buf += " return ERR_PTR(-EINVAL);\n" - buf += " if (kstrtoul(name + 5, 10, &tpgt) || tpgt > UINT_MAX)\n" - buf += " return ERR_PTR(-EINVAL);\n\n" - buf += " tpg = kzalloc(sizeof(struct " + fabric_mod_name + "_tpg), GFP_KERNEL);\n" - buf += " if (!tpg) {\n" - buf += " printk(KERN_ERR \"Unable to allocate struct " + fabric_mod_name + "_tpg\");\n" - buf += " return ERR_PTR(-ENOMEM);\n" - buf += " }\n" - buf += " tpg->" + fabric_mod_port + " = " + fabric_mod_port + ";\n" - buf += " tpg->" + fabric_mod_port + "_tpgt = tpgt;\n\n" - - if proto_ident == "FC": - buf += " ret = core_tpg_register(wwn, &tpg->se_tpg, SCSI_PROTOCOL_FCP);\n" - elif proto_ident == "SAS": - buf += " ret = core_tpg_register(wwn, &tpg->se_tpg, SCSI_PROTOCOL_SAS);\n" - elif proto_ident == "iSCSI": - buf += " ret = core_tpg_register(wwn, &tpg->se_tpg, SCSI_PROTOCOL_ISCSI);\n" - - buf += " if (ret < 0) {\n" - buf += " kfree(tpg);\n" - buf += " return NULL;\n" - buf += " }\n" - buf += " return &tpg->se_tpg;\n" - buf += "}\n\n" - buf += "static void " + fabric_mod_name + "_drop_tpg(struct se_portal_group *se_tpg)\n" - buf += "{\n" - buf += " struct " + fabric_mod_name + "_tpg *tpg = container_of(se_tpg,\n" - buf += " struct " + fabric_mod_name + "_tpg, se_tpg);\n\n" - buf += " core_tpg_deregister(se_tpg);\n" - buf += " kfree(tpg);\n" - buf += "}\n\n" - - buf += "static struct se_wwn *" + fabric_mod_name + "_make_" + fabric_mod_port + "(\n" - buf += " struct target_fabric_configfs *tf,\n" - buf += " struct config_group *group,\n" - buf += " const char *name)\n" - buf += "{\n" - buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + " *" + fabric_mod_port + ";\n" - - if proto_ident == "FC" or proto_ident == "SAS": - buf += " u64 wwpn = 0;\n\n" - - buf += " /* if (" + fabric_mod_name + "_parse_wwn(name, &wwpn, 1) < 0)\n" - buf += " return ERR_PTR(-EINVAL); */\n\n" - buf += " " + fabric_mod_port + " = kzalloc(sizeof(struct " + fabric_mod_name + "_" + fabric_mod_port + "), GFP_KERNEL);\n" - buf += " if (!" + fabric_mod_port + ") {\n" - buf += " printk(KERN_ERR \"Unable to allocate struct " + fabric_mod_name + "_" + fabric_mod_port + "\");\n" - buf += " return ERR_PTR(-ENOMEM);\n" - buf += " }\n" - - if proto_ident == "FC" or proto_ident == "SAS": - buf += " " + fabric_mod_port + "->" + fabric_mod_port + "_wwpn = wwpn;\n" - - buf += " /* " + fabric_mod_name + "_format_wwn(&" + fabric_mod_port + "->" + fabric_mod_port + "_name[0], " + fabric_mod_name.upper() + "_NAMELEN, wwpn); */\n\n" - buf += " return &" + fabric_mod_port + "->" + fabric_mod_port + "_wwn;\n" - buf += "}\n\n" - buf += "static void " + fabric_mod_name + "_drop_" + fabric_mod_port + "(struct se_wwn *wwn)\n" - buf += "{\n" - buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + " *" + fabric_mod_port + " = container_of(wwn,\n" - buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + ", " + fabric_mod_port + "_wwn);\n" - buf += " kfree(" + fabric_mod_port + ");\n" - buf += "}\n\n" - - buf += "static const struct target_core_fabric_ops " + fabric_mod_name + "_ops = {\n" - buf += " .module = THIS_MODULE,\n" - buf += " .name = \"" + fabric_mod_name + "\",\n" - buf += " .get_fabric_name = " + fabric_mod_name + "_get_fabric_name,\n" - buf += " .tpg_get_wwn = " + fabric_mod_name + "_get_fabric_wwn,\n" - buf += " .tpg_get_tag = " + fabric_mod_name + "_get_tag,\n" - buf += " .tpg_check_demo_mode = " + fabric_mod_name + "_check_false,\n" - buf += " .tpg_check_demo_mode_cache = " + fabric_mod_name + "_check_true,\n" - buf += " .tpg_check_demo_mode_write_protect = " + fabric_mod_name + "_check_true,\n" - buf += " .tpg_check_prod_mode_write_protect = " + fabric_mod_name + "_check_false,\n" - buf += " .tpg_get_inst_index = " + fabric_mod_name + "_tpg_get_inst_index,\n" - buf += " .release_cmd = " + fabric_mod_name + "_release_cmd,\n" - buf += " .sess_get_index = " + fabric_mod_name + "_sess_get_index,\n" - buf += " .sess_get_initiator_sid = NULL,\n" - buf += " .write_pending = " + fabric_mod_name + "_write_pending,\n" - buf += " .set_default_node_attributes = " + fabric_mod_name + "_set_default_node_attrs,\n" - buf += " .get_cmd_state = " + fabric_mod_name + "_get_cmd_state,\n" - buf += " .queue_data_in = " + fabric_mod_name + "_queue_data_in,\n" - buf += " .queue_status = " + fabric_mod_name + "_queue_status,\n" - buf += " .queue_tm_rsp = " + fabric_mod_name + "_queue_tm_rsp,\n" - buf += " .aborted_task = " + fabric_mod_name + "_aborted_task,\n" - buf += " /*\n" - buf += " * Setup function pointers for generic logic in target_core_fabric_configfs.c\n" - buf += " */\n" - buf += " .fabric_make_wwn = " + fabric_mod_name + "_make_" + fabric_mod_port + ",\n" - buf += " .fabric_drop_wwn = " + fabric_mod_name + "_drop_" + fabric_mod_port + ",\n" - buf += " .fabric_make_tpg = " + fabric_mod_name + "_make_tpg,\n" - buf += " .fabric_drop_tpg = " + fabric_mod_name + "_drop_tpg,\n" - buf += "};\n\n" - - buf += "static int __init " + fabric_mod_name + "_init(void)\n" - buf += "{\n" - buf += " return target_register_template(&" + fabric_mod_name + "_ops);\n" - buf += "};\n\n" - - buf += "static void __exit " + fabric_mod_name + "_exit(void)\n" - buf += "{\n" - buf += " target_unregister_template(&" + fabric_mod_name + "_ops);\n" - buf += "};\n\n" - - buf += "MODULE_DESCRIPTION(\"" + fabric_mod_name.upper() + " series fabric driver\");\n" - buf += "MODULE_LICENSE(\"GPL\");\n" - buf += "module_init(" + fabric_mod_name + "_init);\n" - buf += "module_exit(" + fabric_mod_name + "_exit);\n" - - ret = p.write(buf) - if ret: - tcm_mod_err("Unable to write f: " + f) - - p.close() - - return - -def tcm_mod_scan_fabric_ops(tcm_dir): - - fabric_ops_api = tcm_dir + "include/target/target_core_fabric.h" - - print "Using tcm_mod_scan_fabric_ops: " + fabric_ops_api - process_fo = 0; - - p = open(fabric_ops_api, 'r') - - line = p.readline() - while line: - if process_fo == 0 and re.search('struct target_core_fabric_ops {', line): - line = p.readline() - continue - - if process_fo == 0: - process_fo = 1; - line = p.readline() - # Search for function pointer - if not re.search('\(\*', line): - continue - - fabric_ops.append(line.rstrip()) - continue - - line = p.readline() - # Search for function pointer - if not re.search('\(\*', line): - continue - - fabric_ops.append(line.rstrip()) - - p.close() - return - -def tcm_mod_dump_fabric_ops(proto_ident, fabric_mod_dir_var, fabric_mod_name): - buf = "" - bufi = "" - - f = fabric_mod_dir_var + "/" + fabric_mod_name + "_fabric.c" - print "Writing file: " + f - - p = open(f, 'w') - if not p: - tcm_mod_err("Unable to open file: " + f) - - fi = fabric_mod_dir_var + "/" + fabric_mod_name + "_fabric.h" - print "Writing file: " + fi - - pi = open(fi, 'w') - if not pi: - tcm_mod_err("Unable to open file: " + fi) - - buf = "#include <linux/slab.h>\n" - buf += "#include <linux/kthread.h>\n" - buf += "#include <linux/types.h>\n" - buf += "#include <linux/list.h>\n" - buf += "#include <linux/types.h>\n" - buf += "#include <linux/string.h>\n" - buf += "#include <linux/ctype.h>\n" - buf += "#include <asm/unaligned.h>\n" - buf += "#include <scsi/scsi_common.h>\n" - buf += "#include <scsi/scsi_proto.h>\n" - buf += "#include <target/target_core_base.h>\n" - buf += "#include <target/target_core_fabric.h>\n" - buf += "#include \"" + fabric_mod_name + "_base.h\"\n" - buf += "#include \"" + fabric_mod_name + "_fabric.h\"\n\n" - - buf += "int " + fabric_mod_name + "_check_true(struct se_portal_group *se_tpg)\n" - buf += "{\n" - buf += " return 1;\n" - buf += "}\n\n" - bufi += "int " + fabric_mod_name + "_check_true(struct se_portal_group *);\n" - - buf += "int " + fabric_mod_name + "_check_false(struct se_portal_group *se_tpg)\n" - buf += "{\n" - buf += " return 0;\n" - buf += "}\n\n" - bufi += "int " + fabric_mod_name + "_check_false(struct se_portal_group *);\n" - - total_fabric_ops = len(fabric_ops) - i = 0 - - while i < total_fabric_ops: - fo = fabric_ops[i] - i += 1 -# print "fabric_ops: " + fo - - if re.search('get_fabric_name', fo): - buf += "char *" + fabric_mod_name + "_get_fabric_name(void)\n" - buf += "{\n" - buf += " return \"" + fabric_mod_name + "\";\n" - buf += "}\n\n" - bufi += "char *" + fabric_mod_name + "_get_fabric_name(void);\n" - continue - - if re.search('get_wwn', fo): - buf += "char *" + fabric_mod_name + "_get_fabric_wwn(struct se_portal_group *se_tpg)\n" - buf += "{\n" - buf += " struct " + fabric_mod_name + "_tpg *tpg = container_of(se_tpg,\n" - buf += " struct " + fabric_mod_name + "_tpg, se_tpg);\n" - buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + " *" + fabric_mod_port + " = tpg->" + fabric_mod_port + ";\n\n" - buf += " return &" + fabric_mod_port + "->" + fabric_mod_port + "_name[0];\n" - buf += "}\n\n" - bufi += "char *" + fabric_mod_name + "_get_fabric_wwn(struct se_portal_group *);\n" - - if re.search('get_tag', fo): - buf += "u16 " + fabric_mod_name + "_get_tag(struct se_portal_group *se_tpg)\n" - buf += "{\n" - buf += " struct " + fabric_mod_name + "_tpg *tpg = container_of(se_tpg,\n" - buf += " struct " + fabric_mod_name + "_tpg, se_tpg);\n" - buf += " return tpg->" + fabric_mod_port + "_tpgt;\n" - buf += "}\n\n" - bufi += "u16 " + fabric_mod_name + "_get_tag(struct se_portal_group *);\n" - - if re.search('tpg_get_inst_index\)\(', fo): - buf += "u32 " + fabric_mod_name + "_tpg_get_inst_index(struct se_portal_group *se_tpg)\n" - buf += "{\n" - buf += " return 1;\n" - buf += "}\n\n" - bufi += "u32 " + fabric_mod_name + "_tpg_get_inst_index(struct se_portal_group *);\n" - - if re.search('\*release_cmd\)\(', fo): - buf += "void " + fabric_mod_name + "_release_cmd(struct se_cmd *se_cmd)\n" - buf += "{\n" - buf += " return;\n" - buf += "}\n\n" - bufi += "void " + fabric_mod_name + "_release_cmd(struct se_cmd *);\n" - - if re.search('sess_get_index\)\(', fo): - buf += "u32 " + fabric_mod_name + "_sess_get_index(struct se_session *se_sess)\n" - buf += "{\n" - buf += " return 0;\n" - buf += "}\n\n" - bufi += "u32 " + fabric_mod_name + "_sess_get_index(struct se_session *);\n" - - if re.search('write_pending\)\(', fo): - buf += "int " + fabric_mod_name + "_write_pending(struct se_cmd *se_cmd)\n" - buf += "{\n" - buf += " return 0;\n" - buf += "}\n\n" - bufi += "int " + fabric_mod_name + "_write_pending(struct se_cmd *);\n" - - if re.search('set_default_node_attributes\)\(', fo): - buf += "void " + fabric_mod_name + "_set_default_node_attrs(struct se_node_acl *nacl)\n" - buf += "{\n" - buf += " return;\n" - buf += "}\n\n" - bufi += "void " + fabric_mod_name + "_set_default_node_attrs(struct se_node_acl *);\n" - - if re.search('get_cmd_state\)\(', fo): - buf += "int " + fabric_mod_name + "_get_cmd_state(struct se_cmd *se_cmd)\n" - buf += "{\n" - buf += " return 0;\n" - buf += "}\n\n" - bufi += "int " + fabric_mod_name + "_get_cmd_state(struct se_cmd *);\n" - - if re.search('queue_data_in\)\(', fo): - buf += "int " + fabric_mod_name + "_queue_data_in(struct se_cmd *se_cmd)\n" - buf += "{\n" - buf += " return 0;\n" - buf += "}\n\n" - bufi += "int " + fabric_mod_name + "_queue_data_in(struct se_cmd *);\n" - - if re.search('queue_status\)\(', fo): - buf += "int " + fabric_mod_name + "_queue_status(struct se_cmd *se_cmd)\n" - buf += "{\n" - buf += " return 0;\n" - buf += "}\n\n" - bufi += "int " + fabric_mod_name + "_queue_status(struct se_cmd *);\n" - - if re.search('queue_tm_rsp\)\(', fo): - buf += "void " + fabric_mod_name + "_queue_tm_rsp(struct se_cmd *se_cmd)\n" - buf += "{\n" - buf += " return;\n" - buf += "}\n\n" - bufi += "void " + fabric_mod_name + "_queue_tm_rsp(struct se_cmd *);\n" - - if re.search('aborted_task\)\(', fo): - buf += "void " + fabric_mod_name + "_aborted_task(struct se_cmd *se_cmd)\n" - buf += "{\n" - buf += " return;\n" - buf += "}\n\n" - bufi += "void " + fabric_mod_name + "_aborted_task(struct se_cmd *);\n" - - ret = p.write(buf) - if ret: - tcm_mod_err("Unable to write f: " + f) - - p.close() - - ret = pi.write(bufi) - if ret: - tcm_mod_err("Unable to write fi: " + fi) - - pi.close() - return - -def tcm_mod_build_kbuild(fabric_mod_dir_var, fabric_mod_name): - - buf = "" - f = fabric_mod_dir_var + "/Makefile" - print "Writing file: " + f - - p = open(f, 'w') - if not p: - tcm_mod_err("Unable to open file: " + f) - - buf += fabric_mod_name + "-objs := " + fabric_mod_name + "_fabric.o \\\n" - buf += " " + fabric_mod_name + "_configfs.o\n" - buf += "obj-$(CONFIG_" + fabric_mod_name.upper() + ") += " + fabric_mod_name + ".o\n" - - ret = p.write(buf) - if ret: - tcm_mod_err("Unable to write f: " + f) - - p.close() - return - -def tcm_mod_build_kconfig(fabric_mod_dir_var, fabric_mod_name): - - buf = "" - f = fabric_mod_dir_var + "/Kconfig" - print "Writing file: " + f - - p = open(f, 'w') - if not p: - tcm_mod_err("Unable to open file: " + f) - - buf = "config " + fabric_mod_name.upper() + "\n" - buf += " tristate \"" + fabric_mod_name.upper() + " fabric module\"\n" - buf += " depends on TARGET_CORE && CONFIGFS_FS\n" - buf += " default n\n" - buf += " help\n" - buf += " Say Y here to enable the " + fabric_mod_name.upper() + " fabric module\n" - - ret = p.write(buf) - if ret: - tcm_mod_err("Unable to write f: " + f) - - p.close() - return - -def tcm_mod_add_kbuild(tcm_dir, fabric_mod_name): - buf = "obj-$(CONFIG_" + fabric_mod_name.upper() + ") += " + fabric_mod_name.lower() + "/\n" - kbuild = tcm_dir + "/drivers/target/Makefile" - - f = open(kbuild, 'a') - f.write(buf) - f.close() - return - -def tcm_mod_add_kconfig(tcm_dir, fabric_mod_name): - buf = "source \"drivers/target/" + fabric_mod_name.lower() + "/Kconfig\"\n" - kconfig = tcm_dir + "/drivers/target/Kconfig" - - f = open(kconfig, 'a') - f.write(buf) - f.close() - return - -def main(modname, proto_ident): -# proto_ident = "FC" -# proto_ident = "SAS" -# proto_ident = "iSCSI" - - tcm_dir = os.getcwd(); - tcm_dir += "/../../" - print "tcm_dir: " + tcm_dir - fabric_mod_name = modname - fabric_mod_dir = tcm_dir + "drivers/target/" + fabric_mod_name - print "Set fabric_mod_name: " + fabric_mod_name - print "Set fabric_mod_dir: " + fabric_mod_dir - print "Using proto_ident: " + proto_ident - - if proto_ident != "FC" and proto_ident != "SAS" and proto_ident != "iSCSI": - print "Unsupported proto_ident: " + proto_ident - sys.exit(1) - - ret = tcm_mod_create_module_subdir(fabric_mod_dir) - if ret: - print "tcm_mod_create_module_subdir() failed because module already exists!" - sys.exit(1) - - tcm_mod_build_base_includes(proto_ident, fabric_mod_dir, fabric_mod_name) - tcm_mod_scan_fabric_ops(tcm_dir) - tcm_mod_dump_fabric_ops(proto_ident, fabric_mod_dir, fabric_mod_name) - tcm_mod_build_configfs(proto_ident, fabric_mod_dir, fabric_mod_name) - tcm_mod_build_kbuild(fabric_mod_dir, fabric_mod_name) - tcm_mod_build_kconfig(fabric_mod_dir, fabric_mod_name) - - input = raw_input("Would you like to add " + fabric_mod_name + " to drivers/target/Makefile..? [yes,no]: ") - if input == "yes" or input == "y": - tcm_mod_add_kbuild(tcm_dir, fabric_mod_name) - - input = raw_input("Would you like to add " + fabric_mod_name + " to drivers/target/Kconfig..? [yes,no]: ") - if input == "yes" or input == "y": - tcm_mod_add_kconfig(tcm_dir, fabric_mod_name) - - return - -parser = optparse.OptionParser() -parser.add_option('-m', '--modulename', help='Module name', dest='modname', - action='store', nargs=1, type='string') -parser.add_option('-p', '--protoident', help='Protocol Ident', dest='protoident', - action='store', nargs=1, type='string') - -(opts, args) = parser.parse_args() - -mandatories = ['modname', 'protoident'] -for m in mandatories: - if not opts.__dict__[m]: - print "mandatory option is missing\n" - parser.print_help() - exit(-1) - -if __name__ == "__main__": - - main(str(opts.modname), opts.protoident) diff --git a/Documentation/tools/rtla/common_options.rst b/Documentation/tools/rtla/common_options.rst index af76df6205d4..aeb91ff3bd68 100644 --- a/Documentation/tools/rtla/common_options.rst +++ b/Documentation/tools/rtla/common_options.rst @@ -2,6 +2,10 @@ Set the osnoise tracer to run the sample threads in the cpu-list. +**-H**, **--house-keeping** *cpu-list* + + Run rtla control threads only on the given cpu-list. + **-d**, **--duration** *time[s|m|h|d]* Set the duration of the session. @@ -42,6 +46,10 @@ - *f:prio* - use SCHED_FIFO with *prio*; - *d:runtime[us|ms|s]:period[us|ms|s]* - use SCHED_DEADLINE with *runtime* and *period* in nanoseconds. +**-C**, **--cgroup**\[*=cgroup*] + + Set a *cgroup* to the tracer's threads. If the **-C** option is passed without arguments, the tracer's thread will inherit **rtla**'s *cgroup*. Otherwise, the threads will be placed on the *cgroup* passed to the option. + **-h**, **--help** Print help menu. diff --git a/Documentation/tools/rtla/common_timerlat_aa.rst b/Documentation/tools/rtla/common_timerlat_aa.rst index 795b9fbcbc6d..077029e6b289 100644 --- a/Documentation/tools/rtla/common_timerlat_aa.rst +++ b/Documentation/tools/rtla/common_timerlat_aa.rst @@ -5,10 +5,3 @@ **--no-aa** disable auto-analysis, reducing rtla timerlat cpu usage - -**--aa-only** *us* - - Set stop tracing conditions and run without collecting and displaying statistics. - Print the auto-analysis if the system hits the stop tracing condition. This option - is useful to reduce rtla timerlat CPU, enabling the debug without the overhead of - collecting the statistics. diff --git a/Documentation/tools/rtla/common_timerlat_options.rst b/Documentation/tools/rtla/common_timerlat_options.rst index bacdea6de7a3..88506b397c2d 100644 --- a/Documentation/tools/rtla/common_timerlat_options.rst +++ b/Documentation/tools/rtla/common_timerlat_options.rst @@ -26,3 +26,10 @@ Set the /dev/cpu_dma_latency to *us*, aiming to bound exit from idle latencies. *cyclictest* sets this value to *0* by default, use **--dma-latency** *0* to have similar results. + +**-u**, **--user-threads** + + Set timerlat to run without a workload, and then dispatches user-space workloads + to wait on the timerlat_fd. Once the workload is awakes, it goes to sleep again + adding so the measurement for the kernel-to-user and user-to-kernel to the tracer + output. diff --git a/Documentation/tools/rtla/rtla-timerlat-hist.rst b/Documentation/tools/rtla/rtla-timerlat-hist.rst index 6bf7f0ca4556..057db78d4095 100644 --- a/Documentation/tools/rtla/rtla-timerlat-hist.rst +++ b/Documentation/tools/rtla/rtla-timerlat-hist.rst @@ -29,15 +29,18 @@ OPTIONS .. include:: common_options.rst +.. include:: common_timerlat_aa.rst + EXAMPLE ======= In the example below, **rtla timerlat hist** is set to run for *10* minutes, in the cpus *0-4*, *skipping zero* only lines. Moreover, **rtla timerlat hist** will change the priority of the *timerlat* threads to run under *SCHED_DEADLINE* priority, with a *10us* runtime every *1ms* period. The -*1ms* period is also passed to the *timerlat* tracer:: +*1ms* period is also passed to the *timerlat* tracer. Auto-analysis is disabled +to reduce overhead :: - [root@alien ~]# timerlat hist -d 10m -c 0-4 -P d:100us:1ms -p 1ms + [root@alien ~]# timerlat hist -d 10m -c 0-4 -P d:100us:1ms -p 1ms --no-aa # RTLA timerlat histogram # Time unit is microseconds (us) # Duration: 0 00:10:00 diff --git a/Documentation/tools/rtla/rtla-timerlat-top.rst b/Documentation/tools/rtla/rtla-timerlat-top.rst index 73799c1150ad..ab6cb60c9083 100644 --- a/Documentation/tools/rtla/rtla-timerlat-top.rst +++ b/Documentation/tools/rtla/rtla-timerlat-top.rst @@ -32,6 +32,13 @@ OPTIONS .. include:: common_timerlat_aa.rst +**--aa-only** *us* + + Set stop tracing conditions and run without collecting and displaying statistics. + Print the auto-analysis if the system hits the stop tracing condition. This option + is useful to reduce rtla timerlat CPU, enabling the debug without the overhead of + collecting the statistics. + EXAMPLE ======= @@ -110,7 +117,7 @@ syscall in a btrfs file system. The raw trace is saved in the **timerlat_trace.txt** file for further analysis. Note that **rtla timerlat** was dispatched without changing *timerlat* tracer -threads' priority. That is generally not needed because these threads hava +threads' priority. That is generally not needed because these threads have priority *FIFO:95* by default, which is a common priority used by real-time kernel developers to analyze scheduling delays. diff --git a/Documentation/trace/coresight/coresight-dummy.rst b/Documentation/trace/coresight/coresight-dummy.rst new file mode 100644 index 000000000000..eff7c553ee6c --- /dev/null +++ b/Documentation/trace/coresight/coresight-dummy.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================= +Coresight Dummy Trace Module +============================= + + :Author: Hao Zhang <quic_hazha@quicinc.com> + :Date: June 2023 + +Introduction +------------ + +The Coresight dummy trace module is for the specific devices that kernel don't +have permission to access or configure, e.g., CoreSight TPDMs on Qualcomm +platforms. For these devices, a dummy driver is needed to register them as +Coresight devices. The module may also be used to define components that may +not have any programming interfaces, so that paths can be created in the driver. +It provides Coresight API for operations on dummy devices, such as enabling and +disabling them. It also provides the Coresight dummy sink/source paths for +debugging. + +Config details +-------------- + +There are two types of nodes, dummy sink and dummy source. These nodes +are available at ``/sys/bus/coresight/devices``. + +Example output:: + + $ ls -l /sys/bus/coresight/devices | grep dummy + dummy_sink0 -> ../../../devices/platform/soc@0/soc@0:sink/dummy_sink0 + dummy_source0 -> ../../../devices/platform/soc@0/soc@0:source/dummy_source0 diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst index 70e34b8c81c1..89ac4e6fc96f 100644 --- a/Documentation/trace/coresight/coresight-etm4x-reference.rst +++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst @@ -675,7 +675,7 @@ Bit assignments shown below:- reconstructed using only conditional branches. There is currently no support in Perf for supplying modified binaries to the decoder, so this - feature is only inteded to be used for debugging purposes or with a 3rd party tool. + feature is only intended to be used for debugging purposes or with a 3rd party tool. Choosing this option will result in a significant increase in the amount of trace generated - possible danger of overflows, or fewer instructions covered. Note, that this option also diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst index f5fcb8e1218f..759907c20e75 100644 --- a/Documentation/trace/events.rst +++ b/Documentation/trace/events.rst @@ -219,6 +219,20 @@ the function "security_prepare_creds" and less than the end of that function. The ".function" postfix can only be attached to values of size long, and can only be compared with "==" or "!=". +Cpumask fields or scalar fields that encode a CPU number can be filtered using +a user-provided cpumask in cpulist format. The format is as follows:: + + CPUS{$cpulist} + +Operators available to cpumask filtering are: + +& (intersection), ==, != + +For example, this will filter events that have their .target_cpu field present +in the given cpumask:: + + target_cpu & CPUS{17-42} + 5.2 Setting filters ------------------- @@ -915,7 +929,7 @@ functions can be used. To create a kprobe event, an empty or partially empty kprobe event should first be created using kprobe_event_gen_cmd_start(). The name -of the event and the probe location should be specfied along with one +of the event and the probe location should be specified along with one or args each representing a probe field should be supplied to this function. Before calling kprobe_event_gen_cmd_start(), the user should create and initialize a dynevent_cmd object using @@ -995,7 +1009,7 @@ The basic idea is simple and amounts to providing a general-purpose layer that can be used to generate trace event commands. The generated command strings can then be passed to the command-parsing and event creation code that already exists in the trace event -subystem for creating the corresponding trace events. +subsystem for creating the corresponding trace events. In a nutshell, the way it works is that the higher-level interface code creates a struct dynevent_cmd object, then uses a couple @@ -1068,7 +1082,7 @@ to add an operator between the pair (here none) and a separator to be appended onto the end of the arg pair (here ';'). There's also a dynevent_str_add() function that can be used to simply -add a string as-is, with no spaces, delimeters, or arg check. +add a string as-is, with no spaces, delimiters, or arg check. Any number of dynevent_*_add() calls can be made to build up the string (until its length surpasses cmd->maxlen). When all the arguments have diff --git a/Documentation/trace/fprobe.rst b/Documentation/trace/fprobe.rst index 40dd2fbce861..7a895514b537 100644 --- a/Documentation/trace/fprobe.rst +++ b/Documentation/trace/fprobe.rst @@ -113,7 +113,7 @@ If the entry callback function returns !0, the corresponding exit callback will 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 currect return address. + pointer of @regs is set to the current return address. @entry_data This is a local storage to share the data between entry and exit handlers. diff --git a/Documentation/trace/fprobetrace.rst b/Documentation/trace/fprobetrace.rst new file mode 100644 index 000000000000..8e9bebcf0a2e --- /dev/null +++ b/Documentation/trace/fprobetrace.rst @@ -0,0 +1,216 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +Fprobe-based Event Tracing +========================== + +.. Author: Masami Hiramatsu <mhiramat@kernel.org> + +Overview +-------- + +Fprobe event is similar to the kprobe event, but limited to probe on +the function entry and exit only. It is good enough for many use cases +which only traces some specific functions. + +This document also covers tracepoint probe events (tprobe) since this +is also works only on the tracepoint entry. User can trace a part of +tracepoint argument, or the tracepoint without trace-event, which is +not exposed on tracefs. + +As same as other dynamic events, fprobe events and tracepoint probe +events are defined via `dynamic_events` interface file on tracefs. + +Synopsis of fprobe-events +------------------------- +:: + + f[:[GRP1/][EVENT1]] SYM [FETCHARGS] : Probe on function entry + f[MAXACTIVE][:[GRP1/][EVENT1]] SYM%return [FETCHARGS] : Probe on function exit + t[:[GRP2/][EVENT2]] TRACEPOINT [FETCHARGS] : Probe on tracepoint + + GRP1 : Group name for fprobe. If omitted, use "fprobes" for it. + GRP2 : Group name for tprobe. If omitted, use "tracepoints" for it. + EVENT1 : Event name for fprobe. If omitted, the event name is + "SYM__entry" or "SYM__exit". + EVENT2 : Event name for tprobe. If omitted, the event name is + the same as "TRACEPOINT", but if the "TRACEPOINT" starts + with a digit character, "_TRACEPOINT" is used. + MAXACTIVE : Maximum number of instances of the specified function that + can be probed simultaneously, or 0 for the default value + as defined in Documentation/trace/fprobe.rst + + FETCHARGS : Arguments. Each probe can have up to 128 args. + ARG : Fetch "ARG" function argument using BTF (only for function + entry or tracepoint.) (\*1) + @ADDR : Fetch memory at ADDR (ADDR should be in kernel) + @SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol) + $stackN : Fetch Nth entry of stack (N >= 0) + $stack : Fetch stack address. + $argN : Fetch the Nth function argument. (N >= 1) (\*2) + $retval : Fetch return value.(\*3) + $comm : Fetch current task comm. + +|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*4)(\*5) + \IMM : Store an immediate value to the argument. + NAME=FETCHARG : Set NAME as the argument name of FETCHARG. + FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types + (u8/u16/u32/u64/s8/s16/s32/s64), hexadecimal types + (x8/x16/x32/x64), "char", "string", "ustring", "symbol", "symstr" + and bitfield are supported. + + (\*1) This is available only when BTF is enabled. + (\*2) only for the probe on function entry (offs == 0). + (\*3) only for return probe. + (\*4) this is useful for fetching a field of data structures. + (\*5) "u" means user-space dereference. + +For the details of TYPE, see :ref:`kprobetrace documentation <kprobetrace_types>`. + +BTF arguments +------------- +BTF (BPF Type Format) argument allows user to trace function and tracepoint +parameters by its name instead of ``$argN``. This feature is available if the +kernel is configured with CONFIG_BPF_SYSCALL and CONFIG_DEBUG_INFO_BTF. +If user only specify the BTF argument, the event's argument name is also +automatically set by the given name. :: + + # echo 'f:myprobe vfs_read count pos' >> dynamic_events + # cat dynamic_events + f:fprobes/myprobe vfs_read count=count pos=pos + +It also chooses the fetch type from BTF information. For example, in the above +example, the ``count`` is unsigned long, and the ``pos`` is a pointer. Thus, +both are converted to 64bit unsigned long, but only ``pos`` has "%Lx" +print-format as below :: + + # cat events/fprobes/myprobe/format + name: myprobe + ID: 1313 + format: + field:unsigned short common_type; offset:0; size:2; signed:0; + field:unsigned char common_flags; offset:2; size:1; signed:0; + field:unsigned char common_preempt_count; offset:3; size:1; signed:0; + field:int common_pid; offset:4; size:4; signed:1; + + field:unsigned long __probe_ip; offset:8; size:8; signed:0; + field:u64 count; offset:16; size:8; signed:0; + field:u64 pos; offset:24; size:8; signed:0; + + print fmt: "(%lx) count=%Lu pos=0x%Lx", REC->__probe_ip, REC->count, REC->pos + +If user unsures the name of arguments, ``$arg*`` will be helpful. The ``$arg*`` +is expanded to all function arguments of the function or the tracepoint. :: + + # echo 'f:myprobe vfs_read $arg*' >> dynamic_events + # cat dynamic_events + f:fprobes/myprobe vfs_read file=file buf=buf count=count pos=pos + +BTF also affects the ``$retval``. If user doesn't set any type, the retval +type is automatically picked from the BTF. If the function returns ``void``, +``$retval`` is rejected. + +You can access the data fields of a data structure using allow operator ``->`` +(for pointer type) and dot operator ``.`` (for data structure type.):: + +# echo 't sched_switch preempt prev_pid=prev->pid next_pid=next->pid' >> dynamic_events + +The field access operators, ``->`` and ``.`` can be combined for accessing deeper +members and other structure members pointed by the member. e.g. ``foo->bar.baz->qux`` +If there is non-name union member, you can directly access it as the C code does. +For example:: + + struct { + union { + int a; + int b; + }; + } *foo; + +To access ``a`` and ``b``, use ``foo->a`` and ``foo->b`` in this case. + +This data field access is available for the return value via ``$retval``, +e.g. ``$retval->name``. + +For these BTF arguments and fields, ``:string`` and ``:ustring`` change the +behavior. If these are used for BTF argument or field, it checks whether +the BTF type of the argument or the data field is ``char *`` or ``char []``, +or not. If not, it rejects applying the string types. Also, with the BTF +support, you don't need a memory dereference operator (``+0(PTR)``) for +accessing the string pointed by a ``PTR``. It automatically adds the memory +dereference operator according to the BTF type. e.g. :: + +# echo 't sched_switch prev->comm:string' >> dynamic_events +# echo 'f getname_flags%return $retval->name:string' >> dynamic_events + +The ``prev->comm`` is an embedded char array in the data structure, and +``$retval->name`` is a char pointer in the data structure. But in both +cases, you can use ``:string`` type to get the string. + + +Usage examples +-------------- +Here is an example to add fprobe events on ``vfs_read()`` function entry +and exit, with BTF arguments. +:: + + # echo 'f vfs_read $arg*' >> dynamic_events + # echo 'f vfs_read%return $retval' >> dynamic_events + # cat dynamic_events + f:fprobes/vfs_read__entry vfs_read file=file buf=buf count=count pos=pos + f:fprobes/vfs_read__exit vfs_read%return arg1=$retval + # echo 1 > events/fprobes/enable + # head -n 20 trace | tail + # TASK-PID CPU# ||||| TIMESTAMP FUNCTION + # | | | ||||| | | + sh-70 [000] ...1. 335.883195: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c6879 count=1 pos=0xffffc900005aff08 + sh-70 [000] ..... 335.883208: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1 + sh-70 [000] ...1. 335.883220: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c6879 count=1 pos=0xffffc900005aff08 + sh-70 [000] ..... 335.883224: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1 + sh-70 [000] ...1. 335.883232: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c687a count=1 pos=0xffffc900005aff08 + sh-70 [000] ..... 335.883237: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1 + sh-70 [000] ...1. 336.050329: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c6879 count=1 pos=0xffffc900005aff08 + sh-70 [000] ..... 336.050343: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1 + +You can see all function arguments and return values are recorded as signed int. + +Also, here is an example of tracepoint events on ``sched_switch`` tracepoint. +To compare the result, this also enables the ``sched_switch`` traceevent too. +:: + + # echo 't sched_switch $arg*' >> dynamic_events + # echo 1 > events/sched/sched_switch/enable + # echo 1 > events/tracepoints/sched_switch/enable + # echo > trace + # head -n 20 trace | tail + # TASK-PID CPU# ||||| TIMESTAMP FUNCTION + # | | | ||||| | | + sh-70 [000] d..2. 3912.083993: sched_switch: prev_comm=sh prev_pid=70 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120 + sh-70 [000] d..3. 3912.083995: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffff88800664e100 next=0xffffffff828229c0 prev_state=1 + <idle>-0 [000] d..2. 3912.084183: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcu_preempt next_pid=16 next_prio=120 + <idle>-0 [000] d..3. 3912.084184: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffffffff828229c0 next=0xffff888004208000 prev_state=0 + rcu_preempt-16 [000] d..2. 3912.084196: sched_switch: prev_comm=rcu_preempt prev_pid=16 prev_prio=120 prev_state=I ==> next_comm=swapper/0 next_pid=0 next_prio=120 + rcu_preempt-16 [000] d..3. 3912.084196: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffff888004208000 next=0xffffffff828229c0 prev_state=1026 + <idle>-0 [000] d..2. 3912.085191: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcu_preempt next_pid=16 next_prio=120 + <idle>-0 [000] d..3. 3912.085191: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffffffff828229c0 next=0xffff888004208000 prev_state=0 + +As you can see, the ``sched_switch`` trace-event shows *cooked* parameters, on +the other hand, the ``sched_switch`` tracepoint probe event shows *raw* +parameters. This means you can access any field values in the task +structure pointed by the ``prev`` and ``next`` arguments. + +For example, usually ``task_struct::start_time`` is not traced, but with this +traceprobe event, you can trace that field as below. +:: + + # echo 't sched_switch comm=next->comm:string next->start_time' > dynamic_events + # head -n 20 trace | tail + # TASK-PID CPU# ||||| TIMESTAMP FUNCTION + # | | | ||||| | | + sh-70 [000] d..3. 5606.686577: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="rcu_preempt" usage=1 start_time=245000000 + rcu_preempt-16 [000] d..3. 5606.686602: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="sh" usage=1 start_time=1596095526 + sh-70 [000] d..3. 5606.686637: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="swapper/0" usage=2 start_time=0 + <idle>-0 [000] d..3. 5606.687190: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="rcu_preempt" usage=1 start_time=245000000 + rcu_preempt-16 [000] d..3. 5606.687202: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="swapper/0" usage=2 start_time=0 + <idle>-0 [000] d..3. 5606.690317: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="kworker/0:1" usage=1 start_time=137000000 + kworker/0:1-14 [000] d..3. 5606.690339: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="swapper/0" usage=2 start_time=0 + <idle>-0 [000] d..3. 5606.692368: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="kworker/0:1" usage=1 start_time=137000000 diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index 027437b745a0..23572f6697c0 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -324,6 +324,12 @@ of ftrace. Here is a list of some of the key files: "set_graph_function", or "set_graph_notrace". (See the section "dynamic ftrace" below for more details.) + available_filter_functions_addrs: + + Similar to available_filter_functions, but with address displayed + for each function. The displayed address is the patch-site address + and can differ from /proc/kallsyms address. + dyn_ftrace_total_info: This file is for debugging purposes. The number of functions that @@ -1359,6 +1365,19 @@ Options for function_graph tracer: only a closing curly bracket "}" is displayed for the return of a function. + funcgraph-retval + When set, the return value of each traced function + will be printed after an equal sign "=". By default + this is off. + + funcgraph-retval-hex + When set, the return value will always be printed + in hexadecimal format. If the option is not set and + the return value is an error code, it will be printed + in signed decimal format; otherwise it will also be + printed in hexadecimal format. By default, this option + is off. + sleep-time When running function graph tracer, to include the time a task schedules out in its function. @@ -2704,6 +2723,119 @@ It is default disabled. 0) 1.757 us | } /* kmem_cache_free() */ 0) 2.861 us | } /* putname() */ +The return value of each traced function can be displayed after +an equal sign "=". When encountering system call failures, it +can be very helpful to quickly locate the function that first +returns an error code. + + - hide: echo nofuncgraph-retval > trace_options + - show: echo funcgraph-retval > trace_options + + Example with funcgraph-retval:: + + 1) | cgroup_migrate() { + 1) 0.651 us | cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */ + 1) | cgroup_migrate_execute() { + 1) | cpu_cgroup_can_attach() { + 1) | cgroup_taskset_first() { + 1) 0.732 us | cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */ + 1) 1.232 us | } /* cgroup_taskset_first = 0xffff93fc8fb20000 */ + 1) 0.380 us | sched_rt_can_attach(); /* = 0x0 */ + 1) 2.335 us | } /* cpu_cgroup_can_attach = -22 */ + 1) 4.369 us | } /* cgroup_migrate_execute = -22 */ + 1) 7.143 us | } /* cgroup_migrate = -22 */ + +The above example shows that the function cpu_cgroup_can_attach +returned the error code -22 firstly, then we can read the code +of this function to get the root cause. + +When the option funcgraph-retval-hex is not set, the return value can +be displayed in a smart way. Specifically, if it is an error code, +it will be printed in signed decimal format, otherwise it will +printed in hexadecimal format. + + - smart: echo nofuncgraph-retval-hex > trace_options + - hexadecimal: echo funcgraph-retval-hex > trace_options + + Example with funcgraph-retval-hex:: + + 1) | cgroup_migrate() { + 1) 0.651 us | cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */ + 1) | cgroup_migrate_execute() { + 1) | cpu_cgroup_can_attach() { + 1) | cgroup_taskset_first() { + 1) 0.732 us | cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */ + 1) 1.232 us | } /* cgroup_taskset_first = 0xffff93fc8fb20000 */ + 1) 0.380 us | sched_rt_can_attach(); /* = 0x0 */ + 1) 2.335 us | } /* cpu_cgroup_can_attach = 0xffffffea */ + 1) 4.369 us | } /* cgroup_migrate_execute = 0xffffffea */ + 1) 7.143 us | } /* cgroup_migrate = 0xffffffea */ + +At present, there are some limitations when using the funcgraph-retval +option, and these limitations will be eliminated in the future: + +- Even if the function return type is void, a return value will still + be printed, and you can just ignore it. + +- Even if return values are stored in multiple registers, only the + value contained in the first register will be recorded and printed. + To illustrate, in the x86 architecture, eax and edx are used to store + a 64-bit return value, with the lower 32 bits saved in eax and the + upper 32 bits saved in edx. However, only the value stored in eax + will be recorded and printed. + +- In certain procedure call standards, such as arm64's AAPCS64, when a + type is smaller than a GPR, it is the responsibility of the consumer + to perform the narrowing, and the upper bits may contain UNKNOWN values. + Therefore, it is advisable to check the code for such cases. For instance, + when using a u8 in a 64-bit GPR, bits [63:8] may contain arbitrary values, + especially when larger types are truncated, whether explicitly or implicitly. + Here are some specific cases to illustrate this point: + + **Case One**: + + The function narrow_to_u8 is defined as follows:: + + u8 narrow_to_u8(u64 val) + { + // implicitly truncated + return val; + } + + It may be compiled to:: + + narrow_to_u8: + < ... ftrace instrumentation ... > + RET + + If you pass 0x123456789abcdef to this function and want to narrow it, + it may be recorded as 0x123456789abcdef instead of 0xef. + + **Case Two**: + + The function error_if_not_4g_aligned is defined as follows:: + + int error_if_not_4g_aligned(u64 val) + { + if (val & GENMASK(31, 0)) + return -EINVAL; + + return 0; + } + + It could be compiled to:: + + error_if_not_4g_aligned: + CBNZ w0, .Lnot_aligned + RET // bits [31:0] are zero, bits + // [63:32] are UNKNOWN + .Lnot_aligned: + MOV x0, #-EINVAL + RET + + When passing 0x2_0000_0000 to it, the return value may be recorded as + 0x2_0000_0000 instead of 0. + You can put some comments on specific functions by using trace_printk() For example, if you want to put a comment inside the __might_sleep() function, you just have to include diff --git a/Documentation/trace/hisi-ptt.rst b/Documentation/trace/hisi-ptt.rst index 4f87d8e21065..989255eb5622 100644 --- a/Documentation/trace/hisi-ptt.rst +++ b/Documentation/trace/hisi-ptt.rst @@ -148,14 +148,20 @@ For example, if the desired filter is Endpoint function 0000:01:00.1 the filter value will be 0x00101. If the desired filter is Root Port 0000:00:10.0 then then filter value is calculated as 0x80001. +The driver also presents every supported Root Port and Requester filter through +sysfs. Each filter will be an individual file with name of its related PCIe +device name (domain:bus:device.function). The files of Root Port filters are +under $(PTT PMU dir)/root_port_filters and files of Requester filters +are under $(PTT PMU dir)/requester_filters. + Note that multiple Root Ports can be specified at one time, but only one Endpoint function can be specified in one trace. Specifying both Root Port and function at the same time is not supported. Driver maintains a list of available filters and will check the invalid inputs. -Currently the available filters are detected in driver's probe. If the supported -devices are removed/added after probe, you may need to reload the driver to update -the filters. +The available filters will be dynamically updated, which means you will always +get correct filter information when hotplug events happen, or when you manually +remove/rescan the devices. 2. Type ------- diff --git a/Documentation/trace/hwlat_detector.rst b/Documentation/trace/hwlat_detector.rst index de94b499b0bc..11b749c2a8bd 100644 --- a/Documentation/trace/hwlat_detector.rst +++ b/Documentation/trace/hwlat_detector.rst @@ -14,7 +14,7 @@ originally written for use by the "RT" patch since the Real Time kernel is highly latency sensitive. SMIs are not serviced by the Linux kernel, which means that it does not -even know that they are occuring. SMIs are instead set up by BIOS code +even know that they are occurring. SMIs are instead set up by BIOS code and are serviced by BIOS code, usually for "critical" events such as management of thermal sensors and fans. Sometimes though, SMIs are used for other tasks and those tasks can spend an inordinate amount of time in the diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst index ea25a9220f92..5092d6c13af5 100644 --- a/Documentation/trace/index.rst +++ b/Documentation/trace/index.rst @@ -13,6 +13,7 @@ Linux Tracing Technologies kprobes kprobetrace uprobetracer + fprobetrace tracepoints events events-kmem diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst index 651f9ab53f3e..8a2dfee38145 100644 --- a/Documentation/trace/kprobetrace.rst +++ b/Documentation/trace/kprobetrace.rst @@ -66,6 +66,8 @@ Synopsis of kprobe_events (\*3) this is useful for fetching a field of data structures. (\*4) "u" means user-space dereference. See :ref:`user_mem_access`. +.. _kprobetrace_types: + Types ----- Several types are supported for fetchargs. Kprobe tracer will access memory diff --git a/Documentation/trace/rv/da_monitor_synthesis.rst b/Documentation/trace/rv/da_monitor_synthesis.rst index 0dbdcd1e62b9..0a92729c8a9b 100644 --- a/Documentation/trace/rv/da_monitor_synthesis.rst +++ b/Documentation/trace/rv/da_monitor_synthesis.rst @@ -1,7 +1,7 @@ Deterministic Automata Monitor Synthesis ======================================== -The starting point for the application of runtime verification (RV) technics +The starting point for the application of runtime verification (RV) techniques is the *specification* or *modeling* of the desired (or undesired) behavior of the system under scrutiny. diff --git a/Documentation/trace/rv/monitor_wwnr.rst b/Documentation/trace/rv/monitor_wwnr.rst index 80f1777b85aa..9f739030f826 100644 --- a/Documentation/trace/rv/monitor_wwnr.rst +++ b/Documentation/trace/rv/monitor_wwnr.rst @@ -26,7 +26,7 @@ definition:: | running | -+ +-------------+ -This model is borken, the reason is that a task can be running +This model is broken, the reason is that a task can be running in the processor without being set as RUNNABLE. Think about a task about to sleep:: diff --git a/Documentation/trace/rv/runtime-verification.rst b/Documentation/trace/rv/runtime-verification.rst index c46b6149470e..dae78dfa7cdc 100644 --- a/Documentation/trace/rv/runtime-verification.rst +++ b/Documentation/trace/rv/runtime-verification.rst @@ -31,7 +31,7 @@ In Linux terms, the runtime verification monitors are encapsulated inside the *RV monitor* abstraction. A *RV monitor* includes a reference model of the system, a set of instances of the monitor (per-cpu monitor, per-task monitor, and so on), and the helper functions that glue the monitor to the system via -trace, as depicted bellow:: +trace, as depicted below:: Linux +---- RV Monitor ----------------------------------+ Formal Realm | | Realm diff --git a/Documentation/trace/timerlat-tracer.rst b/Documentation/trace/timerlat-tracer.rst index db17df312bc8..53a56823e903 100644 --- a/Documentation/trace/timerlat-tracer.rst +++ b/Documentation/trace/timerlat-tracer.rst @@ -180,3 +180,81 @@ dummy_load_1ms_pd_init, which had the following code (on purpose):: return 0; } + +User-space interface +--------------------------- + +Timerlat allows user-space threads to use timerlat infra-structure to +measure scheduling latency. This interface is accessible via a per-CPU +file descriptor inside $tracing_dir/osnoise/per_cpu/cpu$ID/timerlat_fd. + +This interface is accessible under the following conditions: + + - timerlat tracer is enable + - osnoise workload option is set to NO_OSNOISE_WORKLOAD + - The user-space thread is affined to a single processor + - The thread opens the file associated with its single processor + - Only one thread can access the file at a time + +The open() syscall will fail if any of these conditions are not met. +After opening the file descriptor, the user space can read from it. + +The read() system call will run a timerlat code that will arm the +timer in the future and wait for it as the regular kernel thread does. + +When the timer IRQ fires, the timerlat IRQ will execute, report the +IRQ latency and wake up the thread waiting in the read. The thread will be +scheduled and report the thread latency via tracer - as for the kernel +thread. + +The difference from the in-kernel timerlat is that, instead of re-arming +the timer, timerlat will return to the read() system call. At this point, +the user can run any code. + +If the application rereads the file timerlat file descriptor, the tracer +will report the return from user-space latency, which is the total +latency. If this is the end of the work, it can be interpreted as the +response time for the request. + +After reporting the total latency, timerlat will restart the cycle, arm +a timer, and go to sleep for the following activation. + +If at any time one of the conditions is broken, e.g., the thread migrates +while in user space, or the timerlat tracer is disabled, the SIG_KILL +signal will be sent to the user-space thread. + +Here is an basic example of user-space code for timerlat:: + + int main(void) + { + char buffer[1024]; + int timerlat_fd; + int retval; + long cpu = 0; /* place in CPU 0 */ + cpu_set_t set; + + CPU_ZERO(&set); + CPU_SET(cpu, &set); + + if (sched_setaffinity(gettid(), sizeof(set), &set) == -1) + return 1; + + snprintf(buffer, sizeof(buffer), + "/sys/kernel/tracing/osnoise/per_cpu/cpu%ld/timerlat_fd", + cpu); + + timerlat_fd = open(buffer, O_RDONLY); + if (timerlat_fd < 0) { + printf("error opening %s: %s\n", buffer, strerror(errno)); + exit(1); + } + + for (;;) { + retval = read(timerlat_fd, buffer, 1024); + if (retval < 0) + break; + } + + close(timerlat_fd); + exit(0); + } diff --git a/Documentation/trace/uprobetracer.rst b/Documentation/trace/uprobetracer.rst index 122d15572fd5..01f6a780fb04 100644 --- a/Documentation/trace/uprobetracer.rst +++ b/Documentation/trace/uprobetracer.rst @@ -55,7 +55,7 @@ Synopsis of uprobe_tracer (\*1) only for return probe. (\*2) this is useful for fetching a field of data structures. - (\*3) Unlike kprobe event, "u" prefix will just be ignored, becuse uprobe + (\*3) Unlike kprobe event, "u" prefix will just be ignored, because uprobe events can access only user-space memory. Types diff --git a/Documentation/trace/user_events.rst b/Documentation/trace/user_events.rst index e7b07313550a..f9530d0ac5d3 100644 --- a/Documentation/trace/user_events.rst +++ b/Documentation/trace/user_events.rst @@ -93,7 +93,7 @@ or perf record -e user_events:[name] when attaching/recording. **NOTE:** The event subsystem name by default is "user_events". Callers should not assume it will always be "user_events". Operators reserve the right in the -future to change the subsystem name per-process to accomodate event isolation. +future to change the subsystem name per-process to accommodate event isolation. Command Format ^^^^^^^^^^^^^^ diff --git a/Documentation/translations/sp_SP/process/contribution-maturity-model.rst b/Documentation/translations/sp_SP/process/contribution-maturity-model.rst new file mode 100644 index 000000000000..cc052ae8183d --- /dev/null +++ b/Documentation/translations/sp_SP/process/contribution-maturity-model.rst @@ -0,0 +1,120 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/contribution-maturity-model.rst +:Translator: Avadhut Naik <avadhut.naik@amd.com> + +==================================================== +Modelo de Madurez de Contribución al Kernel de Linux +==================================================== + + +Los Antecedentes +================ + +Como parte de la cumbre de mantenedores del kernel de Linux 2021, hubo +una `discusión <https://lwn.net/Articles/870581/>`_ sobre los desafíos +en el reclutamiento de mantenedores del kernel, así como la sucesión de +los mantenedores. Algunas de las conclusiones de esa discusión incluyeron +que las empresas que forman parte de la comunidad del kernel de Linux +necesitan permitir que los ingenieros sean mantenedores como parte de su +trabajo, para que puedan convertirse en lideres respetados y finalmente, +en mantenedores del kernel. Para apoyar una fuente solida de talento, se +debe permitir y alentar a los desarrolladores a asumir contribuciones +upstream, como revisar los parches de otras personas, reestructurar la +infraestructura del kernel y escribir documentación. + +Con ese fin, Technical Advisory Board (TAB) de la Fundación Linux propone +este Modelo de Madurez de Contribución al Kernel de Linux. Estas +expectativas comunes para la participación con la comunidad upstream +tienen como objetivo aumentar la influencia de los desarrolladores +individuales, aumentar la colaboración de las organizaciones y mejorar +la salud general del ecosistema del kernel de Linux. + +El TAB insta a las organizaciones a evaluar continuamente su modelo de +madurez de Código Abierto y comprometerse a realizar mejoras para +alinearse con este modelo. Para ser eficaz, esta evaluación debe +incorporar la reacción de toda la organización, incluyendo la gerencia +y los desarrolladores en todos los niveles de antigüedad. En el espíritu +de Código Abierto, alentamos a las organizaciones a publicar sus +evaluaciones y planes para mejorar su participación con la comunidad +upstream. + +Nivel 0 +======= + +* A los ingenieros de software no se les permite contribuir con parches + al kernel de Linux. + +Nivel 1 +======= + +* A los ingenieros de software se les permite contribuir con parches al + kernel de Linux, ya sea como parte de sus responsabilidades de trabajo + o en su propio tiempo. + +Nivel 2 +======= + +* Se espera que los ingenieros de software contribuyan al kernel de Linux + como parte de sus responsabilidades de trabajo. +* Se proporcionará apoyo a los ingenieros de software para asistir a + conferencias relacionadas con Linux como parte de su trabajo. +* Las contribuciones de código upstream de un ingeniero de software se + considerarán en la promoción y las revisiones de rendimiento. + +Nivel 3 +======= + +* Se espera que los ingenieros de software revisen los parches (incluidos + los parches escritos por ingenieros de otras empresas) como parte de + sus responsabilidades de trabajo. +* Contribuir con presentaciones o ponencias a conferencias relacionadas + con Linux o académicas (como las organizadas por la Fundación Linux, + Usenix, ACM, etc.), se consideran parte del trabajo de un ingeniero. +* Las contribuciones a la comunidad de un ingeniero de software se + considerarán en la promoción y las revisiones de rendimiento. +* Las organizaciones informarán regularmente sobre las métricas de sus + contribuciones de código abierto y harán un seguimiento de estas + métricas a lo largo del tiempo. Estas métricas pueden publicarse + solo internamente dentro de la organización, o a discreción de la + organización, algunas o todas pueden publicarse externamente. Las + métricas que se sugieren encarecidamente incluyen: + + * El número de contribuciones al kernel upstream por equipo u + organización (por ejemplo, todas las personas que reportan a un + gerente o director o vicepresidente). + * El porcentaje de desarrolladores del kernel que han realizado + contribuciones upstream relativo al total de desarrolladores + del kernel en la organización. + * El intervalo de tiempo entre los kernels utilizados en los servidores + y/o productos de la organización y la fecha de publicación del kernel + upstream en el que se basa el kernel interno. + * El número de commits fuera del árbol de desarrollo presentes en los + kernels internos. + +Nivel 4 +======= + +* Se anima a los ingenieros de software a pasar una parte de su tiempo de + trabajo centrado en el Trabajo Ascendente, que se define como revisar + parches, servir en los comités de programas, mejorar la infraestructura + del proyecto central como escribir o mantener pruebas, reducir la deuda + de tecnología upstream, escribir documentación, etc. +* Los ingenieros de software son apoyados para ayudar a organizar + conferencias relacionadas con Linux. +* Las organizaciones considerarán los comentarios de los miembros de la + comunidad en las revisiones oficiales de rendimiento. + +Nivel 5 +======= + +* El desarrollo del kernel upstream se considera un puesto de trabajo + formal, con al menos un tercio del tiempo del ingeniero pasado a hacer + el Trabajo Ascendente. +* Las organizaciones buscarán activamente las reacciones de los miembros + de la comunidad como un factor en las revisiones oficiales de + rendimiento. +* Las organizaciones informarán regularmente internamente sobre la ratio + de trabajo upstream a trabajo enfocado en perseguir directamente los + objetivos comerciales. diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst index 0bdeb1eb4403..09bfece0f52f 100644 --- a/Documentation/translations/sp_SP/process/index.rst +++ b/Documentation/translations/sp_SP/process/index.rst @@ -20,3 +20,5 @@ programming-language deprecated adding-syscalls + researcher-guidelines + contribution-maturity-model diff --git a/Documentation/translations/sp_SP/process/researcher-guidelines.rst b/Documentation/translations/sp_SP/process/researcher-guidelines.rst new file mode 100644 index 000000000000..462b3290b7b8 --- /dev/null +++ b/Documentation/translations/sp_SP/process/researcher-guidelines.rst @@ -0,0 +1,150 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Original: :ref:`Documentation/process/researcher-guidelines.rst` +:Translator: Avadhut Naik <avadhut.naik@amd.com> + +Directrices para Investigadores +++++++++++++++++++++++++++++++++ + +La comunidad del kernel de Linux da la bienvenida a la investigación +transparente sobre el kernel de Linux, las actividades involucradas +en su producción, otros subproductos de su desarrollo. Linux se +beneficia mucho de este tipo de investigación, y la mayoría de los +aspectos de Linux son impulsados por investigación en una forma u otra. + +La comunidad agradece mucho si los investigadores pueden compartir +los hallazgos preliminares antes de hacer públicos sus resultados, +especialmente si tal investigación involucra seguridad. Involucrarse +temprano ayuda a mejorar la calidad de investigación y la capacidad +de Linux para mejorar a partir de ella. En cualquier caso, se recomienda +compartir copias de acceso abierto de la investigación publicada con +la comunidad. + +Este documento busca clarificar lo que la comunidad del kernel de Linux +considera practicas aceptables y no aceptables al llevar a cabo +investigación de este tipo. Por lo menos, dicha investigación y +actividades afines deben seguir las reglas estándar de ética de la +investigación. Para más información sobre la ética de la investigación +en general, ética en la tecnología y la investigación de las comunidades +de desarrolladores en particular, ver: + + +* `Historia de la Ética en la Investigación <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_ +* `Ética de la IEEE <https://www.ieee.org/about/ethics/index.html>`_ +* `Perspectivas de Desarrolladores e Investigadores sobre la Ética de los Experimentos en Proyectos de Código Abierto <https://arxiv.org/pdf/2112.13217.pdf>`_ + +La comunidad del kernel de Linux espera que todos los que interactúan con +el proyecto están participando en buena fe para mejorar Linux. La +investigación sobre cualquier artefacto disponible públicamente (incluido, +pero no limitado a código fuente) producido por la comunidad del kernel +de Linux es bienvenida, aunque la investigación sobre los desarrolladores +debe ser claramente opcional. + +La investigación pasiva que se basa completamente en fuentes disponibles +públicamente, incluidas las publicaciones en listas de correo públicas y +las contribuciones a los repositorios públicos, es claramente permitida. +Aunque, como con cualquier investigación, todavía se debe seguir la ética +estándar. + +La investigación activa sobre el comportamiento de los desarrolladores, +sin embargo, debe hacerse con el acuerdo explícito y la divulgación +completa a los desarrolladores individuales involucrados. No se puede +interactuar / experimentar con los desarrolladores sin consentimiento; +esto también es ética de investigación estándar. + +Para ayudar a aclarar: enviar parches a los desarrolladores es interactuar +con ellos, pero ya han dado su consentimiento para recibir contribuciones +en buena fe. No se ha dado consentimiento para enviar parches intencionalmente +defectuosos / vulnerables o contribuir con la información engañosa a las +discusiones. Dicha comunicación puede ser perjudicial al desarrollador (por +ejemplo, agotar el tiempo, el esfuerzo, y la moral) y perjudicial para el +proyecto al erosionar la confianza de toda la comunidad de desarrolladores en +el colaborador (y la organización del colaborador en conjunto), socavando +los esfuerzos para proporcionar reacciones constructivas a los colaboradores +y poniendo a los usuarios finales en riesgo de fallas de software. + +La participación en el desarrollo de Linux en sí mismo por parte de +investigadores, como con cualquiera, es bienvenida y alentada. La +investigación del código de Linux es una práctica común, especialmente +cuando se trata de desarrollar o ejecutar herramientas de análisis que +producen resultados procesables. + +Cuando se interactúa con la comunidad de desarrolladores, enviar un +parche ha sido tradicionalmente la mejor manera para hacer un impacto. +Linux ya tiene muchos errores conocidos – lo que es mucho más útil es +tener soluciones verificadas. Antes de contribuir, lea cuidadosamente +la documentación adecuada. + +* Documentation/process/development-process.rst +* Documentation/process/submitting-patches.rst +* Documentation/admin-guide/reporting-issues.rst +* Documentation/process/security-bugs.rst + +Entonces envíe un parche (incluyendo un registro de confirmación con +todos los detalles enumerados abajo) y haga un seguimiento de cualquier +comentario de otros desarrolladores. + +* ¿Cuál es el problema específico que se ha encontrado? +* ¿Como podría llegar al problema en un sistema en ejecución? +* ¿Qué efecto tendría encontrar el problema en el sistema? +* ¿Como se encontró el problema? Incluya específicamente detalles sobre + cualquier prueba, programas de análisis estáticos o dinámicos, y cualquier + otra herramienta o método utilizado para realizar el trabajo. +* ¿En qué versión de Linux se encontró el problema? Se prefiere usar la + versión más reciente o una rama reciente de linux-next (ver + Documentation/process/howto.rst). +* ¿Que se cambió para solucionar el problema y por qué se cree es correcto? +* ¿Como se probó el cambio para la complicación y el tiempo de ejecución? +* ¿Qué confirmación previa corrige este cambio? Esto debería ir en un “Fixes:” + etiqueta como se describe en la documentación. +* ¿Quién más ha revisado este parche? Esto debería ir con la adecuada “Reviewed-by” + etiqueta; Vea abajo. + +Por ejemplo (en inglés, pues es en las listas):: + + From: Author <author@email> + Subject: [PATCH] drivers/foo_bar: Add missing kfree() + + The error path in foo_bar driver does not correctly free the allocated + struct foo_bar_info. This can happen if the attached foo_bar device + rejects the initialization packets sent during foo_bar_probe(). This + would result in a 64 byte slab memory leak once per device attach, + wasting memory resources over time. + + This flaw was found using an experimental static analysis tool we are + developing, LeakMagic[1], which reported the following warning when + analyzing the v5.15 kernel release: + + path/to/foo_bar.c:187: missing kfree() call? + + Add the missing kfree() to the error path. No other references to + this memory exist outside the probe function, so this is the only + place it can be freed. + + x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC + 11.2 show no new warnings, and LeakMagic no longer warns about this + code path. As we don't have a FooBar device to test with, no runtime + testing was able to be performed. + + [1] https://url/to/leakmagic/details + + Reported-by: Researcher <researcher@email> + Fixes: aaaabbbbccccdddd ("Introduce support for FooBar") + Signed-off-by: Author <author@email> + Reviewed-by: Reviewer <reviewer@email> + +Si usted es un colaborador por primera vez, se recomienda que el parche en +si sea examinado por otros en privado antes de ser publicado en listas +públicas. (Esto es necesario si se le ha dicho explícitamente que sus parches +necesitan una revisión interna más cuidadosa.) Se espera que estas personas +tengan su etiqueta “Reviewed-by” incluida en el parche resultante. Encontrar +otro desarrollador con conocimiento de las contribuciones a Linux, especialmente +dentro de su propia organización, y tener su ayuda con las revisiones antes de +enviarlas a las listas de correo publico tiende a mejorar significativamente la +calidad de los parches resultantes, y reduce así la carga de otros desarrolladores. + +Si no se puede encontrar a nadie para revisar internamente los parches y necesita +ayuda para encontrar a esa persona, o si tiene alguna otra pregunta relacionada +con este documento y las expectativas de la comunidad de desarrolladores, por +favor contacte con la lista de correo privada Technical Advisory Board: +<tech-board@lists.linux-foundation.org>. diff --git a/Documentation/translations/zh_CN/arm/Booting b/Documentation/translations/zh_CN/arch/arm/Booting index 5ecea0767893..f18585156b67 100644 --- a/Documentation/translations/zh_CN/arm/Booting +++ b/Documentation/translations/zh_CN/arch/arm/Booting @@ -1,4 +1,4 @@ -Chinese translated version of Documentation/arm/booting.rst +Chinese translated version of Documentation/arch/arm/booting.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -9,7 +9,7 @@ or if there is a problem with the translation. Maintainer: Russell King <linux@arm.linux.org.uk> Chinese maintainer: Fu Wei <tekkamanninja@gmail.com> --------------------------------------------------------------------- -Documentation/arm/booting.rst 的中文翻译 +Documentation/arch/arm/booting.rst 的中文翻译 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 diff --git a/Documentation/translations/zh_CN/arm/kernel_user_helpers.txt b/Documentation/translations/zh_CN/arch/arm/kernel_user_helpers.txt index 99af4363984d..018eb7d54233 100644 --- a/Documentation/translations/zh_CN/arm/kernel_user_helpers.txt +++ b/Documentation/translations/zh_CN/arch/arm/kernel_user_helpers.txt @@ -1,4 +1,4 @@ -Chinese translated version of Documentation/arm/kernel_user_helpers.rst +Chinese translated version of Documentation/arch/arm/kernel_user_helpers.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -10,7 +10,7 @@ Maintainer: Nicolas Pitre <nicolas.pitre@linaro.org> Dave Martin <dave.martin@linaro.org> Chinese maintainer: Fu Wei <tekkamanninja@gmail.com> --------------------------------------------------------------------- -Documentation/arm/kernel_user_helpers.rst 的中文翻译 +Documentation/arch/arm/kernel_user_helpers.rst 的中文翻译 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 diff --git a/Documentation/translations/zh_CN/arm64/amu.rst b/Documentation/translations/zh_CN/arch/arm64/amu.rst index ab7180f91394..f8e09fd21ef5 100644 --- a/Documentation/translations/zh_CN/arm64/amu.rst +++ b/Documentation/translations/zh_CN/arch/arm64/amu.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/arm64/amu.rst <amu_index>` +:Original: :ref:`Documentation/arch/arm64/amu.rst <amu_index>` Translator: Bailu Lin <bailu.lin@vivo.com> diff --git a/Documentation/translations/zh_CN/arm64/booting.txt b/Documentation/translations/zh_CN/arch/arm64/booting.txt index 5b0164132c71..630eb32a8854 100644 --- a/Documentation/translations/zh_CN/arm64/booting.txt +++ b/Documentation/translations/zh_CN/arch/arm64/booting.txt @@ -1,4 +1,4 @@ -Chinese translated version of Documentation/arm64/booting.rst +Chinese translated version of Documentation/arch/arm64/booting.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -10,7 +10,7 @@ M: Will Deacon <will.deacon@arm.com> zh_CN: Fu Wei <wefu@redhat.com> C: 55f058e7574c3615dea4615573a19bdb258696c6 --------------------------------------------------------------------- -Documentation/arm64/booting.rst 的中文翻译 +Documentation/arch/arm64/booting.rst 的中文翻译 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 diff --git a/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst b/Documentation/translations/zh_CN/arch/arm64/elf_hwcaps.rst index 9aa4637eac97..f60ac1580d3e 100644 --- a/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst +++ b/Documentation/translations/zh_CN/arch/arm64/elf_hwcaps.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/arm64/elf_hwcaps.rst <elf_hwcaps_index>` +:Original: :ref:`Documentation/arch/arm64/elf_hwcaps.rst <elf_hwcaps_index>` Translator: Bailu Lin <bailu.lin@vivo.com> @@ -92,7 +92,7 @@ HWCAP_ASIMDHP ID_AA64PFR0_EL1.AdvSIMD == 0b0001 表示有此功能。 HWCAP_CPUID - 根据 Documentation/arm64/cpu-feature-registers.rst 描述，EL0 可以访问 + 根据 Documentation/arch/arm64/cpu-feature-registers.rst 描述，EL0 可以访问 某些 ID 寄存器。 这些 ID 寄存器可能表示功能的可用性。 @@ -152,12 +152,12 @@ HWCAP_SB ID_AA64ISAR1_EL1.SB == 0b0001 表示有此功能。 HWCAP_PACA - 如 Documentation/arm64/pointer-authentication.rst 所描述， + 如 Documentation/arch/arm64/pointer-authentication.rst 所描述， ID_AA64ISAR1_EL1.APA == 0b0001 或 ID_AA64ISAR1_EL1.API == 0b0001 表示有此功能。 HWCAP_PACG - 如 Documentation/arm64/pointer-authentication.rst 所描述， + 如 Documentation/arch/arm64/pointer-authentication.rst 所描述， ID_AA64ISAR1_EL1.GPA == 0b0001 或 ID_AA64ISAR1_EL1.GPI == 0b0001 表示有此功能。 diff --git a/Documentation/translations/zh_CN/arm64/hugetlbpage.rst b/Documentation/translations/zh_CN/arch/arm64/hugetlbpage.rst index 13304d269d0b..8079eadde29a 100644 --- a/Documentation/translations/zh_CN/arm64/hugetlbpage.rst +++ b/Documentation/translations/zh_CN/arch/arm64/hugetlbpage.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/arm64/hugetlbpage.rst <hugetlbpage_index>` +:Original: :ref:`Documentation/arch/arm64/hugetlbpage.rst <hugetlbpage_index>` Translator: Bailu Lin <bailu.lin@vivo.com> diff --git a/Documentation/translations/zh_CN/arm64/index.rst b/Documentation/translations/zh_CN/arch/arm64/index.rst index 57dc5de5ccc5..e12b9f6e5d6c 100644 --- a/Documentation/translations/zh_CN/arm64/index.rst +++ b/Documentation/translations/zh_CN/arch/arm64/index.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/arm64/index.rst <arm64_index>` +:Original: :ref:`Documentation/arch/arm64/index.rst <arm64_index>` :Translator: Bailu Lin <bailu.lin@vivo.com> .. _cn_arm64_index: diff --git a/Documentation/translations/zh_CN/arm64/legacy_instructions.txt b/Documentation/translations/zh_CN/arch/arm64/legacy_instructions.txt index e295cf75f606..e469fccbe356 100644 --- a/Documentation/translations/zh_CN/arm64/legacy_instructions.txt +++ b/Documentation/translations/zh_CN/arch/arm64/legacy_instructions.txt @@ -1,4 +1,4 @@ -Chinese translated version of Documentation/arm64/legacy_instructions.rst +Chinese translated version of Documentation/arch/arm64/legacy_instructions.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -10,7 +10,7 @@ Maintainer: Punit Agrawal <punit.agrawal@arm.com> Suzuki K. Poulose <suzuki.poulose@arm.com> Chinese maintainer: Fu Wei <wefu@redhat.com> --------------------------------------------------------------------- -Documentation/arm64/legacy_instructions.rst 的中文翻译 +Documentation/arch/arm64/legacy_instructions.rst 的中文翻译 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 diff --git a/Documentation/translations/zh_CN/arm64/memory.txt b/Documentation/translations/zh_CN/arch/arm64/memory.txt index be20f8228b91..c6962e9cb9f8 100644 --- a/Documentation/translations/zh_CN/arm64/memory.txt +++ b/Documentation/translations/zh_CN/arch/arm64/memory.txt @@ -1,4 +1,4 @@ -Chinese translated version of Documentation/arm64/memory.rst +Chinese translated version of Documentation/arch/arm64/memory.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -9,7 +9,7 @@ or if there is a problem with the translation. Maintainer: Catalin Marinas <catalin.marinas@arm.com> Chinese maintainer: Fu Wei <wefu@redhat.com> --------------------------------------------------------------------- -Documentation/arm64/memory.rst 的中文翻译 +Documentation/arch/arm64/memory.rst 的中文翻译 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 diff --git a/Documentation/translations/zh_CN/arm64/perf.rst b/Documentation/translations/zh_CN/arch/arm64/perf.rst index 9bf21d73f4d1..6be72704e659 100644 --- a/Documentation/translations/zh_CN/arm64/perf.rst +++ b/Documentation/translations/zh_CN/arch/arm64/perf.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/arm64/perf.rst <perf_index>` +:Original: :ref:`Documentation/arch/arm64/perf.rst <perf_index>` Translator: Bailu Lin <bailu.lin@vivo.com> diff --git a/Documentation/translations/zh_CN/arm64/silicon-errata.txt b/Documentation/translations/zh_CN/arch/arm64/silicon-errata.txt index 440c59ac7dce..f4767ffdd61d 100644 --- a/Documentation/translations/zh_CN/arm64/silicon-errata.txt +++ b/Documentation/translations/zh_CN/arch/arm64/silicon-errata.txt @@ -1,4 +1,4 @@ -Chinese translated version of Documentation/arm64/silicon-errata.rst +Chinese translated version of Documentation/arch/arm64/silicon-errata.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -10,7 +10,7 @@ M: Will Deacon <will.deacon@arm.com> zh_CN: Fu Wei <wefu@redhat.com> C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 --------------------------------------------------------------------- -Documentation/arm64/silicon-errata.rst 的中文翻译 +Documentation/arch/arm64/silicon-errata.rst 的中文翻译 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 diff --git a/Documentation/translations/zh_CN/arm64/tagged-pointers.txt b/Documentation/translations/zh_CN/arch/arm64/tagged-pointers.txt index 77ac3548a16d..27577c3c5e3f 100644 --- a/Documentation/translations/zh_CN/arm64/tagged-pointers.txt +++ b/Documentation/translations/zh_CN/arch/arm64/tagged-pointers.txt @@ -1,4 +1,4 @@ -Chinese translated version of Documentation/arm64/tagged-pointers.rst +Chinese translated version of Documentation/arch/arm64/tagged-pointers.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -9,7 +9,7 @@ or if there is a problem with the translation. Maintainer: Will Deacon <will.deacon@arm.com> Chinese maintainer: Fu Wei <wefu@redhat.com> --------------------------------------------------------------------- -Documentation/arm64/tagged-pointers.rst 的中文翻译 +Documentation/arch/arm64/tagged-pointers.rst 的中文翻译 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 diff --git a/Documentation/translations/zh_CN/arch/index.rst b/Documentation/translations/zh_CN/arch/index.rst index 908ea131bb1c..e3d273d7d599 100644 --- a/Documentation/translations/zh_CN/arch/index.rst +++ b/Documentation/translations/zh_CN/arch/index.rst @@ -8,12 +8,12 @@ .. toctree:: :maxdepth: 2 - ../mips/index - ../arm64/index + mips/index + arm64/index ../riscv/index openrisc/index parisc/index - ../loongarch/index + loongarch/index TODOList: diff --git a/Documentation/translations/zh_CN/loongarch/booting.rst b/Documentation/translations/zh_CN/arch/loongarch/booting.rst index fb6440c438f0..d2f55872904e 100644 --- a/Documentation/translations/zh_CN/loongarch/booting.rst +++ b/Documentation/translations/zh_CN/arch/loongarch/booting.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/loongarch/booting.rst +:Original: Documentation/arch/loongarch/booting.rst :翻译: diff --git a/Documentation/translations/zh_CN/loongarch/features.rst b/Documentation/translations/zh_CN/arch/loongarch/features.rst index 3886e635ec06..82bfac180bdc 100644 --- a/Documentation/translations/zh_CN/loongarch/features.rst +++ b/Documentation/translations/zh_CN/arch/loongarch/features.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/loongarch/features.rst +:Original: Documentation/arch/loongarch/features.rst :Translator: Huacai Chen <chenhuacai@loongson.cn> .. kernel-feat:: $srctree/Documentation/features loongarch diff --git a/Documentation/translations/zh_CN/loongarch/index.rst b/Documentation/translations/zh_CN/arch/loongarch/index.rst index 0273a08342f7..4bd24f5ffed1 100644 --- a/Documentation/translations/zh_CN/loongarch/index.rst +++ b/Documentation/translations/zh_CN/arch/loongarch/index.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/loongarch/index.rst +:Original: Documentation/arch/loongarch/index.rst :Translator: Huacai Chen <chenhuacai@loongson.cn> ================= diff --git a/Documentation/translations/zh_CN/loongarch/introduction.rst b/Documentation/translations/zh_CN/arch/loongarch/introduction.rst index 470c38ae2caf..cba04befc950 100644 --- a/Documentation/translations/zh_CN/loongarch/introduction.rst +++ b/Documentation/translations/zh_CN/arch/loongarch/introduction.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/loongarch/introduction.rst +:Original: Documentation/arch/loongarch/introduction.rst :Translator: Huacai Chen <chenhuacai@loongson.cn> ============= diff --git a/Documentation/translations/zh_CN/loongarch/irq-chip-model.rst b/Documentation/translations/zh_CN/arch/loongarch/irq-chip-model.rst index fb5d23b49ed5..f1e9ab18206c 100644 --- a/Documentation/translations/zh_CN/loongarch/irq-chip-model.rst +++ b/Documentation/translations/zh_CN/arch/loongarch/irq-chip-model.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/loongarch/irq-chip-model.rst +:Original: Documentation/arch/loongarch/irq-chip-model.rst :Translator: Huacai Chen <chenhuacai@loongson.cn> ================================== diff --git a/Documentation/translations/zh_CN/mips/booting.rst b/Documentation/translations/zh_CN/arch/mips/booting.rst index e0bbd3f20862..485b57e0ca0b 100644 --- a/Documentation/translations/zh_CN/mips/booting.rst +++ b/Documentation/translations/zh_CN/arch/mips/booting.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/mips/booting.rst +:Original: Documentation/arch/mips/booting.rst :翻译: diff --git a/Documentation/translations/zh_CN/mips/features.rst b/Documentation/translations/zh_CN/arch/mips/features.rst index b61dab06ceaf..da1b956e4a40 100644 --- a/Documentation/translations/zh_CN/mips/features.rst +++ b/Documentation/translations/zh_CN/arch/mips/features.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/mips/features.rst +:Original: Documentation/arch/mips/features.rst :翻译: diff --git a/Documentation/translations/zh_CN/mips/index.rst b/Documentation/translations/zh_CN/arch/mips/index.rst index 192c6adbb72e..2a34217119ea 100644 --- a/Documentation/translations/zh_CN/mips/index.rst +++ b/Documentation/translations/zh_CN/arch/mips/index.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/mips/index.rst +:Original: Documentation/arch/mips/index.rst :翻译: diff --git a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst b/Documentation/translations/zh_CN/arch/mips/ingenic-tcu.rst index ddbe149c517b..3d599a36b571 100644 --- a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst +++ b/Documentation/translations/zh_CN/arch/mips/ingenic-tcu.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/mips/ingenic-tcu.rst +:Original: Documentation/arch/mips/ingenic-tcu.rst :翻译: diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst index af65e7e93c02..69e7e4cb2002 100644 --- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst @@ -3,7 +3,7 @@ .. include:: ../disclaimer-zh_CN.rst :Original: Documentation/dev-tools/testing-overview.rst -:Translator: 胡皓文 Hu Haowen <src.res@email.cn> +:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com> ============ 内核测试指南 diff --git a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst index 84ce2322fdba..aeccff777170 100644 --- a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst +++ b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst @@ -153,8 +153,7 @@ get/set(获取/设置)函数调用没法返回错误,且有可能是配置错误 大多数 GPIO 控制器可以通过内存读/写指令来访问。这些指令不会休眠,可以 安全地在硬(非线程)中断例程和类似的上下文中完成。 -对于那些用 gpio_cansleep()测试总是返回失败的 GPIO(见下文)，使用 -以下的函数访问:: +对于那些 GPIO，使用以下的函数访问:: /* GPIO 输入:返回零或非零 */ int gpio_get_value(unsigned gpio); @@ -186,11 +185,6 @@ GPIO值是布尔值，零表示低电平，非零表示高电平。当读取一 GPIO 值的命令需要等待其信息排到队首才发送命令，再获得其反馈。期间需要 休眠，这不能在 IRQ 例程(中断上下文)中执行。 -支持此类 GPIO 的平台通过以下函数返回非零值来区分出这种 GPIO。(此函数需要 -一个之前通过 gpio_request 分配到的有效 GPIO 编号):: - - int gpio_cansleep(unsigned gpio); - 为了访问这种 GPIO,内核定义了一套不同的函数:: /* GPIO 输入:返回零或非零 ,可能会休眠 */ @@ -199,7 +193,6 @@ GPIO 值的命令需要等待其信息排到队首才发送命令，再获得其 /* GPIO 输出,可能会休眠 */ void gpio_set_value_cansleep(unsigned gpio, int value); - 访问这样的 GPIO 需要一个允许休眠的上下文，例如线程 IRQ 处理例程，并用以上的 访问函数替换那些没有 cansleep()后缀的自旋锁安全访问函数。 @@ -294,11 +287,6 @@ gpio_request()前将这类细节配置好，例如使用引脚控制子系统的 * GPIOF_INIT_LOW - 在作为输出时,初始值为低电平 * GPIOF_INIT_HIGH - 在作为输出时,初始值为高电平 - * GPIOF_OPEN_DRAIN - gpio引脚为开漏信号 - * GPIOF_OPEN_SOURCE - gpio引脚为源极开路信号 - - * GPIOF_EXPORT_DIR_FIXED - 将 gpio 导出到 sysfs，并保持方向 - * GPIOF_EXPORT_DIR_CHANGEABLE - 同样是导出, 但允许改变方向 因为 GPIOF_INIT_* 仅有在配置为输出的时候才存在,所以有效的组合为: @@ -306,18 +294,6 @@ gpio_request()前将这类细节配置好，例如使用引脚控制子系统的 * GPIOF_OUT_INIT_LOW - 配置为输出,并初始化为低电平 * GPIOF_OUT_INIT_HIGH - 配置为输出,并初始化为高电平 -当设置 flag 为 GPIOF_OPEN_DRAIN 时，则假设引脚是开漏信号。这样的引脚 -将不会在输出模式下置1。这样的引脚需要连接上拉电阻。通过使能这个标志，gpio库 -将会在被要求输出模式下置1时将引脚变为输入状态来使引脚置高。引脚在输出模式下 -通过置0使其输出低电平。 - -当设置 flag 为 GPIOF_OPEN_SOURCE 时，则假设引脚为源极开路信号。这样的引脚 -将不会在输出模式下置0。这样的引脚需要连接下拉电阻。通过使能这个标志，gpio库 -将会在被要求输出模式下置0时将引脚变为输入状态来使引脚置低。引脚在输出模式下 -通过置1使其输出高电平。 - -将来这些标志可能扩展到支持更多的属性。 - 更进一步,为了更简单地声明/释放多个 GPIO,'struct gpio'被引进来封装所有 这三个领域:: @@ -500,8 +476,8 @@ GPIO 实现者的框架（可选） 为了支持这个框架，一个平台的 Kconfig 文件将会 "select"(选择) ARCH_REQUIRE_GPIOLIB 或 ARCH_WANT_OPTIONAL_GPIOLIB，并让它的 -<asm/gpio.h> 包含 <asm-generic/gpio.h>，同时定义三个方法: -gpio_get_value()、gpio_set_value()和 gpio_cansleep()。 +<asm/gpio.h> 包含 <asm-generic/gpio.h>，同时定义两个方法: +gpio_get_value()、gpio_set_value()。 它也应提供一个 ARCH_NR_GPIOS 的定义值，这样可以更好地反映该平台 GPIO 的实际数量,节省静态表的空间。(这个定义值应该包含片上系统内建 GPIO 和 @@ -519,7 +495,6 @@ ARCH_WANT_OPTIONAL_GPIOLIB 意味着 gpiolib 核心默认关闭,且用户可以 #define gpio_get_value __gpio_get_value #define gpio_set_value __gpio_set_value - #define gpio_cansleep __gpio_cansleep 这些定义可以用更理想的实现方法替代，那就是使用经过逻辑优化的内联函数来访问 基于特定片上系统的 GPIO。例如,若引用的 GPIO (寄存器位偏移)是常量“12”， diff --git a/Documentation/translations/zh_CN/mm/frontswap.rst b/Documentation/translations/zh_CN/mm/frontswap.rst deleted file mode 100644 index 434975390b48..000000000000 --- a/Documentation/translations/zh_CN/mm/frontswap.rst +++ /dev/null @@ -1,196 +0,0 @@ -:Original: Documentation/mm/frontswap.rst - -:翻译: - - 司延腾 Yanteng Si <siyanteng@loongson.cn> - -:校译: - -========= -Frontswap -========= - -Frontswap为交换页提供了一个 “transcendent memory” 的接口。在一些环境中，由 -于交换页被保存在RAM（或类似RAM的设备）中，而不是交换磁盘，因此可以获得巨大的性能 -节省（提高）。 - -.. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/ - -Frontswap之所以这么命名，是因为它可以被认为是与swap设备的“back”存储相反。存 -储器被认为是一个同步并发安全的面向页面的“伪RAM设备”，符合transcendent memory -（如Xen的“tmem”，或内核内压缩内存，又称“zcache”，或未来的类似RAM的设备）的要 -求；这个伪RAM设备不能被内核直接访问或寻址，其大小未知且可能随时间变化。驱动程序通过 -调用frontswap_register_ops将自己与frontswap链接起来，以适当地设置frontswap_ops -的功能，它提供的功能必须符合某些策略，如下所示: - -一个 “init” 将设备准备好接收与指定的交换设备编号（又称“类型”）相关的frontswap -交换页。一个 “store” 将把该页复制到transcendent memory，并与该页的类型和偏移 -量相关联。一个 “load” 将把该页，如果找到的话，从transcendent memory复制到内核 -内存，但不会从transcendent memory中删除该页。一个 “invalidate_page” 将从 -transcendent memory中删除该页，一个 “invalidate_area” 将删除所有与交换类型 -相关的页（例如，像swapoff）并通知 “device” 拒绝进一步存储该交换类型。 - -一旦一个页面被成功存储，在该页面上的匹配加载通常会成功。因此，当内核发现自己处于需 -要交换页面的情况时，它首先尝试使用frontswap。如果存储的结果是成功的，那么数据就已 -经成功的保存到了transcendent memory中，并且避免了磁盘写入，如果后来再读回数据， -也避免了磁盘读取。如果存储返回失败，transcendent memory已经拒绝了该数据，且该页 -可以像往常一样被写入交换空间。 - -请注意，如果一个页面被存储，而该页面已经存在于transcendent memory中（一个 “重复” -的存储），要么存储成功，数据被覆盖，要么存储失败，该页面被废止。这确保了旧的数据永远 -不会从frontswap中获得。 - -如果配置正确，对frontswap的监控是通过 `/sys/kernel/debug/frontswap` 目录下的 -debugfs完成的。frontswap的有效性可以通过以下方式测量（在所有交换设备中）: - -``failed_stores`` - 有多少次存储的尝试是失败的 - -``loads`` - 尝试了多少次加载（应该全部成功） - -``succ_stores`` - 有多少次存储的尝试是成功的 - -``invalidates`` - 尝试了多少次作废 - -后台实现可以提供额外的指标。 - -经常问到的问题 -============== - -* 价值在哪里? - -当一个工作负载开始交换时，性能就会下降。Frontswap通过提供一个干净的、动态的接口来 -读取和写入交换页到 “transcendent memory”，从而大大增加了许多这样的工作负载的性 -能，否则内核是无法直接寻址的。当数据被转换为不同的形式和大小（比如压缩）或者被秘密 -移动（对于一些类似RAM的设备来说，这可能对写平衡很有用）时，这个接口是理想的。交换 -页（和被驱逐的页面缓存页）是这种比RAM慢但比磁盘快得多的“伪RAM设备”的一大用途。 - -Frontswap对内核的影响相当小，为各种系统配置中更动态、更灵活的RAM利用提供了巨大的 -灵活性： - -在单一内核的情况下，又称“zcache”，页面被压缩并存储在本地内存中，从而增加了可以安 -全保存在RAM中的匿名页面总数。Zcache本质上是用压缩/解压缩的CPU周期换取更好的内存利 -用率。Benchmarks测试显示，当内存压力较低时，几乎没有影响，而在高内存压力下的一些 -工作负载上，则有明显的性能改善（25%以上）。 - -“RAMster” 在zcache的基础上增加了对集群系统的 “peer-to-peer” transcendent memory -的支持。Frontswap页面像zcache一样被本地压缩，但随后被“remotified” 到另一个系 -统的RAM。这使得RAM可以根据需要动态地来回负载平衡，也就是说，当系统A超载时，它可以 -交换到系统B，反之亦然。RAMster也可以被配置成一个内存服务器，因此集群中的许多服务器 -可以根据需要动态地交换到配置有大量内存的单一服务器上......而不需要预先配置每个客户 -有多少内存可用 - -在虚拟情况下，虚拟化的全部意义在于统计地将物理资源在多个虚拟机的不同需求之间进行复 -用。对于RAM来说，这真的很难做到，而且在不改变内核的情况下，要做好这一点的努力基本上 -是失败的（除了一些广为人知的特殊情况下的工作负载）。具体来说，Xen Transcendent Memory -后端允许管理器拥有的RAM “fallow”，不仅可以在多个虚拟机之间进行“time-shared”， -而且页面可以被压缩和重复利用，以优化RAM的利用率。当客户操作系统被诱导交出未充分利用 -的RAM时（如 “selfballooning”），突然出现的意外内存压力可能会导致交换；frontswap -允许这些页面被交换到管理器RAM中或从管理器RAM中交换（如果整体主机系统内存条件允许）， -从而减轻计划外交换可能带来的可怕的性能影响。 - -一个KVM的实现正在进行中，并且已经被RFC'ed到lkml。而且，利用frontswap，对NVM作为 -内存扩展技术的调查也在进行中。 - -* 当然，在某些情况下可能有性能上的优势，但frontswap的空间/时间开销是多少？ - -如果 CONFIG_FRONTSWAP 被禁用，每个 frontswap 钩子都会编译成空，唯一的开销是每 -个 swapon'ed swap 设备的几个额外字节。如果 CONFIG_FRONTSWAP 被启用，但没有 -frontswap的 “backend” 寄存器，每读或写一个交换页就会有一个额外的全局变量，而不 -是零。如果 CONFIG_FRONTSWAP 被启用，并且有一个frontswap的backend寄存器，并且 -后端每次 “store” 请求都失败（即尽管声称可能，但没有提供内存），CPU 的开销仍然可以 -忽略不计 - 因为每次frontswap失败都是在交换页写到磁盘之前，系统很可能是 I/O 绑定 -的，无论如何使用一小部分的 CPU 都是不相关的。 - -至于空间，如果CONFIG_FRONTSWAP被启用，并且有一个frontswap的backend注册，那么 -每个交换设备的每个交换页都会被分配一个比特。这是在内核已经为每个交换设备的每个交换 -页分配的8位（在2.6.34之前是16位）上增加的。(Hugh Dickins观察到，frontswap可能 -会偷取现有的8个比特，但是我们以后再来担心这个小的优化问题)。对于标准的4K页面大小的 -非常大的交换盘（这很罕见），这是每32GB交换盘1MB开销。 - -当交换页存储在transcendent memory中而不是写到磁盘上时，有一个副作用，即这可能会 -产生更多的内存压力，有可能超过其他的优点。一个backend，比如zcache，必须实现策略 -来仔细（但动态地）管理内存限制，以确保这种情况不会发生。 - -* 好吧，那就用内核骇客能理解的术语来快速概述一下这个frontswap补丁的作用如何？ - -我们假设在内核初始化过程中，一个frontswap 的 “backend” 已经注册了；这个注册表 -明这个frontswap 的 “backend” 可以访问一些不被内核直接访问的“内存”。它到底提 -供了多少内存是完全动态和随机的。 - -每当一个交换设备被交换时，就会调用frontswap_init()，把交换设备的编号（又称“类 -型”）作为一个参数传给它。这就通知了frontswap，以期待 “store” 与该号码相关的交 -换页的尝试。 - -每当交换子系统准备将一个页面写入交换设备时（参见swap_writepage()），就会调用 -frontswap_store。Frontswap与frontswap backend协商，如果backend说它没有空 -间，frontswap_store返回-1，内核就会照常把页换到交换设备上。注意，来自frontswap -backend的响应对内核来说是不可预测的；它可能选择从不接受一个页面，可能接受每九个 -页面，也可能接受每一个页面。但是如果backend确实接受了一个页面，那么这个页面的数 -据已经被复制并与类型和偏移量相关联了，而且backend保证了数据的持久性。在这种情况 -下，frontswap在交换设备的“frontswap_map” 中设置了一个位，对应于交换设备上的 -页面偏移量，否则它就会将数据写入该设备。 - -当交换子系统需要交换一个页面时（swap_readpage()），它首先调用frontswap_load()， -检查frontswap_map，看这个页面是否早先被frontswap backend接受。如果是，该页 -的数据就会从frontswap后端填充，换入就完成了。如果不是，正常的交换代码将被执行， -以便从真正的交换设备上获得这一页的数据。 - -所以每次frontswap backend接受一个页面时，交换设备的读取和（可能）交换设备的写 -入都被 “frontswap backend store” 和（可能）“frontswap backend loads” -所取代，这可能会快得多。 - -* frontswap不能被配置为一个 “特殊的” 交换设备，它的优先级要高于任何真正的交换 - 设备（例如像zswap，或者可能是swap-over-nbd/NFS）？ - -首先，现有的交换子系统不允许有任何种类的交换层次结构。也许它可以被重写以适应层次 -结构，但这将需要相当大的改变。即使它被重写，现有的交换子系统也使用了块I/O层，它 -假定交换设备是固定大小的，其中的任何页面都是可线性寻址的。Frontswap几乎没有触 -及现有的交换子系统，而是围绕着块I/O子系统的限制，提供了大量的灵活性和动态性。 - -例如，frontswap backend对任何交换页的接受是完全不可预测的。这对frontswap backend -的定义至关重要，因为它赋予了backend完全动态的决定权。在zcache中，人们无法预 -先知道一个页面的可压缩性如何。可压缩性 “差” 的页面会被拒绝，而 “差” 本身也可 -以根据当前的内存限制动态地定义。 - -此外，frontswap是完全同步的，而真正的交换设备，根据定义，是异步的，并且使用 -块I/O。块I/O层不仅是不必要的，而且可能进行 “优化”，这对面向RAM的设备来说是 -不合适的，包括将一些页面的写入延迟相当长的时间。同步是必须的，以确保后端的动 -态性，并避免棘手的竞争条件，这将不必要地大大增加frontswap和/或块I/O子系统的 -复杂性。也就是说，只有最初的 “store” 和 “load” 操作是需要同步的。一个独立 -的异步线程可以自由地操作由frontswap存储的页面。例如，RAMster中的 “remotification” -线程使用标准的异步内核套接字，将压缩的frontswap页面移动到远程机器。同样， -KVM的客户方实现可以进行客户内压缩，并使用 “batched” hypercalls。 - -在虚拟化环境中，动态性允许管理程序（或主机操作系统）做“intelligent overcommit”。 -例如，它可以选择只接受页面，直到主机交换可能即将发生，然后强迫客户机做他们 -自己的交换。 - -transcendent memory规格的frontswap有一个坏处。因为任何 “store” 都可 -能失败，所以必须在一个真正的交换设备上有一个真正的插槽来交换页面。因此， -frontswap必须作为每个交换设备的 “影子” 来实现，它有可能容纳交换设备可能 -容纳的每一个页面，也有可能根本不容纳任何页面。这意味着frontswap不能包含比 -swap设备总数更多的页面。例如，如果在某些安装上没有配置交换设备，frontswap -就没有用。无交换设备的便携式设备仍然可以使用frontswap，但是这种设备的 -backend必须配置某种 “ghost” 交换设备，并确保它永远不会被使用。 - - -* 为什么会有这种关于 “重复存储” 的奇怪定义？如果一个页面以前被成功地存储过， - 难道它不能总是被成功地覆盖吗？ - -几乎总是可以的，不，有时不能。考虑一个例子，数据被压缩了，原来的4K页面被压 -缩到了1K。现在，有人试图用不可压缩的数据覆盖该页，因此会占用整个4K。但是 -backend没有更多的空间了。在这种情况下，这个存储必须被拒绝。每当frontswap -拒绝一个会覆盖的存储时，它也必须使旧的数据作废，并确保它不再被访问。因为交 -换子系统会把新的数据写到读交换设备上，这是确保一致性的正确做法。 - -* 为什么frontswap补丁会创建新的头文件swapfile.h？ - -frontswap代码依赖于一些swap子系统内部的数据结构，这些数据结构多年来一直 -在静态和全局之间来回移动。这似乎是一个合理的妥协：将它们定义为全局，但在一 -个新的包含文件中声明它们，该文件不被包含swap.h的大量源文件所包含。 - -Dan Magenheimer，最后更新于2012年4月9日 diff --git a/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst b/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst index b7a0544224ad..20947f8bd065 100644 --- a/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst +++ b/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst @@ -219,7 +219,7 @@ vma_commit_reservation()之间，预留映射有可能被改变。如果hugetlb_ 释放巨页 ======== -巨页释放是由函数free_huge_page()执行的。这个函数是hugetlbfs复合页的析构器。因此，它只传 +巨页释放是由函数free_huge_folio()执行的。这个函数是hugetlbfs复合页的析构器。因此，它只传 递一个指向页面结构体的指针。当一个巨页被释放时，可能需要进行预留计算。如果该页与包含保 留的子池相关联，或者该页在错误路径上被释放，必须恢复全局预留计数，就会出现这种情况。 @@ -296,7 +296,7 @@ COW和预留 调用代码执行全局检查和分配，以确定是否有足够的巨页使操作成功。 2) - a) 如果操作能够成功，regi_add()将被调用，以实际修改先前传递给regi_chg()的相同范围 + a) 如果操作能够成功，region_add()将被调用，以实际修改先前传递给region_chg()的相同范围 [f, t]的预留映射。 b) 如果操作不能成功，region_abort被调用，在相同的范围[f, t]内中止操作。 @@ -307,7 +307,7 @@ COW和预留 如上所述，region_chg()确定该范围内当前没有在映射中表示的页面的数量。region_add()返回添加 到映射中的范围内的页数。在大多数情况下， region_add() 的返回值与 region_chg() 的返回值相 同。然而，在共享映射的情况下，有可能在调用 region_chg() 和 region_add() 之间对预留映射进 -行更改。在这种情况下，regi_add()的返回值将与regi_chg()的返回值不符。在这种情况下，全局计数 +行更改。在这种情况下，region_add()的返回值将与region_chg()的返回值不符。在这种情况下，全局计数 和子池计数很可能是不正确的，需要调整。检查这种情况并进行适当的调整是调用者的责任。 函数region_del()被调用以从预留映射中移除区域。 @@ -387,7 +387,7 @@ region_count()在解除私有巨页映射时被调用。在私有映射中，预 然而，有几种情况是，在一个巨页被分配后，但在它被实例化之前，就遇到了错误。在这种情况下， 页面分配已经消耗了预留，并进行了适当的子池、预留映射和全局计数调整。如果页面在这个时候被释放 -（在实例化和清除PagePrivate之前），那么free_huge_page将增加全局预留计数。然而，预留映射 +（在实例化和清除PagePrivate之前），那么free_huge_folio将增加全局预留计数。然而，预留映射 显示报留被消耗了。这种不一致的状态将导致预留的巨页的 “泄漏” 。全局预留计数将比它原本的要高， 并阻止分配一个预先分配的页面。 diff --git a/Documentation/translations/zh_CN/mm/index.rst b/Documentation/translations/zh_CN/mm/index.rst index 2f53e37b8049..b950dd118be7 100644 --- a/Documentation/translations/zh_CN/mm/index.rst +++ b/Documentation/translations/zh_CN/mm/index.rst @@ -42,7 +42,6 @@ Linux内存管理文档 damon/index free_page_reporting ksm - frontswap hmm hwpoison hugetlbfs_reserv diff --git a/Documentation/translations/zh_CN/mm/page_migration.rst b/Documentation/translations/zh_CN/mm/page_migration.rst index 076081dc1635..f95063826a15 100644 --- a/Documentation/translations/zh_CN/mm/page_migration.rst +++ b/Documentation/translations/zh_CN/mm/page_migration.rst @@ -55,7 +55,7 @@ mbind()设置一个新的内存策略。一个进程的页面也可以通过sys_ 消失。它还可以防止交换器或其他扫描器遇到该页。 -2. 我们需要有一个new_page_t类型的函数，可以传递给migrate_pages()。这个函数应该计算 +2. 我们需要有一个new_folio_t类型的函数，可以传递给migrate_pages()。这个函数应该计算 出如何在给定的旧页面中分配正确的新页面。 3. migrate_pages()函数被调用，它试图进行迁移。它将调用该函数为每个被考虑迁移的页面分 diff --git a/Documentation/translations/zh_CN/mm/split_page_table_lock.rst b/Documentation/translations/zh_CN/mm/split_page_table_lock.rst index 4fb7aa666037..a2c288670a24 100644 --- a/Documentation/translations/zh_CN/mm/split_page_table_lock.rst +++ b/Documentation/translations/zh_CN/mm/split_page_table_lock.rst @@ -56,16 +56,16 @@ Hugetlb特定的辅助函数: 架构对分页表锁的支持 ==================== -没有必要特别启用PTE分页表锁：所有需要的东西都由pgtable_pte_page_ctor() -和pgtable_pte_page_dtor()完成，它们必须在PTE表分配/释放时被调用。 +没有必要特别启用PTE分页表锁：所有需要的东西都由pagetable_pte_ctor() +和pagetable_pte_dtor()完成，它们必须在PTE表分配/释放时被调用。 确保架构不使用slab分配器来分配页表：slab使用page->slab_cache来分配其页 面。这个区域与page->ptl共享存储。 PMD分页锁只有在你有两个以上的页表级别时才有意义。 -启用PMD分页锁需要在PMD表分配时调用pgtable_pmd_page_ctor()，在释放时调 -用pgtable_pmd_page_dtor()。 +启用PMD分页锁需要在PMD表分配时调用pagetable_pmd_ctor()，在释放时调 +用pagetable_pmd_dtor()。 分配通常发生在pmd_alloc_one()中，释放发生在pmd_free()和pmd_free_tlb() 中，但要确保覆盖所有的PMD表分配/释放路径：即X86_PAE在pgd_alloc()中预先 @@ -73,7 +73,7 @@ PMD分页锁只有在你有两个以上的页表级别时才有意义。 一切就绪后，你可以设置CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK。 -注意：pgtable_pte_page_ctor()和pgtable_pmd_page_ctor()可能失败--必 +注意：pagetable_pte_ctor()和pagetable_pmd_ctor()可能失败--必 须正确处理。 page->ptl @@ -90,7 +90,7 @@ page->ptl用于访问分割页表锁，其中'page'是包含该表的页面struc 的指针并动态分配它。这允许在启用DEBUG_SPINLOCK或DEBUG_LOCK_ALLOC的 情况下使用分页锁，但由于间接访问而多花了一个缓存行。 -PTE表的spinlock_t分配在pgtable_pte_page_ctor()中，PMD表的spinlock_t -分配在pgtable_pmd_page_ctor()中。 +PTE表的spinlock_t分配在pagetable_pte_ctor()中，PMD表的spinlock_t +分配在pagetable_pmd_ctor()中。 请不要直接访问page->ptl - -使用适当的辅助函数。 diff --git a/Documentation/translations/zh_CN/process/2.Process.rst b/Documentation/translations/zh_CN/process/2.Process.rst index 4a6ed0219494..e68c9de0f7f8 100644 --- a/Documentation/translations/zh_CN/process/2.Process.rst +++ b/Documentation/translations/zh_CN/process/2.Process.rst @@ -358,7 +358,7 @@ Andrew Morton 为有抱负的内核开发人员提供了如下建议 机器上始终完美运行”。通常的方法是和其他人一起解决问题（这可能需 要坚持！），但就是如此——这是内核开发的一部分。 -(http://lwn.net/articles/283982/) +(http://lwn.net/Articles/283982/) 在没有明显问题需要解决的情况下，通常建议开发人员查看当前的回归和开放缺陷 列表。从来都不缺少需要解决的问题；通过解决这些问题，开发人员将从该过程获得 diff --git a/Documentation/translations/zh_CN/process/3.Early-stage.rst b/Documentation/translations/zh_CN/process/3.Early-stage.rst index de53dd12e911..2caba4753b75 100644 --- a/Documentation/translations/zh_CN/process/3.Early-stage.rst +++ b/Documentation/translations/zh_CN/process/3.Early-stage.rst @@ -44,7 +44,7 @@ 试图向这些人传达用户需求是浪费时间。他们太“聪明”了，根本听不到少数 人的话。 -（http://lwn.net/articles/131776/） +（http://lwn.net/Articles/131776/） 实际情况却是不同的；与特定模块相比，内核开发人员更关心系统稳定性、长期维护 以及找到问题的正确解决方案。这个故事的寓意是把重点放在问题上——而不是具体的 diff --git a/Documentation/translations/zh_CN/process/4.Coding.rst b/Documentation/translations/zh_CN/process/4.Coding.rst index 94f7f866f103..7cac9424f5d5 100644 --- a/Documentation/translations/zh_CN/process/4.Coding.rst +++ b/Documentation/translations/zh_CN/process/4.Coding.rst @@ -149,7 +149,7 @@ Linus对这个问题给出了最佳答案: 所以我们不会通过引入新问题来修复错误。这种方式是靠不住的，没人知道 是否真的有进展。是前进两步、后退一步，还是前进一步、后退两步？ -（http://lwn.net/articles/243460/） +（http://lwn.net/Articles/243460/） 特别不受欢迎的一种回归类型是用户空间ABI的任何变化。一旦接口被导出到用户空间， 就必须无限期地支持它。这一事实使得用户空间接口的创建特别具有挑战性：因为它们 diff --git a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst index 6d0dadae13b1..57beca02181c 100644 --- a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst +++ b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst @@ -98,7 +98,7 @@ Git提供了一些强大的工具，可以让您重写开发历史。一个不 你可以给我发补丁，但当我从你那里拉取一个Git补丁时，我需要知道你清楚 自己在做什么，我需要能够相信事情而 *无需* 手动检查每个单独的更改。 -（http://lwn.net/articles/224135/）。 +（http://lwn.net/Articles/224135/）。 为了避免这种情况，请确保给定分支中的所有补丁都与相关主题紧密相关；“驱动程序 修复”分支不应更改核心内存管理代码。而且，最重要的是，不要使用Git树来绕过 diff --git a/Documentation/translations/zh_TW/IRQ.txt b/Documentation/translations/zh_TW/IRQ.txt index 73d435a0d1e7..fd78ca720298 100644 --- a/Documentation/translations/zh_TW/IRQ.txt +++ b/Documentation/translations/zh_TW/IRQ.txt @@ -7,7 +7,7 @@ help. Contact the Chinese maintainer if this translation is outdated or if there is a problem with the translation. Maintainer: Eric W. Biederman <ebiederman@xmission.com> -Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> +Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> --------------------------------------------------------------------- Documentation/core-api/irq/index.rst 的繁體中文翻譯 @@ -16,9 +16,9 @@ Documentation/core-api/irq/index.rst 的繁體中文翻譯 者翻譯存在問題，請聯繫繁體中文版維護者。 英文版維護者： Eric W. Biederman <ebiederman@xmission.com> -繁體中文版維護者： 胡皓文 Hu Haowen <src.res@email.cn> -繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res@email.cn> -繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn> +繁體中文版維護者： 胡皓文 Hu Haowen <src.res.211@gmail.com> +繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com> +繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com> 以下爲正文 diff --git a/Documentation/translations/zh_TW/admin-guide/README.rst b/Documentation/translations/zh_TW/admin-guide/README.rst index 6ce97edbab37..7fc56e1e3348 100644 --- a/Documentation/translations/zh_TW/admin-guide/README.rst +++ b/Documentation/translations/zh_TW/admin-guide/README.rst @@ -7,7 +7,7 @@ :譯者: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> Linux內核5.x版本 <http://kernel.org/> ========================================= diff --git a/Documentation/translations/zh_TW/admin-guide/bug-bisect.rst b/Documentation/translations/zh_TW/admin-guide/bug-bisect.rst index 41a39aebb8d6..b448dbf5ac87 100644 --- a/Documentation/translations/zh_TW/admin-guide/bug-bisect.rst +++ b/Documentation/translations/zh_TW/admin-guide/bug-bisect.rst @@ -7,7 +7,7 @@ :譯者: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> 二分（bisect）缺陷 +++++++++++++++++++ diff --git a/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst b/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst index 4d813aec77d2..9a3de3bff5e7 100644 --- a/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst +++ b/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst @@ -7,7 +7,7 @@ :譯者: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> 追蹤缺陷 ========= diff --git a/Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst b/Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst index bdc1a22046cf..bd0c08aab8ea 100644 --- a/Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst +++ b/Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_TW.rst -:Translator: 胡皓文 Hu Haowen <src.res@email.cn> +:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com> 清除 WARN_ONCE -------------- diff --git a/Documentation/translations/zh_TW/admin-guide/cpu-load.rst b/Documentation/translations/zh_TW/admin-guide/cpu-load.rst index be087cef1967..9e04aeac1a5c 100644 --- a/Documentation/translations/zh_TW/admin-guide/cpu-load.rst +++ b/Documentation/translations/zh_TW/admin-guide/cpu-load.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_TW.rst -:Translator: 胡皓文 Hu Haowen <src.res@email.cn> +:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com> ======== CPU 負載 diff --git a/Documentation/translations/zh_TW/admin-guide/index.rst b/Documentation/translations/zh_TW/admin-guide/index.rst index 293c20245783..2804d619201d 100644 --- a/Documentation/translations/zh_TW/admin-guide/index.rst +++ b/Documentation/translations/zh_TW/admin-guide/index.rst @@ -3,7 +3,7 @@ .. include:: ../disclaimer-zh_TW.rst :Original: :doc:`../../../admin-guide/index` -:Translator: 胡皓文 Hu Haowen <src.res@email.cn> +:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com> Linux 內核用戶和管理員指南 ========================== diff --git a/Documentation/translations/zh_TW/admin-guide/init.rst b/Documentation/translations/zh_TW/admin-guide/init.rst index 32cdf134948f..db3fdf611080 100644 --- a/Documentation/translations/zh_TW/admin-guide/init.rst +++ b/Documentation/translations/zh_TW/admin-guide/init.rst @@ -7,7 +7,7 @@ :譯者: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> 解釋「No working init found.」啓動掛起消息 ========================================== diff --git a/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst b/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst index 27638e199f13..ea51342879c0 100644 --- a/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst +++ b/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst @@ -16,7 +16,7 @@ :譯者: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> 報告問題 diff --git a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst index 15f8e9005071..65c8dd24c96d 100644 --- a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst +++ b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst @@ -7,7 +7,7 @@ :譯者: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> 安全缺陷 ========= diff --git a/Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst b/Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst index d7b3c4276417..ebe3812ead82 100644 --- a/Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst +++ b/Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst @@ -7,7 +7,7 @@ :譯者: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> 受汙染的內核 ------------- diff --git a/Documentation/translations/zh_TW/admin-guide/unicode.rst b/Documentation/translations/zh_TW/admin-guide/unicode.rst index 720875be5ef8..7908b369b85b 100644 --- a/Documentation/translations/zh_TW/admin-guide/unicode.rst +++ b/Documentation/translations/zh_TW/admin-guide/unicode.rst @@ -7,7 +7,7 @@ :譯者: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> Unicode（統一碼）支持 ====================== diff --git a/Documentation/translations/zh_TW/arm64/amu.rst b/Documentation/translations/zh_TW/arch/arm64/amu.rst index ffdc466e0f62..21ac0db63889 100644 --- a/Documentation/translations/zh_TW/arm64/amu.rst +++ b/Documentation/translations/zh_TW/arch/arm64/amu.rst @@ -1,11 +1,11 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_TW.rst +.. include:: ../../disclaimer-zh_TW.rst -:Original: :ref:`Documentation/arm64/amu.rst <amu_index>` +:Original: :ref:`Documentation/arch/arm64/amu.rst <amu_index>` Translator: Bailu Lin <bailu.lin@vivo.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> ================================== AArch64 Linux 中擴展的活動監控單元 diff --git a/Documentation/translations/zh_TW/arm64/booting.txt b/Documentation/translations/zh_TW/arch/arm64/booting.txt index b9439dd54012..3cc8f593e006 100644 --- a/Documentation/translations/zh_TW/arm64/booting.txt +++ b/Documentation/translations/zh_TW/arch/arm64/booting.txt @@ -1,6 +1,6 @@ SPDX-License-Identifier: GPL-2.0 -Chinese translated version of Documentation/arm64/booting.rst +Chinese translated version of Documentation/arch/arm64/booting.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -10,10 +10,10 @@ or if there is a problem with the translation. M: Will Deacon <will.deacon@arm.com> zh_CN: Fu Wei <wefu@redhat.com> -zh_TW: Hu Haowen <src.res@email.cn> +zh_TW: Hu Haowen <src.res.211@gmail.com> C: 55f058e7574c3615dea4615573a19bdb258696c6 --------------------------------------------------------------------- -Documentation/arm64/booting.rst 的中文翻譯 +Documentation/arch/arm64/booting.rst 的中文翻譯 如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻 @@ -23,7 +23,7 @@ Documentation/arm64/booting.rst 的中文翻譯 中文版維護者： 傅煒 Fu Wei <wefu@redhat.com> 中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com> 中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com> -繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn> +繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com> 本文翻譯提交時的 Git 檢出點爲： 55f058e7574c3615dea4615573a19bdb258696c6 以下爲正文 diff --git a/Documentation/translations/zh_TW/arm64/elf_hwcaps.rst b/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst index 3eb1c623ce31..ca7ff749a67b 100644 --- a/Documentation/translations/zh_TW/arm64/elf_hwcaps.rst +++ b/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst @@ -1,11 +1,11 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_TW.rst +.. include:: ../../disclaimer-zh_TW.rst -:Original: :ref:`Documentation/arm64/elf_hwcaps.rst <elf_hwcaps_index>` +:Original: :ref:`Documentation/arch/arm64/elf_hwcaps.rst <elf_hwcaps_index>` Translator: Bailu Lin <bailu.lin@vivo.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> ================ ARM64 ELF hwcaps @@ -95,7 +95,7 @@ HWCAP_ASIMDHP ID_AA64PFR0_EL1.AdvSIMD == 0b0001 表示有此功能。 HWCAP_CPUID - 根據 Documentation/arm64/cpu-feature-registers.rst 描述，EL0 可以訪問 + 根據 Documentation/arch/arm64/cpu-feature-registers.rst 描述，EL0 可以訪問 某些 ID 寄存器。 這些 ID 寄存器可能表示功能的可用性。 @@ -155,12 +155,12 @@ HWCAP_SB ID_AA64ISAR1_EL1.SB == 0b0001 表示有此功能。 HWCAP_PACA - 如 Documentation/arm64/pointer-authentication.rst 所描述， + 如 Documentation/arch/arm64/pointer-authentication.rst 所描述， ID_AA64ISAR1_EL1.APA == 0b0001 或 ID_AA64ISAR1_EL1.API == 0b0001 表示有此功能。 HWCAP_PACG - 如 Documentation/arm64/pointer-authentication.rst 所描述， + 如 Documentation/arch/arm64/pointer-authentication.rst 所描述， ID_AA64ISAR1_EL1.GPA == 0b0001 或 ID_AA64ISAR1_EL1.GPI == 0b0001 表示有此功能。 diff --git a/Documentation/translations/zh_TW/arm64/hugetlbpage.rst b/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst index 846b500dae97..a17858c978d6 100644 --- a/Documentation/translations/zh_TW/arm64/hugetlbpage.rst +++ b/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst @@ -1,11 +1,11 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_TW.rst +.. include:: ../../disclaimer-zh_TW.rst -:Original: :ref:`Documentation/arm64/hugetlbpage.rst <hugetlbpage_index>` +:Original: :ref:`Documentation/arch/arm64/hugetlbpage.rst <hugetlbpage_index>` Translator: Bailu Lin <bailu.lin@vivo.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> ===================== ARM64中的 HugeTLBpage diff --git a/Documentation/translations/zh_TW/arm64/index.rst b/Documentation/translations/zh_TW/arch/arm64/index.rst index 2322783f3881..a62b5f06b66c 100644 --- a/Documentation/translations/zh_TW/arm64/index.rst +++ b/Documentation/translations/zh_TW/arch/arm64/index.rst @@ -1,10 +1,10 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_TW.rst +.. include:: ../../disclaimer-zh_TW.rst -:Original: :ref:`Documentation/arm64/index.rst <arm64_index>` +:Original: :ref:`Documentation/arch/arm64/index.rst <arm64_index>` :Translator: Bailu Lin <bailu.lin@vivo.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_arm64_index: diff --git a/Documentation/translations/zh_TW/arm64/legacy_instructions.txt b/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt index 6d4454f77b9e..c2d02cd5017d 100644 --- a/Documentation/translations/zh_TW/arm64/legacy_instructions.txt +++ b/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt @@ -1,6 +1,6 @@ SPDX-License-Identifier: GPL-2.0 -Chinese translated version of Documentation/arm64/legacy_instructions.rst +Chinese translated version of Documentation/arch/arm64/legacy_instructions.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -11,9 +11,9 @@ or if there is a problem with the translation. Maintainer: Punit Agrawal <punit.agrawal@arm.com> Suzuki K. Poulose <suzuki.poulose@arm.com> Chinese maintainer: Fu Wei <wefu@redhat.com> -Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> +Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> --------------------------------------------------------------------- -Documentation/arm64/legacy_instructions.rst 的中文翻譯 +Documentation/arch/arm64/legacy_instructions.rst 的中文翻譯 如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻 @@ -26,7 +26,7 @@ Documentation/arm64/legacy_instructions.rst 的中文翻譯 中文版維護者： 傅煒 Fu Wei <wefu@redhat.com> 中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com> 中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com> -繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> +繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 以下爲正文 --------------------------------------------------------------------- diff --git a/Documentation/translations/zh_TW/arm64/memory.txt b/Documentation/translations/zh_TW/arch/arm64/memory.txt index 99c2b78b5674..0280200e791f 100644 --- a/Documentation/translations/zh_TW/arm64/memory.txt +++ b/Documentation/translations/zh_TW/arch/arm64/memory.txt @@ -1,6 +1,6 @@ SPDX-License-Identifier: GPL-2.0 -Chinese translated version of Documentation/arm64/memory.rst +Chinese translated version of Documentation/arch/arm64/memory.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -10,9 +10,9 @@ or if there is a problem with the translation. Maintainer: Catalin Marinas <catalin.marinas@arm.com> Chinese maintainer: Fu Wei <wefu@redhat.com> -Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> +Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> --------------------------------------------------------------------- -Documentation/arm64/memory.rst 的中文翻譯 +Documentation/arch/arm64/memory.rst 的中文翻譯 如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻 @@ -24,7 +24,7 @@ Documentation/arm64/memory.rst 的中文翻譯 中文版維護者： 傅煒 Fu Wei <wefu@redhat.com> 中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com> 中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com> -繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn> +繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com> 以下爲正文 --------------------------------------------------------------------- diff --git a/Documentation/translations/zh_TW/arm64/perf.rst b/Documentation/translations/zh_TW/arch/arm64/perf.rst index f1ffd55dfe50..645f3944a0f4 100644 --- a/Documentation/translations/zh_TW/arm64/perf.rst +++ b/Documentation/translations/zh_TW/arch/arm64/perf.rst @@ -1,11 +1,11 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_TW.rst +.. include:: ../../disclaimer-zh_TW.rst -:Original: :ref:`Documentation/arm64/perf.rst <perf_index>` +:Original: :ref:`Documentation/arch/arm64/perf.rst <perf_index>` Translator: Bailu Lin <bailu.lin@vivo.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> ============= Perf 事件屬性 diff --git a/Documentation/translations/zh_TW/arm64/silicon-errata.txt b/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt index bf2077197504..f6f41835a54a 100644 --- a/Documentation/translations/zh_TW/arm64/silicon-errata.txt +++ b/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt @@ -1,6 +1,6 @@ SPDX-License-Identifier: GPL-2.0 -Chinese translated version of Documentation/arm64/silicon-errata.rst +Chinese translated version of Documentation/arch/arm64/silicon-errata.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -10,10 +10,10 @@ or if there is a problem with the translation. M: Will Deacon <will.deacon@arm.com> zh_CN: Fu Wei <wefu@redhat.com> -zh_TW: Hu Haowen <src.res@email.cn> +zh_TW: Hu Haowen <src.res.211@gmail.com> C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 --------------------------------------------------------------------- -Documentation/arm64/silicon-errata.rst 的中文翻譯 +Documentation/arch/arm64/silicon-errata.rst 的中文翻譯 如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻 @@ -23,7 +23,7 @@ Documentation/arm64/silicon-errata.rst 的中文翻譯 中文版維護者： 傅煒 Fu Wei <wefu@redhat.com> 中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com> 中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com> -繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn> +繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com> 本文翻譯提交時的 Git 檢出點爲： 1926e54f115725a9248d0c4c65c22acaf94de4c4 以下爲正文 diff --git a/Documentation/translations/zh_TW/arm64/tagged-pointers.txt b/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt index 87f88628401a..c0be1d1e0d01 100644 --- a/Documentation/translations/zh_TW/arm64/tagged-pointers.txt +++ b/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt @@ -1,6 +1,6 @@ SPDX-License-Identifier: GPL-2.0 -Chinese translated version of Documentation/arm64/tagged-pointers.rst +Chinese translated version of Documentation/arch/arm64/tagged-pointers.rst If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -10,9 +10,9 @@ or if there is a problem with the translation. Maintainer: Will Deacon <will.deacon@arm.com> Chinese maintainer: Fu Wei <wefu@redhat.com> -Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> +Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> --------------------------------------------------------------------- -Documentation/arm64/tagged-pointers.rst 的中文翻譯 +Documentation/arch/arm64/tagged-pointers.rst 的中文翻譯 如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文 交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻 @@ -22,7 +22,7 @@ Documentation/arm64/tagged-pointers.rst 的中文翻譯 中文版維護者： 傅煒 Fu Wei <wefu@redhat.com> 中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com> 中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com> -繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn> +繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com> 以下爲正文 --------------------------------------------------------------------- diff --git a/Documentation/translations/zh_TW/cpu-freq/core.rst b/Documentation/translations/zh_TW/cpu-freq/core.rst index 3d890c2f2a61..f1951e1b23bb 100644 --- a/Documentation/translations/zh_TW/cpu-freq/core.rst +++ b/Documentation/translations/zh_TW/cpu-freq/core.rst @@ -4,7 +4,7 @@ :Original: :doc:`../../../cpu-freq/core` :Translator: Yanteng Si <siyanteng@loongson.cn> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_core.rst: diff --git a/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst b/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst index 2bb8197cd320..671b1bf0e2c5 100644 --- a/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst +++ b/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst @@ -4,7 +4,7 @@ :Original: :doc:`../../../cpu-freq/cpu-drivers` :Translator: Yanteng Si <siyanteng@loongson.cn> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_cpu-drivers.rst: diff --git a/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst b/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst index d80bfed50e8c..49088becd5fa 100644 --- a/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst +++ b/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst @@ -4,7 +4,7 @@ :Original: :doc:`../../../cpu-freq/cpufreq-stats` :Translator: Yanteng Si <siyanteng@loongson.cn> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_cpufreq-stats.rst: diff --git a/Documentation/translations/zh_TW/cpu-freq/index.rst b/Documentation/translations/zh_TW/cpu-freq/index.rst index 1a8e680f95ed..c6cf825b57a5 100644 --- a/Documentation/translations/zh_TW/cpu-freq/index.rst +++ b/Documentation/translations/zh_TW/cpu-freq/index.rst @@ -4,7 +4,7 @@ :Original: :doc:`../../../cpu-freq/index` :Translator: Yanteng Si <siyanteng@loongson.cn> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_index.rst: diff --git a/Documentation/translations/zh_TW/disclaimer-zh_TW.rst b/Documentation/translations/zh_TW/disclaimer-zh_TW.rst index f4cf87d03dc5..0d0ffb1ca4e8 100644 --- a/Documentation/translations/zh_TW/disclaimer-zh_TW.rst +++ b/Documentation/translations/zh_TW/disclaimer-zh_TW.rst @@ -7,5 +7,5 @@ .. note:: 如果您發現本文檔與原始文件有任何不同或者有翻譯問題，請聯繫該文件的譯者， - 或者發送電子郵件給胡皓文以獲取幫助：<src.res@email.cn>。 + 或者發送電子郵件給胡皓文以獲取幫助：<src.res.211@gmail.com>。 diff --git a/Documentation/translations/zh_TW/filesystems/debugfs.rst b/Documentation/translations/zh_TW/filesystems/debugfs.rst index 270dd94fddf1..ddf801943c92 100644 --- a/Documentation/translations/zh_TW/filesystems/debugfs.rst +++ b/Documentation/translations/zh_TW/filesystems/debugfs.rst @@ -14,12 +14,12 @@ Debugfs 中文版維護者：羅楚成 Chucheng Luo <luochucheng@vivo.com> 中文版翻譯者：羅楚成 Chucheng Luo <luochucheng@vivo.com> 中文版校譯者: 羅楚成 Chucheng Luo <luochucheng@vivo.com> - 繁體中文版校譯者: 胡皓文 Hu Haowen <src.res@email.cn> + 繁體中文版校譯者: 胡皓文 Hu Haowen <src.res.211@gmail.com> 版權所有2020 羅楚成 <luochucheng@vivo.com> -版權所有2021 胡皓文 Hu Haowen <src.res@email.cn> +版權所有2021 胡皓文 Hu Haowen <src.res.211@gmail.com> Debugfs是內核開發人員在用戶空間獲取信息的簡單方法。與/proc不同，proc只提供進程 diff --git a/Documentation/translations/zh_TW/filesystems/index.rst b/Documentation/translations/zh_TW/filesystems/index.rst index 4e5dde0dca3c..789e742fa3c5 100644 --- a/Documentation/translations/zh_TW/filesystems/index.rst +++ b/Documentation/translations/zh_TW/filesystems/index.rst @@ -4,7 +4,7 @@ :Original: :ref:`Documentation/filesystems/index.rst <filesystems_index>` :Translator: Wang Wenhu <wenhu.wang@vivo.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_filesystems_index: diff --git a/Documentation/translations/zh_TW/filesystems/sysfs.txt b/Documentation/translations/zh_TW/filesystems/sysfs.txt index 280824cc7e5d..a84eba2af9d3 100644 --- a/Documentation/translations/zh_TW/filesystems/sysfs.txt +++ b/Documentation/translations/zh_TW/filesystems/sysfs.txt @@ -22,7 +22,7 @@ Documentation/filesystems/sysfs.rst 的中文翻譯 中文版維護者： 傅煒 Fu Wei <tekkamanninja@gmail.com> 中文版翻譯者： 傅煒 Fu Wei <tekkamanninja@gmail.com> 中文版校譯者： 傅煒 Fu Wei <tekkamanninja@gmail.com> -繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> +繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 以下爲正文 diff --git a/Documentation/translations/zh_TW/filesystems/tmpfs.rst b/Documentation/translations/zh_TW/filesystems/tmpfs.rst index 8d753a34785b..2c8439b2b77e 100644 --- a/Documentation/translations/zh_TW/filesystems/tmpfs.rst +++ b/Documentation/translations/zh_TW/filesystems/tmpfs.rst @@ -5,7 +5,7 @@ :Original: Documentation/filesystems/tmpfs.rst Translated by Wang Qing <wangqing@vivo.com> -and Hu Haowen <src.res@email.cn> +and Hu Haowen <src.res.211@gmail.com> ===== Tmpfs diff --git a/Documentation/translations/zh_TW/filesystems/virtiofs.rst b/Documentation/translations/zh_TW/filesystems/virtiofs.rst index 2b05e84375dd..086fce5839dd 100644 --- a/Documentation/translations/zh_TW/filesystems/virtiofs.rst +++ b/Documentation/translations/zh_TW/filesystems/virtiofs.rst @@ -11,7 +11,7 @@ 中文版翻譯者： 王文虎 Wang Wenhu <wenhu.wang@vivo.com> 中文版校譯者： 王文虎 Wang Wenhu <wenhu.wang@vivo.com> 中文版校譯者： 王文虎 Wang Wenhu <wenhu.wang@vivo.com> - 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> + 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> =========================================== virtiofs: virtio-fs 主機<->客機共享文件系統 diff --git a/Documentation/translations/zh_TW/gpio.txt b/Documentation/translations/zh_TW/gpio.txt index 62e560ffe628..555e4b11a5c7 100644 --- a/Documentation/translations/zh_TW/gpio.txt +++ b/Documentation/translations/zh_TW/gpio.txt @@ -8,7 +8,7 @@ or if there is a problem with the translation. Maintainer: Grant Likely <grant.likely@secretlab.ca> Linus Walleij <linus.walleij@linaro.org> -Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> +Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> --------------------------------------------------------------------- Documentation/admin-guide/gpio 的繁體中文翻譯 @@ -18,9 +18,9 @@ Documentation/admin-guide/gpio 的繁體中文翻譯 英文版維護者： Grant Likely <grant.likely@secretlab.ca> Linus Walleij <linus.walleij@linaro.org> -繁體中文版維護者： 胡皓文 Hu Haowen <src.res@email.cn> -繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res@email.cn> -繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn> +繁體中文版維護者： 胡皓文 Hu Haowen <src.res.211@gmail.com> +繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com> +繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com> 以下爲正文 --------------------------------------------------------------------- @@ -161,8 +161,7 @@ get/set(獲取/設置)函數調用沒法返回錯誤,且有可能是配置錯誤 大多數 GPIO 控制器可以通過內存讀/寫指令來訪問。這些指令不會休眠,可以 安全地在硬(非線程)中斷例程和類似的上下文中完成。 -對於那些用 gpio_cansleep()測試總是返回失敗的 GPIO(見下文)，使用 -以下的函數訪問: +對於那些 GPIO，使用以下的函數訪問: /* GPIO 輸入:返回零或非零 */ int gpio_get_value(unsigned gpio); @@ -193,11 +192,6 @@ GPIO值是布爾值，零表示低電平，非零表示高電平。當讀取一 GPIO 值的命令需要等待其信息排到隊首才發送命令，再獲得其反饋。期間需要 休眠，這不能在 IRQ 例程(中斷上下文)中執行。 -支持此類 GPIO 的平台通過以下函數返回非零值來區分出這種 GPIO。(此函數需要 -一個之前通過 gpio_request 分配到的有效 GPIO 編號): - - int gpio_cansleep(unsigned gpio); - 爲了訪問這種 GPIO,內核定義了一套不同的函數: /* GPIO 輸入:返回零或非零 ,可能會休眠 */ @@ -206,7 +200,6 @@ GPIO 值的命令需要等待其信息排到隊首才發送命令，再獲得其 /* GPIO 輸出,可能會休眠 */ void gpio_set_value_cansleep(unsigned gpio, int value); - 訪問這樣的 GPIO 需要一個允許休眠的上下文，例如線程 IRQ 處理例程，並用以上的 訪問函數替換那些沒有 cansleep()後綴的自旋鎖安全訪問函數。 @@ -300,11 +293,6 @@ gpio_request()前將這類細節配置好，例如使用 pinctrl 子系統的映 * GPIOF_INIT_LOW - 在作爲輸出時,初始值爲低電平 * GPIOF_INIT_HIGH - 在作爲輸出時,初始值爲高電平 - * GPIOF_OPEN_DRAIN - gpio引腳爲開漏信號 - * GPIOF_OPEN_SOURCE - gpio引腳爲源極開路信號 - - * GPIOF_EXPORT_DIR_FIXED - 將 gpio 導出到 sysfs，並保持方向 - * GPIOF_EXPORT_DIR_CHANGEABLE - 同樣是導出, 但允許改變方向 因爲 GPIOF_INIT_* 僅有在配置爲輸出的時候才存在,所以有效的組合爲: @@ -312,18 +300,6 @@ gpio_request()前將這類細節配置好，例如使用 pinctrl 子系統的映 * GPIOF_OUT_INIT_LOW - 配置爲輸出,並初始化爲低電平 * GPIOF_OUT_INIT_HIGH - 配置爲輸出,並初始化爲高電平 -當設置 flag 爲 GPIOF_OPEN_DRAIN 時，則假設引腳是開漏信號。這樣的引腳 -將不會在輸出模式下置1。這樣的引腳需要連接上拉電阻。通過使能這個標誌，gpio庫 -將會在被要求輸出模式下置1時將引腳變爲輸入狀態來使引腳置高。引腳在輸出模式下 -通過置0使其輸出低電平。 - -當設置 flag 爲 GPIOF_OPEN_SOURCE 時，則假設引腳爲源極開路信號。這樣的引腳 -將不會在輸出模式下置0。這樣的引腳需要連接下拉電阻。通過使能這個標誌，gpio庫 -將會在被要求輸出模式下置0時將引腳變爲輸入狀態來使引腳置低。引腳在輸出模式下 -通過置1使其輸出高電平。 - -將來這些標誌可能擴展到支持更多的屬性。 - 更進一步,爲了更簡單地聲明/釋放多個 GPIO,'struct gpio'被引進來封裝所有 這三個領域: @@ -466,8 +442,8 @@ GPIO 實現者的框架 (可選) ------- 爲了支持這個框架，一個平台的 Kconfig 文件將會 "select"(選擇) ARCH_REQUIRE_GPIOLIB 或 ARCH_WANT_OPTIONAL_GPIOLIB，並讓它的 -<asm/gpio.h> 包含 <asm-generic/gpio.h>，同時定義三個方法: -gpio_get_value()、gpio_set_value()和 gpio_cansleep()。 +<asm/gpio.h> 包含 <asm-generic/gpio.h>，同時定義二個方法: +gpio_get_value()、gpio_set_value()。 它也應提供一個 ARCH_NR_GPIOS 的定義值，這樣可以更好地反映該平台 GPIO 的實際數量,節省靜態表的空間。(這個定義值應該包含片上系統內建 GPIO 和 @@ -485,7 +461,6 @@ ARCH_WANT_OPTIONAL_GPIOLIB 意味著 gpiolib 核心默認關閉,且用戶可以 #define gpio_get_value __gpio_get_value #define gpio_set_value __gpio_set_value - #define gpio_cansleep __gpio_cansleep 這些定義可以用更理想的實現方法替代，那就是使用經過邏輯優化的內聯函數來訪問 基於特定片上系統的 GPIO。例如,若引用的 GPIO (寄存器位偏移)是常量「12」， diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst index e97d7d578751..d1cf0b4d8e46 100644 --- a/Documentation/translations/zh_TW/index.rst +++ b/Documentation/translations/zh_TW/index.rst @@ -15,159 +15,115 @@ .. note:: 內核文檔繁體中文版的翻譯工作正在進行中。如果您願意並且有時間參與這項工 - 作，歡迎提交補丁給胡皓文 <src.res@email.cn>。 + 作，歡迎提交補丁給胡皓文 <src.res.211@gmail.com>。 -許可證文檔 ----------- - -下面的文檔介紹了Linux內核原始碼的許可證（GPLv2）、如何在原始碼樹中正確標記 -單個文件的許可證、以及指向完整許可證文本的連結。 - -Documentation/translations/zh_TW/process/license-rules.rst +與Linux 內核社區一起工作 +------------------------ -用戶文檔 --------- - -下面的手冊是爲內核用戶編寫的——即那些試圖讓它在給定系統上以最佳方式工作的 -用戶。 +與內核開發社區進行協作並將工作推向上游的基本指南。 .. toctree:: - :maxdepth: 2 + :maxdepth: 1 - admin-guide/index + process/development-process + process/submitting-patches + 行爲準則 <process/code-of-conduct> + 完整開發流程文檔 <process/index> TODOList: -* kbuild/index +* maintainer/index -固件相關文檔 ------------- +內部API文檔 +----------- -下列文檔描述了內核需要的平台固件相關信息。 +開發人員使用的內核內部交互接口手冊。 TODOList: -* firmware-guide/index -* devicetree/index - -應用程式開發人員文檔 --------------------- - -用戶空間API手冊涵蓋了描述應用程式開發人員可見內核接口方面的文檔。 - -TODOlist: - -* userspace-api/index +* core-api/index +* driver-api/index +* 內核中的鎖 <locking/index> +* subsystem-apis -內核開發簡介 ------------- +開發工具和流程 +-------------- -這些手冊包含有關如何開發內核的整體信息。內核社區非常龐大，一年下來有數千名 -開發人員做出貢獻。與任何大型社區一樣，知道如何完成任務將使得更改合併的過程 -變得更加容易。 +爲所有內核開發人員提供有用信息的各種其他手冊。 .. toctree:: - :maxdepth: 2 + :maxdepth: 1 - process/index + process/license-rules TODOList: -* dev-tools/index * doc-guide/index +* dev-tools/index +* dev-tools/testing-overview * kernel-hacking/index +* rust/index * trace/index -* maintainer/index * fault-injection/index * livepatch/index -* rust/index -內核API文檔 ------------ +面向用戶的文檔 +-------------- -以下手冊從內核開發人員的角度詳細介紹了特定的內核子系統是如何工作的。這裡的 -大部分信息都是直接從內核原始碼獲取的，並根據需要添加補充材料（或者至少是在 -我們設法添加的時候——可能不是所有的都是有需要的）。 +下列手冊針對 +希望內核在給定系統上以最佳方式工作的*用戶*， +和查找內核用戶空間API信息的程序開發人員。 .. toctree:: - :maxdepth: 2 + :maxdepth: 1 - cpu-freq/index - filesystems/index + admin-guide/index + admin-guide/reporting-issues.rst TODOList: -* driver-api/index -* core-api/index -* locking/index -* accounting/index -* block/index -* cdrom/index -* ide/index -* fb/index -* fpga/index -* hid/index -* i2c/index -* iio/index -* isdn/index -* infiniband/index -* leds/index -* netlabel/index -* networking/index -* pcmcia/index -* power/index -* target/index -* timers/index -* spi/index -* w1/index -* watchdog/index -* virt/index -* input/index -* hwmon/index -* gpu/index -* security/index -* sound/index -* crypto/index -* mm/index -* bpf/index -* usb/index -* PCI/index -* scsi/index -* misc-devices/index -* scheduler/index -* mhi/index - -體系結構無關文檔 ----------------- +* userspace-api/index +* 內核構建系統 <kbuild/index> +* 用戶空間工具 <tools/index> -TODOList: +也可參考獨立於內核文檔的 `Linux 手冊頁 <https://www.kernel.org/doc/man-pages/>`_ 。 + +固件相關文檔 +------------ -* asm-annotations +下列文檔描述了內核需要的平臺固件相關信息。 -特定體系結構文檔 ----------------- +TODOList: -.. toctree:: - :maxdepth: 2 +* devicetree/index +* firmware-guide/index - arm64/index +體系結構文檔 +------------ TODOList: -* arch +* arch/index 其他文檔 -------- -有幾份未排序的文檔似乎不適合放在文檔的其他部分，或者可能需要進行一些調整和/或 +有幾份未分類的文檔似乎不適合放在文檔的其他部分，或者可能需要進行一些調整和/或 轉換爲reStructureText格式，也有可能太舊。 TODOList: * staging/index -* watch_queue -目錄和表格 +術語表 +------ + +TODOList: + +* glossary + + +索引和表格 ---------- * :ref:`genindex` diff --git a/Documentation/translations/zh_TW/io_ordering.txt b/Documentation/translations/zh_TW/io_ordering.txt index 1e99206c8421..03f86840c139 100644 --- a/Documentation/translations/zh_TW/io_ordering.txt +++ b/Documentation/translations/zh_TW/io_ordering.txt @@ -6,7 +6,7 @@ communicating in English you can also ask the Chinese maintainer for help. Contact the Chinese maintainer if this translation is outdated or if there is a problem with the translation. -Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> +Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> --------------------------------------------------------------------- Documentation/driver-api/io_ordering.rst 的繁體中文翻譯 @@ -14,9 +14,9 @@ Documentation/driver-api/io_ordering.rst 的繁體中文翻譯 交流有困難的話，也可以向繁體中文版維護者求助。如果本翻譯更新不及時或 者翻譯存在問題，請聯繫繁體中文版維護者。 -繁體中文版維護者： 胡皓文 Hu Haowen <src.res@email.cn> -繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res@email.cn> -繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn> +繁體中文版維護者： 胡皓文 Hu Haowen <src.res.211@gmail.com> +繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com> +繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com> 以下爲正文 diff --git a/Documentation/translations/zh_TW/process/1.Intro.rst b/Documentation/translations/zh_TW/process/1.Intro.rst index ca2b931be6c5..f236fe95a6c6 100644 --- a/Documentation/translations/zh_TW/process/1.Intro.rst +++ b/Documentation/translations/zh_TW/process/1.Intro.rst @@ -11,7 +11,7 @@ :校譯: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> .. _tw_development_process_intro: diff --git a/Documentation/translations/zh_TW/process/2.Process.rst b/Documentation/translations/zh_TW/process/2.Process.rst index b01cdd3a39ae..17bb4e07d171 100644 --- a/Documentation/translations/zh_TW/process/2.Process.rst +++ b/Documentation/translations/zh_TW/process/2.Process.rst @@ -11,7 +11,7 @@ :校譯: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> .. _tw_development_process: @@ -361,7 +361,7 @@ Andrew Morton 爲有抱負的內核開發人員提供了如下建議 機器上始終完美運行」。通常的方法是和其他人一起解決問題（這可能需 要堅持！），但就是如此——這是內核開發的一部分。 -(http://lwn.net/articles/283982/) +(http://lwn.net/Articles/283982/) 在沒有明顯問題需要解決的情況下，通常建議開發人員查看當前的回歸和開放缺陷 列表。從來都不缺少需要解決的問題；通過解決這些問題，開發人員將從該過程獲得 diff --git a/Documentation/translations/zh_TW/process/3.Early-stage.rst b/Documentation/translations/zh_TW/process/3.Early-stage.rst index ab2a45fd65a4..636e506fd196 100644 --- a/Documentation/translations/zh_TW/process/3.Early-stage.rst +++ b/Documentation/translations/zh_TW/process/3.Early-stage.rst @@ -11,7 +11,7 @@ :校譯: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> .. _tw_development_early_stage: @@ -47,7 +47,7 @@ 試圖向這些人傳達用戶需求是浪費時間。他們太「聰明」了，根本聽不到少數 人的話。 -（http://lwn.net/articles/131776/） +（http://lwn.net/Articles/131776/） 實際情況卻是不同的；與特定模塊相比，內核開發人員更關心系統穩定性、長期維護 以及找到問題的正確解決方案。這個故事的寓意是把重點放在問題上——而不是具體的 diff --git a/Documentation/translations/zh_TW/process/4.Coding.rst b/Documentation/translations/zh_TW/process/4.Coding.rst index ccc3946227a0..adb5339aab6a 100644 --- a/Documentation/translations/zh_TW/process/4.Coding.rst +++ b/Documentation/translations/zh_TW/process/4.Coding.rst @@ -11,7 +11,7 @@ :校譯: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> .. _tw_development_coding: @@ -152,7 +152,7 @@ Linus對這個問題給出了最佳答案: 所以我們不會通過引入新問題來修復錯誤。這種方式是靠不住的，沒人知道 是否真的有進展。是前進兩步、後退一步，還是前進一步、後退兩步？ -（http://lwn.net/articles/243460/） +（http://lwn.net/Articles/243460/） 特別不受歡迎的一種回歸類型是用戶空間ABI的任何變化。一旦接口被導出到用戶空間， 就必須無限期地支持它。這一事實使得用戶空間接口的創建特別具有挑戰性：因爲它們 diff --git a/Documentation/translations/zh_TW/process/5.Posting.rst b/Documentation/translations/zh_TW/process/5.Posting.rst index 280a8832ecc0..27015622ad63 100644 --- a/Documentation/translations/zh_TW/process/5.Posting.rst +++ b/Documentation/translations/zh_TW/process/5.Posting.rst @@ -11,7 +11,7 @@ :校譯: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> .. _tw_development_posting: diff --git a/Documentation/translations/zh_TW/process/6.Followthrough.rst b/Documentation/translations/zh_TW/process/6.Followthrough.rst index 4af782742db3..5073b6e77c1c 100644 --- a/Documentation/translations/zh_TW/process/6.Followthrough.rst +++ b/Documentation/translations/zh_TW/process/6.Followthrough.rst @@ -11,7 +11,7 @@ :校譯: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> .. _tw_development_followthrough: diff --git a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst index 3de093d0f170..2cbd16bfed29 100644 --- a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst +++ b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst @@ -11,7 +11,7 @@ :校譯: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> .. _tw_development_advancedtopics: @@ -101,7 +101,7 @@ Git提供了一些強大的工具，可以讓您重寫開發歷史。一個不 你可以給我發補丁，但當我從你那裡拉取一個Git補丁時，我需要知道你清楚 自己在做什麼，我需要能夠相信事情而 *無需* 手動檢查每個單獨的更改。 -（http://lwn.net/articles/224135/）。 +（http://lwn.net/Articles/224135/）。 爲了避免這種情況，請確保給定分支中的所有補丁都與相關主題緊密相關；「驅動程序 修復」分支不應更改核心內存管理代碼。而且，最重要的是，不要使用Git樹來繞過 diff --git a/Documentation/translations/zh_TW/process/8.Conclusion.rst b/Documentation/translations/zh_TW/process/8.Conclusion.rst index 044fcc118bef..1207991d1570 100644 --- a/Documentation/translations/zh_TW/process/8.Conclusion.rst +++ b/Documentation/translations/zh_TW/process/8.Conclusion.rst @@ -10,7 +10,7 @@ :校譯: 吳想成 Wu XiangCheng <bobwxc@email.cn> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> .. _tw_development_conclusion: diff --git a/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst index 949d831aaf6c..920bb0f36974 100644 --- a/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst +++ b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst @@ -4,7 +4,7 @@ :Original: :ref:`Documentation/process/code-of-conduct-interpretation.rst <code_of_conduct_interpretation>` :Translator: Alex Shi <alex.shi@linux.alibaba.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_code_of_conduct_interpretation: diff --git a/Documentation/translations/zh_TW/process/code-of-conduct.rst b/Documentation/translations/zh_TW/process/code-of-conduct.rst index 716e5843b6e9..e3087112f0bc 100644 --- a/Documentation/translations/zh_TW/process/code-of-conduct.rst +++ b/Documentation/translations/zh_TW/process/code-of-conduct.rst @@ -4,7 +4,7 @@ :Original: :ref:`Documentation/process/code-of-conduct.rst <code_of_conduct>` :Translator: Alex Shi <alex.shi@linux.alibaba.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_code_of_conduct: diff --git a/Documentation/translations/zh_TW/process/coding-style.rst b/Documentation/translations/zh_TW/process/coding-style.rst index 61e614aad6a7..83862e4d3b64 100644 --- a/Documentation/translations/zh_TW/process/coding-style.rst +++ b/Documentation/translations/zh_TW/process/coding-style.rst @@ -15,7 +15,7 @@ 管旭東 Xudong Guan <xudong.guan@gmail.com> Li Zefan <lizf@cn.fujitsu.com> Wang Chen <wangchen@cn.fujitsu.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> Linux 內核代碼風格 ========================= diff --git a/Documentation/translations/zh_TW/process/development-process.rst b/Documentation/translations/zh_TW/process/development-process.rst index 45e6385647cd..f4cf5c2bbc82 100644 --- a/Documentation/translations/zh_TW/process/development-process.rst +++ b/Documentation/translations/zh_TW/process/development-process.rst @@ -4,7 +4,7 @@ :Original: :ref:`Documentation/process/development-process.rst <development_process_main>` :Translator: Alex Shi <alex.shi@linux.alibaba.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_development_process_main: diff --git a/Documentation/translations/zh_TW/process/email-clients.rst b/Documentation/translations/zh_TW/process/email-clients.rst index 4ba543d06f3b..ae63e41d9cee 100644 --- a/Documentation/translations/zh_TW/process/email-clients.rst +++ b/Documentation/translations/zh_TW/process/email-clients.rst @@ -14,7 +14,7 @@ 中文版校譯者： Yinglin Luan <synmyth@gmail.com> Xiaochen Wang <wangxiaochen0@gmail.com> yaxinsn <yaxinsn@163.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> Linux郵件客戶端配置信息 ======================= diff --git a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst index fbde3e26eda5..8e4db8baa0d1 100644 --- a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst +++ b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst @@ -4,7 +4,7 @@ :Original: :ref:`Documentation/process/embargoed-hardware-issues.rst <embargoed_hardware_issues>` :Translator: Alex Shi <alex.shi@linux.alibaba.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> 被限制的硬體問題 ================ diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst index ea2f468d3e58..306f5b77b4b8 100644 --- a/Documentation/translations/zh_TW/process/howto.rst +++ b/Documentation/translations/zh_TW/process/howto.rst @@ -16,7 +16,7 @@ 鍾宇 TripleX Chung <xxx.phy@gmail.com> 陳琦 Maggie Chen <chenqi@beyondsoft.com> 王聰 Wang Cong <xiyou.wangcong@gmail.com> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> 如何參與Linux內核開發 ===================== diff --git a/Documentation/translations/zh_TW/process/index.rst b/Documentation/translations/zh_TW/process/index.rst index c5c59b4fd595..d742642dab01 100644 --- a/Documentation/translations/zh_TW/process/index.rst +++ b/Documentation/translations/zh_TW/process/index.rst @@ -9,7 +9,7 @@ :Original: :ref:`Documentation/process/index.rst <process_index>` :Translator: Alex Shi <alex.shi@linux.alibaba.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_process_index: diff --git a/Documentation/translations/zh_TW/process/kernel-driver-statement.rst b/Documentation/translations/zh_TW/process/kernel-driver-statement.rst index 8f225379b12c..963ecece3db1 100644 --- a/Documentation/translations/zh_TW/process/kernel-driver-statement.rst +++ b/Documentation/translations/zh_TW/process/kernel-driver-statement.rst @@ -6,7 +6,7 @@ :Original: :ref:`Documentation/process/kernel-driver-statement.rst <process_statement_driver>` :Translator: Alex Shi <alex.shi@linux.alibaba.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> 內核驅動聲明 ------------ diff --git a/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst b/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst index 99e21d22800d..2861f4a15721 100644 --- a/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst +++ b/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst @@ -6,7 +6,7 @@ :Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>` :Translator: Alex Shi <alex.shi@linux.alibaba.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> Linux 內核執行聲明 ------------------ diff --git a/Documentation/translations/zh_TW/process/license-rules.rst b/Documentation/translations/zh_TW/process/license-rules.rst index ad2b80f97123..503b6701bde4 100644 --- a/Documentation/translations/zh_TW/process/license-rules.rst +++ b/Documentation/translations/zh_TW/process/license-rules.rst @@ -6,7 +6,7 @@ :Original: :ref:`Documentation/process/license-rules.rst <kernel_licensing>` :Translator: Alex Shi <alex.shi@linux.alibaba.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_kernel_licensing: diff --git a/Documentation/translations/zh_TW/process/magic-number.rst b/Documentation/translations/zh_TW/process/magic-number.rst index c9e3db12c3f9..5657d5cd18d4 100644 --- a/Documentation/translations/zh_TW/process/magic-number.rst +++ b/Documentation/translations/zh_TW/process/magic-number.rst @@ -12,7 +12,7 @@ 中文版維護者： 賈威威 Jia Wei Wei <harryxiyou@gmail.com> 中文版翻譯者： 賈威威 Jia Wei Wei <harryxiyou@gmail.com> 中文版校譯者： 賈威威 Jia Wei Wei <harryxiyou@gmail.com> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> Linux 魔術數 ============ diff --git a/Documentation/translations/zh_TW/process/management-style.rst b/Documentation/translations/zh_TW/process/management-style.rst index dce248470063..e9d29024f4c9 100644 --- a/Documentation/translations/zh_TW/process/management-style.rst +++ b/Documentation/translations/zh_TW/process/management-style.rst @@ -4,7 +4,7 @@ :Original: :ref:`Documentation/process/management-style.rst <managementstyle>` :Translator: Alex Shi <alex.shi@linux.alibaba.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_managementstyle: diff --git a/Documentation/translations/zh_TW/process/programming-language.rst b/Documentation/translations/zh_TW/process/programming-language.rst index 144bdaf81a41..e33389676eed 100644 --- a/Documentation/translations/zh_TW/process/programming-language.rst +++ b/Documentation/translations/zh_TW/process/programming-language.rst @@ -4,7 +4,7 @@ :Original: :ref:`Documentation/process/programming-language.rst <programming_language>` :Translator: Alex Shi <alex.shi@linux.alibaba.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_programming_language: diff --git a/Documentation/translations/zh_TW/process/stable-api-nonsense.rst b/Documentation/translations/zh_TW/process/stable-api-nonsense.rst index 22caa5b8d422..33fc85c2cc51 100644 --- a/Documentation/translations/zh_TW/process/stable-api-nonsense.rst +++ b/Documentation/translations/zh_TW/process/stable-api-nonsense.rst @@ -12,7 +12,7 @@ 中文版維護者： 鍾宇 TripleX Chung <xxx.phy@gmail.com> 中文版翻譯者： 鍾宇 TripleX Chung <xxx.phy@gmail.com> 中文版校譯者： 李陽 Li Yang <leoyang.li@nxp.com> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> Linux 內核驅動接口 ================== diff --git a/Documentation/translations/zh_TW/process/stable-kernel-rules.rst b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst index 9bb0d9b4f3ac..29d9a70a1868 100644 --- a/Documentation/translations/zh_TW/process/stable-kernel-rules.rst +++ b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst @@ -15,7 +15,7 @@ 中文版校譯者： - 李陽 Li Yang <leoyang.li@nxp.com> - Kangkai Yin <e12051@motorola.com> - - 胡皓文 Hu Haowen <src.res@email.cn> + - 胡皓文 Hu Haowen <src.res.211@gmail.com> 所有你想知道的事情 - 關於linux穩定版發布 ======================================== diff --git a/Documentation/translations/zh_TW/process/submit-checklist.rst b/Documentation/translations/zh_TW/process/submit-checklist.rst index ff2f89cba83f..12bf6f5ca5c6 100644 --- a/Documentation/translations/zh_TW/process/submit-checklist.rst +++ b/Documentation/translations/zh_TW/process/submit-checklist.rst @@ -4,7 +4,7 @@ :Original: :ref:`Documentation/process/submit-checklist.rst <submitchecklist>` :Translator: Alex Shi <alex.shi@linux.alibaba.com> - Hu Haowen <src.res@email.cn> + Hu Haowen <src.res.211@gmail.com> .. _tw_submitchecklist: diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst index 3f77ef5d48a0..0746809c31a2 100644 --- a/Documentation/translations/zh_TW/process/submitting-patches.rst +++ b/Documentation/translations/zh_TW/process/submitting-patches.rst @@ -13,7 +13,7 @@ 時奎亮 Alex Shi <alex.shi@linux.alibaba.com> 中文版校譯者： 李陽 Li Yang <leoyang.li@nxp.com> 王聰 Wang Cong <xiyou.wangcong@gmail.com> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> 如何讓你的改動進入內核 diff --git a/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst b/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst index 097fe80352cb..469cb5b3a07c 100644 --- a/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst +++ b/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst @@ -17,7 +17,7 @@ 中文版校譯者： 張漢輝 Eugene Teo <eugeneteo@kernel.sg> 楊瑞 Dave Young <hidave.darkstar@gmail.com> 時奎亮 Alex Shi <alex.shi@linux.alibaba.com> - 胡皓文 Hu Haowen <src.res@email.cn> + 胡皓文 Hu Haowen <src.res.211@gmail.com> 爲什麼不應該使用「volatile」類型 ================================ diff --git a/Documentation/translations/zh_TW/sparse.txt b/Documentation/translations/zh_TW/sparse.txt index c9acb2c926cb..35d3d1d748e6 100644 --- a/Documentation/translations/zh_TW/sparse.txt +++ b/Documentation/translations/zh_TW/sparse.txt @@ -6,7 +6,7 @@ communicating in English you can also ask the Chinese maintainer for help. Contact the Chinese maintainer if this translation is outdated or if there is a problem with the translation. -Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> +Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> --------------------------------------------------------------------- Documentation/dev-tools/sparse.rst 的繁體中文翻譯 @@ -14,8 +14,8 @@ Documentation/dev-tools/sparse.rst 的繁體中文翻譯 交流有困難的話，也可以向繁體中文版維護者求助。如果本翻譯更新不及時或 者翻譯存在問題，請聯繫繁體中文版維護者。 -繁體中文版維護者： 胡皓文 Hu Haowen <src.res@email.cn> -繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res@email.cn> +繁體中文版維護者： 胡皓文 Hu Haowen <src.res.211@gmail.com> +繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com> 以下爲正文 --------------------------------------------------------------------- @@ -66,11 +66,11 @@ __bitwise"類型。 你可以從 Sparse 的主頁獲取最新的發布版本： - http://www.kernel.org/pub/linux/kernel/people/josh/sparse/ + https://www.kernel.org/pub/software/devel/sparse/dist/ 或者，你也可以使用 git 克隆最新的 sparse 開發版本： - git://git.kernel.org/pub/scm/linux/kernel/git/josh/sparse.git + git://git.kernel.org/pub/scm/devel/sparse/sparse.git 一旦你下載了源碼，只要以普通用戶身份運行： diff --git a/Documentation/usb/authorization.rst b/Documentation/usb/authorization.rst index 9e53909d04c2..150a14970e95 100644 --- a/Documentation/usb/authorization.rst +++ b/Documentation/usb/authorization.rst @@ -33,12 +33,9 @@ Remove the lock down:: $ echo 1 > /sys/bus/usb/devices/usbX/authorized_default -By default, Wired USB devices are authorized by default to -connect. Wireless USB hosts deauthorize by default all new connected -devices (this is so because we need to do an authentication phase -before authorizing). Writing "2" to the authorized_default attribute -causes kernel to only authorize by default devices connected to internal -USB ports. +By default, all USB devices are authorized. Writing "2" to the +authorized_default attribute causes the kernel to authorize by default +only devices connected to internal USB ports. Example system lockdown (lame) diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 2fca40443dc9..394cd226bfae 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -27,6 +27,7 @@ provided by gadgets. 18. UVC function 19. PRINTER function 20. UAC1 function (new API) + 21. MIDI2 function 1. ACM function @@ -965,3 +966,156 @@ e.g.:: $ arecord -f dat -t wav -D hw:CARD=UAC1Gadget,DEV=0 | \ aplay -D default:CARD=OdroidU3 + + +21. MIDI2 function +================== + +The function is provided by usb_f_midi2.ko module. +It will create a virtual ALSA card containing a UMP rawmidi device +where the UMP packet is looped back. In addition, a legacy rawmidi +device is created. The UMP rawmidi is bound with ALSA sequencer +clients, too. + +Function-specific configfs interface +------------------------------------ + +The function name to use when creating the function directory is "midi2". +The midi2 function provides these attributes in its function directory +as the card top-level information: + + ============= ================================================= + process_ump Bool flag to process UMP Stream messages (0 or 1) + static_block Bool flag for static blocks (0 or 1) + iface_name Optional interface name string + ============= ================================================= + +The directory contains a subdirectory "ep.0", and this provides the +attributes for a UMP Endpoint (which is a pair of USB MIDI Endpoints): + + ============= ================================================= + protocol_caps MIDI protocol capabilities; + 1: MIDI 1.0, 2: MIDI 2.0, or 3: both protocols + protocol Default MIDI protocol (either 1 or 2) + ep_name UMP Endpoint name string + product_id Product ID string + manufacturer Manufacture ID number (24 bit) + family Device family ID number (16 bit) + model Device model ID number (16 bit) + sw_revision Software revision (32 bit) + ============= ================================================= + +Each Endpoint subdirectory contains a subdirectory "block.0", which +represents the Function Block for Block 0 information. +Its attributes are: + + ================= =============================================== + name Function Block name string + direction Direction of this FB + 1: input, 2: output, or 3: bidirectional + first_group The first UMP Group number (0-15) + num_groups The number of groups in this FB (1-16) + 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 UI-hint of this FB + 0: unknown, 1: receiver, 2: sender, 3: both + midi_ci_verison 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 + 2: MIDI 1.0 with low speed + sysex8_streams Max number of SysEx8 streams (8 bit) + active Bool flag for FB activity (0 or 1) + ================= =============================================== + +If multiple Function Blocks are required, you can add more Function +Blocks by creating subdirectories "block.<num>" with the corresponding +Function Block number (1, 2, ....). The FB subdirectories can be +dynamically removed, too. Note that the Function Block numbers must be +continuous. + +Similarly, if you multiple UMP Endpoints are required, you can add +more Endpoints by creating subdirectories "ep.<num>". The number must +be continuous. + +For emulating the old MIDI 2.0 device without UMP v1.1 support, pass 0 +to `process_ump` flag. Then the whole UMP v1.1 requests are ignored. + +Testing the MIDI2 function +-------------------------- + +On the device: run the gadget, and running:: + + $ cat /proc/asound/cards + +will show a new sound card containing a MIDI2 device. + +OTOH, on the host:: + + $ cat /proc/asound/cards + +will show a new sound card containing either MIDI1 or MIDI2 device, +depending on the USB audio driver configuration. + +On both, when ALSA sequencer is enabled on the host, you can find the +UMP MIDI client such as "MIDI 2.0 Gadget". + +As the driver simply loops back the data, there is no need for a real +device just for testing. + +For testing a MIDI input from the gadget to the host (e.g. emulating a +MIDI keyboard), you can send a MIDI stream like the following. + +On the gadget:: + + $ aconnect -o + .... + client 20: 'MIDI 2.0 Gadget' [type=kernel,card=1] + 0 'MIDI 2.0 ' + 1 'Group 1 (MIDI 2.0 Gadget I/O)' + $ aplaymidi -p 20:1 to_host.mid + +On the host:: + + $ aconnect -i + .... + client 24: 'MIDI 2.0 Gadget' [type=kernel,card=2] + 0 'MIDI 2.0 ' + 1 'Group 1 (MIDI 2.0 Gadget I/O)' + $ arecordmidi -p 24:1 from_gadget.mid + +If you have a UMP-capable application, you can use the UMP port to +send/receive the raw UMP packets, too. For example, aseqdump program +with UMP support can receive from UMP port. On the host:: + + $ aseqdump -u 2 -p 24:1 + Waiting for data. Press Ctrl+C to end. + Source Group Event Ch Data + 24:1 Group 0, Program change 0, program 0, Bank select 0:0 + 24:1 Group 0, Channel pressure 0, value 0x80000000 + +For testing a MIDI output to the gadget to the host (e.g. emulating a +MIDI synth), it'll be just other way round. + +On the gadget:: + + $ arecordmidi -p 20:1 from_host.mid + +On the host:: + + $ aplaymidi -p 24:1 to_gadget.mid + +The access to MIDI 1.0 on altset 0 on the host is supported, and it's +translated from/to UMP packets on the gadget. It's bound to only +Function Block 0. + +The current operation mode can be observed in ALSA control element +"Operation Mode" for SND_CTL_IFACE_RAWMIDI. For example:: + + $ amixer -c1 contents + numid=1,iface=RAWMIDI,name='Operation Mode' + ; type=INTEGER,access=r--v----,values=1,min=0,max=2,step=0 + : values=2 + +where 0 = unused, 1 = MIDI 1.0 (altset 0), 2 = MIDI 2.0 (altset 1). +The example above shows it's running in 2, i.e. MIDI 2.0. diff --git a/Documentation/usb/gadget_uvc.rst b/Documentation/usb/gadget_uvc.rst index 62bd81ba3dd1..80a1f031b593 100644 --- a/Documentation/usb/gadget_uvc.rst +++ b/Documentation/usb/gadget_uvc.rst @@ -168,7 +168,7 @@ Header linking The UVC specification requires that Format and Frame descriptors be preceded by Headers detailing things such as the number and cumulative size of the different -Format descriptors that follow. This and similar operations are acheived in +Format descriptors that follow. This and similar operations are achieved in configfs by linking between the configfs item representing the header and the config items representing those other descriptors, in this manner: diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 4f7b23faebb9..4ea5b837399a 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -180,6 +180,7 @@ Code Seq# Include File Comments 'P' 00-0F drivers/usb/class/usblp.c conflict! 'P' 01-09 drivers/misc/pci_endpoint_test.c conflict! 'P' 00-0F xen/privcmd.h conflict! +'P' 00-05 linux/tps6594_pfsm.h conflict! 'Q' all linux/soundcard.h 'R' 00-1F linux/random.h conflict! 'R' 01 linux/rfkill.h conflict! diff --git a/Documentation/userspace-api/media/frontend.h.rst.exceptions b/Documentation/userspace-api/media/frontend.h.rst.exceptions index 8b73fee11a79..dcaf5740de7e 100644 --- a/Documentation/userspace-api/media/frontend.h.rst.exceptions +++ b/Documentation/userspace-api/media/frontend.h.rst.exceptions @@ -142,6 +142,10 @@ ignore symbol FEC_26_45 ignore symbol FEC_28_45 ignore symbol FEC_32_45 ignore symbol FEC_77_90 +ignore symbol FEC_11_45 +ignore symbol FEC_4_15 +ignore symbol FEC_14_45 +ignore symbol FEC_7_15 ignore symbol TRANSMISSION_MODE_AUTO ignore symbol TRANSMISSION_MODE_1K diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst index 9cd18c153d19..72aef1759b60 100644 --- a/Documentation/userspace-api/media/v4l/biblio.rst +++ b/Documentation/userspace-api/media/v4l/biblio.rst @@ -427,3 +427,12 @@ VP9 :title: VP9 Bitstream & Decoding Process Specification :author: Adrian Grange (Google), Peter de Rivaz (Argon Design), Jonathan Hunt (Argon Design) + +.. _av1: + +AV1 +=== + +:title: AV1 Bitstream & Decoding Process Specification + +:author: Peter de Rivaz, Argon Design Ltd, Jack Haughton, Argon Design Ltd diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst index 675bc2c3c6b8..ef8e8cf31f90 100644 --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst @@ -277,7 +277,7 @@ Initialization other fields follow standard semantics. - * **Return fields:** + * **Returned fields:** ``sizeimage`` adjusted size of ``OUTPUT`` buffers. @@ -311,7 +311,7 @@ Initialization ``memory`` follows standard semantics. - * **Return fields:** + * **Returned fields:** ``count`` the actual number of buffers allocated. @@ -339,7 +339,7 @@ Initialization ``format`` follows standard semantics. - * **Return fields:** + * **Returned fields:** ``count`` adjusted to the number of allocated buffers. @@ -410,7 +410,7 @@ Capture Setup ``type`` a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``. - * **Return fields:** + * **Returned fields:** ``width``, ``height`` frame buffer resolution for the decoded frames. @@ -443,7 +443,7 @@ Capture Setup ``target`` set to ``V4L2_SEL_TGT_COMPOSE``. - * **Return fields:** + * **Returned fields:** ``r.left``, ``r.top``, ``r.width``, ``r.height`` the visible rectangle; it must fit within the frame buffer resolution @@ -552,7 +552,7 @@ Capture Setup frame is written; defaults to ``V4L2_SEL_TGT_COMPOSE_DEFAULT``; read-only on hardware without additional compose/scaling capabilities. - * **Return fields:** + * **Returned fields:** ``r.left``, ``r.top``, ``r.width``, ``r.height`` the visible rectangle; it must fit within the frame buffer resolution @@ -629,7 +629,7 @@ Capture Setup ``memory`` follows standard semantics. - * **Return fields:** + * **Returned fields:** ``count`` actual number of buffers allocated. @@ -668,7 +668,7 @@ Capture Setup a format representing the maximum framebuffer resolution to be accommodated by newly allocated buffers. - * **Return fields:** + * **Returned fields:** ``count`` adjusted to the number of allocated buffers. diff --git a/Documentation/userspace-api/media/v4l/dev-encoder.rst b/Documentation/userspace-api/media/v4l/dev-encoder.rst index aa338b9624b0..6c523c69bdce 100644 --- a/Documentation/userspace-api/media/v4l/dev-encoder.rst +++ b/Documentation/userspace-api/media/v4l/dev-encoder.rst @@ -115,8 +115,8 @@ Querying Capabilities 4. The client may use :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` to detect supported frame intervals for a given format and resolution, passing the desired pixel - format in :c:type:`v4l2_frmsizeenum` ``pixel_format`` and the resolution - in :c:type:`v4l2_frmsizeenum` ``width`` and :c:type:`v4l2_frmsizeenum` + format in :c:type:`v4l2_frmivalenum` ``pixel_format`` and the resolution + in :c:type:`v4l2_frmivalenum` ``width`` and :c:type:`v4l2_frmivalenum` ``height``. * Values returned by :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` for a coded pixel @@ -163,7 +163,7 @@ Initialization other fields follow standard semantics. - * **Return fields:** + * **Returned fields:** ``sizeimage`` adjusted size of ``CAPTURE`` buffers. @@ -189,7 +189,7 @@ Initialization other fields follow standard semantics. - * **Return fields:** + * **Returned fields:** ``pixelformat`` raw format supported for the coded format currently selected on @@ -215,7 +215,7 @@ Initialization other fields follow standard semantics. - * **Return fields:** + * **Returned fields:** ``width``, ``height`` may be adjusted to match encoder minimums, maximums and alignment @@ -233,7 +233,7 @@ Initialization :c:func:`VIDIOC_S_PARM`. This also sets the coded frame interval on the ``CAPTURE`` queue to the same value. - * ** Required fields:** + * **Required fields:** ``type`` a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``. @@ -245,7 +245,7 @@ Initialization the desired frame interval; the encoder may adjust it to match hardware requirements. - * **Return fields:** + * **Returned fields:** ``parm.output.timeperframe`` the adjusted frame interval. @@ -284,7 +284,7 @@ Initialization the case for off-line encoding. Support for this feature is signalled by the :ref:`V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL <fmtdesc-flags>` format flag. - * ** Required fields:** + * **Required fields:** ``type`` a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``. @@ -296,7 +296,7 @@ Initialization the desired coded frame interval; the encoder may adjust it to match hardware requirements. - * **Return fields:** + * **Returned fields:** ``parm.capture.timeperframe`` the adjusted frame interval. @@ -339,7 +339,7 @@ Initialization rectangle and may be subject to adjustment to match codec and hardware constraints. - * **Return fields:** + * **Returned fields:** ``r.left``, ``r.top``, ``r.width``, ``r.height`` visible rectangle adjusted by the encoder. @@ -387,7 +387,7 @@ Initialization other fields follow standard semantics. - * **Return fields:** + * **Returned fields:** ``count`` actual number of buffers allocated. @@ -420,7 +420,7 @@ Initialization other fields follow standard semantics. - * **Return fields:** + * **Returned fields:** ``count`` adjusted to the number of allocated buffers. diff --git a/Documentation/userspace-api/media/v4l/dev-stateless-decoder.rst b/Documentation/userspace-api/media/v4l/dev-stateless-decoder.rst index 4a26646eeec5..35ed05f2695e 100644 --- a/Documentation/userspace-api/media/v4l/dev-stateless-decoder.rst +++ b/Documentation/userspace-api/media/v4l/dev-stateless-decoder.rst @@ -180,7 +180,7 @@ Initialization ``memory`` follows standard semantics. - * **Return fields:** + * **Returned fields:** ``count`` actual number of buffers allocated. @@ -208,7 +208,7 @@ Initialization follows standard semantics. ``V4L2_MEMORY_USERPTR`` is not supported for ``CAPTURE`` buffers. - * **Return fields:** + * **Returned fields:** ``count`` adjusted to allocated number of buffers, in case the codec requires diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-camera.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-camera.rst index daa4f40869f8..cdc515c60468 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-camera.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-camera.rst @@ -506,6 +506,8 @@ enum v4l2_scene_mode - value down. A value of zero stops the motion if one is in progress and has no effect otherwise. +.. _v4l2-camera-sensor-orientation: + ``V4L2_CID_CAMERA_ORIENTATION (menu)`` This read-only control describes the camera orientation by reporting its mounting position on the device where the camera is installed. The control @@ -536,6 +538,7 @@ enum v4l2_scene_mode - - The camera is not directly attached to the device and is freely movable. +.. _v4l2-camera-sensor-rotation: ``V4L2_CID_CAMERA_SENSOR_ROTATION (integer)`` This read-only control describes the rotation correction in degrees in the diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst index 3d8411acd5b8..786127b1e206 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst @@ -1890,11 +1890,11 @@ params syntax' of the :ref:`vp9` specification for more details. * - __u8 - ``tree_probs[7]`` - Specifies the probability values to be used when decoding a Segment-ID. - See '5.15. Segmentation map' section of :ref:`vp9` for more details. + See '5.15 Segmentation map' section of :ref:`vp9` for more details. * - __u8 - ``pred_probs[3]`` - Specifies the probability values to be used when decoding a - Predicted-Segment-ID. See '6.4.14. Get segment id syntax' + Predicted-Segment-ID. See '6.4.14 Get segment id syntax' section of :ref:`vp9` for more details. * - __u8 - ``flags`` @@ -2923,6 +2923,13 @@ This structure contains all loop filter related parameters. See sections - ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - PocLtCurr as described in section 8.3.2 "Decoding process for reference picture set": provides the index of the long term references in DPB array. + * - __u8 + - ``num_delta_pocs_of_ref_rps_idx`` + - When the short_term_ref_pic_set_sps_flag in the slice header is equal to 0, + it is the same as the derived value NumDeltaPocs[RefRpsIdx]. It can be used to parse + the RPS data in slice headers instead of skipping it with @short_term_ref_pic_set_size. + When the value of short_term_ref_pic_set_sps_flag in the slice header is + equal to 1, num_delta_pocs_of_ref_rps_idx shall be set to 0. * - struct :c:type:`v4l2_hevc_dpb_entry` - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - The decoded picture buffer, for meta-data about reference frames. @@ -2950,3 +2957,1208 @@ This structure contains all loop filter related parameters. See sections * - ``V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR`` - 0x00000004 - + +.. _v4l2-codec-stateless-av1: + +``V4L2_CID_STATELESS_AV1_SEQUENCE (struct)`` + Represents an AV1 Sequence OBU (Open Bitstream Unit). See section 5.5 + "Sequence header OBU syntax" in :ref:`av1` for more details. + +.. c:type:: v4l2_ctrl_av1_sequence + +.. cssclass:: longtable + +.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}| + +.. flat-table:: struct v4l2_ctrl_av1_sequence + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u32 + - ``flags`` + - See :ref:`AV1 Sequence Flags <av1_sequence_flags>`. + * - __u8 + - ``seq_profile`` + - Specifies the features that can be used in the coded video sequence. + * - __u8 + - ``order_hint_bits`` + - Specifies the number of bits used for the order_hint field at each frame. + * - __u8 + - ``bit_depth`` + - the bit depth to use for the sequence as described in section 5.5.2 + "Color config syntax" in :ref:`av1` for more details. + * - __u8 + - ``reserved`` + - Applications and drivers must set this to zero. + * - __u16 + - ``max_frame_width_minus_1`` + - specifies the maximum frame width minus 1 for the frames represented by + this sequence header. + +.. _av1_sequence_flags: + +``AV1 Sequence Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_SEQUENCE_FLAG_STILL_PICTURE`` + - 0x00000001 + - If set, specifies that the coded video sequence contains only one coded + frame. If not set, specifies that the coded video sequence contains one + or more coded frames. + * - ``V4L2_AV1_SEQUENCE_FLAG_USE_128X128_SUPERBLOCK`` + - 0x00000002 + - If set, indicates that superblocks contain 128x128 luma samples. + When equal to 0, it indicates that superblocks contain 64x64 luma + samples. The number of contained chroma samples depends on + subsampling_x and subsampling_y. + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_FILTER_INTRA`` + - 0x00000004 + - If set, specifies that the use_filter_intra syntax element may be + present. If not set, specifies that the use_filter_intra syntax element + will not be present. + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_INTRA_EDGE_FILTER`` + - 0x00000008 + - Specifies whether the intra edge filtering process should be enabled. + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_INTERINTRA_COMPOUND`` + - 0x00000010 + - If set, specifies that the mode info for inter blocks may contain the + syntax element interintra. If not set, specifies that the syntax element + interintra will not be present. + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_MASKED_COMPOUND`` + - 0x00000020 + - If set, specifies that the mode info for inter blocks may contain the + syntax element compound_type. If not set, specifies that the syntax + element compound_type will not be present. + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_WARPED_MOTION`` + - 0x00000040 + - If set, indicates that the allow_warped_motion syntax element may be + present. If not set, indicates that the allow_warped_motion syntax + element will not be present. + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_DUAL_FILTER`` + - 0x00000080 + - If set, indicates that the inter prediction filter type may be specified + independently in the horizontal and vertical directions. If the flag is + equal to 0, only one filter type may be specified, which is then used in + both directions. + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_ORDER_HINT`` + - 0x00000100 + - If set, indicates that tools based on the values of order hints may be + used. If not set, indicates that tools based on order hints are + disabled. + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_JNT_COMP`` + - 0x00000200 + - If set, indicates that the distance weights process may be used for + inter prediction. + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_REF_FRAME_MVS`` + - 0x00000400 + - If set, indicates that the use_ref_frame_mvs syntax element may be + present. If not set, indicates that the use_ref_frame_mvs syntax element + will not be present. + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_SUPERRES`` + - 0x00000800 + - If set, specifies that the use_superres syntax element will be present + in the uncompressed header. If not set, specifies that the use_superres + syntax element will not be present (instead use_superres will be set to + 0 in the uncompressed header without being read). + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_CDEF`` + - 0x00001000 + - If set, specifies that cdef filtering may be enabled. If not set, + specifies that cdef filtering is disabled. + * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_RESTORATION`` + - 0x00002000 + - If set, specifies that loop restoration filtering may be enabled. If not + set, specifies that loop restoration filtering is disabled. + * - ``V4L2_AV1_SEQUENCE_FLAG_MONO_CHROME`` + - 0x00004000 + - If set, indicates that the video does not contain U and V color planes. + If not set, indicates that the video contains Y, U, and V color planes. + * - ``V4L2_AV1_SEQUENCE_FLAG_COLOR_RANGE`` + - 0x00008000 + - If set, signals full swing representation, i.e. "Full Range + Quantization". If not set, signals studio swing representation, i.e. + "Limited Range Quantization". + * - ``V4L2_AV1_SEQUENCE_FLAG_SUBSAMPLING_X`` + - 0x00010000 + - Specify the chroma subsampling format. + * - ``V4L2_AV1_SEQUENCE_FLAG_SUBSAMPLING_Y`` + - 0x00020000 + - Specify the chroma subsampling format. + * - ``V4L2_AV1_SEQUENCE_FLAG_FILM_GRAIN_PARAMS_PRESENT`` + - 0x00040000 + - Specifies whether film grain parameters are present in the coded video + sequence. + * - ``V4L2_AV1_SEQUENCE_FLAG_SEPARATE_UV_DELTA_Q`` + - 0x00080000 + - If set, indicates that the U and V planes may have separate delta + quantizer values. If not set, indicates that the U and V planes will share + the same delta quantizer value. + +``V4L2_CID_STATELESS_AV1_TILE_GROUP_ENTRY (struct)`` + Represents a single AV1 tile inside an AV1 Tile Group. Note that MiRowStart, + MiRowEnd, MiColStart and MiColEnd can be retrieved from struct + v4l2_av1_tile_info in struct v4l2_ctrl_av1_frame using tile_row and + tile_col. See section 6.10.1 "General tile group OBU semantics" in + :ref:`av1` for more details. + +.. c:type:: v4l2_ctrl_av1_tile_group_entry + +.. cssclass:: longtable + +.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}| + +.. flat-table:: struct v4l2_ctrl_av1_tile_group_entry + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u32 + - ``tile_offset`` + - Offset from the OBU data, i.e. where the coded tile data actually starts. + * - __u32 + - ``tile_size`` + - Specifies the size in bytes of the coded tile. Equivalent to "TileSize" + in :ref:`av1`. + * - __u32 + - ``tile_row`` + - Specifies the row of the current tile. Equivalent to "TileRow" in + :ref:`av1`. + * - __u32 + - ``tile_col`` + - Specifies the column of the current tile. Equivalent to "TileColumn" in + :ref:`av1`. + +.. c:type:: v4l2_av1_warp_model + + AV1 Warp Model as described in section 3 "Symbols and abbreviated terms" of + :ref:`av1`. + +.. raw:: latex + + \scriptsize + +.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_WARP_MODEL_IDENTITY`` + - 0 + - Warp model is just an identity transform. + * - ``V4L2_AV1_WARP_MODEL_TRANSLATION`` + - 1 + - Warp model is a pure translation. + * - ``V4L2_AV1_WARP_MODEL_ROTZOOM`` + - 2 + - Warp model is a rotation + symmetric zoom + translation. + * - ``V4L2_AV1_WARP_MODEL_AFFINE`` + - 3 + - Warp model is a general affine transform. + +.. c:type:: v4l2_av1_reference_frame + +AV1 Reference Frames as described in section 6.10.24 "Ref frames semantics" +of :ref:`av1`. + +.. raw:: latex + + \scriptsize + +.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_REF_INTRA_FRAME`` + - 0 + - Intra Frame Reference. + * - ``V4L2_AV1_REF_LAST_FRAME`` + - 1 + - Last Frame Reference. + * - ``V4L2_AV1_REF_LAST2_FRAME`` + - 2 + - Last2 Frame Reference. + * - ``V4L2_AV1_REF_LAST3_FRAME`` + - 3 + - Last3 Frame Reference. + * - ``V4L2_AV1_REF_GOLDEN_FRAME`` + - 4 + - Golden Frame Reference. + * - ``V4L2_AV1_REF_BWDREF_FRAME`` + - 5 + - BWD Frame Reference. + * - ``V4L2_AV1_REF_ALTREF2_FRAME`` + - 6 + - ALTREF2 Frame Reference. + * - ``V4L2_AV1_REF_ALTREF_FRAME`` + - 7 + - ALTREF Frame Reference. + +.. c:type:: v4l2_av1_global_motion + +AV1 Global Motion parameters as described in section 6.8.17 +"Global motion params semantics" of :ref:`av1`. + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}| + +.. flat-table:: struct v4l2_av1_global_motion + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``flags[V4L2_AV1_TOTAL_REFS_PER_FRAME]`` + - A bitfield containing the flags per reference frame. See + :ref:`AV1 Global Motion Flags <av1_global_motion_flags>` for more + details. + * - enum :c:type:`v4l2_av1_warp_model` + - ``type[V4L2_AV1_TOTAL_REFS_PER_FRAME]`` + - The type of global motion transform used. + * - __s32 + - ``params[V4L2_AV1_TOTAL_REFS_PER_FRAME][6]`` + - This field has the same meaning as "gm_params" in :ref:`av1`. + * - __u8 + - ``invalid`` + - Bitfield indicating whether the global motion params are invalid for a + given reference frame. See section 7.11.3.6 Setup shear process and the + variable "warpValid". Use V4L2_AV1_GLOBAL_MOTION_IS_INVALID(ref) to + create a suitable mask. + * - __u8 + - ``reserved[3]`` + - Applications and drivers must set this to zero. + +.. _av1_global_motion_flags: + +``AV1 Global Motion Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_GLOBAL_MOTION_FLAG_IS_GLOBAL`` + - 0x00000001 + - Specifies whether global motion parameters are present for a particular + reference frame. + * - ``V4L2_AV1_GLOBAL_MOTION_FLAG_IS_ROT_ZOOM`` + - 0x00000002 + - Specifies whether a particular reference frame uses rotation and zoom + global motion. + * - ``V4L2_AV1_GLOBAL_MOTION_FLAG_IS_TRANSLATION`` + - 0x00000004 + - Specifies whether a particular reference frame uses translation global + motion + +.. c:type:: v4l2_av1_frame_restoration_type + +AV1 Frame Restoration Type. + +.. raw:: latex + + \scriptsize + +.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_FRAME_RESTORE_NONE`` + - 0 + - No filtering is applied. + * - ``V4L2_AV1_FRAME_RESTORE_WIENER`` + - 1 + - Wiener filter process is invoked. + * - ``V4L2_AV1_FRAME_RESTORE_SGRPROJ`` + - 2 + - Self guided filter process is invoked. + * - ``V4L2_AV1_FRAME_RESTORE_SWITCHABLE`` + - 3 + - Restoration filter is swichtable. + +.. c:type:: v4l2_av1_loop_restoration + +AV1 Loop Restoration as described in section 6.10.15 "Loop restoration params +semantics" of :ref:`av1`. + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}| + +.. flat-table:: struct v4l2_av1_loop_restoration + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``flags`` + - See :ref:`AV1 Loop Restoration Flags <av1_loop_restoration_flags>`. + * - __u8 + - ``lr_unit_shift`` + - Specifies if the luma restoration size should be halved. + * - __u8 + - ``lr_uv_shift`` + - Specifies if the chroma size should be half the luma size. + * - __u8 + - ``reserved`` + - Applications and drivers must set this to zero. + * - :c:type:`v4l2_av1_frame_restoration_type` + - ``frame_restoration_type[V4L2_AV1_NUM_PLANES_MAX]`` + - Specifies the type of restoration used for each plane. + * - __u8 + - ``loop_restoration_size[V4L2_AV1_MAX_NUM_PLANES]`` + - Specifies the size of loop restoration units in units of samples in the + current plane. + +.. _av1_loop_restoration_flags: + +``AV1 Loop Restoration Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_LOOP_RESTORATION_FLAG_USES_LR`` + - 0x00000001 + - Retains the same meaning as UsesLr in :ref:`av1`. + * - ``V4L2_AV1_LOOP_RESTORATION_FLAG_USES_CHROMA_LR`` + - 0x00000002 + - Retains the same meaning as UsesChromaLr in :ref:`av1`. + +.. c:type:: v4l2_av1_cdef + +AV1 CDEF params semantics as described in section 6.10.14 "CDEF params +semantics" of :ref:`av1`. + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}| + +.. flat-table:: struct v4l2_av1_cdef + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``damping_minus_3`` + - Controls the amount of damping in the deringing filter. + * - __u8 + - ``bits`` + - Specifies the number of bits needed to specify which CDEF filter to + apply. + * - __u8 + - ``y_pri_strength[V4L2_AV1_CDEF_MAX]`` + - Specifies the strength of the primary filter. + * - __u8 + - ``y_sec_strength[V4L2_AV1_CDEF_MAX]`` + - Specifies the strength of the secondary filter. + * - __u8 + - ``uv_pri_strength[V4L2_AV1_CDEF_MAX]`` + - Specifies the strength of the primary filter. + * - __u8 + - ``uv_secondary_strength[V4L2_AV1_CDEF_MAX]`` + - Specifies the strength of the secondary filter. + +.. c:type:: v4l2_av1_segment_feature + +AV1 segment features as described in section 3 "Symbols and abbreviated terms" +of :ref:`av1`. + +.. raw:: latex + + \scriptsize + +.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_SEG_LVL_ALT_Q`` + - 0 + - Index for quantizer segment feature. + * - ``V4L2_AV1_SEG_LVL_ALT_LF_Y_V`` + - 1 + - Index for vertical luma loop filter segment feature. + * - ``V4L2_AV1_SEG_LVL_REF_FRAME`` + - 5 + - Index for reference frame segment feature. + * - ``V4L2_AV1_SEG_LVL_REF_SKIP`` + - 6 + - Index for skip segment feature. + * - ``V4L2_AV1_SEG_LVL_REF_GLOBALMV`` + - 7 + - Index for global mv feature. + * - ``V4L2_AV1_SEG_LVL_MAX`` + - 8 + - Number of segment features. + +.. c:type:: v4l2_av1_segmentation + +AV1 Segmentation params as defined in section 6.8.13 "Segmentation params +semantics" of :ref:`av1`. + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}| + +.. flat-table:: struct v4l2_av1_segmentation + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``flags`` + - See :ref:`AV1 Segmentation Flags <av1_segmentation_flags>` + * - __u8 + - ``last_active_seg_id`` + - Indicates the highest numbered segment id that has some + enabled feature. This is used when decoding the segment id to only decode + choices corresponding to used segments. + * - __u8 + - ``feature_enabled[V4L2_AV1_MAX_SEGMENTS]`` + - Bitmask defining which features are enabled in each segment. Use + V4L2_AV1_SEGMENT_FEATURE_ENABLED to build a suitable mask. + * - __u16 + - `feature_data[V4L2_AV1_MAX_SEGMENTS][V4L2_AV1_SEG_LVL_MAX]`` + - Data attached to each feature. Data entry is only valid if the feature + is enabled. + +.. _av1_segmentation_flags: + +``AV1 Segmentation Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_SEGMENTATION_FLAG_ENABLED`` + - 0x00000001 + - If set, indicates that this frame makes use of the segmentation tool. If + not set, indicates that the frame does not use segmentation. + * - ``V4L2_AV1_SEGMENTATION_FLAG_UPDATE_MAP`` + - 0x00000002 + - If set, indicates that the segmentation map are updated during the + decoding of this frame. If not set, indicates that the segmentation map + from the previous frame is used. + * - ``V4L2_AV1_SEGMENTATION_FLAG_TEMPORAL_UPDATE`` + - 0x00000004 + - If set, indicates that the updates to the segmentation map are coded + relative to the existing segmentation map. If not set, indicates that + the new segmentation map is coded without reference to the existing + segmentation map. + * - ``V4L2_AV1_SEGMENTATION_FLAG_UPDATE_DATA`` + - 0x00000008 + - If set, indicates that the updates to the segmentation map are coded + relative to the existing segmentation map. If not set, indicates that + the new segmentation map is coded without reference to the existing + segmentation map. + * - ``V4L2_AV1_SEGMENTATION_FLAG_SEG_ID_PRE_SKIP`` + - 0x00000010 + - If set, indicates that the segment id will be read before the skip + syntax element. If not set, indicates that the skip syntax element will + be read first. + +.. c:type:: v4l2_av1_loop_filter + +AV1 Loop filter params as defined in section 6.8.10 "Loop filter semantics" of +:ref:`av1`. + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}| + +.. flat-table:: struct v4l2_av1_global_motion + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``flags`` + - See + :ref:`AV1 Loop Filter flags <av1_loop_filter_flags>` for more details. + * - __u8 + - ``level[4]`` + - An array containing loop filter strength values. Different loop + filter strength values from the array are used depending on the image + plane being filtered, and the edge direction (vertical or horizontal) + being filtered. + * - __u8 + - ``sharpness`` + - indicates the sharpness level. The loop_filter_level and + loop_filter_sharpness together determine when a block edge is filtered, + and by how much the filtering can change the sample values. The loop + filter process is described in section 7.14 of :ref:`av1`. + * - __u8 + - ``ref_deltas[V4L2_AV1_TOTAL_REFS_PER_FRAME]`` + - contains the adjustment needed for the filter level based on the + chosen reference frame. If this syntax element is not present, it + maintains its previous value. + * - __u8 + - ``mode_deltas[2]`` + - contains the adjustment needed for the filter level based on + the chosen mode. If this syntax element is not present, it maintains its + previous value. + * - __u8 + - ``delta_lf_res`` + - specifies the left shift which should be applied to decoded loop filter + delta values. + +.. _av1_loop_filter_flags: + +``AV1 Loop Filter Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_LOOP_FILTER_FLAG_DELTA_ENABLED`` + - 0x00000001 + - If set, means that the filter level depends on the mode and reference + frame used to predict a block. If not set, means that the filter level + does not depend on the mode and reference frame. + * - ``V4L2_AV1_LOOP_FILTER_FLAG_DELTA_UPDATE`` + - 0x00000002 + - If set, means that additional syntax elements are present that specify + which mode and reference frame deltas are to be updated. If not set, + means that these syntax elements are not present. + * - ``V4L2_AV1_LOOP_FILTER_FLAG_DELTA_LF_PRESENT`` + - 0x00000004 + - Specifies whether loop filter delta values are present + * - ``V4L2_AV1_LOOP_FILTER_FLAG_DELTA_LF_MULTI`` + - 0x00000008 + - A value equal to 1 specifies that separate loop filter + deltas are sent for horizontal luma edges, vertical luma edges, + the U edges, and the V edges. A value of delta_lf_multi equal to 0 + specifies that the same loop filter delta is used for all edges. + +.. c:type:: v4l2_av1_quantization + +AV1 Quantization params as defined in section 6.8.11 "Quantization params +semantics" of :ref:`av1`. + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}| + +.. flat-table:: struct v4l2_av1_quantization + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``flags`` + - See + :ref:`AV1 Loop Filter flags <av1_quantization_flags>` for more details. + * - __u8 + - ``base_q_idx`` + - Indicates the base frame qindex. This is used for Y AC coefficients and + as the base value for the other quantizers. + * - __u8 + - ``delta_q_y_dc`` + - Indicates the Y DC quantizer relative to base_q_idx. + * - __u8 + - ``delta_q_u_dc`` + - Indicates the U DC quantizer relative to base_q_idx. + * - __u8 + - ``delta_q_u_ac`` + - Indicates the U AC quantizer relative to base_q_idx. + * - __u8 + - ``delta_q_v_dc`` + - Indicates the V DC quantizer relative to base_q_idx. + * - __u8 + - ``delta_q_v_ac`` + - Indicates the V AC quantizer relative to base_q_idx. + * - __u8 + - ``qm_y`` + - Specifies the level in the quantizer matrix that should be used for + luma plane decoding. + * - __u8 + - ``qm_u`` + - Specifies the level in the quantizer matrix that should be used for + chroma U plane decoding. + * - __u8 + - ``qm_v`` + - Specifies the level in the quantizer matrix that should be used for + chroma V plane decoding. + * - __u8 + - ``delta_q_res`` + - Specifies the left shift which should be applied to decoded quantizer + index delta values. + +.. _av1_quantization_flags: + +``AV1 Quantization Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_QUANTIZATION_FLAG_DIFF_UV_DELTA`` + - 0x00000001 + - If set, indicates that the U and V delta quantizer values are coded + separately. If not set, indicates that the U and V delta quantizer + values share a common value. + * - ``V4L2_AV1_QUANTIZATION_FLAG_USING_QMATRIX`` + - 0x00000002 + - If set, specifies that the quantizer matrix will be used to compute + quantizers. + * - ``V4L2_AV1_QUANTIZATION_FLAG_DELTA_Q_PRESENT`` + - 0x00000004 + - Specifies whether quantizer index delta values are present. + +.. c:type:: v4l2_av1_tile_info + +AV1 Tile info as defined in section 6.8.14 "Tile info semantics" of ref:`av1`. + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}| + +.. flat-table:: struct v4l2_av1_tile_info + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``flags`` + - See + :ref:`AV1 Tile Info flags <av1_tile_info_flags>` for more details. + * - __u8 + - ``context_update_tile_id`` + - Specifies which tile to use for the CDF update. + * - __u8 + - ``tile_cols`` + - Specifies the number of tiles across the frame. + * - __u8 + - ``tile_rows`` + - Specifies the number of tiles down the frame. + * - __u32 + - ``mi_col_starts[V4L2_AV1_MAX_TILE_COLS + 1]`` + - An array specifying the start column (in units of 4x4 luma + samples) for each tile across the image. + * - __u32 + - ``mi_row_starts[V4L2_AV1_MAX_TILE_ROWS + 1]`` + - An array specifying the start row (in units of 4x4 luma + samples) for each tile across the image. + * - __u32 + - ``width_in_sbs_minus_1[V4L2_AV1_MAX_TILE_COLS]`` + - Specifies the width of a tile minus 1 in units of superblocks. + * - __u32 + - ``height_in_sbs_minus_1[V4L2_AV1_MAX_TILE_ROWS]`` + - Specifies the height of a tile minus 1 in units of superblocks. + * - __u8 + - ``tile_size_bytes`` + - Specifies the number of bytes needed to code each tile size. + * - __u8 + - ``reserved[3]`` + - Applications and drivers must set this to zero. + +.. _av1_tile_info_flags: + +``AV1 Tile Info Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_TILE_INFO_FLAG_UNIFORM_TILE_SPACING`` + - 0x00000001 + - If set, means that the tiles are uniformly spaced across the frame. (In + other words, all tiles are the same size except for the ones at the + right and bottom edge which can be smaller). If not set means that the + tile sizes are coded. + +.. c:type:: v4l2_av1_frame_type + +AV1 Frame Type + +.. raw:: latex + + \scriptsize + +.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_KEY_FRAME`` + - 0 + - Key frame. + * - ``V4L2_AV1_INTER_FRAME`` + - 1 + - Inter frame. + * - ``V4L2_AV1_INTRA_ONLY_FRAME`` + - 2 + - Intra-only frame. + * - ``V4L2_AV1_SWITCH_FRAME`` + - 3 + - Switch frame. + +.. c:type:: v4l2_av1_interpolation_filter + +AV1 Interpolation Filter + +.. raw:: latex + + \scriptsize + +.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_INTERPOLATION_FILTER_EIGHTTAP`` + - 0 + - Eight tap filter. + * - ``V4L2_AV1_INTERPOLATION_FILTER_EIGHTTAP_SMOOTH`` + - 1 + - Eight tap smooth filter. + * - ``V4L2_AV1_INTERPOLATION_FILTER_EIGHTTAP_SHARP`` + - 2 + - Eight tap sharp filter. + * - ``V4L2_AV1_INTERPOLATION_FILTER_BILINEAR`` + - 3 + - Bilinear filter. + * - ``V4L2_AV1_INTERPOLATION_FILTER_SWITCHABLE`` + - 4 + - Filter selection is signaled at the block level. + +.. c:type:: v4l2_av1_tx_mode + +AV1 Tx mode as described in section 6.8.21 "TX mode semantics" of :ref:`av1`. + +.. raw:: latex + + \scriptsize + +.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_TX_MODE_ONLY_4X4`` + - 0 + - The inverse transform will use only 4x4 transforms. + * - ``V4L2_AV1_TX_MODE_LARGEST`` + - 1 + - The inverse transform will use the largest transform size that fits + inside the block. + * - ``V4L2_AV1_TX_MODE_SELECT`` + - 2 + - The choice of transform size is specified explicitly for each block. + +``V4L2_CID_STATELESS_AV1_FRAME (struct)`` + Represents a Frame Header OBU. See 6.8 "Frame Header OBU semantics" of + :ref:`av1` for more details. + +.. c:type:: v4l2_ctrl_av1_frame + +.. cssclass:: longtable + +.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}| + +.. flat-table:: struct v4l2_ctrl_av1_frame + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - struct :c:type:`v4l2_av1_tile_info` + - ``tile_info`` + - Tile info + * - struct :c:type:`v4l2_av1_quantization` + - ``quantization`` + - Quantization parameters. + * - struct :c:type:`v4l2_av1_segmentation` + - ``segmentation`` + - Segmentation parameters. + * - __u8 + - ``superres_denom`` + - The denominator for the upscaling ratio. + * - struct :c:type:`v4l2_av1_loop_filter` + - ``loop_filter`` + - Loop filter params + * - struct :c:type:`v4l2_av1_cdef` + - ``cdef`` + - CDEF params + * - __u8 + - ``skip_mode_frame[2]`` + - Specifies the frames to use for compound prediction when skip_mode is + equal to 1. + * - __u8 + - ``primary_ref_frame`` + - Specifies which reference frame contains the CDF values and other state + that should be loaded at the start of the frame. + * - struct :c:type:`v4l2_av1_loop_restoration` + - ``loop_restoration`` + - Loop restoration parameters. + * - struct :c:type:`v4l2_av1_loop_global_motion` + - ``global_motion`` + - Global motion parameters. + * - __u32 + - ``flags`` + - See + :ref:`AV1 Frame flags <av1_frame_flags>` for more details. + * - enum :c:type:`v4l2_av1_frame_type` + - ``frame_type`` + - Specifies the AV1 frame type + * - __u32 + - ``order_hint`` + - Specifies OrderHintBits least significant bits of the expected output + order for this frame. + * - __u32 + - ``upscaled_width`` + - The upscaled width. + * - enum :c:type:`v4l2_av1_interpolation_filter` + - ``interpolation_filter`` + - Specifies the filter selection used for performing inter prediction. + * - enum :c:type:`v4l2_av1_tx_mode` + - ``tx_mode`` + - Specifies how the transform size is determined. + * - __u32 + - ``frame_width_minus_1`` + - Add 1 to get the frame's width. + * - __u32 + - ``frame_height_minus_1`` + - Add 1 to get the frame's height. + * - __u16 + - ``render_width_minus_1`` + - Add 1 to get the render width of the frame in luma samples. + * - __u16 + - ``render_height_minus_1`` + - Add 1 to get the render height of the frame in luma samples. + * - __u32 + - ``current_frame_id`` + - Specifies the frame id number for the current frame. Frame + id numbers are additional information that do not affect the decoding + process, but provide decoders with a way of detecting missing reference + frames so that appropriate action can be taken. + * - __u8 + - ``buffer_removal_time[V4L2_AV1_MAX_OPERATING_POINTS]`` + - Specifies the frame removal time in units of DecCT clock ticks counted + from the removal time of the last random access point for operating point + opNum. + * - __u8 + - ``reserved[4]`` + - Applications and drivers must set this to zero. + * - __u32 + - ``order_hints[V4L2_AV1_TOTAL_REFS_PER_FRAME]`` + - Specifies the expected output order hint for each reference frame. + This field corresponds to the OrderHints variable from the specification + (section 5.9.2 "Uncompressed header syntax"). As such, this is only + used for non-intra frames and ignored otherwise. order_hints[0] is + always ignored. + * - __u64 + - ``reference_frame_ts[V4L2_AV1_TOTAL_REFS_PER_FRAME]`` + - The V4L2 timestamp for each of the reference frames enumerated in + enum :c:type:`v4l2_av1_reference_frame` starting at + ``V4L2_AV1_REF_LAST_FRAME``. This represents the state of reference + slot as described in the spec and updated by userland through the + "Reference frame update process" in section 7.20 The timestamp refers + to the ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the + :c:func:`v4l2_timeval_to_ns()` function to convert the struct + :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. + * - __s8 + - ``ref_frame_idx[V4L2_AV1_REFS_PER_FRAME]`` + - An index into ``reference_frame_ts`` representing the ordered list of + references used by inter-frame. Matches the bitstream syntax + element of the same name. + * - __u8 + - ``refresh_frame_flags`` + - Contains a bitmask that specifies which reference frame slots will be + updated with the current frame after it is decoded. + +.. _av1_frame_flags: + +``AV1 Frame Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_FRAME_FLAG_SHOW_FRAME`` + - 0x00000001 + - If set, specifies that this frame should be immediately output once + decoded. If not set, specifies that this frame should not be immediately + output; it may be output later if a later uncompressed header uses + show_existing_frame equal to 1. + * - ``V4L2_AV1_FRAME_FLAG_SHOWABLE_FRAME`` + - 0x00000002 + - If set, specifies that the frame may be output using the + show_existing_frame mechanism. If not set, specifies that this frame + will not be output using the show_existing_frame mechanism. + * - ``V4L2_AV1_FRAME_FLAG_ERROR_RESILIENT_MODE`` + - 0x00000004 + - Specifies whether error resilient mode is enabled. + * - ``V4L2_AV1_FRAME_FLAG_DISABLE_CDF_UPDATE`` + - 0x00000008 + - Specifies whether the CDF update in the symbol decoding process should + be disabled. + * - ``V4L2_AV1_FRAME_FLAG_ALLOW_SCREEN_CONTENT_TOOLS`` + - 0x00000010 + - If set, indicates that intra blocks may use palette encoding. If not + set, indicates that palette encoding is never used. + * - ``V4L2_AV1_FRAME_FLAG_FORCE_INTEGER_MV`` + - 0x00000020 + - If set, specifies that motion vectors will always be integers. If not + set, specifies that motion vectors can contain fractional bits. + * - ``V4L2_AV1_FRAME_FLAG_ALLOW_INTRABC`` + - 0x00000040 + - If set, indicates that intra block copy may be used in this frame. If + not set, indicates that intra block copy is not allowed in this frame. + * - ``V4L2_AV1_FRAME_FLAG_USE_SUPERRES`` + - 0x00000080 + - If set, indicates that upscaling is needed. + * - ``V4L2_AV1_FRAME_FLAG_ALLOW_HIGH_PRECISION_MV`` + - 0x00000100 + - If set, specifies that motion vectors are specified to eighth pel + precision. If not set, specifies that motion vectors are specified to + quarter pel precision; + * - ``V4L2_AV1_FRAME_FLAG_IS_MOTION_MODE_SWITCHABLE`` + - 0x00000200 + - If not set, specifies that only the SIMPLE motion mode will be used. + * - ``V4L2_AV1_FRAME_FLAG_USE_REF_FRAME_MVS`` + - 0x00000400 + - If set specifies that motion vector information from a previous frame + can be used when decoding the current frame. If not set, specifies that + this information will not be used. + * - ``V4L2_AV1_FRAME_FLAG_DISABLE_FRAME_END_UPDATE_CDF`` + - 0x00000800 + - If set indicates that the end of frame CDF update is disabled. If not + set, indicates that the end of frame CDF update is enabled + * - ``V4L2_AV1_FRAME_FLAG_ALLOW_WARPED_MOTION`` + - 0x00001000 + - If set, indicates that the syntax element motion_mode may be present, if + not set, indicates that the syntax element motion_mode will not be + present. + * - ``V4L2_AV1_FRAME_FLAG_REFERENCE_SELECT`` + - 0x00002000 + - If set, specifies that the mode info for inter blocks contains the + syntax element comp_mode that indicates whether to use single or + compound reference prediction. If not set, specifies that all inter + blocks will use single prediction. + * - ``V4L2_AV1_FRAME_FLAG_REDUCED_TX_SET`` + - 0x00004000 + - If set, specifies that the frame is restricted to a reduced subset of + the full set of transform types. + * - ``V4L2_AV1_FRAME_FLAG_SKIP_MODE_ALLOWED`` + - 0x00008000 + - This flag retains the same meaning as SkipModeAllowed in :ref:`av1`. + * - ``V4L2_AV1_FRAME_FLAG_SKIP_MODE_PRESENT`` + - 0x00010000 + - If set, specifies that the syntax element skip_mode will be present, if + not set, specifies that skip_mode will not be used for this frame. + * - ``V4L2_AV1_FRAME_FLAG_FRAME_SIZE_OVERRIDE`` + - 0x00020000 + - If set, specifies that the frame size will either be specified as the + size of one of the reference frames, or computed from the + frame_width_minus_1 and frame_height_minus_1 syntax elements. If not + set, specifies that the frame size is equal to the size in the sequence + header. + * - ``V4L2_AV1_FRAME_FLAG_BUFFER_REMOVAL_TIME_PRESENT`` + - 0x00040000 + - If set, specifies that buffer_removal_time is present. If not set, + specifies that buffer_removal_time is not present. + * - ``V4L2_AV1_FRAME_FLAG_FRAME_REFS_SHORT_SIGNALING`` + - 0x00080000 + - If set, indicates that only two reference frames are explicitly + signaled. If not set, indicates that all reference frames are explicitly + signaled. + +``V4L2_CID_STATELESS_AV1_FILM_GRAIN (struct)`` + Represents the optional film grain parameters. See section + 6.8.20 "Film grain params semantics" of :ref:`av1` for more details. + +.. c:type:: v4l2_ctrl_av1_film_grain + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}| + +.. flat-table:: struct v4l2_ctrl_av1_film_grain + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``flags`` + - See :ref:`AV1 Film Grain Flags <av1_film_grain_flags>`. + * - __u8 + - ``cr_mult`` + - Represents a multiplier for the cr component used in derivation of the + input index to the cr component scaling function. + * - __u16 + - ``grain_seed`` + - Specifies the starting value for the pseudo-random numbers used during + film grain synthesis. + * - __u8 + - ``film_grain_params_ref_idx`` + - Indicates which reference frame contains the film grain parameters to be + used for this frame. + * - __u8 + - ``num_y_points`` + - Specifies the number of points for the piece-wise linear scaling + function of the luma component. + * - __u8 + - ``point_y_value[V4L2_AV1_MAX_NUM_Y_POINTS]`` + - Represents the x (luma value) coordinate for the i-th point + of the piecewise linear scaling function for luma component. The values + are signaled on the scale of 0..255. In case of 10 bit video, these + values correspond to luma values divided by 4. In case of 12 bit video, + these values correspond to luma values divided by 16. + * - __u8 + - ``point_y_scaling[V4L2_AV1_MAX_NUM_Y_POINTS]`` + - Represents the scaling (output) value for the i-th point + of the piecewise linear scaling function for luma component. + * - __u8 + - ``num_cb_points`` + - Specifies the number of points for the piece-wise linear scaling + function of the cb component. + * - __u8 + - ``point_cb_value[V4L2_AV1_MAX_NUM_CB_POINTS]`` + - Represents the x coordinate for the i-th point of the + piece-wise linear scaling function for cb component. The values are + signaled on the scale of 0..255. + * - __u8 + - ``point_cb_scaling[V4L2_AV1_MAX_NUM_CB_POINTS]`` + - Represents the scaling (output) value for the i-th point of the + piecewise linear scaling function for cb component. + * - __u8 + - ``num_cr_points`` + - Represents the number of points for the piece-wise + linear scaling function of the cr component. + * - __u8 + - ``point_cr_value[V4L2_AV1_MAX_NUM_CR_POINTS]`` + - Represents the x coordinate for the i-th point of the + piece-wise linear scaling function for cr component. The values are + signaled on the scale of 0..255. + * - __u8 + - ``point_cr_scaling[V4L2_AV1_MAX_NUM_CR_POINTS]`` + - Represents the scaling (output) value for the i-th point of the + piecewise linear scaling function for cr component. + * - __u8 + - ``grain_scaling_minus_8`` + - Represents the shift - 8 applied to the values of the chroma component. + The grain_scaling_minus_8 can take values of 0..3 and determines the + range and quantization step of the standard deviation of film grain. + * - __u8 + - ``ar_coeff_lag`` + - Specifies the number of auto-regressive coefficients for luma and + chroma. + * - __u8 + - ``ar_coeffs_y_plus_128[V4L2_AV1_AR_COEFFS_SIZE]`` + - Specifies auto-regressive coefficients used for the Y plane. + * - __u8 + - ``ar_coeffs_cb_plus_128[V4L2_AV1_AR_COEFFS_SIZE]`` + - Specifies auto-regressive coefficients used for the U plane. + * - __u8 + - ``ar_coeffs_cr_plus_128[V4L2_AV1_AR_COEFFS_SIZE]`` + - Specifies auto-regressive coefficients used for the V plane. + * - __u8 + - ``ar_coeff_shift_minus_6`` + - Specifies the range of the auto-regressive coefficients. Values of 0, + 1, 2, and 3 correspond to the ranges for auto-regressive coefficients of + [-2, 2), [-1, 1), [-0.5, 0.5) and [-0.25, 0.25) respectively. + * - __u8 + - ``grain_scale_shift`` + - Specifies how much the Gaussian random numbers should be scaled down + during the grain synthesis process. + * - __u8 + - ``cb_mult`` + - Represents a multiplier for the cb component used in derivation of the + input index to the cb component scaling function. + * - __u8 + - ``cb_luma_mult`` + - Represents a multiplier for the average luma component used in + derivation of the input index to the cb component scaling function.. + * - __u8 + - ``cr_luma_mult`` + - Represents a multiplier for the average luma component used in + derivation of the input index to the cr component scaling function. + * - __u16 + - ``cb_offset`` + - Represents an offset used in derivation of the input index to the + cb component scaling function. + * - __u16 + - ``cr_offset`` + - Represents an offset used in derivation of the input index to the + cr component scaling function. + * - __u8 + - ``reserved[4]`` + - Applications and drivers must set this to zero. + +.. _av1_film_grain_flags: + +``AV1 Film Grain Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_AV1_FILM_GRAIN_FLAG_APPLY_GRAIN`` + - 0x00000001 + - If set, specifies that film grain should be added to this frame. If not + set, specifies that film grain should not be added. + * - ``V4L2_AV1_FILM_GRAIN_FLAG_UPDATE_GRAIN`` + - 0x00000002 + - If set, means that a new set of parameters should be sent. If not set, + specifies that the previous set of parameters should be used. + * - ``V4L2_AV1_FILM_GRAIN_FLAG_CHROMA_SCALING_FROM_LUMA`` + - 0x00000004 + - If set, specifies that the chroma scaling is inferred from the luma + scaling. + * - ``V4L2_AV1_FILM_GRAIN_FLAG_OVERLAP`` + - 0x00000008 + - If set, indicates that the overlap between film grain blocks shall be + applied. If not set, indicates that the overlap between film grain blocks + shall not be applied. + * - ``V4L2_AV1_FILM_GRAIN_FLAG_CLIP_TO_RESTRICTED_RANGE`` + - 0x00000010 + - If set, indicates that clipping to the restricted (studio, i.e. limited) + range shall be applied to the sample values after adding the film grain + (see the semantics for color_range for an explanation of studio swing). + If not set, indicates that clipping to the full range shall be applied + to the sample values after adding the film grain. diff --git a/Documentation/userspace-api/media/v4l/meta-formats.rst b/Documentation/userspace-api/media/v4l/meta-formats.rst index fff25357fe86..0bb61fc5bc00 100644 --- a/Documentation/userspace-api/media/v4l/meta-formats.rst +++ b/Documentation/userspace-api/media/v4l/meta-formats.rst @@ -12,10 +12,10 @@ These formats are used for the :ref:`metadata` interface only. .. toctree:: :maxdepth: 1 - pixfmt-meta-d4xx - pixfmt-meta-intel-ipu3 - pixfmt-meta-rkisp1 - pixfmt-meta-uvc - pixfmt-meta-vsp1-hgo - pixfmt-meta-vsp1-hgt - pixfmt-meta-vivid + metafmt-d4xx + metafmt-intel-ipu3 + metafmt-rkisp1 + metafmt-uvc + metafmt-vsp1-hgo + metafmt-vsp1-hgt + metafmt-vivid diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-d4xx.rst b/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst index 4e437ba97a0e..0686413b16b2 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-meta-d4xx.rst +++ b/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst @@ -12,7 +12,7 @@ Intel D4xx UVC Cameras Metadata Description =========== -Intel D4xx (D435 and other) cameras include per-frame metadata in their UVC +Intel D4xx (D435, D455 and others) cameras include per-frame metadata in their UVC payload headers, following the Microsoft(R) UVC extension proposal [1_]. That means, that the private D4XX metadata, following the standard UVC header, is organised in blocks. D4XX cameras implement several standard block types, @@ -26,6 +26,8 @@ V4L2_META_FMT_UVC with the only difference, that it also includes proprietary payload header data. D4xx cameras use bulk transfers and only send one payload per frame, therefore their headers cannot be larger than 255 bytes. +This document implements Intel Configuration version 3 [9_]. + Below are proprietary Microsoft style metadata types, used by D4xx cameras, where all fields are in little endian order: @@ -43,10 +45,10 @@ where all fields are in little endian order: * - __u32 ID - 0x80000000 * - __u32 Size - - Size in bytes (currently 56) + - Size in bytes, include ID (all protocol versions: 60) * - __u32 Version - - Version of this structure. The documentation herein corresponds to - version xxx. The version number will be incremented when new fields are + - Version of this structure. The documentation herein covers versions 1, + 2 and 3. The version number will be incremented when new fields are added. * - __u32 Flags - A bitmask of flags: see [2_] below @@ -72,13 +74,17 @@ where all fields are in little endian order: - Bottom border of the AE Region of Interest * - __u32 Preset - Preset selector value, default: 0, unless changed by the user - * - __u32 Laser mode - - 0: off, 1: on + * - __u8 Emitter mode (v3 only) (__u32 Laser mode for v1) [8_] + - 0: off, 1: on, same as __u32 Laser mode for v1 + * - __u8 RFU byte (v3 only) + - Spare byte for future use + * - __u16 LED Power (v3 only) + - Led power value 0-360 (F416 SKU) * - :cspan:`1` *Capture Timing* * - __u32 ID - 0x80000001 * - __u32 Size - - Size in bytes (currently 40) + - Size in bytes, include ID (all protocol versions: 40) * - __u32 Version - Version of this structure. The documentation herein corresponds to version xxx. The version number will be incremented when new fields are @@ -101,7 +107,7 @@ where all fields are in little endian order: * - __u32 ID - 0x80000002 * - __u32 Size - - Size in bytes (currently 40) + - Size in bytes, include ID (v1:36, v3:40) * - __u32 Version - Version of this structure. The documentation herein corresponds to version xxx. The version number will be incremented when new fields are @@ -124,6 +130,14 @@ where all fields are in little endian order: - Requested frame rate per second * - __u16 Trigger - Byte 0: bit 0: depth and RGB are synchronised, bit 1: external trigger + * - __u16 Calibration count (v3 only) + - Calibration counter, see [4_] below + * - __u8 GPIO input data (v3 only) + - GPIO readout, see [4_] below (Supported from FW 5.12.7.0) + * - __u32 Sub-preset info (v3 only) + - Sub-preset choice information, see [4_] below + * - __u8 reserved (v3 only) + - RFU byte. .. _1: @@ -140,6 +154,8 @@ where all fields are in little endian order: 0x00000010 Exposure priority 0x00000020 AE ROI 0x00000040 Preset + 0x00000080 Emitter mode + 0x00000100 LED Power .. _3: @@ -165,6 +181,8 @@ where all fields are in little endian order: 0x00000040 Framerate 0x00000080 Trigger 0x00000100 Cal count + 0x00000200 GPIO Input Data + 0x00000400 Sub-preset Info .. _5: @@ -211,3 +229,24 @@ Left sensor: :: Fish Eye sensor: :: 1 RAW8 + +.. _8: + +[8] The "Laser mode" has been replaced in version 3 by three different fields. +"Laser" has been renamed to "Emitter" as there are multiple technologies for +camera projectors. As we have another field for "Laser Power" we introduced +"LED Power" for extra emitter. + +The "Laser mode" __u32 fields has been split into: :: + 1 __u8 Emitter mode + 2 __u8 RFU byte + 3 __u16 LED Power + +This is a change between versions 1 and 3. All versions 1, 2 and 3 are backward +compatible with the same data format and they are supported. See [2_] for which +attributes are valid. + +.. _9: + +[9] LibRealSense SDK metadata source: +https://github.com/IntelRealSense/librealsense/blob/master/src/metadata.h diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst b/Documentation/userspace-api/media/v4l/metafmt-intel-ipu3.rst index 84d81dd7a7b5..84d81dd7a7b5 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst +++ b/Documentation/userspace-api/media/v4l/metafmt-intel-ipu3.rst diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst b/Documentation/userspace-api/media/v4l/metafmt-rkisp1.rst index fa04f00bcd2e..fa04f00bcd2e 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst +++ b/Documentation/userspace-api/media/v4l/metafmt-rkisp1.rst diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-uvc.rst b/Documentation/userspace-api/media/v4l/metafmt-uvc.rst index 784346d14bbd..784346d14bbd 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-meta-uvc.rst +++ b/Documentation/userspace-api/media/v4l/metafmt-uvc.rst diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-vivid.rst b/Documentation/userspace-api/media/v4l/metafmt-vivid.rst index 7173e2c3e245..7173e2c3e245 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-meta-vivid.rst +++ b/Documentation/userspace-api/media/v4l/metafmt-vivid.rst diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-vsp1-hgo.rst b/Documentation/userspace-api/media/v4l/metafmt-vsp1-hgo.rst index 8d886feb180c..8d886feb180c 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-meta-vsp1-hgo.rst +++ b/Documentation/userspace-api/media/v4l/metafmt-vsp1-hgo.rst diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-vsp1-hgt.rst b/Documentation/userspace-api/media/v4l/metafmt-vsp1-hgt.rst index d8830ff605de..d8830ff605de 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-meta-vsp1-hgt.rst +++ b/Documentation/userspace-api/media/v4l/metafmt-vsp1-hgt.rst diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst index 06b78e5589d2..806ed73ac474 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst @@ -258,6 +258,22 @@ Compressed Formats RV9 players - the format and decoder did not change, only the encoder did. As a result, it uses the same FourCC. + * .. _V4L2-PIX-FMT-AV1-FRAME: + + - ``V4L2_PIX_FMT_AV1_FRAME`` + - 'AV1F' + - AV1 parsed frame, including the frame header, as extracted from the container. + This format is adapted for stateless video decoders that implement a AV1 + pipeline with the :ref:`stateless_decoder`. Metadata associated with the + frame to decode is required to be passed through the + ``V4L2_CID_STATELESS_AV1_SEQUENCE``, ``V4L2_CID_STATELESS_AV1_FRAME``, + and ``V4L2_CID_STATELESS_AV1_TILE_GROUP_ENTRY`` controls. + See the :ref:`associated Codec Control IDs <v4l2-codec-stateless-av1>`. + Exactly one output and one capture buffer must be provided for use with + this pixel format. The output buffer must contain the appropriate number + of macroblocks to decode a full corresponding frame to the matching + capture buffer. + .. raw:: latex \normalsize diff --git a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst index 58f6ae25b2e7..296ad2025e8d 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst @@ -275,6 +275,19 @@ please make a proposal on the linux-media mailing list. Decoder's implementation can be found here, `aspeed_codec <https://github.com/AspeedTech-BMC/aspeed_codec/>`__ + * .. _V4L2-PIX-FMT-MT2110T: + + - ``V4L2_PIX_FMT_MT2110T`` + - 'MT2110T' + - This format is two-planar 10-Bit tile mode and having similitude with + ``V4L2_PIX_FMT_MM21`` in term of alignment and tiling. Used for VP9, AV1 + and HEVC. + * .. _V4L2-PIX-FMT-MT2110R: + + - ``V4L2_PIX_FMT_MT2110R`` + - 'MT2110R' + - This format is two-planar 10-Bit raster mode and having similitude with + ``V4L2_PIX_FMT_MM21`` in term of alignment and tiling. Used for AVC. .. raw:: latex \normalsize diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst index 72324274f20c..1840224faa41 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst @@ -137,6 +137,13 @@ All components are stored with the same number of bits per component. - Cb, Cr - No - Linear + * - V4L2_PIX_FMT_NV15_4L4 + - 'VT15' + - 15 + - 4:2:0 + - Cb, Cr + - Yes + - 4x4 tiles * - V4L2_PIX_FMT_NV16 - 'NV16' - 8 @@ -378,6 +385,15 @@ two non-contiguous planes. Example V4L2_PIX_FMT_NV12MT memory layout of tiles +.. _V4L2-PIX-FMT-NV15-4L4: + +Tiled NV15 +---------- + +Semi-planar 10-bit YUV 4:2:0 formats, using 4x4 tiling. +All components are packed without any padding between each other. +As a side-effect, each group of 4 components are stored over 5 bytes +(YYYY or UVUV = 4 * 10 bits = 40 bits = 5 bytes). .. _V4L2-PIX-FMT-NV16: .. _V4L2-PIX-FMT-NV61: 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 5292d5e1a91f..f9f73530a6be 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -185,12 +185,12 @@ still cause this situation. - ``p_u32`` - A pointer to a matrix control of unsigned 32-bit values. Valid if this control is of type ``V4L2_CTRL_TYPE_U32``. - * - __u32 * + * - __s32 * - ``p_s32`` - A pointer to a matrix control of signed 32-bit values. Valid if this control is of type ``V4L2_CTRL_TYPE_INTEGER`` and ``V4L2_CTRL_FLAG_HAS_PAYLOAD`` is set. - * - __u32 * + * - __s64 * - ``p_s64`` - A pointer to a matrix control of signed 64-bit values. Valid if this control is of type ``V4L2_CTRL_TYPE_INTEGER64`` and @@ -279,6 +279,22 @@ still cause this situation. - ``p_hevc_decode_params`` - A pointer to a struct :c:type:`v4l2_ctrl_hevc_decode_params`. Valid if this control is of type ``V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS``. + * - struct :c:type:`v4l2_ctrl_av1_sequence` * + - ``p_av1_sequence`` + - A pointer to a struct :c:type:`v4l2_ctrl_av1_sequence`. Valid if this control is + of type ``V4L2_CTRL_TYPE_AV1_SEQUENCE``. + * - struct :c:type:`v4l2_ctrl_av1_tile_group_entry` * + - ``p_av1_tile_group_entry`` + - A pointer to a struct :c:type:`v4l2_ctrl_av1_tile_group_entry`. Valid if this control is + of type ``V4L2_CTRL_TYPE_AV1_TILE_GROUP_ENTRY``. + * - struct :c:type:`v4l2_ctrl_av1_frame` * + - ``p_av1_frame`` + - A pointer to a struct :c:type:`v4l2_ctrl_av1_frame`. Valid if this control is + of type ``V4L2_CTRL_TYPE_AV1_FRAME``. + * - struct :c:type:`v4l2_ctrl_av1_film_grain` * + - ``p_av1_film_grain`` + - A pointer to a struct :c:type:`v4l2_ctrl_av1_film_grain`. Valid if this control is + of type ``V4L2_CTRL_TYPE_AV1_FILM_GRAIN``. * - void * - ``ptr`` - A pointer to a compound type which can be an N-dimensional array diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index a20dfa2a933b..4d38acafe8e1 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -525,6 +525,30 @@ See also the examples in :ref:`control`. - n/a - A struct :c:type:`v4l2_ctrl_vp9_frame`, containing VP9 frame decode parameters for stateless video decoders. + * - ``V4L2_CTRL_TYPE_AV1_SEQUENCE`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_av1_sequence`, containing AV1 Sequence OBU + decoding parameters for stateless video decoders. + * - ``V4L2_CTRL_TYPE_AV1_TILE_GROUP_ENTRY`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_av1_tile_group_entry`, containing AV1 Tile Group + OBU decoding parameters for stateless video decoders. + * - ``V4L2_CTRL_TYPE_AV1_FRAME`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_av1_frame`, containing AV1 Frame/Frame + Header OBU decoding parameters for stateless video decoders. + * - ``V4L2_CTRL_TYPE_AV1_FILM_GRAIN`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_av1_film_grain`, containing AV1 Film Grain + parameters for stateless video decoders. .. raw:: latex diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst index 68ca343c3b44..72677a280cd6 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst @@ -58,6 +58,9 @@ the subdevice exposes, drivers return the ENOSPC error code and adjust the value of the ``num_routes`` field. Application should then reserve enough memory for all the route entries and call ``VIDIOC_SUBDEV_G_ROUTING`` again. +On a successful ``VIDIOC_SUBDEV_G_ROUTING`` call the driver updates the +``num_routes`` field to reflect the actual number of routes returned. + .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}| .. c:type:: v4l2_subdev_routing @@ -122,7 +125,7 @@ for all the route entries and call ``VIDIOC_SUBDEV_G_ROUTING`` again. :widths: 3 1 4 * - V4L2_SUBDEV_ROUTE_FL_ACTIVE - - 0 + - 0x0001 - The route is enabled. Set by applications. Return Value @@ -138,9 +141,7 @@ ENOSPC EINVAL The sink or source pad identifiers reference a non-existing pad, or reference - pads of different types (ie. the sink_pad identifiers refers to a source pad) - or the sink or source stream identifiers reference a non-existing stream on - the sink or source pad. + pads of different types (ie. the sink_pad identifiers refers to a source pad). E2BIG The application provided ``num_routes`` for ``VIDIOC_SUBDEV_S_ROUTING`` is diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index 2a589d34b80e..3e58aac4ef0b 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -161,6 +161,10 @@ 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_HEVC_SCALING_MATRIX :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_AV1_SEQUENCE :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_AV1_TILE_GROUP_ENTRY :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_AV1_FRAME :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_AV1_FILM_GRAIN :c:type:`v4l2_ctrl_type` # V4L2 capability defines replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities diff --git a/Documentation/userspace-api/netlink/genetlink-legacy.rst b/Documentation/userspace-api/netlink/genetlink-legacy.rst index 802875a37a27..40b82ad5d54a 100644 --- a/Documentation/userspace-api/netlink/genetlink-legacy.rst +++ b/Documentation/userspace-api/netlink/genetlink-legacy.rst @@ -8,11 +8,8 @@ This document describes the many additional quirks and properties required to describe older Generic Netlink families which form the ``genetlink-legacy`` protocol level. -The spec is a work in progress, some of the quirks are just documented -for future reference. - -Specification (defined) -======================= +Specification +============= Attribute type nests -------------------- @@ -156,16 +153,27 @@ it will be allocated 3 for the request (``a`` is the previous operation with a request section and the value of 2) and 8 for response (``c`` is the previous operation in the "from-kernel" direction). -Other quirks (todo) -=================== +Other quirks +============ Structures ---------- Legacy families can define C structures both to be used as the contents of an attribute and as a fixed message header. Structures are defined in -``definitions`` and referenced in operations or attributes. Note that -structures defined in YAML are implicitly packed according to C +``definitions`` and referenced in operations or attributes. + +members +~~~~~~~ + + - ``name`` - The attribute name of the struct member + - ``type`` - One of the scalar types ``u8``, ``u16``, ``u32``, ``u64``, ``s8``, + ``s16``, ``s32``, ``s64``, ``string`` or ``binary``. + - ``byte-order`` - ``big-endian`` or ``little-endian`` + - ``doc``, ``enum``, ``enum-as-flags``, ``display-hint`` - Same as for + :ref:`attribute definitions <attribute_properties>` + +Note that structures defined in YAML are implicitly packed according to C conventions. For example, the following struct is 4 bytes, not 6 bytes: .. code-block:: c diff --git a/Documentation/userspace-api/netlink/index.rst b/Documentation/userspace-api/netlink/index.rst index 26f3720cb3be..62725dafbbdb 100644 --- a/Documentation/userspace-api/netlink/index.rst +++ b/Documentation/userspace-api/netlink/index.rst @@ -14,5 +14,6 @@ Netlink documentation for users. specs c-code-gen genetlink-legacy + netlink-raw See also :ref:`Documentation/core-api/netlink.rst <kernel_netlink>`. diff --git a/Documentation/userspace-api/netlink/intro-specs.rst b/Documentation/userspace-api/netlink/intro-specs.rst index a3b847eafff7..bada89699455 100644 --- a/Documentation/userspace-api/netlink/intro-specs.rst +++ b/Documentation/userspace-api/netlink/intro-specs.rst @@ -78,3 +78,82 @@ to see other examples. The code generation itself is performed by ``tools/net/ynl/ynl-gen-c.py`` but it takes a few arguments so calling it directly for each file quickly becomes tedious. + +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. + +YNL basics +---------- + +The YNL library consists of two parts - the generic code (functions +prefix by ``ynl_``) and per-family auto-generated code (prefixed +with the name of the family). + +To create a YNL socket call ynl_sock_create() passing the family +struct (family structs are exported by the auto-generated code). +ynl_sock_destroy() closes the socket. + +YNL requests +------------ + +Steps for issuing YNL requests are best explained on an example. +All the functions and types in this example come from the auto-generated +code (for the netdev family in this case): + +.. code-block:: c + + // 0. Request and response pointers + struct netdev_dev_get_req *req; + struct netdev_dev_get_rsp *d; + + // 1. Allocate a request + req = netdev_dev_get_req_alloc(); + // 2. Set request parameters (as needed) + netdev_dev_get_req_set_ifindex(req, ifindex); + + // 3. Issues the request + d = netdev_dev_get(ys, req); + // 4. Free the request arguments + netdev_dev_get_req_free(req); + // 5. Error check (the return value from step 3) + if (!d) { + // 6. Print the YNL-generated error + fprintf(stderr, "YNL: %s\n", ys->err.msg); + return -1; + } + + // ... do stuff with the response @d + + // 7. Free response + netdev_dev_get_rsp_free(d); + +YNL dumps +--------- + +Performing dumps follows similar pattern as requests. +Dumps return a list of objects terminated by a special marker, +or NULL on error. Use ``ynl_dump_foreach()`` to iterate over +the result. + +YNL notifications +----------------- + +YNL lib supports using the same socket for notifications and +requests. In case notifications arrive during processing of a request +they are queued internally and can be retrieved at a later time. + +To subscribed to notifications use ``ynl_subscribe()``. +The notifications have to be read out from the socket, +``ynl_socket_get_fd()`` returns the underlying socket fd which can +be plugged into appropriate asynchronous IO API like ``poll``, +or ``select``. + +Notifications can be retrieved using ``ynl_ntf_dequeue()`` and have +to be freed using ``ynl_ntf_free()``. Since we don't know the notification +type upfront the notifications are returned as ``struct ynl_ntf_base_type *`` +and user is expected to cast them to the appropriate full type based +on the ``cmd`` member. diff --git a/Documentation/userspace-api/netlink/intro.rst b/Documentation/userspace-api/netlink/intro.rst index 0955e9f203d3..af94e71761ec 100644 --- a/Documentation/userspace-api/netlink/intro.rst +++ b/Documentation/userspace-api/netlink/intro.rst @@ -615,7 +615,7 @@ and ``SET``. Each object can handle all or some of those requests is defined by the 2 lowest bits of the message type, so commands for new objects would always be allocated with a stride of 4. -Each object would also have it's own fixed metadata shared by all request +Each object would also have its own fixed metadata shared by all request types (e.g. struct ifinfomsg for netdev requests, struct ifaddrmsg for address requests, struct tcmsg for qdisc requests). diff --git a/Documentation/userspace-api/netlink/netlink-raw.rst b/Documentation/userspace-api/netlink/netlink-raw.rst new file mode 100644 index 000000000000..f07fb9b9c101 --- /dev/null +++ b/Documentation/userspace-api/netlink/netlink-raw.rst @@ -0,0 +1,58 @@ +.. SPDX-License-Identifier: BSD-3-Clause + +====================================================== +Netlink specification support for raw Netlink families +====================================================== + +This document describes the additional properties required by raw Netlink +families such as ``NETLINK_ROUTE`` which use the ``netlink-raw`` protocol +specification. + +Specification +============= + +The netlink-raw schema extends the :doc:`genetlink-legacy <genetlink-legacy>` +schema with properties that are needed to specify the protocol numbers and +multicast IDs used by raw netlink families. See :ref:`classic_netlink` for more +information. + +Globals +------- + +protonum +~~~~~~~~ + +The ``protonum`` property is used to specify the protocol number to use when +opening a netlink socket. + +.. code-block:: yaml + + # SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + + name: rt-addr + protocol: netlink-raw + protonum: 0 # part of the NETLINK_ROUTE protocol + + +Multicast group properties +-------------------------- + +value +~~~~~ + +The ``value`` property is used to specify the group ID to use for multicast +group registration. + +.. code-block:: yaml + + mcast-groups: + list: + - + name: rtnlgrp-ipv4-ifaddr + value: 5 + - + name: rtnlgrp-ipv6-ifaddr + value: 9 + - + name: rtnlgrp-mctp-ifaddr + value: 34 diff --git a/Documentation/userspace-api/netlink/specs.rst b/Documentation/userspace-api/netlink/specs.rst index 2e4acde890b7..cc4e2430997e 100644 --- a/Documentation/userspace-api/netlink/specs.rst +++ b/Documentation/userspace-api/netlink/specs.rst @@ -68,6 +68,10 @@ The following sections describe the properties of the most modern ``genetlink`` schema. See the documentation of :doc:`genetlink-c <c-code-gen>` for information on how C names are derived from name properties. +See also :ref:`Documentation/core-api/netlink.rst <kernel_netlink>` for +information on the Netlink specification properties that are only relevant to +the kernel space and not part of the user space API. + genetlink ========= @@ -180,6 +184,8 @@ attributes List of attributes in the set. +.. _attribute_properties: + Attribute properties -------------------- @@ -264,6 +270,13 @@ a C array of u32 values can be specified with ``type: binary`` and ``sub-type: u32``. Binary types and legacy array formats are described in more detail in :doc:`genetlink-legacy`. +display-hint +~~~~~~~~~~~~ + +Optional format indicator that is intended only for choosing the right +formatting mechanism when displaying values of this type. Currently supported +hints are ``hex``, ``mac``, ``fddi``, ``ipv4``, ``ipv6`` and ``uuid``. + operations ---------- diff --git a/Documentation/virt/guest-halt-polling.rst b/Documentation/virt/guest-halt-polling.rst index b4e747942417..922291ddc40c 100644 --- a/Documentation/virt/guest-halt-polling.rst +++ b/Documentation/virt/guest-halt-polling.rst @@ -72,7 +72,7 @@ high once achieves global guest_halt_poll_ns value). Default: Y -The module parameters can be set from the debugfs files in:: +The module parameters can be set from the sysfs files in:: /sys/module/haltpoll/parameters/ diff --git a/Documentation/virt/hyperv/clocks.rst b/Documentation/virt/hyperv/clocks.rst index 2da2879fad52..a56f4837d443 100644 --- a/Documentation/virt/hyperv/clocks.rst +++ b/Documentation/virt/hyperv/clocks.rst @@ -60,7 +60,7 @@ vDSO, and gettimeofday() and related system calls can execute entirely in user space. The vDSO is implemented by mapping the shared page with scale and offset values into user space. User space code performs the same algorithm of reading the TSC and -appying the scale and offset to get the constant 10 MHz clock. +applying the scale and offset to get the constant 10 MHz clock. Linux clockevents are based on Hyper-V synthetic timer 0. While Hyper-V offers 4 synthetic timers for each CPU, Linux only uses diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index add067793b90..73db30cb60fb 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -578,7 +578,7 @@ This is an asynchronous vcpu ioctl and can be invoked from any thread. RISC-V: ^^^^^^^ -Queues an external interrupt to be injected into the virutal CPU. This ioctl +Queues an external interrupt to be injected into the virtual CPU. This ioctl is overloaded with 2 different irq values: a) KVM_INTERRUPT_SET @@ -2613,7 +2613,7 @@ follows:: this vcpu, and determines which register slices are visible through this ioctl interface. -(See Documentation/arm64/sve.rst for an explanation of the "vq" +(See Documentation/arch/arm64/sve.rst for an explanation of the "vq" nomenclature.) KVM_REG_ARM64_SVE_VLS is only accessible after KVM_ARM_VCPU_INIT. @@ -2722,7 +2722,7 @@ The isa config register can be read anytime but can only be written before a Guest VCPU runs. It will have ISA feature bits matching underlying host set by default. -RISC-V core registers represent the general excution state of a Guest VCPU +RISC-V core registers represent the general execution state of a Guest VCPU and it has the following id bit patterns:: 0x8020 0000 02 <index into the kvm_riscv_core struct:24> (32bit Host) @@ -5232,7 +5232,7 @@ KVM_PV_DISABLE Deregister the VM from the Ultravisor and reclaim the memory that had been donated to the Ultravisor, making it usable by the kernel again. All registered VCPUs are converted back to non-protected ones. If a - previous protected VM had been prepared for asynchonous teardown with + previous protected VM had been prepared for asynchronous teardown with KVM_PV_ASYNC_CLEANUP_PREPARE and not subsequently torn down with KVM_PV_ASYNC_CLEANUP_PERFORM, it will be torn down in this call together with the current protected VM. @@ -5692,7 +5692,7 @@ flags values for ``kvm_sregs2``: ``KVM_SREGS2_FLAGS_PDPTRS_VALID`` - Indicates thats the struct contain valid PDPTR values. + Indicates that the struct contains valid PDPTR values. 4.132 KVM_SET_SREGS2 @@ -6263,7 +6263,7 @@ to the byte array. It is strongly recommended that userspace use ``KVM_EXIT_IO`` (x86) or ``KVM_EXIT_MMIO`` (all except s390) to implement functionality that -requires a guest to interact with host userpace. +requires a guest to interact with host userspace. .. note:: KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO. @@ -6336,7 +6336,7 @@ s390 specific. } s390_ucontrol; s390 specific. A page fault has occurred for a user controlled virtual -machine (KVM_VM_S390_UNCONTROL) on it's host page table that cannot be +machine (KVM_VM_S390_UNCONTROL) on its host page table that cannot be resolved by the kernel. The program code and the translation exception code that were placed in the cpu's lowcore are presented here as defined by the z Architecture @@ -7510,7 +7510,7 @@ APIC/MSRs/etc). attribute is not supported by KVM. KVM_CAP_SGX_ATTRIBUTE enables a userspace VMM to grant a VM access to one or -more priveleged enclave attributes. args[0] must hold a file handle to a valid +more privileged enclave attributes. args[0] must hold a file handle to a valid SGX attribute file corresponding to an attribute that is supported/restricted by KVM (currently only PROVISIONKEY). @@ -7928,7 +7928,7 @@ writing to the respective MSRs. This capability indicates that userspace can load HV_X64_MSR_VP_INDEX msr. Its value is used to denote the target vcpu for a SynIC interrupt. For -compatibilty, KVM initializes this msr to KVM's internal vcpu index. When this +compatibility, KVM initializes this msr to KVM's internal vcpu index. When this capability is absent, userspace can still query this msr's value. 8.13 KVM_CAP_S390_AIS_MIGRATION @@ -8118,10 +8118,10 @@ regardless of what has actually been exposed through the CPUID leaf. :Parameters: args[0] - size of the dirty log ring KVM is capable of tracking dirty memory using ring buffers that are -mmaped into userspace; there is one dirty ring per vcpu. +mmapped into userspace; there is one dirty ring per vcpu. The dirty ring is available to userspace as an array of -``struct kvm_dirty_gfn``. Each dirty entry it's defined as:: +``struct kvm_dirty_gfn``. Each dirty entry is defined as:: struct kvm_dirty_gfn { __u32 flags; @@ -8160,7 +8160,7 @@ state machine for the entry is as follows:: | | +------------------------------------------+ -To harvest the dirty pages, userspace accesses the mmaped ring buffer +To harvest the dirty pages, userspace accesses the mmapped ring buffer to read the dirty GFNs. If the flags has the DIRTY bit set (at this stage the RESET bit must be cleared), then it means this GFN is a dirty GFN. The userspace should harvest this GFN and mark the flags from state @@ -8286,7 +8286,7 @@ the KVM_XEN_ATTR_TYPE_RUNSTATE_UPDATE_FLAG attribute in the KVM_XEN_SET_ATTR and KVM_XEN_GET_ATTR ioctls. This controls whether KVM will set the XEN_RUNSTATE_UPDATE flag in guest memory mapped vcpu_runstate_info during updates of the runstate information. Note that versions of KVM which support -the RUNSTATE feature above, but not thie RUNSTATE_UPDATE_FLAG feature, will +the RUNSTATE feature above, but not the RUNSTATE_UPDATE_FLAG feature, will always set the XEN_RUNSTATE_UPDATE flag when updating the guest structure, which is perhaps counterintuitive. When this flag is advertised, KVM will behave more correctly, not using the XEN_RUNSTATE_UPDATE flag until/unless @@ -8335,7 +8335,7 @@ Architectures: x86 When enabled, KVM will disable emulated Hyper-V features provided to the guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all -currently implmented Hyper-V features are provided unconditionally when +currently implemented Hyper-V features are provided unconditionally when Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001) leaf. @@ -8445,6 +8445,33 @@ structure. When getting the Modified Change Topology Report value, the attr->addr must point to a byte where the value will be stored or retrieved from. +8.40 KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE +--------------------------------------- + +:Capability: KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE +:Architectures: arm64 +:Type: vm +:Parameters: arg[0] is the new split chunk size. +:Returns: 0 on success, -EINVAL if any memslot was already created. + +This capability sets the chunk size used in Eager Page Splitting. + +Eager Page Splitting improves the performance of dirty-logging (used +in live migrations) when guest memory is backed by huge-pages. It +avoids splitting huge-pages (into PAGE_SIZE pages) on fault, by doing +it eagerly when enabling dirty logging (with the +KVM_MEM_LOG_DIRTY_PAGES flag for a memory region), or when using +KVM_CLEAR_DIRTY_LOG. + +The chunk size specifies how many pages to break at a time, using a +single allocation for each chunk. Bigger the chunk size, more pages +need to be allocated ahead of time. + +The chunk size needs to be a valid block size. The list of acceptable +block sizes is exposed in KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES as a +64-bit bitmap (each bit describing a block size). The default value is +0, to disable the eager page splitting. + 9. Known KVM API problems ========================= diff --git a/Documentation/virt/kvm/devices/vfio.rst b/Documentation/virt/kvm/devices/vfio.rst index 08b544212638..c549143bb891 100644 --- a/Documentation/virt/kvm/devices/vfio.rst +++ b/Documentation/virt/kvm/devices/vfio.rst @@ -9,22 +9,34 @@ Device types supported: - KVM_DEV_TYPE_VFIO Only one VFIO instance may be created per VM. The created device -tracks VFIO groups in use by the VM and features of those groups -important to the correctness and acceleration of the VM. As groups -are enabled and disabled for use by the VM, KVM should be updated -about their presence. When registered with KVM, a reference to the -VFIO-group is held by KVM. +tracks VFIO files (group or device) in use by the VM and features +of those groups/devices important to the correctness and acceleration +of the VM. As groups/devices are enabled and disabled for use by the +VM, KVM should be updated about their presence. When registered with +KVM, a reference to the VFIO file is held by KVM. Groups: - KVM_DEV_VFIO_GROUP - -KVM_DEV_VFIO_GROUP attributes: - KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking - kvm_device_attr.addr points to an int32_t file descriptor - for the VFIO group. - KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking - kvm_device_attr.addr points to an int32_t file descriptor - for the VFIO group. + KVM_DEV_VFIO_FILE + alias: KVM_DEV_VFIO_GROUP + +KVM_DEV_VFIO_FILE attributes: + KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM device + tracking + + kvm_device_attr.addr points to an int32_t file descriptor for the + VFIO file. + + KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from VFIO-KVM + device tracking + + kvm_device_attr.addr points to an int32_t file descriptor for the + VFIO file. + +KVM_DEV_VFIO_GROUP (legacy kvm device group restricted to the handling of VFIO group fd): + KVM_DEV_VFIO_GROUP_ADD: same as KVM_DEV_VFIO_FILE_ADD for group fd only + + KVM_DEV_VFIO_GROUP_DEL: same as KVM_DEV_VFIO_FILE_DEL for group fd only + KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE table allocated by sPAPR KVM. kvm_device_attr.addr points to a struct:: @@ -40,7 +52,10 @@ KVM_DEV_VFIO_GROUP attributes: - @tablefd is a file descriptor for a TCE table allocated via KVM_CREATE_SPAPR_TCE. -The GROUP_ADD operation above should be invoked prior to accessing the +The FILE/GROUP_ADD operation above should be invoked prior to accessing the device file descriptor via VFIO_GROUP_GET_DEVICE_FD in order to support drivers which require a kvm pointer to be set in their .open_device() -callback. +callback. It is the same for device file descriptor via character device +open which gets device access via VFIO_DEVICE_BIND_IOMMUFD. For such file +descriptors, FILE_ADD should be invoked before VFIO_DEVICE_BIND_IOMMUFD +to support the drivers mentioned in prior sentence as well. diff --git a/Documentation/virt/kvm/devices/vm.rst b/Documentation/virt/kvm/devices/vm.rst index 9d726e60ec47..a4d39fa1b083 100644 --- a/Documentation/virt/kvm/devices/vm.rst +++ b/Documentation/virt/kvm/devices/vm.rst @@ -92,7 +92,7 @@ Allows user space to retrieve or request to change cpu related information for a KVM does not enforce or limit the cpu model data in any form. Take the information retrieved by means of KVM_S390_VM_CPU_MACHINE as hint for reasonable configuration setups. Instruction interceptions triggered by additionally set facility bits that -are not handled by KVM need to by imlemented in the VM driver code. +are not handled by KVM need to by implemented in the VM driver code. :Parameters: address of buffer to store/set the processor related cpu data of type struct kvm_s390_vm_cpu_processor*. diff --git a/Documentation/virt/kvm/devices/xive.rst b/Documentation/virt/kvm/devices/xive.rst index 8b5e7b40bdf8..a07e16d34006 100644 --- a/Documentation/virt/kvm/devices/xive.rst +++ b/Documentation/virt/kvm/devices/xive.rst @@ -50,7 +50,7 @@ the legacy interrupt mode, referred as XICS (POWER7/8). When a device is passed-through into the guest, the source interrupts are from a different HW controller (PHB4) and the ESB - pages exposed to the guest should accommadate this change. + pages exposed to the guest should accommodate this change. The passthru_irq helpers, kvmppc_xive_set_mapped() and kvmppc_xive_clr_mapped() are called when the device HW irqs are diff --git a/Documentation/virt/kvm/halt-polling.rst b/Documentation/virt/kvm/halt-polling.rst index 3fae39b1a5ba..c82a04b709b4 100644 --- a/Documentation/virt/kvm/halt-polling.rst +++ b/Documentation/virt/kvm/halt-polling.rst @@ -14,7 +14,7 @@ before giving up the cpu to the scheduler in order to let something else run. Polling provides a latency advantage in cases where the guest can be run again very quickly by at least saving us a trip through the scheduler, normally on the order of a few micro-seconds, although performance benefits are workload -dependant. In the event that no wakeup source arrives during the polling +dependent. In the event that no wakeup source arrives during the polling interval or some other task on the runqueue is runnable the scheduler is invoked. Thus halt polling is especially useful on workloads with very short wakeup periods where the time spent halt polling is minimised and the time @@ -112,11 +112,11 @@ powerpc kvm-hv case. | | function. | | +-----------------------+---------------------------+-------------------------+ -These module parameters can be set from the debugfs files in: +These module parameters can be set from the sysfs files in: /sys/module/kvm/parameters/ -Note: that these module parameters are system wide values and are not able to +Note: these module parameters are system-wide values and are not able to be tuned on a per vm basis. Any changes to these parameters will be picked up by new and existing vCPUs the @@ -142,12 +142,12 @@ Further Notes global max polling interval (halt_poll_ns) then the host will always poll for the entire block time and thus cpu utilisation will go to 100%. -- Halt polling essentially presents a trade off between power usage and latency and +- Halt polling essentially presents a trade-off between power usage and latency and the module parameters should be used to tune the affinity for this. Idle cpu time is essentially converted to host kernel time with the aim of decreasing latency when entering the guest. - Halt polling will only be conducted by the host when no other tasks are runnable on that cpu, otherwise the polling will cease immediately and schedule will be invoked to - allow that other task to run. Thus this doesn't allow a guest to denial of service the - cpu. + allow that other task to run. Thus this doesn't allow a guest to cause denial of service + of the cpu. diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 8c77554e4896..3a034db5e55f 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -67,7 +67,7 @@ following two cases: 2. Write-Protection: The SPTE is present and the fault is caused by write-protect. That means we just need to change the W bit of the spte. -What we use to avoid all the race is the Host-writable bit and MMU-writable bit +What we use to avoid all the races is the Host-writable bit and MMU-writable bit on the spte: - Host-writable means the gfn is writable in the host kernel page tables and in @@ -130,7 +130,7 @@ to gfn. For indirect sp, we disabled fast page fault for simplicity. A solution for indirect sp could be to pin the gfn, for example via kvm_vcpu_gfn_to_pfn_atomic, before the cmpxchg. After the pinning: -- We have held the refcount of pfn that means the pfn can not be freed and +- We have held the refcount of pfn; that means the pfn can not be freed and be reused for another gfn. - The pfn is writable and therefore it cannot be shared between different gfns by KSM. @@ -186,22 +186,22 @@ 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_has_volatile_bits()]; it means the spte is always atomically updated in this case. 3) flush tlbs due to spte updated -If the spte is updated from writable to readonly, we should flush all TLBs, +If the spte is updated from writable to read-only, we should flush all TLBs, otherwise rmap_write_protect will find a read-only spte, even though the writable spte might be cached on a CPU's TLB. As mentioned before, the spte can be updated to writable out of mmu-lock on -fast page fault path, in order to easily audit the path, we see if TLBs need -be flushed caused by this reason in mmu_spte_update() since this is a common +fast page fault path. In order to easily audit the path, we see if TLBs needing +to be flushed caused this reason in mmu_spte_update() since this is a common 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, the race caused by fast page fault can be avoided, +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(). Lockless Access Tracking: @@ -283,9 +283,9 @@ time it will be set using the Dirty tracking mechanism described above. :Arch: x86 :Protects: wakeup_vcpus_on_cpu :Comment: This is a per-CPU lock and it is used for VT-d posted-interrupts. - When VT-d posted-interrupts is supported and the VM has assigned + When VT-d posted-interrupts are supported and the VM has assigned devices, we put the blocked vCPU on the list blocked_vcpu_on_cpu - protected by blocked_vcpu_on_cpu_lock, when VT-d hardware issues + protected by blocked_vcpu_on_cpu_lock. When VT-d hardware issues wakeup notification event since external interrupts from the assigned devices happens, we will find the vCPU on the list to wakeup. diff --git a/Documentation/virt/kvm/ppc-pv.rst b/Documentation/virt/kvm/ppc-pv.rst index 5fdb907670be..740d03d25300 100644 --- a/Documentation/virt/kvm/ppc-pv.rst +++ b/Documentation/virt/kvm/ppc-pv.rst @@ -89,7 +89,7 @@ also define a new hypercall feature to indicate that the host can give you more registers. Only if the host supports the additional features, make use of them. The magic page layout is described by struct kvm_vcpu_arch_shared -in arch/powerpc/include/asm/kvm_para.h. +in arch/powerpc/include/uapi/asm/kvm_para.h. Magic page features =================== @@ -112,7 +112,7 @@ Magic page flags ================ In addition to features that indicate whether a host is capable of a particular -feature we also have a channel for a guest to tell the guest whether it's capable +feature we also have a channel for a guest to tell the host whether it's capable of something. This is what we call "flags". Flags are passed to the host in the low 12 bits of the Effective Address. @@ -139,7 +139,7 @@ Patched instructions ==================== The "ld" and "std" instructions are transformed to "lwz" and "stw" instructions -respectively on 32 bit systems with an added offset of 4 to accommodate for big +respectively on 32-bit systems with an added offset of 4 to accommodate for big endianness. The following is a list of mapping the Linux kernel performs when running as @@ -210,7 +210,7 @@ available on all targets. 2) PAPR hypercalls PAPR hypercalls are needed to run server PowerPC PAPR guests (-M pseries in QEMU). -These are the same hypercalls that pHyp, the POWER hypervisor implements. Some of +These are the same hypercalls that pHyp, the POWER hypervisor, implements. Some of them are handled in the kernel, some are handled in user space. This is only available on book3s_64. diff --git a/Documentation/virt/kvm/vcpu-requests.rst b/Documentation/virt/kvm/vcpu-requests.rst index 87f04c1fa53d..06718b9bc959 100644 --- a/Documentation/virt/kvm/vcpu-requests.rst +++ b/Documentation/virt/kvm/vcpu-requests.rst @@ -101,7 +101,7 @@ also be used, e.g. :: However, VCPU request users should refrain from doing so, as it would break the abstraction. The first 8 bits are reserved for architecture -independent requests, all additional bits are available for architecture +independent requests; all additional bits are available for architecture dependent requests. Architecture Independent Requests @@ -151,8 +151,8 @@ KVM_REQUEST_NO_WAKEUP This flag is applied to requests that only need immediate attention from VCPUs running in guest mode. That is, sleeping VCPUs do not need - to be awaken for these requests. Sleeping VCPUs will handle the - requests when they are awaken later for some other reason. + to be awakened for these requests. Sleeping VCPUs will handle the + requests when they are awakened later for some other reason. KVM_REQUEST_WAIT diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst index 487b6328b3e7..995780088eb2 100644 --- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst @@ -57,7 +57,7 @@ information, see the SEV Key Management spec [api-spec]_ The main ioctl to access SEV is KVM_MEMORY_ENCRYPT_OP. If the argument to KVM_MEMORY_ENCRYPT_OP is NULL, the ioctl returns 0 if SEV is enabled -and ``ENOTTY` if it is disabled (on some older versions of Linux, +and ``ENOTTY`` if it is disabled (on some older versions of Linux, the ioctl runs normally even with a NULL argument, and therefore will likely return ``EFAULT``). If non-NULL, the argument to KVM_MEMORY_ENCRYPT_OP must be a struct kvm_sev_cmd:: diff --git a/Documentation/virt/kvm/x86/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst index 8364afa228ec..d47595b33fcf 100644 --- a/Documentation/virt/kvm/x86/mmu.rst +++ b/Documentation/virt/kvm/x86/mmu.rst @@ -205,7 +205,7 @@ Shadow pages contain the following information: role.passthrough: The page is not backed by a guest page table, but its first entry points to one. This is set if NPT uses 5-level page tables (host - CR4.LA57=1) and is shadowing L1's 4-level NPT (L1 CR4.LA57=1). + CR4.LA57=1) and is shadowing L1's 4-level NPT (L1 CR4.LA57=0). gfn: Either the guest page table containing the translations shadowed by this page, or the base page frame for linear translations. See role.direct. @@ -245,7 +245,7 @@ Shadow pages contain the following information: unsynchronized children). unsync_child_bitmap: A bitmap indicating which sptes in spt point (directly or indirectly) at - pages that may be unsynchronized. Used to quickly locate all unsychronized + pages that may be unsynchronized. Used to quickly locate all unsynchronized pages reachable from a given page. clear_spte_count: Only present on 32-bit hosts, where a 64-bit spte cannot be written diff --git a/Documentation/virt/kvm/x86/running-nested-guests.rst b/Documentation/virt/kvm/x86/running-nested-guests.rst index 71136fe1723b..87326413d5c7 100644 --- a/Documentation/virt/kvm/x86/running-nested-guests.rst +++ b/Documentation/virt/kvm/x86/running-nested-guests.rst @@ -169,7 +169,7 @@ Enabling "nested" (s390x) $ modprobe kvm nested=1 .. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive - with the ``nested`` paramter — i.e. to be able to enable + with the ``nested`` parameter — i.e. to be able to enable ``nested``, the ``hpage`` parameter *must* be disabled. 2. The guest hypervisor (L1) must be provided with the ``sie`` CPU diff --git a/Documentation/virt/paravirt_ops.rst b/Documentation/virt/paravirt_ops.rst index 6b789d27cead..62d867e0d4d6 100644 --- a/Documentation/virt/paravirt_ops.rst +++ b/Documentation/virt/paravirt_ops.rst @@ -5,31 +5,31 @@ Paravirt_ops ============ Linux provides support for different hypervisor virtualization technologies. -Historically different binary kernels would be required in order to support -different hypervisors, this restriction was removed with pv_ops. +Historically, different binary kernels would be required in order to support +different hypervisors; this restriction was removed with pv_ops. Linux pv_ops is a virtualization API which enables support for different hypervisors. It allows each hypervisor to override critical operations and allows a single kernel binary to run on all supported execution environments including native machine -- without any hypervisors. pv_ops provides a set of function pointers which represent operations -corresponding to low level critical instructions and high level -functionalities in various areas. pv-ops allows for optimizations at run -time by enabling binary patching of the low-ops critical operations +corresponding to low-level critical instructions and high-level +functionalities in various areas. pv_ops allows for optimizations at run +time by enabling binary patching of the low-level critical operations at boot time. pv_ops operations are classified into three categories: - simple indirect call - These operations correspond to high level functionality where it is + These operations correspond to high-level functionality where it is known that the overhead of indirect call isn't very important. - indirect call which allows optimization with binary patch - Usually these operations correspond to low level critical instructions. They + Usually these operations correspond to low-level critical instructions. They are called frequently and are performance critical. The overhead is very important. - a set of macros for hand written assembly code Hand written assembly codes (.S files) also need paravirtualization - because they include sensitive instructions or some of code paths in + because they include sensitive instructions or some code paths in them are very performance critical. diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst index af2a97429692..d1cfe415e4c4 100644 --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst @@ -1224,7 +1224,7 @@ between a driver and the host at the UML command line is OK security-wise. Allowing it as a loadable module parameter isn't. -If such functionality is desireable for a particular application +If such functionality is desirable for a particular application (e.g. loading BPF "firmware" for raw socket network transports), it should be off by default and should be explicitly turned on as a command line parameter at startup. diff --git a/Documentation/w1/slaves/w1_therm.rst b/Documentation/w1/slaves/w1_therm.rst index 758dadba84f6..6aec04dd0905 100644 --- a/Documentation/w1/slaves/w1_therm.rst +++ b/Documentation/w1/slaves/w1_therm.rst @@ -58,7 +58,7 @@ A strong pullup will be applied during the conversion if required. ``conv_time`` is used to get current conversion time (read), and adjust it (write). A temperature conversion time depends on the device type and -it's current resolution. Default conversion time is set by the driver according +its current resolution. Default conversion time is set by the driver according to the device datasheet. A conversion time for many original device clones deviate from datasheet specs. There are three options: 1) manually set the correct conversion time by writing a value in milliseconds to ``conv_time``; 2) diff --git a/Documentation/w1/w1-generic.rst b/Documentation/w1/w1-generic.rst index 99255b6d0e53..96a042585fce 100644 --- a/Documentation/w1/w1-generic.rst +++ b/Documentation/w1/w1-generic.rst @@ -101,7 +101,7 @@ w1_master_search (rw) the number of searches left to do, w1_master_slave_count (ro) the number of slaves found w1_master_slaves (ro) the names of the slaves, one per line w1_master_timeout (ro) the delay in seconds between searches -w1_master_timeout_us (ro) the delay in microseconds beetwen searches +w1_master_timeout_us (ro) the delay in microseconds between searches ========================= ===================================================== If you have a w1 bus that never changes (you don't add or remove devices), diff --git a/Documentation/w1/w1-netlink.rst b/Documentation/w1/w1-netlink.rst index aaa13243a5e4..be4f7b82dcb4 100644 --- a/Documentation/w1/w1-netlink.rst +++ b/Documentation/w1/w1-netlink.rst @@ -66,7 +66,7 @@ Each connector message can include one or more w1_netlink_msg with zero or more attached w1_netlink_cmd messages. For event messages there are no w1_netlink_cmd embedded structures, -only connector header and w1_netlink_msg strucutre with "len" field +only connector header and w1_netlink_msg structure with "len" field being zero and filled type (one of event types) and id: either 8 bytes of slave unique id in host order, or master's id, which is assigned to bus master device diff --git a/Documentation/watchdog/watchdog-kernel-api.rst b/Documentation/watchdog/watchdog-kernel-api.rst index baf44e986b07..243231fe4c0a 100644 --- a/Documentation/watchdog/watchdog-kernel-api.rst +++ b/Documentation/watchdog/watchdog-kernel-api.rst @@ -77,7 +77,7 @@ It contains following fields: * groups: List of sysfs attribute groups to create when creating the watchdog device. * info: a pointer to a watchdog_info structure. This structure gives some - additional information about the watchdog timer itself. (Like it's unique name) + additional information about the watchdog timer itself. (Like its unique name) * ops: a pointer to the list of watchdog operations that the watchdog supports. * gov: a pointer to the assigned watchdog device pretimeout governor or NULL. * timeout: the watchdog timer's timeout value (in seconds). diff --git a/Documentation/wmi/acpi-interface.rst b/Documentation/wmi/acpi-interface.rst new file mode 100644 index 000000000000..d31af0ed9c08 --- /dev/null +++ b/Documentation/wmi/acpi-interface.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +================== +ACPI WMI interface +================== + +The ACPI WMI interface is a proprietary extension of the ACPI specification made +by Microsoft to allow hardware vendors to embed WMI (Windows Management Instrumentation) +objects inside their ACPI firmware. Typical functions implemented over ACPI WMI +are hotkey events on modern notebooks and configuration of BIOS options. + +PNP0C14 ACPI device +------------------- + +Discovery of WMI objects is handled by defining ACPI devices with a PNP ID +of ``PNP0C14``. These devices will contain a set of ACPI buffers and methods +used for mapping and execution of WMI methods and/or queries. If there exist +multiple of such devices, then each device is required to have a +unique ACPI UID. + +_WDG buffer +----------- + +The ``_WDG`` buffer is used to discover WMI objects and is required to be +static. Its internal structure consists of data blocks with a size of 20 bytes, +containing the following data: + +======= =============== ===================================================== +Offset Size (in bytes) Content +======= =============== ===================================================== +0x00 16 128 bit Variant 2 object GUID. +0x10 2 2 character method ID or single byte notification ID. +0x12 1 Object instance count. +0x13 1 Object flags. +======= =============== ===================================================== + +The WMI object flags control whether the method or notification ID is used: + +- 0x1: Data block usage is expensive and must be explicitly enabled/disabled. +- 0x2: Data block contains WMI methods. +- 0x4: Data block contains ASCIZ string. +- 0x8: Data block describes a WMI event, use notification ID instead + of method ID. + +Each WMI object GUID can appear multiple times inside a system. +The method/notification ID is used to construct the ACPI method names used for +interacting with the WMI object. + +WQxx ACPI methods +----------------- + +If a data block does not contain WMI methods, then its content can be retrieved +by this required ACPI method. The last two characters of the ACPI method name +are the method ID of the data block to query. Their single parameter is an +integer describing the instance which should be queried. This parameter can be +omitted if the data block contains only a single instance. + +WSxx ACPI methods +----------------- + +Similar to the ``WQxx`` ACPI methods, except that it is optional and takes an +additional buffer as its second argument. The instance argument also cannot +be omitted. + +WMxx ACPI methods +----------------- + +Used for executing WMI methods associated with a data block. The last two +characters of the ACPI method name are the method ID of the data block +containing the WMI methods. Their first parameter is a integer describing the +instance which methods should be executed. The second parameter is an integer +describing the WMI method ID to execute, and the third parameter is a buffer +containing the WMI method parameters. If the data block is marked as containing +an ASCIZ string, then this buffer should contain an ASCIZ string. The ACPI +method will return the result of the executed WMI method. + +WExx ACPI methods +----------------- + +Used for optionally enabling/disabling WMI events, the last two characters of +the ACPI method are the notification ID of the data block describing the WMI +event as hexadecimal value. Their first parameter is an integer with a value +of 0 if the WMI event should be disabled, other values will enable +the WMI event. + +WCxx ACPI methods +----------------- +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. + +_WED ACPI method +---------------- + +Used to retrieve additional WMI event data, its single parameter is a integer +holding the notification ID of the event. diff --git a/Documentation/wmi/devices/dell-wmi-ddv.rst b/Documentation/wmi/devices/dell-wmi-ddv.rst new file mode 100644 index 000000000000..2fcdfcf03327 --- /dev/null +++ b/Documentation/wmi/devices/dell-wmi-ddv.rst @@ -0,0 +1,297 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +============================================ +Dell DDV WMI interface driver (dell-wmi-ddv) +============================================ + +Introduction +============ + +Many Dell notebooks made after ~2020 support a WMI-based interface for +retrieving various system data like battery temperature, ePPID, diagostic data +and fan/thermal sensor data. + +This interface is likely used by the `Dell Data Vault` software on Windows, +so it was called `DDV`. Currently the ``dell-wmi-ddv`` driver supports +version 2 and 3 of the interface, with support for new interface versions +easily added. + +.. warning:: The interface is regarded as internal by Dell, so no vendor + documentation is available. All knowledge was thus obtained by + trial-and-error, please keep that in mind. + +Dell ePPID (electronic Piece Part Identification) +================================================= + +The Dell ePPID is used to uniquely identify components in Dell machines, +including batteries. It has a form similar to `CC-PPPPPP-MMMMM-YMD-SSSS-FFF` +and contains the following information: + +* Country code of origin (CC). +* Part number with the first character being a filling number (PPPPPP). +* Manufacture Identification (MMMMM). +* Manufacturing Year/Month/Date (YMD) in base 36, with Y being the last digit + of the year. +* Manufacture Sequence Number (SSSS). +* Optional Firmware Version/Revision (FFF). + +The `eppidtool <https://pypi.org/project/eppidtool>`_ python utility can be used +to decode and display this information. + +All information regarding the Dell ePPID was gathered using Dell support +documentation and `this website <https://telcontar.net/KBK/Dell/date_codes>`_. + +WMI interface description +========================= + +The WMI interface description can be decoded from the embedded binary MOF (bmof) +data using the `bmfdec <https://github.com/pali/bmfdec>`_ utility: + +:: + + [WMI, Dynamic, Provider("WmiProv"), Locale("MS\\0x409"), Description("WMI Function"), guid("{8A42EA14-4F2A-FD45-6422-0087F7A7E608}")] + class DDVWmiMethodFunction { + [key, read] string InstanceName; + [read] boolean Active; + + [WmiMethodId(1), Implemented, read, write, Description("Return Battery Design Capacity.")] void BatteryDesignCapacity([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(2), Implemented, read, write, Description("Return Battery Full Charge Capacity.")] void BatteryFullChargeCapacity([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(3), Implemented, read, write, Description("Return Battery Manufacture Name.")] void BatteryManufactureName([in] uint32 arg2, [out] string argr); + [WmiMethodId(4), Implemented, read, write, Description("Return Battery Manufacture Date.")] void BatteryManufactureDate([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(5), Implemented, read, write, Description("Return Battery Serial Number.")] void BatterySerialNumber([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(6), Implemented, read, write, Description("Return Battery Chemistry Value.")] void BatteryChemistryValue([in] uint32 arg2, [out] string argr); + [WmiMethodId(7), Implemented, read, write, Description("Return Battery Temperature.")] void BatteryTemperature([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(8), Implemented, read, write, Description("Return Battery Current.")] void BatteryCurrent([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(9), Implemented, read, write, Description("Return Battery Voltage.")] void BatteryVoltage([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(10), Implemented, read, write, Description("Return Battery Manufacture Access(MA code).")] void BatteryManufactureAceess([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(11), Implemented, read, write, Description("Return Battery Relative State-Of-Charge.")] void BatteryRelativeStateOfCharge([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(12), Implemented, read, write, Description("Return Battery Cycle Count")] void BatteryCycleCount([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(13), Implemented, read, write, Description("Return Battery ePPID")] void BatteryePPID([in] uint32 arg2, [out] string argr); + [WmiMethodId(14), Implemented, read, write, Description("Return Battery Raw Analytics Start")] void BatteryeRawAnalyticsStart([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(15), Implemented, read, write, Description("Return Battery Raw Analytics")] void BatteryeRawAnalytics([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]); + [WmiMethodId(16), Implemented, read, write, Description("Return Battery Design Voltage.")] void BatteryDesignVoltage([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(17), Implemented, read, write, Description("Return Battery Raw Analytics A Block")] void BatteryeRawAnalyticsABlock([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]); + [WmiMethodId(18), Implemented, read, write, Description("Return Version.")] void ReturnVersion([in] uint32 arg2, [out] uint32 argr); + [WmiMethodId(32), Implemented, read, write, Description("Return Fan Sensor Information")] void FanSensorInformation([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]); + [WmiMethodId(34), Implemented, read, write, Description("Return Thermal Sensor Information")] void ThermalSensorInformation([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]); + }; + +Each WMI method takes an ACPI buffer containing a 32-bit index as input argument, +with the first 8 bit being used to specify the battery when using battery-related +WMI methods. Other WMI methods may ignore this argument or interpret it +differently. The WMI method output format varies: + +* if the function has only a single output, then an ACPI object + of the corresponding type is returned +* if the function has multiple outputs, when an ACPI package + containing the outputs in the same order is returned + +The format of the output should be thoroughly checked, since many methods can +return malformed data in case of an error. + +The data format of many battery-related methods seems to be based on the +`Smart Battery Data Specification`, so unknown battery-related methods are +likely to follow this standard in some way. + +WMI method GetBatteryDesignCapacity() +------------------------------------- + +Returns the design capacity of the battery in mAh as an u16. + +WMI method BatteryFullCharge() +------------------------------ + +Returns the full charge capacity of the battery in mAh as an u16. + +WMI method BatteryManufactureName() +----------------------------------- + +Returns the manufacture name of the battery as an ASCII string. + +WMI method BatteryManufactureDate() +----------------------------------- + +Returns the manufacture date of the battery as an u16. +The date is encoded in the following manner: + +- bits 0 to 4 contain the manufacture day. +- bits 5 to 8 contain the manufacture month. +- bits 9 to 15 contain the manufacture year biased by 1980. + +.. note:: + The data format needs to be verified on more machines. + +WMI method BatterySerialNumber() +-------------------------------- + +Returns the serial number of the battery as an u16. + +WMI method BatteryChemistryValue() +---------------------------------- + +Returns the chemistry of the battery as an ASCII string. +Known values are: + +- "Li-I" for Li-Ion + +WMI method BatteryTemperature() +------------------------------- + +Returns the temperature of the battery in tenth degree kelvin as an u16. + +WMI method BatteryCurrent() +--------------------------- + +Returns the current flow of the battery in mA as an s16. +Negative values indicate discharging. + +WMI method BatteryVoltage() +--------------------------- + +Returns the voltage flow of the battery in mV as an u16. + +WMI method BatteryManufactureAccess() +------------------------------------- + +Returns a manufacture-defined value as an u16. + +WMI method BatteryRelativeStateOfCharge() +----------------------------------------- + +Returns the capacity of the battery in percent as an u16. + +WMI method BatteryCycleCount() +------------------------------ + +Returns the cycle count of the battery as an u16. + +WMI method BatteryePPID() +------------------------- + +Returns the ePPID of the battery as an ASCII string. + +WMI method BatteryeRawAnalyticsStart() +-------------------------------------- + +Performs an analysis of the battery and returns a status code: + +- ``0x0``: Success +- ``0x1``: Interface not supported +- ``0xfffffffe``: Error/Timeout + +.. note:: + The meaning of this method is still largely unknown. + +WMI method BatteryeRawAnalytics() +--------------------------------- + +Returns a buffer usually containing 12 blocks of analytics data. +Those blocks contain: + +- a block number starting with 0 (u8) +- 31 bytes of unknown data + +.. note:: + The meaning of this method is still largely unknown. + +WMI method BatteryDesignVoltage() +--------------------------------- + +Returns the design voltage of the battery in mV as an u16. + +WMI method BatteryeRawAnalyticsABlock() +--------------------------------------- + +Returns a single block of analytics data, with the second byte +of the index being used for selecting the block number. + +*Supported since WMI interface version 3!* + +.. note:: + The meaning of this method is still largely unknown. + +WMI method ReturnVersion() +-------------------------- + +Returns the WMI interface version as an u32. + +WMI method FanSensorInformation() +--------------------------------- + +Returns a buffer containing fan sensor entries, terminated +with a single ``0xff``. +Those entries contain: + +- fan type (u8) +- fan speed in RPM (little endian u16) + +WMI method ThermalSensorInformation() +------------------------------------- + +Returns a buffer containing thermal sensor entries, terminated +with a single ``0xff``. +Those entries contain: + +- thermal type (u8) +- current temperature (s8) +- min. temperature (s8) +- max. temperature (s8) +- unknown field (u8) + +.. note:: + TODO: Find out what the meaning of the last byte is. + +ACPI battery matching algorithm +=============================== + +The algorithm used to match ACPI batteries to indices is based on information +which was found inside the logging messages of the OEM software. + +Basically for each new ACPI battery, the serial numbers of the batteries behind +indices 1 till 3 are compared with the serial number of the ACPI battery. +Since the serial number of the ACPI battery can either be encoded as a normal +integer or as a hexadecimal value, both cases need to be checked. The first +index with a matching serial number is then selected. + +A serial number of 0 indicates that the corresponding index is not associated +with an actual battery, or that the associated battery is not present. + +Some machines like the Dell Inspiron 3505 only support a single battery and thus +ignore the battery index. Because of this the driver depends on the ACPI battery +hook mechanism to discover batteries. + +.. note:: + The ACPI battery matching algorithm currently used inside the driver is + outdated and does not match the algorithm described above. The reasons for + this are differences in the handling of the ToHexString() ACPI opcode between + Linux and Windows, which distorts the serial number of ACPI batteries on many + machines. Until this issue is resolved, the driver cannot use the above + algorithm. + +Reverse-Engineering the DDV WMI interface +========================================= + +1. Find a supported Dell notebook, usually made after ~2020. +2. Dump the ACPI tables and search for the WMI device (usually called "ADDV"). +3. Decode the corresponding bmof data and look at the ASL code. +4. Try to deduce the meaning of a certain WMI method by comparing the control + flow with other ACPI methods (_BIX or _BIF for battery related methods + for example). +5. Use the built-in UEFI diagostics to view sensor types/values for fan/thermal + related methods (sometimes overwriting static ACPI data fields can be used + to test different sensor type values, since on some machines this data is + not reinitialized upon a warm reset). + +Alternatively: + +1. Load the ``dell-wmi-ddv`` driver, use the ``force`` module param + if necessary. +2. Use the debugfs interface to access the raw fan/thermal sensor buffer data. +3. Compare the data with the built-in UEFI diagnostics. + +In case the DDV WMI interface version available on your Dell notebook is not +supported or you are seeing unknown fan/thermal sensors, please submit a +bugreport on `bugzilla <https://bugzilla.kernel.org>`_ so they can be added +to the ``dell-wmi-ddv`` driver. + +See Documentation/admin-guide/reporting-issues.rst for further information. diff --git a/Documentation/wmi/devices/index.rst b/Documentation/wmi/devices/index.rst new file mode 100644 index 000000000000..c08735a9d7df --- /dev/null +++ b/Documentation/wmi/devices/index.rst @@ -0,0 +1,22 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +============================= +Driver-specific Documentation +============================= + +This section provides information about various devices supported by +the Linux kernel, their protocols and driver details. + +.. toctree:: + :maxdepth: 1 + :numbered: + :glob: + + * + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/wmi/devices/wmi-bmof.rst b/Documentation/wmi/devices/wmi-bmof.rst new file mode 100644 index 000000000000..ca1ee9a29be3 --- /dev/null +++ b/Documentation/wmi/devices/wmi-bmof.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +============================== +WMI embedded Binary MOF driver +============================== + +Introduction +============ + +Many machines embed WMI Binary MOF (Managed Object Format) metadata used to +describe the details of their ACPI WMI interfaces. The data can be decoded +with tools like `bmfdec <https://github.com/pali/bmfdec>`_ to obtain a +human readable WMI interface description, which is useful for developing +new WMI drivers. + +The Binary MOF data can be retrieved from the ``bmof`` sysfs attribute of the +associated WMI device. Please note that multiple WMI devices containing Binary +MOF data can exist on a given system. + +WMI interface +============= + +The Binary MOF WMI device is identified by the WMI GUID ``05901221-D566-11D1-B2F0-00A0C9062910``. +The Binary MOF can be obtained by doing a WMI data block query. The result is +then returned as an ACPI buffer with a variable size. diff --git a/Documentation/wmi/index.rst b/Documentation/wmi/index.rst new file mode 100644 index 000000000000..537cff188e14 --- /dev/null +++ b/Documentation/wmi/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +============= +WMI Subsystem +============= + +.. toctree:: + :maxdepth: 1 + + acpi-interface + devices/index + +.. only:: subproject and html + + + Indices + ======= + + * :ref:`genindex` |