diff options
author | Thomas Zimmermann <tzimmermann@suse.de> | 2023-10-11 10:50:59 +0300 |
---|---|---|
committer | Thomas Zimmermann <tzimmermann@suse.de> | 2023-10-11 10:50:59 +0300 |
commit | 57390019b68b83f96eb98f490367b9df1f2d77cb (patch) | |
tree | e6d4b6c75efdd2d7fb7d37f980688c491be3ff6a /Documentation | |
parent | e5f9d543419c78ac58f3b3557bc5a76b20ff600b (diff) | |
parent | 389af786f92ecdff35883551d54bf4e507ffcccb (diff) | |
download | linux-57390019b68b83f96eb98f490367b9df1f2d77cb.tar.xz |
Merge drm/drm-next into drm-misc-next
Updating drm-misc-next to the state of Linux v6.6-rc2.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Diffstat (limited to 'Documentation')
1226 files changed, 25365 insertions, 9222 deletions
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 index a786504b6027..2881244e3f09 100644 --- a/Documentation/ABI/stable/sysfs-platform-wmi-bmof +++ b/Documentation/ABI/stable/sysfs-platform-wmi-bmof @@ -2,6 +2,6 @@ What: /sys/bus/wmi/devices/05901221-D566-11D1-B2F0-00A0C9062910[-X]/bmof Date: Jun 2017 KernelVersion: 4.13 Description: - Binary MOF metadata used to decribe the details of available ACPI WMI interfaces. + 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-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-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 dc3b3a5c876b..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 diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 6350dd82b9a9..087f762ebfd5 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -82,7 +82,12 @@ Description: 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 not be actively decoding any HPA ranges. + 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 @@ -92,7 +97,13 @@ 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. + 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/ 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 be663258b9b7..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 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 1b3ecae80b3d..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. @@ -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-trigger-netdev b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev index 78b62a23b14a..f6d9d72ce77b 100644 --- a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev @@ -13,7 +13,7 @@ Description: Specifies the duration of the LED blink in milliseconds. Defaults to 50 ms. - With hw_control ON, the interval value MUST be set to the + 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. @@ -44,8 +44,8 @@ Description: If set to 1, the LED will blink for the milliseconds specified in interval to signal transmission. - With hw_control ON, the blink interval is controlled by hardware - and won't reflect the value set in interval. + 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 @@ -59,21 +59,21 @@ Description: If set to 1, the LED will blink for the milliseconds specified in interval to signal reception. - With hw_control ON, the blink interval is controlled by hardware - and won't reflect the value set in interval. + 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>/hw_control +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 driven by hardware - or software fallback is used. + 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 is using hardware control to blink and signal the - requested modes. + If 1, the LED blinking in requested mode is offloaded to + hardware. What: /sys/class/leds/<led>/link_10 Date: Jun 2023 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-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-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 ecd585ca2d50..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 @@ -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-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-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 e487f969a15e..0c7efaf62de0 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -1437,180 +1437,6 @@ Description: If avail_wb_buff < wb_flush_threshold, it indicates that WriteBooster buffer needs to be flushed, otherwise it is not necessary. -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. - Contact: Daniil Lunev <dlunev@chromium.org> What: /sys/bus/platform/drivers/ufshcd/*/capabilities/ What: /sys/bus/platform/devices/*.ufs/capabilities/ @@ -1648,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-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-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 4c5c02d8f870..65ed3865da62 100644 --- a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl +++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl @@ -84,3 +84,69 @@ 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/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst index c237596f67e3..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,7 +362,7 @@ 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 Documentation/powerpc/eeh-pci-error-recovery.rst for additional detail on real-life experience of the causes of 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/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/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/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 fabaad3fd9c2..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. @@ -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 4ef890191196..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 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 a1457995fd41..0a1731a0f0ef 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -418,20 +418,20 @@ 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.nomops [ARM64] Unconditionally disable Memory Copy and Memory - Set instructions support + arm64.nosve [ARM64] Unconditionally disable Scalable Vector + Extension support ataflop= [HW,M68k] @@ -553,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} @@ -598,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 @@ -696,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 @@ -706,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 @@ -862,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. @@ -875,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 @@ -893,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. @@ -1623,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. @@ -2624,7 +2656,7 @@ kvm-intel.flexpriority= [KVM,Intel] Control KVM's use of FlexPriority feature - (TPR shadow). Default is 1 (enabled). Disalbe by KVM if + (TPR shadow). Default is 1 (enabled). Disable by KVM if hardware lacks support for it. kvm-intel.nested= @@ -2918,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. @@ -3105,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 @@ -3273,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 @@ -3717,7 +3754,7 @@ nohibernate [HIBERNATION] Disable hibernation and resume. - nohlt [ARM,ARM64,MICROBLAZE,MIPS,SH] Forces the kernel to + 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 @@ -3853,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,MIPS,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. @@ -4037,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 @@ -4067,6 +4090,20 @@ 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#> @@ -4186,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. @@ -4928,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. @@ -4953,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 @@ -4967,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] @@ -4983,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. @@ -5264,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 @@ -5293,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 @@ -5468,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] @@ -5501,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, @@ -5875,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) @@ -6243,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 @@ -6308,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 @@ -6607,7 +6719,7 @@ 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) @@ -6964,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 @@ -6985,15 +7104,6 @@ threshold repeatedly. They are likely good candidates for using WQ_UNBOUND workqueues instead. - 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.power_efficient Per-cpu workqueues are generally preferred because they show better performance thanks to cache @@ -7009,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/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index 2d495fa85a0e..8da1b7281827 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -87,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 │ │ │ │ │ │ │ │ ... │ │ │ │ │ │ ... @@ -99,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/ @@ -127,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. @@ -359,15 +363,21 @@ 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``.:: @@ -381,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: @@ -397,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. @@ -406,13 +422,21 @@ 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 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/alibaba_pmu.rst b/Documentation/admin-guide/perf/alibaba_pmu.rst index 11de998bb480..7d840023903f 100644 --- a/Documentation/admin-guide/perf/alibaba_pmu.rst +++ b/Documentation/admin-guide/perf/alibaba_pmu.rst @@ -88,6 +88,11 @@ data bandwidth:: -e ali_drw_27080/hif_rmw/ \ -e ali_drw_27080/cycle/ -- sleep 10 +Example usage of counting all memory read/write bandwidth by metric:: + + perf stat -M ddr_read_bandwidth.all -- sleep 10 + perf stat -M ddr_write_bandwidth.all -- sleep 10 + The average DRAM bandwidth can be calculated as follows: - Read Bandwidth = perf_hif_rd * DDRC_WIDTH * DDRC_Freq / DDRC_Cycle 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 3800fab1619b..cf33de56da27 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -450,6 +450,35 @@ this allows system administrators to override the ``IA64_THREAD_UAC_NOPRINT`` ``prctl`` and avoid logs being flooded. +io_uring_disabled +================= + +Prevents all processes from creating new io_uring instances. Enabling this +shrinks the kernel's attack surface. + += ====================================================================== +0 All processes can create io_uring instances as normal. This is the + default setting. +1 io_uring creation is disabled (io_uring_setup() will fail with + -EPERM) for unprivileged processes not in the io_uring_group group. + Existing io_uring instances can still be used. See the + documentation for io_uring_group for more information. +2 io_uring creation is disabled for all processes. io_uring_setup() + always fails with -EPERM. Existing io_uring instances can still be + used. += ====================================================================== + + +io_uring_group +============== + +When io_uring_disabled is set to 1, a process must either be +privileged (CAP_SYS_ADMIN) or be in the io_uring_group group in order +to create an io_uring instance. If io_uring_group is set to -1 (the +default), only processes with the CAP_SYS_ADMIN capability may create +io_uring instances. + + kexec_load_disabled =================== @@ -941,16 +970,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). +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/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/arch/arm/arm.rst b/Documentation/arch/arm/arm.rst index 99d660fdf73f..7b41b89dd9bd 100644 --- a/Documentation/arch/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/arch/arm/ixp4xx.rst b/Documentation/arch/arm/ixp4xx.rst index a57235616294..17aafc610908 100644 --- a/Documentation/arch/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/arch/arm/sunxi/clocks.rst b/Documentation/arch/arm/sunxi/clocks.rst index 23bd03f3e21f..dfe6d4887210 100644 --- a/Documentation/arch/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/arch/arm/swp_emulation.rst b/Documentation/arch/arm/swp_emulation.rst index 6a608a9c3715..bf205e3de36e 100644 --- a/Documentation/arch/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/arch/arm/tcm.rst b/Documentation/arch/arm/tcm.rst index 1dc6c39220f9..7ce17a248af9 100644 --- a/Documentation/arch/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/arch/arm/uefi.rst b/Documentation/arch/arm/uefi.rst index baebe688a006..2b7ad9bd7cd2 100644 --- a/Documentation/arch/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/arch/arm/vlocks.rst b/Documentation/arch/arm/vlocks.rst index a40a1742110b..737aa8661a21 100644 --- a/Documentation/arch/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/arch/arm64/acpi_object_usage.rst b/Documentation/arch/arm64/acpi_object_usage.rst index 1da22200fdf8..06d8a87971ef 100644 --- a/Documentation/arch/arm64/acpi_object_usage.rst +++ b/Documentation/arch/arm64/acpi_object_usage.rst @@ -45,7 +45,7 @@ APMT Signature Reserved (signature == "APMT") **Arm Performance Monitoring Table** - This table describes the properties of PMU support implmented by + This table describes the properties of PMU support implemented by components in the system. BERT Section 18.3 (signature == "BERT") diff --git a/Documentation/arch/arm64/arm-acpi.rst b/Documentation/arch/arm64/arm-acpi.rst index 94274a8d84cf..a46c34fa9604 100644 --- a/Documentation/arch/arm64/arm-acpi.rst +++ b/Documentation/arch/arm64/arm-acpi.rst @@ -99,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 diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst index 496cdca5cb99..e96f057ea2a0 100644 --- a/Documentation/arch/arm64/silicon-errata.rst +++ b/Documentation/arch/arm64/silicon-errata.rst @@ -63,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 | @@ -109,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 | @@ -148,6 +148,9 @@ stable kernels. | ARM | MMU-700 | #2268618,2812531| N/A | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ +| ARM | GIC-700 | #2941627 | ARM64_ERRATUM_2941627 | ++----------------+-----------------+-----------------+-----------------------------+ ++----------------+-----------------+-----------------+-----------------------------+ | Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_845719 | +----------------+-----------------+-----------------+-----------------------------+ | Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 | @@ -195,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 | +----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/arch/arm64/sme.rst b/Documentation/arch/arm64/sme.rst index ba529a1dc606..3d0e53ecac4f 100644 --- a/Documentation/arch/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 diff --git a/Documentation/arch/index.rst b/Documentation/arch/index.rst index 8458b88e9b79..84b80255b851 100644 --- a/Documentation/arch/index.rst +++ b/Documentation/arch/index.rst @@ -13,15 +13,15 @@ implementation. 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/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/btf.rst b/Documentation/bpf/btf.rst index 7cd7c5415a99..e43c2fdafcd7 100644 --- a/Documentation/bpf/btf.rst +++ b/Documentation/bpf/btf.rst @@ -726,8 +726,8 @@ same as the one describe in :ref:`BTF_Type_String`. 4.2 .BTF.ext section -------------------- -The .BTF.ext section encodes func_info and line_info which needs loader -manipulation before loading into the kernel. +The .BTF.ext section encodes func_info, line_info and CO-RE relocations +which needs loader manipulation before loading into the kernel. The specification for .BTF.ext section is defined at ``tools/lib/bpf/btf.h`` and ``tools/lib/bpf/btf.c``. @@ -745,15 +745,20 @@ The current header of .BTF.ext section:: __u32 func_info_len; __u32 line_info_off; __u32 line_info_len; + + /* optional part of .BTF.ext header */ + __u32 core_relo_off; + __u32 core_relo_len; }; It is very similar to .BTF section. Instead of type/string section, it -contains func_info and line_info section. See :ref:`BPF_Prog_Load` for details -about func_info and line_info record format. +contains func_info, line_info and core_relo sub-sections. +See :ref:`BPF_Prog_Load` for details about func_info and line_info +record format. The func_info is organized as below.:: - func_info_rec_size + func_info_rec_size /* __u32 value */ btf_ext_info_sec for section #1 /* func_info for section #1 */ btf_ext_info_sec for section #2 /* func_info for section #2 */ ... @@ -773,7 +778,7 @@ Here, num_info must be greater than 0. The line_info is organized as below.:: - line_info_rec_size + line_info_rec_size /* __u32 value */ btf_ext_info_sec for section #1 /* line_info for section #1 */ btf_ext_info_sec for section #2 /* line_info for section #2 */ ... @@ -787,6 +792,20 @@ kernel API, the ``insn_off`` is the instruction offset in the unit of ``struct bpf_insn``. For ELF API, the ``insn_off`` is the byte offset from the beginning of section (``btf_ext_info_sec->sec_name_off``). +The core_relo is organized as below.:: + + core_relo_rec_size /* __u32 value */ + btf_ext_info_sec for section #1 /* core_relo for section #1 */ + btf_ext_info_sec for section #2 /* core_relo for section #2 */ + +``core_relo_rec_size`` specifies the size of ``bpf_core_relo`` +structure when .BTF.ext is generated. All ``bpf_core_relo`` structures +within a single ``btf_ext_info_sec`` describe relocations applied to +section named by ``btf_ext_info_sec->sec_name_off``. + +See :ref:`Documentation/bpf/llvm_reloc.rst <btf-co-re-relocations>` +for more information on CO-RE relocations. + 4.2 .BTF_ids section -------------------- @@ -990,7 +1009,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 +1019,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 3139c7c02e79..a22b6ad105fb 100644 --- a/Documentation/bpf/cpumasks.rst +++ b/Documentation/bpf/cpumasks.rst @@ -364,7 +364,7 @@ can be used to query the contents of cpumasks. ---- 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..aeaeb35e6d4a 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 diff --git a/Documentation/bpf/linux-notes.rst b/Documentation/bpf/linux-notes.rst index 508d009d3bed..00d2693de025 100644 --- a/Documentation/bpf/linux-notes.rst +++ b/Documentation/bpf/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/bpf/llvm_reloc.rst b/Documentation/bpf/llvm_reloc.rst index e4a777a6a3a2..44188e219d32 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 @@ -157,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: @@ -203,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``:: @@ -240,3 +240,307 @@ The .BTF/.BTF.ext sections has R_BPF_64_NODYLD32 relocations:: Offset Info Type Symbol's Value Symbol's Name 000000000000002c 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text 0000000000000040 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text + +.. _btf-co-re-relocations: + +================= +CO-RE Relocations +================= + +From object file point of view CO-RE mechanism is implemented as a set +of CO-RE specific relocation records. These relocation records are not +related to ELF relocations and are encoded in .BTF.ext section. +See :ref:`Documentation/bpf/btf.rst <BTF_Ext_Section>` for more +information on .BTF.ext structure. + +CO-RE relocations are applied to BPF instructions to update immediate +or offset fields of the instruction at load time with information +relevant for target kernel. + +Field to patch is selected basing on the instruction class: + +* For BPF_ALU, BPF_ALU64, BPF_LD `immediate` field is patched; +* For BPF_LDX, BPF_STX, BPF_ST `offset` field is patched; +* BPF_JMP, BPF_JMP32 instructions **should not** be patched. + +Relocation kinds +================ + +There are several kinds of CO-RE relocations that could be split in +three groups: + +* Field-based - patch instruction with field related information, e.g. + change offset field of the BPF_LDX instruction to reflect offset + of a specific structure field in the target kernel. + +* Type-based - patch instruction with type related information, e.g. + change immediate field of the BPF_ALU move instruction to 0 or 1 to + reflect if specific type is present in the target kernel. + +* Enum-based - patch instruction with enum related information, e.g. + change immediate field of the BPF_LD_IMM64 instruction to reflect + value of a specific enum literal in the target kernel. + +The complete list of relocation kinds is represented by the following enum: + +.. code-block:: c + + enum bpf_core_relo_kind { + BPF_CORE_FIELD_BYTE_OFFSET = 0, /* field byte offset */ + BPF_CORE_FIELD_BYTE_SIZE = 1, /* field size in bytes */ + BPF_CORE_FIELD_EXISTS = 2, /* field existence in target kernel */ + BPF_CORE_FIELD_SIGNED = 3, /* field signedness (0 - unsigned, 1 - signed) */ + BPF_CORE_FIELD_LSHIFT_U64 = 4, /* bitfield-specific left bitshift */ + BPF_CORE_FIELD_RSHIFT_U64 = 5, /* bitfield-specific right bitshift */ + BPF_CORE_TYPE_ID_LOCAL = 6, /* type ID in local BPF object */ + BPF_CORE_TYPE_ID_TARGET = 7, /* type ID in target kernel */ + BPF_CORE_TYPE_EXISTS = 8, /* type existence in target kernel */ + BPF_CORE_TYPE_SIZE = 9, /* type size in bytes */ + BPF_CORE_ENUMVAL_EXISTS = 10, /* enum value existence in target kernel */ + BPF_CORE_ENUMVAL_VALUE = 11, /* enum value integer value */ + BPF_CORE_TYPE_MATCHES = 12, /* type match in target kernel */ + }; + +Notes: + +* ``BPF_CORE_FIELD_LSHIFT_U64`` and ``BPF_CORE_FIELD_RSHIFT_U64`` are + supposed to be used to read bitfield values using the following + algorithm: + + .. code-block:: c + + // To read bitfield ``f`` from ``struct s`` + is_signed = relo(s->f, BPF_CORE_FIELD_SIGNED) + off = relo(s->f, BPF_CORE_FIELD_BYTE_OFFSET) + sz = relo(s->f, BPF_CORE_FIELD_BYTE_SIZE) + l = relo(s->f, BPF_CORE_FIELD_LSHIFT_U64) + r = relo(s->f, BPF_CORE_FIELD_RSHIFT_U64) + // define ``v`` as signed or unsigned integer of size ``sz`` + v = *({s|u}<sz> *)((void *)s + off) + v <<= l + v >>= r + +* The ``BPF_CORE_TYPE_MATCHES`` queries matching relation, defined as + follows: + + * for integers: types match if size and signedness match; + * for arrays & pointers: target types are recursively matched; + * for structs & unions: + + * local members need to exist in target with the same name; + + * for each member we recursively check match unless it is already behind a + pointer, in which case we only check matching names and compatible kind; + + * for enums: + + * local variants have to have a match in target by symbolic name (but not + numeric value); + + * size has to match (but enum may match enum64 and vice versa); + + * for function pointers: + + * number and position of arguments in local type has to match target; + * for each argument and the return value we recursively check match. + +CO-RE Relocation Record +======================= + +Relocation record is encoded as the following structure: + +.. code-block:: c + + struct bpf_core_relo { + __u32 insn_off; + __u32 type_id; + __u32 access_str_off; + enum bpf_core_relo_kind kind; + }; + +* ``insn_off`` - instruction offset (in bytes) within a code section + associated with this relocation; + +* ``type_id`` - BTF type ID of the "root" (containing) entity of a + relocatable type or field; + +* ``access_str_off`` - offset into corresponding .BTF string section. + String interpretation depends on specific relocation kind: + + * for field-based relocations, string encodes an accessed field using + a sequence of field and array indices, separated by colon (:). It's + conceptually very close to LLVM's `getelementptr <GEP_>`_ instruction's + arguments for identifying offset to a field. For example, consider the + following C code: + + .. code-block:: c + + struct sample { + int a; + int b; + struct { int c[10]; }; + } __attribute__((preserve_access_index)); + struct sample *s; + + * Access to ``s[0].a`` would be encoded as ``0:0``: + + * ``0``: first element of ``s`` (as if ``s`` is an array); + * ``0``: index of field ``a`` in ``struct sample``. + + * Access to ``s->a`` would be encoded as ``0:0`` as well. + * Access to ``s->b`` would be encoded as ``0:1``: + + * ``0``: first element of ``s``; + * ``1``: index of field ``b`` in ``struct sample``. + + * Access to ``s[1].c[5]`` would be encoded as ``1:2:0:5``: + + * ``1``: second element of ``s``; + * ``2``: index of anonymous structure field in ``struct sample``; + * ``0``: index of field ``c`` in anonymous structure; + * ``5``: access to array element #5. + + * for type-based relocations, string is expected to be just "0"; + + * for enum value-based relocations, string contains an index of enum + value within its enum type; + +* ``kind`` - one of ``enum bpf_core_relo_kind``. + +.. _GEP: https://llvm.org/docs/LangRef.html#getelementptr-instruction + +.. _btf_co_re_relocation_examples: + +CO-RE Relocation Examples +========================= + +For the following C code: + +.. code-block:: c + + struct foo { + int a; + int b; + unsigned c:15; + } __attribute__((preserve_access_index)); + + enum bar { U, V }; + +With the following BTF definitions: + +.. code-block:: + + ... + [2] STRUCT 'foo' size=8 vlen=2 + 'a' type_id=3 bits_offset=0 + 'b' type_id=3 bits_offset=32 + 'c' type_id=4 bits_offset=64 bitfield_size=15 + [3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED + [4] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none) + ... + [16] ENUM 'bar' encoding=UNSIGNED size=4 vlen=2 + 'U' val=0 + 'V' val=1 + +Field offset relocations are generated automatically when +``__attribute__((preserve_access_index))`` is used, for example: + +.. code-block:: c + + void alpha(struct foo *s, volatile unsigned long *g) { + *g = s->a; + s->a = 1; + } + + 00 <alpha>: + 0: r3 = *(s32 *)(r1 + 0x0) + 00: CO-RE <byte_off> [2] struct foo::a (0:0) + 1: *(u64 *)(r2 + 0x0) = r3 + 2: *(u32 *)(r1 + 0x0) = 0x1 + 10: CO-RE <byte_off> [2] struct foo::a (0:0) + 3: exit + + +All relocation kinds could be requested via built-in functions. +E.g. field-based relocations: + +.. code-block:: c + + void bravo(struct foo *s, volatile unsigned long *g) { + *g = __builtin_preserve_field_info(s->b, 0 /* field byte offset */); + *g = __builtin_preserve_field_info(s->b, 1 /* field byte size */); + *g = __builtin_preserve_field_info(s->b, 2 /* field existence */); + *g = __builtin_preserve_field_info(s->b, 3 /* field signedness */); + *g = __builtin_preserve_field_info(s->c, 4 /* bitfield left shift */); + *g = __builtin_preserve_field_info(s->c, 5 /* bitfield right shift */); + } + + 20 <bravo>: + 4: r1 = 0x4 + 20: CO-RE <byte_off> [2] struct foo::b (0:1) + 5: *(u64 *)(r2 + 0x0) = r1 + 6: r1 = 0x4 + 30: CO-RE <byte_sz> [2] struct foo::b (0:1) + 7: *(u64 *)(r2 + 0x0) = r1 + 8: r1 = 0x1 + 40: CO-RE <field_exists> [2] struct foo::b (0:1) + 9: *(u64 *)(r2 + 0x0) = r1 + 10: r1 = 0x1 + 50: CO-RE <signed> [2] struct foo::b (0:1) + 11: *(u64 *)(r2 + 0x0) = r1 + 12: r1 = 0x31 + 60: CO-RE <lshift_u64> [2] struct foo::c (0:2) + 13: *(u64 *)(r2 + 0x0) = r1 + 14: r1 = 0x31 + 70: CO-RE <rshift_u64> [2] struct foo::c (0:2) + 15: *(u64 *)(r2 + 0x0) = r1 + 16: exit + + +Type-based relocations: + +.. code-block:: c + + void charlie(struct foo *s, volatile unsigned long *g) { + *g = __builtin_preserve_type_info(*s, 0 /* type existence */); + *g = __builtin_preserve_type_info(*s, 1 /* type size */); + *g = __builtin_preserve_type_info(*s, 2 /* type matches */); + *g = __builtin_btf_type_id(*s, 0 /* type id in this object file */); + *g = __builtin_btf_type_id(*s, 1 /* type id in target kernel */); + } + + 88 <charlie>: + 17: r1 = 0x1 + 88: CO-RE <type_exists> [2] struct foo + 18: *(u64 *)(r2 + 0x0) = r1 + 19: r1 = 0xc + 98: CO-RE <type_size> [2] struct foo + 20: *(u64 *)(r2 + 0x0) = r1 + 21: r1 = 0x1 + a8: CO-RE <type_matches> [2] struct foo + 22: *(u64 *)(r2 + 0x0) = r1 + 23: r1 = 0x2 ll + b8: CO-RE <local_type_id> [2] struct foo + 25: *(u64 *)(r2 + 0x0) = r1 + 26: r1 = 0x2 ll + d0: CO-RE <target_type_id> [2] struct foo + 28: *(u64 *)(r2 + 0x0) = r1 + 29: exit + +Enum-based relocations: + +.. code-block:: c + + void delta(struct foo *s, volatile unsigned long *g) { + *g = __builtin_preserve_enum_value(*(enum bar *)U, 0 /* enum literal existence */); + *g = __builtin_preserve_enum_value(*(enum bar *)V, 1 /* enum literal value */); + } + + f0 <delta>: + 30: r1 = 0x1 ll + f0: CO-RE <enumval_exists> [16] enum bar::U = 0 + 32: *(u64 *)(r2 + 0x0) = r1 + 33: r1 = 0x1 ll + 108: CO-RE <enumval_value> [16] enum bar::V = 1 + 35: *(u64 *)(r2 + 0x0) = r1 + 36: exit diff --git a/Documentation/bpf/standardization/abi.rst b/Documentation/bpf/standardization/abi.rst new file mode 100644 index 000000000000..0c2e10eeb89a --- /dev/null +++ b/Documentation/bpf/standardization/abi.rst @@ -0,0 +1,25 @@ +.. contents:: +.. sectnum:: + +=================================================== +BPF ABI Recommended Conventions and Guidelines v1.0 +=================================================== + +This is version 1.0 of an informational document containing recommended +conventions and guidelines for producing portable BPF program binaries. + +Registers and calling convention +================================ + +BPF has 10 general purpose registers and a read-only frame pointer register, +all of which are 64-bits wide. + +The BPF calling convention is defined as: + +* R0: return value from function calls, and exit value for BPF programs +* R1 - R5: arguments for function calls +* R6 - R9: callee saved registers that function calls will preserve +* R10: read-only frame pointer to access stack + +R0 - R5 are scratch registers and BPF programs needs to spill/fill them if +necessary across calls. diff --git a/Documentation/bpf/standardization/index.rst b/Documentation/bpf/standardization/index.rst new file mode 100644 index 000000000000..a50c3baf6345 --- /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 + abi + +.. 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 6644842cd3ea..c5d53a6e8c79 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -1,39 +1,106 @@ .. contents:: .. sectnum:: -======================================== -eBPF Instruction Set Specification, v1.0 -======================================== +======================================= +BPF Instruction Set Specification, v1.0 +======================================= -This document specifies version 1.0 of the eBPF instruction set. +This document specifies version 1.0 of the BPF 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. - -Registers and calling convention -================================ - -eBPF has 10 general purpose registers and a read-only frame pointer register, -all of which are 64-bits wide. - -The eBPF calling convention is defined as: - -* R0: return value from function calls, and exit value for eBPF programs -* R1 - R5: arguments for function calls -* R6 - R9: callee saved registers that function calls will preserve -* R10: read-only frame pointer to access stack - -R0 - R5 are scratch registers and eBPF programs needs to spill/fill them if -necessary across calls. +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 Instruction encoding ==================== -eBPF has two instruction encodings: +BPF has two instruction encodings: * the basic instruction encoding, which uses 64 bits to encode an instruction * the wide instruction encoding, which appends a second 64-bit immediate (i.e., @@ -154,27 +221,30 @@ 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 & mask) -BPF_RSH 0x70 dst >>= (src & mask) -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 dst >>= (src & mask) -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 +the 64-bit or 32-bit value will wrap. If BPF program execution would result in division by zero, the destination register is instead set to zero. If execution would result in modulo by zero, for ``BPF_ALU64`` the value of the destination register is unchanged whereas for ``BPF_ALU`` the upper @@ -198,47 +268,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 ----------------- @@ -249,7 +347,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 @@ -258,7 +357,7 @@ BPF_JNE 0x5 any PC += offset if dst != src BPF_JSGT 0x6 any PC += offset if dst > src signed BPF_JSGE 0x7 any PC += offset if dst >= src signed BPF_CALL 0x8 0x0 call helper function by address see `Helper functions`_ -BPF_CALL 0x8 0x1 call PC += offset see `Program-local functions`_ +BPF_CALL 0x8 0x1 call PC += imm see `Program-local functions`_ BPF_CALL 0x8 0x2 call helper function by BTF ID see `Helper functions`_ BPF_EXIT 0x9 0x0 return BPF_JMP only BPF_JLT 0xa any PC += offset if dst < src unsigned @@ -267,7 +366,7 @@ BPF_JSLT 0xc any PC += offset if dst < src signed BPF_JSLE 0xd any PC += offset if dst <= src signed ======== ===== === =========================================== ========================================= -The eBPF program needs to store the return value into register R0 before doing a +The BPF program needs to store the return value into register R0 before doing a ``BPF_EXIT``. Example: @@ -278,6 +377,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 ~~~~~~~~~~~~~~~~ @@ -296,8 +408,8 @@ Program-local functions ~~~~~~~~~~~~~~~~~~~~~~~ Program-local functions are functions exposed by the same BPF program as the caller, and are referenced by offset from the call instruction, similar to -``BPF_JA``. A ``BPF_EXIT`` within the program-local function will return to -the caller. +``BPF_JA``. The offset is encoded in the imm field of the call instruction. +A ``BPF_EXIT`` within the program-local function will return to the caller. Load and store instructions =========================== @@ -320,6 +432,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`_ ============= ===== ==================================== ============= @@ -350,18 +463,32 @@ 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 ----------------- Atomic operations are operations that operate on memory and can not be interrupted or corrupted by other access to the same memory region -by other eBPF programs or means outside of this specification. +by other BPF programs or means outside of this specification. -All atomic operations supported by eBPF are encoded as store operations +All atomic operations supported by BPF are encoded as store operations that use the ``BPF_ATOMIC`` mode modifier as follows: * ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations @@ -451,7 +578,7 @@ where Maps ~~~~ -Maps are shared memory regions accessible by eBPF programs on some platforms. +Maps are shared memory regions accessible by BPF programs on some platforms. A map can have various semantics as defined in a separate document, and may or may not have a single contiguous memory region, but the 'map_val(map)' is currently only defined for maps that do have a single contiguous memory region. @@ -473,6 +600,6 @@ identified by the given id. Legacy BPF Packet access instructions ------------------------------------- -eBPF previously introduced special instructions for access to packet data that were +BPF previously introduced special instructions for access to packet data that were carried over from classic BPF. However, these instructions are deprecated and should no longer be used. 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 e6f5bc39cf5c..9511e405aabd 100644 --- a/Documentation/core-api/cpu_hotplug.rst +++ b/Documentation/core-api/cpu_hotplug.rst @@ -395,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 @@ -588,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; .... @@ -597,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; .... @@ -606,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; .... @@ -741,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 f2bcc5a7ea43..ae92a2571388 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -162,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: 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/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/workqueue.rst b/Documentation/core-api/workqueue.rst index a4c9b9d1905f..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,27 +347,346 @@ 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 CMwake mayday rescued + 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 - - - - + 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 CMwake mayday rescued + 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 - - - - + 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 - - diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index f4acf9c2e90f..382818a7197a 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -41,8 +41,8 @@ Support Architectures ~~~~~~~~~~~~~ -Generic KASAN is supported on x86_64, arm, arm64, powerpc, riscv, s390, and -xtensa, and the tag-based KASAN modes are supported only on arm64. +Generic KASAN is supported on x86_64, arm, arm64, powerpc, riscv, s390, xtensa, +and loongarch, and the tag-based KASAN modes are supported only on arm64. Compilers ~~~~~~~~~ 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/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 08d59842655c..1c1094cd6b77 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -218,6 +218,14 @@ properties: - 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 d6c84b6e7fe6..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 --- diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml index cb78cfa56702..c960c8e0a9a5 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.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,coresight-dummy-sink.yaml# diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml index 5fedaed49a1f..6745b4cc8f1c 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.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,coresight-dummy-source.yaml# 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 cdd65881fcdd..8dd6b6446394 100644 --- a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml +++ b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml @@ -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: 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/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml index 5c3ac97e8728..4cc4e6754681 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml @@ -66,6 +66,7 @@ properties: - description: BCM47094 based boards items: - enum: + - asus,rt-ac3100 - asus,rt-ac88u - dlink,dir-885l - dlink,dir-890l 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 9e6a45eea4e5..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 @@ -158,6 +160,7 @@ properties: - arm,cortex-x1c - arm,cortex-x2 - arm,cortex-x3 + - arm,cortex-x4 - arm,neoverse-e1 - arm,neoverse-n1 - arm,neoverse-n2 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 2510eaa8906d..9450b2c8a678 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -909,6 +909,7 @@ properties: - 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 @@ -1031,10 +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 - gateworks,imx8mp-gw7905-2x # i.MX8MP Gateworks Board - - polyhex,imx8mp-debix # Polyhex Debix boards - - polyhex,imx8mp-debix-model-a # Polyhex Debix Model A 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 @@ -1068,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: @@ -1220,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: @@ -1289,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 86b59de7707e..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# 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/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/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 450f616774e0..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 @@ -72,6 +73,7 @@ description: | sdx65 sdx75 sm4250 + sm4450 sm6115 sm6115p sm6125 @@ -104,6 +106,7 @@ description: | hk10-c2 idp liquid + rdp432-c2 mtp qrd rb2 @@ -186,6 +189,7 @@ properties: - items: - enum: + - samsung,a7 - sony,kanuti-tulip - square,apq8039-t2 - const: qcom,msm8939 @@ -341,6 +345,11 @@ 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 @@ -904,6 +913,11 @@ properties: - items: - enum: + - qcom,sm4450-qrd + - const: qcom,sm4450 + + - items: + - enum: - fxtec,pro1x - const: qcom,sm6115 diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index ecdb72a519cb..ca5389862887 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -196,6 +196,11 @@ 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: @@ -222,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 @@ -694,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/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 b63ff591ef8f..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 diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 4466b455bffa..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 diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index ee8fdd2da869..e4dd678f4212 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -541,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 @@ -997,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/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 577eee95c893..03d2a0d79fb0 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -25,6 +25,12 @@ 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 @@ -72,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/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/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/cache/andestech,ax45mp-cache.yaml b/Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml new file mode 100644 index 000000000000..9ab5f0c435d4 --- /dev/null +++ b/Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (C) 2023 Renesas Electronics Corp. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cache/andestech,ax45mp-cache.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Andestech AX45MP L2 Cache Controller + +maintainers: + - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> + +description: + A level-2 cache (L2C) is used to improve the system performance by providing + a large amount of cache line entries and reasonable access delays. The L2C + is shared between cores, and a non-inclusive non-exclusive policy is used. + +select: + properties: + compatible: + contains: + enum: + - andestech,ax45mp-cache + + required: + - compatible + +properties: + compatible: + items: + - const: andestech,ax45mp-cache + - const: cache + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + cache-line-size: + const: 64 + + cache-level: + const: 2 + + cache-sets: + const: 1024 + + cache-size: + enum: [131072, 262144, 524288, 1048576, 2097152] + + cache-unified: true + + next-level-cache: true + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - cache-line-size + - cache-level + - cache-sets + - cache-size + - cache-unified + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + cache-controller@2010000 { + compatible = "andestech,ax45mp-cache", "cache"; + reg = <0x13400000 0x100000>; + interrupts = <508 IRQ_TYPE_LEVEL_HIGH>; + cache-line-size = <64>; + cache-level = <2>; + cache-sets = <1024>; + cache-size = <262144>; + cache-unified; + }; 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,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/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/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/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,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-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 ba969e7a57bf..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,7 +28,6 @@ properties: enum: - qcom,gcc-ipq6018 - qcom,gcc-mdm9607 - - 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 8bf9b6f49550..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 diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml index ff0b18bbb0fc..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 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 ead6665b9a45..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 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 a00216b3b15a..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 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,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 422f5776a771..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 @@ -297,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: @@ -309,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 267cf8c26823..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 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,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,sm8350-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml index 23505c8c3dbd..46d1d91e3a01 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml @@ -19,7 +19,9 @@ description: | properties: compatible: - const: qcom,sm8350-videocc + enum: + - qcom,sc8280xp-videocc + - qcom,sm8350-videocc clocks: items: @@ -51,7 +53,7 @@ unevaluatedProperties: 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@abf0000 { compatible = "qcom,sm8350-videocc"; @@ -59,7 +61,7 @@ examples: clocks = <&rpmhcc RPMH_CXO_CLK>, <&rpmhcc RPMH_CXO_CLK_A>, <&sleep_clk>; - power-domains = <&rpmhpd SM8350_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-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-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml index f1c6dd50f184..bad8f019a8d3 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml @@ -64,13 +64,13 @@ 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> videocc: clock-controller@aaf0000 { compatible = "qcom,sm8450-videocc"; reg = <0x0aaf0000 0x10000>; clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_VIDEO_AHB_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,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/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,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,versal-clk.yaml b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml index 5cbb34d0b61b..1ba687d433b1 100644 --- a/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml +++ b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml @@ -14,11 +14,16 @@ description: | 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 @@ -26,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 @@ -45,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 { @@ -59,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 1c4d3eb87763..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. @@ -224,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 @@ -264,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). 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/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/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 bb828068c3b8..8e665d910e6e 100644 --- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml @@ -34,6 +34,7 @@ properties: - enum: - qcom,ipq6018-qce - qcom,ipq8074-qce + - qcom,ipq9574-qce - qcom,msm8996-qce - qcom,qcm2290-qce - qcom,sdm845-qce 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/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/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/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/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/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/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 7a7cf3fb3e6d..f12558960cd8 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -28,6 +28,7 @@ properties: - qcom,sm8350-dp - items: - enum: + - qcom,sm8250-dp - qcom,sm8450-dp - qcom,sm8550-dp - const: qcom,sm8350-dp @@ -79,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 01848bdd5873..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# @@ -27,6 +27,7 @@ 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 @@ -166,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 @@ -301,6 +306,7 @@ allOf: contains: enum: - qcom,msm8998-dsi-ctrl + - qcom,sm6125-dsi-ctrl - qcom,sm6350-dsi-ctrl then: properties: 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 62fb3e484eb2..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# 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/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml index 58ca8912a8c3..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]$' 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 2fe032d0e8f8..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# diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml index db9f07c6142d..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: 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 630b11480496..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# @@ -15,6 +15,7 @@ properties: compatible: enum: - qcom,sc7180-dpu + - qcom,sm6125-dpu - qcom,sm6350-dpu - qcom,sm6375-dpu @@ -63,7 +64,9 @@ allOf: - if: properties: compatible: - const: qcom,sm6375-dpu + enum: + - qcom,sm6375-dpu + - qcom,sm6125-dpu then: properties: 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 index ed0ad194d4ce..db255b1f4c20 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-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,sm6350-mdss.yaml# @@ -131,13 +131,6 @@ examples: remote-endpoint = <&dsi0_in>; }; }; - - port@1 { - reg = <1>; - dpu_intf2_out: endpoint { - remote-endpoint = <&dsi1_in>; - }; - }; }; }; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml index 76369a4f7c4d..30d36fffaedb 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-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,sm6375-mdss.yaml# @@ -132,13 +132,6 @@ examples: remote-endpoint = <&dsi0_in>; }; }; - - port@1 { - reg = <1>; - dpu_intf2_out: endpoint { - remote-endpoint = <&dsi1_in>; - }; - }; }; }; 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 79a226e4cc6a..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: @@ -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/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/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/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-mipi-dbi-spi.yaml b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml index 2f0238b770eb..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,6 +66,7 @@ properties: compatible: items: - enum: + - saef,sftc154b - sainsmart18 - shineworld,lh133k - const: panel-mipi-dbi-spi 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/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 150e81090af2..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# 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-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/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/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 1e5752b19a49..7b94d24d5ef4 100644 --- a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml +++ b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml @@ -148,7 +148,7 @@ properties: 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" 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/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 0e31bb36ebb1..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 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 2c8cf6aab19a..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 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/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 bdbee58a542b..4233ea839bfc 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml @@ -176,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 910bebe6cfa8..822864488dcb 100644 --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml @@ -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/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,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-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-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_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/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 index 22c0cae73425..4555f1644a4d 100644 --- a/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml @@ -28,6 +28,10 @@ properties: gpio-controller: true + gpio-line-names: + minItems: 1 + maxItems: 24 + interrupt-controller: true st,norequest-mask: 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/x-powers,axp209-gpio.yaml b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml index 1638cfe90f1c..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 diff --git a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml index 18e61aff2185..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 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/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/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 ff57c5416ebc..9f1d35ce1fe8 100644 --- a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml +++ b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.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/i2c/qcom,i2c-cci.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml index ec79b7270437..042d4dc636ee 100644 --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml @@ -269,6 +269,7 @@ examples: port { ov7251_ep: endpoint { data-lanes = <0 1>; + link-frequencies = /bits/ 64 <240000000 319200000>; remote-endpoint = <&csiphy3_ep>; }; }; diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml index fdb4212149e7..ab69f4115de4 100644 --- a/Documentation/devicetree/bindings/i3c/i3c.yaml +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml @@ -135,9 +135,10 @@ patternProperties: minimum: 0x1 maximum: 0xff description: | - Dynamic address to be assigned to this device. This property is only - valid if the I3C device has a static address (first cell of the reg - property != 0). + Dynamic address to be assigned to this device. In case static address is + present (first cell of the reg property != 0), this address is assigned + through SETDASA. If static address is not present, this address is assigned + through SETNEWDA after assigning a temporary address via ENTDAA. required: - reg @@ -163,12 +164,18 @@ examples: pagesize = <0x8>; }; - /* I3C device with a static I2C address. */ + /* I3C device with a static I2C address and assigned address. */ thermal_sensor: sensor@68,39200144004 { reg = <0x68 0x392 0x144004>; assigned-address = <0xa>; }; + /* I3C device with only assigned address. */ + pressure_sensor: sensor@0,39200124004 { + reg = <0x0 0x392 0x124000>; + assigned-address = <0xc>; + }; + /* * I3C device without a static I2C address but requiring * resources described in the DT. 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/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/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/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/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/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/pressure/honeywell,mprls0025pa.yaml b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml index c0a923febf13..b31f8120f14e 100644 --- a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml +++ b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml @@ -47,7 +47,7 @@ properties: reset-gpios: description: Optional GPIO for resetting the device. - If not present the device is not resetted during the probe. + If not present the device is not reset during the probe. maxItems: 1 honeywell,pmin-pascal: 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 e450821a741d..fff7e3d83a02 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -97,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/input/azoteq,iqs7222.yaml b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml index 9ddba7f2e7aa..5b1769c19b17 100644 --- a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml +++ b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml @@ -4,14 +4,14 @@ $id: http://devicetree.org/schemas/input/azoteq,iqs7222.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Azoteq IQS7222A/B/C Capacitive Touch Controller +title: Azoteq IQS7222A/B/C/D Capacitive Touch Controller maintainers: - Jeff LaBundy <jeff@labundy.com> description: | - The Azoteq IQS7222A, IQS7222B and IQS7222C are multichannel capacitive touch - controllers that feature additional sensing capabilities. + The Azoteq IQS7222A, IQS7222B, IQS7222C and IQS7222D are multichannel + capacitive touch controllers that feature additional sensing capabilities. Link to datasheets: https://www.azoteq.com/ @@ -21,6 +21,7 @@ properties: - azoteq,iqs7222a - azoteq,iqs7222b - azoteq,iqs7222c + - azoteq,iqs7222d reg: maxItems: 1 @@ -173,6 +174,152 @@ properties: maximum: 3000 description: Specifies the report rate (in ms) during ultra-low-power mode. + touchscreen-size-x: true + touchscreen-size-y: true + touchscreen-inverted-x: true + touchscreen-inverted-y: true + touchscreen-swapped-x-y: true + + trackpad: + type: object + description: Represents all channels associated with the trackpad. + + properties: + azoteq,channel-select: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 12 + items: + minimum: 0 + maximum: 13 + description: + Specifies the order of the channels that participate in the trackpad. + Specify 255 to omit a given channel for the purpose of mapping a non- + rectangular trackpad. + + azoteq,num-rows: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 12 + description: Specifies the number of rows that comprise the trackpad. + + azoteq,num-cols: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 12 + description: Specifies the number of columns that comprise the trackpad. + + azoteq,top-speed: + $ref: /schemas/types.yaml#/definitions/uint32 + multipleOf: 4 + minimum: 0 + maximum: 1020 + description: + Specifies the speed (in coordinates traveled per conversion) after + which coordinate filtering is no longer applied. + + azoteq,bottom-speed: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: + Specifies the speed (in coordinates traveled per conversion) after + which coordinate filtering is linearly reduced. + + azoteq,use-prox: + type: boolean + description: + Directs the trackpad to respond to the proximity states of the + selected channels instead of their corresponding touch states. + Note the trackpad cannot report granular coordinates during a + state of proximity. + + patternProperties: + "^azoteq,lower-cal-(x|y)$": + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the trackpad's lower starting points. + + "^azoteq,upper-cal-(x|y)$": + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the trackpad's upper starting points. + + "^event-(press|tap|(swipe|flick)-(x|y)-(pos|neg))$": + type: object + $ref: input.yaml# + description: + Represents a press or gesture event reported by the trackpad. Specify + 'linux,code' under the press event to report absolute coordinates. + + properties: + linux,code: true + + azoteq,gesture-angle-tighten: + type: boolean + description: + Limits the tangent of the gesture angle to 0.5 (axial gestures + only). If specified in one direction, the effect is applied in + either direction. + + azoteq,gesture-max-ms: + multipleOf: 16 + minimum: 0 + maximum: 4080 + description: + Specifies the length of time (in ms) within which a tap, swipe + or flick gesture must be completed in order to be acknowledged + by the device. The number specified for any one swipe or flick + gesture applies to all other swipe or flick gestures. + + azoteq,gesture-min-ms: + multipleOf: 16 + minimum: 0 + maximum: 4080 + description: + Specifies the length of time (in ms) for which a tap gesture must + be held in order to be acknowledged by the device. + + azoteq,gesture-dist: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 65535 + description: + Specifies the distance (in coordinates) across which a swipe or + flick gesture must travel in order to be acknowledged by the + device. The number specified for any one swipe or flick gesture + applies to all remaining swipe or flick gestures. + + For tap gestures, this property specifies the distance from the + original point of contact across which the contact is permitted + to travel before the gesture is rejected by the device. + + azoteq,gpio-select: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 3 + items: + minimum: 0 + maximum: 2 + description: | + Specifies one or more GPIO mapped to the event as follows: + 0: GPIO0 + 1: GPIO3 + 2: GPIO4 + + Note that although multiple events can be mapped to a single + GPIO, they must all be of the same type (proximity, touch or + trackpad gesture). + + additionalProperties: false + + required: + - azoteq,channel-select + + additionalProperties: false + patternProperties: "^cycle-[0-9]$": type: object @@ -288,6 +435,10 @@ patternProperties: Activates the reference channel in response to proximity events instead of touch events. + azoteq,counts-filt-enable: + type: boolean + description: Applies counts filtering to the channel. + azoteq,ati-band: $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1, 2, 3] @@ -432,12 +583,12 @@ patternProperties: description: | Specifies one or more GPIO mapped to the event as follows: 0: GPIO0 - 1: GPIO3 (IQS7222C only) - 2: GPIO4 (IQS7222C only) + 1: GPIO3 + 2: GPIO4 Note that although multiple events can be mapped to a single GPIO, they must all be of the same type (proximity, touch or - slider gesture). + slider/trackpad gesture). azoteq,thresh: $ref: /schemas/types.yaml#/definitions/uint32 @@ -521,16 +672,16 @@ patternProperties: minimum: 0 maximum: 65535 description: - Specifies the speed of movement after which coordinate filtering is - no longer applied. + Specifies the speed (in coordinates traveled per conversion) after + which coordinate filtering is no longer applied. azoteq,bottom-speed: $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 255 description: - Specifies the speed of movement after which coordinate filtering is - linearly reduced. + Specifies the speed (in coordinates traveled per conversion) after + which coordinate filtering is linearly reduced. azoteq,bottom-beta: $ref: /schemas/types.yaml#/definitions/uint32 @@ -595,10 +746,10 @@ patternProperties: minimum: 0 maximum: 4080 description: - Specifies the distance across which a swipe or flick gesture must - travel in order to be acknowledged by the device. The number spec- - ified for any one swipe or flick gesture applies to all remaining - swipe or flick gestures. + Specifies the distance (in coordinates) across which a swipe or + flick gesture must travel in order to be acknowledged by the + device. The number specified for any one swipe or flick gesture + applies to all remaining swipe or flick gestures. azoteq,gpio-select: $ref: /schemas/types.yaml#/definitions/uint32-array @@ -610,8 +761,8 @@ patternProperties: description: | Specifies one or more GPIO mapped to the event as follows: 0: GPIO0 - 1: GPIO3 (IQS7222C only) - 2: GPIO4 (IQS7222C only) + 1: GPIO3 + 2: GPIO4 Note that although multiple events can be mapped to a single GPIO, they must all be of the same type (proximity, touch or @@ -629,8 +780,8 @@ patternProperties: description: | Represents a GPIO mapped to one or more events as follows: gpio-0: GPIO0 - gpio-1: GPIO3 (IQS7222C only) - gpio-2: GPIO4 (IQS7222C only) + gpio-1: GPIO3 + gpio-2: GPIO4 allOf: - $ref: ../pinctrl/pincfg-node.yaml# @@ -641,11 +792,53 @@ patternProperties: additionalProperties: false allOf: + - $ref: touchscreen/touchscreen.yaml# + - if: properties: compatible: contains: - const: azoteq,iqs7222b + enum: + - azoteq,iqs7222a + - azoteq,iqs7222b + - azoteq,iqs7222c + + then: + properties: + touchscreen-size-x: false + touchscreen-size-y: false + touchscreen-inverted-x: false + touchscreen-inverted-y: false + touchscreen-swapped-x-y: false + + trackpad: false + + patternProperties: + "^channel-([0-9]|1[0-9])$": + properties: + azoteq,counts-filt-enable: false + + - if: + properties: + compatible: + contains: + enum: + - azoteq,iqs7222b + - azoteq,iqs7222c + + then: + patternProperties: + "^channel-([0-9]|1[0-9])$": + properties: + azoteq,ulp-allow: false + + - if: + properties: + compatible: + contains: + enum: + - azoteq,iqs7222b + - azoteq,iqs7222d then: patternProperties: @@ -657,13 +850,22 @@ allOf: properties: azoteq,ref-select: false + "^slider-[0-1]$": false + + - if: + properties: + compatible: + contains: + const: azoteq,iqs7222b + + then: + patternProperties: + "^channel-([0-9]|1[0-9])$": patternProperties: "^event-(prox|touch)$": properties: azoteq,gpio-select: false - "^slider-[0-1]$": false - "^gpio-[0-2]$": false - if: @@ -704,10 +906,6 @@ allOf: else: patternProperties: - "^channel-([0-9]|1[0-9])$": - properties: - azoteq,ulp-allow: false - "^slider-[0-1]$": patternProperties: "^event-(press|tap|(swipe|flick)-(pos|neg))$": 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/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/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/azoteq,iqs7211.yaml b/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml new file mode 100644 index 000000000000..8cf371b99f19 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml @@ -0,0 +1,769 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/azoteq,iqs7211.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Azoteq IQS7210A/7211A/E Trackpad/Touchscreen Controller + +maintainers: + - Jeff LaBundy <jeff@labundy.com> + +description: | + The Azoteq IQS7210A, IQS7211A and IQS7211E trackpad and touchscreen control- + lers employ projected-capacitance sensing and can track two contacts. + + Link to datasheets: https://www.azoteq.com/ + +properties: + compatible: + enum: + - azoteq,iqs7210a + - azoteq,iqs7211a + - azoteq,iqs7211e + + reg: + maxItems: 1 + + irq-gpios: + maxItems: 1 + description: + Specifies the GPIO connected to the device's active-low RDY output. The + pin doubles as the IQS7211E's active-low MCLR input, in which case this + GPIO must be configured as open-drain. + + reset-gpios: + maxItems: 1 + description: + Specifies the GPIO connected to the device's active-low MCLR input. The + device is temporarily held in hardware reset prior to initialization if + this property is present. + + azoteq,forced-comms: + type: boolean + description: + Enables forced communication; to be used with host adapters that cannot + tolerate clock stretching. + + azoteq,forced-comms-default: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: + Indicates if the device's OTP memory enables (1) or disables (0) forced + communication by default. Specifying this property can expedite startup + time if the default value is known. + + If this property is not specified, communication is not initiated until + the device asserts its RDY pin shortly after exiting hardware reset. At + that point, forced communication is either enabled or disabled based on + the presence or absence of the 'azoteq,forced-comms' property. + + azoteq,rate-active-ms: + minimum: 0 + maximum: 65535 + description: Specifies the report rate (in ms) during active mode. + + azoteq,rate-touch-ms: + minimum: 0 + maximum: 65535 + description: Specifies the report rate (in ms) during idle-touch mode. + + azoteq,rate-idle-ms: + minimum: 0 + maximum: 65535 + description: Specifies the report rate (in ms) during idle mode. + + azoteq,rate-lp1-ms: + minimum: 0 + maximum: 65535 + description: Specifies the report rate (in ms) during low-power mode 1. + + azoteq,rate-lp2-ms: + minimum: 0 + maximum: 65535 + description: Specifies the report rate (in ms) during low-power mode 2. + + azoteq,timeout-active-ms: + multipleOf: 1000 + minimum: 0 + maximum: 65535000 + description: + Specifies the length of time (in ms) to wait for an event before moving + from active mode to idle or idle-touch modes. + + azoteq,timeout-touch-ms: + multipleOf: 1000 + minimum: 0 + maximum: 65535000 + description: + Specifies the length of time (in ms) to wait for an event before moving + from idle-touch mode to idle mode. + + azoteq,timeout-idle-ms: + multipleOf: 1000 + minimum: 0 + maximum: 65535000 + description: + Specifies the length of time (in ms) to wait for an event before moving + from idle mode to low-power mode 1. + + azoteq,timeout-lp1-ms: + multipleOf: 1000 + minimum: 0 + maximum: 65535000 + description: + Specifies the length of time (in ms) to wait for an event before moving + from low-power mode 1 to low-power mode 2. + + azoteq,timeout-lp2-ms: + multipleOf: 1000 + minimum: 0 + maximum: 60000 + description: + Specifies the rate (in ms) at which the trackpad reference values + are updated during low-power modes 1 and 2. + + azoteq,timeout-ati-ms: + multipleOf: 1000 + minimum: 0 + maximum: 60000 + description: + Specifies the delay (in ms) before the automatic tuning implementation + (ATI) is retried in the event it fails to complete. + + azoteq,timeout-comms-ms: + minimum: 0 + maximum: 65535 + description: + Specifies the delay (in ms) before a communication window is closed. + + azoteq,timeout-press-ms: + multipleOf: 1000 + minimum: 0 + maximum: 60000 + description: + Specifies the length of time (in ms) to wait before automatically + releasing a press event. Specify zero to allow the press state to + persist indefinitely. + + azoteq,fosc-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + Specifies the device's core clock frequency as follows: + 0: 14 MHz + 1: 18 MHz + + azoteq,fosc-trim: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Specifies the device's core clock frequency trim. + + azoteq,num-contacts: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 2 + default: 0 + description: Specifies the number of contacts reported by the device. + + azoteq,contact-split: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the contact (finger) split factor. + + azoteq,trim-x: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the horizontal trim width. + + azoteq,trim-y: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the vertical trim height. + + trackpad: + type: object + description: Represents all channels associated with the trackpad. + + properties: + azoteq,rx-enable: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + items: + minimum: 0 + maximum: 7 + description: + Specifies the order of the CRx pin(s) associated with the trackpad. + + azoteq,tx-enable: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 12 + items: + minimum: 0 + maximum: 11 + description: + Specifies the order of the CTx pin(s) associated with the trackpad. + + azoteq,channel-select: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 36 + items: + minimum: 0 + maximum: 255 + description: | + Specifies the channels mapped to each cycle in the following order: + Cycle 0, slot 0 + Cycle 0, slot 1 + Cycle 1, slot 0 + Cycle 1, slot 1 + ...and so on. Specify 255 to disable a given slot. + + azoteq,ati-frac-div-fine: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the trackpad's ATI fine fractional divider. + + azoteq,ati-frac-mult-coarse: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Specifies the trackpad's ATI coarse fractional multiplier. + + azoteq,ati-frac-div-coarse: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the trackpad's ATI coarse fractional divider. + + azoteq,ati-comp-div: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the trackpad's ATI compensation divider. + + azoteq,ati-target: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 65535 + description: Specifies the trackpad's ATI target. + + azoteq,touch-enter: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the trackpad's touch entrance factor. + + azoteq,touch-exit: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the trackpad's touch exit factor. + + azoteq,thresh: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the trackpad's stationary touch threshold. + + azoteq,conv-period: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the trackpad's conversion period. + + azoteq,conv-frac: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the trackpad's conversion frequency fraction. + + patternProperties: + "^event-(tap(-double|-triple)?|hold|palm|swipe-(x|y)-(pos|neg)(-hold)?)$": + type: object + $ref: ../input.yaml# + description: + Represents a gesture event reported by the trackpad. In the case of + axial gestures, the duration or distance specified in one direction + applies to both directions along the same axis. + + properties: + linux,code: true + + azoteq,gesture-max-ms: + minimum: 0 + maximum: 65535 + description: Specifies the maximum duration of tap/swipe gestures. + + azoteq,gesture-mid-ms: + minimum: 0 + maximum: 65535 + description: + Specifies the maximum duration between subsequent tap gestures + (IQS7211E only). + + azoteq,gesture-min-ms: + minimum: 0 + maximum: 65535 + description: Specifies the minimum duration of hold gestures. + + azoteq,gesture-dist: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 65535 + description: + Specifies the minimum (swipe) or maximum (tap and hold) distance + a finger may travel to be considered a gesture. + + azoteq,gesture-dist-rep: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 65535 + description: + Specifies the minimum distance a finger must travel to elicit a + repeated swipe gesture (IQS7211E only). + + azoteq,gesture-angle: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 75 + description: + Specifies the maximum angle (in degrees) a finger may travel to + be considered a swipe gesture. + + azoteq,thresh: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 42 + description: Specifies the palm gesture threshold (IQS7211E only). + + additionalProperties: false + + dependencies: + azoteq,rx-enable: ["azoteq,tx-enable"] + azoteq,tx-enable: ["azoteq,rx-enable"] + azoteq,channel-select: ["azoteq,rx-enable"] + + additionalProperties: false + + alp: + type: object + $ref: ../input.yaml# + description: Represents the alternate low-power channel (ALP). + + properties: + azoteq,rx-enable: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + items: + minimum: 0 + maximum: 7 + description: + Specifies the CRx pin(s) associated with the ALP in no particular + order. + + azoteq,tx-enable: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 12 + items: + minimum: 0 + maximum: 11 + description: + Specifies the CTx pin(s) associated with the ALP in no particular + order. + + azoteq,ati-frac-div-fine: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the ALP's ATI fine fractional divider. + + azoteq,ati-frac-mult-coarse: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Specifies the ALP's ATI coarse fractional multiplier. + + azoteq,ati-frac-div-coarse: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the ALP's ATI coarse fractional divider. + + azoteq,ati-comp-div: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the ALP's ATI compensation divider. + + azoteq,ati-target: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 65535 + description: Specifies the ALP's ATI target. + + azoteq,ati-base: + $ref: /schemas/types.yaml#/definitions/uint32 + multipleOf: 8 + minimum: 0 + maximum: 255 + description: Specifies the ALP's ATI base. + + azoteq,ati-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + Specifies the ALP's ATI mode as follows: + 0: Partial + 1: Full + + azoteq,sense-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + Specifies the ALP's sensing mode as follows: + 0: Self capacitive + 1: Mutual capacitive + + azoteq,debounce-enter: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the ALP's debounce entrance factor. + + azoteq,debounce-exit: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the ALP's debounce exit factor. + + azoteq,thresh: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 65535 + description: Specifies the ALP's proximity or touch threshold. + + azoteq,conv-period: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the ALP's conversion period. + + azoteq,conv-frac: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the ALP's conversion frequency fraction. + + linux,code: true + + additionalProperties: false + + button: + type: object + description: Represents the inductive or capacitive button. + + properties: + azoteq,ati-frac-div-fine: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the button's ATI fine fractional divider. + + azoteq,ati-frac-mult-coarse: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Specifies the button's ATI coarse fractional multiplier. + + azoteq,ati-frac-div-coarse: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the button's ATI coarse fractional divider. + + azoteq,ati-comp-div: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the button's ATI compensation divider. + + azoteq,ati-target: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 65535 + description: Specifies the button's ATI target. + + azoteq,ati-base: + $ref: /schemas/types.yaml#/definitions/uint32 + multipleOf: 8 + minimum: 0 + maximum: 255 + description: Specifies the button's ATI base. + + azoteq,ati-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + Specifies the button's ATI mode as follows: + 0: Partial + 1: Full + + azoteq,sense-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + description: | + Specifies the button's sensing mode as follows: + 0: Self capacitive + 1: Mutual capacitive + 2: Inductive + + azoteq,touch-enter: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the button's touch entrance factor. + + azoteq,touch-exit: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the button's touch exit factor. + + azoteq,debounce-enter: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the button's debounce entrance factor. + + azoteq,debounce-exit: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the button's debounce exit factor. + + azoteq,thresh: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 65535 + description: Specifies the button's proximity threshold. + + azoteq,conv-period: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the button's conversion period. + + azoteq,conv-frac: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the button's conversion frequency fraction. + + patternProperties: + "^event-(prox|touch)$": + type: object + $ref: ../input.yaml# + description: + Represents a proximity or touch event reported by the button. + + properties: + linux,code: true + + additionalProperties: false + + additionalProperties: false + + wakeup-source: true + + touchscreen-size-x: true + touchscreen-size-y: true + touchscreen-inverted-x: true + touchscreen-inverted-y: true + touchscreen-swapped-x-y: true + +dependencies: + touchscreen-size-x: ["azoteq,num-contacts"] + touchscreen-size-y: ["azoteq,num-contacts"] + touchscreen-inverted-x: ["azoteq,num-contacts"] + touchscreen-inverted-y: ["azoteq,num-contacts"] + touchscreen-swapped-x-y: ["azoteq,num-contacts"] + +required: + - compatible + - reg + - irq-gpios + +additionalProperties: false + +allOf: + - $ref: touchscreen.yaml# + + - if: + properties: + compatible: + contains: + const: azoteq,iqs7210a + + then: + properties: + alp: + properties: + azoteq,rx-enable: + maxItems: 4 + items: + minimum: 4 + + else: + properties: + azoteq,timeout-press-ms: false + + alp: + properties: + azoteq,ati-mode: false + + button: false + + - if: + properties: + compatible: + contains: + const: azoteq,iqs7211e + + then: + properties: + reset-gpios: false + + trackpad: + properties: + azoteq,tx-enable: + maxItems: 13 + items: + maximum: 12 + + alp: + properties: + azoteq,tx-enable: + maxItems: 13 + items: + maximum: 12 + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/input/input.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touch@56 { + compatible = "azoteq,iqs7210a"; + reg = <0x56>; + irq-gpios = <&gpio 4 GPIO_ACTIVE_LOW>; + reset-gpios = <&gpio 17 (GPIO_ACTIVE_LOW | + GPIO_PUSH_PULL)>; + azoteq,num-contacts = <2>; + + trackpad { + azoteq,rx-enable = <6>, <5>, <4>, <3>, <2>; + azoteq,tx-enable = <1>, <7>, <8>, <9>, <10>; + }; + + button { + azoteq,sense-mode = <2>; + azoteq,touch-enter = <40>; + azoteq,touch-exit = <36>; + + event-touch { + linux,code = <KEY_HOME>; + }; + }; + + alp { + azoteq,sense-mode = <1>; + linux,code = <KEY_POWER>; + }; + }; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/input/input.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touch@56 { + compatible = "azoteq,iqs7211e"; + reg = <0x56>; + irq-gpios = <&gpio 4 (GPIO_ACTIVE_LOW | + GPIO_OPEN_DRAIN)>; + + trackpad { + event-tap { + linux,code = <KEY_PLAYPAUSE>; + }; + + event-tap-double { + linux,code = <KEY_SHUFFLE>; + }; + + event-tap-triple { + linux,code = <KEY_AGAIN>; + }; + + event-hold { + linux,code = <KEY_STOP>; + }; + + event-palm { + linux,code = <KEY_EXIT>; + }; + + event-swipe-x-pos { + linux,code = <KEY_REWIND>; + }; + + event-swipe-x-pos-hold { + linux,code = <KEY_PREVIOUS>; + }; + + event-swipe-x-neg { + linux,code = <KEY_FASTFORWARD>; + }; + + event-swipe-x-neg-hold { + linux,code = <KEY_NEXT>; + }; + + event-swipe-y-pos { + linux,code = <KEY_VOLUMEUP>; + }; + + event-swipe-y-pos-hold { + linux,code = <KEY_MUTE>; + }; + + event-swipe-y-neg { + linux,code = <KEY_VOLUMEDOWN>; + }; + + event-swipe-y-neg-hold { + linux,code = <KEY_MUTE>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml index ef4c841387bd..f2808cb4d99d 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml @@ -93,6 +93,12 @@ properties: minimum: 1 maximum: 255 + threshold: + description: Allows setting the "click"-threshold in the range from 0 to 255. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + touchscreen-size-x: true touchscreen-size-y: true touchscreen-fuzz-x: true diff --git a/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml index 007adbc89c14..9dc25d30a0a8 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml @@ -24,6 +24,8 @@ properties: maxItems: 1 reset-gpios: maxItems: 1 + vdd-supply: + description: Power supply regulator for the chip touchscreen-size-x: true touchscreen-size-y: true touchscreen-inverted-x: true diff --git a/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml b/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml index fdd02898e249..07f9dd6b1c9c 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml @@ -52,6 +52,11 @@ properties: touchscreen-swapped-x-y: true touchscreen-max-pressure: true + linux,keycodes: + description: Keycodes for the touch keys + minItems: 1 + maxItems: 15 + additionalProperties: false required: 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/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/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.yaml b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml index e84e4f33b358..3d06db98e978 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml @@ -35,6 +35,7 @@ properties: - 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: 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/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/st,sti-irq-syscfg.txt b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt deleted file mode 100644 index 977d7ed3670e..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt +++ /dev/null @@ -1,30 +0,0 @@ -STMicroelectronics STi System Configuration Controlled IRQs ------------------------------------------------------------ - -On STi based systems; External, CTI (Core Sight), PMU (Performance Management), -and PL310 L2 Cache IRQs are controlled using System Configuration registers. -This driver is used to unmask them prior to use. - -Required properties: -- compatible : Should be "st,stih407-irq-syscfg" -- st,syscfg : Phandle to Cortex-A9 IRQ system config registers -- st,irq-device : Array of IRQs to enable - should be 2 in length -- st,fiq-device : Array of FIQs to enable - should be 2 in length - -Optional properties: -- st,invert-ext : External IRQs can be inverted at will. This property inverts - these IRQs using bitwise logic. A number of defines have been - provided for convenience: - ST_IRQ_SYSCFG_EXT_1_INV - ST_IRQ_SYSCFG_EXT_2_INV - ST_IRQ_SYSCFG_EXT_3_INV -Example: - -irq-syscfg { - compatible = "st,stih407-irq-syscfg"; - st,syscfg = <&syscfg_cpu>; - st,irq-device = <ST_IRQ_SYSCFG_PMU_0>, - <ST_IRQ_SYSCFG_PMU_1>; - st,fiq-device = <ST_IRQ_SYSCFG_DISABLED>, - <ST_IRQ_SYSCFG_DISABLED>; -}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml new file mode 100644 index 000000000000..2b153d7c5421 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/st,stih407-irq-syscfg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STi System Configuration Controlled IRQs + +maintainers: + - Patrice Chotard <patrice.chotard@foss.st.com> + +description: + On STi based systems; External, CTI (Core Sight), PMU (Performance + Management), and PL310 L2 Cache IRQs are controlled using System + Configuration registers. This device is used to unmask them prior to use. + +properties: + compatible: + const: st,stih407-irq-syscfg + + st,syscfg: + description: Phandle to Cortex-A9 IRQ system config registers + $ref: /schemas/types.yaml#/definitions/phandle + + st,irq-device: + description: Array of IRQs to enable. + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: Enable the IRQ of the channel one. + - description: Enable the IRQ of the channel two. + + st,fiq-device: + description: Array of FIQs to enable. + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: Enable the IRQ of the channel one. + - description: Enable the IRQ of the channel two. + + st,invert-ext: + description: External IRQs can be inverted at will. This property inverts + these three IRQs using bitwise logic, each one being encoded respectively + on the first, second and fourth bit. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2, 3, 4, 5, 6 ] + +required: + - compatible + - st,syscfg + - st,irq-device + - st,fiq-device + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq-st.h> + irq-syscfg { + compatible = "st,stih407-irq-syscfg"; + st,syscfg = <&syscfg_cpu>; + st,irq-device = <ST_IRQ_SYSCFG_PMU_0>, + <ST_IRQ_SYSCFG_PMU_1>; + st,fiq-device = <ST_IRQ_SYSCFG_DISABLED>, + <ST_IRQ_SYSCFG_DISABLED>; + }; +... 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 3a31a979709b..cf29ab10501c 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -270,6 +270,47 @@ 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: 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/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/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index 58b492d00246..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 @@ -158,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-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 058be1fedbc8..e9d4514d0166 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml @@ -106,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 @@ -129,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: | diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml index e6f1999cb22f..ea84ad426df1 100644 --- a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml @@ -56,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/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/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 58f0d94c6d71..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 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/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/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/ov5695.txt b/Documentation/devicetree/bindings/media/i2c/ov5695.txt deleted file mode 100644 index 640a63717d96..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/ov5695.txt +++ /dev/null @@ -1,41 +0,0 @@ -* Omnivision OV5695 MIPI CSI-2 sensor - -Required Properties: -- compatible: shall be "ovti,ov5695" -- clocks: reference to the xvclk input clock -- clock-names: shall be "xvclk" -- avdd-supply: Analog voltage supply, 2.8 volts -- dovdd-supply: Digital I/O voltage supply, 1.8 volts -- dvdd-supply: Digital core voltage supply, 1.2 volts -- reset-gpios: Low active reset gpio - -The device node shall contain one 'port' child node with an -'endpoint' subnode for its digital output video port, -in accordance with the video interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. -The endpoint optional property 'data-lanes' shall be "<1 2>". - -Example: -&i2c7 { - ov5695: camera-sensor@36 { - compatible = "ovti,ov5695"; - reg = <0x36>; - pinctrl-names = "default"; - pinctrl-0 = <&clk_24m_cam>; - - clocks = <&cru SCLK_TESTCLKOUT1>; - clock-names = "xvclk"; - - avdd-supply = <&pp2800_cam>; - dovdd-supply = <&pp1800>; - dvdd-supply = <&pp1250_cam>; - reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; - - port { - wcam_out: endpoint { - remote-endpoint = <&mipi_in_wcam>; - data-lanes = <1 2>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/media/i2c/ov7251.txt b/Documentation/devicetree/bindings/media/i2c/ov7251.txt deleted file mode 100644 index 8281151f7493..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/ov7251.txt +++ /dev/null @@ -1,52 +0,0 @@ -* Omnivision 1/7.5-Inch B&W VGA CMOS Digital Image Sensor - -The Omnivision OV7251 is a 1/7.5-Inch CMOS active pixel digital image sensor -with an active array size of 640H x 480V. It is programmable through a serial -I2C interface. - -Required Properties: -- compatible: Value should be "ovti,ov7251". -- clocks: Reference to the xclk clock. -- clock-names: Should be "xclk". -- clock-frequency: Frequency of the xclk clock. -- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This corresponds - to the hardware pin XSHUTDOWN which is physically active low. -- vdddo-supply: Chip digital IO regulator. -- vdda-supply: Chip analog regulator. -- vddd-supply: Chip digital core regulator. - -The device node shall contain one 'port' child node with a single 'endpoint' -subnode for its digital output video port, in accordance with the video -interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. - -Example: - - &i2c1 { - ... - - ov7251: camera-sensor@60 { - compatible = "ovti,ov7251"; - reg = <0x60>; - - enable-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>; - pinctrl-names = "default"; - pinctrl-0 = <&camera_bw_default>; - - clocks = <&clks 200>; - clock-names = "xclk"; - clock-frequency = <24000000>; - - vdddo-supply = <&camera_dovdd_1v8>; - vdda-supply = <&camera_avdd_2v8>; - vddd-supply = <&camera_dvdd_1v2>; - - port { - ov7251_ep: endpoint { - clock-lanes = <1>; - data-lanes = <0>; - remote-endpoint = <&csi0_ep>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml index 359dc08440a8..6829a4aadd22 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml @@ -5,26 +5,41 @@ $id: http://devicetree.org/schemas/media/i2c/ovti,ov5693.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Omnivision OV5693 CMOS Sensor +title: Omnivision OV5693/OV5695 CMOS Sensors maintainers: - Tommaso Merciai <tommaso.merciai@amarulasolutions.com> description: | - The Omnivision OV5693 is a high performance, 1/4-inch, 5 megapixel, CMOS - image sensor that delivers 2592x1944 at 30fps. It provides full-frame, + The Omnivision OV5693/OV5695 are high performance, 1/4-inch, 5 megapixel, CMOS + image sensors that deliver 2592x1944 at 30fps. It provides full-frame, sub-sampled, and windowed 10-bit MIPI images in various formats via the Serial Camera Control Bus (SCCB) interface. - OV5693 is controlled via I2C and two-wire Serial Camera Control Bus (SCCB). - The sensor output is available via CSI-2 serial data output (up to 2-lane). + OV5693/OV5695 are controlled via I2C and two-wire Serial Camera Control Bus + (SCCB). The sensor output is available via CSI-2 serial data output (up to + 2-lane). allOf: - $ref: /schemas/media/video-interface-devices.yaml# + - if: + properties: + compatible: + contains: + const: ovti,ov5693 + then: + properties: + port: + properties: + endpoint: + required: + - link-frequencies properties: compatible: - const: ovti,ov5693 + enum: + - ovti,ov5693 + - ovti,ov5695 reg: maxItems: 1 @@ -34,6 +49,9 @@ properties: System input clock (aka XVCLK). From 6 to 27 MHz. maxItems: 1 + clock-names: + const: xvclk + dovdd-supply: description: Digital I/O voltage supply, 1.8V. @@ -72,7 +90,6 @@ properties: required: - data-lanes - - link-frequencies required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml new file mode 100644 index 000000000000..2e5187acbbb8 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov7251.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OmniVision OV7251 Image Sensor + +description: + The Omnivision OV7251 is a 1/7.5-Inch CMOS active pixel digital image sensor + with an active array size of 640H x 480V. It is programmable through a serial + I2C interface. + +maintainers: + - Todor Tomov <todor.too@gmail.com> + +properties: + compatible: + const: ovti,ov7251 + + reg: + maxItems: 1 + + clocks: + description: XCLK Input Clock + + clock-names: + const: xclk + + clock-frequency: + description: Frequency of the xclk clock in Hz. + + vdda-supply: + description: Analog voltage supply, 2.8 volts + + vddd-supply: + description: Digital core voltage supply, 1.2 volts + + vdddo-supply: + description: Digital I/O voltage supply, 1.8 volts + + enable-gpios: + maxItems: 1 + description: + Reference to the GPIO connected to the XSHUTDOWN pin, if any. Polarity + is GPIO_ACTIVE_HIGH. + + port: + description: Digital Output Port + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maximum: 1 + + data-lanes: + maxItems: 1 + + link-frequencies: true + + required: + - data-lanes + - link-frequencies + +required: + - compatible + - reg + - clocks + - vdddo-supply + - vdda-supply + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + camera@3c { + compatible = "ovti,ov7251"; + reg = <0x3c>; + clocks = <&clks 1>; + clock-frequency = <24000000>; + vdddo-supply = <&ov7251_vdddo_1v8>; + vdda-supply = <&ov7251_vdda_2v8>; + vddd-supply = <&ov7251_vddd_1v5>; + enable-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; + + port { + ov7251_ep: endpoint { + remote-endpoint = <&csi0_ep>; + clock-lanes = <1>; + data-lanes = <0>; + link-frequencies = /bits/ 64 <240000000 319200000>; + }; + }; + }; + }; +... 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-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,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/rockchip-isp1.yaml b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml index 0bad7e640148..e466dff8286d 100644 --- a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml @@ -199,6 +199,7 @@ examples: wcam: camera@36 { compatible = "ovti,ov5695"; reg = <0x36>; + clocks = <&cru SCLK_TESTCLKOUT1>; port { wcam_out: endpoint { 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/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/xlnx,zynq-ddrc-a05.yaml b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml index 75143db51411..b74ad9a3305c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml @@ -12,7 +12,7 @@ maintainers: 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/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 9f9a14af875e..cb480162f967 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml @@ -35,7 +35,7 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm63xx-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 @@ -44,7 +44,7 @@ patternProperties: "^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 803277dd2725..c14def1b2ad2 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml @@ -35,7 +35,7 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm63xx-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 @@ -44,7 +44,7 @@ patternProperties: "^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 b9a6856ce970..5f48209ed40f 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml @@ -35,7 +35,7 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm63xx-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 @@ -44,7 +44,7 @@ patternProperties: "^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 4651fe4dde07..f1f4629565d9 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml @@ -35,7 +35,7 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm63xx-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 @@ -44,7 +44,7 @@ patternProperties: "^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 0330b621fd38..4d594739b382 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml @@ -35,7 +35,7 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm63xx-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 @@ -44,7 +44,7 @@ patternProperties: "^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 82d3e4415bda..aae83d432880 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml @@ -35,7 +35,7 @@ patternProperties: "^gpio@[0-9a-f]+$": # Child node type: object - $ref: "../gpio/brcm,bcm63xx-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 @@ -44,7 +44,7 @@ patternProperties: "^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/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 8b9a2008a354..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,6 +71,8 @@ properties: - qcom,pm8994 - qcom,pm8998 - qcom,pma8084 + - qcom,pmc8180 + - qcom,pmc8180c - qcom,pmd9635 - qcom,pmi632 - qcom,pmi8950 @@ -88,6 +91,7 @@ properties: - qcom,pms405 - qcom,pmx55 - qcom,pmx65 + - qcom,pmx75 - qcom,smb2351 - const: qcom,spmi-pmic @@ -127,7 +131,7 @@ 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 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/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 97c61097f9e2..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: @@ -187,10 +193,8 @@ properties: "^(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/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/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/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/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 6da28e630577..80141eb7fc6b 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml @@ -215,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"; @@ -232,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/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml index 787ef488dd5b..57b6957c8415 100644 --- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml @@ -50,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] @@ -66,6 +66,10 @@ patternProperties: unevaluatedProperties: false + dependencies: + nand-ecc-strength: [nand-ecc-step-size] + nand-ecc-step-size: [nand-ecc-strength] + 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 index a10729bb1840..1ecea848e8b9 100644 --- a/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml @@ -16,6 +16,7 @@ properties: - 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 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/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index 83a4fe4cc29d..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# 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/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/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml index 56cbb42b5aea..eba2f3026ab0 100644 --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml @@ -19,12 +19,14 @@ properties: - 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 @@ -57,6 +59,9 @@ properties: 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 @@ -72,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 @@ -111,6 +119,7 @@ allOf: compatible: contains: enum: + - qcom,wcn3988-bt - qcom,wcn3990-bt - qcom,wcn3991-bt - qcom,wcn3998-bt @@ -155,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,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/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 33726134f5c9..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: - 6163, 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/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 c1241c8a3b77..8fb2a6ee7e5b 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -110,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/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 5aa320c8af5a..ed9d845f6008 100644 --- a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml @@ -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 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/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/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/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml index 176ea5f90251..70bbc4220e2a 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml @@ -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/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/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/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,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/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/layouts/fixed-cell.yaml b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml index e698098450e1..ac2381e66027 100644 --- a/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml +++ b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml @@ -11,6 +11,15 @@ maintainers: - 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 @@ -25,6 +34,23 @@ properties: 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 diff --git a/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml index c271537d0714..9bd34bd5af30 100644 --- a/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml +++ b/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml @@ -44,6 +44,18 @@ examples: #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/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/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml index 980244100690..9f921d940142 100644 --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml @@ -49,7 +49,10 @@ properties: patternProperties: "@[0-9a-f]+(,[0-7])?$": type: object - $ref: layouts/fixed-cell.yaml + allOf: + - $ref: layouts/fixed-cell.yaml + - properties: + compatible: false deprecated: true additionalProperties: true diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml index 6cd4682a167d..8740938c32eb 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml @@ -23,11 +23,13 @@ properties: - 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 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/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 811112255d7d..a223ce029cab 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml @@ -11,10 +11,13 @@ maintainers: properties: compatible: - enum: - - qcom,sdx55-pcie-ep - - qcom,sdx65-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: @@ -71,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 @@ -98,6 +109,8 @@ required: - interrupts - interrupt-names - reset-gpios + - interconnects + - interconnect-names - resets - reset-names - power-domains @@ -110,7 +123,6 @@ allOf: contains: enum: - qcom,sdx55-pcie-ep - - qcom,sdx65-pcie-ep then: properties: clocks: @@ -167,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>, @@ -194,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-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml index a4f61ced5e88..1ae8dcfa072c 100644 --- a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml @@ -60,6 +60,61 @@ properties: - 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 num-lanes: true @@ -108,6 +163,7 @@ unevaluatedProperties: false examples: - | + #include <dt-bindings/interrupt-controller/arm-gic.h> bus { #address-cells = <2>; @@ -127,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>; @@ -140,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/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/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/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/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,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 3d42ee3901a1..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,sc8180x-qmp-pcie-phy - - 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,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 881ba543fd46..000000000000 --- a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml +++ /dev/null @@ -1,228 +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,sc8180x-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,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 4c96dab5b9e3..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,25 +23,16 @@ properties: - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-usb3-phy - qcom,msm8998-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,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 ] @@ -131,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: @@ -202,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 @@ -228,51 +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,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: @@ -293,12 +216,9 @@ allOf: enum: - qcom,ipq6018-qmp-usb3-phy - qcom,ipq8074-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,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,sc7180-qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml deleted file mode 100644 index d30734338888..000000000000 --- a/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml +++ /dev/null @@ -1,282 +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 - - orientation-switch: - description: Flag the port as possible handler of orientation switching - type: boolean - - 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>; - - orientation-switch; - - 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 a1897a7606df..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: minItems: 3 clock-names: minItems: 3 - else: + + - 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-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml index ef1c02d8ac88..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 @@ -85,7 +94,6 @@ required: - reg - clocks - clock-names - - power-domains - resets - reset-names - vdda-phy-supply @@ -93,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: 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/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/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,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,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index 8aaf50181cef..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 @@ -53,6 +54,8 @@ properties: - qcom,pm8994-gpio - qcom,pm8998-gpio - qcom,pma8084-gpio + - qcom,pmc8180-gpio + - qcom,pmc8180c-gpio - qcom,pmi632-gpio - qcom,pmi8950-gpio - qcom,pmi8994-gpio @@ -68,6 +71,7 @@ properties: - qcom,pms405-gpio - qcom,pmx55-gpio - qcom,pmx65-gpio + - qcom,pmx75-gpio - enum: - qcom,spmi-gpio @@ -172,6 +176,7 @@ allOf: compatible: contains: enum: + - qcom,pm7550ba-gpio - qcom,pm8226-gpio - qcom,pm8350b-gpio - qcom,pm8550ve-gpio @@ -301,6 +306,7 @@ allOf: contains: enum: - qcom,pmx65-gpio + - qcom,pmx75-gpio then: properties: gpio-line-names: @@ -413,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 @@ -456,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,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,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,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/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,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml index 24ad0614e61b..01b6f2b57843 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml @@ -273,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/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/restart-handler.yaml b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml index f2ffdd29d52a..965a834a3dbe 100644 --- a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml +++ b/Documentation/devicetree/bindings/power/reset/restart-handler.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/restart-handler.yaml# diff --git a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml index 4fe9c3705265..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 --- 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/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/brcm,kona-pwm.txt b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt deleted file mode 100644 index c42eecfc81ed..000000000000 --- a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt +++ /dev/null @@ -1,21 +0,0 @@ -Broadcom Kona PWM controller device tree bindings - -This controller has 6 channels. - -Required Properties : -- compatible: should contain "brcm,kona-pwm" -- reg: physical base address and length of the controller's registers -- clocks: phandle + clock specifier pair for the external clock -- #pwm-cells: Should be 3. See pwm.yaml in this directory for a - description of the cells format. - -Refer to clocks/clock-bindings.txt for generic clock consumer properties. - -Example: - -pwm: pwm@3e01a000 { - compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm"; - reg = <0x3e01a000 0xc4>; - clocks = <&pwm_clk>; - #pwm-cells = <3>; -}; diff --git a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml new file mode 100644 index 000000000000..e86c8053b366 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/brcm,kona-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Kona family PWM controller + +description: + This controller has 6 channels. + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + items: + - enum: + - brcm,bcm11351-pwm + - const: brcm,kona-pwm + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + '#pwm-cells': + const: 3 + +required: + - compatible + - reg + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/bcm281xx.h> + + pwm@3e01a000 { + compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm"; + reg = <0x3e01a000 0xcc>; + clocks = <&slave_ccu BCM281XX_SLAVE_CCU_PWM>; + #pwm-cells = <3>; + }; +... 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/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,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/pfuze100.yaml b/Documentation/devicetree/bindings/regulator/pfuze100.yaml index e384e4953f0a..0eda44752cdd 100644 --- a/Documentation/devicetree/bindings/regulator/pfuze100.yaml +++ b/Documentation/devicetree/bindings/regulator/pfuze100.yaml @@ -68,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/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/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/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/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/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/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 35f0bb38f7b2..2811334515d1 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.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-consumer.yaml# 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/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/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.yaml b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml index 0d50f6a54af3..49db66801429 100644 --- a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml +++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml @@ -32,6 +32,7 @@ properties: enum: - xlnx,zynqmp-reset - xlnx,versal-reset + - xlnx,versal-net-reset "#reset-cells": const: 1 diff --git a/Documentation/devicetree/bindings/riscv/thead.yaml b/Documentation/devicetree/bindings/riscv/thead.yaml index e62f6821372e..301912dcd290 100644 --- a/Documentation/devicetree/bindings/riscv/thead.yaml +++ b/Documentation/devicetree/bindings/riscv/thead.yaml @@ -17,6 +17,10 @@ properties: 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: 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/atmel,at91rm9200-rtc.yaml b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml index 4d2bef15fb7a..c8bb2eef442d 100644 --- a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml @@ -14,13 +14,17 @@ maintainers: properties: compatible: - enum: - - atmel,at91rm9200-rtc - - atmel,at91sam9x5-rtc - - atmel,sama5d4-rtc - - atmel,sama5d2-rtc - - microchip,sam9x60-rtc - - microchip,sama7g5-rtc + oneOf: + - enum: + - atmel,at91rm9200-rtc + - atmel,at91sam9x5-rtc + - atmel,sama5d4-rtc + - atmel,sama5d2-rtc + - microchip,sam9x60-rtc + - microchip,sama7g5-rtc + - items: + - const: microchip,sam9x7-rtc + - const: microchip,sam9x60-rtc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/rtc/intersil,isl12022.yaml b/Documentation/devicetree/bindings/rtc/intersil,isl12022.yaml new file mode 100644 index 000000000000..c2d1441ef273 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/intersil,isl12022.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/intersil,isl12022.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intersil ISL12022 Real-time Clock + +maintainers: + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +properties: + compatible: + const: isil,isl12022 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#clock-cells': + const: 0 + + isil,battery-trip-levels-microvolt: + description: + The battery voltages at which the first alarm and second alarm + should trigger (normally ~85% and ~75% of nominal V_BAT). + items: + - enum: [2125000, 2295000, 2550000, 2805000, 3060000, 4250000, 4675000] + - enum: [1875000, 2025000, 2250000, 2475000, 2700000, 3750000, 4125000] + +required: + - compatible + - reg + +allOf: + - $ref: rtc.yaml# + # If #clock-cells is present, interrupts must not be present + - if: + required: + - '#clock-cells' + then: + properties: + interrupts: false + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc@6f { + compatible = "isil,isl12022"; + reg = <0x6f>; + interrupts-extended = <&gpio1 5 IRQ_TYPE_LEVEL_LOW>; + isil,battery-trip-levels-microvolt = <2550000>, <2250000>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/rtc/maxim,ds3231.txt b/Documentation/devicetree/bindings/rtc/maxim,ds3231.txt deleted file mode 100644 index 85be53a42180..000000000000 --- a/Documentation/devicetree/bindings/rtc/maxim,ds3231.txt +++ /dev/null @@ -1,38 +0,0 @@ -* Maxim DS3231 Real Time Clock - -Required properties: -- compatible: Should contain "maxim,ds3231". -- reg: I2C address for chip. - -Optional property: -- #clock-cells: Should be 1. -- clock-output-names: - overwrite the default clock names "ds3231_clk_sqw" and "ds3231_clk_32khz". - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. Following indices are allowed: - - 0: square-wave output on the SQW pin - - 1: square-wave output on the 32kHz pin - -- interrupts: rtc alarm/event interrupt. When this property is selected, - clock on the SQW pin cannot be used. - -Example: - -ds3231: ds3231@51 { - compatible = "maxim,ds3231"; - reg = <0x68>; - #clock-cells = <1>; -}; - -device1 { -... - clocks = <&ds3231 0>; -... -}; - -device2 { -... - clocks = <&ds3231 1>; -... -}; diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml index bcb230027622..2d9fe5a75b06 100644 --- a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml @@ -18,6 +18,7 @@ properties: - nxp,pca2129 - nxp,pcf2127 - nxp,pcf2129 + - nxp,pcf2131 reg: maxItems: 1 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/st,m48t86.yaml b/Documentation/devicetree/bindings/rtc/st,m48t86.yaml new file mode 100644 index 000000000000..e3e12fa23380 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/st,m48t86.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/st,m48t86.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ST M48T86 / Dallas DS12887 RTC with SRAM + +maintainers: + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +allOf: + - $ref: rtc.yaml + +properties: + compatible: + enum: + - st,m48t86 + + reg: + items: + - description: index register + - description: data register + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + rtc@10800000 { + compatible = "st,m48t86"; + reg = <0x10800000 0x1>, <0x11700000 0x1>; + }; + +... diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml index 9af77f21bb7f..2a65f31ac5a0 100644 --- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml @@ -45,8 +45,6 @@ properties: - isil,isl1208 # Intersil ISL1218 Low Power RTC with Battery Backed SRAM - isil,isl1218 - # Intersil ISL12022 Real-time Clock - - isil,isl12022 # Real Time Clock Module with I2C-Bus - microcrystal,rv3029 # Real Time Clock 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/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/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/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/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/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/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml index 9dc8e48c8af4..d1c7c2be865f 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml @@ -77,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,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,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index 65c02a7fef80..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,12 +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: @@ -109,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/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/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/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-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,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/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/dialog,da7219.yaml b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml index bb5af48ab1e1..eb7d219e2c86 100644 --- a/Documentation/devicetree/bindings/sound/dialog,da7219.yaml +++ b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml @@ -74,7 +74,7 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 dlg,mic-amp-in-sel: - enum: ["diff", "se_p", "se_n"] + enum: [diff, se_p, se_n] description: Mic input source type. @@ -123,7 +123,7 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 dlg,jack-ins-det-pty: - enum: ["low", "high"] + enum: [low, high] description: Polarity for jack insertion detection. $ref: /schemas/types.yaml#/definitions/string diff --git a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml index bdde68a1059c..a680d7aff237 100644 --- a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml @@ -14,7 +14,13 @@ properties: pattern: "^easrc@.*" compatible: - const: fsl,imx8mn-easrc + oneOf: + - enum: + - fsl,imx8mn-easrc + - items: + - enum: + - fsl,imx8mp-easrc + - const: fsl,imx8mn-easrc reg: maxItems: 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/google,sc7180-trogdor.yaml b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml index 666a95ac22c8..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 @@ -86,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/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 e6cb711ece77..90520f89208b 100644 --- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml @@ -25,6 +25,12 @@ 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 @@ -135,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 @@ -176,6 +182,7 @@ 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 diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml index 05e532b5d50a..43b3b67bdf3b 100644 --- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml @@ -9,23 +9,19 @@ title: MediaTek MT8188 ASoC sound card maintainers: - Trevor Wu <trevor.wu@mediatek.com> +allOf: + - $ref: sound-card-common.yaml# + properties: compatible: enum: - mediatek,mt8188-mt6359-evb - mediatek,mt8188-nau8825 - 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 - 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 @@ -86,7 +82,7 @@ patternProperties: required: - link-name -additionalProperties: false +unevaluatedProperties: false required: - compatible @@ -96,6 +92,7 @@ examples: - | sound { compatible = "mediatek,mt8188-mt6359-evb"; + model = "MT6359-EVB"; mediatek,platform = <&afe>; pinctrl-names = "default"; pinctrl-0 = <&aud_pins_default>; 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/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/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/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/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/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 a970fd264b21..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,15 +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: items: - description: Optional controller resets + - description: controller reset of Sampling rate + minItems: 1 dmas: items: @@ -51,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: @@ -66,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/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/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 index 8d60e4e236d6..a69e6c223308 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml +++ b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml @@ -29,7 +29,7 @@ properties: reg: description: I2C address, in multiple tas2781s case, all the i2c address - aggreate as one Audio Device to support multiple audio slots. + aggregate as one Audio Device to support multiple audio slots. maxItems: 8 minItems: 1 items: 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/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 fb44b89a754e..7d60a9654912 100644 --- a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml +++ b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml @@ -159,7 +159,7 @@ 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 @@ -176,7 +176,7 @@ 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 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 4f15f9a0cc34..cca81f89e252 100644 --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml @@ -86,7 +86,17 @@ 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: 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/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 b7552739b554..d4b61b0e8301 100644 --- a/Documentation/devicetree/bindings/spi/spi-cadence.yaml +++ b/Documentation/devicetree/bindings/spi/spi-cadence.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-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/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/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/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/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/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/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index ba2bfb547909..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 @@ -193,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 @@ -291,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 @@ -315,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 bdfa86a0cc98..462ead5a1cec 100644 --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml @@ -29,6 +29,7 @@ properties: - qcom,sa8775p-ufshc - qcom,sc8280xp-ufshc - qcom,sdm845-ufshc + - qcom,sm6115-ufshc - qcom,sm6350-ufshc - qcom,sm8150-ufshc - qcom,sm8250-ufshc @@ -79,6 +80,11 @@ properties: minItems: 1 maxItems: 2 + reg-names: + items: + - const: std + - const: ice + required-opps: maxItems: 1 @@ -134,6 +140,8 @@ allOf: reg: minItems: 1 maxItems: 1 + reg-names: + maxItems: 1 - if: properties: @@ -162,6 +170,10 @@ allOf: reg: minItems: 2 maxItems: 2 + reg-names: + minItems: 2 + required: + - reg-names - if: properties: @@ -190,6 +202,37 @@ 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 @@ -274,5 +317,6 @@ examples: <0 0>, <0 0>, <0 0>; + qcom,ice = <&ice>; }; }; 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 782402800d4a..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 @@ -76,11 +77,11 @@ properties: clocks: minItems: 1 - maxItems: 2 + maxItems: 3 clock-names: minItems: 1 - maxItems: 2 + maxItems: 3 dr_mode: true @@ -167,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. @@ -292,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/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/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml index b956bb5fada7..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 @@ -67,6 +68,7 @@ properties: - 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 be268e23ca79..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 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/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/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index ae24dac78d9a..67591057f234 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -14,6 +14,7 @@ properties: items: - enum: - qcom,ipq4019-dwc3 + - qcom,ipq5332-dwc3 - qcom,ipq6018-dwc3 - qcom,ipq8064-dwc3 - qcom,ipq8074-dwc3 @@ -82,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 @@ -246,6 +238,7 @@ allOf: compatible: contains: enum: + - qcom,ipq5332-dwc3 - qcom,msm8994-dwc3 - qcom,qcs404-dwc3 then: @@ -290,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: @@ -410,6 +411,7 @@ allOf: compatible: contains: enum: + - qcom,ipq5332-dwc3 - qcom,sdm660-dwc3 then: properties: 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/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/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/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 1dfafc339ddd..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,.*": @@ -1155,6 +1157,8 @@ patternProperties: description: Shenzhen Roofull Technology Co, Ltd "^roseapplepi,.*": description: RoseapplePi.org + "^saef,.*": + description: Saef Technology Limited "^samsung,.*": description: Samsung Semiconductor "^samtec,.*": 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/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/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/driver-api/basics.rst b/Documentation/driver-api/basics.rst index 7671b531ba1a..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 ------------------ 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/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/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/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/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/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/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt index bf0124fae643..c4581c2edb28 100644 --- a/Documentation/features/debug/KASAN/arch-support.txt +++ b/Documentation/features/debug/KASAN/arch-support.txt @@ -13,7 +13,7 @@ | csky: | TODO | | hexagon: | TODO | | ia64: | TODO | - | loongarch: | TODO | + | loongarch: | ok | | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | diff --git a/Documentation/features/debug/kcov/arch-support.txt b/Documentation/features/debug/kcov/arch-support.txt index ffcc9f2b1d74..de84cefbcdd3 100644 --- a/Documentation/features/debug/kcov/arch-support.txt +++ b/Documentation/features/debug/kcov/arch-support.txt @@ -13,7 +13,7 @@ | csky: | TODO | | hexagon: | TODO | | ia64: | TODO | - | loongarch: | TODO | + | loongarch: | ok | | m68k: | TODO | | microblaze: | TODO | | mips: | ok | diff --git a/Documentation/features/debug/kgdb/arch-support.txt b/Documentation/features/debug/kgdb/arch-support.txt index 958498f9f2a4..5e91ec78c80b 100644 --- a/Documentation/features/debug/kgdb/arch-support.txt +++ b/Documentation/features/debug/kgdb/arch-support.txt @@ -13,7 +13,7 @@ | csky: | TODO | | hexagon: | ok | | 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/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/btrfs.rst b/Documentation/filesystems/btrfs.rst index 992eddb0e11b..a81db8f54d68 100644 --- a/Documentation/filesystems/btrfs.rst +++ b/Documentation/filesystems/btrfs.rst @@ -37,7 +37,6 @@ For more information please refer to the documentation site or wiki https://btrfs.readthedocs.io - https://btrfs.wiki.kernel.org that maintains information about administration tasks, frequently asked questions, use cases, mount options, comprehensible changelogs, features, 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/ceph.rst b/Documentation/filesystems/ceph.rst index 76ce938e7024..085f309ece60 100644 --- a/Documentation/filesystems/ceph.rst +++ b/Documentation/filesystems/ceph.rst @@ -57,6 +57,16 @@ a snapshot on any subdirectory (and its nested contents) in the system. Snapshot creation and deletion are as simple as 'mkdir .snap/foo' and 'rmdir .snap/foo'. +Snapshot names have two limitations: + +* They can not start with an underscore ('_'), as these names are reserved + for internal usage by the MDS. +* They can not exceed 240 characters in size. This is because the MDS makes + use of long snapshot names internally, which follow the format: + `_<SNAPSHOT-NAME>_<INODE-NUMBER>`. Since filenames in general can't have + more than 255 characters, and `<node-id>` takes 13 characters, the long + snapshot names can take as much as 255 - 1 - 1 - 13 = 240. + Ceph also provides some recursive accounting on directories for nested files and bytes. That is, a 'getfattr -d foo' on any directory in the system will reveal the total number of nested regular files and 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/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 9359978a5af2..d32c6209685d 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -359,7 +359,7 @@ errors=%s Specify f2fs behavior on critical errors. This supports modes: ====================== =============== =============== ======== mode continue remount-ro panic ====================== =============== =============== ======== - access ops normal noraml N/A + 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 @@ -480,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. @@ -792,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 cb845e8e5435..13e4b18e5dbb 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -326,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 ====================== 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 ed148919e11a..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); @@ -551,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 @@ -628,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 @@ -657,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 3d97b8d8f735..4b30daee399a 100644 --- a/Documentation/filesystems/nfs/exporting.rst +++ b/Documentation/filesystems/nfs/exporting.rst @@ -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/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 eb7d2c88ddec..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 @@ -235,7 +235,7 @@ Mount options: Redirects are not created and not followed. - "redirect_dir=off": If "redirect_always_follow" is enabled in the kernel/module config, - this "off" traslates to "follow", otherwise it translates to "nofollow". + 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 @@ -405,6 +405,53 @@ 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 -------------------------- @@ -610,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 cb2a97e49872..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); @@ -1126,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/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/driver-misc.rst b/Documentation/gpu/amdgpu/driver-misc.rst index be131e963d87..4321c38fef21 100644 --- a/Documentation/gpu/amdgpu/driver-misc.rst +++ b/Documentation/gpu/amdgpu/driver-misc.rst @@ -11,19 +11,19 @@ via sysfs product_name ------------ -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c :doc: product_name product_number -------------- -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c - :doc: product_name +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c + :doc: product_number serial_number ------------- -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c :doc: serial_number unique_id 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/automated_testing.rst b/Documentation/gpu/automated_testing.rst new file mode 100644 index 000000000000..469b6fb65c30 --- /dev/null +++ b/Documentation/gpu/automated_testing.rst @@ -0,0 +1,144 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +========================================= +Automated testing of the DRM subsystem +========================================= + +Introduction +============ + +Making sure that changes to the core or drivers don't introduce regressions can +be very time-consuming when lots of different hardware configurations need to +be tested. Moreover, it isn't practical for each person interested in this +testing to have to acquire and maintain what can be a considerable amount of +hardware. + +Also, it is desirable for developers to check for regressions in their code by +themselves, instead of relying on the maintainers to find them and then +reporting back. + +There are facilities in gitlab.freedesktop.org to automatically test Mesa that +can be used as well for testing the DRM subsystem. This document explains how +people interested in testing it can use this shared infrastructure to save +quite some time and effort. + + +Relevant files +============== + +drivers/gpu/drm/ci/gitlab-ci.yml +-------------------------------- + +This is the root configuration file for GitLab CI. Among other less interesting +bits, it specifies the specific version of the scripts to be used. There are +some variables that can be modified to change the behavior of the pipeline: + +DRM_CI_PROJECT_PATH + Repository that contains the Mesa software infrastructure for CI + +DRM_CI_COMMIT_SHA + A particular revision to use from that repository + +UPSTREAM_REPO + URL to git repository containing the target branch + +TARGET_BRANCH + Branch to which this branch is to be merged into + +IGT_VERSION + Revision of igt-gpu-tools being used, from + https://gitlab.freedesktop.org/drm/igt-gpu-tools + +drivers/gpu/drm/ci/testlist.txt +------------------------------- + +IGT tests to be run on all drivers (unless mentioned in a driver's \*-skips.txt +file, see below). + +drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-fails.txt +---------------------------------------------------------- + +Lists the known failures for a given driver on a specific hardware revision. + +drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-flakes.txt +----------------------------------------------------------- + +Lists the tests that for a given driver on a specific hardware revision are +known to behave unreliably. These tests won't cause a job to fail regardless of +the result. They will still be run. + +drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt +----------------------------------------------------------- + +Lists the tests that won't be run for a given driver on a specific hardware +revision. These are usually tests that interfere with the running of the test +list due to hanging the machine, causing OOM, taking too long, etc. + + +How to enable automated testing on your tree +============================================ + +1. Create a Linux tree in https://gitlab.freedesktop.org/ if you don't have one +yet + +2. In your kernel repo's configuration (eg. +https://gitlab.freedesktop.org/janedoe/linux/-/settings/ci_cd), change the +CI/CD configuration file from .gitlab-ci.yml to +drivers/gpu/drm/ci/gitlab-ci.yml. + +3. Next time you push to this repository, you will see a CI pipeline being +created (eg. https://gitlab.freedesktop.org/janedoe/linux/-/pipelines) + +4. The various jobs will be run and when the pipeline is finished, all jobs +should be green unless a regression has been found. + + +How to update test expectations +=============================== + +If your changes to the code fix any tests, you will have to remove one or more +lines from one or more of the files in +drivers/gpu/drm/ci/${DRIVER_NAME}_*_fails.txt, for each of the test platforms +affected by the change. + + +How to expand coverage +====================== + +If your code changes make it possible to run more tests (by solving reliability +issues, for example), you can remove tests from the flakes and/or skips lists, +and then the expected results if there are any known failures. + +If there is a need for updating the version of IGT being used (maybe you have +added more tests to it), update the IGT_VERSION variable at the top of the +gitlab-ci.yml file. + + +How to test your changes to the scripts +======================================= + +For testing changes to the scripts in the drm-ci repo, change the +DRM_CI_PROJECT_PATH and DRM_CI_COMMIT_SHA variables in +drivers/gpu/drm/ci/gitlab-ci.yml to match your fork of the project (eg. +janedoe/drm-ci). This fork needs to be in https://gitlab.freedesktop.org/. + + +How to incorporate external fixes in your testing +================================================= + +Often, regressions in other trees will prevent testing changes local to the +tree under test. These fixes will be automatically merged in during the build +jobs from a branch in the target tree that is named as +${TARGET_BRANCH}-external-fixes. + +If the pipeline is not in a merge request and a branch with the same name +exists in the local tree, commits from that branch will be merged in as well. + + +How to deal with automated testing labs that may be down +======================================================== + +If a hardware farm is down and thus causing pipelines to fail that would +otherwise pass, one can disable all jobs that would be submitted to that farm +by editing the file at +https://gitlab.freedesktop.org/gfx-ci/lab-status/-/blob/main/lab-status.yml. 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-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index 8d963cd7c1b7..7aca5c7a7b1d 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 @@ -119,7 +119,7 @@ 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 ^^^^^^ 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/index.rst b/Documentation/gpu/index.rst index eee5996acf2c..e45ff0915246 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -17,6 +17,7 @@ GPU Driver Developer's Guide backlight vga-switcheroo vgaarbiter + automated_testing todo rfc/index 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/todo.rst b/Documentation/gpu/todo.rst index 139980487ccf..03fe5d1247be 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -69,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 @@ -185,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 @@ -248,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 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/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/index.rst b/Documentation/hwmon/index.rst index 042e1cf9501b..88dadea85cfc 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -78,6 +78,7 @@ Hardware Monitoring Kernel Drivers gxp-fan-ctrl hih6130 hp-wmi-sensors + hs3001 ibmaem ibm-cffps ibmpowernv @@ -195,7 +196,6 @@ Hardware Monitoring Kernel Drivers shtc1 sis5595 sl28cpld - smm665 smpro-hwmon smsc47b397 smsc47m192 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/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/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/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/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/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 ec0ddfb9cdd3..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,20 +33,18 @@ 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' 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/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 4bfdf1d30c4a..a20383d01a95 100644 --- a/Documentation/mm/damon/design.rst +++ b/Documentation/mm/damon/design.rst @@ -380,12 +380,24 @@ 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). -As of this writing, anonymous page type and memory cgroup type are supported by -the feature. Some filter target types can require additional arguments. For -example, the memory cgroup filter type asks users to specify the file path of -the memory cgroup for the filter. Hence, users can apply specific schemes to -only anonymous pages, non-anonymous pages, pages of specific cgroups, all pages -excluding those of specific cgroups, and any combination of those. +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 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 e35af7805be5..f1ce67a26615 100644 --- a/Documentation/mm/page_migration.rst +++ b/Documentation/mm/page_migration.rst @@ -180,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/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst index a834fad9de12..e4f6972eb6c0 100644 --- a/Documentation/mm/split_page_table_lock.rst +++ b/Documentation/mm/split_page_table_lock.rst @@ -58,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 @@ -68,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 @@ -77,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 @@ -97,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 57d1c1c4918f..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. @@ -274,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 43b769c98fb2..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. @@ -321,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 1cbb448d2f1c..3d338c48bf21 100644 --- a/Documentation/netlink/genetlink.yaml +++ b/Documentation/netlink/genetlink.yaml @@ -243,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 5d46ca966979..d1ebcd927149 100644 --- a/Documentation/netlink/specs/devlink.yaml +++ b/Documentation/netlink/specs/devlink.yaml @@ -6,6 +6,16 @@ protocol: genetlink-legacy doc: Partial family for Devlink. +definitions: + - + type: enum + name: sb-pool-type + entries: + - + name: ingress + - + name: egress + attribute-sets: - name: devlink @@ -25,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 @@ -56,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 @@ -103,6 +178,21 @@ attribute-sets: 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 @@ -165,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 @@ -183,18 +278,212 @@ 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 @@ -204,3 +493,181 @@ operations: - 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/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_vport.yaml b/Documentation/netlink/specs/ovs_vport.yaml index 17336455bec1..f65ce62cd60d 100644 --- a/Documentation/netlink/specs/ovs_vport.yaml +++ b/Documentation/netlink/specs/ovs_vport.yaml @@ -82,6 +82,10 @@ attribute-sets: enum-name: ovs-vport-attr attributes: - + name: unspec + type: unused + value: 0 + - name: port-no type: u32 - @@ -121,9 +125,34 @@ operations: name-prefix: ovs-vport-cmd- list: - + 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 1cc35de336a4..dceeb0d763aa 100644 --- a/Documentation/networking/af_xdp.rst +++ b/Documentation/networking/af_xdp.rst @@ -462,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 @@ -541,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/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 94ecb67c0885..9827e816084b 100644 --- a/Documentation/networking/device_drivers/ethernet/index.rst +++ b/Documentation/networking/device_drivers/ethernet/index.rst @@ -16,6 +16,7 @@ Contents: 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/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst index bfd233cfac35..1e196cb9ce25 100644 --- a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst +++ b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst @@ -332,3 +332,11 @@ Setup HTB offload # 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 a395df9c2751..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). 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 a4edf908b707..000000000000 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst +++ /dev/null @@ -1,313 +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. -- 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/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 6e3f5ee8b0d0..b617e93d7c2c 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst @@ -190,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 4a010a7cde7f..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. @@ -2287,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/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/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 d33b554ca7ba..a50834798454 100644 --- a/Documentation/powerpc/index.rst +++ b/Documentation/powerpc/index.rst @@ -36,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/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 5561dae94f85..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.68.2 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 @@ -482,7 +482,7 @@ E2fsprogs JFSutils -------- -- <http://jfs.sourceforge.net/> +- <https://jfs.sourceforge.net/> Reiserfsprogs ------------- @@ -503,7 +503,7 @@ Pcmciautils Quota-tools ----------- -- <http://sourceforge.net/projects/linuxquota/> +- <https://sourceforge.net/projects/linuxquota/> Intel P6 microcode @@ -524,7 +524,7 @@ FUSE mcelog ------ -- <http://www.mcelog.org/> +- <https://www.mcelog.org/> cpio ---- @@ -544,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 -------- @@ -559,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..ac7c52f130c9 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -251,10 +251,10 @@ an involved disclosed party. The current ambassadors list: IBM Z Christian Borntraeger <borntraeger@de.ibm.com> Intel Tony Luck <tony.luck@intel.com> Qualcomm Trilok Soni <tsoni@codeaurora.org> + RISC-V Palmer Dabbelt <palmer@dabbelt.com> 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 +263,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/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 9992bfd7eaa3..976391cec528 100644 --- a/Documentation/process/maintainer-handbooks.rst +++ b/Documentation/process/maintainer-handbooks.rst @@ -17,5 +17,6 @@ Contents: maintainer-netdev maintainer-soc + maintainer-soc-clean-dts maintainer-tip maintainer-kvm-x86 diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index 2ab843cde830..09dcf6377c27 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: - https://patchwork.hopto.org/net-next.html + https://netdev.bots.linux.dev/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 @@ -120,7 +120,37 @@ queue for netdev: https://patchwork.kernel.org/project/netdevbpf/list/ The "State" field will tell you exactly where things are at with your -patch. Patches are indexed by the ``Message-ID`` header of the emails +patch: + +================== ============================================================= +Patch state Description +================== ============================================================= +New, Under review pending review, patch is in the maintainer’s queue for + review; the two states are used interchangeably (depending on + the exact co-maintainer handling patchwork at the time) +Accepted patch was applied to the appropriate networking tree, this is + usually set automatically by the pw-bot +Needs ACK waiting for an ack from an area expert or testing +Changes requested patch has not passed the review, new revision is expected + with appropriate code and commit message changes +Rejected patch has been rejected and new revision is not expected +Not applicable patch is expected to be applied outside of the networking + subsystem +Awaiting upstream patch should be reviewed and handled by appropriate + sub-maintainer, who will send it on to the networking trees; + patches set to ``Awaiting upstream`` in netdev's patchwork + will usually remain in this state, whether the sub-maintainer + requested changes, accepted or rejected the patch +Deferred patch needs to be reposted later, usually due to dependency + or because it was posted for a closed tree +Superseded new version of the patch was posted, usually set by the + pw-bot +RFC not to be applied, usually not in maintainer’s review queue, + pw-bot can automatically set patches to this state based + on subject tags +================== ============================================================= + +Patches are indexed by the ``Message-ID`` header of the emails which carried them so if you have trouble finding your patch append the value of ``Message-ID`` to the URL above. @@ -155,7 +185,7 @@ must match the MAINTAINERS entry) and a handful of senior reviewers. Bot records its activity here: - https://patchwork.hopto.org/pw-bot.html + https://netdev.bots.linux.dev/pw-bot.html Review timelines ~~~~~~~~~~~~~~~~ @@ -167,6 +197,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 ~~~~~~~~~~~~~~~~~ @@ -359,6 +391,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 index 49f08289d62c..12637530d68f 100644 --- a/Documentation/process/maintainer-soc.rst +++ b/Documentation/process/maintainer-soc.rst @@ -133,8 +133,8 @@ with the dt-bindings that describe the ABI. Please read the section 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, as it has the advantage of being a newer -architecture, ``make dtbs_check W=1`` is required to not add any new warnings. +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. 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/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 933c715065d6..a52996b22f75 100644 --- a/Documentation/riscv/hwprobe.rst +++ b/Documentation/riscv/hwprobe.rst @@ -87,13 +87,12 @@ The following keys are defined: emulated via software, either in or below the kernel. These accesses are always extremely slow. - * :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are supported - in hardware, but are slower than the cooresponding aligned accesses - sequences. + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are slower + than equivalent byte accesses. Misaligned accesses may be supported + directly in hardware, or trapped and emulated by software. - * :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are supported - in hardware and are faster than the cooresponding aligned accesses - sequences. + * :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are faster + than equivalent byte accesses. * :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are not supported at all and will generate a misaligned address fault. diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst index 81cf6e616476..4dab0cb4b900 100644 --- a/Documentation/riscv/index.rst +++ b/Documentation/riscv/index.rst @@ -6,6 +6,7 @@ RISC-V architecture :maxdepth: 1 acpi + boot boot-image-header vm-layout hwprobe diff --git a/Documentation/riscv/vector.rst b/Documentation/riscv/vector.rst index 165b7ed0ac4f..75dd88a62e1d 100644 --- a/Documentation/riscv/vector.rst +++ b/Documentation/riscv/vector.rst @@ -13,7 +13,7 @@ order to support the use of the RISC-V Vector Extension. 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 thess interfaces is not +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 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 a8931512ed98..f382914f4191 100644 --- a/Documentation/rust/quick-start.rst +++ b/Documentation/rust/quick-start.rst @@ -38,7 +38,9 @@ and run:: rustup override set $(scripts/min-tool-version.sh rustc) -Otherwise, fetch a standalone installer 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://forge.rust-lang.org/infra/other-installation-methods.html#standalone @@ -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-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/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/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 ea66b50a2b03..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 ------------------------------------------------- @@ -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 49c1f2f688f8..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 diff --git a/Documentation/sound/cards/sb-live-mixer.rst b/Documentation/sound/cards/sb-live-mixer.rst index 4dd9bfe01bd8..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). diff --git a/Documentation/sound/designs/midi-2.0.rst b/Documentation/sound/designs/midi-2.0.rst index 27d0d3dea1b0..45987f256b97 100644 --- a/Documentation/sound/designs/midi-2.0.rst +++ b/Documentation/sound/designs/midi-2.0.rst @@ -376,3 +376,191 @@ Sequencer API Extensions 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 b67a1b65855b..90a0535a932a 100644 --- a/Documentation/subsystem-apis.rst +++ b/Documentation/subsystem-apis.rst @@ -10,6 +10,20 @@ 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). +Core subsystems +--------------- + +.. toctree:: + :maxdepth: 1 + + core-api/index + driver-api/index + mm/index + power/index + scheduler/index + timers/index + locking/index + Human interfaces ---------------- @@ -22,6 +36,18 @@ Human interfaces gpu/index fb/index +Networking interfaces +--------------------- + +.. toctree:: + :maxdepth: 1 + + networking/index + netlabel/index + infiniband/index + isdn/index + mhi/index + Storage interfaces ------------------ @@ -39,22 +65,13 @@ Storage interfaces .. toctree:: :maxdepth: 1 - driver-api/index - core-api/index - locking/index accounting/index cpu-freq/index fpga/index i2c/index iio/index - isdn/index - infiniband/index leds/index - netlabel/index - networking/index pcmcia/index - power/index - timers/index spi/index w1/index watchdog/index @@ -63,12 +80,9 @@ Storage interfaces accel/index security/index crypto/index - mm/index bpf/index usb/index PCI/index misc-devices/index - scheduler/index - mhi/index peci/index wmi/index diff --git a/Documentation/tools/rtla/rtla-timerlat-top.rst b/Documentation/tools/rtla/rtla-timerlat-top.rst index 1b7cf4e3eafe..ab6cb60c9083 100644 --- a/Documentation/tools/rtla/rtla-timerlat-top.rst +++ b/Documentation/tools/rtla/rtla-timerlat-top.rst @@ -117,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-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 index 7297f9478459..8e9bebcf0a2e 100644 --- a/Documentation/trace/fprobetrace.rst +++ b/Documentation/trace/fprobetrace.rst @@ -79,9 +79,9 @@ automatically set by the given name. :: 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 :: +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 @@ -105,9 +105,47 @@ is expanded to all function arguments of the function or the tracepoint. :: # 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. +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 -------------- @@ -161,10 +199,10 @@ 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 it as below. +traceprobe event, you can trace that field as below. :: - # echo 't sched_switch comm=+1896(next):string start_time=+1728(next):u64' > dynamic_events + # echo 't sched_switch comm=next->comm:string next->start_time' > dynamic_events # head -n 20 trace | tail # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | @@ -176,13 +214,3 @@ traceprobe event, you can trace it as below. <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 - -Currently, to find the offset of a specific field in the data structure, -you need to build kernel with debuginfo and run `perf probe` command with -`-D` option. e.g. -:: - - # perf probe -D "__probestub_sched_switch next->comm:string next->start_time" - p:probe/__probestub_sched_switch __probestub_sched_switch+0 comm=+1896(%cx):string start_time=+1728(%cx):u64 - -And replace the ``%cx`` with the ``next``. diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index f606c5bd1c0d..23572f6697c0 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -2725,7 +2725,7 @@ It is default disabled. The return value of each traced function can be displayed after an equal sign "=". When encountering system call failures, it -can be verfy helpful to quickly locate the function that first +can be very helpful to quickly locate the function that first returns an error code. - hide: echo nofuncgraph-retval > trace_options 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/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/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/arch/index.rst b/Documentation/translations/zh_CN/arch/index.rst index 6fa0cb671009..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 + 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/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst index 05ef904dbcfb..8fdb20c9665b 100644 --- a/Documentation/translations/zh_CN/dev-tools/kasan.rst +++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst @@ -42,7 +42,7 @@ KASAN有三种模式: 体系架构 ~~~~~~~~ -在x86_64、arm、arm64、powerpc、riscv、s390和xtensa上支持通用KASAN, +在x86_64、arm、arm64、powerpc、riscv、s390、xtensa和loongarch上支持通用KASAN, 而基于标签的KASAN模式只在arm64上支持。 编译器 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/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/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_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/arch/arm64/amu.rst b/Documentation/translations/zh_TW/arch/arm64/amu.rst index f947a6c7369f..21ac0db63889 100644 --- a/Documentation/translations/zh_TW/arch/arm64/amu.rst +++ b/Documentation/translations/zh_TW/arch/arm64/amu.rst @@ -5,7 +5,7 @@ :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/arch/arm64/booting.txt b/Documentation/translations/zh_TW/arch/arm64/booting.txt index 24817b8b70cd..3cc8f593e006 100644 --- a/Documentation/translations/zh_TW/arch/arm64/booting.txt +++ b/Documentation/translations/zh_TW/arch/arm64/booting.txt @@ -10,7 +10,7 @@ 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/arch/arm64/booting.rst 的中文翻譯 @@ -23,7 +23,7 @@ Documentation/arch/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/arch/arm64/elf_hwcaps.rst b/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst index fca3c6ff7b93..ca7ff749a67b 100644 --- a/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst +++ b/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst @@ -5,7 +5,7 @@ :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 diff --git a/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst b/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst index 10feb329dfb8..a17858c978d6 100644 --- a/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst +++ b/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst @@ -5,7 +5,7 @@ :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/arch/arm64/index.rst b/Documentation/translations/zh_TW/arch/arm64/index.rst index 68befee14b99..a62b5f06b66c 100644 --- a/Documentation/translations/zh_TW/arch/arm64/index.rst +++ b/Documentation/translations/zh_TW/arch/arm64/index.rst @@ -4,7 +4,7 @@ :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/arch/arm64/legacy_instructions.txt b/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt index 3c915df9836c..c2d02cd5017d 100644 --- a/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt +++ b/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt @@ -11,7 +11,7 @@ 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/arch/arm64/legacy_instructions.rst 的中文翻譯 @@ -26,7 +26,7 @@ Documentation/arch/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/arch/arm64/memory.txt b/Documentation/translations/zh_TW/arch/arm64/memory.txt index 2437380a26d8..0280200e791f 100644 --- a/Documentation/translations/zh_TW/arch/arm64/memory.txt +++ b/Documentation/translations/zh_TW/arch/arm64/memory.txt @@ -10,7 +10,7 @@ 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/arch/arm64/memory.rst 的中文翻譯 @@ -24,7 +24,7 @@ Documentation/arch/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/arch/arm64/perf.rst b/Documentation/translations/zh_TW/arch/arm64/perf.rst index 3b39997a52eb..645f3944a0f4 100644 --- a/Documentation/translations/zh_TW/arch/arm64/perf.rst +++ b/Documentation/translations/zh_TW/arch/arm64/perf.rst @@ -5,7 +5,7 @@ :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/arch/arm64/silicon-errata.txt b/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt index 66c3a3506458..f6f41835a54a 100644 --- a/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt +++ b/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt @@ -10,7 +10,7 @@ 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/arch/arm64/silicon-errata.rst 的中文翻譯 @@ -23,7 +23,7 @@ Documentation/arch/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/arch/arm64/tagged-pointers.txt b/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt index b7f683f20ed1..c0be1d1e0d01 100644 --- a/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt +++ b/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt @@ -10,7 +10,7 @@ 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/arch/arm64/tagged-pointers.rst 的中文翻譯 @@ -22,7 +22,7 @@ Documentation/arch/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 b93788a2628b..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> 以下爲正文 --------------------------------------------------------------------- diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst index e7c83868e780..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 - arch/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 9d465df1f6c3..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: diff --git a/Documentation/translations/zh_TW/process/3.Early-stage.rst b/Documentation/translations/zh_TW/process/3.Early-stage.rst index 076873ca0905..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: diff --git a/Documentation/translations/zh_TW/process/4.Coding.rst b/Documentation/translations/zh_TW/process/4.Coding.rst index 7fc0344ed16b..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: 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 4fbc104a37ca..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: 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/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-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst index 81e60f4002c8..786127b1e206 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst @@ -3293,7 +3293,7 @@ AV1 Frame Restoration Type. .. c:type:: v4l2_av1_loop_restoration -AV1 Loop Restauration as described in section 6.10.15 "Loop restoration params +AV1 Loop Restoration as described in section 6.10.15 "Loop restoration params semantics" of :ref:`av1`. .. cssclass:: longtable diff --git a/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst b/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst index 541836074f94..0686413b16b2 100644 --- a/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst +++ b/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst @@ -237,7 +237,7 @@ Fish Eye sensor: :: camera projectors. As we have another field for "Laser Power" we introduced "LED Power" for extra emitter. -The "Laser mode" __u32 fiels has been split into: :: +The "Laser mode" __u32 fields has been split into: :: 1 __u8 Emitter mode 2 __u8 RFU byte 3 __u16 LED Power 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/vidioc-subdev-g-routing.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst index 2d6e3bbdd040..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 @@ -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/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.rst b/Documentation/userspace-api/netlink/intro.rst index 0955e9f203d3..7b1d401210ef 100644 --- a/Documentation/userspace-api/netlink/intro.rst +++ b/Documentation/userspace-api/netlink/intro.rst @@ -528,6 +528,8 @@ families may, however, require a larger buffer. 32kB buffer is recommended for most efficient handling of dumps (larger buffer fits more dumped objects and therefore fewer recvmsg() calls are needed). +.. _classic_netlink: + Classic Netlink =============== @@ -615,7 +617,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/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 c0ddd3035462..21a7578142a1 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 @@ -2259,6 +2259,8 @@ Errors: EINVAL invalid register ID, or no such register or used with VMs in protected virtualization mode on s390 EPERM (arm64) register access not allowed before vcpu finalization + EBUSY (riscv) changing register value not allowed after the vcpu + has run at least once ====== ============================================================ (These error codes are indicative only: do not rely on a specific error @@ -2722,7 +2724,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) @@ -3499,7 +3501,7 @@ VCPU matching underlying host. --------------------- :Capability: basic -:Architectures: arm64, mips +:Architectures: arm64, mips, riscv :Type: vcpu ioctl :Parameters: struct kvm_reg_list (in/out) :Returns: 0 on success; -1 on error @@ -5232,7 +5234,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 +5694,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 +6265,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 +6338,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 +7512,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 +7930,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 +8120,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 +8162,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 +8288,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 +8337,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. 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 4f1a1b23d99c..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 diff --git a/Documentation/virt/kvm/x86/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst index 26f62034b6f3..d47595b33fcf 100644 --- a/Documentation/virt/kvm/x86/mmu.rst +++ b/Documentation/virt/kvm/x86/mmu.rst @@ -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/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/devices/dell-wmi-ddv.rst b/Documentation/wmi/devices/dell-wmi-ddv.rst index bf963d91dd55..2fcdfcf03327 100644 --- a/Documentation/wmi/devices/dell-wmi-ddv.rst +++ b/Documentation/wmi/devices/dell-wmi-ddv.rst @@ -185,7 +185,7 @@ Performs an analysis of the battery and returns a status code: WMI method BatteryeRawAnalytics() --------------------------------- -Returns a buffer usually containg 12 blocks of analytics data. +Returns a buffer usually containing 12 blocks of analytics data. Those blocks contain: - a block number starting with 0 (u8) @@ -218,7 +218,7 @@ Returns the WMI interface version as an u32. WMI method FanSensorInformation() --------------------------------- -Returns a buffer containg fan sensor entries, terminated +Returns a buffer containing fan sensor entries, terminated with a single ``0xff``. Those entries contain: |