diff options
Diffstat (limited to 'Documentation')
819 files changed, 25647 insertions, 12997 deletions
diff --git a/Documentation/ABI/obsolete/sysfs-class-dax b/Documentation/ABI/obsolete/sysfs-class-dax index 0faf1354cd05..5bcce27458e3 100644 --- a/Documentation/ABI/obsolete/sysfs-class-dax +++ b/Documentation/ABI/obsolete/sysfs-class-dax @@ -1,7 +1,7 @@ What: /sys/class/dax/ Date: May, 2016 KernelVersion: v4.7 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: Device DAX is the device-centric analogue of Filesystem DAX (CONFIG_FS_DAX). It allows memory ranges to be allocated and mapped without need of an intervening file diff --git a/Documentation/ABI/obsolete/sysfs-cpuidle b/Documentation/ABI/obsolete/sysfs-cpuidle index e398fb5e542f..972cc11d3434 100644 --- a/Documentation/ABI/obsolete/sysfs-cpuidle +++ b/Documentation/ABI/obsolete/sysfs-cpuidle @@ -6,4 +6,4 @@ Description: with the update that cpuidle governor can be changed at runtime in default, both current_governor and current_governor_ro co-exist under /sys/devices/system/cpu/cpuidle/ file, it's duplicate so make - current_governor_ro obselete. + current_governor_ro obsolete. diff --git a/Documentation/ABI/obsolete/sysfs-kernel-fadump_registered b/Documentation/ABI/obsolete/sysfs-kernel-fadump_registered index 0360be39c98e..dae880b1a5d5 100644 --- a/Documentation/ABI/obsolete/sysfs-kernel-fadump_registered +++ b/Documentation/ABI/obsolete/sysfs-kernel-fadump_registered @@ -1,4 +1,4 @@ -This ABI is renamed and moved to a new location /sys/kernel/fadump/registered.¬ +This ABI is renamed and moved to a new location /sys/kernel/fadump/registered. What: /sys/kernel/fadump_registered Date: Feb 2012 diff --git a/Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem b/Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem index 6ce0b129ab12..ca2396edb5f1 100644 --- a/Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem +++ b/Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem @@ -1,4 +1,4 @@ -This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem.¬ +This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem. What: /sys/kernel/fadump_release_mem Date: Feb 2012 diff --git a/Documentation/ABI/removed/sysfs-bus-nfit b/Documentation/ABI/removed/sysfs-bus-nfit index ae8c1ca53828..277437005def 100644 --- a/Documentation/ABI/removed/sysfs-bus-nfit +++ b/Documentation/ABI/removed/sysfs-bus-nfit @@ -1,7 +1,7 @@ What: /sys/bus/nd/devices/regionX/nfit/ecc_unit_size Date: Aug, 2017 KernelVersion: v4.14 (Removed v4.18) -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) Size of a write request to a DIMM that will not incur a read-modify-write cycle at the memory controller. diff --git a/Documentation/ABI/removed/sysfs-kernel-uids b/Documentation/ABI/removed/sysfs-kernel-uids index dc4463f190a7..85a90b86ce1e 100644 --- a/Documentation/ABI/removed/sysfs-kernel-uids +++ b/Documentation/ABI/removed/sysfs-kernel-uids @@ -5,7 +5,7 @@ Contact: Dhaval Giani <dhaval@linux.vnet.ibm.com> Description: The /sys/kernel/uids/<uid>/cpu_shares tunable is used to set the cpu bandwidth a user is allowed. This is a - propotional value. What that means is that if there + proportional value. What that means is that if there are two users logged in, each with an equal number of shares, then they will get equal CPU bandwidth. Another example would be, if User A has shares = 1024 and user diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus b/Documentation/ABI/stable/sysfs-bus-vmbus index 42599d9fa161..3066feae1d8d 100644 --- a/Documentation/ABI/stable/sysfs-bus-vmbus +++ b/Documentation/ABI/stable/sysfs-bus-vmbus @@ -61,7 +61,7 @@ Date: September. 2017 KernelVersion: 4.14 Contact: Stephen Hemminger <sthemmin@microsoft.com> Description: Directory for per-channel information - NN is the VMBUS relid associtated with the channel. + NN is the VMBUS relid associated with the channel. What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/cpu Date: September. 2017 diff --git a/Documentation/ABI/stable/sysfs-bus-xen-backend b/Documentation/ABI/stable/sysfs-bus-xen-backend index e8b60bd766f7..480a89edfa05 100644 --- a/Documentation/ABI/stable/sysfs-bus-xen-backend +++ b/Documentation/ABI/stable/sysfs-bus-xen-backend @@ -19,7 +19,7 @@ Date: April 2011 KernelVersion: 3.0 Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Description: - The major:minor number (in hexidecimal) of the + The major:minor number (in hexadecimal) of the physical device providing the storage for this backend block device. diff --git a/Documentation/ABI/stable/sysfs-class-infiniband b/Documentation/ABI/stable/sysfs-class-infiniband index 348c4ac803ad..9b1bdfa43354 100644 --- a/Documentation/ABI/stable/sysfs-class-infiniband +++ b/Documentation/ABI/stable/sysfs-class-infiniband @@ -731,26 +731,6 @@ Description: is the irq number of "sdma3", and M is irq number of "sdma4" in the /proc/interrupts file. - -sysfs interface for Intel(R) X722 iWARP i40iw driver ----------------------------------------------------- - -What: /sys/class/infiniband/i40iwX/hw_rev -What: /sys/class/infiniband/i40iwX/hca_type -What: /sys/class/infiniband/i40iwX/board_id -Date: Jan, 2016 -KernelVersion: v4.10 -Contact: linux-rdma@vger.kernel.org -Description: - =============== ==== ======================== - hw_rev: (RO) Hardware revision number - - hca_type: (RO) Show HCA type (I40IW) - - board_id: (RO) I40IW board ID - =============== ==== ======================== - - sysfs interface for QLogic qedr NIC Driver ------------------------------------------ diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu index 33c133e2a631..516dafea03eb 100644 --- a/Documentation/ABI/stable/sysfs-devices-system-cpu +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu @@ -23,3 +23,86 @@ Description: Default value for the Data Stream Control Register (DSCR) on here). If set by a process it will be inherited by child processes. Values: 64 bit unsigned integer (bit field) + +What: /sys/devices/system/cpu/cpuX/topology/physical_package_id +Description: physical package id of cpuX. Typically corresponds to a physical + socket number, but the actual value is architecture and platform + dependent. +Values: integer + +What: /sys/devices/system/cpu/cpuX/topology/die_id +Description: the CPU die ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. +Values: integer + +What: /sys/devices/system/cpu/cpuX/topology/core_id +Description: the CPU core ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. +Values: integer + +What: /sys/devices/system/cpu/cpuX/topology/book_id +Description: the book ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. it's only used on s390. +Values: integer + +What: /sys/devices/system/cpu/cpuX/topology/drawer_id +Description: the drawer ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. it's only used on s390. +Values: integer + +What: /sys/devices/system/cpu/cpuX/topology/core_cpus +Description: internal kernel map of CPUs within the same core. + (deprecated name: "thread_siblings") +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/core_cpus_list +Description: human-readable list of CPUs within the same core. + The format is like 0-3, 8-11, 14,17. + (deprecated name: "thread_siblings_list"). +Values: decimal list. + +What: /sys/devices/system/cpu/cpuX/topology/package_cpus +Description: internal kernel map of the CPUs sharing the same physical_package_id. + (deprecated name: "core_siblings"). +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/package_cpus_list +Description: human-readable list of CPUs sharing the same physical_package_id. + The format is like 0-3, 8-11, 14,17. + (deprecated name: "core_siblings_list") +Values: decimal list. + +What: /sys/devices/system/cpu/cpuX/topology/die_cpus +Description: internal kernel map of CPUs within the same die. +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list +Description: human-readable list of CPUs within the same die. + The format is like 0-3, 8-11, 14,17. +Values: decimal list. + +What: /sys/devices/system/cpu/cpuX/topology/book_siblings +Description: internal kernel map of cpuX's hardware threads within the same + book_id. it's only used on s390. +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/book_siblings_list +Description: human-readable list of cpuX's hardware threads within the same + book_id. + The format is like 0-3, 8-11, 14,17. it's only used on s390. +Values: decimal list. + +What: /sys/devices/system/cpu/cpuX/topology/drawer_siblings +Description: internal kernel map of cpuX's hardware threads within the same + drawer_id. it's only used on s390. +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/drawer_siblings_list +Description: human-readable list of cpuX's hardware threads within the same + drawer_id. + The format is like 0-3, 8-11, 14,17. it's only used on s390. +Values: decimal list. diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index 55285c136cf0..d431e2d00472 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -173,7 +173,7 @@ What: /sys/bus/dsa/devices/wq<m>.<n>/priority Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org -Description: The priority value of this work queue, it is a vlue relative to +Description: The priority value of this work queue, it is a value relative to other work queue in the same group to control quality of service for dispatching work from multiple workqueues in the same group. diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io index fd9a8045bb0c..b2553df2e786 100644 --- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -137,7 +137,7 @@ Contact: Vadim Pasternak <vadimpmellanox.com> Description: These files show the system reset cause, as following: COMEX thermal shutdown; wathchdog power off or reset was derived by one of the next components: COMEX, switch board or by Small Form - Factor mezzanine, reset requested from ASIC, reset cuased by BIOS + Factor mezzanine, reset requested from ASIC, reset caused by BIOS reload. Value 1 in file means this is reset cause, 0 - otherwise. Only one of the above causes could be 1 at the same time, representing only last reset cause. @@ -183,7 +183,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/vpd_wp Date: January 2020 KernelVersion: 5.6 Contact: Vadim Pasternak <vadimpmellanox.com> -Description: This file allows to overwrite system VPD hardware wrtie +Description: This file allows to overwrite system VPD hardware write protection when attribute is set 1. The file is read/write. diff --git a/Documentation/ABI/testing/configfs-iio b/Documentation/ABI/testing/configfs-iio index aebda53ec0f7..1637fcb50f56 100644 --- a/Documentation/ABI/testing/configfs-iio +++ b/Documentation/ABI/testing/configfs-iio @@ -31,4 +31,4 @@ Date: April 2016 KernelVersion: 4.7 Description: Dummy IIO devices directory. Creating a directory here will result - in creating a dummy IIO device in the IIO subystem. + in creating a dummy IIO device in the IIO subsystem. diff --git a/Documentation/ABI/testing/configfs-most b/Documentation/ABI/testing/configfs-most index bc6b8bd18da4..0a4b8649aa5a 100644 --- a/Documentation/ABI/testing/configfs-most +++ b/Documentation/ABI/testing/configfs-most @@ -20,7 +20,7 @@ Description: subbuffer_size configure the sub-buffer size for this channel - (needed for synchronous and isochrnous data) + (needed for synchronous and isochronous data) num_buffers @@ -75,7 +75,7 @@ Description: subbuffer_size configure the sub-buffer size for this channel - (needed for synchronous and isochrnous data) + (needed for synchronous and isochronous data) num_buffers @@ -130,7 +130,7 @@ Description: subbuffer_size configure the sub-buffer size for this channel - (needed for synchronous and isochrnous data) + (needed for synchronous and isochronous data) num_buffers @@ -196,7 +196,7 @@ Description: subbuffer_size configure the sub-buffer size for this channel - (needed for synchronous and isochrnous data) + (needed for synchronous and isochronous data) num_buffers diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget index dc351e9af80a..b7943aa7e997 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget +++ b/Documentation/ABI/testing/configfs-usb-gadget @@ -137,7 +137,7 @@ Description: This group contains "OS String" extension handling attributes. ============= =============================================== - use flag turning "OS Desctiptors" support on/off + use flag turning "OS Descriptors" support on/off b_vendor_code one-byte value used for custom per-device and per-interface requests qw_sign an identifier to be reported as "OS String" diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc index ac5e11af79a8..889ed45be4ca 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc @@ -170,7 +170,7 @@ Description: Default color matching descriptors bMatrixCoefficients matrix used to compute luma and chroma values from the color primaries bTransferCharacteristics optoelectronic transfer - characteristic of the source picutre, + characteristic of the source picture, also called the gamma function bColorPrimaries color primaries and the reference white @@ -311,7 +311,7 @@ Description: Specific streaming header descriptors a hardware trigger interrupt event bTriggerSupport flag specifying if hardware triggering is supported - bStillCaptureMethod method of still image caputre + bStillCaptureMethod method of still image capture supported bTerminalLink id of the output terminal to which the video endpoint of this interface diff --git a/Documentation/ABI/testing/debugfs-driver-genwqe b/Documentation/ABI/testing/debugfs-driver-genwqe index 1c2f25674e8c..b45b016545d8 100644 --- a/Documentation/ABI/testing/debugfs-driver-genwqe +++ b/Documentation/ABI/testing/debugfs-driver-genwqe @@ -31,7 +31,7 @@ What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_regs Date: Oct 2013 Contact: haver@linux.vnet.ibm.com Description: Dump of the error registers before the last reset of - the card occured. + the card occurred. Only available for PF. What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid0 diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index c78fc9282876..e89c6351503c 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -153,7 +153,7 @@ KernelVersion: 5.1 Contact: ogabbay@kernel.org Description: Triggers an I2C transaction that is generated by the device's CPU. Writing to this file generates a write transaction while - reading from the file generates a read transcation + reading from the file generates a read transaction What: /sys/kernel/debug/habanalabs/hl<n>/i2c_reg Date: Jan 2019 diff --git a/Documentation/ABI/testing/evm b/Documentation/ABI/testing/evm index 3c477ba48a31..553fd8a33e56 100644 --- a/Documentation/ABI/testing/evm +++ b/Documentation/ABI/testing/evm @@ -24,7 +24,7 @@ Description: 1 Enable digital signature validation 2 Permit modification of EVM-protected metadata at runtime. Not supported if HMAC validation and - creation is enabled. + creation is enabled (deprecated). 31 Disable further runtime modification of EVM policy === ================================================== @@ -47,10 +47,38 @@ Description: will enable digital signature validation, permit modification of EVM-protected metadata and - disable all further modification of policy + disable all further modification of policy. This option is now + deprecated in favor of:: - Note that once a key has been loaded, it will no longer be - possible to enable metadata modification. + echo 0x80000002 ><securityfs>/evm + + as the outstanding issues that prevent the usage of EVM portable + signatures have been solved. + + Echoing a value is additive, the new value is added to the + existing initialization flags. + + For example, after:: + + echo 2 ><securityfs>/evm + + another echo can be performed:: + + echo 1 ><securityfs>/evm + + and the resulting value will be 3. + + Note that once an HMAC key has been loaded, it will no longer + be possible to enable metadata modification. Signaling that an + HMAC key has been loaded will clear the corresponding flag. + For example, if the current value is 6 (2 and 4 set):: + + echo 1 ><securityfs>/evm + + will set the new value to 3 (4 cleared). + + Loading an HMAC key is the only way to disable metadata + modification. Until key loading has been signaled EVM can not create or validate the 'security.evm' xattr, but returns diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 2fe7490ad6a8..0b6a2e6e8fbb 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -24,3 +24,106 @@ Description: (RO) "Persistent Only Capacity" as bytes. Represents the identically named field in the Identify Memory Device Output Payload in the CXL-2.0 specification. + +What: /sys/bus/cxl/devices/*/devtype +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + CXL device objects export the devtype attribute which mirrors + the same value communicated in the DEVTYPE environment variable + for uevents for devices on the "cxl" bus. + +What: /sys/bus/cxl/devices/portX/uport +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + CXL port objects are enumerated from either a platform firmware + device (ACPI0017 and ACPI0016) or PCIe switch upstream port with + CXL component registers. The 'uport' symlink connects the CXL + portX object to the device that published the CXL port + capability. + +What: /sys/bus/cxl/devices/portX/dportY +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + CXL port objects are enumerated from either a platform firmware + device (ACPI0017 and ACPI0016) or PCIe switch upstream port with + CXL component registers. The 'dportY' symlink identifies one or + more downstream ports that the upstream port may target in its + decode of CXL memory resources. The 'Y' integer reflects the + hardware port unique-id used in the hardware decoder target + list. + +What: /sys/bus/cxl/devices/decoderX.Y +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + CXL decoder objects are enumerated from either a platform + firmware description, or a CXL HDM decoder register set in a + PCIe device (see CXL 2.0 section 8.2.5.12 CXL HDM Decoder + Capability Structure). The 'X' in decoderX.Y represents the + cxl_port container of this decoder, and 'Y' represents the + instance id of a given decoder resource. + +What: /sys/bus/cxl/devices/decoderX.Y/{start,size} +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + The 'start' and 'size' attributes together convey the physical + address base and number of bytes mapped in the decoder's decode + window. For decoders of devtype "cxl_decoder_root" the address + range is fixed. For decoders of devtype "cxl_decoder_switch" the + address is bounded by the decode range of the cxl_port ancestor + of the decoder's cxl_port, and dynamically updates based on the + active memory regions in that address space. + +What: /sys/bus/cxl/devices/decoderX.Y/locked +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + CXL HDM decoders have the capability to lock the configuration + until the next device reset. For decoders of devtype + "cxl_decoder_root" there is no standard facility to unlock them. + For decoders of devtype "cxl_decoder_switch" a secondary bus + reset, of the PCIe bridge that provides the bus for this + decoders uport, unlocks / resets the decoder. + +What: /sys/bus/cxl/devices/decoderX.Y/target_list +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + Display a comma separated list of the current decoder target + configuration. The list is ordered by the current configured + interleave order of the decoder's dport instances. Each entry in + the list is a dport id. + +What: /sys/bus/cxl/devices/decoderX.Y/cap_{pmem,ram,type2,type3} +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + When a CXL decoder is of devtype "cxl_decoder_root", it + represents a fixed memory window identified by platform + firmware. A fixed window may only support a subset of memory + types. The 'cap_*' attributes indicate whether persistent + memory, volatile memory, accelerator memory, and / or expander + memory may be mapped behind this decoder's memory window. + +What: /sys/bus/cxl/devices/decoderX.Y/target_type +Date: June, 2021 +KernelVersion: v5.14 +Contact: linux-cxl@vger.kernel.org +Description: + When a CXL decoder is of devtype "cxl_decoder_switch", it can + optionally decode either accelerator memory (type-2) or expander + memory (type-3). The 'target_type' attribute indicates the + current setting which may dynamically change based on what + memory regions are activated in this decode hierarchy. diff --git a/Documentation/ABI/testing/sysfs-bus-fsi b/Documentation/ABI/testing/sysfs-bus-fsi index d148214181a1..76e0caa0c2b3 100644 --- a/Documentation/ABI/testing/sysfs-bus-fsi +++ b/Documentation/ABI/testing/sysfs-bus-fsi @@ -12,7 +12,7 @@ KernelVersion: 4.12 Contact: linux-fsi@lists.ozlabs.org Description: Sends an FSI BREAK command on a master's communication - link to any connnected slaves. A BREAK resets connected + link to any connected slaves. A BREAK resets connected device's logic and preps it to receive further commands from the master. diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 267973541e72..6f98b6a9b785 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -786,7 +786,7 @@ What: /sys/.../events/in_capacitanceY_adaptive_thresh_rising_en What: /sys/.../events/in_capacitanceY_adaptive_thresh_falling_en KernelVersion: 5.13 Contact: linux-iio@vger.kernel.org -Descrption: +Description: Adaptive thresholds are similar to normal fixed thresholds but the value is expressed as an offset from a value which provides a low frequency approximation of the channel itself. @@ -798,10 +798,10 @@ What: /sys/.../in_capacitanceY_adaptive_thresh_rising_timeout What: /sys/.../in_capacitanceY_adaptive_thresh_falling_timeout KernelVersion: 5.11 Contact: linux-iio@vger.kernel.org -Descrption: +Description: When adaptive thresholds are used, the tracking signal may adjust too slowly to step changes in the raw signal. - *_timeout (in seconds) specifies a time for which the + Thus these specify the time in seconds for which the difference between the slow tracking signal and the raw signal is allowed to remain out-of-range before a reset event occurs in which the tracking signal is made equal diff --git a/Documentation/ABI/testing/sysfs-bus-nfit b/Documentation/ABI/testing/sysfs-bus-nfit index 63ef0b9ecce7..e7282d184a74 100644 --- a/Documentation/ABI/testing/sysfs-bus-nfit +++ b/Documentation/ABI/testing/sysfs-bus-nfit @@ -5,7 +5,7 @@ Interface Table (NFIT)' section in the ACPI specification What: /sys/bus/nd/devices/nmemX/nfit/serial Date: Jun, 2015 KernelVersion: v4.2 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) Serial number of the NVDIMM (non-volatile dual in-line memory module), assigned by the module vendor. @@ -14,7 +14,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/handle Date: Apr, 2015 KernelVersion: v4.2 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) The address (given by the _ADR object) of the device on its parent bus of the NVDIMM device containing the NVDIMM region. @@ -23,7 +23,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/device Date: Apr, 2015 KernelVersion: v4.1 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) Device id for the NVDIMM, assigned by the module vendor. @@ -31,7 +31,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/rev_id Date: Jun, 2015 KernelVersion: v4.2 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) Revision of the NVDIMM, assigned by the module vendor. @@ -39,7 +39,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/phys_id Date: Apr, 2015 KernelVersion: v4.2 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) Handle (i.e., instance number) for the SMBIOS (system management BIOS) Memory Device structure describing the NVDIMM @@ -49,7 +49,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/flags Date: Jun, 2015 KernelVersion: v4.2 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) The flags in the NFIT memory device sub-structure indicate the state of the data on the nvdimm relative to its energy @@ -68,7 +68,7 @@ What: /sys/bus/nd/devices/nmemX/nfit/format1 What: /sys/bus/nd/devices/nmemX/nfit/formats Date: Apr, 2016 KernelVersion: v4.7 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) The interface codes indicate support for persistent memory mapped directly into system physical address space and / or a @@ -84,7 +84,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/vendor Date: Apr, 2016 KernelVersion: v4.7 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) Vendor id of the NVDIMM. @@ -92,7 +92,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/dsm_mask Date: May, 2016 KernelVersion: v4.7 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) The bitmask indicates the supported device specific control functions relative to the NVDIMM command family supported by the @@ -102,7 +102,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/family Date: Apr, 2016 KernelVersion: v4.7 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) Displays the NVDIMM family command sets. Values 0, 1, 2 and 3 correspond to NVDIMM_FAMILY_INTEL, @@ -118,7 +118,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/id Date: Apr, 2016 KernelVersion: v4.7 -Contact: linux-nvdimm@lists.01.org +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. @@ -127,7 +127,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/subsystem_vendor Date: Apr, 2016 KernelVersion: v4.7 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) Sub-system vendor id of the NVDIMM non-volatile memory subsystem controller. @@ -136,7 +136,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/subsystem_rev_id Date: Apr, 2016 KernelVersion: v4.7 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) Sub-system revision id of the NVDIMM non-volatile memory subsystem controller, assigned by the non-volatile memory subsystem @@ -146,7 +146,7 @@ Description: What: /sys/bus/nd/devices/nmemX/nfit/subsystem_device Date: Apr, 2016 KernelVersion: v4.7 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) Sub-system device id for the NVDIMM non-volatile memory subsystem controller, assigned by the non-volatile memory @@ -156,7 +156,7 @@ Description: What: /sys/bus/nd/devices/ndbusX/nfit/revision Date: Jun, 2015 KernelVersion: v4.2 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) ACPI NFIT table revision number. @@ -164,7 +164,7 @@ Description: What: /sys/bus/nd/devices/ndbusX/nfit/scrub Date: Sep, 2016 KernelVersion: v4.9 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RW) This shows the number of full Address Range Scrubs (ARS) that have been completed since driver load time. Userspace can @@ -177,7 +177,7 @@ Description: What: /sys/bus/nd/devices/ndbusX/nfit/hw_error_scrub Date: Sep, 2016 KernelVersion: v4.9 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RW) Provides a way to toggle the behavior between just adding the address (cache line) where the MCE happened to the poison @@ -196,7 +196,7 @@ Description: What: /sys/bus/nd/devices/ndbusX/nfit/dsm_mask Date: Jun, 2017 KernelVersion: v4.13 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) The bitmask indicates the supported bus specific control functions. See the section named 'NVDIMM Root Device _DSMs' in @@ -205,7 +205,7 @@ Description: What: /sys/bus/nd/devices/ndbusX/nfit/firmware_activate_noidle Date: Apr, 2020 KernelVersion: v5.8 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RW) The Intel platform implementation of firmware activate support exposes an option let the platform force idle devices in @@ -225,7 +225,7 @@ Description: What: /sys/bus/nd/devices/regionX/nfit/range_index Date: Jun, 2015 KernelVersion: v4.2 -Contact: linux-nvdimm@lists.01.org +Contact: nvdimm@lists.linux.dev Description: (RO) A unique number provided by the BIOS to identify an address range. Used by NVDIMM Region Mapping Structure to uniquely refer diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem index 8316c33862a0..95254cec92bf 100644 --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem @@ -1,7 +1,7 @@ What: /sys/bus/nd/devices/nmemX/papr/flags Date: Apr, 2020 KernelVersion: v5.8 -Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org, +Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev, Description: (RO) Report flags indicating various states of a papr-pmem NVDIMM device. Each flag maps to a one or @@ -36,12 +36,14 @@ Description: What: /sys/bus/nd/devices/nmemX/papr/perf_stats Date: May, 2020 KernelVersion: v5.9 -Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org, +Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev, Description: (RO) Report various performance stats related to papr-scm NVDIMM - device. Each stat is reported on a new line with each line - composed of a stat-identifier followed by it value. Below are - currently known dimm performance stats which are reported: + device. This attribute is only available for NVDIMM devices + that support reporting NVDIMM performance stats. Each stat is + reported on a new line with each line composed of a + stat-identifier followed by it value. Below are currently known + dimm performance stats which are reported: * "CtlResCt" : Controller Reset Count * "CtlResTm" : Controller Reset Elapsed Time diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index ef00fada2efb..793cbb76cd25 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -139,8 +139,8 @@ Description: binary file containing the Vital Product Data for the device. It should follow the VPD format defined in PCI Specification 2.1 or 2.2, but users should consider - that some devices may have malformatted data. If the - underlying VPD has a writable section then the + that some devices may have incorrectly formatted data. + If the underlying VPD has a writable section then the corresponding section of this file will be writable. What: /sys/bus/pci/devices/.../virtfnN diff --git a/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor b/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor new file mode 100644 index 000000000000..d76cd3946434 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor @@ -0,0 +1,31 @@ +What: /sys/bus/spi/devices/.../spi-nor/jedec_id +Date: April 2021 +KernelVersion: 5.14 +Contact: linux-mtd@lists.infradead.org +Description: (RO) The JEDEC ID of the SPI NOR flash as reported by the + flash device. + + +What: /sys/bus/spi/devices/.../spi-nor/manufacturer +Date: April 2021 +KernelVersion: 5.14 +Contact: linux-mtd@lists.infradead.org +Description: (RO) Manufacturer of the SPI NOR flash. + + +What: /sys/bus/spi/devices/.../spi-nor/partname +Date: April 2021 +KernelVersion: 5.14 +Contact: linux-mtd@lists.infradead.org +Description: (RO) Part name of the SPI NOR flash. + + +What: /sys/bus/spi/devices/.../spi-nor/sfdp +Date: April 2021 +KernelVersion: 5.14 +Contact: linux-mtd@lists.infradead.org +Description: (RO) This attribute is only present if the SPI NOR flash + device supports the "Read SFDP" command (5Ah). + + If present, it contains the complete SFDP (serial flash + discoverable parameters) binary data of the flash. diff --git a/Documentation/ABI/testing/sysfs-class-backlight b/Documentation/ABI/testing/sysfs-class-backlight index 1fc86401bf95..c453646b06e2 100644 --- a/Documentation/ABI/testing/sysfs-class-backlight +++ b/Documentation/ABI/testing/sysfs-class-backlight @@ -84,3 +84,103 @@ Description: It can be enabled by writing the value stored in /sys/class/backlight/<backlight>/max_brightness to /sys/class/backlight/<backlight>/brightness. + +What: /sys/class/backlight/<backlight>/<ambient light zone>_max +Date: Sep, 2009 +KernelVersion: v2.6.32 +Contact: device-drivers-devel@blackfin.uclinux.org +Description: + Control the maximum brightness for <ambient light zone> + on this <backlight>. Values are between 0 and 127. This file + will also show the brightness level stored for this + <ambient light zone>. + + The <ambient light zone> is device-driver specific: + + For ADP5520 and ADP5501, <ambient light zone> can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + daylight /sys/class/backlight/<backlight>/daylight_max + office /sys/class/backlight/<backlight>/office_max + dark /sys/class/backlight/<backlight>/dark_max + =========== ================================================ + + For ADP8860, <ambient light zone> can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + l1_daylight /sys/class/backlight/<backlight>/l1_daylight_max + l2_office /sys/class/backlight/<backlight>/l2_office_max + l3_dark /sys/class/backlight/<backlight>/l3_dark_max + =========== ================================================ + + For ADP8870, <ambient light zone> can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + l1_daylight /sys/class/backlight/<backlight>/l1_daylight_max + l2_bright /sys/class/backlight/<backlight>/l2_bright_max + l3_office /sys/class/backlight/<backlight>/l3_office_max + l4_indoor /sys/class/backlight/<backlight>/l4_indoor_max + l5_dark /sys/class/backlight/<backlight>/l5_dark_max + =========== ================================================ + + See also: /sys/class/backlight/<backlight>/ambient_light_zone. + +What: /sys/class/backlight/<backlight>/<ambient light zone>_dim +Date: Sep, 2009 +KernelVersion: v2.6.32 +Contact: device-drivers-devel@blackfin.uclinux.org +Description: + Control the dim brightness for <ambient light zone> + on this <backlight>. Values are between 0 and 127, typically + set to 0. Full off when the backlight is disabled. + This file will also show the dim brightness level stored for + this <ambient light zone>. + + The <ambient light zone> is device-driver specific: + + For ADP5520 and ADP5501, <ambient light zone> can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + daylight /sys/class/backlight/<backlight>/daylight_dim + office /sys/class/backlight/<backlight>/office_dim + dark /sys/class/backlight/<backlight>/dark_dim + =========== ================================================ + + For ADP8860, <ambient light zone> can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + l1_daylight /sys/class/backlight/<backlight>/l1_daylight_dim + l2_office /sys/class/backlight/<backlight>/l2_office_dim + l3_dark /sys/class/backlight/<backlight>/l3_dark_dim + =========== ================================================ + + For ADP8870, <ambient light zone> can be: + + =========== ================================================ + Ambient sysfs entry + light zone + =========== ================================================ + l1_daylight /sys/class/backlight/<backlight>/l1_daylight_dim + l2_bright /sys/class/backlight/<backlight>/l2_bright_dim + l3_office /sys/class/backlight/<backlight>/l3_office_dim + l4_indoor /sys/class/backlight/<backlight>/l4_indoor_dim + l5_dark /sys/class/backlight/<backlight>/l5_dark_dim + =========== ================================================ + + See also: /sys/class/backlight/<backlight>/ambient_light_zone. + diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp5520 b/Documentation/ABI/testing/sysfs-class-backlight-adp5520 deleted file mode 100644 index 34b6ebafa210..000000000000 --- a/Documentation/ABI/testing/sysfs-class-backlight-adp5520 +++ /dev/null @@ -1,31 +0,0 @@ -sysfs interface for analog devices adp5520(01) backlight driver ---------------------------------------------------------------- - -The backlight brightness control operates at three different levels for the -adp5520 and adp5501 devices: daylight (level 1), office (level 2) and dark -(level 3). By default the brightness operates at the daylight brightness level. - -What: /sys/class/backlight/<backlight>/daylight_max -What: /sys/class/backlight/<backlight>/office_max -What: /sys/class/backlight/<backlight>/dark_max -Date: Sep, 2009 -KernelVersion: v2.6.32 -Contact: Michael Hennerich <michael.hennerich@analog.com> -Description: - (RW) Maximum current setting for the backlight when brightness - is at one of the three levels (daylight, office or dark). This - is an input code between 0 and 127, which is transformed to a - value between 0 mA and 30 mA using linear or non-linear - algorithms. - -What: /sys/class/backlight/<backlight>/daylight_dim -What: /sys/class/backlight/<backlight>/office_dim -What: /sys/class/backlight/<backlight>/dark_dim -Date: Sep, 2009 -KernelVersion: v2.6.32 -Contact: Michael Hennerich <michael.hennerich@analog.com> -Description: - (RW) Dim current setting for the backlight when brightness is at - one of the three levels (daylight, office or dark). This is an - input code between 0 and 127, which is transformed to a value - between 0 mA and 30 mA using linear or non-linear algorithms. diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp8860 b/Documentation/ABI/testing/sysfs-class-backlight-adp8860 deleted file mode 100644 index 6610ac73f9ba..000000000000 --- a/Documentation/ABI/testing/sysfs-class-backlight-adp8860 +++ /dev/null @@ -1,37 +0,0 @@ -sysfs interface for analog devices adp8860 backlight driver ------------------------------------------------------------ - -The backlight brightness control operates at three different levels for the -adp8860, adp8861 and adp8863 devices: daylight (level 1), office (level 2) and -dark (level 3). By default the brightness operates at the daylight brightness -level. - -See also /sys/class/backlight/<backlight>/ambient_light_level and -/sys/class/backlight/<backlight>/ambient_light_zone. - - -What: /sys/class/backlight/<backlight>/l1_daylight_max -What: /sys/class/backlight/<backlight>/l2_office_max -What: /sys/class/backlight/<backlight>/l3_dark_max -Date: Apr, 2010 -KernelVersion: v2.6.35 -Contact: Michael Hennerich <michael.hennerich@analog.com> -Description: - (RW) Maximum current setting for the backlight when brightness - is at one of the three levels (daylight, office or dark). This - is an input code between 0 and 127, which is transformed to a - value between 0 mA and 30 mA using linear or non-linear - algorithms. - - -What: /sys/class/backlight/<backlight>/l1_daylight_dim -What: /sys/class/backlight/<backlight>/l2_office_dim -What: /sys/class/backlight/<backlight>/l3_dark_dim -Date: Apr, 2010 -KernelVersion: v2.6.35 -Contact: Michael Hennerich <michael.hennerich@analog.com> -Description: - (RW) Dim current setting for the backlight when brightness is at - one of the three levels (daylight, office or dark). This is an - input code between 0 and 127, which is transformed to a value - between 0 mA and 30 mA using linear or non-linear algorithms. diff --git a/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 b/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 deleted file mode 100644 index b08ca912cad4..000000000000 --- a/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 +++ /dev/null @@ -1,32 +0,0 @@ -See also /sys/class/backlight/<backlight>/ambient_light_level and -/sys/class/backlight/<backlight>/ambient_light_zone. - -What: /sys/class/backlight/<backlight>/<ambient light zone>_max -What: /sys/class/backlight/<backlight>/l1_daylight_max -What: /sys/class/backlight/<backlight>/l2_bright_max -What: /sys/class/backlight/<backlight>/l3_office_max -What: /sys/class/backlight/<backlight>/l4_indoor_max -What: /sys/class/backlight/<backlight>/l5_dark_max -Date: May 2011 -KernelVersion: 3.0 -Contact: device-drivers-devel@blackfin.uclinux.org -Description: - Control the maximum brightness for <ambient light zone> - on this <backlight>. Values are between 0 and 127. This file - will also show the brightness level stored for this - <ambient light zone>. - -What: /sys/class/backlight/<backlight>/<ambient light zone>_dim -What: /sys/class/backlight/<backlight>/l2_bright_dim -What: /sys/class/backlight/<backlight>/l3_office_dim -What: /sys/class/backlight/<backlight>/l4_indoor_dim -What: /sys/class/backlight/<backlight>/l5_dark_dim -Date: May 2011 -KernelVersion: 3.0 -Contact: device-drivers-devel@blackfin.uclinux.org -Description: - Control the dim brightness for <ambient light zone> - on this <backlight>. Values are between 0 and 127, typically - set to 0. Full off when the backlight is disabled. - This file will also show the dim brightness level stored for - this <ambient light zone>. diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes index 8ea59fea4709..3348bf80a37c 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -197,8 +197,24 @@ Description: Drivers may emit a CHANGE uevent when a password is set or unset userspace may check it again. - On Dell systems, if Admin password is set, then all BIOS attributes + On Dell and Lenovo 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. + + Lenovo specific class extensions + ------------------------------ + + On Lenovo systems the following additional settings are available: + + lenovo_encoding: + The encoding method that is used. This can be either "ascii" + or "scancode". Default is set to "ascii" + + lenovo_kbdlang: + The keyboard language method that is used. This is generally a + two char code (e.g. "us", "fr", "gr") and may vary per platform. + Default is set to "us" What: /sys/class/firmware-attributes/*/attributes/pending_reboot Date: February 2021 diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 b/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 deleted file mode 100644 index 04f3ffdc5936..000000000000 --- a/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 +++ /dev/null @@ -1,9 +0,0 @@ -What: /sys/class/leds/<led>/repeat -Date: September 2019 -KernelVersion: 5.5 -Description: - EL15203000 supports only indefinitely patterns, - so this file should always store -1. - - For more info, please see: - Documentation/ABI/testing/sysfs-class-led-trigger-pattern diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern index d91a07767adf..8c57d2780554 100644 --- a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern @@ -35,3 +35,6 @@ Description: This file will always return the originally written repeat number. + + It should be noticed that some leds, like EL15203000 may + only support indefinitely patterns, so they always store -1. diff --git a/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa b/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa new file mode 100644 index 000000000000..c56dcf15bf29 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa @@ -0,0 +1,78 @@ +What: /sys/devices/platform/soc@X/XXXXXXX.ipa/ +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The /sys/devices/platform/soc@X/XXXXXXX.ipa/ directory + contains read-only attributes exposing information about + an IPA device. The X values could vary, but are typically + "soc@0/1e40000.ipa". + +What: .../XXXXXXX.ipa/version +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/version file contains the IPA hardware + version, as a period-separated set of two or three integers + (e.g., "3.5.1" or "4.2"). + +What: .../XXXXXXX.ipa/feature/ +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/feature/ directory contains a set of + attributes describing features implemented by the IPA + hardware. + +What: .../XXXXXXX.ipa/feature/rx_offload +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/feature/rx_offload file contains a + string indicating the type of receive checksum offload + that is supported by the hardware. The possible values + are "MAPv4" or "MAPv5". + +What: .../XXXXXXX.ipa/feature/tx_offload +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/feature/tx_offload file contains a + string indicating the type of transmit checksum offload + that is supported by the hardware. The possible values + are "MAPv4" or "MAPv5". + +What: .../XXXXXXX.ipa/modem/ +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/modem/ directory contains a set of + attributes describing properties of the modem execution + environment reachable by the IPA hardware. + +What: .../XXXXXXX.ipa/modem/rx_endpoint_id +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/feature/rx_endpoint_id file contains + the AP endpoint ID that receives packets originating from + the modem execution environment. The "rx" is from the + perspective of the AP; this endpoint is considered an "IPA + producer". An endpoint ID is a small unsigned integer. + +What: .../XXXXXXX.ipa/modem/tx_endpoint_id +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/feature/tx_endpoint_id file contains + the AP endpoint ID used to transmit packets destined for + the modem execution environment. The "tx" is from the + perspective of the AP; this endpoint is considered an "IPA + consumer". An endpoint ID is a small unsigned integer. diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index fe13baa53c59..160b10c029c0 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -50,7 +50,7 @@ Description: Dynamic addition and removal of CPU's. This is not hotplug architecture specific. release: writes to this file dynamically remove a CPU from - the system. Information writtento the file to remove CPU's + the system. Information written to the file to remove CPU's is architecture specific. What: /sys/devices/system/cpu/cpu#/node @@ -97,7 +97,7 @@ Description: CPU topology files that describe a logical CPU's relationship corresponds to a physical socket number, but the actual value is architecture and platform dependent. - thread_siblings: internel kernel map of cpu#'s hardware + thread_siblings: internal kernel map of cpu#'s hardware threads within the same core as cpu# thread_siblings_list: human-readable list of cpu#'s hardware @@ -280,7 +280,7 @@ Description: Disable L3 cache indices on a processor with this functionality will return the currently disabled index for that node. There is one L3 structure per node, or per internal node on MCM machines. Writing a valid - index to one of these files will cause the specificed cache + index to one of these files will cause the specified cache index to be disabled. All AMD processors with L3 caches provide this functionality. @@ -295,7 +295,7 @@ Description: Processor frequency boosting control This switch controls the boost setting for the whole system. Boosting allows the CPU and the firmware to run at a frequency - beyound it's nominal limit. + beyond it's nominal limit. More details can be found in Documentation/admin-guide/pm/cpufreq.rst @@ -532,7 +532,7 @@ What: /sys/devices/system/cpu/smt /sys/devices/system/cpu/smt/control Date: June 2018 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> -Description: Control Symetric Multi Threading (SMT) +Description: Control Symmetric Multi Threading (SMT) active: Tells whether SMT is active (enabled and siblings online) diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index d1bc23cb6a9d..b4a5d55fa19f 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -168,7 +168,7 @@ Description: This file shows the manufacturing date in BCD format. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/manufacturer_id Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> -Description: This file shows the manufacturee ID. This is one of the +Description: This file shows the manufacturer ID. This is one of the UFS device descriptor parameters. The full information about the descriptor could be found at UFS specifications 2.1. @@ -521,7 +521,7 @@ Description: This file shows maximum VCC, VCCQ and VCCQ2 value for What: /sys/bus/platform/drivers/ufshcd/*/string_descriptors/manufacturer_name Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> -Description: This file contains a device manufactureer name string. +Description: This file contains a device manufacturer name string. The full information about the descriptor could be found at UFS specifications 2.1. @@ -995,6 +995,132 @@ Description: This entry shows the target state of an UFS UIC link The file is read only. +What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_enable +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows the status of performance monitor enablement + and it can be used to start/stop the monitor. When the monitor + is stopped, the performance data collected is also cleared. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_chunk_size +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file tells the monitor to focus on requests transferring + data of specific chunk size (in Bytes). 0 means any chunk size. + It can only be changed when monitor is disabled. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_sectors +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows how many sectors (in 512 Bytes) have been + sent from device to host after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_busy +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows how long (in micro seconds) has been spent + sending data from device to host after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_nr_requests +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows how many read requests have been sent after + monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_max +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows the maximum latency (in micro seconds) of + read requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_min +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows the minimum latency (in micro seconds) of + read requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_avg +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows the average latency (in micro seconds) of + read requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_sum +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows the total latency (in micro seconds) of + read requests sent after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_sectors +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows how many sectors (in 512 Bytes) have been sent + from host to device after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_busy +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows how long (in micro seconds) has been spent + sending data from host to device after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_nr_requests +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows how many write requests have been sent after + monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_max +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows the maximum latency (in micro seconds) of write + requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_min +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows the minimum latency (in micro seconds) of write + requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_avg +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows the average latency (in micro seconds) of write + requests after monitor gets started. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_sum +Date: January 2021 +Contact: Can Guo <cang@codeaurora.org> +Description: This file shows the total latency (in micro seconds) of write + requests after monitor gets started. + + The file is read only. + What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_presv_us_en Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 4849b8e84e42..5d9ae27bd462 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -238,7 +238,7 @@ Description: Shows current reserved blocks in system, it may be temporarily What: /sys/fs/f2fs/<disk>/gc_urgent Date: August 2017 Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> -Description: Do background GC agressively when set. When gc_urgent = 1, +Description: Do background GC aggressively when set. When gc_urgent = 1, background thread starts to do GC by given gc_urgent_sleep_time interval. When gc_urgent = 2, F2FS will lower the bar of checking idle in order to process outstanding discard commands diff --git a/Documentation/ABI/testing/sysfs-kernel-iommu_groups b/Documentation/ABI/testing/sysfs-kernel-iommu_groups index 0fedbb0f94e4..eae2f1c1e11e 100644 --- a/Documentation/ABI/testing/sysfs-kernel-iommu_groups +++ b/Documentation/ABI/testing/sysfs-kernel-iommu_groups @@ -25,14 +25,10 @@ Description: /sys/kernel/iommu_groups/reserved_regions list IOVA the base IOVA, the second is the end IOVA and the third field describes the type of the region. -What: /sys/kernel/iommu_groups/reserved_regions -Date: June 2019 -KernelVersion: v5.3 -Contact: Eric Auger <eric.auger@redhat.com> -Description: In case an RMRR is used only by graphics or USB devices - it is now exposed as "direct-relaxable" instead of "direct". - In device assignment use case, for instance, those RMRR - are considered to be relaxable and safe. + Since kernel 5.3, in case an RMRR is used only by graphics or + USB devices it is now exposed as "direct-relaxable" instead + of "direct". In device assignment use case, for instance, + those RMRR are considered to be relaxable and safe. What: /sys/kernel/iommu_groups/<grp_id>/type Date: November 2020 diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module index a485434d2a0f..88bddf192ceb 100644 --- a/Documentation/ABI/testing/sysfs-module +++ b/Documentation/ABI/testing/sysfs-module @@ -37,13 +37,13 @@ Description: Maximum time allowed for periodic transfers per microframe (μs) What: /sys/module/*/{coresize,initsize} Date: Jan 2012 -KernelVersion:»·3.3 +KernelVersion: 3.3 Contact: Kay Sievers <kay.sievers@vrfy.org> Description: Module size in bytes. What: /sys/module/*/taint Date: Jan 2012 -KernelVersion:»·3.3 +KernelVersion: 3.3 Contact: Kay Sievers <kay.sievers@vrfy.org> Description: Module taint flags: == ===================== diff --git a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi new file mode 100644 index 000000000000..7f9e18705861 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi @@ -0,0 +1,55 @@ +What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type +Date: Apr 2021 +KernelVersion: 5.13 +Contact: "perry.yuan@dell.com>" +Description: + Display which dell hardware level privacy devices are supported + “Dell Privacy” is a set of HW, FW, and SW features to enhance + Dell’s commitment to platform privacy for MIC, Camera, and + ePrivacy screens. + The supported hardware privacy devices are: +Attributes: + Microphone Mute: + Identifies the local microphone can be muted by hardware, no applications + is available to capture system mic sound + + Camera Shutter: + Identifies camera shutter controlled by hardware, which is a micromechanical + shutter assembly that is built onto the camera module to block capturing images + from outside the laptop + + supported: + The privacy device is supported by this system + + unsupported: + The privacy device is not supported on this system + + For example to check which privacy devices are supported: + + # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type + [Microphone Mute] [supported] + [Camera Shutter] [supported] + [ePrivacy Screen] [unsupported] + +What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state +Date: Apr 2021 +KernelVersion: 5.13 +Contact: "perry.yuan@dell.com>" +Description: + Allow user space to check current dell privacy device state. + Describes the Device State class exposed by BIOS which can be + consumed by various applications interested in knowing the Privacy + feature capabilities +Attributes: + muted: + Identifies the privacy device is turned off and cannot send stream to OS applications + + unmuted: + Identifies the privacy device is turned on ,audio or camera driver can get + stream from mic and camera module to OS applications + + For example to check all supported current privacy device states: + + # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state + [Microphone] [unmuted] + [Camera Shutter] [unmuted] diff --git a/Documentation/Makefile b/Documentation/Makefile index 9c42dde97671..c3feb657b654 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -76,7 +76,7 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4) PYTHONDONTWRITEBYTECODE=1 \ BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \ $(PYTHON3) $(srctree)/scripts/jobserver-exec \ - $(SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \ + $(CONFIG_SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \ $(SPHINXBUILD) \ -b $2 \ -c $(abspath $(srctree)/$(src)) \ diff --git a/Documentation/PCI/acpi-info.rst b/Documentation/PCI/acpi-info.rst index 060217081c79..34c64a5a66ec 100644 --- a/Documentation/PCI/acpi-info.rst +++ b/Documentation/PCI/acpi-info.rst @@ -22,9 +22,9 @@ or if the device has INTx interrupts connected by platform interrupt controllers and a _PRT is needed to describe those connections. ACPI resource description is done via _CRS objects of devices in the ACPI -namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read +namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read _CRS and figure out what resource is being consumed even if it doesn't have -a driver for the device [3]. That's important because it means an old OS +a driver for the device [3]. That's important because it means an old OS can work correctly even on a system with new devices unknown to the OS. The new devices might not do anything, but the OS can at least make sure no resources conflict with them. @@ -41,15 +41,15 @@ ACPI, that device will have a specific _HID/_CID that tells the OS what driver to bind to it, and the _CRS tells the OS and the driver where the device's registers are. -PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should -describe all the address space they consume. This includes all the windows +PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should +describe all the address space they consume. This includes all the windows they forward down to the PCI bus, as well as registers of the host bridge -itself that are not forwarded to PCI. The host bridge registers include +itself that are not forwarded to PCI. The host bridge registers include things like secondary/subordinate bus registers that determine the bus range below the bridge, window registers that describe the apertures, etc. These are all device-specific, non-architected things, so the only way a PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain -the device-specific details. The host bridge registers also include ECAM +the device-specific details. The host bridge registers also include ECAM space, since it is consumed by the host bridge. ACPI defines a Consumer/Producer bit to distinguish the bridge registers @@ -66,7 +66,7 @@ the PNP0A03/PNP0A08 device itself. The workaround was to describe the bridge registers (including ECAM space) in PNP0C02 catch-all devices [6]. With the exception of ECAM, the bridge register space is device-specific anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to -know about it. +know about it. New architectures should be able to use "Consumer" Extended Address Space descriptors in the PNP0A03 device for bridge registers, including ECAM, @@ -75,9 +75,9 @@ ia64 kernels assume all address space descriptors, including "Consumer" Extended Address Space ones, are windows, so it would not be safe to describe bridge registers this way on those architectures. -PNP0C02 "motherboard" devices are basically a catch-all. There's no +PNP0C02 "motherboard" devices are basically a catch-all. There's no programming model for them other than "don't use these resources for -anything else." So a PNP0C02 _CRS should claim any address space that is +anything else." So a PNP0C02 _CRS should claim any address space that is (1) not claimed by _CRS under any other device object in the ACPI namespace and (2) should not be assigned by the OS to something else. diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst index 696f8eeb4738..db609b97ad58 100644 --- a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst +++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst @@ -125,4 +125,4 @@ all the EPF devices are created and linked with the EPC device. | interrupt_pin | function -[1] :doc:`pci-endpoint` +[1] Documentation/PCI/endpoint/pci-endpoint.rst diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index 814b40f8360b..fa651e25d98c 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -265,7 +265,7 @@ Set the DMA mask size --------------------- .. note:: If anything below doesn't make sense, please refer to - :doc:`/core-api/dma-api`. This section is just a reminder that + Documentation/core-api/dma-api.rst. This section is just a reminder that drivers need to indicate DMA capabilities of the device and is not an authoritative source for DMA interfaces. @@ -291,7 +291,7 @@ Many 64-bit "PCI" devices (before PCI-X) and some PCI-X devices are Setup shared control data ------------------------- Once the DMA masks are set, the driver can allocate "consistent" (a.k.a. shared) -memory. See :doc:`/core-api/dma-api` for a full description of +memory. See Documentation/core-api/dma-api.rst for a full description of the DMA APIs. This section is just a reminder that it needs to be done before enabling DMA on the device. @@ -421,7 +421,7 @@ owners if there is one. Then clean up "consistent" buffers which contain the control data. -See :doc:`/core-api/dma-api` for details on unmapping interfaces. +See Documentation/core-api/dma-api.rst for details on unmapping interfaces. Unregister from other subsystems diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index a648b423ba0e..11cdab037bff 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -21,7 +21,7 @@ Any code that happens after the end of a given RCU grace period is guaranteed to see the effects of all accesses prior to the beginning of that grace period that are within RCU read-side critical sections. Similarly, any code that happens before the beginning of a given RCU grace -period is guaranteed to see the effects of all accesses following the end +period is guaranteed to not see the effects of all accesses following the end of that grace period that are within RCU read-side critical sections. Note well that RCU-sched read-side critical sections include any region @@ -339,14 +339,14 @@ The diagram below shows the path of ordering if the leftmost leftmost ``rcu_node`` structure offlines its last CPU and if the next ``rcu_node`` structure has no online CPUs). -.. kernel-figure:: TreeRCU-gp-init-1.svg +.. kernel-figure:: TreeRCU-gp-init-2.svg The final ``rcu_gp_init()`` pass through the ``rcu_node`` tree traverses breadth-first, setting each ``rcu_node`` structure's ``->gp_seq`` field to the newly advanced value from the ``rcu_state`` structure, as shown in the following diagram. -.. kernel-figure:: TreeRCU-gp-init-1.svg +.. kernel-figure:: TreeRCU-gp-init-3.svg This change will also cause each CPU's next call to ``__note_gp_changes()`` to notice that a new grace period has started, diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 1030119294d0..01cc21f17f7b 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -211,27 +211,40 @@ over a rather long period of time, but improvements are always welcome! of the system, especially to real-time workloads running on the rest of the system. -7. As of v4.20, a given kernel implements only one RCU flavor, - which is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y. - If the updater uses call_rcu() or synchronize_rcu(), - then the corresponding readers may use rcu_read_lock() and - rcu_read_unlock(), rcu_read_lock_bh() and rcu_read_unlock_bh(), - or any pair of primitives that disables and re-enables preemption, - for example, rcu_read_lock_sched() and rcu_read_unlock_sched(). - If the updater uses synchronize_srcu() or call_srcu(), - then the corresponding readers must use srcu_read_lock() and - srcu_read_unlock(), and with the same srcu_struct. The rules for - the expedited primitives are the same as for their non-expedited - counterparts. Mixing things up will result in confusion and - broken kernels, and has even resulted in an exploitable security - issue. - - One exception to this rule: rcu_read_lock() and rcu_read_unlock() - may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh() - in cases where local bottom halves are already known to be - disabled, for example, in irq or softirq context. Commenting - such cases is a must, of course! And the jury is still out on - whether the increased speed is worth it. +7. As of v4.20, a given kernel implements only one RCU flavor, which + is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y. + If the updater uses call_rcu() or synchronize_rcu(), then + the corresponding readers may use: (1) rcu_read_lock() and + rcu_read_unlock(), (2) any pair of primitives that disables + and re-enables softirq, for example, rcu_read_lock_bh() and + rcu_read_unlock_bh(), or (3) any pair of primitives that disables + and re-enables preemption, for example, rcu_read_lock_sched() and + rcu_read_unlock_sched(). If the updater uses synchronize_srcu() + or call_srcu(), then the corresponding readers must use + srcu_read_lock() and srcu_read_unlock(), and with the same + srcu_struct. The rules for the expedited RCU grace-period-wait + primitives are the same as for their non-expedited counterparts. + + If the updater uses call_rcu_tasks() or synchronize_rcu_tasks(), + then the readers must refrain from executing voluntary + context switches, that is, from blocking. If the updater uses + call_rcu_tasks_trace() or synchronize_rcu_tasks_trace(), then + the corresponding readers must use rcu_read_lock_trace() and + rcu_read_unlock_trace(). If an updater uses call_rcu_tasks_rude() + or synchronize_rcu_tasks_rude(), then the corresponding readers + must use anything that disables interrupts. + + Mixing things up will result in confusion and broken kernels, and + has even resulted in an exploitable security issue. Therefore, + when using non-obvious pairs of primitives, commenting is + of course a must. One example of non-obvious pairing is + the XDP feature in networking, which calls BPF programs from + network-driver NAPI (softirq) context. BPF relies heavily on RCU + protection for its data structures, but because the BPF program + invocation happens entirely within a single local_bh_disable() + section in a NAPI poll cycle, this usage is safe. The reason + that this usage is safe is that readers can use anything that + disables BH when updaters use call_rcu() or synchronize_rcu(). 8. Although synchronize_rcu() is slower than is call_rcu(), it usually results in simpler code. So, unless update performance is diff --git a/Documentation/accounting/delay-accounting.rst b/Documentation/accounting/delay-accounting.rst index 7cc7f5852da0..1b8b46deeb29 100644 --- a/Documentation/accounting/delay-accounting.rst +++ b/Documentation/accounting/delay-accounting.rst @@ -69,13 +69,15 @@ Compile the kernel with:: CONFIG_TASK_DELAY_ACCT=y CONFIG_TASKSTATS=y -Delay accounting is enabled by default at boot up. -To disable, add:: +Delay accounting is disabled by default at boot up. +To enable, add:: - nodelayacct + delayacct -to the kernel boot options. The rest of the instructions -below assume this has not been done. +to the kernel boot options. The rest of the instructions below assume this has +been done. Alternatively, use sysctl kernel.task_delayacct to switch the state +at runtime. Note however that only tasks started after enabling it will have +delayacct information. After the system has booted up, use a utility similar to getdelays.c to access the delays diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst index 452b7dcd7f6b..6a79f2e59396 100644 --- a/Documentation/admin-guide/bootconfig.rst +++ b/Documentation/admin-guide/bootconfig.rst @@ -89,13 +89,35 @@ you can use ``+=`` operator. For example:: In this case, the key ``foo`` has ``bar``, ``baz`` and ``qux``. -However, a sub-key and a value can not co-exist under a parent key. -For example, following config is NOT allowed.:: +Moreover, sub-keys and a value can coexist under a parent key. +For example, following config is allowed.:: foo = value1 - foo.bar = value2 # !ERROR! subkey "bar" and value "value1" can NOT co-exist - foo.bar := value2 # !ERROR! even with the override operator, this is NOT allowed. + foo.bar = value2 + foo := value3 # This will update foo's value. + +Note, since there is no syntax to put a raw value directly under a +structured key, you have to define it outside of the brace. For example:: + + foo { + bar = value1 + bar { + baz = value2 + qux = value3 + } + } + +Also, the order of the value node under a key is fixed. If there +are a value and subkeys, the value is always the first child node +of the key. Thus if user specifies subkeys first, e.g.:: + + foo.bar = value1 + foo = value2 + +In the program (and /proc/bootconfig), it will be shown as below:: + foo = value2 + foo.bar = value1 Comments -------- diff --git a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst index 36d43ae7dc13..16253eda192e 100644 --- a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst +++ b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst @@ -17,36 +17,37 @@ level logical devices like device mapper. HOWTO ===== + Throttling/Upper Limit policy ----------------------------- -- Enable Block IO controller:: +Enable Block IO controller:: CONFIG_BLK_CGROUP=y -- Enable throttling in block layer:: +Enable throttling in block layer:: CONFIG_BLK_DEV_THROTTLING=y -- Mount blkio controller (see cgroups.txt, Why are cgroups needed?):: +Mount blkio controller (see cgroups.txt, Why are cgroups needed?):: mount -t cgroup -o blkio none /sys/fs/cgroup/blkio -- Specify a bandwidth rate on particular device for root group. The format - for policy is "<major>:<minor> <bytes_per_second>":: +Specify a bandwidth rate on particular device for root group. The format +for policy is "<major>:<minor> <bytes_per_second>":: echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device - Above will put a limit of 1MB/second on reads happening for root group - on device having major/minor number 8:16. +This will put a limit of 1MB/second on reads happening for root group +on device having major/minor number 8:16. -- Run dd to read a file and see if rate is throttled to 1MB/s or not:: +Run dd to read a file and see if rate is throttled to 1MB/s or not:: # dd iflag=direct if=/mnt/common/zerofile of=/dev/null bs=4K count=1024 1024+0 records in 1024+0 records out 4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s - Limits for writes can be put using blkio.throttle.write_bps_device file. +Limits for writes can be put using blkio.throttle.write_bps_device file. Hierarchical Cgroups ==================== @@ -79,85 +80,89 @@ following:: Various user visible config options =================================== -CONFIG_BLK_CGROUP - - Block IO controller. -CONFIG_BFQ_CGROUP_DEBUG - - Debug help. Right now some additional stats file show up in cgroup + CONFIG_BLK_CGROUP + Block IO controller. + + CONFIG_BFQ_CGROUP_DEBUG + Debug help. Right now some additional stats file show up in cgroup if this option is enabled. -CONFIG_BLK_DEV_THROTTLING - - Enable block device throttling support in block layer. + CONFIG_BLK_DEV_THROTTLING + Enable block device throttling support in block layer. Details of cgroup files ======================= + Proportional weight policy files -------------------------------- -- blkio.weight - - Specifies per cgroup weight. This is default weight of the group - on all the devices until and unless overridden by per device rule. - (See blkio.weight_device). - Currently allowed range of weights is from 10 to 1000. -- blkio.weight_device - - One can specify per cgroup per device rules using this interface. - These rules override the default value of group weight as specified - by blkio.weight. + blkio.bfq.weight + Specifies per cgroup weight. This is default weight of the group + on all the devices until and unless overridden by per device rule + (see `blkio.bfq.weight_device` below). + + Currently allowed range of weights is from 1 to 1000. For more details, + see Documentation/block/bfq-iosched.rst. + + blkio.bfq.weight_device + Specifes per cgroup per device weights, overriding the default group + weight. For more details, see Documentation/block/bfq-iosched.rst. Following is the format:: - # echo dev_maj:dev_minor weight > blkio.weight_device + # echo dev_maj:dev_minor weight > blkio.bfq.weight_device Configure weight=300 on /dev/sdb (8:16) in this cgroup:: - # echo 8:16 300 > blkio.weight_device - # cat blkio.weight_device + # echo 8:16 300 > blkio.bfq.weight_device + # cat blkio.bfq.weight_device dev weight 8:16 300 Configure weight=500 on /dev/sda (8:0) in this cgroup:: - # echo 8:0 500 > blkio.weight_device - # cat blkio.weight_device + # echo 8:0 500 > blkio.bfq.weight_device + # cat blkio.bfq.weight_device dev weight 8:0 500 8:16 300 Remove specific weight for /dev/sda in this cgroup:: - # echo 8:0 0 > blkio.weight_device - # cat blkio.weight_device + # echo 8:0 0 > blkio.bfq.weight_device + # cat blkio.bfq.weight_device dev weight 8:16 300 -- blkio.time - - disk time allocated to cgroup per device in milliseconds. First + blkio.time + Disk time allocated to cgroup per device in milliseconds. First two fields specify the major and minor number of the device and third field specifies the disk time allocated to group in milliseconds. -- blkio.sectors - - number of sectors transferred to/from disk by the group. First + blkio.sectors + Number of sectors transferred to/from disk by the group. First two fields specify the major and minor number of the device and third field specifies the number of sectors transferred by the group to/from the device. -- blkio.io_service_bytes - - Number of bytes transferred to/from the disk by the group. These + blkio.io_service_bytes + Number of bytes transferred to/from the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field specifies the number of bytes. -- blkio.io_serviced - - Number of IOs (bio) issued to the disk by the group. These + blkio.io_serviced + Number of IOs (bio) issued to the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field specifies the number of IOs. -- blkio.io_service_time - - Total amount of time between request dispatch and request completion + blkio.io_service_time + Total amount of time between request dispatch and request completion for the IOs done by this cgroup. This is in nanoseconds to make it meaningful for flash devices too. For devices with queue depth of 1, this time represents the actual service time. When queue_depth > 1, @@ -170,8 +175,8 @@ Proportional weight policy files specifies the operation type and the fourth field specifies the io_service_time in ns. -- blkio.io_wait_time - - Total amount of time the IOs for this cgroup spent waiting in the + blkio.io_wait_time + Total amount of time the IOs for this cgroup spent waiting in the scheduler queues for service. This can be greater than the total time elapsed since it is cumulative io_wait_time for all IOs. It is not a measure of total time the cgroup spent waiting but rather a measure of @@ -185,24 +190,24 @@ Proportional weight policy files minor number of the device, third field specifies the operation type and the fourth field specifies the io_wait_time in ns. -- blkio.io_merged - - Total number of bios/requests merged into requests belonging to this + blkio.io_merged + Total number of bios/requests merged into requests belonging to this cgroup. This is further divided by the type of operation - read or write, sync or async. -- blkio.io_queued - - Total number of requests queued up at any given instant for this + blkio.io_queued + Total number of requests queued up at any given instant for this cgroup. This is further divided by the type of operation - read or write, sync or async. -- blkio.avg_queue_size - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.avg_queue_size + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. The average queue size for this cgroup over the entire time of this cgroup's existence. Queue size samples are taken each time one of the queues of this cgroup gets a timeslice. -- blkio.group_wait_time - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.group_wait_time + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This is the amount of time the cgroup had to wait since it became busy (i.e., went from 0 to 1 request queued) to get a timeslice for one of its queues. This is different from the io_wait_time which is the @@ -212,8 +217,8 @@ Proportional weight policy files will only report the group_wait_time accumulated till the last time it got a timeslice and will not include the current delta. -- blkio.empty_time - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.empty_time + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This is the amount of time a cgroup spends without any pending requests when not being served, i.e., it does not include any time spent idling for one of the queues of the cgroup. This is in @@ -221,8 +226,8 @@ Proportional weight policy files the stat will only report the empty_time accumulated till the last time it had a pending request and will not include the current delta. -- blkio.idle_time - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.idle_time + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This is the amount of time spent by the IO scheduler idling for a given cgroup in anticipation of a better request than the existing ones from other queues/cgroups. This is in nanoseconds. If this is read @@ -230,60 +235,60 @@ Proportional weight policy files idle_time accumulated till the last idle period and will not include the current delta. -- blkio.dequeue - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This + blkio.dequeue + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This gives the statistics about how many a times a group was dequeued from service tree of the device. First two fields specify the major and minor number of the device and third field specifies the number of times a group was dequeued from a particular device. -- blkio.*_recursive - - Recursive version of various stats. These files show the + blkio.*_recursive + Recursive version of various stats. These files show the same information as their non-recursive counterparts but include stats from all the descendant cgroups. Throttling/Upper limit policy files ----------------------------------- -- blkio.throttle.read_bps_device - - Specifies upper limit on READ rate from the device. IO rate is + blkio.throttle.read_bps_device + Specifies upper limit on READ rate from the device. IO rate is specified in bytes per second. Rules are per device. Following is the format:: echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.read_bps_device -- blkio.throttle.write_bps_device - - Specifies upper limit on WRITE rate to the device. IO rate is + blkio.throttle.write_bps_device + Specifies upper limit on WRITE rate to the device. IO rate is specified in bytes per second. Rules are per device. Following is the format:: echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.write_bps_device -- blkio.throttle.read_iops_device - - Specifies upper limit on READ rate from the device. IO rate is + blkio.throttle.read_iops_device + Specifies upper limit on READ rate from the device. IO rate is specified in IO per second. Rules are per device. Following is the format:: echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.read_iops_device -- blkio.throttle.write_iops_device - - Specifies upper limit on WRITE rate to the device. IO rate is + blkio.throttle.write_iops_device + Specifies upper limit on WRITE rate to the device. IO rate is specified in io per second. Rules are per device. Following is the format:: echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.write_iops_device -Note: If both BW and IOPS rules are specified for a device, then IO is - subjected to both the constraints. + Note: If both BW and IOPS rules are specified for a device, then IO is + subjected to both the constraints. -- blkio.throttle.io_serviced - - Number of IOs (bio) issued to the disk by the group. These + blkio.throttle.io_serviced + Number of IOs (bio) issued to the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field specifies the number of IOs. -- blkio.throttle.io_service_bytes - - Number of bytes transferred to/from the disk by the group. These + blkio.throttle.io_service_bytes + Number of bytes transferred to/from the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field @@ -291,6 +296,6 @@ Note: If both BW and IOPS rules are specified for a device, then IO is Common files among various policies ----------------------------------- -- blkio.reset_stats - - Writing an int to this file will result in resetting all the stats + blkio.reset_stats + Writing an int to this file will result in resetting all the stats for that cgroup. diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index b1e81aa8598a..5c7377b5bd3e 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -56,6 +56,7 @@ v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgrou 5-3-3. IO Latency 5-3-3-1. How IO Latency Throttling Works 5-3-3-2. IO Latency Interface Files + 5-3-4. IO Priority 5-4. PID 5-4-1. PID Interface Files 5-5. Cpuset @@ -952,6 +953,21 @@ All cgroup core files are prefixed with "cgroup." it's possible to delete a frozen (and empty) cgroup, as well as create new sub-cgroups. + cgroup.kill + A write-only single value file which exists in non-root cgroups. + The only allowed value is "1". + + Writing "1" to the file causes the cgroup and all descendant cgroups to + be killed. This means that all processes located in the affected cgroup + tree will be killed via SIGKILL. + + Killing a cgroup tree will deal with concurrent forks appropriately and + is protected against migrations. + + In a threaded cgroup, writing this file fails with EOPNOTSUPP as + killing cgroups is a process directed operation, i.e. it affects + the whole thread-group. + Controllers =========== @@ -1866,6 +1882,60 @@ IO Latency Interface Files duration of time between evaluation events. Windows only elapse with IO activity. Idle periods extend the most recent window. +IO Priority +~~~~~~~~~~~ + +A single attribute controls the behavior of the I/O priority cgroup policy, +namely the blkio.prio.class attribute. The following values are accepted for +that attribute: + + no-change + Do not modify the I/O priority class. + + none-to-rt + For requests that do not have an I/O priority class (NONE), + change the I/O priority class into RT. Do not modify + the I/O priority class of other requests. + + restrict-to-be + For requests that do not have an I/O priority class or that have I/O + priority class RT, change it into BE. Do not modify the I/O priority + class of requests that have priority class IDLE. + + idle + Change the I/O priority class of all requests into IDLE, the lowest + I/O priority class. + +The following numerical values are associated with the I/O priority policies: + ++-------------+---+ +| no-change | 0 | ++-------------+---+ +| none-to-rt | 1 | ++-------------+---+ +| rt-to-be | 2 | ++-------------+---+ +| all-to-idle | 3 | ++-------------+---+ + +The numerical value that corresponds to each I/O priority class is as follows: + ++-------------------------------+---+ +| IOPRIO_CLASS_NONE | 0 | ++-------------------------------+---+ +| IOPRIO_CLASS_RT (real-time) | 1 | ++-------------------------------+---+ +| IOPRIO_CLASS_BE (best effort) | 2 | ++-------------------------------+---+ +| IOPRIO_CLASS_IDLE | 3 | ++-------------------------------+---+ + +The algorithm to set the I/O priority class for a request is as follows: + +- Translate the I/O priority class policy into a number. +- Change the request I/O priority class into the maximum of the I/O priority + class policy number and the numerical I/O priority class. + PID --- diff --git a/Documentation/admin-guide/cputopology.rst b/Documentation/admin-guide/cputopology.rst index b90dafcc8237..8632a1db36e4 100644 --- a/Documentation/admin-guide/cputopology.rst +++ b/Documentation/admin-guide/cputopology.rst @@ -2,87 +2,10 @@ How CPU topology info is exported via sysfs =========================================== -Export CPU topology info via sysfs. Items (attributes) are similar -to /proc/cpuinfo output of some architectures. They reside in -/sys/devices/system/cpu/cpuX/topology/: - -physical_package_id: - - physical package id of cpuX. Typically corresponds to a physical - socket number, but the actual value is architecture and platform - dependent. - -die_id: - - the CPU die ID of cpuX. Typically it is the hardware platform's - identifier (rather than the kernel's). The actual value is - architecture and platform dependent. - -core_id: - - the CPU core ID of cpuX. Typically it is the hardware platform's - identifier (rather than the kernel's). The actual value is - architecture and platform dependent. - -book_id: - - the book ID of cpuX. Typically it is the hardware platform's - identifier (rather than the kernel's). The actual value is - architecture and platform dependent. - -drawer_id: - - the drawer ID of cpuX. Typically it is the hardware platform's - identifier (rather than the kernel's). The actual value is - architecture and platform dependent. - -core_cpus: - - internal kernel map of CPUs within the same core. - (deprecated name: "thread_siblings") - -core_cpus_list: - - human-readable list of CPUs within the same core. - (deprecated name: "thread_siblings_list"); - -package_cpus: - - internal kernel map of the CPUs sharing the same physical_package_id. - (deprecated name: "core_siblings") - -package_cpus_list: - - human-readable list of CPUs sharing the same physical_package_id. - (deprecated name: "core_siblings_list") - -die_cpus: - - internal kernel map of CPUs within the same die. - -die_cpus_list: - - human-readable list of CPUs within the same die. - -book_siblings: - - internal kernel map of cpuX's hardware threads within the same - book_id. - -book_siblings_list: - - human-readable list of cpuX's hardware threads within the same - book_id. - -drawer_siblings: - - internal kernel map of cpuX's hardware threads within the same - drawer_id. - -drawer_siblings_list: - - human-readable list of cpuX's hardware threads within the same - drawer_id. +CPU topology info is exported via sysfs. Items (attributes) are similar +to /proc/cpuinfo output of some architectures. They reside in +/sys/devices/system/cpu/cpuX/topology/. Please refer to the ABI file: +Documentation/ABI/stable/sysfs-devices-system-cpu. Architecture-neutral, drivers/base/topology.c, exports these attributes. However, the book and drawer related sysfs files will only be created if diff --git a/Documentation/admin-guide/device-mapper/writecache.rst b/Documentation/admin-guide/device-mapper/writecache.rst index dce0184e07ca..65427d8dfca6 100644 --- a/Documentation/admin-guide/device-mapper/writecache.rst +++ b/Documentation/admin-guide/device-mapper/writecache.rst @@ -12,7 +12,6 @@ first sector should contain valid superblock from previous invocation. Constructor parameters: 1. type of the cache device - "p" or "s" - - p - persistent memory - s - SSD 2. the underlying device that will be cached @@ -21,7 +20,6 @@ Constructor parameters: size) 5. the number of optional parameters (the parameters with an argument count as two) - start_sector n (default: 0) offset from the start of cache device in 512-byte sectors high_watermark n (default: 50) @@ -53,6 +51,27 @@ Constructor parameters: - some underlying devices perform better with fua, some with nofua. The user should test it + cleaner + when this option is activated (either in the constructor + arguments or by a message), the cache will not promote + new writes (however, writes to already cached blocks are + promoted, to avoid data corruption due to misordered + writes) and it will gradually writeback any cached + data. The userspace can then monitor the cleaning + process with "dmsetup status". When the number of cached + blocks drops to zero, userspace can unload the + dm-writecache target and replace it with dm-linear or + other targets. + max_age n + specifies the maximum age of a block in milliseconds. If + a block is stored in the cache for too long, it will be + written to the underlying device and cleaned up. + metadata_only + only metadata is promoted to the cache. This option + improves performance for heavier REQ_META workloads. + pause_writeback n (default: 3000) + pause writeback if there was some write I/O redirected to + the origin volume in the last n milliseconds Status: 1. error indicator - 0 if there was no error, otherwise error number @@ -77,3 +96,5 @@ Messages: 5. resume the device, so that it will use the linear target 6. the cache device is now inactive and it can be deleted + cleaner + See above "cleaner" constructor documentation. diff --git a/Documentation/admin-guide/ext4.rst b/Documentation/admin-guide/ext4.rst index d2795ca6821e..4c559e08d11e 100644 --- a/Documentation/admin-guide/ext4.rst +++ b/Documentation/admin-guide/ext4.rst @@ -392,7 +392,7 @@ When mounting an ext4 filesystem, the following option are accepted: dax Use direct access (no page cache). See - Documentation/filesystems/dax.txt. Note that this option is + Documentation/filesystems/dax.rst. Note that this option is incompatible with data=journal. inlinecrypt diff --git a/Documentation/admin-guide/hw-vuln/core-scheduling.rst b/Documentation/admin-guide/hw-vuln/core-scheduling.rst new file mode 100644 index 000000000000..7b410aef9c5c --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/core-scheduling.rst @@ -0,0 +1,223 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +Core Scheduling +=============== +Core scheduling support allows userspace to define groups of tasks that can +share a core. These groups can be specified either for security usecases (one +group of tasks don't trust another), or for performance usecases (some +workloads may benefit from running on the same core as they don't need the same +hardware resources of the shared core, or may prefer different cores if they +do share hardware resource needs). This document only describes the security +usecase. + +Security usecase +---------------- +A cross-HT attack involves the attacker and victim running on different Hyper +Threads of the same core. MDS and L1TF are examples of such attacks. The only +full mitigation of cross-HT attacks is to disable Hyper Threading (HT). Core +scheduling is a scheduler feature that can mitigate some (not all) cross-HT +attacks. It allows HT to be turned on safely by ensuring that only tasks in a +user-designated trusted group can share a core. This increase in core sharing +can also improve performance, however it is not guaranteed that performance +will always improve, though that is seen to be the case with a number of real +world workloads. In theory, core scheduling aims to perform at least as good as +when Hyper Threading is disabled. In practice, this is mostly the case though +not always: as synchronizing scheduling decisions across 2 or more CPUs in a +core involves additional overhead - especially when the system is lightly +loaded. When ``total_threads <= N_CPUS/2``, the extra overhead may cause core +scheduling to perform more poorly compared to SMT-disabled, where N_CPUS is the +total number of CPUs. Please measure the performance of your workloads always. + +Usage +----- +Core scheduling support is enabled via the ``CONFIG_SCHED_CORE`` config option. +Using this feature, userspace defines groups of tasks that can be co-scheduled +on the same core. The core scheduler uses this information to make sure that +tasks that are not in the same group never run simultaneously on a core, while +doing its best to satisfy the system's scheduling requirements. + +Core scheduling can be enabled via the ``PR_SCHED_CORE`` prctl interface. +This interface provides support for the creation of core scheduling groups, as +well as admission and removal of tasks from created groups:: + + #include <sys/prctl.h> + + int prctl(int option, unsigned long arg2, unsigned long arg3, + unsigned long arg4, unsigned long arg5); + +option: + ``PR_SCHED_CORE`` + +arg2: + Command for operation, must be one off: + + - ``PR_SCHED_CORE_GET`` -- get core_sched cookie of ``pid``. + - ``PR_SCHED_CORE_CREATE`` -- create a new unique cookie for ``pid``. + - ``PR_SCHED_CORE_SHARE_TO`` -- push core_sched cookie to ``pid``. + - ``PR_SCHED_CORE_SHARE_FROM`` -- pull core_sched cookie from ``pid``. + +arg3: + ``pid`` of the task for which the operation applies. + +arg4: + ``pid_type`` for which the operation applies. It is of type ``enum pid_type``. + For example, if arg4 is ``PIDTYPE_TGID``, then the operation of this command + will be performed for all tasks in the task group of ``pid``. + +arg5: + userspace pointer to an unsigned long for storing the cookie returned by + ``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands. + +In order for a process to push a cookie to, or pull a cookie from a process, it +is required to have the ptrace access mode: `PTRACE_MODE_READ_REALCREDS` to the +process. + +Building hierarchies of tasks +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The simplest way to build hierarchies of threads/processes which share a +cookie and thus a core is to rely on the fact that the core-sched cookie is +inherited across forks/clones and execs, thus setting a cookie for the +'initial' script/executable/daemon will place every spawned child in the +same core-sched group. + +Cookie Transferral +~~~~~~~~~~~~~~~~~~ +Transferring a cookie between the current and other tasks is possible using +PR_SCHED_CORE_SHARE_FROM and PR_SCHED_CORE_SHARE_TO to inherit a cookie from a +specified task or a share a cookie with a task. In combination this allows a +simple helper program to pull a cookie from a task in an existing core +scheduling group and share it with already running tasks. + +Design/Implementation +--------------------- +Each task that is tagged is assigned a cookie internally in the kernel. As +mentioned in `Usage`_, tasks with the same cookie value are assumed to trust +each other and share a core. + +The basic idea is that, every schedule event tries to select tasks for all the +siblings of a core such that all the selected tasks running on a core are +trusted (same cookie) at any point in time. Kernel threads are assumed trusted. +The idle task is considered special, as it trusts everything and everything +trusts it. + +During a schedule() event on any sibling of a core, the highest priority task on +the sibling's core is picked and assigned to the sibling calling schedule(), if +the sibling has the task enqueued. For rest of the siblings in the core, +highest priority task with the same cookie is selected if there is one runnable +in their individual run queues. If a task with same cookie is not available, +the idle task is selected. Idle task is globally trusted. + +Once a task has been selected for all the siblings in the core, an IPI is sent to +siblings for whom a new task was selected. Siblings on receiving the IPI will +switch to the new task immediately. If an idle task is selected for a sibling, +then the sibling is considered to be in a `forced idle` state. I.e., it may +have tasks on its on runqueue to run, however it will still have to run idle. +More on this in the next section. + +Forced-idling of hyperthreads +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The scheduler tries its best to find tasks that trust each other such that all +tasks selected to be scheduled are of the highest priority in a core. However, +it is possible that some runqueues had tasks that were incompatible with the +highest priority ones in the core. Favoring security over fairness, one or more +siblings could be forced to select a lower priority task if the highest +priority task is not trusted with respect to the core wide highest priority +task. If a sibling does not have a trusted task to run, it will be forced idle +by the scheduler (idle thread is scheduled to run). + +When the highest priority task is selected to run, a reschedule-IPI is sent to +the sibling to force it into idle. This results in 4 cases which need to be +considered depending on whether a VM or a regular usermode process was running +on either HT:: + + HT1 (attack) HT2 (victim) + A idle -> user space user space -> idle + B idle -> user space guest -> idle + C idle -> guest user space -> idle + D idle -> guest guest -> idle + +Note that for better performance, we do not wait for the destination CPU +(victim) to enter idle mode. This is because the sending of the IPI would bring +the destination CPU immediately into kernel mode from user space, or VMEXIT +in the case of guests. At best, this would only leak some scheduler metadata +which may not be worth protecting. It is also possible that the IPI is received +too late on some architectures, but this has not been observed in the case of +x86. + +Trust model +~~~~~~~~~~~ +Core scheduling maintains trust relationships amongst groups of tasks by +assigning them a tag that is the same cookie value. +When a system with core scheduling boots, all tasks are considered to trust +each other. This is because the core scheduler does not have information about +trust relationships until userspace uses the above mentioned interfaces, to +communicate them. In other words, all tasks have a default cookie value of 0. +and are considered system-wide trusted. The forced-idling of siblings running +cookie-0 tasks is also avoided. + +Once userspace uses the above mentioned interfaces to group sets of tasks, tasks +within such groups are considered to trust each other, but do not trust those +outside. Tasks outside the group also don't trust tasks within. + +Limitations of core-scheduling +------------------------------ +Core scheduling tries to guarantee that only trusted tasks run concurrently on a +core. But there could be small window of time during which untrusted tasks run +concurrently or kernel could be running concurrently with a task not trusted by +kernel. + +IPI processing delays +~~~~~~~~~~~~~~~~~~~~~ +Core scheduling selects only trusted tasks to run together. IPI is used to notify +the siblings to switch to the new task. But there could be hardware delays in +receiving of the IPI on some arch (on x86, this has not been observed). This may +cause an attacker task to start running on a CPU before its siblings receive the +IPI. Even though cache is flushed on entry to user mode, victim tasks on siblings +may populate data in the cache and micro architectural buffers after the attacker +starts to run and this is a possibility for data leak. + +Open cross-HT issues that core scheduling does not solve +-------------------------------------------------------- +1. For MDS +~~~~~~~~~~ +Core scheduling cannot protect against MDS attacks between an HT running in +user mode and another running in kernel mode. Even though both HTs run tasks +which trust each other, kernel memory is still considered untrusted. Such +attacks are possible for any combination of sibling CPU modes (host or guest mode). + +2. For L1TF +~~~~~~~~~~~ +Core scheduling cannot protect against an L1TF guest attacker exploiting a +guest or host victim. This is because the guest attacker can craft invalid +PTEs which are not inverted due to a vulnerable guest kernel. The only +solution is to disable EPT (Extended Page Tables). + +For both MDS and L1TF, if the guest vCPU is configured to not trust each +other (by tagging separately), then the guest to guest attacks would go away. +Or it could be a system admin policy which considers guest to guest attacks as +a guest problem. + +Another approach to resolve these would be to make every untrusted task on the +system to not trust every other untrusted task. While this could reduce +parallelism of the untrusted tasks, it would still solve the above issues while +allowing system processes (trusted tasks) to share a core. + +3. Protecting the kernel (IRQ, syscall, VMEXIT) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Unfortunately, core scheduling does not protect kernel contexts running on +sibling hyperthreads from one another. Prototypes of mitigations have been posted +to LKML to solve this, but it is debatable whether such windows are practically +exploitable, and whether the performance overhead of the prototypes are worth +it (not to mention, the added code complexity). + +Other Use cases +--------------- +The main use case for Core scheduling is mitigating the cross-HT vulnerabilities +with SMT enabled. There are other use cases where this feature could be used: + +- Isolating tasks that needs a whole core: Examples include realtime tasks, tasks + that uses SIMD instructions etc. +- Gang scheduling: Requirements for a group of tasks that needs to be scheduled + together could also be realized using core scheduling. One example is vCPUs of + a VM. diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index ca4dbdd9016d..f12cda55538b 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -15,3 +15,4 @@ are configurable at compile, boot or run time. tsx_async_abort multihit.rst special-register-buffer-data-sampling.rst + core-scheduling.rst diff --git a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst index 3b1ce68d2456..966c9b3296ea 100644 --- a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst +++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst @@ -3,7 +3,8 @@ SRBDS - Special Register Buffer Data Sampling ============================================= -SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to +SRBDS is a hardware vulnerability that allows MDS +Documentation/admin-guide/hw-vuln/mds.rst techniques to infer values returned from special register accesses. Special register accesses are accesses to off core registers. According to Intel's evaluation, the special register reads that have a security expectation of privacy are diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst index 75a9dd98e76e..cb30ca3df27c 100644 --- a/Documentation/admin-guide/kdump/kdump.rst +++ b/Documentation/admin-guide/kdump/kdump.rst @@ -2,7 +2,7 @@ Documentation for Kdump - The kexec-based Crash Dumping Solution ================================================================ -This document includes overview, setup and installation, and analysis +This document includes overview, setup, installation, and analysis information. Overview @@ -13,9 +13,9 @@ dump of the system kernel's memory needs to be taken (for example, when the system panics). The system kernel's memory image is preserved across the reboot and is accessible to the dump-capture kernel. -You can use common commands, such as cp and scp, to copy the -memory image to a dump file on the local disk, or across the network to -a remote system. +You can use common commands, such as cp, scp or makedumpfile to copy +the memory image to a dump file on the local disk, or across the network +to a remote system. Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, s390x, arm and arm64 architectures. @@ -26,13 +26,15 @@ the dump-capture kernel. This ensures that ongoing Direct Memory Access The kexec -p command loads the dump-capture kernel into this reserved memory. -On x86 machines, the first 640 KB of physical memory is needed to boot, -regardless of where the kernel loads. Therefore, kexec backs up this -region just before rebooting into the dump-capture kernel. +On x86 machines, the first 640 KB of physical memory is needed for boot, +regardless of where the kernel loads. For simpler handling, the whole +low 1M is reserved to avoid any later kernel or device driver writing +data into this area. Like this, the low 1M can be reused as system RAM +by kdump kernel without extra handling. -Similarly on PPC64 machines first 32KB of physical memory is needed for -booting regardless of where the kernel is loaded and to support 64K page -size kexec backs up the first 64KB memory. +On PPC64 machines first 32KB of physical memory is needed for booting +regardless of where the kernel is loaded and to support 64K page size +kexec backs up the first 64KB memory. For s390x, when kdump is triggered, the crashkernel region is exchanged with the region [0, crashkernel region size] and then the kdump kernel @@ -46,14 +48,14 @@ passed to the dump-capture kernel through the elfcorehdr= boot parameter. Optionally the size of the ELF header can also be passed when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax. - With the dump-capture kernel, you can access the memory image through /proc/vmcore. This exports the dump as an ELF-format file that you can -write out using file copy commands such as cp or scp. Further, you can -use analysis tools such as the GNU Debugger (GDB) and the Crash tool to -debug the dump file. This method ensures that the dump pages are correctly -ordered. - +write out using file copy commands such as cp or scp. You can also use +makedumpfile utility to analyze and write out filtered contents with +options, e.g with '-d 31' it will only write out kernel data. Further, +you can use analysis tools such as the GNU Debugger (GDB) and the Crash +tool to debug the dump file. This method ensures that the dump pages are +correctly ordered. Setup and Installation ====================== @@ -125,9 +127,18 @@ dump-capture kernels for enabling kdump support. System kernel config options ---------------------------- -1) Enable "kexec system call" in "Processor type and features.":: +1) Enable "kexec system call" or "kexec file based system call" in + "Processor type and features.":: + + CONFIG_KEXEC=y or CONFIG_KEXEC_FILE=y + + And both of them will select KEXEC_CORE:: - CONFIG_KEXEC=y + CONFIG_KEXEC_CORE=y + + Subsequently, CRASH_CORE is selected by KEXEC_CORE:: + + CONFIG_CRASH_CORE=y 2) Enable "sysfs file system support" in "Filesystem" -> "Pseudo filesystems." This is usually enabled by default:: @@ -175,17 +186,19 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64) CONFIG_HIGHMEM4G -2) On i386 and x86_64, disable symmetric multi-processing support - under "Processor type and features":: +2) With CONFIG_SMP=y, usually nr_cpus=1 need specified on the kernel + command line when loading the dump-capture kernel because one + CPU is enough for kdump kernel to dump vmcore on most of systems. - CONFIG_SMP=n + However, you can also specify nr_cpus=X to enable multiple processors + in kdump kernel. In this case, "disable_cpu_apicid=" is needed to + tell kdump kernel which cpu is 1st kernel's BSP. Please refer to + admin-guide/kernel-parameters.txt for more details. - (If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line - when loading the dump-capture kernel, see section "Load the Dump-capture - Kernel".) + With CONFIG_SMP=n, the above things are not related. -3) If one wants to build and use a relocatable kernel, - Enable "Build a relocatable kernel" support under "Processor type and +3) A relocatable kernel is suggested to be built by default. If not yet, + enable "Build a relocatable kernel" support under "Processor type and features":: CONFIG_RELOCATABLE=y @@ -232,7 +245,7 @@ Dump-capture kernel config options (Arch Dependent, ia64) as a dump-capture kernel if desired. The crashkernel region can be automatically placed by the system - kernel at run time. This is done by specifying the base address as 0, + kernel at runtime. This is done by specifying the base address as 0, or omitting it all together:: crashkernel=256M@0 @@ -241,10 +254,6 @@ Dump-capture kernel config options (Arch Dependent, ia64) crashkernel=256M - If the start address is specified, note that the start address of the - kernel will be aligned to 64Mb, so if the start address is not then - any space below the alignment point will be wasted. - Dump-capture kernel config options (Arch Dependent, arm) ---------------------------------------------------------- @@ -260,46 +269,82 @@ Dump-capture kernel config options (Arch Dependent, arm64) on non-VHE systems even if it is configured. This is because the CPU will not be reset to EL2 on panic. -Extended crashkernel syntax +crashkernel syntax =========================== +1) crashkernel=size@offset -While the "crashkernel=size[@offset]" syntax is sufficient for most -configurations, sometimes it's handy to have the reserved memory dependent -on the value of System RAM -- that's mostly for distributors that pre-setup -the kernel command line to avoid a unbootable system after some memory has -been removed from the machine. + Here 'size' specifies how much memory to reserve for the dump-capture kernel + and 'offset' specifies the beginning of this reserved memory. For example, + "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory + starting at physical address 0x01000000 (16MB) for the dump-capture kernel. -The syntax is:: + The crashkernel region can be automatically placed by the system + kernel at run time. This is done by specifying the base address as 0, + or omitting it all together:: - crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset] - range=start-[end] + crashkernel=256M@0 -For example:: + or:: - crashkernel=512M-2G:64M,2G-:128M + crashkernel=256M -This would mean: + If the start address is specified, note that the start address of the + kernel will be aligned to a value (which is Arch dependent), so if the + start address is not then any space below the alignment point will be + wasted. - 1) if the RAM is smaller than 512M, then don't reserve anything - (this is the "rescue" case) - 2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M - 3) if the RAM size is larger than 2G, then reserve 128M +2) range1:size1[,range2:size2,...][@offset] + While the "crashkernel=size[@offset]" syntax is sufficient for most + configurations, sometimes it's handy to have the reserved memory dependent + on the value of System RAM -- that's mostly for distributors that pre-setup + the kernel command line to avoid a unbootable system after some memory has + been removed from the machine. + The syntax is:: -Boot into System Kernel -======================= + crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset] + range=start-[end] + + For example:: + + crashkernel=512M-2G:64M,2G-:128M + This would mean: + + 1) if the RAM is smaller than 512M, then don't reserve anything + (this is the "rescue" case) + 2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M + 3) if the RAM size is larger than 2G, then reserve 128M + +3) crashkernel=size,high and crashkernel=size,low + + If memory above 4G is preferred, crashkernel=size,high can be used to + fulfill that. With it, physical memory is allowed to be allocated from top, + so could be above 4G if system has more than 4G RAM installed. Otherwise, + memory region will be allocated below 4G if available. + + When crashkernel=X,high is passed, kernel could allocate physical memory + region above 4G, low memory under 4G is needed in this case. There are + three ways to get low memory: + + 1) Kernel will allocate at least 256M memory below 4G automatically + if crashkernel=Y,low is not specified. + 2) Let user specify low memory size instead. + 3) Specified value 0 will disable low memory allocation:: + + crashkernel=0,low + +Boot into System Kernel +----------------------- 1) Update the boot loader (such as grub, yaboot, or lilo) configuration files as necessary. -2) Boot the system kernel with the boot parameter "crashkernel=Y@X", - where Y specifies how much memory to reserve for the dump-capture kernel - and X specifies the beginning of this reserved memory. For example, - "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory - starting at physical address 0x01000000 (16MB) for the dump-capture kernel. +2) Boot the system kernel with the boot parameter "crashkernel=Y@X". - On x86 and x86_64, use "crashkernel=64M@16M". + On x86 and x86_64, use "crashkernel=Y[@X]". Most of the time, the + start address 'X' is not necessary, kernel will search a suitable + area. Unless an explicit start address is expected. On ppc64, use "crashkernel=128M@32M". @@ -331,8 +376,8 @@ of dump-capture kernel. Following is the summary. For i386 and x86_64: - - Use vmlinux if kernel is not relocatable. - Use bzImage/vmlinuz if kernel is relocatable. + - Use vmlinux if kernel is not relocatable. For ppc64: @@ -392,7 +437,7 @@ loading dump-capture kernel. For i386, x86_64 and ia64: - "1 irqpoll maxcpus=1 reset_devices" + "1 irqpoll nr_cpus=1 reset_devices" For ppc64: @@ -400,7 +445,7 @@ For ppc64: For s390x: - "1 maxcpus=1 cgroup_disable=memory" + "1 nr_cpus=1 cgroup_disable=memory" For arm: @@ -408,7 +453,7 @@ For arm: For arm64: - "1 maxcpus=1 reset_devices" + "1 nr_cpus=1 reset_devices" Notes on loading the dump-capture kernel: @@ -488,6 +533,10 @@ the following command:: cp /proc/vmcore <dump-file> +You can also use makedumpfile utility to write out the dump file +with specified options to filter out unwanted contents, e.g:: + + makedumpfile -l --message-level 1 -d 31 /proc/vmcore <dump-file> Analysis ======== @@ -535,8 +584,7 @@ This will cause a kdump to occur at the add_taint()->panic() call. Contact ======= -- Vivek Goyal (vgoyal@redhat.com) -- Maneesh Soni (maneesh@in.ibm.com) +- kexec@lists.infradead.org GDB macros ========== diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 3996b54158bf..01ba293a2d70 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -76,6 +76,11 @@ to change, such as less cores in the CPU list, then N and any ranges using N will also change. Use the same on a small 4 core system, and "16-N" becomes "16-3" and now the same boot input will be flagged as invalid (start > end). +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(). 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 diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index cb89dbdedc46..b4ee11198762 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -113,7 +113,7 @@ the GPE dispatcher. This facility can be used to prevent such uncontrolled GPE floodings. - Format: <byte> + Format: <byte> or <bitmap-list> acpi_no_auto_serialize [HW,ACPI] Disable auto-serialization of AML methods @@ -301,6 +301,9 @@ allowed anymore to lift isolation requirements as needed. This option does not override iommu=pt + force_enable - Force enable the IOMMU on platforms known + to be buggy with IOMMU enabled. Use this + option with care. amd_iommu_dump= [HW,X86-64] Enable AMD IOMMU driver option to dump the ACPI table @@ -497,16 +500,21 @@ ccw_timeout_log [S390] See Documentation/s390/common_io.rst for details. - cgroup_disable= [KNL] Disable a particular controller - Format: {name of the controller(s) to disable} + cgroup_disable= [KNL] Disable a particular controller or optional feature + Format: {name of the controller(s) or feature(s) to disable} The effects of cgroup_disable=foo are: - foo isn't auto-mounted if you mount all cgroups in a single hierarchy - foo isn't visible as an individually mountable subsystem + - if foo is an optional feature then the feature is + disabled and corresponding cgroup files are not + created {Currently only "memory" controller deal with this and cut the overhead, others just disable the usage. So only cgroup_disable=memory is actually worthy} + Specifying "pressure" disables per-cgroup pressure + stall information accounting feature cgroup_no_v1= [KNL] Disable cgroup controllers and named hierarchies in v1 Format: { { controller | "all" | "named" } @@ -581,6 +589,28 @@ loops can be debugged more effectively on production systems. + clocksource.max_cswd_read_retries= [KNL] + Number of clocksource_watchdog() retries due to + external delays before the clock will be marked + unstable. Defaults to three retries, that is, + four attempts to read the clock under test. + + clocksource.verify_n_cpus= [KNL] + Limit the number of CPUs checked for clocksources + marked with CLOCK_SOURCE_VERIFY_PERCPU that + are marked unstable due to excessive skew. + A negative value says to check all CPUs, while + zero says not to check any. Values larger than + nr_cpu_ids are silently truncated to nr_cpu_ids. + The actual CPUs are chosen randomly, with + no replacement if the same CPU is chosen twice. + + clocksource-wdtest.holdoff= [KNL] + Set the time in seconds that the clocksource + watchdog test waits before commencing its tests. + Defaults to zero when built as a module and to + 10 seconds when built into the kernel. + clearcpuid=BITNUM[,BITNUM...] [X86] Disable CPUID feature X for the kernel. See arch/x86/include/asm/cpufeatures.h for the valid bit @@ -1567,6 +1597,23 @@ Documentation/admin-guide/mm/hugetlbpage.rst. Format: size[KMG] + hugetlb_free_vmemmap= + [KNL] Reguires CONFIG_HUGETLB_PAGE_FREE_VMEMMAP + enabled. + Allows heavy hugetlb users to free up some more + memory (6 * PAGE_SIZE for each 2MB hugetlb page). + Format: { on | off (default) } + + on: enable the feature + off: disable the feature + + Built with CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON=y, + the default is on. + + This is not compatible with memory_hotplug.memmap_on_memory. + If both parameters are enabled, hugetlb_free_vmemmap takes + precedence over memory_hotplug.memmap_on_memory. + hung_task_panic= [KNL] Should the hung task detector generate panics. Format: 0 | 1 @@ -1987,7 +2034,7 @@ forcing Dual Address Cycle for PCI cards supporting greater than 32-bit addressing. - iommu.strict= [ARM64] Configure TLB invalidation behaviour + iommu.strict= [ARM64, X86] Configure TLB invalidation behaviour Format: { "0" | "1" } 0 - Lazy mode. Request that DMA unmap operations use deferred @@ -1998,6 +2045,10 @@ 1 - Strict mode (default). DMA unmap operations invalidate IOMMU hardware TLBs synchronously. + Note: on x86, the default behaviour depends on the + equivalent driver-specific parameters, but a strict + mode explicitly specified by either method takes + precedence. iommu.passthrough= [ARM64, X86] Configure DMA to bypass the IOMMU by default. @@ -2833,6 +2884,10 @@ Note that even when enabled, there are a few cases where the feature is not effective. + This is not compatible with hugetlb_free_vmemmap. If + both parameters are enabled, hugetlb_free_vmemmap takes + precedence over memory_hotplug.memmap_on_memory. + memtest= [KNL,X86,ARM,PPC,RISCV] Enable memtest Format: <integer> default : 0 <disable> @@ -3244,7 +3299,7 @@ noclflush [BUGS=X86] Don't use the CLFLUSH instruction - nodelayacct [KNL] Disable per-task delay accounting + delayacct [KNL] Enable per-task delay accounting nodsp [SH] Disable hardware DSP at boot time. @@ -3513,6 +3568,9 @@ nr_uarts= [SERIAL] maximum number of UARTs to be registered. + numa=off [KNL, ARM64, PPC, RISCV, SPARC, X86] Disable NUMA, Only + set up a single NUMA node spanning all memory. + numa_balancing= [KNL,ARM64,PPC,RISCV,S390,X86] Enable or disable automatic NUMA balancing. Allowed values are enable and disable @@ -3566,6 +3624,12 @@ off: turn off poisoning (default) on: turn on poisoning + page_reporting.page_reporting_order= + [KNL] Minimal page reporting order + Format: <integer> + Adjust the minimal page reporting order. The page + reporting is disabled when it exceeds (MAX_ORDER-1). + panic= [KNL] Kernel behaviour on panic: delay <timeout> timeout > 0: seconds before rebooting timeout = 0: wait forever @@ -4290,6 +4354,11 @@ whole algorithm to behave better in low memory condition. + rcutree.rcu_delay_page_cache_fill_msec= [KNL] + Set the page-cache refill delay (in milliseconds) + in response to low-memory conditions. The range + of permitted values is in the range 0:100000. + rcutree.jiffies_till_first_fqs= [KNL] Set delay from grace-period initialization to first attempt to force quiescent states. @@ -4775,11 +4844,6 @@ Reserves a hole at the top of the kernel virtual address space. - reservelow= [X86] - Format: nn[K] - Set the amount of memory to reserve for BIOS at - the bottom of the address space. - reset_devices [KNL] Force drivers to reset the underlying device during initialization. @@ -5283,6 +5347,14 @@ exception. Default behavior is by #AC if both features are enabled in hardware. + ratelimit:N - + Set system wide rate limit to N bus locks + per second for bus lock detection. + 0 < N <= 1000. + + N/A for split lock detection. + + If an #AC exception is hit in the kernel or in firmware (i.e. not while executing in user mode) the kernel will oops in either "warn" or "fatal" @@ -5605,12 +5677,25 @@ Note, echoing 1 into this file without the tracepoint_printk kernel cmdline option has no effect. + The tp_printk_stop_on_boot (see below) can also be used + to stop the printing of events to console at + late_initcall_sync. + ** CAUTION ** Having tracepoints sent to printk() and activating high frequency tracepoints such as irq or sched, can cause the system to live lock. + tp_printk_stop_on_boot[FTRACE] + When tp_printk (above) is set, it can cause a lot of noise + on the console. It may be useful to only include the + printing of events during boot up, as user space may + make the system inoperable. + + This command line option will stop the printing of events + to console at the late_initcall_sync() time frame. + traceoff_on_warning [FTRACE] enable this option to disable tracing when a warning is hit. This turns off "tracing_on". Tracing can diff --git a/Documentation/admin-guide/laptops/laptop-mode.rst b/Documentation/admin-guide/laptops/laptop-mode.rst index c984c4262f2e..b61cc601d298 100644 --- a/Documentation/admin-guide/laptops/laptop-mode.rst +++ b/Documentation/admin-guide/laptops/laptop-mode.rst @@ -101,17 +101,6 @@ this results in concentration of disk activity in a small time interval which occurs only once every 10 minutes, or whenever the disk is forced to spin up by a cache miss. The disk can then be spun down in the periods of inactivity. -If you want to find out which process caused the disk to spin up, you can -gather information by setting the flag /proc/sys/vm/block_dump. When this flag -is set, Linux reports all disk read and write operations that take place, and -all block dirtyings done to files. This makes it possible to debug why a disk -needs to spin up, and to increase battery life even more. The output of -block_dump is written to the kernel output, and it can be retrieved using -"dmesg". When you use block_dump and your kernel logging level also includes -kernel debugging messages, you probably want to turn off klogd, otherwise -the output of block_dump will be logged, causing disk activity that is not -normally there. - Configuration ------------- diff --git a/Documentation/admin-guide/lockup-watchdogs.rst b/Documentation/admin-guide/lockup-watchdogs.rst index 290840c160af..3e09284a8b9b 100644 --- a/Documentation/admin-guide/lockup-watchdogs.rst +++ b/Documentation/admin-guide/lockup-watchdogs.rst @@ -39,7 +39,7 @@ in principle, they should work in any architecture where these subsystems are present. A periodic hrtimer runs to generate interrupts and kick the watchdog -task. An NMI perf event is generated every "watchdog_thresh" +job. An NMI perf event is generated every "watchdog_thresh" (compile-time initialized to 10 and configurable through sysctl of the same name) seconds to check for hardlockups. If any CPU in the system does not receive any hrtimer interrupt during that time the @@ -47,7 +47,7 @@ does not receive any hrtimer interrupt during that time the generate a kernel warning or call panic, depending on the configuration. -The watchdog task is a high priority kernel thread that updates a +The watchdog job runs in a stop scheduling thread that updates a timestamp every time it is scheduled. If that timestamp is not updated for 2*watchdog_thresh seconds (the softlockup threshold) the 'softlockup detector' (coded inside the hrtimer callback function) diff --git a/Documentation/admin-guide/media/bt8xx.rst b/Documentation/admin-guide/media/bt8xx.rst index 1382ada1e38e..3589f6ab7e46 100644 --- a/Documentation/admin-guide/media/bt8xx.rst +++ b/Documentation/admin-guide/media/bt8xx.rst @@ -15,11 +15,12 @@ Authors: General information ------------------- -This class of cards has a bt878a as the PCI interface, and require the bttv driver -for accessing the i2c bus and the gpio pins of the bt8xx chipset. +This class of cards has a bt878a as the PCI interface, and require the bttv +driver for accessing the i2c bus and the gpio pins of the bt8xx chipset. -Please see :doc:`bttv-cardlist` for a complete list of Cards based on the -Conexant Bt8xx PCI bridge supported by the Linux Kernel. +Please see Documentation/admin-guide/media/bttv-cardlist.rst for a complete +list of Cards based on the Conexant Bt8xx PCI bridge supported by the +Linux Kernel. In order to be able to compile the kernel, some config options should be enabled:: @@ -80,7 +81,7 @@ for dvb-bt8xx drivers by passing modprobe parameters may be necessary. Running TwinHan and Clones ~~~~~~~~~~~~~~~~~~~~~~~~~~ -As shown at :doc:`bttv-cardlist`, TwinHan and +As shown at Documentation/admin-guide/media/bttv-cardlist.rst, TwinHan and clones use ``card=113`` modprobe parameter. So, in order to properly detect it for devices without EEPROM, you should use:: @@ -105,12 +106,12 @@ The autodetected values are determined by the cards' "response string". In your logs see f. ex.: dst_get_device_id: Recognize [DSTMCI]. For bug reports please send in a complete log with verbose=4 activated. -Please also see :doc:`ci`. +Please also see Documentation/admin-guide/media/ci.rst. Running multiple cards ~~~~~~~~~~~~~~~~~~~~~~ -See :doc:`bttv-cardlist` for a complete list of +See Documentation/admin-guide/media/bttv-cardlist.rst for a complete list of Card ID. Some examples: =========================== === diff --git a/Documentation/admin-guide/media/bttv.rst b/Documentation/admin-guide/media/bttv.rst index 0ef1f203104d..125f6f47123d 100644 --- a/Documentation/admin-guide/media/bttv.rst +++ b/Documentation/admin-guide/media/bttv.rst @@ -24,7 +24,8 @@ If your board has digital TV, you'll also need:: ./scripts/config -m DVB_BT8XX -In this case, please see :doc:`bt8xx` for additional notes. +In this case, please see Documentation/admin-guide/media/bt8xx.rst +for additional notes. Make bttv work with your card ----------------------------- @@ -39,7 +40,7 @@ If it doesn't bttv likely could not autodetect your card and needs some insmod options. The most important insmod option for bttv is "card=n" to select the correct card type. If you get video but no sound you've very likely specified the wrong (or no) card type. A list of supported -cards is in :doc:`bttv-cardlist`. +cards is in Documentation/admin-guide/media/bttv-cardlist.rst. If bttv takes very long to load (happens sometimes with the cheap cards which have no tuner), try adding this to your modules configuration @@ -57,8 +58,8 @@ directory should be enough for it to be autoload during the driver's probing mode (e. g. when the Kernel boots or when the driver is manually loaded via ``modprobe`` command). -If your card isn't listed in :doc:`bttv-cardlist` or if you have -trouble making audio work, please read :ref:`still_doesnt_work`. +If your card isn't listed in Documentation/admin-guide/media/bttv-cardlist.rst +or if you have trouble making audio work, please read :ref:`still_doesnt_work`. Autodetecting cards @@ -77,8 +78,8 @@ the Subsystem ID in the second line, looks like this: only bt878-based cards can have a subsystem ID (which does not mean that every card really has one). bt848 cards can't have a Subsystem ID and therefore can't be autodetected. There is a list with the ID's -at :doc:`bttv-cardlist` (in case you are interested or want to mail -patches with updates). +at Documentation/admin-guide/media/bttv-cardlist.rst +(in case you are interested or want to mail patches with updates). .. _still_doesnt_work: @@ -259,15 +260,15 @@ bug. It is very helpful if you can tell where exactly it broke With a hard freeze you probably doesn't find anything in the logfiles. The only way to capture any kernel messages is to hook up a serial console and let some terminal application log the messages. /me uses -screen. See :doc:`/admin-guide/serial-console` for details on setting -up a serial console. +screen. See Documentation/admin-guide/serial-console.rst for details on +setting up a serial console. -Read :doc:`/admin-guide/bug-hunting` to learn how to get any useful +Read Documentation/admin-guide/bug-hunting.rst to learn how to get any useful information out of a register+stack dump printed by the kernel on protection faults (so-called "kernel oops"). If you run into some kind of deadlock, you can try to dump a call trace -for each process using sysrq-t (see :doc:`/admin-guide/sysrq`). +for each process using sysrq-t (see Documentation/admin-guide/sysrq.rst). This way it is possible to figure where *exactly* some process in "D" state is stuck. diff --git a/Documentation/admin-guide/media/index.rst b/Documentation/admin-guide/media/index.rst index 6e0d2bae7154..c676af665111 100644 --- a/Documentation/admin-guide/media/index.rst +++ b/Documentation/admin-guide/media/index.rst @@ -11,12 +11,14 @@ its supported drivers. Please see: -- :doc:`/userspace-api/media/index` - for the userspace APIs used on media devices. +Documentation/userspace-api/media/index.rst -- :doc:`/driver-api/media/index` - for driver development information and Kernel APIs used by - media devices; + - for the userspace APIs used on media devices. + +Documentation/driver-api/media/index.rst + + - for driver development information and Kernel APIs used by + media devices; The media subsystem =================== diff --git a/Documentation/admin-guide/media/ipu3.rst b/Documentation/admin-guide/media/ipu3.rst index f59697c7b374..52c1c04173da 100644 --- a/Documentation/admin-guide/media/ipu3.rst +++ b/Documentation/admin-guide/media/ipu3.rst @@ -234,22 +234,23 @@ The IPU3 ImgU pipelines can be configured using the Media Controller, defined at Running mode and firmware binary selection ------------------------------------------ -ImgU works based on firmware, currently the ImgU firmware support run 2 pipes in -time-sharing with single input frame data. Each pipe can run at certain mode - -"VIDEO" or "STILL", "VIDEO" mode is commonly used for video frames capture, and -"STILL" is used for still frame capture. However, you can also select "VIDEO" to -capture still frames if you want to capture images with less system load and -power. For "STILL" mode, ImgU will try to use smaller BDS factor and output -larger bayer frame for further YUV processing than "VIDEO" mode to get high -quality images. Besides, "STILL" mode need XNR3 to do noise reduction, hence -"STILL" mode will need more power and memory bandwidth than "VIDEO" mode. TNR -will be enabled in "VIDEO" mode and bypassed by "STILL" mode. ImgU is running at -“VIDEO” mode by default, the user can use v4l2 control V4L2_CID_INTEL_IPU3_MODE -(currently defined in drivers/staging/media/ipu3/include/intel-ipu3.h) to query -and set the running mode. For user, there is no difference for buffer queueing -between the "VIDEO" and "STILL" mode, mandatory input and main output node -should be enabled and buffers need be queued, the statistics and the view-finder -queues are optional. +ImgU works based on firmware, currently the ImgU firmware support run 2 pipes +in time-sharing with single input frame data. Each pipe can run at certain mode +- "VIDEO" or "STILL", "VIDEO" mode is commonly used for video frames capture, +and "STILL" is used for still frame capture. However, you can also select +"VIDEO" to capture still frames if you want to capture images with less system +load and power. For "STILL" mode, ImgU will try to use smaller BDS factor and +output larger bayer frame for further YUV processing than "VIDEO" mode to get +high quality images. Besides, "STILL" mode need XNR3 to do noise reduction, +hence "STILL" mode will need more power and memory bandwidth than "VIDEO" mode. +TNR will be enabled in "VIDEO" mode and bypassed by "STILL" mode. ImgU is +running at "VIDEO" mode by default, the user can use v4l2 control +V4L2_CID_INTEL_IPU3_MODE (currently defined in +drivers/staging/media/ipu3/include/uapi/intel-ipu3.h) to query and set the +running mode. For user, there is no difference for buffer queueing between the +"VIDEO" and "STILL" mode, mandatory input and main output node should be +enabled and buffers need be queued, the statistics and the view-finder queues +are optional. The firmware binary will be selected according to current running mode, such log "using binary if_to_osys_striped " or "using binary if_to_osys_primary_striped" @@ -586,7 +587,7 @@ preserved. References ========== -.. [#f5] drivers/staging/media/ipu3/include/intel-ipu3.h +.. [#f5] drivers/staging/media/ipu3/include/uapi/intel-ipu3.h .. [#f1] https://github.com/intel/nvt diff --git a/Documentation/admin-guide/media/saa7134.rst b/Documentation/admin-guide/media/saa7134.rst index 7ab9c70b9abe..51eae7eb5ab7 100644 --- a/Documentation/admin-guide/media/saa7134.rst +++ b/Documentation/admin-guide/media/saa7134.rst @@ -50,7 +50,8 @@ To build and install, you should run:: Once the new Kernel is booted, saa7134 driver should be loaded automatically. Depending on the card you might have to pass ``card=<nr>`` as insmod option. -If so, please check :doc:`saa7134-cardlist` for valid choices. +If so, please check Documentation/admin-guide/media/saa7134-cardlist.rst +for valid choices. Once you have your card type number, you can pass a modules configuration via a file (usually, it is either ``/etc/modules.conf`` or some file at diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index f7b1c7462991..8abaeb144e44 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -60,6 +60,10 @@ HugePages_Surp the pool above the value in ``/proc/sys/vm/nr_hugepages``. The maximum number of surplus huge pages is controlled by ``/proc/sys/vm/nr_overcommit_hugepages``. + Note: When the feature of freeing unused vmemmap pages associated + with each hugetlb page is enabled, the number of surplus huge pages + may be temporarily larger than the maximum number of surplus huge + pages when the system is under memory pressure. Hugepagesize is the default hugepage size (in Kb). Hugetlb @@ -80,6 +84,10 @@ returned to the huge page pool when freed by a task. A user with root privileges can dynamically allocate more or free some persistent huge pages by increasing or decreasing the value of ``nr_hugepages``. +Note: When the feature of freeing unused vmemmap pages associated with each +hugetlb page is enabled, we can fail to free the huge pages triggered by +the user when ths system is under memory pressure. Please try again later. + Pages that are used as huge pages are reserved inside the kernel and cannot be used for other purposes. Huge pages cannot be swapped out under memory pressure. @@ -145,6 +153,9 @@ default_hugepagesz will all result in 256 2M huge pages being allocated. Valid default huge page size is architecture dependent. +hugetlb_free_vmemmap + When CONFIG_HUGETLB_PAGE_FREE_VMEMMAP is set, this enables freeing + unused vmemmap pages associated with each HugeTLB page. When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages`` indicates the current number of pre-allocated huge pages of the default size. diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index 05d51d2d8beb..c6bae2d77160 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -357,6 +357,19 @@ creates ZONE_MOVABLE as following. Unfortunately, there is no information to show which memory block belongs to ZONE_MOVABLE. This is TBD. + Memory offlining can fail when dissolving a free huge page on ZONE_MOVABLE + and the feature of freeing unused vmemmap pages associated with each hugetlb + page is enabled. + + This can happen when we have plenty of ZONE_MOVABLE memory, but not enough + kernel memory to allocate vmemmmap pages. We may even be able to migrate + huge page contents, but will not be able to dissolve the source huge page. + This will prevent an offline operation and is unfortunate as memory offlining + is expected to succeed on movable zones. Users that depend on memory hotplug + to succeed for movable zones should carefully consider whether the memory + savings gained from this feature are worth the risk of possibly not being + able to offline memory in certain situations. + .. note:: Techniques that rely on long-term pinnings of memory (especially, RDMA and vfio) are fundamentally problematic with ZONE_MOVABLE and, therefore, memory diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst index 340a5aee9b80..fb578fbbb76c 100644 --- a/Documentation/admin-guide/mm/pagemap.rst +++ b/Documentation/admin-guide/mm/pagemap.rst @@ -21,6 +21,8 @@ There are four components to pagemap: * Bit 55 pte is soft-dirty (see :ref:`Documentation/admin-guide/mm/soft-dirty.rst <soft_dirty>`) * Bit 56 page exclusively mapped (since 4.2) + * Bit 57 pte is uffd-wp write-protected (since 5.13) (see + :ref:`Documentation/admin-guide/mm/userfaultfd.rst <userfaultfd>`) * Bits 57-60 zero * Bit 61 page is file-page or shared-anon (since 3.5) * Bit 62 page swapped diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst index 3aa38e8b8361..6528036093e1 100644 --- a/Documentation/admin-guide/mm/userfaultfd.rst +++ b/Documentation/admin-guide/mm/userfaultfd.rst @@ -77,7 +77,8 @@ events, except page fault notifications, may be generated: - ``UFFD_FEATURE_MINOR_HUGETLBFS`` indicates that the kernel supports ``UFFDIO_REGISTER_MODE_MINOR`` registration for hugetlbfs virtual memory - areas. + areas. ``UFFD_FEATURE_MINOR_SHMEM`` is the analogous feature indicating + support for shmem virtual memory areas. The userland application should set the feature flags it intends to use when invoking the ``UFFDIO_API`` ioctl, to request that those features be diff --git a/Documentation/admin-guide/pm/cpuidle.rst b/Documentation/admin-guide/pm/cpuidle.rst index 10fde58d0869..aec2cd2aaea7 100644 --- a/Documentation/admin-guide/pm/cpuidle.rst +++ b/Documentation/admin-guide/pm/cpuidle.rst @@ -347,81 +347,8 @@ for tickless systems. It follows the same basic strategy as the ``menu`` `one <menu-gov_>`_: it always tries to find the deepest idle state suitable for the given conditions. However, it applies a different approach to that problem. -First, it does not use sleep length correction factors, but instead it attempts -to correlate the observed idle duration values with the available idle states -and use that information to pick up the idle state that is most likely to -"match" the upcoming CPU idle interval. Second, it does not take the tasks -that were running on the given CPU in the past and are waiting on some I/O -operations to complete now at all (there is no guarantee that they will run on -the same CPU when they become runnable again) and the pattern detection code in -it avoids taking timer wakeups into account. It also only uses idle duration -values less than the current time till the closest timer (with the scheduler -tick excluded) for that purpose. - -Like in the ``menu`` governor `case <menu-gov_>`_, the first step is to obtain -the *sleep length*, which is the time until the closest timer event with the -assumption that the scheduler tick will be stopped (that also is the upper bound -on the time until the next CPU wakeup). That value is then used to preselect an -idle state on the basis of three metrics maintained for each idle state provided -by the ``CPUIdle`` driver: ``hits``, ``misses`` and ``early_hits``. - -The ``hits`` and ``misses`` metrics measure the likelihood that a given idle -state will "match" the observed (post-wakeup) idle duration if it "matches" the -sleep length. They both are subject to decay (after a CPU wakeup) every time -the target residency of the idle state corresponding to them is less than or -equal to the sleep length and the target residency of the next idle state is -greater than the sleep length (that is, when the idle state corresponding to -them "matches" the sleep length). The ``hits`` metric is increased if the -former condition is satisfied and the target residency of the given idle state -is less than or equal to the observed idle duration and the target residency of -the next idle state is greater than the observed idle duration at the same time -(that is, it is increased when the given idle state "matches" both the sleep -length and the observed idle duration). In turn, the ``misses`` metric is -increased when the given idle state "matches" the sleep length only and the -observed idle duration is too short for its target residency. - -The ``early_hits`` metric measures the likelihood that a given idle state will -"match" the observed (post-wakeup) idle duration if it does not "match" the -sleep length. It is subject to decay on every CPU wakeup and it is increased -when the idle state corresponding to it "matches" the observed (post-wakeup) -idle duration and the target residency of the next idle state is less than or -equal to the sleep length (i.e. the idle state "matching" the sleep length is -deeper than the given one). - -The governor walks the list of idle states provided by the ``CPUIdle`` driver -and finds the last (deepest) one with the target residency less than or equal -to the sleep length. Then, the ``hits`` and ``misses`` metrics of that idle -state are compared with each other and it is preselected if the ``hits`` one is -greater (which means that that idle state is likely to "match" the observed idle -duration after CPU wakeup). If the ``misses`` one is greater, the governor -preselects the shallower idle state with the maximum ``early_hits`` metric -(or if there are multiple shallower idle states with equal ``early_hits`` -metric which also is the maximum, the shallowest of them will be preselected). -[If there is a wakeup latency constraint coming from the `PM QoS framework -<cpu-pm-qos_>`_ which is hit before reaching the deepest idle state with the -target residency within the sleep length, the deepest idle state with the exit -latency within the constraint is preselected without consulting the ``hits``, -``misses`` and ``early_hits`` metrics.] - -Next, the governor takes several idle duration values observed most recently -into consideration and if at least a half of them are greater than or equal to -the target residency of the preselected idle state, that idle state becomes the -final candidate to ask for. Otherwise, the average of the most recent idle -duration values below the target residency of the preselected idle state is -computed and the governor walks the idle states shallower than the preselected -one and finds the deepest of them with the target residency within that average. -That idle state is then taken as the final candidate to ask for. - -Still, at this point the governor may need to refine the idle state selection if -it has not decided to `stop the scheduler tick <idle-cpus-and-tick_>`_. That -generally happens if the target residency of the idle state selected so far is -less than the tick period and the tick has not been stopped already (in a -previous iteration of the idle loop). Then, like in the ``menu`` governor -`case <menu-gov_>`_, the sleep length used in the previous computations may not -reflect the real time until the closest timer event and if it really is greater -than that time, a shallower state with a suitable target residency may need to -be selected. - +.. kernel-doc:: drivers/cpuidle/governors/teo.c + :doc: teo-description .. _idle-states-representation: diff --git a/Documentation/admin-guide/pm/intel_idle.rst b/Documentation/admin-guide/pm/intel_idle.rst index 89309e1b0e48..b799a43da62e 100644 --- a/Documentation/admin-guide/pm/intel_idle.rst +++ b/Documentation/admin-guide/pm/intel_idle.rst @@ -20,8 +20,8 @@ Nehalem and later generations of Intel processors, but the level of support for a particular processor model in it depends on whether or not it recognizes that processor model and may also depend on information coming from the platform firmware. [To understand ``intel_idle`` it is necessary to know how ``CPUIdle`` -works in general, so this is the time to get familiar with :doc:`cpuidle` if you -have not done that yet.] +works in general, so this is the time to get familiar with +Documentation/admin-guide/pm/cpuidle.rst if you have not done that yet.] ``intel_idle`` uses the ``MWAIT`` instruction to inform the processor that the logical CPU executing it is idle and so it may be possible to put some of the @@ -53,7 +53,8 @@ processor) corresponding to them depends on the processor model and it may also depend on the configuration of the platform. In order to create a list of available idle states required by the ``CPUIdle`` -subsystem (see :ref:`idle-states-representation` in :doc:`cpuidle`), +subsystem (see :ref:`idle-states-representation` in +Documentation/admin-guide/pm/cpuidle.rst), ``intel_idle`` can use two sources of information: static tables of idle states for different processor models included in the driver itself and the ACPI tables of the system. The former are always used if the processor model at hand is @@ -98,7 +99,8 @@ states may not be enabled by default if there are no matching entries in the preliminary list of idle states coming from the ACPI tables. In that case user space still can enable them later (on a per-CPU basis) with the help of the ``disable`` idle state attribute in ``sysfs`` (see -:ref:`idle-states-representation` in :doc:`cpuidle`). This basically means that +:ref:`idle-states-representation` in +Documentation/admin-guide/pm/cpuidle.rst). This basically means that the idle states "known" to the driver may not be enabled by default if they have not been exposed by the platform firmware (through the ACPI tables). @@ -186,7 +188,8 @@ be desirable. In practice, it is only really necessary to do that if the idle states in question cannot be enabled during system startup, because in the working state of the system the CPU power management quality of service (PM QoS) feature can be used to prevent ``CPUIdle`` from touching those idle states -even if they have been enumerated (see :ref:`cpu-pm-qos` in :doc:`cpuidle`). +even if they have been enumerated (see :ref:`cpu-pm-qos` in +Documentation/admin-guide/pm/cpuidle.rst). Setting ``max_cstate`` to 0 causes the ``intel_idle`` initialization to fail. The ``no_acpi`` and ``use_acpi`` module parameters (recognized by ``intel_idle`` @@ -202,7 +205,8 @@ Namely, the positions of the bits that are set in the ``states_off`` value are the indices of idle states to be disabled by default (as reflected by the names of the corresponding idle state directories in ``sysfs``, :file:`state0`, :file:`state1` ... :file:`state<i>` ..., where ``<i>`` is the index of the given -idle state; see :ref:`idle-states-representation` in :doc:`cpuidle`). +idle state; see :ref:`idle-states-representation` in +Documentation/admin-guide/pm/cpuidle.rst). For example, if ``states_off`` is equal to 3, the driver will disable idle states 0 and 1 by default, and if it is equal to 8, idle state 3 will be diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index df29b4f1f219..d5043cd8d2f5 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -18,8 +18,8 @@ General Information (``CPUFreq``). It is a scaling driver for the Sandy Bridge and later generations of Intel processors. Note, however, that some of those processors may not be supported. [To understand ``intel_pstate`` it is necessary to know -how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if -you have not done that yet.] +how ``CPUFreq`` works in general, so this is the time to read +Documentation/admin-guide/pm/cpufreq.rst if you have not done that yet.] For the processors supported by ``intel_pstate``, the P-state concept is broader than just an operating frequency or an operating performance point (see the @@ -365,6 +365,9 @@ argument is passed to the kernel in the command line. inclusive) including both turbo and non-turbo P-states (see `Turbo P-states Support`_). + This attribute is present only if the value exposed by it is the same + for all of the CPUs in the system. + The value of this attribute is not affected by the ``no_turbo`` setting described `below <no_turbo_attr_>`_. @@ -374,6 +377,9 @@ argument is passed to the kernel in the command line. Ratio of the `turbo range <turbo_>`_ size to the size of the entire range of supported P-states, in percent. + This attribute is present only if the value exposed by it is the same + for all of the CPUs in the system. + This attribute is read-only. .. _no_turbo_attr: @@ -445,8 +451,9 @@ Interpretation of Policy Attributes ----------------------------------- The interpretation of some ``CPUFreq`` policy attributes described in -:doc:`cpufreq` is special with ``intel_pstate`` as the current scaling driver -and it generally depends on the driver's `operation mode <Operation Modes_>`_. +Documentation/admin-guide/pm/cpufreq.rst is special with ``intel_pstate`` +as the current scaling driver and it generally depends on the driver's +`operation mode <Operation Modes_>`_. First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and ``scaling_cur_freq`` attributes are produced by applying a processor-specific diff --git a/Documentation/admin-guide/pstore-blk.rst b/Documentation/admin-guide/pstore-blk.rst index 49d8149f8d32..2d22ead9520e 100644 --- a/Documentation/admin-guide/pstore-blk.rst +++ b/Documentation/admin-guide/pstore-blk.rst @@ -45,15 +45,18 @@ blkdev The block device to use. Most of the time, it is a partition of block device. It's required for pstore/blk. It is also used for MTD device. -It accepts the following variants for block device: +When pstore/blk is built as a module, "blkdev" accepts the following variants: -1. <hex_major><hex_minor> device number in hexadecimal represents itself; no - leading 0x, for example b302. -#. /dev/<disk_name> represents the device number of disk +1. /dev/<disk_name> represents the device number of disk #. /dev/<disk_name><decimal> represents the device number of partition - device number of disk plus the partition number #. /dev/<disk_name>p<decimal> - same as the above; this form is used when disk name of partitioned disk ends with a digit. + +When pstore/blk is built into the kernel, "blkdev" accepts the following variants: + +#. <hex_major><hex_minor> device number in hexadecimal representation, + with no leading 0x, for example b302. #. PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF represents the unique id of a partition if the partition table provides it. The UUID may be either an EFI/GPT UUID, or refer to an MSDOS partition using the format SSSSSSSS-PP, @@ -227,8 +230,5 @@ For developer reference, here are all the important structures and APIs: .. kernel-doc:: include/linux/pstore_zone.h :internal: -.. kernel-doc:: fs/pstore/blk.c - :internal: - .. kernel-doc:: include/linux/pstore_blk.h :internal: diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst index 18d8e25ba9df..d7ac13f789cc 100644 --- a/Documentation/admin-guide/reporting-issues.rst +++ b/Documentation/admin-guide/reporting-issues.rst @@ -1248,7 +1248,7 @@ paragraph makes the severeness obvious. In case you performed a successful bisection, use the title of the change that introduced the regression as the second part of your subject. Make the report -also mention the commit id of the culprit. In case of an unsuccessful bisection, +also mention the commit id of the culprit. In case of an unsuccessful bisection, make your report mention the latest tested version that's working fine (say 5.7) and the oldest where the issue occurs (say 5.8-rc1). diff --git a/Documentation/admin-guide/sysctl/abi.rst b/Documentation/admin-guide/sysctl/abi.rst index 77b1d1b2ad42..4e6db0a2a4c0 100644 --- a/Documentation/admin-guide/sysctl/abi.rst +++ b/Documentation/admin-guide/sysctl/abi.rst @@ -11,7 +11,7 @@ Documentation for /proc/sys/abi/ Copyright (c) 2020, Stephen Kitt -For general info, see :doc:`index`. +For general info, see Documentation/admin-guide/sysctl/index.rst. ------------------------------------------------------------------------------ diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 1d56a6b73a4e..426162009ce9 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -9,7 +9,8 @@ Copyright (c) 1998, 1999, Rik van Riel <riel@nl.linux.org> Copyright (c) 2009, Shen Feng<shen@cn.fujitsu.com> -For general info and legal blurb, please look in :doc:`index`. +For general info and legal blurb, please look in +Documentation/admin-guide/sysctl/index.rst. ------------------------------------------------------------------------------ @@ -54,7 +55,7 @@ free space valid for 30 seconds. acpi_video_flags ================ -See :doc:`/power/video`. This allows the video resume mode to be set, +See Documentation/power/video.rst. This allows the video resume mode to be set, in a similar fashion to the ``acpi_sleep`` kernel parameter, by combining the following values: @@ -89,7 +90,7 @@ is 0x15 and the full version number is 0x234, this file will contain the value 340 = 0x154. See the ``type_of_loader`` and ``ext_loader_type`` fields in -:doc:`/x86/boot` for additional information. +Documentation/x86/boot.rst for additional information. bootloader_version (x86 only) @@ -99,7 +100,7 @@ The complete bootloader version number. In the example above, this file will contain the value 564 = 0x234. See the ``type_of_loader`` and ``ext_loader_ver`` fields in -:doc:`/x86/boot` for additional information. +Documentation/x86/boot.rst for additional information. bpf_stats_enabled @@ -269,7 +270,7 @@ see the ``hostname(1)`` man page. firmware_config =============== -See :doc:`/driver-api/firmware/fallback-mechanisms`. +See Documentation/driver-api/firmware/fallback-mechanisms.rst. The entries in this directory allow the firmware loader helper fallback to be controlled: @@ -297,7 +298,7 @@ crashes and outputting them to a serial console. ftrace_enabled, stack_tracer_enabled ==================================== -See :doc:`/trace/ftrace`. +See Documentation/trace/ftrace.rst. hardlockup_all_cpu_backtrace @@ -325,7 +326,7 @@ when a hard lockup is detected. 1 Panic on hard lockup. = =========================== -See :doc:`/admin-guide/lockup-watchdogs` for more information. +See Documentation/admin-guide/lockup-watchdogs.rst for more information. This can also be set using the nmi_watchdog kernel parameter. @@ -333,7 +334,12 @@ hotplug ======= Path for the hotplug policy agent. -Default value is "``/sbin/hotplug``". +Default value is ``CONFIG_UEVENT_HELPER_PATH``, which in turn defaults +to the empty string. + +This file only exists when ``CONFIG_UEVENT_HELPER`` is enabled. Most +modern systems rely exclusively on the netlink-based uevent source and +don't need this. hung_task_all_cpu_backtrace @@ -483,10 +489,11 @@ modprobe ======== The full path to the usermode helper for autoloading kernel modules, -by default "/sbin/modprobe". This binary is executed when the kernel -requests a module. For example, if userspace passes an unknown -filesystem type to mount(), then the kernel will automatically request -the corresponding filesystem module by executing this usermode helper. +by default ``CONFIG_MODPROBE_PATH``, which in turn defaults to +"/sbin/modprobe". This binary is executed when the kernel requests a +module. For example, if userspace passes an unknown filesystem type +to mount(), then the kernel will automatically request the +corresponding filesystem module by executing this usermode helper. This usermode helper should insert the needed module into the kernel. This sysctl only affects module autoloading. It has no effect on the @@ -581,7 +588,8 @@ in a KVM virtual machine. This default can be overridden by adding:: nmi_watchdog=1 -to the guest kernel command line (see :doc:`/admin-guide/kernel-parameters`). +to the guest kernel command line (see +Documentation/admin-guide/kernel-parameters.rst). numa_balancing @@ -1066,7 +1074,7 @@ that support this feature. real-root-dev ============= -See :doc:`/admin-guide/initrd`. +See Documentation/admin-guide/initrd.rst. reboot-cmd (SPARC only) @@ -1087,6 +1095,13 @@ Model available). If your platform happens to meet the requirements for EAS but you do not want to use it, change this value to 0. +task_delayacct +=============== + +Enables/disables task delay accounting (see +:doc:`accounting/delay-accounting.rst`). Enabling this feature incurs +a small amount of overhead in the scheduler but is useful for debugging +and performance tuning. It is required by some tools such as iotop. sched_schedstats ================ @@ -1153,7 +1168,7 @@ will take effect. seccomp ======= -See :doc:`/userspace-api/seccomp_filter`. +See Documentation/userspace-api/seccomp_filter.rst. sg-big-buff @@ -1282,11 +1297,11 @@ This parameter can be used to control the soft lockup detector. = ================================= The soft lockup detector monitors CPUs for threads that are hogging the CPUs -without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads -from running. The mechanism depends on the CPUs ability to respond to timer -interrupts which are needed for the 'watchdog/N' threads to be woken up by -the watchdog timer function, otherwise the NMI watchdog — if enabled — can -detect a hard lockup condition. +without rescheduling voluntarily, and thus prevent the 'migration/N' threads +from running, causing the watchdog work fail to execute. The mechanism depends +on the CPUs ability to respond to timer interrupts which are needed for the +watchdog work to be queued by the watchdog timer function, otherwise the NMI +watchdog — if enabled — can detect a hard lockup condition. stack_erasing @@ -1324,7 +1339,7 @@ the boot PROM. sysrq ===== -See :doc:`/admin-guide/sysrq`. +See Documentation/admin-guide/sysrq.rst. tainted @@ -1354,15 +1369,16 @@ ORed together. The letters are seen in "Tainted" line of Oops reports. 131072 `(T)` The kernel was built with the struct randomization plugin ====== ===== ============================================================== -See :doc:`/admin-guide/tainted-kernels` for more information. +See Documentation/admin-guide/tainted-kernels.rst for more information. Note: writes to this sysctl interface will fail with ``EINVAL`` if the kernel is booted with the command line option ``panic_on_taint=<bitmask>,nousertaint`` and any of the ORed together values being written to ``tainted`` match with the bitmask declared on panic_on_taint. - See :doc:`/admin-guide/kernel-parameters` for more details on that particular - kernel command line option and its optional ``nousertaint`` switch. + See Documentation/admin-guide/kernel-parameters.rst for more details on + that particular kernel command line option and its optional + ``nousertaint`` switch. threads-max =========== @@ -1386,7 +1402,7 @@ If a value outside of this range is written to ``threads-max`` an traceoff_on_warning =================== -When set, disables tracing (see :doc:`/trace/ftrace`) when a +When set, disables tracing (see Documentation/trace/ftrace.rst) when a ``WARN()`` is hit. @@ -1406,8 +1422,8 @@ will send them to printk() again. This only works if the kernel was booted with ``tp_printk`` enabled. -See :doc:`/admin-guide/kernel-parameters` and -:doc:`/trace/boottime-trace`. +See Documentation/admin-guide/kernel-parameters.rst and +Documentation/trace/boottime-trace.rst. .. _unaligned-dump-stack: @@ -1457,11 +1473,22 @@ unprivileged_bpf_disabled ========================= Writing 1 to this entry will disable unprivileged calls to ``bpf()``; -once disabled, calling ``bpf()`` without ``CAP_SYS_ADMIN`` will return -``-EPERM``. +once disabled, calling ``bpf()`` without ``CAP_SYS_ADMIN`` or ``CAP_BPF`` +will return ``-EPERM``. Once set to 1, this can't be cleared from the +running kernel anymore. -Once set, this can't be cleared. +Writing 2 to this entry will also disable unprivileged calls to ``bpf()``, +however, an admin can still change this setting later on, if needed, by +writing 0 or 1 to this entry. +If ``BPF_UNPRIV_DEFAULT_OFF`` is enabled in the kernel config, then this +entry will default to 2 instead of 0. + += ============================================================= +0 Unprivileged calls to ``bpf()`` are enabled +1 Unprivileged calls to ``bpf()`` are disabled without recovery +2 Unprivileged calls to ``bpf()`` are disabled += ============================================================= watchdog ======== diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index 586cd4b86428..003d5cc3751b 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -25,7 +25,6 @@ files can be found in mm/swap.c. Currently, these files are in /proc/sys/vm: - admin_reserve_kbytes -- block_dump - compact_memory - compaction_proactiveness - compact_unevictable_allowed @@ -64,7 +63,7 @@ Currently, these files are in /proc/sys/vm: - overcommit_ratio - page-cluster - panic_on_oom -- percpu_pagelist_fraction +- percpu_pagelist_high_fraction - stat_interval - stat_refresh - numa_stat @@ -106,13 +105,6 @@ On x86_64 this is about 128MB. Changing this takes effect whenever an application requests memory. -block_dump -========== - -block_dump enables block I/O debugging when set to a nonzero value. More -information on block I/O debugging is in Documentation/admin-guide/laptops/laptop-mode.rst. - - compact_memory ============== @@ -790,22 +782,24 @@ panic_on_oom=2+kdump gives you very strong tool to investigate why oom happens. You can get snapshot. -percpu_pagelist_fraction -======================== +percpu_pagelist_high_fraction +============================= -This is the fraction of pages at most (high mark pcp->high) in each zone that -are allocated for each per cpu page list. The min value for this is 8. It -means that we don't allow more than 1/8th of pages in each zone to be -allocated in any single per_cpu_pagelist. This entry only changes the value -of hot per cpu pagelists. User can specify a number like 100 to allocate -1/100th of each zone to each per cpu page list. +This is the fraction of pages in each zone that are can be stored to +per-cpu page lists. It is an upper boundary that is divided depending +on the number of online CPUs. The min value for this is 8 which means +that we do not allow more than 1/8th of pages in each zone to be stored +on per-cpu page lists. This entry only changes the value of hot per-cpu +page lists. A user can specify a number like 100 to allocate 1/100th of +each zone between per-cpu lists. -The batch value of each per cpu pagelist is also updated as a result. It is -set to pcp->high/4. The upper limit of batch is (PAGE_SHIFT * 8) +The batch value of each per-cpu page list remains the same regardless of +the value of the high fraction so allocation latencies are unaffected. -The initial value is zero. Kernel does not use this value at boot time to set -the high water marks for each per cpu page list. If the user writes '0' to this -sysctl, it will revert to this default behavior. +The initial value is zero. Kernel uses this value to set the high pcp->high +mark based on the low watermark for the zone and the number of local +online CPUs. If the user writes '0' to this sysctl, it will revert to +this default behavior. stat_interval @@ -936,12 +930,12 @@ allocations, THP and hugetlbfs pages. To make it sensible with respect to the watermark_scale_factor parameter, the unit is in fractions of 10,000. The default value of -15,000 on !DISCONTIGMEM configurations means that up to 150% of the high -watermark will be reclaimed in the event of a pageblock being mixed due -to fragmentation. The level of reclaim is determined by the number of -fragmentation events that occurred in the recent past. If this value is -smaller than a pageblock then a pageblocks worth of pages will be reclaimed -(e.g. 2MB on 64-bit x86). A boost factor of 0 will disable the feature. +15,000 means that up to 150% of the high watermark will be reclaimed in the +event of a pageblock being mixed due to fragmentation. The level of reclaim +is determined by the number of fragmentation events that occurred in the +recent past. If this value is smaller than a pageblock then a pageblocks +worth of pages will be reclaimed (e.g. 2MB on 64-bit x86). A boost factor +of 0 will disable the feature. watermark_scale_factor diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst index c50be711ec72..db2246493d18 100644 --- a/Documentation/arm/marvell.rst +++ b/Documentation/arm/marvell.rst @@ -259,7 +259,7 @@ Storage family https://web.archive.org/web/20191129073953/http://www.marvell.com/storage/armada-sp/ Core: - Sheeva ARMv7 comatible Quad-core PJ4C + Sheeva ARMv7 compatible Quad-core PJ4C (not supported in upstream Linux kernel) diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 18b8cc1bf32c..a9192e7a231b 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -277,6 +277,12 @@ Before jumping into the kernel, the following conditions must be met: - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1. + For CPUs with support for HCRX_EL2 (FEAT_HCX) present: + + - If EL3 is present and the kernel is entered at EL2: + + - SCR_EL3.HXEn (bit 38) must be initialised to 0b1. + For CPUs with Advanced SIMD and floating point support: - If EL3 is present: diff --git a/Documentation/block/bfq-iosched.rst b/Documentation/block/bfq-iosched.rst index 66c5a4e54130..df3a8a47f58c 100644 --- a/Documentation/block/bfq-iosched.rst +++ b/Documentation/block/bfq-iosched.rst @@ -553,20 +553,36 @@ throughput sustainable with bfq, because updating the blkio.bfq.* stats is rather costly, especially for some of the stats enabled by CONFIG_BFQ_CGROUP_DEBUG. -Parameters to set ------------------ +Parameters +---------- -For each group, there is only the following parameter to set. +For each group, the following parameters can be set: -weight (namely blkio.bfq.weight or io.bfq-weight): the weight of the -group inside its parent. Available values: 1..1000 (default 100). The -linear mapping between ioprio and weights, described at the beginning -of the tunable section, is still valid, but all weights higher than -IOPRIO_BE_NR*10 are mapped to ioprio 0. + weight + This specifies the default weight for the cgroup inside its parent. + Available values: 1..1000 (default: 100). -Recall that, if low-latency is set, then BFQ automatically raises the -weight of the queues associated with interactive and soft real-time -applications. Unset this tunable if you need/want to control weights. + For cgroup v1, it is set by writing the value to `blkio.bfq.weight`. + + For cgroup v2, it is set by writing the value to `io.bfq.weight`. + (with an optional prefix of `default` and a space). + + The linear mapping between ioprio and weights, described at the beginning + of the tunable section, is still valid, but all weights higher than + IOPRIO_BE_NR*10 are mapped to ioprio 0. + + Recall that, if low-latency is set, then BFQ automatically raises the + weight of the queues associated with interactive and soft real-time + applications. Unset this tunable if you need/want to control weights. + + weight_device + This specifies a per-device weight for the cgroup. The syntax is + `minor:major weight`. A weight of `0` may be used to reset to the default + weight. + + For cgroup v1, it is set by writing the value to `blkio.bfq.weight_device`. + + For cgroup v2, the file name is `io.bfq.weight`. [1] diff --git a/Documentation/block/biodoc.rst b/Documentation/block/biodoc.rst index 1d4d71e391af..2098477851a4 100644 --- a/Documentation/block/biodoc.rst +++ b/Documentation/block/biodoc.rst @@ -196,7 +196,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address do not have a corresponding kernel virtual address space mapping) and low-memory pages. -Note: Please refer to :doc:`/core-api/dma-api-howto` for a discussion +Note: Please refer to Documentation/core-api/dma-api-howto.rst for a discussion on PCI high mem DMA aspects and mapping of scatter gather lists, and support for 64 bit PCI. diff --git a/Documentation/block/blk-mq.rst b/Documentation/block/blk-mq.rst index a980d23af48c..d96118c73954 100644 --- a/Documentation/block/blk-mq.rst +++ b/Documentation/block/blk-mq.rst @@ -62,7 +62,7 @@ queue, to be sent in the future, when the hardware is able. Software staging queues ~~~~~~~~~~~~~~~~~~~~~~~ -The block IO subsystem adds requests in the software staging queues +The block IO subsystem adds requests in the software staging queues (represented by struct blk_mq_ctx) in case that they weren't sent directly to the driver. A request is one or more BIOs. They arrived at the block layer through the data structure struct bio. The block layer @@ -132,7 +132,7 @@ In order to indicate which request has been completed, every request is identified by an integer, ranging from 0 to the dispatch queue size. This tag is generated by the block layer and later reused by the device driver, removing the need to create a redundant identifier. When a request is completed in the -drive, the tag is sent back to the block layer to notify it of the finalization. +driver, the tag is sent back to the block layer to notify it of the finalization. This removes the need to do a linear search to find out which IO has been completed. diff --git a/Documentation/block/data-integrity.rst b/Documentation/block/data-integrity.rst index 4f2452a95c43..07a97aa26668 100644 --- a/Documentation/block/data-integrity.rst +++ b/Documentation/block/data-integrity.rst @@ -1,4 +1,4 @@ -============== +============== Data Integrity ============== diff --git a/Documentation/block/stat.rst b/Documentation/block/stat.rst index 77311335c08b..a1cd9db2058f 100644 --- a/Documentation/block/stat.rst +++ b/Documentation/block/stat.rst @@ -18,7 +18,7 @@ A. each, it would be impossible to guarantee that a set of readings represent a single point in time. -The stat file consists of a single line of text containing 11 decimal +The stat file consists of a single line of text containing 17 decimal values separated by whitespace. The fields are summarized in the following table, and described in more detail below. diff --git a/Documentation/bpf/bpf_lsm.rst b/Documentation/bpf/bpf_lsm.rst index 1c0a75a51d79..0dc3fb0d9544 100644 --- a/Documentation/bpf/bpf_lsm.rst +++ b/Documentation/bpf/bpf_lsm.rst @@ -20,10 +20,10 @@ LSM hook: Other LSM hooks which can be instrumented can be found in ``include/linux/lsm_hooks.h``. -eBPF programs that use :doc:`/bpf/btf` do not need to include kernel headers -for accessing information from the attached eBPF program's context. They can -simply declare the structures in the eBPF program and only specify the fields -that need to be accessed. +eBPF programs that use Documentation/bpf/btf.rst do not need to include kernel +headers for accessing information from the attached eBPF program's context. +They can simply declare the structures in the eBPF program and only specify +the fields that need to be accessed. .. code-block:: c @@ -88,8 +88,9 @@ example: The ``__attribute__((preserve_access_index))`` is a clang feature that allows the BPF verifier to update the offsets for the access at runtime using the -:doc:`/bpf/btf` information. Since the BPF verifier is aware of the types, it -also validates all the accesses made to the various types in the eBPF program. +Documentation/bpf/btf.rst information. Since the BPF verifier is aware of the +types, it also validates all the accesses made to the various types in the +eBPF program. Loading ------- diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index a702f67dd45f..baea6c2abba5 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -12,6 +12,19 @@ BPF instruction-set. The Cilium project also maintains a `BPF and XDP Reference Guide`_ that goes into great technical depth about the BPF Architecture. +libbpf +====== + +Libbpf is a userspace library for loading and interacting with bpf programs. + +.. toctree:: + :maxdepth: 1 + + libbpf/libbpf + libbpf/libbpf_api + libbpf/libbpf_build + libbpf/libbpf_naming_convention + BPF Type Format (BTF) ===================== @@ -84,6 +97,7 @@ Other :maxdepth: 1 ringbuf + llvm_reloc .. Links: .. _networking-filter: ../networking/filter.rst diff --git a/Documentation/bpf/libbpf/libbpf.rst b/Documentation/bpf/libbpf/libbpf.rst new file mode 100644 index 000000000000..1b1e61d5ead1 --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +libbpf +====== + +This is documentation for libbpf, a userspace library for loading and +interacting with bpf programs. + +All general BPF questions, including kernel functionality, libbpf APIs and +their application, should be sent to bpf@vger.kernel.org mailing list. +You can `subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the +mailing list search its `archive <https://lore.kernel.org/bpf/>`_. +Please search the archive before asking new questions. It very well might +be that this was already addressed or answered before. diff --git a/Documentation/bpf/libbpf/libbpf_api.rst b/Documentation/bpf/libbpf/libbpf_api.rst new file mode 100644 index 000000000000..f07eecd054da --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf_api.rst @@ -0,0 +1,27 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +API +=== + +This documentation is autogenerated from header files in libbpf, tools/lib/bpf + +.. kernel-doc:: tools/lib/bpf/libbpf.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf.h + :internal: + +.. kernel-doc:: tools/lib/bpf/btf.h + :internal: + +.. kernel-doc:: tools/lib/bpf/xsk.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf_tracing.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf_core_read.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf_endian.h + :internal:
\ No newline at end of file diff --git a/Documentation/bpf/libbpf/libbpf_build.rst b/Documentation/bpf/libbpf/libbpf_build.rst new file mode 100644 index 000000000000..8e8c23e8093d --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf_build.rst @@ -0,0 +1,37 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +Building libbpf +=============== + +libelf and zlib are internal dependencies of libbpf and thus are required to link +against and must be installed on the system for applications to work. +pkg-config is used by default to find libelf, and the program called +can be overridden with PKG_CONFIG. + +If using pkg-config at build time is not desired, it can be disabled by +setting NO_PKG_CONFIG=1 when calling make. + +To build both static libbpf.a and shared libbpf.so: + +.. code-block:: bash + + $ cd src + $ make + +To build only static libbpf.a library in directory build/ and install them +together with libbpf headers in a staging directory root/: + +.. code-block:: bash + + $ cd src + $ mkdir build root + $ BUILD_STATIC_ONLY=y OBJDIR=build DESTDIR=root make install + +To build both static libbpf.a and shared libbpf.so against a custom libelf +dependency installed in /build/root/ and install them together with libbpf +headers in a build directory /build/root/: + +.. code-block:: bash + + $ cd src + $ PKG_CONFIG_PATH=/build/root/lib64/pkgconfig DESTDIR=/build/root make
\ No newline at end of file diff --git a/Documentation/bpf/libbpf/libbpf_naming_convention.rst b/Documentation/bpf/libbpf/libbpf_naming_convention.rst new file mode 100644 index 000000000000..3de1d51e41da --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf_naming_convention.rst @@ -0,0 +1,162 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +API naming convention +===================== + +libbpf API provides access to a few logically separated groups of +functions and types. Every group has its own naming convention +described here. It's recommended to follow these conventions whenever a +new function or type is added to keep libbpf API clean and consistent. + +All types and functions provided by libbpf API should have one of the +following prefixes: ``bpf_``, ``btf_``, ``libbpf_``, ``xsk_``, +``btf_dump_``, ``ring_buffer_``, ``perf_buffer_``. + +System call wrappers +-------------------- + +System call wrappers are simple wrappers for commands supported by +sys_bpf system call. These wrappers should go to ``bpf.h`` header file +and map one to one to corresponding commands. + +For example ``bpf_map_lookup_elem`` wraps ``BPF_MAP_LOOKUP_ELEM`` +command of sys_bpf, ``bpf_prog_attach`` wraps ``BPF_PROG_ATTACH``, etc. + +Objects +------- + +Another class of types and functions provided by libbpf API is "objects" +and functions to work with them. Objects are high-level abstractions +such as BPF program or BPF map. They're represented by corresponding +structures such as ``struct bpf_object``, ``struct bpf_program``, +``struct bpf_map``, etc. + +Structures are forward declared and access to their fields should be +provided via corresponding getters and setters rather than directly. + +These objects are associated with corresponding parts of ELF object that +contains compiled BPF programs. + +For example ``struct bpf_object`` represents ELF object itself created +from an ELF file or from a buffer, ``struct bpf_program`` represents a +program in ELF object and ``struct bpf_map`` is a map. + +Functions that work with an object have names built from object name, +double underscore and part that describes function purpose. + +For example ``bpf_object__open`` consists of the name of corresponding +object, ``bpf_object``, double underscore and ``open`` that defines the +purpose of the function to open ELF file and create ``bpf_object`` from +it. + +All objects and corresponding functions other than BTF related should go +to ``libbpf.h``. BTF types and functions should go to ``btf.h``. + +Auxiliary functions +------------------- + +Auxiliary functions and types that don't fit well in any of categories +described above should have ``libbpf_`` prefix, e.g. +``libbpf_get_error`` or ``libbpf_prog_type_by_name``. + +AF_XDP functions +------------------- + +AF_XDP functions should have an ``xsk_`` prefix, e.g. +``xsk_umem__get_data`` or ``xsk_umem__create``. The interface consists +of both low-level ring access functions and high-level configuration +functions. These can be mixed and matched. Note that these functions +are not reentrant for performance reasons. + +ABI +========== + +libbpf can be both linked statically or used as DSO. To avoid possible +conflicts with other libraries an application is linked with, all +non-static libbpf symbols should have one of the prefixes mentioned in +API documentation above. See API naming convention to choose the right +name for a new symbol. + +Symbol visibility +----------------- + +libbpf follow the model when all global symbols have visibility "hidden" +by default and to make a symbol visible it has to be explicitly +attributed with ``LIBBPF_API`` macro. For example: + +.. code-block:: c + + LIBBPF_API int bpf_prog_get_fd_by_id(__u32 id); + +This prevents from accidentally exporting a symbol, that is not supposed +to be a part of ABI what, in turn, improves both libbpf developer- and +user-experiences. + +ABI versionning +--------------- + +To make future ABI extensions possible libbpf ABI is versioned. +Versioning is implemented by ``libbpf.map`` version script that is +passed to linker. + +Version name is ``LIBBPF_`` prefix + three-component numeric version, +starting from ``0.0.1``. + +Every time ABI is being changed, e.g. because a new symbol is added or +semantic of existing symbol is changed, ABI version should be bumped. +This bump in ABI version is at most once per kernel development cycle. + +For example, if current state of ``libbpf.map`` is: + +.. code-block:: c + + LIBBPF_0.0.1 { + global: + bpf_func_a; + bpf_func_b; + local: + \*; + }; + +, and a new symbol ``bpf_func_c`` is being introduced, then +``libbpf.map`` should be changed like this: + +.. code-block:: c + + LIBBPF_0.0.1 { + global: + bpf_func_a; + bpf_func_b; + local: + \*; + }; + LIBBPF_0.0.2 { + global: + bpf_func_c; + } LIBBPF_0.0.1; + +, where new version ``LIBBPF_0.0.2`` depends on the previous +``LIBBPF_0.0.1``. + +Format of version script and ways to handle ABI changes, including +incompatible ones, described in details in [1]. + +Stand-alone build +------------------- + +Under https://github.com/libbpf/libbpf there is a (semi-)automated +mirror of the mainline's version of libbpf for a stand-alone build. + +However, all changes to libbpf's code base must be upstreamed through +the mainline kernel tree. + +License +------------------- + +libbpf is dual-licensed under LGPL 2.1 and BSD 2-Clause. + +Links +------------------- + +[1] https://www.akkadia.org/drepper/dsohowto.pdf + (Chapter 3. Maintaining APIs and ABIs). diff --git a/Documentation/bpf/llvm_reloc.rst b/Documentation/bpf/llvm_reloc.rst new file mode 100644 index 000000000000..ca8957d5b671 --- /dev/null +++ b/Documentation/bpf/llvm_reloc.rst @@ -0,0 +1,240 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +==================== +BPF LLVM Relocations +==================== + +This document describes LLVM BPF backend relocation types. + +Relocation Record +================= + +LLVM BPF backend records each relocation with the following 16-byte +ELF structure:: + + typedef struct + { + Elf64_Addr r_offset; // Offset from the beginning of section. + Elf64_Xword r_info; // Relocation type and symbol index. + } Elf64_Rel; + +For example, for the following code:: + + int g1 __attribute__((section("sec"))); + int g2 __attribute__((section("sec"))); + static volatile int l1 __attribute__((section("sec"))); + static volatile int l2 __attribute__((section("sec"))); + int test() { + return g1 + g2 + l1 + l2; + } + +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 + 0000000000000000: R_BPF_64_64 g1 + 2: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 3: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll + 0000000000000018: R_BPF_64_64 g2 + 5: 61 20 00 00 00 00 00 00 r0 = *(u32 *)(r2 + 0) + 6: 0f 10 00 00 00 00 00 00 r0 += r1 + 7: 18 01 00 00 08 00 00 00 00 00 00 00 00 00 00 00 r1 = 8 ll + 0000000000000038: R_BPF_64_64 sec + 9: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 10: 0f 10 00 00 00 00 00 00 r0 += r1 + 11: 18 01 00 00 0c 00 00 00 00 00 00 00 00 00 00 00 r1 = 12 ll + 0000000000000058: R_BPF_64_64 sec + 13: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 14: 0f 10 00 00 00 00 00 00 r0 += r1 + 15: 95 00 00 00 00 00 00 00 exit + +There are four relations in the above for four ``LD_imm64`` instructions. +The following ``llvm-readelf -r test.o`` shows the binary values of the four +relocations:: + + Relocation section '.rel.text' at offset 0x190 contains 4 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000000 0000000600000001 R_BPF_64_64 0000000000000000 g1 + 0000000000000018 0000000700000001 R_BPF_64_64 0000000000000004 g2 + 0000000000000038 0000000400000001 R_BPF_64_64 0000000000000000 sec + 0000000000000058 0000000400000001 R_BPF_64_64 0000000000000000 sec + +Each relocation is represented by ``Offset`` (8 bytes) and ``Info`` (8 bytes). +For example, the first relocation corresponds to the first instruction +(Offset 0x0) and the corresponding ``Info`` indicates the relocation type +of ``R_BPF_64_64`` (type 1) and the entry in the symbol table (entry 6). +The following is the symbol table with ``llvm-readelf -s test.o``:: + + Symbol table '.symtab' contains 8 entries: + Num: Value Size Type Bind Vis Ndx Name + 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND + 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS test.c + 2: 0000000000000008 4 OBJECT LOCAL DEFAULT 4 l1 + 3: 000000000000000c 4 OBJECT LOCAL DEFAULT 4 l2 + 4: 0000000000000000 0 SECTION LOCAL DEFAULT 4 sec + 5: 0000000000000000 128 FUNC GLOBAL DEFAULT 2 test + 6: 0000000000000000 4 OBJECT GLOBAL DEFAULT 4 g1 + 7: 0000000000000004 4 OBJECT GLOBAL DEFAULT 4 g2 + +The 6th entry is global variable ``g1`` with value 0. + +Similarly, the second relocation is at ``.text`` offset ``0x18``, instruction 3, +for global variable ``g2`` which has a symbol value 4, the offset +from the start of ``.data`` section. + +The third and fourth relocations refers to static variables ``l1`` +and ``l2``. From ``.rel.text`` section above, it is not clear +which symbols they really refers to as they both refers to +symbol table entry 4, symbol ``sec``, which has ``STT_SECTION`` type +and represents a section. So for static variable or function, +the section offset is written to the original insn +buffer, which is called ``A`` (addend). Looking at +above insn ``7`` and ``11``, they have section offset ``8`` and ``12``. +From symbol table, we can find that they correspond to entries ``2`` +and ``3`` for ``l1`` and ``l2``. + +In general, the ``A`` is 0 for global variables and functions, +and is the section offset or some computation result based on +section offset for static variables/functions. The non-section-offset +case refers to function calls. See below for more details. + +Different Relocation Types +========================== + +Six relocation types are supported. The following is an overview and +``S`` represents the value of the symbol in the symbol table:: + + Enum ELF Reloc Type Description BitSize Offset Calculation + 0 R_BPF_NONE None + 1 R_BPF_64_64 ld_imm64 insn 32 r_offset + 4 S + A + 2 R_BPF_64_ABS64 normal data 64 r_offset S + A + 3 R_BPF_64_ABS32 normal data 32 r_offset S + A + 4 R_BPF_64_NODYLD32 .BTF[.ext] data 32 r_offset S + A + 10 R_BPF_64_32 call insn 32 r_offset + 4 (S + A) / 8 - 1 + +For example, ``R_BPF_64_64`` relocation type is used for ``ld_imm64`` instruction. +The actual to-be-relocated data (0 or section offset) +is stored at ``r_offset + 4`` and the read/write +data bitsize is 32 (4 bytes). The relocation can be resolved with +the symbol value plus implicit addend. Note that the ``BitSize`` is 32 which +means the section offset must be less than or equal to ``UINT32_MAX`` and this +is enforced by LLVM BPF backend. + +In another case, ``R_BPF_64_ABS64`` relocation type is used for normal 64-bit data. +The actual to-be-relocated data is stored at ``r_offset`` and the read/write data +bitsize is 64 (8 bytes). The relocation can be resolved with +the symbol value plus implicit addend. + +Both ``R_BPF_64_ABS32`` and ``R_BPF_64_NODYLD32`` types are for 32-bit data. +But ``R_BPF_64_NODYLD32`` specifically refers to relocations in ``.BTF`` and +``.BTF.ext`` sections. For cases like bcc where llvm ``ExecutionEngine RuntimeDyld`` +is involved, ``R_BPF_64_NODYLD32`` types of relocations should not be resolved +to actual function/variable address. Otherwise, ``.BTF`` and ``.BTF.ext`` +become unusable by bcc and kernel. + +Type ``R_BPF_64_32`` is used for call instruction. The call target section +offset is stored at ``r_offset + 4`` (32bit) and calculated as +``(S + A) / 8 - 1``. + +Examples +======== + +Types ``R_BPF_64_64`` and ``R_BPF_64_32`` are used to resolve ``ld_imm64`` +and ``call`` instructions. For example:: + + __attribute__((noinline)) __attribute__((section("sec1"))) + int gfunc(int a, int b) { + return a * b; + } + static __attribute__((noinline)) __attribute__((section("sec1"))) + int lfunc(int a, int b) { + return a + b; + } + int global __attribute__((section("sec2"))); + int test(int a, int b) { + return gfunc(a, b) + lfunc(a, b) + global; + } + +Compiled with ``clang -target bpf -O2 -c test.c``, we will have +following code with `llvm-objdump -dr test.o``:: + + Disassembly of section .text: + + 0000000000000000 <test>: + 0: bf 26 00 00 00 00 00 00 r6 = r2 + 1: bf 17 00 00 00 00 00 00 r7 = r1 + 2: 85 10 00 00 ff ff ff ff call -1 + 0000000000000010: R_BPF_64_32 gfunc + 3: bf 08 00 00 00 00 00 00 r8 = r0 + 4: bf 71 00 00 00 00 00 00 r1 = r7 + 5: bf 62 00 00 00 00 00 00 r2 = r6 + 6: 85 10 00 00 02 00 00 00 call 2 + 0000000000000030: R_BPF_64_32 sec1 + 7: 0f 80 00 00 00 00 00 00 r0 += r8 + 8: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll + 0000000000000040: R_BPF_64_64 global + 10: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 11: 0f 10 00 00 00 00 00 00 r0 += r1 + 12: 95 00 00 00 00 00 00 00 exit + + Disassembly of section sec1: + + 0000000000000000 <gfunc>: + 0: bf 20 00 00 00 00 00 00 r0 = r2 + 1: 2f 10 00 00 00 00 00 00 r0 *= r1 + 2: 95 00 00 00 00 00 00 00 exit + + 0000000000000018 <lfunc>: + 3: bf 20 00 00 00 00 00 00 r0 = r2 + 4: 0f 10 00 00 00 00 00 00 r0 += r1 + 5: 95 00 00 00 00 00 00 00 exit + +The first relocation corresponds to ``gfunc(a, b)`` where ``gfunc`` has a value of 0, +so the ``call`` instruction offset is ``(0 + 0)/8 - 1 = -1``. +The second relocation corresponds to ``lfunc(a, b)`` where ``lfunc`` has a section +offset ``0x18``, so the ``call`` instruction offset is ``(0 + 0x18)/8 - 1 = 2``. +The third relocation corresponds to ld_imm64 of ``global``, which has a section +offset ``0``. + +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 +relocation below in ``.data`` section with command +``llvm-readelf -r test.o``:: + + Relocation section '.rel.data' at offset 0x458 contains 1 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000000 0000000700000002 R_BPF_64_ABS64 0000000000000000 global + +The relocation says the first 8-byte of ``.data`` section should be +filled with address of ``global`` variable. + +With ``llvm-readelf`` output, we can see that dwarf sections have a bunch of +``R_BPF_64_ABS32`` and ``R_BPF_64_ABS64`` relocations:: + + Relocation section '.rel.debug_info' at offset 0x468 contains 13 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000006 0000000300000003 R_BPF_64_ABS32 0000000000000000 .debug_abbrev + 000000000000000c 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 0000000000000012 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 0000000000000016 0000000600000003 R_BPF_64_ABS32 0000000000000000 .debug_line + 000000000000001a 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 000000000000001e 0000000200000002 R_BPF_64_ABS64 0000000000000000 .text + 000000000000002b 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 0000000000000037 0000000800000002 R_BPF_64_ABS64 0000000000000000 gbl + 0000000000000040 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + ...... + +The .BTF/.BTF.ext sections has R_BPF_64_NODYLD32 relocations:: + + Relocation section '.rel.BTF' at offset 0x538 contains 1 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000084 0000000800000004 R_BPF_64_NODYLD32 0000000000000000 gbl + + Relocation section '.rel.BTF.ext' at offset 0x548 contains 2 entries: + 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 diff --git a/Documentation/cdrom/cdrom-standard.rst b/Documentation/cdrom/cdrom-standard.rst index 70500b189cc8..5845960ca382 100644 --- a/Documentation/cdrom/cdrom-standard.rst +++ b/Documentation/cdrom/cdrom-standard.rst @@ -146,18 +146,18 @@ with the kernel as a block device by registering the following general *struct file_operations*:: struct file_operations cdrom_fops = { - NULL, /∗ lseek ∗/ - block _read , /∗ read—general block-dev read ∗/ - block _write, /∗ write—general block-dev write ∗/ - NULL, /∗ readdir ∗/ - NULL, /∗ select ∗/ - cdrom_ioctl, /∗ ioctl ∗/ - NULL, /∗ mmap ∗/ - cdrom_open, /∗ open ∗/ - cdrom_release, /∗ release ∗/ - NULL, /∗ fsync ∗/ - NULL, /∗ fasync ∗/ - NULL /∗ revalidate ∗/ + NULL, /* lseek */ + block _read , /* read--general block-dev read */ + block _write, /* write--general block-dev write */ + NULL, /* readdir */ + NULL, /* select */ + cdrom_ioctl, /* ioctl */ + NULL, /* mmap */ + cdrom_open, /* open */ + cdrom_release, /* release */ + NULL, /* fsync */ + NULL, /* fasync */ + NULL /* revalidate */ }; Every active CD-ROM device shares this *struct*. The routines @@ -250,12 +250,12 @@ The drive-specific, minor-like information that is registered with `cdrom.c`, currently contains the following fields:: struct cdrom_device_info { - const struct cdrom_device_ops * ops; /* device operations for this major */ + const struct cdrom_device_ops * ops; /* device operations for this major */ struct list_head list; /* linked list of all device_info */ struct gendisk * disk; /* matching block layer disk */ void * handle; /* driver-dependent data */ - int mask; /* mask of capability: disables them */ + int mask; /* mask of capability: disables them */ int speed; /* maximum speed for reading data */ int capacity; /* number of discs in a jukebox */ @@ -569,7 +569,7 @@ the *CDC_CLOSE_TRAY* bit in *mask*. In the file `cdrom.c` you will encounter many constructions of the type:: - if (cdo->capability & ∼cdi->mask & CDC _⟨capability⟩) ... + if (cdo->capability & ~cdi->mask & CDC _<capability>) ... There is no *ioctl* to set the mask... The reason is that I think it is better to control the **behavior** rather than the diff --git a/Documentation/conf.py b/Documentation/conf.py index 879e86dbea66..7d92ec3e5b6e 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -41,15 +41,7 @@ extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'maintainers_include', 'sphinx.ext.autosectionlabel', 'kernel_abi', 'kernel_feat'] -# -# cdomain is badly broken in Sphinx 3+. Leaving it out generates *most* -# of the docs correctly, but not all. Scream bloody murder but allow -# the process to proceed; hopefully somebody will fix this properly soon. -# if major >= 3: - sys.stderr.write('''WARNING: The kernel documentation build process - support for Sphinx v3.0 and above is brand new. Be prepared for - possible issues in the generated output.\n''') if (major > 3) or (minor > 0 or patch >= 2): # Sphinx c function parser is more pedantic with regards to type # checking. Due to that, having macros at c:function cause problems. @@ -353,6 +345,8 @@ latex_elements = { # Additional stuff for the LaTeX preamble. 'preamble': ''' + % Prevent column squeezing of tabulary. + \\setlength{\\tymin}{20em} % Use some font with UTF-8 support with XeLaTeX \\usepackage{fontspec} \\setsansfont{DejaVu Sans} @@ -366,11 +360,23 @@ latex_elements = { cjk_cmd = check_output(['fc-list', '--format="%{family[0]}\n"']).decode('utf-8', 'ignore') if cjk_cmd.find("Noto Sans CJK SC") >= 0: - print ("enabling CJK for LaTeX builder") latex_elements['preamble'] += ''' % This is needed for translations \\usepackage{xeCJK} \\setCJKmainfont{Noto Sans CJK SC} + % Define custom macros to on/off CJK + \\newcommand{\\kerneldocCJKon}{\\makexeCJKactive} + \\newcommand{\\kerneldocCJKoff}{\\makexeCJKinactive} + % To customize \sphinxtableofcontents + \\usepackage{etoolbox} + % Inactivate CJK after tableofcontents + \\apptocmd{\\sphinxtableofcontents}{\\kerneldocCJKoff}{}{} + ''' +else: + latex_elements['preamble'] += ''' + % Custom macros to on/off CJK (Dummy) + \\newcommand{\\kerneldocCJKon}{} + \\newcommand{\\kerneldocCJKoff}{} ''' # Fix reference escape troubles with Sphinx 1.4.x diff --git a/Documentation/core-api/bus-virt-phys-mapping.rst b/Documentation/core-api/bus-virt-phys-mapping.rst index c7bc99cd2e21..c72b24a7d52c 100644 --- a/Documentation/core-api/bus-virt-phys-mapping.rst +++ b/Documentation/core-api/bus-virt-phys-mapping.rst @@ -8,7 +8,7 @@ How to access I/O mapped memory from within device drivers The virt_to_bus() and bus_to_virt() functions have been superseded by the functionality provided by the PCI DMA interface - (see :doc:`/core-api/dma-api-howto`). They continue + (see Documentation/core-api/dma-api-howto.rst). They continue to be documented below for historical purposes, but new code must not use them. --davidm 00/12/12 diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst index 00a1d4fa3f9e..6d6d0edd2d27 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -5,7 +5,7 @@ Dynamic DMA mapping using the generic device :Author: James E.J. Bottomley <James.Bottomley@HansenPartnership.com> This document describes the DMA API. For a more gentle introduction -of the API (and actual examples), see :doc:`/core-api/dma-api-howto`. +of the API (and actual examples), see Documentation/core-api/dma-api-howto.rst. This API is split into two pieces. Part I describes the basic API. Part II describes extensions for supporting non-consistent memory @@ -479,7 +479,8 @@ without the _attrs suffixes, except that they pass an optional dma_attrs. The interpretation of DMA attributes is architecture-specific, and -each attribute should be documented in :doc:`/core-api/dma-attributes`. +each attribute should be documented in +Documentation/core-api/dma-attributes.rst. If dma_attrs are 0, the semantics of each of these functions is identical to those of the corresponding function diff --git a/Documentation/core-api/dma-isa-lpc.rst b/Documentation/core-api/dma-isa-lpc.rst index e59a3d35a93d..17b193603f0a 100644 --- a/Documentation/core-api/dma-isa-lpc.rst +++ b/Documentation/core-api/dma-isa-lpc.rst @@ -17,7 +17,7 @@ To do ISA style DMA you need to include two headers:: #include <asm/dma.h> The first is the generic DMA API used to convert virtual addresses to -bus addresses (see :doc:`/core-api/dma-api` for details). +bus addresses (see Documentation/core-api/dma-api.rst for details). The second contains the routines specific to ISA DMA transfers. Since this is not present on all platforms make sure you construct your diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index f1c9d20bd42d..5de2c7a4b1b3 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -48,7 +48,7 @@ Concurrency primitives ====================== How Linux keeps everything from happening at the same time. See -:doc:`/locking/index` for more related documentation. +Documentation/locking/index.rst for more related documentation. .. toctree:: :maxdepth: 1 @@ -77,7 +77,7 @@ Memory management ================= How to allocate and use memory in the kernel. Note that there is a lot -more memory-management documentation in :doc:`/vm/index`. +more memory-management documentation in Documentation/vm/index.rst. .. toctree:: :maxdepth: 1 diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst index 8214e215a8bf..53283b3729a1 100644 --- a/Documentation/core-api/irq/irq-domain.rst +++ b/Documentation/core-api/irq/irq-domain.rst @@ -146,7 +146,6 @@ Legacy irq_domain_add_simple() irq_domain_add_legacy() - irq_domain_add_legacy_isa() irq_domain_create_simple() irq_domain_create_legacy() diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 741aa37dc181..2a7444e3a4c2 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -24,11 +24,8 @@ String Conversions .. kernel-doc:: lib/vsprintf.c :export: -.. kernel-doc:: include/linux/kernel.h - :functions: kstrtol - -.. kernel-doc:: include/linux/kernel.h - :functions: kstrtoul +.. kernel-doc:: include/linux/kstrtox.h + :functions: kstrtol kstrtoul .. kernel-doc:: lib/kstrtox.c :export: diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index f063a384c7c8..4346ae17a72c 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -37,14 +37,13 @@ Integer types u64 %llu or %llx -If <type> is dependent on a config option for its size (e.g., sector_t, -blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a -format specifier of its largest possible type and explicitly cast to it. +If <type> is architecture-dependent for its size (e.g., cycles_t, tcflag_t) or +is dependent on a config option for its size (e.g., blk_status_t), use a format +specifier of its largest possible type and explicitly cast to it. Example:: - printk("test: sector number/total blocks: %llu/%llu\n", - (unsigned long long)sector, (unsigned long long)blockcount); + printk("test: latency: %llu cycles\n", (unsigned long long)time); Reminder: sizeof() returns type size_t. @@ -514,9 +513,10 @@ Time and date :: %pt[RT] YYYY-mm-ddTHH:MM:SS + %pt[RT]s YYYY-mm-dd HH:MM:SS %pt[RT]d YYYY-mm-dd %pt[RT]t HH:MM:SS - %pt[RT][dt][r] + %pt[RT][dt][r][s] For printing date and time as represented by:: @@ -528,6 +528,10 @@ in human readable format. By default year will be incremented by 1900 and month by 1. Use %pt[RT]r (raw) to suppress this behaviour. +The %pt[RT]s (space) will override ISO 8601 separator by using ' ' (space) +instead of 'T' (Capital T) between date and time. It won't have any effect +when date or time is omitted. + Passed by reference. struct clk diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst index 51fed1bd72ec..f0956e9ea2d8 100644 --- a/Documentation/dev-tools/checkpatch.rst +++ b/Documentation/dev-tools/checkpatch.rst @@ -246,6 +246,7 @@ Allocation style The first argument for kcalloc or kmalloc_array should be the number of elements. sizeof() as the first argument is generally wrong. + See: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html **ALLOC_SIZEOF_STRUCT** @@ -264,6 +265,7 @@ Allocation style **ALLOC_WITH_MULTIPLY** Prefer kmalloc_array/kcalloc over kmalloc/kzalloc with a sizeof multiply. + See: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html @@ -284,6 +286,7 @@ API usage BUG() or BUG_ON() should be avoided totally. Use WARN() and WARN_ON() instead, and handle the "impossible" error condition as gracefully as possible. + See: https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on **CONSIDER_KSTRTO** @@ -292,12 +295,161 @@ API usage may lead to unexpected results in callers. The respective kstrtol(), kstrtoll(), kstrtoul(), and kstrtoull() functions tend to be the correct replacements. + See: https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull + **CONSTANT_CONVERSION** + Use of __constant_<foo> form is discouraged for the following functions:: + + __constant_cpu_to_be[x] + __constant_cpu_to_le[x] + __constant_be[x]_to_cpu + __constant_le[x]_to_cpu + __constant_htons + __constant_ntohs + + Using any of these outside of include/uapi/ is not preferred as using the + function without __constant_ is identical when the argument is a + constant. + + In big endian systems, the macros like __constant_cpu_to_be32(x) and + cpu_to_be32(x) expand to the same expression:: + + #define __constant_cpu_to_be32(x) ((__force __be32)(__u32)(x)) + #define __cpu_to_be32(x) ((__force __be32)(__u32)(x)) + + In little endian systems, the macros __constant_cpu_to_be32(x) and + cpu_to_be32(x) expand to __constant_swab32 and __swab32. __swab32 + has a __builtin_constant_p check:: + + #define __swab32(x) \ + (__builtin_constant_p((__u32)(x)) ? \ + ___constant_swab32(x) : \ + __fswab32(x)) + + So ultimately they have a special case for constants. + Similar is the case with all of the macros in the list. Thus + using the __constant_... forms are unnecessarily verbose and + not preferred outside of include/uapi. + + See: https://lore.kernel.org/lkml/1400106425.12666.6.camel@joe-AO725/ + + **DEPRECATED_API** + Usage of a deprecated RCU API is detected. It is recommended to replace + old flavourful RCU APIs by their new vanilla-RCU counterparts. + + The full list of available RCU APIs can be viewed from the kernel docs. + + See: https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html#full-list-of-rcu-apis + + **DEPRECATED_VARIABLE** + EXTRA_{A,C,CPP,LD}FLAGS are deprecated and should be replaced by the new + flags added via commit f77bf01425b1 ("kbuild: introduce ccflags-y, + asflags-y and ldflags-y"). + + The following conversion scheme maybe used:: + + EXTRA_AFLAGS -> asflags-y + EXTRA_CFLAGS -> ccflags-y + EXTRA_CPPFLAGS -> cppflags-y + EXTRA_LDFLAGS -> ldflags-y + + See: + + 1. https://lore.kernel.org/lkml/20070930191054.GA15876@uranus.ravnborg.org/ + 2. https://lore.kernel.org/lkml/1313384834-24433-12-git-send-email-lacombar@gmail.com/ + 3. https://www.kernel.org/doc/html/latest/kbuild/makefiles.html#compilation-flags + + **DEVICE_ATTR_FUNCTIONS** + The function names used in DEVICE_ATTR is unusual. + Typically, the store and show functions are used with <attr>_store and + <attr>_show, where <attr> is a named attribute variable of the device. + + Consider the following examples:: + + static DEVICE_ATTR(type, 0444, type_show, NULL); + static DEVICE_ATTR(power, 0644, power_show, power_store); + + The function names should preferably follow the above pattern. + + See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes + + **DEVICE_ATTR_RO** + The DEVICE_ATTR_RO(name) helper macro can be used instead of + DEVICE_ATTR(name, 0444, name_show, NULL); + + Note that the macro automatically appends _show to the named + attribute variable of the device for the show method. + + See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes + + **DEVICE_ATTR_RW** + The DEVICE_ATTR_RW(name) helper macro can be used instead of + DEVICE_ATTR(name, 0644, name_show, name_store); + + Note that the macro automatically appends _show and _store to the + named attribute variable of the device for the show and store methods. + + See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes + + **DEVICE_ATTR_WO** + The DEVICE_AATR_WO(name) helper macro can be used instead of + DEVICE_ATTR(name, 0200, NULL, name_store); + + Note that the macro automatically appends _store to the + named attribute variable of the device for the store method. + + See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes + + **DUPLICATED_SYSCTL_CONST** + Commit d91bff3011cf ("proc/sysctl: add shared variables for range + check") added some shared const variables to be used instead of a local + copy in each source file. + + Consider replacing the sysctl range checking value with the shared + one in include/linux/sysctl.h. The following conversion scheme may + be used:: + + &zero -> SYSCTL_ZERO + &one -> SYSCTL_ONE + &int_max -> SYSCTL_INT_MAX + + See: + + 1. https://lore.kernel.org/lkml/20190430180111.10688-1-mcroce@redhat.com/ + 2. https://lore.kernel.org/lkml/20190531131422.14970-1-mcroce@redhat.com/ + + **ENOSYS** + ENOSYS means that a nonexistent system call was called. + Earlier, it was wrongly used for things like invalid operations on + otherwise valid syscalls. This should be avoided in new code. + + See: https://lore.kernel.org/lkml/5eb299021dec23c1a48fa7d9f2c8b794e967766d.1408730669.git.luto@amacapital.net/ + + **ENOTSUPP** + ENOTSUPP is not a standard error code and should be avoided in new patches. + EOPNOTSUPP should be used instead. + + See: https://lore.kernel.org/netdev/20200510182252.GA411829@lunn.ch/ + + **EXPORT_SYMBOL** + EXPORT_SYMBOL should immediately follow the symbol to be exported. + + **IN_ATOMIC** + in_atomic() is not for driver use so any such use is reported as an ERROR. + Also in_atomic() is often used to determine if sleeping is permitted, + but it is not reliable in this use model. Therefore its use is + strongly discouraged. + + However, in_atomic() is ok for core kernel use. + + See: https://lore.kernel.org/lkml/20080320201723.b87b3732.akpm@linux-foundation.org/ + **LOCKDEP** The lockdep_no_validate class was added as a temporary measure to prevent warnings on conversion of device->sem to device->mutex. It should not be used for any other purpose. + See: https://lore.kernel.org/lkml/1268959062.9440.467.camel@laptop/ **MALFORMED_INCLUDE** @@ -308,14 +460,21 @@ API usage **USE_LOCKDEP** lockdep_assert_held() annotations should be preferred over assertions based on spin_is_locked() + See: https://www.kernel.org/doc/html/latest/locking/lockdep-design.html#annotations **UAPI_INCLUDE** No #include statements in include/uapi should use a uapi/ path. + **USLEEP_RANGE** + usleep_range() should be preferred over udelay(). The proper way of + using usleep_range() is mentioned in the kernel docs. -Comment style -------------- + See: https://www.kernel.org/doc/html/latest/timers/timers-howto.html#delays-information-on-the-various-kernel-delay-sleep-mechanisms + + +Comments +-------- **BLOCK_COMMENT_STYLE** The comment style is incorrect. The preferred style for multi- @@ -338,8 +497,24 @@ Comment style **C99_COMMENTS** C99 style single line comments (//) should not be used. Prefer the block comment style instead. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#commenting + **DATA_RACE** + Applications of data_race() should have a comment so as to document the + reasoning behind why it was deemed safe. + + See: https://lore.kernel.org/lkml/20200401101714.44781-1-elver@google.com/ + + **FSF_MAILING_ADDRESS** + Kernel maintainers reject new instances of the GPL boilerplate paragraph + directing people to write to the FSF for a copy of the GPL, since the + FSF has moved in the past and may do so again. + So do not write paragraphs about writing to the Free Software Foundation's + mailing address. + + See: https://lore.kernel.org/lkml/20131006222342.GT19510@leaf/ + Commit message -------------- @@ -347,6 +522,7 @@ Commit message **BAD_SIGN_OFF** The signed-off-by line does not fall in line with the standards specified by the community. + See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 **BAD_STABLE_ADDRESS_STYLE** @@ -368,12 +544,33 @@ Commit message **COMMIT_MESSAGE** The patch is missing a commit description. A brief description of the changes made by the patch should be added. + + See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes + + **EMAIL_SUBJECT** + Naming the tool that found the issue is not very useful in the + subject line. A good subject line summarizes the change that + the patch brings. + See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes + **FROM_SIGN_OFF_MISMATCH** + The author's email does not match with that in the Signed-off-by: + line(s). This can be sometimes caused due to an improperly configured + email client. + + This message is emitted due to any of the following reasons:: + + - The email names do not match. + - The email addresses do not match. + - The email subaddresses do not match. + - The email comments do not match. + **MISSING_SIGN_OFF** The patch is missing a Signed-off-by line. A signed-off-by line should be added according to Developer's certificate of Origin. + See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin **NO_AUTHOR_SIGN_OFF** @@ -382,6 +579,7 @@ Commit message end of explanation of the patch to denote that the author has written it or otherwise has the rights to pass it on as an open source patch. + See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin **DIFF_IN_COMMIT_MSG** @@ -389,6 +587,7 @@ Commit message This causes problems when one tries to apply a file containing both the changelog and the diff because patch(1) tries to apply the diff which it found in the changelog. + See: https://lore.kernel.org/lkml/20150611134006.9df79a893e3636019ad2759e@linux-foundation.org/ **GERRIT_CHANGE_ID** @@ -431,6 +630,7 @@ Comparison style **BOOL_COMPARISON** Comparisons of A to true and false are better written as A and !A. + See: https://lore.kernel.org/lkml/1365563834.27174.12.camel@joe-AO722/ **COMPARISON_TO_NULL** @@ -442,6 +642,87 @@ Comparison style side of the test should be avoided. +Indentation and Line Breaks +--------------------------- + + **CODE_INDENT** + Code indent should use tabs instead of spaces. + Outside of comments, documentation and Kconfig, + spaces are never used for indentation. + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation + + **DEEP_INDENTATION** + Indentation with 6 or more tabs usually indicate overly indented + code. + + It is suggested to refactor excessive indentation of + if/else/for/do/while/switch statements. + + See: https://lore.kernel.org/lkml/1328311239.21255.24.camel@joe2Laptop/ + + **SWITCH_CASE_INDENT_LEVEL** + switch should be at the same indent as case. + Example:: + + switch (suffix) { + case 'G': + case 'g': + mem <<= 30; + break; + case 'M': + case 'm': + mem <<= 20; + break; + case 'K': + case 'k': + mem <<= 10; + fallthrough; + default: + break; + } + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation + + **LONG_LINE** + The line has exceeded the specified maximum length. + To use a different maximum line length, the --max-line-length=n option + may be added while invoking checkpatch. + + Earlier, the default line length was 80 columns. Commit bdc48fa11e46 + ("checkpatch/coding-style: deprecate 80-column warning") increased the + limit to 100 columns. This is not a hard limit either and it's + preferable to stay within 80 columns whenever possible. + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + + **LONG_LINE_STRING** + A string starts before but extends beyond the maximum line length. + To use a different maximum line length, the --max-line-length=n option + may be added while invoking checkpatch. + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + + **LONG_LINE_COMMENT** + A comment starts before but extends beyond the maximum line length. + To use a different maximum line length, the --max-line-length=n option + may be added while invoking checkpatch. + + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + + **TRAILING_STATEMENTS** + Trailing statements (for example after any conditional) should be + on the next line. + Statements, such as:: + + if (x == y) break; + + should be:: + + if (x == y) + break; + + Macros, Attributes and Symbols ------------------------------ @@ -472,7 +753,7 @@ Macros, Attributes and Symbols **BIT_MACRO** Defines like: 1 << <digit> could be BIT(digit). - The BIT() macro is defined in include/linux/bitops.h:: + The BIT() macro is defined via include/linux/bits.h:: #define BIT(nr) (1UL << (nr)) @@ -492,6 +773,7 @@ Macros, Attributes and Symbols The kernel does *not* use the ``__DATE__`` and ``__TIME__`` macros, and enables warnings if they are used as they can lead to non-deterministic builds. + See: https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html#timestamps **DEFINE_ARCH_HAS** @@ -502,8 +784,12 @@ Macros, Attributes and Symbols want architectures able to override them with optimized ones, we should either use weak functions (appropriate for some cases), or the symbol that protects them should be the same symbol we use. + See: https://lore.kernel.org/lkml/CA+55aFycQ9XJvEOsiM3txHL5bjUc8CeKWJNR_H+MiicaddB42Q@mail.gmail.com/ + **DO_WHILE_MACRO_WITH_TRAILING_SEMICOLON** + do {} while(0) macros should not have a trailing semicolon. + **INIT_ATTRIBUTE** Const init definitions should use __initconst instead of __initdata. @@ -528,6 +814,20 @@ Macros, Attributes and Symbols ... } + **MISPLACED_INIT** + It is possible to use section markers on variables in a way + which gcc doesn't understand (or at least not the way the + developer intended):: + + static struct __initdata samsung_pll_clock exynos4_plls[nr_plls] = { + + does not put exynos4_plls in the .initdata section. The __initdata + marker can be virtually anywhere on the line, except right after + "struct". The preferred location is before the "=" sign if there is + one, or before the trailing ";" otherwise. + + See: https://lore.kernel.org/lkml/1377655732.3619.19.camel@joe-AO722/ + **MULTISTATEMENT_MACRO_USE_DO_WHILE** Macros with multiple statements should be enclosed in a do - while block. Same should also be the case for macros @@ -541,6 +841,10 @@ Macros, Attributes and Symbols See: https://www.kernel.org/doc/html/latest/process/coding-style.html#macros-enums-and-rtl + **PREFER_FALLTHROUGH** + Use the `fallthrough;` pseudo keyword instead of + `/* fallthrough */` like comments. + **WEAK_DECLARATION** Using weak declarations like __attribute__((weak)) or __weak can have unintended link defects. Avoid using them. @@ -551,8 +855,51 @@ Functions and Variables **CAMELCASE** Avoid CamelCase Identifiers. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#naming + **CONST_CONST** + Using `const <type> const *` is generally meant to be + written `const <type> * const`. + + **CONST_STRUCT** + Using const is generally a good idea. Checkpatch reads + a list of frequently used structs that are always or + almost always constant. + + The existing structs list can be viewed from + `scripts/const_structs.checkpatch`. + + See: https://lore.kernel.org/lkml/alpine.DEB.2.10.1608281509480.3321@hadrien/ + + **EMBEDDED_FUNCTION_NAME** + Embedded function names are less appropriate to use as + refactoring can cause function renaming. Prefer the use of + "%s", __func__ to embedded function names. + + Note that this does not work with -f (--file) checkpatch option + as it depends on patch context providing the function name. + + **FUNCTION_ARGUMENTS** + This warning is emitted due to any of the following reasons: + + 1. Arguments for the function declaration do not follow + the identifier name. Example:: + + void foo + (int bar, int baz) + + This should be corrected to:: + + void foo(int bar, int baz) + + 2. Some arguments for the function definition do not + have an identifier name. Example:: + + void foo(int) + + All arguments should have identifier names. + **FUNCTION_WITHOUT_ARGS** Function declarations without arguments like:: @@ -583,6 +930,34 @@ Functions and Variables return bar; +Permissions +----------- + + **DEVICE_ATTR_PERMS** + The permissions used in DEVICE_ATTR are unusual. + Typically only three permissions are used - 0644 (RW), 0444 (RO) + and 0200 (WO). + + See: https://www.kernel.org/doc/html/latest/filesystems/sysfs.html#attributes + + **EXECUTE_PERMISSIONS** + There is no reason for source files to be executable. The executable + bit can be removed safely. + + **EXPORTED_WORLD_WRITABLE** + Exporting world writable sysfs/debugfs files is usually a bad thing. + When done arbitrarily they can introduce serious security bugs. + In the past, some of the debugfs vulnerabilities would seemingly allow + any local user to write arbitrary values into device registers - a + situation from which little good can be expected to emerge. + + See: https://lore.kernel.org/linux-arm-kernel/cover.1296818921.git.segoon@openwall.com/ + + **NON_OCTAL_PERMISSIONS** + Permission bits should use 4 digit octal permissions (like 0700 or 0444). + Avoid using any other base like decimal. + + Spacing and Brackets -------------------- @@ -616,7 +991,7 @@ Spacing and Brackets 1. With a type on the left:: - ;int [] a; + int [] a; 2. At the beginning of a line for slice initialisers:: @@ -626,12 +1001,6 @@ Spacing and Brackets = { [0...10] = 5 } - **CODE_INDENT** - Code indent should use tabs instead of spaces. - Outside of comments, documentation and Kconfig, - spaces are never used for indentation. - See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation - **CONCATENATED_STRING** Concatenated elements should have a space in between. Example:: @@ -644,17 +1013,20 @@ Spacing and Brackets **ELSE_AFTER_BRACE** `else {` should follow the closing block `}` on the same line. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces **LINE_SPACING** Vertical space is wasted given the limited number of lines an editor window can display when multiple blank lines are used. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces **OPEN_BRACE** The opening brace should be following the function definitions on the next line. For any non-functional block it should be on the same line as the last construct. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces **POINTER_LOCATION** @@ -671,37 +1043,47 @@ Spacing and Brackets **SPACING** Whitespace style used in the kernel sources is described in kernel docs. - See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces - **SWITCH_CASE_INDENT_LEVEL** - switch should be at the same indent as case. - Example:: - - switch (suffix) { - case 'G': - case 'g': - mem <<= 30; - break; - case 'M': - case 'm': - mem <<= 20; - break; - case 'K': - case 'k': - mem <<= 10; - /* fall through */ - default: - break; - } - - See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces **TRAILING_WHITESPACE** Trailing whitespace should always be removed. Some editors highlight the trailing whitespace and cause visual distractions when editing files. + See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces + **UNNECESSARY_PARENTHESES** + Parentheses are not required in the following cases: + + 1. Function pointer uses:: + + (foo->bar)(); + + could be:: + + foo->bar(); + + 2. Comparisons in if:: + + if ((foo->bar) && (foo->baz)) + if ((foo == bar)) + + could be:: + + if (foo->bar && foo->baz) + if (foo == bar) + + 3. addressof/dereference single Lvalues:: + + &(foo->bar) + *(foo->bar) + + could be:: + + &foo->bar + *foo->bar + **WHILE_AFTER_BRACE** while should follow the closing bracket on the same line:: @@ -723,17 +1105,50 @@ Others The patch seems to be corrupted or lines are wrapped. Please regenerate the patch file before sending it to the maintainer. + **CVS_KEYWORD** + Since linux moved to git, the CVS markers are no longer used. + So, CVS style keywords ($Id$, $Revision$, $Log$) should not be + added. + + **DEFAULT_NO_BREAK** + switch default case is sometimes written as "default:;". This can + cause new cases added below default to be defective. + + A "break;" should be added after empty default statement to avoid + unwanted fallthrough. + **DOS_LINE_ENDINGS** For DOS-formatted patches, there are extra ^M symbols at the end of the line. These should be removed. - **EXECUTE_PERMISSIONS** - There is no reason for source files to be executable. The executable - bit can be removed safely. + **DT_SCHEMA_BINDING_PATCH** + DT bindings moved to a json-schema based format instead of + freeform text. - **NON_OCTAL_PERMISSIONS** - Permission bits should use 4 digit octal permissions (like 0700 or 0444). - Avoid using any other base like decimal. + See: https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-schema.html + + **DT_SPLIT_BINDING_PATCH** + Devicetree bindings should be their own patch. This is because + bindings are logically independent from a driver implementation, + they have a different maintainer (even though they often + are applied via the same tree), and it makes for a cleaner history in the + DT only tree created with git-filter-branch. + + See: https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters + + **EMBEDDED_FILENAME** + Embedding the complete filename path inside the file isn't particularly + useful as often the path is moved around and becomes incorrect. + + **FILE_PATH_CHANGES** + Whenever files are added, moved, or deleted, the MAINTAINERS file + patterns can be out of sync or outdated. + + So MAINTAINERS might need updating in these cases. + + **MEMSET** + The memset use appears to be incorrect. This may be caused due to + badly ordered parameters. Please recheck the usage. **NOT_UNIFIED_DIFF** The patch file does not appear to be in unified-diff format. Please @@ -742,14 +1157,12 @@ Others **PRINTF_0XDECIMAL** Prefixing 0x with decimal output is defective and should be corrected. - **TRAILING_STATEMENTS** - Trailing statements (for example after any conditional) should be - on the next line. - Like:: - - if (x == y) break; + **SPDX_LICENSE_TAG** + The source file is missing or has an improper SPDX identifier tag. + The Linux kernel requires the precise SPDX identifier in all source files, + and it is thoroughly documented in the kernel docs. - should be:: + See: https://www.kernel.org/doc/html/latest/process/license-rules.html - if (x == y) - break; + **TYPO_SPELLING** + Some words may have been misspelled. Consider reviewing them. diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index d3f335ffc751..83ec4a556c19 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -447,11 +447,10 @@ When a test fails due to a failed ``kmalloc``:: When a test fails due to a missing KASAN report:: - # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629 - Expected kasan_data->report_expected == kasan_data->report_found, but - kasan_data->report_expected == 1 - kasan_data->report_found == 0 - not ok 28 - kmalloc_double_kzfree + # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:974 + KASAN failure expected in "kfree_sensitive(ptr)", but none occurred + not ok 44 - kmalloc_double_kzfree + At the end the cumulative status of all KASAN tests is printed. On success:: diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index d85ce238ace7..6a600cf8430b 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -27,75 +27,57 @@ Error reports A typical data race report looks like this:: ================================================================== - BUG: KCSAN: data-race in generic_permission / kernfs_refresh_inode - - write to 0xffff8fee4c40700c of 4 bytes by task 175 on cpu 4: - kernfs_refresh_inode+0x70/0x170 - kernfs_iop_permission+0x4f/0x90 - inode_permission+0x190/0x200 - link_path_walk.part.0+0x503/0x8e0 - path_lookupat.isra.0+0x69/0x4d0 - filename_lookup+0x136/0x280 - user_path_at_empty+0x47/0x60 - vfs_statx+0x9b/0x130 - __do_sys_newlstat+0x50/0xb0 - __x64_sys_newlstat+0x37/0x50 - do_syscall_64+0x85/0x260 - entry_SYSCALL_64_after_hwframe+0x44/0xa9 - - read to 0xffff8fee4c40700c of 4 bytes by task 166 on cpu 6: - generic_permission+0x5b/0x2a0 - kernfs_iop_permission+0x66/0x90 - inode_permission+0x190/0x200 - link_path_walk.part.0+0x503/0x8e0 - path_lookupat.isra.0+0x69/0x4d0 - filename_lookup+0x136/0x280 - user_path_at_empty+0x47/0x60 - do_faccessat+0x11a/0x390 - __x64_sys_access+0x3c/0x50 - do_syscall_64+0x85/0x260 - entry_SYSCALL_64_after_hwframe+0x44/0xa9 + BUG: KCSAN: data-race in test_kernel_read / test_kernel_write + + write to 0xffffffffc009a628 of 8 bytes by task 487 on cpu 0: + test_kernel_write+0x1d/0x30 + access_thread+0x89/0xd0 + kthread+0x23e/0x260 + ret_from_fork+0x22/0x30 + + read to 0xffffffffc009a628 of 8 bytes by task 488 on cpu 6: + test_kernel_read+0x10/0x20 + access_thread+0x89/0xd0 + kthread+0x23e/0x260 + ret_from_fork+0x22/0x30 + + value changed: 0x00000000000009a6 -> 0x00000000000009b2 Reported by Kernel Concurrency Sanitizer on: - CPU: 6 PID: 166 Comm: systemd-journal Not tainted 5.3.0-rc7+ #1 - Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 + CPU: 6 PID: 488 Comm: access_thread Not tainted 5.12.0-rc2+ #1 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 ================================================================== The header of the report provides a short summary of the functions involved in the race. It is followed by the access types and stack traces of the 2 threads -involved in the data race. +involved in the data race. If KCSAN also observed a value change, the observed +old value and new value are shown on the "value changed" line respectively. The other less common type of data race report looks like this:: ================================================================== - BUG: KCSAN: data-race in e1000_clean_rx_irq+0x551/0xb10 - - race at unknown origin, with read to 0xffff933db8a2ae6c of 1 bytes by interrupt on cpu 0: - e1000_clean_rx_irq+0x551/0xb10 - e1000_clean+0x533/0xda0 - net_rx_action+0x329/0x900 - __do_softirq+0xdb/0x2db - irq_exit+0x9b/0xa0 - do_IRQ+0x9c/0xf0 - ret_from_intr+0x0/0x18 - default_idle+0x3f/0x220 - arch_cpu_idle+0x21/0x30 - do_idle+0x1df/0x230 - cpu_startup_entry+0x14/0x20 - rest_init+0xc5/0xcb - arch_call_rest_init+0x13/0x2b - start_kernel+0x6db/0x700 + BUG: KCSAN: data-race in test_kernel_rmw_array+0x71/0xd0 + + race at unknown origin, with read to 0xffffffffc009bdb0 of 8 bytes by task 515 on cpu 2: + test_kernel_rmw_array+0x71/0xd0 + access_thread+0x89/0xd0 + kthread+0x23e/0x260 + ret_from_fork+0x22/0x30 + + value changed: 0x0000000000002328 -> 0x0000000000002329 Reported by Kernel Concurrency Sanitizer on: - CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc7+ #2 - Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 + CPU: 2 PID: 515 Comm: access_thread Not tainted 5.12.0-rc2+ #1 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 ================================================================== This report is generated where it was not possible to determine the other racing thread, but a race was inferred due to the data value of the watched -memory location having changed. These can occur either due to missing -instrumentation or e.g. DMA accesses. These reports will only be generated if -``CONFIG_KCSAN_REPORT_RACE_UNKNOWN_ORIGIN=y`` (selected by default). +memory location having changed. These reports always show a "value changed" +line. A common reason for reports of this type are missing instrumentation in +the racing thread, but could also occur due to e.g. DMA accesses. Such reports +are shown only if ``CONFIG_KCSAN_REPORT_RACE_UNKNOWN_ORIGIN=y``, which is +enabled by default. Selective analysis ~~~~~~~~~~~~~~~~~~ @@ -106,7 +88,8 @@ the below options are available: * KCSAN understands the ``data_race(expr)`` annotation, which tells KCSAN that any data races due to accesses in ``expr`` should be ignored and resulting - behaviour when encountering a data race is deemed safe. + behaviour when encountering a data race is deemed safe. Please see + `"Marking Shared-Memory Accesses" in the LKMM`_ for more information. * Disabling data race detection for entire functions can be accomplished by using the function attribute ``__no_kcsan``:: @@ -128,6 +111,8 @@ the below options are available: KCSAN_SANITIZE := n +.. _"Marking Shared-Memory Accesses" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/access-marking.txt + Furthermore, it is possible to tell KCSAN to show or hide entire classes of data races, depending on preferences. These can be changed via the following Kconfig options: diff --git a/Documentation/dev-tools/kunit/api/index.rst b/Documentation/dev-tools/kunit/api/index.rst index 9b9bffe5d41a..b33ad72bcf0b 100644 --- a/Documentation/dev-tools/kunit/api/index.rst +++ b/Documentation/dev-tools/kunit/api/index.rst @@ -10,7 +10,7 @@ API Reference This section documents the KUnit kernel testing API. It is divided into the following sections: -================================= ============================================== -:doc:`test` documents all of the standard testing API - excluding mocking or mocking related features. -================================= ============================================== +Documentation/dev-tools/kunit/api/test.rst + + - documents all of the standard testing API excluding mocking + or mocking related features. diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst index 8d5029ad210a..5c6555d020f3 100644 --- a/Documentation/dev-tools/kunit/faq.rst +++ b/Documentation/dev-tools/kunit/faq.rst @@ -97,7 +97,7 @@ things to try. modules will automatically execute associated tests when loaded. Test results can be collected from ``/sys/kernel/debug/kunit/<test suite>/results``, and can be parsed with ``kunit.py parse``. For more details, see "KUnit on - non-UML architectures" in :doc:`usage`. + non-UML architectures" in Documentation/dev-tools/kunit/usage.rst. If none of the above tricks help, you are always welcome to email any issues to kunit-dev@googlegroups.com. diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst index 848478838347..cacb35ec658d 100644 --- a/Documentation/dev-tools/kunit/index.rst +++ b/Documentation/dev-tools/kunit/index.rst @@ -14,6 +14,7 @@ KUnit - Unit Testing for the Linux Kernel style faq tips + running_tips What is KUnit? ============== @@ -36,7 +37,7 @@ To make running these tests (and reading the results) easier, KUnit offers results. This provides a quick way of running KUnit tests during development, without requiring a virtual machine or separate hardware. -Get started now: :doc:`start` +Get started now: Documentation/dev-tools/kunit/start.rst Why KUnit? ========== @@ -88,9 +89,9 @@ it takes to read their test log? How do I use it? ================ -* :doc:`start` - for new users of KUnit -* :doc:`tips` - for short examples of best practices -* :doc:`usage` - for a more detailed explanation of KUnit features -* :doc:`api/index` - for the list of KUnit APIs used for testing -* :doc:`kunit-tool` - for more information on the kunit_tool helper script -* :doc:`faq` - for answers to some common questions about KUnit +* Documentation/dev-tools/kunit/start.rst - for new users of KUnit +* Documentation/dev-tools/kunit/tips.rst - for short examples of best practices +* Documentation/dev-tools/kunit/usage.rst - for a more detailed explanation of KUnit features +* Documentation/dev-tools/kunit/api/index.rst - for the list of KUnit APIs used for testing +* Documentation/dev-tools/kunit/kunit-tool.rst - for more information on the kunit_tool helper script +* Documentation/dev-tools/kunit/faq.rst - for answers to some common questions about KUnit diff --git a/Documentation/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst index 29ae2fee8123..c7ff9afe407a 100644 --- a/Documentation/dev-tools/kunit/kunit-tool.rst +++ b/Documentation/dev-tools/kunit/kunit-tool.rst @@ -22,14 +22,19 @@ not require any virtualization support: it is just a regular program. What is a .kunitconfig? ======================= -It's just a defconfig that kunit_tool looks for in the base directory. -kunit_tool uses it to generate a .config as you might expect. In addition, it -verifies that the generated .config contains the CONFIG options in the -.kunitconfig; the reason it does this is so that it is easy to be sure that a -CONFIG that enables a test actually ends up in the .config. +It's just a defconfig that kunit_tool looks for in the build directory +(``.kunit`` by default). kunit_tool uses it to generate a .config as you might +expect. In addition, it verifies that the generated .config contains the CONFIG +options in the .kunitconfig; the reason it does this is so that it is easy to +be sure that a CONFIG that enables a test actually ends up in the .config. -How do I use kunit_tool? -======================== +It's also possible to pass a separate .kunitconfig fragment to kunit_tool, +which is useful if you have several different groups of tests you wish +to run independently, or if you want to use pre-defined test configs for +certain subsystems. + +Getting Started with kunit_tool +=============================== If a kunitconfig is present at the root directory, all you have to do is: @@ -48,10 +53,177 @@ However, you most likely want to use it with the following options: .. note:: This command will work even without a .kunitconfig file: if no - .kunitconfig is present, a default one will be used instead. + .kunitconfig is present, a default one will be used instead. + +If you wish to use a different .kunitconfig file (such as one provided for +testing a particular subsystem), you can pass it as an option. + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run --kunitconfig=fs/ext4/.kunitconfig For a list of all the flags supported by kunit_tool, you can run: .. code-block:: bash ./tools/testing/kunit/kunit.py run --help + +Configuring, Building, and Running Tests +======================================== + +It's also possible to run just parts of the KUnit build process independently, +which is useful if you want to make manual changes to part of the process. + +A .config can be generated from a .kunitconfig by using the ``config`` argument +when running kunit_tool: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py config + +Similarly, if you just want to build a KUnit kernel from the current .config, +you can use the ``build`` argument: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py build + +And, if you already have a built UML kernel with built-in KUnit tests, you can +run the kernel and display the test results with the ``exec`` argument: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py exec + +The ``run`` command which is discussed above is equivalent to running all three +of these in sequence. + +All of these commands accept a number of optional command-line arguments. The +``--help`` flag will give a complete list of these, or keep reading this page +for a guide to some of the more useful ones. + +Parsing Test Results +==================== + +KUnit tests output their results in TAP (Test Anything Protocol) format. +kunit_tool will, when running tests, parse this output and print a summary +which is much more pleasant to read. If you wish to look at the raw test +results in TAP format, you can pass the ``--raw_output`` argument. + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run --raw_output + +.. note:: + The raw output from test runs may contain other, non-KUnit kernel log + lines. + +If you have KUnit results in their raw TAP format, you can parse them and print +the human-readable summary with the ``parse`` command for kunit_tool. This +accepts a filename for an argument, or will read from standard input. + +.. code-block:: bash + + # Reading from a file + ./tools/testing/kunit/kunit.py parse /var/log/dmesg + # Reading from stdin + dmesg | ./tools/testing/kunit/kunit.py parse + +This is very useful if you wish to run tests in a configuration not supported +by kunit_tool (such as on real hardware, or an unsupported architecture). + +Filtering Tests +=============== + +It's possible to run only a subset of the tests built into a kernel by passing +a filter to the ``exec`` or ``run`` commands. For example, if you only wanted +to run KUnit resource tests, you could use: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run 'kunit-resource*' + +This uses the standard glob format for wildcards. + +Running Tests on QEMU +===================== + +kunit_tool supports running tests on QEMU as well as via UML (as mentioned +elsewhere). The default way of running tests on QEMU requires two flags: + +``--arch`` + Selects a collection of configs (Kconfig as well as QEMU configs + options, etc) that allow KUnit tests to be run on the specified + architecture in a minimal way; this is usually not much slower than + using UML. The architecture argument is the same as the name of the + option passed to the ``ARCH`` variable used by Kbuild. Not all + architectures are currently supported by this flag, but can be handled + by the ``--qemu_config`` discussed later. If ``um`` is passed (or this + this flag is ignored) the tests will run via UML. Non-UML architectures, + e.g. i386, x86_64, arm, um, etc. Non-UML run on QEMU. + +``--cross_compile`` + Specifies the use of a toolchain by Kbuild. The argument passed here is + the same passed to the ``CROSS_COMPILE`` variable used by Kbuild. As a + reminder this will be the prefix for the toolchain binaries such as gcc + for example ``sparc64-linux-gnu-`` if you have the sparc toolchain + installed on your system, or + ``$HOME/toolchains/microblaze/gcc-9.2.0-nolibc/microblaze-linux/bin/microblaze-linux-`` + if you have downloaded the microblaze toolchain from the 0-day website + to a directory in your home directory called ``toolchains``. + +In many cases it is likely that you may want to run an architecture which is +not supported by the ``--arch`` flag, or you may want to just run KUnit tests +on QEMU using a non-default configuration. For this use case, you can write +your own QemuConfig. These QemuConfigs are written in Python. They must have an +import line ``from ..qemu_config import QemuArchParams`` at the top of the file +and the file must contain a variable called ``QEMU_ARCH`` that has an instance +of ``QemuArchParams`` assigned to it. An example can be seen in +``tools/testing/kunit/qemu_configs/x86_64.py``. + +Once you have a QemuConfig you can pass it into kunit_tool using the +``--qemu_config`` flag; when used this flag replaces the ``--arch`` flag. If we +were to do this with the ``x86_64.py`` example from above, the invocation would +look something like this: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run \ + --timeout=60 \ + --jobs=12 \ + --qemu_config=./tools/testing/kunit/qemu_configs/x86_64.py + +Other Useful Options +==================== + +kunit_tool has a number of other command-line arguments which can be useful +when adapting it to fit your environment or needs. + +Some of the more useful ones are: + +``--help`` + Lists all of the available options. Note that different commands + (``config``, ``build``, ``run``, etc) will have different supported + options. Place ``--help`` before the command to list common options, + and after the command for options specific to that command. + +``--build_dir`` + Specifies the build directory that kunit_tool will use. This is where + the .kunitconfig file is located, as well as where the .config and + compiled kernel will be placed. Defaults to ``.kunit``. + +``--make_options`` + Specifies additional options to pass to ``make`` when compiling a + kernel (with the ``build`` or ``run`` commands). For example, to enable + compiler warnings, you can pass ``--make_options W=1``. + +``--alltests`` + Builds a UML kernel with all config options enabled using ``make + allyesconfig``. This allows you to run as many tests as is possible, + but is very slow and prone to breakage as new options are added or + modified. In most cases, enabling all tests which have satisfied + dependencies by adding ``CONFIG_KUNIT_ALL_TESTS=1`` to your + .kunitconfig is preferable. + +There are several other options (and new ones are often added), so do check +``--help`` if you're looking for something not mentioned here. diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst new file mode 100644 index 000000000000..7d99386cf94a --- /dev/null +++ b/Documentation/dev-tools/kunit/running_tips.rst @@ -0,0 +1,259 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Tips For Running KUnit Tests +============================ + +Using ``kunit.py run`` ("kunit tool") +===================================== + +Running from any directory +-------------------------- + +It can be handy to create a bash function like: + +.. code-block:: bash + + function run_kunit() { + ( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run $@ ) + } + +.. note:: + Early versions of ``kunit.py`` (before 5.6) didn't work unless run from + the kernel root, hence the use of a subshell and ``cd``. + +Running a subset of tests +------------------------- + +``kunit.py run`` accepts an optional glob argument to filter tests. Currently +this only matches against suite names, but this may change in the future. + +Say that we wanted to run the sysctl tests, we could do so via: + +.. code-block:: bash + + $ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig + $ ./tools/testing/kunit/kunit.py run 'sysctl*' + +We're paying the cost of building more tests than we need this way, but it's +easier than fiddling with ``.kunitconfig`` files or commenting out +``kunit_suite``'s. + +However, if we wanted to define a set of tests in a less ad hoc way, the next +tip is useful. + +Defining a set of tests +----------------------- + +``kunit.py run`` (along with ``build``, and ``config``) supports a +``--kunitconfig`` flag. So if you have a set of tests that you want to run on a +regular basis (especially if they have other dependencies), you can create a +specific ``.kunitconfig`` for them. + +E.g. kunit has one for its tests: + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit/.kunitconfig + +Alternatively, if you're following the convention of naming your +file ``.kunitconfig``, you can just pass in the dir, e.g. + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit + +.. note:: + This is a relatively new feature (5.12+) so we don't have any + conventions yet about on what files should be checked in versus just + kept around locally. It's up to you and your maintainer to decide if a + config is useful enough to submit (and therefore have to maintain). + +.. note:: + Having ``.kunitconfig`` fragments in a parent and child directory is + iffy. There's discussion about adding an "import" statement in these + files to make it possible to have a top-level config run tests from all + child directories. But that would mean ``.kunitconfig`` files are no + longer just simple .config fragments. + + One alternative would be to have kunit tool recursively combine configs + automagically, but tests could theoretically depend on incompatible + options, so handling that would be tricky. + +Generating code coverage reports under UML +------------------------------------------ + +.. note:: + TODO(brendanhiggins@google.com): There are various issues with UML and + versions of gcc 7 and up. You're likely to run into missing ``.gcda`` + files or compile errors. We know one `faulty GCC commit + <https://github.com/gcc-mirror/gcc/commit/8c9434c2f9358b8b8bad2c1990edf10a21645f9d>`_ + but not how we'd go about getting this fixed. The compile errors still + need some investigation. + +.. note:: + TODO(brendanhiggins@google.com): for recent versions of Linux + (5.10-5.12, maybe earlier), there's a bug with gcov counters not being + flushed in UML. This translates to very low (<1%) reported coverage. This is + related to the above issue and can be worked around by replacing the + one call to ``uml_abort()`` (it's in ``os_dump_core()``) with a plain + ``exit()``. + + +This is different from the "normal" way of getting coverage information that is +documented in Documentation/dev-tools/gcov.rst. + +Instead of enabling ``CONFIG_GCOV_KERNEL=y``, we can set these options: + +.. code-block:: none + + CONFIG_DEBUG_KERNEL=y + CONFIG_DEBUG_INFO=y + CONFIG_GCOV=y + + +Putting it together into a copy-pastable sequence of commands: + +.. code-block:: bash + + # Append coverage options to the current config + $ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig + $ ./tools/testing/kunit/kunit.py run + # Extract the coverage information from the build dir (.kunit/) + $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ + + # From here on, it's the same process as with CONFIG_GCOV_KERNEL=y + # E.g. can generate an HTML report in a tmp dir like so: + $ genhtml -o /tmp/coverage_html coverage.info + + +If your installed version of gcc doesn't work, you can tweak the steps: + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py run --make_options=CC=/usr/bin/gcc-6 + $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ --gcov-tool=/usr/bin/gcov-6 + + +Running tests manually +====================== + +Running tests without using ``kunit.py run`` is also an important use case. +Currently it's your only option if you want to test on architectures other than +UML. + +As running the tests under UML is fairly straightforward (configure and compile +the kernel, run the ``./linux`` binary), this section will focus on testing +non-UML architectures. + + +Running built-in tests +---------------------- + +When setting tests to ``=y``, the tests will run as part of boot and print +results to dmesg in TAP format. So you just need to add your tests to your +``.config``, build and boot your kernel as normal. + +So if we compiled our kernel with: + +.. code-block:: none + + CONFIG_KUNIT=y + CONFIG_KUNIT_EXAMPLE_TEST=y + +Then we'd see output like this in dmesg signaling the test ran and passed: + +.. code-block:: none + + TAP version 14 + 1..1 + # Subtest: example + 1..1 + # example_simple_test: initializing + ok 1 - example_simple_test + ok 1 - example + +Running tests as modules +------------------------ + +Depending on the tests, you can build them as loadable modules. + +For example, we'd change the config options from before to + +.. code-block:: none + + CONFIG_KUNIT=y + CONFIG_KUNIT_EXAMPLE_TEST=m + +Then after booting into our kernel, we can run the test via + +.. code-block:: none + + $ modprobe kunit-example-test + +This will then cause it to print TAP output to stdout. + +.. note:: + The ``modprobe`` will *not* have a non-zero exit code if any test + failed (as of 5.13). But ``kunit.py parse`` would, see below. + +.. note:: + You can set ``CONFIG_KUNIT=m`` as well, however, some features will not + work and thus some tests might break. Ideally tests would specify they + depend on ``KUNIT=y`` in their ``Kconfig``'s, but this is an edge case + most test authors won't think about. + As of 5.13, the only difference is that ``current->kunit_test`` will + not exist. + +Pretty-printing results +----------------------- + +You can use ``kunit.py parse`` to parse dmesg for test output and print out +results in the same familiar format that ``kunit.py run`` does. + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py parse /var/log/dmesg + + +Retrieving per suite results +---------------------------- + +Regardless of how you're running your tests, you can enable +``CONFIG_KUNIT_DEBUGFS`` to expose per-suite TAP-formatted results: + +.. code-block:: none + + CONFIG_KUNIT=y + CONFIG_KUNIT_EXAMPLE_TEST=m + CONFIG_KUNIT_DEBUGFS=y + +The results for each suite will be exposed under +``/sys/kernel/debug/kunit/<suite>/results``. +So using our example config: + +.. code-block:: bash + + $ modprobe kunit-example-test > /dev/null + $ cat /sys/kernel/debug/kunit/example/results + ... <TAP output> ... + + # After removing the module, the corresponding files will go away + $ modprobe -r kunit-example-test + $ cat /sys/kernel/debug/kunit/example/results + /sys/kernel/debug/kunit/example/results: No such file or directory + +Generating code coverage reports +-------------------------------- + +See Documentation/dev-tools/gcov.rst for details on how to do this. + +The only vaguely KUnit-specific advice here is that you probably want to build +your tests as modules. That way you can isolate the coverage from tests from +other code executed during boot, e.g. + +.. code-block:: bash + + # Reset coverage counters before running the test. + $ echo 0 > /sys/kernel/debug/gcov/reset + $ modprobe kunit-example-test diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index 0e65cabe08eb..1e00f9226f74 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -21,7 +21,7 @@ The wrapper can be run with: ./tools/testing/kunit/kunit.py run For more information on this wrapper (also called kunit_tool) check out the -:doc:`kunit-tool` page. +Documentation/dev-tools/kunit/kunit-tool.rst page. Creating a .kunitconfig ----------------------- @@ -36,7 +36,7 @@ A good starting point for a ``.kunitconfig`` is the KUnit defconfig: .. code-block:: bash cd $PATH_TO_LINUX_REPO - cp arch/um/configs/kunit_defconfig .kunitconfig + cp tools/testing/kunit/configs/default.config .kunitconfig You can then add any other Kconfig options you wish, e.g.: @@ -234,7 +234,9 @@ Congrats! You just wrote your first KUnit test! Next Steps ========== -* Check out the :doc:`tips` page for tips on +* Check out the Documentation/dev-tools/kunit/tips.rst page for tips on writing idiomatic KUnit tests. +* Check out the :doc:`running_tips` page for tips on + how to make running KUnit tests easier. * Optional: see the :doc:`usage` page for a more in-depth explanation of KUnit. diff --git a/Documentation/dev-tools/kunit/tips.rst b/Documentation/dev-tools/kunit/tips.rst index 8d8c238f7f79..492d2ded2f5a 100644 --- a/Documentation/dev-tools/kunit/tips.rst +++ b/Documentation/dev-tools/kunit/tips.rst @@ -125,7 +125,8 @@ Here's a slightly in-depth example of how one could implement "mocking": Note: here we're able to get away with using ``test->priv``, but if you wanted -something more flexible you could use a named ``kunit_resource``, see :doc:`api/test`. +something more flexible you could use a named ``kunit_resource``, see +Documentation/dev-tools/kunit/api/test.rst. Failing the current test ------------------------ @@ -185,5 +186,5 @@ Alternatively, one can take full control over the error message by using ``KUNIT Next Steps ========== -* Optional: see the :doc:`usage` page for a more +* Optional: see the Documentation/dev-tools/kunit/usage.rst page for a more in-depth explanation of KUnit. diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 650f99590df5..63f1bb89ebf5 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -10,7 +10,7 @@ understand it. This guide assumes a working knowledge of the Linux kernel and some basic knowledge of testing. For a high level introduction to KUnit, including setting up KUnit for your -project, see :doc:`start`. +project, see Documentation/dev-tools/kunit/start.rst. Organization of this document ============================= @@ -99,7 +99,8 @@ violated; however, the test will continue running, potentially trying other expectations until the test case ends or is otherwise terminated. This is as opposed to *assertions* which are discussed later. -To learn about more expectations supported by KUnit, see :doc:`api/test`. +To learn about more expectations supported by KUnit, see +Documentation/dev-tools/kunit/api/test.rst. .. note:: A single test case should be pretty short, pretty easy to understand, @@ -216,7 +217,8 @@ test suite in a special linker section so that it can be run by KUnit either after late_init, or when the test module is loaded (depending on whether the test was built in or not). -For more information on these types of things see the :doc:`api/test`. +For more information on these types of things see the +Documentation/dev-tools/kunit/api/test.rst. Common Patterns =============== @@ -465,10 +467,9 @@ fictitious example for ``sha1sum(1)`` .. code-block:: c - /* Note: the cast is to satisfy overly strict type-checking. */ #define TEST_SHA1(in, want) \ sha1sum(in, out); \ - KUNIT_EXPECT_STREQ_MSG(test, (char *)out, want, "sha1sum(%s)", in); + KUNIT_EXPECT_STREQ_MSG(test, out, want, "sha1sum(%s)", in); char out[40]; TEST_SHA1("hello world", "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed"); @@ -507,7 +508,7 @@ In some cases, it can be helpful to write a *table-driven test* instead, e.g. }; for (i = 0; i < ARRAY_SIZE(cases); ++i) { sha1sum(cases[i].str, out); - KUNIT_EXPECT_STREQ_MSG(test, (char *)out, cases[i].sha1, + KUNIT_EXPECT_STREQ_MSG(test, out, cases[i].sha1, "sha1sum(%s)", cases[i].str); } @@ -568,7 +569,7 @@ Reusing the same ``cases`` array from above, we can write the test as a struct sha1_test_case *test_param = (struct sha1_test_case *)(test->param_value); sha1sum(test_param->str, out); - KUNIT_EXPECT_STREQ_MSG(test, (char *)out, test_param->sha1, + KUNIT_EXPECT_STREQ_MSG(test, out, test_param->sha1, "sha1sum(%s)", test_param->str); } @@ -609,17 +610,45 @@ non-UML architectures: None of these are reasons not to run your KUnit tests on real hardware; they are only things to be aware of when doing so. -The biggest impediment will likely be that certain KUnit features and -infrastructure may not support your target environment. For example, at this -time the KUnit Wrapper (``tools/testing/kunit/kunit.py``) does not work outside -of UML. Unfortunately, there is no way around this. Using UML (or even just a -particular architecture) allows us to make a lot of assumptions that make it -possible to do things which might otherwise be impossible. - -Nevertheless, all core KUnit framework features are fully supported on all -architectures, and using them is straightforward: all you need to do is to take -your kunitconfig, your Kconfig options for the tests you would like to run, and -merge them into whatever config your are using for your platform. That's it! +Currently, the KUnit Wrapper (``tools/testing/kunit/kunit.py``) (aka +kunit_tool) only fully supports running tests inside of UML and QEMU; however, +this is only due to our own time limitations as humans working on KUnit. It is +entirely possible to support other emulators and even actual hardware, but for +now QEMU and UML is what is fully supported within the KUnit Wrapper. Again, to +be clear, this is just the Wrapper. The actualy KUnit tests and the KUnit +library they are written in is fully architecture agnostic and can be used in +virtually any setup, you just won't have the benefit of typing a single command +out of the box and having everything magically work perfectly. + +Again, all core KUnit framework features are fully supported on all +architectures, and using them is straightforward: Most popular architectures +are supported directly in the KUnit Wrapper via QEMU. Currently, supported +architectures on QEMU include: + +* i386 +* x86_64 +* arm +* arm64 +* alpha +* powerpc +* riscv +* s390 +* sparc + +In order to run KUnit tests on one of these architectures via QEMU with the +KUnit wrapper, all you need to do is specify the flags ``--arch`` and +``--cross_compile`` when invoking the KUnit Wrapper. For example, we could run +the default KUnit tests on ARM in the following manner (assuming we have an ARM +toolchain installed): + +.. code-block:: bash + + tools/testing/kunit/kunit.py run --timeout=60 --jobs=12 --arch=arm --cross_compile=arm-linux-gnueabihf- + +Alternatively, if you want to run your tests on real hardware or in some other +emulation environment, all you need to do is to take your kunitconfig, your +Kconfig options for the tests you would like to run, and merge them into +whatever config your are using for your platform. That's it! For example, let's say you have the following kunitconfig: diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst index b5b46709969c..65feb81edb14 100644 --- a/Documentation/dev-tools/testing-overview.rst +++ b/Documentation/dev-tools/testing-overview.rst @@ -71,15 +71,15 @@ can be used to verify that a test is executing particular functions or lines of code. This is useful for determining how much of the kernel is being tested, and for finding corner-cases which are not covered by the appropriate test. -:doc:`gcov` is GCC's coverage testing tool, which can be used with the kernel -to get global or per-module coverage. Unlike KCOV, it does not record per-task -coverage. Coverage data can be read from debugfs, and interpreted using the -usual gcov tooling. - -:doc:`kcov` is a feature which can be built in to the kernel to allow -capturing coverage on a per-task level. It's therefore useful for fuzzing and -other situations where information about code executed during, for example, a -single syscall is useful. +Documentation/dev-tools/gcov.rst is GCC's coverage testing tool, which can be +used with the kernel to get global or per-module coverage. Unlike KCOV, it +does not record per-task coverage. Coverage data can be read from debugfs, +and interpreted using the usual gcov tooling. + +Documentation/dev-tools/kcov.rst is a feature which can be built in to the +kernel to allow capturing coverage on a per-task level. It's therefore useful +for fuzzing and other situations where information about code executed during, +for example, a single syscall is useful. Dynamic Analysis Tools diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt deleted file mode 100644 index 5ab59da052df..000000000000 --- a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt +++ /dev/null @@ -1,27 +0,0 @@ -System Control and Power Interface (SCPI) Message Protocol -(in addition to the standard binding in [0]) ----------------------------------------------------------- -Required properties - -- compatible : should be "amlogic,meson-gxbb-scpi" - -AMLOGIC SRAM and Shared Memory for SCPI ------------------------------------- - -Required properties: -- compatible : should be "amlogic,meson-gxbb-sram" - -Each sub-node represents the reserved area for SCPI. - -Required sub-node properties: -- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared - memory on Amlogic GXBB SoC. - -Sensor bindings for the sensors based on SCPI Message Protocol --------------------------------------------------------------- -SCPI provides an API to access the various sensors on the SoC. - -Required properties: -- compatible : should be "amlogic,meson-gxbb-scpi-sensors". - -[0] Documentation/devicetree/bindings/arm/arm,scpi.txt diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt deleted file mode 100644 index 667d58e0a659..000000000000 --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt +++ /dev/null @@ -1,239 +0,0 @@ -System Control and Management Interface (SCMI) Message Protocol ----------------------------------------------------------- - -The SCMI is intended to allow agents such as OSPM to manage various functions -that are provided by the hardware platform it is running on, including power -and performance functions. - -This binding is intended to define the interface the firmware implementing -the SCMI as described in ARM document number ARM DEN 0056A ("ARM System Control -and Management Interface Platform Design Document")[0] provide for OSPM in -the device tree. - -Required properties: - -The scmi node with the following properties shall be under the /firmware/ node. - -- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports -- mboxes: List of phandle and mailbox channel specifiers. It should contain - exactly one or two mailboxes, one for transmitting messages("tx") - and another optional for receiving the notifications("rx") if - supported. -- shmem : List of phandle pointing to the shared memory(SHM) area as per - generic mailbox client binding. -- #address-cells : should be '1' if the device has sub-nodes, maps to - protocol identifier for a given sub-node. -- #size-cells : should be '0' as 'reg' property doesn't have any size - associated with it. -- arm,smc-id : SMC id required when using smc or hvc transports - -Optional properties: - -- mbox-names: shall be "tx" or "rx" depending on mboxes entries. - -- interrupts : when using smc or hvc transports, this optional - property indicates that msg completion by the platform is indicated - by an interrupt rather than by the return of the smc call. This - should not be used except when the platform requires such behavior. - -- interrupt-names : if "interrupts" is present, interrupt-names must also - be present and have the value "a2p". - -See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details -about the generic mailbox controller and client driver bindings. - -The mailbox is the only permitted method of calling the SCMI firmware. -Mailbox doorbell is used as a mechanism to alert the presence of a -messages and/or notification. - -Each protocol supported shall have a sub-node with corresponding compatible -as described in the following sections. If the platform supports dedicated -communication channel for a particular protocol, the 3 properties namely: -mboxes, mbox-names and shmem shall be present in the sub-node corresponding -to that protocol. - -Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol ------------------------------------------------------------- - -This binding uses the common clock binding[1]. - -Required properties: -- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands. - -Power domain bindings for the power domains based on SCMI Message Protocol ------------------------------------------------------------- - -This binding for the SCMI power domain providers uses the generic power -domain binding[2]. - -Required properties: - - #power-domain-cells : Should be 1. Contains the device or the power - domain ID value used by SCMI commands. - -Regulator bindings for the SCMI Regulator based on SCMI Message Protocol ------------------------------------------------------------- -An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain, -and should be always positioned as a root regulator. -It does not support any current operation. - -SCMI Regulators are grouped under a 'regulators' node which in turn is a child -of the SCMI Voltage protocol node inside the desired SCMI instance node. - -This binding uses the common regulator binding[6]. - -Required properties: - - reg : shall identify an existent SCMI Voltage Domain. - -Sensor bindings for the sensors based on SCMI Message Protocol --------------------------------------------------------------- -SCMI provides an API to access the various sensors on the SoC. - -Required properties: -- #thermal-sensor-cells: should be set to 1. This property follows the - thermal device tree bindings[3]. - - Valid cell values are raw identifiers (Sensor ID) - as used by the firmware. Refer to platform details - for your implementation for the IDs to use. - -Reset signal bindings for the reset domains based on SCMI Message Protocol ------------------------------------------------------------- - -This binding for the SCMI reset domain providers uses the generic reset -signal binding[5]. - -Required properties: - - #reset-cells : Should be 1. Contains the reset domain ID value used - by SCMI commands. - -SRAM and Shared Memory for SCMI -------------------------------- - -A small area of SRAM is reserved for SCMI communication between application -processors and SCP. - -The properties should follow the generic mmio-sram description found in [4] - -Each sub-node represents the reserved area for SCMI. - -Required sub-node properties: -- reg : The base offset and size of the reserved area with the SRAM -- compatible : should be "arm,scmi-shmem" for Non-secure SRAM based - shared memory - -[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/power/power-domain.yaml -[3] Documentation/devicetree/bindings/thermal/thermal*.yaml -[4] Documentation/devicetree/bindings/sram/sram.yaml -[5] Documentation/devicetree/bindings/reset/reset.txt -[6] Documentation/devicetree/bindings/regulator/regulator.yaml - -Example: - -sram@50000000 { - compatible = "mmio-sram"; - reg = <0x0 0x50000000 0x0 0x10000>; - - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x0 0x50000000 0x10000>; - - cpu_scp_lpri: scp-shmem@0 { - compatible = "arm,scmi-shmem"; - reg = <0x0 0x200>; - }; - - cpu_scp_hpri: scp-shmem@200 { - compatible = "arm,scmi-shmem"; - reg = <0x200 0x200>; - }; -}; - -mailbox@40000000 { - .... - #mbox-cells = <1>; - reg = <0x0 0x40000000 0x0 0x10000>; -}; - -firmware { - - ... - - scmi { - compatible = "arm,scmi"; - mboxes = <&mailbox 0 &mailbox 1>; - mbox-names = "tx", "rx"; - shmem = <&cpu_scp_lpri &cpu_scp_hpri>; - #address-cells = <1>; - #size-cells = <0>; - - scmi_devpd: protocol@11 { - reg = <0x11>; - #power-domain-cells = <1>; - }; - - scmi_dvfs: protocol@13 { - reg = <0x13>; - #clock-cells = <1>; - }; - - scmi_clk: protocol@14 { - reg = <0x14>; - #clock-cells = <1>; - }; - - scmi_sensors0: protocol@15 { - reg = <0x15>; - #thermal-sensor-cells = <1>; - }; - - scmi_reset: protocol@16 { - reg = <0x16>; - #reset-cells = <1>; - }; - - scmi_voltage: protocol@17 { - reg = <0x17>; - - regulators { - regulator_devX: regulator@0 { - reg = <0x0>; - regulator-max-microvolt = <3300000>; - }; - - regulator_devY: regulator@9 { - reg = <0x9>; - regulator-min-microvolt = <500000>; - regulator-max-microvolt = <4200000>; - }; - - ... - }; - }; - }; -}; - -cpu@0 { - ... - reg = <0 0>; - clocks = <&scmi_dvfs 0>; -}; - -hdlcd@7ff60000 { - ... - reg = <0 0x7ff60000 0 0x1000>; - clocks = <&scmi_clk 4>; - power-domains = <&scmi_devpd 1>; - resets = <&scmi_reset 10>; -}; - -thermal-zones { - soc_thermal { - polling-delay-passive = <100>; - polling-delay = <1000>; - /* sensor ID */ - thermal-sensors = <&scmi_sensors0 3>; - ... - }; -}; diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt deleted file mode 100644 index bcd6c3ec471e..000000000000 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ /dev/null @@ -1,219 +0,0 @@ -System Control and Power Interface (SCPI) Message Protocol ----------------------------------------------------------- - -Firmware implementing the SCPI described in ARM document number ARM DUI 0922B -("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used -by Linux to initiate various system control and power operations. - -Required properties: - -- compatible : should be - * "arm,scpi" : For implementations complying to SCPI v1.0 or above - * "arm,scpi-pre-1.0" : For implementations complying to all - unversioned releases prior to SCPI v1.0 -- mboxes: List of phandle and mailbox channel specifiers - All the channels reserved by remote SCP firmware for use by - SCPI message protocol should be specified in any order -- shmem : List of phandle pointing to the shared memory(SHM) area between the - processors using these mailboxes for IPC, one for each mailbox - SHM can be any memory reserved for the purpose of this communication - between the processors. - -See Documentation/devicetree/bindings/mailbox/mailbox.txt -for more details about the generic mailbox controller and -client driver bindings. - -Clock bindings for the clocks based on SCPI Message Protocol ------------------------------------------------------------- - -This binding uses the common clock binding[1]. - -Container Node -============== -Required properties: -- compatible : should be "arm,scpi-clocks" - All the clocks provided by SCP firmware via SCPI message - protocol much be listed as sub-nodes under this node. - -Sub-nodes -========= -Required properties: -- compatible : shall include one of the following - "arm,scpi-dvfs-clocks" - all the clocks that are variable and index based. - These clocks don't provide an entire range of values between the - limits but only discrete points within the range. The firmware - provides the mapping for each such operating frequency and the - index associated with it. The firmware also manages the - voltage scaling appropriately with the clock scaling. - "arm,scpi-variable-clocks" - all the clocks that are variable and provide full - range within the specified range. The firmware provides the - range of values within a specified range. - -Other required properties for all clocks(all from common clock binding): -- #clock-cells : Should be 1. Contains the Clock ID value used by SCPI commands. -- clock-output-names : shall be the corresponding names of the outputs. -- clock-indices: The identifying number for the clocks(i.e.clock_id) in the - node. It can be non linear and hence provide the mapping of identifiers - into the clock-output-names array. - -SRAM and Shared Memory for SCPI -------------------------------- - -A small area of SRAM is reserved for SCPI communication between application -processors and SCP. - -The properties should follow the generic mmio-sram description found in [3] - -Each sub-node represents the reserved area for SCPI. - -Required sub-node properties: -- reg : The base offset and size of the reserved area with the SRAM -- compatible : should be "arm,scp-shmem" for Non-secure SRAM based - shared memory - -Sensor bindings for the sensors based on SCPI Message Protocol --------------------------------------------------------------- -SCPI provides an API to access the various sensors on the SoC. - -Required properties: -- compatible : should be "arm,scpi-sensors". -- #thermal-sensor-cells: should be set to 1. This property follows the - thermal device tree bindings[2]. - - Valid cell values are raw identifiers (Sensor ID) - as used by the firmware. Refer to platform details - for your implementation for the IDs to use. - -Power domain bindings for the power domains based on SCPI Message Protocol ------------------------------------------------------------- - -This binding uses the generic power domain binding[4]. - -PM domain providers -=================== - -Required properties: - - #power-domain-cells : Should be 1. Contains the device or the power - domain ID value used by SCPI commands. - - num-domains: Total number of power domains provided by SCPI. This is - needed as the SCPI message protocol lacks a mechanism to - query this information at runtime. - -PM domain consumers -=================== - -Required properties: - - power-domains : A phandle and PM domain specifier as defined by bindings of - the power controller specified by phandle. - -[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/thermal/thermal*.yaml -[3] Documentation/devicetree/bindings/sram/sram.yaml -[4] Documentation/devicetree/bindings/power/power-domain.yaml - -Example: - -sram: sram@50000000 { - compatible = "arm,juno-sram-ns", "mmio-sram"; - reg = <0x0 0x50000000 0x0 0x10000>; - - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x0 0x50000000 0x10000>; - - cpu_scp_lpri: scp-shmem@0 { - compatible = "arm,juno-scp-shmem"; - reg = <0x0 0x200>; - }; - - cpu_scp_hpri: scp-shmem@200 { - compatible = "arm,juno-scp-shmem"; - reg = <0x200 0x200>; - }; -}; - -mailbox: mailbox0@40000000 { - .... - #mbox-cells = <1>; -}; - -scpi_protocol: scpi@2e000000 { - compatible = "arm,scpi"; - mboxes = <&mailbox 0 &mailbox 1>; - shmem = <&cpu_scp_lpri &cpu_scp_hpri>; - - clocks { - compatible = "arm,scpi-clocks"; - - scpi_dvfs: scpi_clocks@0 { - compatible = "arm,scpi-dvfs-clocks"; - #clock-cells = <1>; - clock-indices = <0>, <1>, <2>; - clock-output-names = "atlclk", "aplclk","gpuclk"; - }; - scpi_clk: scpi_clocks@3 { - compatible = "arm,scpi-variable-clocks"; - #clock-cells = <1>; - clock-indices = <3>, <4>; - clock-output-names = "pxlclk0", "pxlclk1"; - }; - }; - - scpi_sensors0: sensors { - compatible = "arm,scpi-sensors"; - #thermal-sensor-cells = <1>; - }; - - scpi_devpd: scpi-power-domains { - compatible = "arm,scpi-power-domains"; - num-domains = <2>; - #power-domain-cells = <1>; - }; -}; - -cpu@0 { - ... - reg = <0 0>; - clocks = <&scpi_dvfs 0>; -}; - -hdlcd@7ff60000 { - ... - reg = <0 0x7ff60000 0 0x1000>; - clocks = <&scpi_clk 4>; - power-domains = <&scpi_devpd 1>; -}; - -thermal-zones { - soc_thermal { - polling-delay-passive = <100>; - polling-delay = <1000>; - - /* sensor ID */ - thermal-sensors = <&scpi_sensors0 3>; - ... - }; -}; - -In the above example, the #clock-cells is set to 1 as required. -scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0, -1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0 -and pxlclk1 with 3 and 4 as clock-indices. - -The first consumer in the example is cpu@0 and it has '0' as the clock -specifier which points to the first entry in the output clocks of -scpi_dvfs i.e. "atlclk". - -Similarly the second example is hdlcd@7ff60000 and it has pxlclk1 as input -clock. '4' in the clock specifier here points to the second entry -in the output clocks of scpi_clocks i.e. "pxlclk1" - -The thermal-sensors property in the soc_thermal node uses the -temperature sensor provided by SCP firmware to setup a thermal -zone. The ID "3" is the sensor identifier for the temperature sensor -as used by the firmware. - -The num-domains property in scpi-power-domains domain specifies that -SCPI provides 2 power domains. The hdlcd node uses the power domain with -domain ID 1. diff --git a/Documentation/devicetree/bindings/arm/arm,scu.yaml b/Documentation/devicetree/bindings/arm/arm,scu.yaml new file mode 100644 index 000000000000..dae2aa27e641 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,scu.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,scu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Snoop Control Unit (SCU) + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + As part of the MPCore complex, Cortex-A5 and Cortex-A9 are provided + with a Snoop Control Unit. The register range is usually 256 (0x100) + bytes. + + References: + - Cortex-A9: see DDI0407E Cortex-A9 MPCore Technical Reference Manual + Revision r2p0 + - Cortex-A5: see DDI0434B Cortex-A5 MPCore Technical Reference Manual + Revision r0p1 + - ARM11 MPCore: see DDI0360F ARM 11 MPCore Processor Technical Reference + Manial Revision r2p0 + +properties: + compatible: + enum: + - arm,cortex-a9-scu + - arm,cortex-a5-scu + - arm,arm11mp-scu + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + scu@a0410000 { + compatible = "arm,cortex-a9-scu"; + reg = <0xa0410000 0x100>; + }; diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt deleted file mode 100644 index d38834c67dff..000000000000 --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt +++ /dev/null @@ -1,31 +0,0 @@ -OP-TEE Device Tree Bindings - -OP-TEE is a piece of software using hardware features to provide a Trusted -Execution Environment. The security can be provided with ARM TrustZone, but -also by virtualization or a separate chip. - -We're using "linaro" as the first part of the compatible property for -the reference implementation maintained by Linaro. - -* OP-TEE based on ARM TrustZone required properties: - -- compatible : should contain "linaro,optee-tz" - -- method : The method of calling the OP-TEE Trusted OS. Permitted - values are: - - "smc" : SMC #0, with the register assignments specified - in drivers/tee/optee/optee_smc.h - - "hvc" : HVC #0, with the register assignments specified - in drivers/tee/optee/optee_smc.h - - - -Example: - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml new file mode 100644 index 000000000000..c24047c1fdd5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OP-TEE Device Tree Bindings + +maintainers: + - Jens Wiklander <jens.wiklander@linaro.org> + +description: | + OP-TEE is a piece of software using hardware features to provide a Trusted + Execution Environment. The security can be provided with ARM TrustZone, but + also by virtualization or a separate chip. + + We're using "linaro" as the first part of the compatible property for + the reference implementation maintained by Linaro. + +properties: + $nodename: + const: optee + + compatible: + const: linaro,optee-tz + + method: + enum: [smc, hvc] + description: | + The method of calling the OP-TEE Trusted OS depending on smc or hvc + instruction usage. + SMC #0, register assignments + or + HVC #0, register assignments + register assignments are specified in drivers/tee/optee/optee_smc.h + +required: + - compatible + - method + +additionalProperties: false + +examples: + - | + firmware { + optee { + compatible = "linaro,optee-tz"; + method = "smc"; + }; + }; + + - | + firmware { + optee { + compatible = "linaro,optee-tz"; + method = "hvc"; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 395359dc94fd..fd0061712443 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -86,13 +86,11 @@ This binding uses the common clock binding[1]. Required properties: - compatible: Should be one of: - "fsl,imx8qm-clock" - "fsl,imx8qxp-clock" + "fsl,imx8qm-clk" + "fsl,imx8qxp-clk" followed by "fsl,scu-clk" -- #clock-cells: Should be either - 2: Contains the Resource and Clock ID value. - or - 1: Contains the Clock ID value. (DEPRECATED) +- #clock-cells: Should be 2. + Contains the Resource and Clock ID value. - clocks: List of clock specifiers, must contain an entry for each required entry in clock-names - clock-names: Should include entries "xtal_32KHz", "xtal_24MHz" diff --git a/Documentation/devicetree/bindings/arm/intel,keembay.yaml b/Documentation/devicetree/bindings/arm/intel,keembay.yaml index 69cd30872928..107e686ab207 100644 --- a/Documentation/devicetree/bindings/arm/intel,keembay.yaml +++ b/Documentation/devicetree/bindings/arm/intel,keembay.yaml @@ -11,6 +11,8 @@ maintainers: - Daniele Alessandrelli <daniele.alessandrelli@intel.com> properties: + $nodename: + const: '/' compatible: items: - enum: diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt deleted file mode 100644 index 2ace8696bbee..000000000000 --- a/Documentation/devicetree/bindings/arm/juno,scpi.txt +++ /dev/null @@ -1,26 +0,0 @@ -System Control and Power Interface (SCPI) Message Protocol -(in addition to the standard binding in [0]) - -Juno SRAM and Shared Memory for SCPI ------------------------------------- - -Required properties: -- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM - -Each sub-node represents the reserved area for SCPI. - -Required sub-node properties: -- reg : The base offset and size of the reserved area with the SRAM -- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based - shared memory on Juno platforms - -Sensor bindings for the sensors based on SCPI Message Protocol --------------------------------------------------------------- -Required properties: -- compatible : should be "arm,scpi-sensors". -- #thermal-sensor-cells: should be set to 1. - For Juno R0 and Juno R1 refer to [1] for the - sensor identifiers - -[0] Documentation/devicetree/bindings/arm/arm,scpi.txt -[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt deleted file mode 100644 index 6f0cd31c1520..000000000000 --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt +++ /dev/null @@ -1,86 +0,0 @@ -Texas Instruments System Control Interface (TI-SCI) Message Protocol --------------------------------------------------------------------- - -Texas Instrument's processors including those belonging to Keystone generation -of processors have separate hardware entity which is now responsible for the -management of the System on Chip (SoC) system. These include various system -level functions as well. - -An example of such an SoC is K2G, which contains the system control hardware -block called Power Management Micro Controller (PMMC). This hardware block is -initialized early into boot process and provides services to Operating Systems -on multiple processors including ones running Linux. - -See http://processors.wiki.ti.com/index.php/TISCI for protocol definition. - -TI-SCI controller Device Node: -============================= - -The TI-SCI node describes the Texas Instrument's System Controller entity node. -This parent node may optionally have additional children nodes which describe -specific functionality such as clocks, power domain, reset or additional -functionality as may be required for the SoC. This hierarchy also describes the -relationship between the TI-SCI parent node to the child node. - -Required properties: -------------------- -- compatible: should be "ti,k2g-sci" for TI 66AK2G SoC - should be "ti,am654-sci" for for TI AM654 SoC -- mbox-names: - "rx" - Mailbox corresponding to receive path - "tx" - Mailbox corresponding to transmit path - -- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes - property should contain a phandle to the mailbox controller device - node and an args specifier that will be the phandle to the intended - sub-mailbox child node to be used for communication. - -See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details -about the generic mailbox controller and client driver bindings. Also see -Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical -controller that is used to communicate with this System controllers. - -Optional Properties: -------------------- -- reg-names: - debug_messages - Map the Debug message region -- reg: register space corresponding to the debug_messages -- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot -- ti,host-id: Integer value corresponding to the host ID assigned by Firmware - for identification of host processing entities such as virtual - machines - -Example (K2G): -------------- - pmmc: pmmc { - compatible = "ti,k2g-sci"; - ti,host-id = <2>; - mbox-names = "rx", "tx"; - mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>, - <&msgmgr &msgmgr_proxy_pmmc_tx>; - reg-names = "debug_messages"; - reg = <0x02921800 0x800>; - }; - - -TI-SCI Client Device Node: -========================= - -Client nodes are maintained as children of the relevant TI-SCI device node. - -Example (K2G): -------------- - pmmc: pmmc { - compatible = "ti,k2g-sci"; - ... - - my_clk_node: clk_node { - ... - ... - }; - - my_pd_node: pd_node { - ... - ... - }; - }; diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml new file mode 100644 index 000000000000..34f5f877d444 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml @@ -0,0 +1,129 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI-SCI controller device node bindings + +maintainers: + - Nishanth Menon <nm@ti.com> + +description: | + Texas Instrument's processors including those belonging to Keystone generation + of processors have separate hardware entity which is now responsible for the + management of the System on Chip (SoC) system. These include various system + level functions as well. + + An example of such an SoC is K2G, which contains the system control hardware + block called Power Management Micro Controller (PMMC). This hardware block is + initialized early into boot process and provides services to Operating Systems + on multiple processors including ones running Linux. + + See http://processors.wiki.ti.com/index.php/TISCI for protocol definition. + + The TI-SCI node describes the Texas Instrument's System Controller entity node. + This parent node may optionally have additional children nodes which describe + specific functionality such as clocks, power domain, reset or additional + functionality as may be required for the SoC. This hierarchy also describes the + relationship between the TI-SCI parent node to the child node. + +properties: + $nodename: + pattern: "^system-controller@[0-9a-f]+$" + + compatible: + oneOf: + - description: System controller on TI 66AK2G SoC and other K3 SoCs + items: + - const: ti,k2g-sci + - description: System controller on TI AM654 SoC + items: + - const: ti,am654-sci + + reg-names: + description: | + Specifies the debug messages memory mapped region that is optionally + made available from TI-SCI controller. + const: debug_messages + + reg: + minItems: 1 + + mbox-names: + description: | + Specifies the mailboxes used to communicate with TI-SCI Controller + made available from TI-SCI controller. + items: + - const: rx + - const: tx + + mboxes: + minItems: 2 + + ti,system-reboot-controller: + description: Determines If system reboot can be triggered by SoC reboot + type: boolean + + ti,host-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Value corresponding to the host ID assigned by Firmware + for identification of host processing entities such as virtual machines. + + power-controller: + type: object + $ref: /schemas/soc/ti/sci-pm-domain.yaml# + + clock-controller: + type: object + $ref: /schemas/clock/ti,sci-clk.yaml# + + reset-controller: + type: object + $ref: /schemas/reset/ti,sci-reset.yaml# + +required: + - compatible + - mbox-names + - mboxes + +additionalProperties: false + +examples: + - | + pmmc: system-controller@2921800 { + compatible = "ti,k2g-sci"; + ti,system-reboot-controller; + mbox-names = "rx", "tx"; + mboxes= <&msgmgr 5 2>, + <&msgmgr 0 0>; + reg-names = "debug_messages"; + reg = <0x02921800 0x800>; + }; + + - | + dmsc: system-controller@44083000 { + compatible = "ti,k2g-sci"; + ti,host-id = <12>; + mbox-names = "rx", "tx"; + mboxes= <&secure_proxy_main 11>, + <&secure_proxy_main 13>; + reg-names = "debug_messages"; + reg = <0x44083000 0x1000>; + + k3_pds: power-controller { + compatible = "ti,sci-pm-domain"; + #power-domain-cells = <2>; + }; + + k3_clks: clock-controller { + compatible = "ti,k2g-sci-clk"; + #clock-cells = <2>; + }; + + k3_reset: reset-controller { + compatible = "ti,sci-reset"; + #reset-cells = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/scu.txt b/Documentation/devicetree/bindings/arm/scu.txt deleted file mode 100644 index 74d0a780ce51..000000000000 --- a/Documentation/devicetree/bindings/arm/scu.txt +++ /dev/null @@ -1,28 +0,0 @@ -* ARM Snoop Control Unit (SCU) - -As part of the MPCore complex, Cortex-A5 and Cortex-A9 are provided -with a Snoop Control Unit. The register range is usually 256 (0x100) -bytes. - -References: - -- Cortex-A9: see DDI0407E Cortex-A9 MPCore Technical Reference Manual - Revision r2p0 -- Cortex-A5: see DDI0434B Cortex-A5 MPCore Technical Reference Manual - Revision r0p1 -- ARM11 MPCore: see DDI0360F ARM 11 MPCore Processor Technical Reference - Manial Revision r2p0 - -- compatible : Should be: - "arm,cortex-a9-scu" - "arm,cortex-a5-scu" - "arm,arm11mp-scu" - -- reg : Specify the base address and the size of the SCU register window. - -Example: - -scu@a0410000 { - compatible = "arm,cortex-a9-scu"; - reg = <0xa0410000 0x100>; -}; diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt deleted file mode 100644 index 897eedfa2bc8..000000000000 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt +++ /dev/null @@ -1,57 +0,0 @@ -NVIDIA Tegra Activity Monitor - -The activity monitor block collects statistics about the behaviour of other -components in the system. This information can be used to derive the rate at -which the external memory needs to be clocked in order to serve all requests -from the monitored clients. - -Required properties: -- compatible: should be "nvidia,tegra<chip>-actmon" -- reg: offset and length of the register set for the device -- interrupts: standard interrupt property -- clocks: Must contain a phandle and clock specifier pair for each entry in -clock-names. See ../../clock/clock-bindings.txt for details. -- clock-names: Must include the following entries: - - actmon - - emc -- resets: Must contain an entry for each entry in reset-names. See -../../reset/reset.txt for details. -- reset-names: Must include the following entries: - - actmon -- operating-points-v2: See ../bindings/opp/opp.txt for details. -- interconnects: Should contain entries for memory clients sitting on - MC->EMC memory interconnect path. -- interconnect-names: Should include name of the interconnect path for each - interconnect entry. Consult TRM documentation for - information about available memory clients, see MEMORY - CONTROLLER section. - -For each opp entry in 'operating-points-v2' table: -- opp-supported-hw: bitfield indicating SoC speedo ID mask -- opp-peak-kBps: peak bandwidth of the memory channel - -Example: - dfs_opp_table: opp-table { - compatible = "operating-points-v2"; - - opp@12750000 { - opp-hz = /bits/ 64 <12750000>; - opp-supported-hw = <0x000F>; - opp-peak-kBps = <51000>; - }; - ... - }; - - actmon@6000c800 { - compatible = "nvidia,tegra124-actmon"; - reg = <0x0 0x6000c800 0x0 0x400>; - interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&tegra_car TEGRA124_CLK_ACTMON>, - <&tegra_car TEGRA124_CLK_EMC>; - clock-names = "actmon", "emc"; - resets = <&tegra_car 119>; - reset-names = "actmon"; - operating-points-v2 = <&dfs_opp_table>; - interconnects = <&mc TEGRA124_MC_MPCORER &emc>; - interconnect-names = "cpu"; - }; diff --git a/Documentation/devicetree/bindings/arm/ux500/boards.txt b/Documentation/devicetree/bindings/arm/ux500/boards.txt index 89408de55bfd..18d55532d31e 100644 --- a/Documentation/devicetree/bindings/arm/ux500/boards.txt +++ b/Documentation/devicetree/bindings/arm/ux500/boards.txt @@ -20,13 +20,13 @@ during retention, system won't boot without this): compatible = "ste,dbx500-backupram" scu: - see binding for arm/scu.txt + see binding for arm/arm,scu.yaml interrupt-controller: see binding for interrupt-controller/arm,gic.txt timer: - see binding for timer/arm,twd.txt + see binding for timer/arm,twd-timer.yaml clocks: see binding for clocks/ux500.txt diff --git a/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml b/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml index a75e9a8f539a..3c7a2425f3e6 100644 --- a/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml +++ b/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml @@ -20,7 +20,6 @@ properties: reg: minItems: 2 - maxItems: 3 items: - description: AHCI registers - description: SATA configuration and IPFS registers diff --git a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml index d06096a7ba4b..c060c7914cae 100644 --- a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml +++ b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml @@ -53,6 +53,17 @@ required: - reg - interrupts - clocks + - power-domains + +if: + not: + properties: + compatible: + contains: + const: renesas,sata-r8a7779 +then: + required: + - resets additionalProperties: false diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml index a27025cd3909..c4b7243ddcf2 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml @@ -51,7 +51,6 @@ properties: clocks: minItems: 2 - maxItems: 4 items: - description: High Frequency Oscillator (usually at 24MHz) - description: Low Frequency Oscillator (usually at 32kHz) @@ -60,7 +59,6 @@ properties: clock-names: minItems: 2 - maxItems: 4 items: - const: hosc - const: losc diff --git a/Documentation/devicetree/bindings/clock/gpio-mux-clock.txt b/Documentation/devicetree/bindings/clock/gpio-mux-clock.txt deleted file mode 100644 index 2be1e038ca62..000000000000 --- a/Documentation/devicetree/bindings/clock/gpio-mux-clock.txt +++ /dev/null @@ -1,19 +0,0 @@ -Binding for simple gpio clock multiplexer. - -This binding uses the common clock binding[1]. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt - -Required properties: -- compatible : shall be "gpio-mux-clock". -- clocks: list of two references to parent clocks. -- #clock-cells : from common clock binding; shall be set to 0. -- select-gpios : GPIO reference for selecting the parent clock. - -Example: - clock { - compatible = "gpio-mux-clock"; - clocks = <&parentclk1>, <&parentclk2>; - #clock-cells = <0>; - select-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; - }; diff --git a/Documentation/devicetree/bindings/clock/gpio-mux-clock.yaml b/Documentation/devicetree/bindings/clock/gpio-mux-clock.yaml new file mode 100644 index 000000000000..1e21f8b3a4ff --- /dev/null +++ b/Documentation/devicetree/bindings/clock/gpio-mux-clock.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/gpio-mux-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Simple GPIO clock multiplexer + +maintainers: + - Sergej Sawazki <ce3a@gmx.de> + +properties: + compatible: + const: gpio-mux-clock + + clocks: + items: + - description: First parent clock + - description: Second parent clock + + '#clock-cells': + const: 0 + + select-gpios: + description: GPIO reference for selecting the parent clock. + maxItems: 1 + +required: + - compatible + - clocks + - '#clock-cells' + - select-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + clock { + compatible = "gpio-mux-clock"; + clocks = <&parentclk1>, <&parentclk2>; + #clock-cells = <0>; + select-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml b/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml new file mode 100644 index 000000000000..3ceb29cec704 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/hisilicon,hi3559av100-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Hisilicon SOC Clock for HI3559AV100 + +maintainers: + - Dongjiu Geng <gengdongjiu@huawei.com> + +description: | + Hisilicon SOC clock control module which supports the clocks, resets and + power domains on HI3559AV100. + + See also: + dt-bindings/clock/hi3559av100-clock.h + +properties: + compatible: + enum: + - hisilicon,hi3559av100-clock + - hisilicon,hi3559av100-shub-clock + + reg: + minItems: 1 + maxItems: 2 + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 2 + description: | + First cell is reset request register offset. + Second cell is bit offset in reset request register. + +required: + - compatible + - reg + - '#clock-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + clock-controller@12010000 { + compatible = "hisilicon,hi3559av100-clock"; + #clock-cells = <1>; + #reset-cells = <2>; + reg = <0x0 0x12010000 0x0 0x10000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index c268debe5b8d..26ed040bc717 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -60,7 +60,6 @@ properties: maxItems: 2 idt,xtal-load-femtofarads: - $ref: /schemas/types.yaml#/definitions/uint32 minimum: 9000 maximum: 22760 description: Optional load capacitor for XTAL1 and XTAL2 @@ -84,8 +83,8 @@ patternProperties: enum: [ 1800000, 2500000, 3300000 ] idt,slew-percent: description: The Slew rate control for CMOS single-ended. - $ref: /schemas/types.yaml#/definitions/uint32 enum: [ 80, 85, 90, 100 ] + additionalProperties: false required: - compatible @@ -141,13 +140,13 @@ examples: clock-names = "xin"; OUT1 { - idt,drive-mode = <VC5_CMOSD>; - idt,voltage-microvolts = <1800000>; + idt,mode = <VC5_CMOSD>; + idt,voltage-microvolt = <1800000>; idt,slew-percent = <80>; }; OUT4 { - idt,drive-mode = <VC5_LVDS>; + idt,mode = <VC5_LVDS>; }; }; }; diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml index c65b9458c0b6..6e80dbc8b8b9 100644 --- a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml +++ b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml @@ -22,6 +22,8 @@ select: enum: - ingenic,jz4740-cgu - ingenic,jz4725b-cgu + - ingenic,jz4760-cgu + - ingenic,jz4760b-cgu - ingenic,jz4770-cgu - ingenic,jz4780-cgu - ingenic,x1000-cgu @@ -49,6 +51,8 @@ properties: - enum: - ingenic,jz4740-cgu - ingenic,jz4725b-cgu + - ingenic,jz4760-cgu + - ingenic,jz4760b-cgu - ingenic,jz4770-cgu - ingenic,jz4780-cgu - ingenic,x1000-cgu @@ -93,6 +97,8 @@ required: patternProperties: "^usb-phy@[a-f0-9]+$": allOf: [ $ref: "../phy/ingenic,phy-usb.yaml#" ] + "^mac-phy-ctrl@[a-f0-9]+$": + allOf: [ $ref: "../net/ingenic,mac.yaml#" ] additionalProperties: false diff --git a/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml new file mode 100644 index 000000000000..9f239c3960d1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,camcc-sm8250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Camera Clock & Reset Controller Binding for SM8250 + +maintainers: + - Jonathan Marek <jonathan@marek.ca> + +description: | + Qualcomm camera clock control module which supports the clocks, resets and + power domains on SM8250. + + See also dt-bindings/clock/qcom,camcc-sm8250.h + +properties: + compatible: + const: qcom,sm8250-camcc + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + + clock-names: + items: + - const: bi_tcxo + - const: sleep_clk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@ad00000 { + compatible = "qcom,sm8250-camcc"; + reg = <0x0ad00000 0x10000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&sleep_clk>; + clock-names = "bi_tcxo", "sleep_clk"; + #clock-cells = <1>; + #reset-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 0cdf53f41f84..6667261dc665 100644 --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml @@ -20,6 +20,7 @@ description: | properties: compatible: enum: + - qcom,sc8180x-dispcc - qcom,sm8150-dispcc - qcom,sm8250-dispcc diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml index eacccc88bbf6..8e2eac6cbfb9 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml @@ -46,7 +46,6 @@ properties: nvmem-cell-names: minItems: 1 - maxItems: 2 items: - const: calib - const: calib_backup diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml index 1121b3934cb9..b0d1c65aa354 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml @@ -27,7 +27,6 @@ properties: - description: Sleep clock source - description: PLL test clock source (Optional clock) minItems: 2 - maxItems: 3 clock-names: items: @@ -35,7 +34,6 @@ properties: - const: sleep_clk - const: core_bi_pll_test_se # Optional clock minItems: 2 - maxItems: 3 '#clock-cells': const: 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml new file mode 100644 index 000000000000..ab12b391effc --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-sm6125.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for SM6125 + +maintainers: + - Konrad Dybcio <konrad.dybcio@somainline.org> + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on SM6125. + + See also: + - dt-bindings/clock/qcom,gcc-sm6125.h + +properties: + compatible: + const: qcom,gcc-sm6125 + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + + clock-names: + items: + - const: bi_tcxo + - const: sleep_clk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + + protected-clocks: + description: + Protected clock specifier list as per common clock binding. + +required: + - compatible + - clocks + - clock-names + - reg + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmcc.h> + clock-controller@1400000 { + compatible = "qcom,gcc-sm6125"; + reg = <0x01400000 0x1f0000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + clock-names = "bi_tcxo", "sleep_clk"; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&sleep_clk>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml index 78f35832aa41..1122700dcc2b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml @@ -36,7 +36,6 @@ properties: - description: USB3 phy wrapper pipe clock source (Optional clock) - description: USB3 phy sec pipe clock source (Optional clock) minItems: 2 - maxItems: 13 clock-names: items: @@ -54,7 +53,6 @@ properties: - const: usb3_phy_wrapper_gcc_usb30_pipe_clk # Optional clock - const: usb3_uni_phy_sec_gcc_usb30_pipe_clk # Optional clock minItems: 2 - maxItems: 13 '#clock-cells': const: 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index 490edad25830..8453eeddf30e 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -26,9 +26,10 @@ description: | - dt-bindings/reset/qcom,gcc-msm8939.h - dt-bindings/clock/qcom,gcc-msm8660.h - dt-bindings/reset/qcom,gcc-msm8660.h - - dt-bindings/clock/qcom,gcc-msm8974.h - - dt-bindings/reset/qcom,gcc-msm8974.h + - dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) + - dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) - dt-bindings/clock/qcom,gcc-msm8994.h + - dt-bindings/clock/qcom,gcc-mdm9607.h - dt-bindings/clock/qcom,gcc-mdm9615.h - dt-bindings/reset/qcom,gcc-mdm9615.h - dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660) @@ -40,6 +41,8 @@ properties: - qcom,gcc-ipq4019 - qcom,gcc-ipq6018 - qcom,gcc-ipq8064 + - qcom,gcc-mdm9607 + - qcom,gcc-msm8226 - qcom,gcc-msm8660 - qcom,gcc-msm8916 - qcom,gcc-msm8939 diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt index b44a0622fb3a..6cf5a7ec2b4c 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -12,6 +12,7 @@ Required properties : "qcom,rpmcc-msm8660", "qcom,rpmcc" "qcom,rpmcc-apq8060", "qcom,rpmcc" + "qcom,rpmcc-msm8226", "qcom,rpmcc" "qcom,rpmcc-msm8916", "qcom,rpmcc" "qcom,rpmcc-msm8936", "qcom,rpmcc" "qcom,rpmcc-msm8974", "qcom,rpmcc" diff --git a/Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt b/Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt deleted file mode 100644 index 268ca615459e..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt +++ /dev/null @@ -1,98 +0,0 @@ -Device tree Clock bindings for Renesas EMMA Mobile EV2 - -This binding uses the common clock binding. - -* SMU -System Management Unit described in user's manual R19UH0037EJ1000_SMU. -This is not a clock provider, but clocks under SMU depend on it. - -Required properties: -- compatible: Should be "renesas,emev2-smu" -- reg: Address and Size of SMU registers - -* SMU_CLKDIV -Function block with an input mux and a divider, which corresponds to -"Serial clock generator" in fig."Clock System Overview" of the manual, -and "xxx frequency division setting register" (XXXCLKDIV) registers. -This makes internal (neither input nor output) clock that is provided -to input of xxxGCLK block. - -Required properties: -- compatible: Should be "renesas,emev2-smu-clkdiv" -- reg: Byte offset from SMU base and Bit position in the register -- clocks: Parent clocks. Input clocks as described in clock-bindings.txt -- #clock-cells: Should be <0> - -* SMU_GCLK -Clock gating node shown as "Clock stop processing block" in the -fig."Clock System Overview" of the manual. -Registers are "xxx clock gate control register" (XXXGCLKCTRL). - -Required properties: -- compatible: Should be "renesas,emev2-smu-gclk" -- reg: Byte offset from SMU base and Bit position in the register -- clocks: Input clock as described in clock-bindings.txt -- #clock-cells: Should be <0> - -Example of provider: - -usia_u0_sclkdiv: usia_u0_sclkdiv { - compatible = "renesas,emev2-smu-clkdiv"; - reg = <0x610 0>; - clocks = <&pll3_fo>, <&pll4_fo>, <&pll1_fo>, <&osc1_fo>; - #clock-cells = <0>; -}; - -usia_u0_sclk: usia_u0_sclk { - compatible = "renesas,emev2-smu-gclk"; - reg = <0x4a0 1>; - clocks = <&usia_u0_sclkdiv>; - #clock-cells = <0>; -}; - -Example of consumer: - -serial@e1020000 { - compatible = "renesas,em-uart"; - reg = <0xe1020000 0x38>; - interrupts = <0 8 0>; - clocks = <&usia_u0_sclk>; - clock-names = "sclk"; -}; - -Example of clock-tree description: - - This describes a clock path in the clock tree - c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk - -smu@e0110000 { - compatible = "renesas,emev2-smu"; - reg = <0xe0110000 0x10000>; - #address-cells = <2>; - #size-cells = <0>; - - c32ki: c32ki { - compatible = "fixed-clock"; - clock-frequency = <32768>; - #clock-cells = <0>; - }; - pll3_fo: pll3_fo { - compatible = "fixed-factor-clock"; - clocks = <&c32ki>; - clock-div = <1>; - clock-mult = <7000>; - #clock-cells = <0>; - }; - usia_u0_sclkdiv: usia_u0_sclkdiv { - compatible = "renesas,emev2-smu-clkdiv"; - reg = <0x610 0>; - clocks = <&pll3_fo>; - #clock-cells = <0>; - }; - usia_u0_sclk: usia_u0_sclk { - compatible = "renesas,emev2-smu-gclk"; - reg = <0x4a0 1>; - clocks = <&usia_u0_sclkdiv>; - #clock-cells = <0>; - }; -}; diff --git a/Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml b/Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml new file mode 100644 index 000000000000..4d9a64800481 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml @@ -0,0 +1,140 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/renesas,emev2-smu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas EMMA Mobile EV2 System Management Unit + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + - Magnus Damm <magnus.damm@gmail.com> + +description: | + The System Management Unit is described in user's manual R19UH0037EJ1000_SMU. + This is not a clock provider, but clocks under SMU depend on it. + +properties: + compatible: + const: renesas,emev2-smu + + reg: + maxItems: 1 + + '#address-cells': + const: 2 + + '#size-cells': + const: 0 + +required: + - compatible + - reg + - '#address-cells' + - '#size-cells' + +patternProperties: + ".*sclkdiv@.*": + type: object + + description: | + Function block with an input mux and a divider, which corresponds to + "Serial clock generator" in fig. "Clock System Overview" of the manual, + and "xxx frequency division setting register" (XXXCLKDIV) registers. + This makes internal (neither input nor output) clock that is provided + to input of xxxGCLK block. + + properties: + compatible: + const: renesas,emev2-smu-clkdiv + + reg: + maxItems: 1 + description: + Byte offset from SMU base and Bit position in the register. + + clocks: + minItems: 1 + maxItems: 4 + + '#clock-cells': + const: 0 + + required: + - compatible + - reg + - clocks + - '#clock-cells' + + additionalProperties: false + + ".*sclk@.*": + type: object + + description: | + Clock gating node shown as "Clock stop processing block" in the + fig. "Clock System Overview" of the manual. + Registers are "xxx clock gate control register" (XXXGCLKCTRL). + + properties: + compatible: + const: renesas,emev2-smu-gclk + + reg: + maxItems: 1 + description: + Byte offset from SMU base and Bit position in the register. + + clocks: + maxItems: 1 + + '#clock-cells': + const: 0 + + required: + - compatible + - reg + - clocks + - '#clock-cells' + + additionalProperties: false + +additionalProperties: true + +examples: + - | + // Example of clock-tree description: + // + // This describes a clock path in the clock tree + // c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk + clocks@e0110000 { + compatible = "renesas,emev2-smu"; + reg = <0xe0110000 0x10000>; + #address-cells = <2>; + #size-cells = <0>; + + c32ki: c32ki { + compatible = "fixed-clock"; + clock-frequency = <32768>; + #clock-cells = <0>; + }; + pll3_fo: pll3_fo { + compatible = "fixed-factor-clock"; + clocks = <&c32ki>; + clock-div = <1>; + clock-mult = <7000>; + #clock-cells = <0>; + }; + usia_u0_sclkdiv: usia_u0_sclkdiv@610,0 { + compatible = "renesas,emev2-smu-clkdiv"; + reg = <0x610 0>; + clocks = <&pll3_fo>; + #clock-cells = <0>; + }; + usia_u0_sclk: usia_u0_sclk@4a0,1 { + compatible = "renesas,emev2-smu-gclk"; + reg = <0x4a0 1>; + clocks = <&usia_u0_sclkdiv>; + #clock-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt deleted file mode 100644 index aed713cf0831..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt +++ /dev/null @@ -1,46 +0,0 @@ -* Renesas R9A06G032 SYSCTRL - -Required Properties: - - - compatible: Must be: - - "renesas,r9a06g032-sysctrl" - - reg: Base address and length of the SYSCTRL IO block. - - #clock-cells: Must be 1 - - clocks: References to the parent clocks: - - external 40mhz crystal. - - external (optional) 32.768khz - - external (optional) jtag input - - external (optional) RGMII_REFCLK - - clock-names: Must be: - clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext"; - - #power-domain-cells: Must be 0 - -Examples --------- - - - SYSCTRL node: - - sysctrl: system-controller@4000c000 { - compatible = "renesas,r9a06g032-sysctrl"; - reg = <0x4000c000 0x1000>; - #clock-cells = <1>; - - clocks = <&ext_mclk>, <&ext_rtc_clk>, - <&ext_jtag_clk>, <&ext_rgmii_ref>; - clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext"; - #power-domain-cells = <0>; - }; - - - Other nodes can use the clocks provided by SYSCTRL as in: - - #include <dt-bindings/clock/r9a06g032-sysctrl.h> - uart0: serial@40060000 { - compatible = "snps,dw-apb-uart"; - reg = <0x40060000 0x400>; - interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - reg-io-width = <4>; - clocks = <&sysctrl R9A06G032_CLK_UART0>, <&sysctrl R9A06G032_HCLK_UART0>; - clock-names = "baudclk", "apb_pclk"; - power-domains = <&sysctrl>; - }; diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml new file mode 100644 index 000000000000..25dbb0fac065 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/renesas,r9a06g032-sysctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/N1D (R9A06G032) System Controller + +maintainers: + - Gareth Williams <gareth.williams.jx@renesas.com> + - Geert Uytterhoeven <geert+renesas@glider.be> + +properties: + compatible: + const: renesas,r9a06g032-sysctrl + + reg: + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: External 40 MHz crystal + - description: Optional external 32.768 kHz crystal + - description: Optional external JTAG input + - description: Optional external RGMII_REFCLK + + clock-names: + minItems: 1 + items: + - const: mclk + - const: rtc + - const: jtag + - const: rgmii_ref_ext + + '#clock-cells': + const: 1 + + '#power-domain-cells': + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + sysctrl: system-controller@4000c000 { + compatible = "renesas,r9a06g032-sysctrl"; + reg = <0x4000c000 0x1000>; + clocks = <&ext_mclk>, <&ext_rtc_clk>, <&ext_jtag_clk>, + <&ext_rgmii_ref>; + clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext"; + #clock-cells = <1>; + #power-domain-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml new file mode 100644 index 000000000000..30b2e3d0d25d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Renesas RZ/G2L Clock Pulse Generator / Module Standby Mode + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: | + On Renesas RZ/G2L SoC, the CPG (Clock Pulse Generator) and Module + Standby Mode share the same register block. + + They provide the following functionalities: + - The CPG block generates various core clocks, + - The Module Standby Mode block provides two functions: + 1. Module Standby, providing a Clock Domain to control the clock supply + to individual SoC devices, + 2. Reset Control, to perform a software reset of individual SoC devices. + +properties: + compatible: + const: renesas,r9a07g044-cpg # RZ/G2{L,LC} + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + description: + Clock source to CPG can be either from external clock input (EXCLK) or + crystal oscillator (XIN/XOUT). + const: extal + + '#clock-cells': + description: | + - For CPG core clocks, the two clock specifier cells must be "CPG_CORE" + and a core clock reference, as defined in + <dt-bindings/clock/r9a07g044-cpg.h> + - For module clocks, the two clock specifier cells must be "CPG_MOD" and + a module number, as defined in the <dt-bindings/clock/r9a07g044-cpg.h>. + const: 2 + + '#power-domain-cells': + description: + SoC devices that are part of the CPG/Module Standby Mode Clock Domain and + can be power-managed through Module Standby should refer to the CPG device + node in their "power-domains" property, as documented by the generic PM + Domain bindings in Documentation/devicetree/bindings/power/power-domain.yaml. + const: 0 + + '#reset-cells': + description: + The single reset specifier cell must be the module number, as defined in + the <dt-bindings/clock/r9a07g044-cpg.h>. + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#power-domain-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + - | + cpg: clock-controller@11010000 { + compatible = "renesas,r9a07g044-cpg"; + reg = <0x11010000 0x10000>; + clocks = <&extal_clk>; + clock-names = "extal"; + #clock-cells = <2>; + #power-domain-cells = <0>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/silabs,si5341.txt b/Documentation/devicetree/bindings/clock/silabs,si5341.txt index 504cce3abe46..ce55aba0ce22 100644 --- a/Documentation/devicetree/bindings/clock/silabs,si5341.txt +++ b/Documentation/devicetree/bindings/clock/silabs,si5341.txt @@ -24,9 +24,8 @@ it. The device type, speed grade and revision are determined runtime by probing. -The driver currently only supports XTAL input mode, and does not support any -fancy input configurations. They can still be programmed into the chip and -the driver will leave them "as is". +The driver currently does not support any fancy input configurations. They can +still be programmed into the chip and the driver will leave them "as is". ==I2C device node== @@ -45,9 +44,9 @@ Required properties: corresponding to inputs. Use a fixed clock for the "xtal" input. At least one must be present. - clock-names: One of: "xtal", "in0", "in1", "in2" -- vdd-supply: Regulator node for VDD Optional properties: +- vdd-supply: Regulator node for VDD - vdda-supply: Regulator node for VDDA - vdds-supply: Regulator node for VDDS - silabs,pll-m-num, silabs,pll-m-den: Numerator and denominator for PLL @@ -60,7 +59,14 @@ Optional properties: be initialized, and always performs the soft-reset routine. Since this will temporarily stop all output clocks, don't do this if the chip is generating the CPU clock for example. +- silabs,xaxb-ext-clk: When present, indicates that the XA/XB pins are used + in EXTCLK (external reference clock) rather than XTAL (crystal) mode. - interrupts: Interrupt for INTRb pin. +- silabs,iovdd-33: When present, indicates that the I2C lines are using 3.3V + rather than 1.8V thresholds. +- vddoX-supply (where X is an output index): Regulator node for VDDO for the + specified output. The driver selects the output VDD_SEL setting based on this + voltage. - #address-cells: shall be set to 1. - #size-cells: shall be set to 0. @@ -77,8 +83,6 @@ Required child node properties: - reg: number of clock output. Optional child node properties: -- vdd-supply: Regulator node for VDD for this output. The driver selects default - values for common-mode and amplitude based on the voltage. - silabs,format: Output format, one of: 1 = differential (defaults to LVDS levels) 2 = low-power (defaults to HCSL levels) diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml index 4069e09cb62d..47e1ab08c95d 100644 --- a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml +++ b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml @@ -40,7 +40,6 @@ properties: clock-names: minItems: 1 - maxItems: 4 items: - const: ext-26m - const: ext-32k diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml index 4e385508f516..8b1ecb2ecdd5 100644 --- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml +++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml @@ -54,7 +54,9 @@ properties: compatible: items: - - const: st,stm32mp1-rcc + - enum: + - st,stm32mp1-rcc-secure + - st,stm32mp1-rcc - const: syscon reg: @@ -71,7 +73,7 @@ additionalProperties: false examples: - | rcc: rcc@50000000 { - compatible = "st,stm32mp1-rcc", "syscon"; + compatible = "st,stm32mp1-rcc-secure", "syscon"; reg = <0x50000000 0x1000>; #clock-cells = <1>; #reset-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt index f207053e0550..d0fa1e02d06d 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt @@ -10,7 +10,10 @@ Required properties: - compatible : shall be: "st,clkgen-pll0" + "st,clkgen-pll0-a0" + "st,clkgen-pll0-c0" "st,clkgen-pll1" + "st,clkgen-pll1-c0" "st,stih407-clkgen-plla9" "st,stih418-clkgen-plla9" diff --git a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt index 7ff77fc57dff..55a18939bddd 100644 --- a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt +++ b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt @@ -64,6 +64,16 @@ Required properties: audio use case) "st,flexgen-video", "st,flexgen" (enable clock propagation on parent and activate synchronous mode) + "st,flexgen-stih407-a0" + "st,flexgen-stih410-a0" + "st,flexgen-stih407-c0" + "st,flexgen-stih410-c0" + "st,flexgen-stih418-c0" + "st,flexgen-stih407-d0" + "st,flexgen-stih410-d0" + "st,flexgen-stih407-d2" + "st,flexgen-stih418-d2" + "st,flexgen-stih407-d3" - #clock-cells : from common clock binding; shall be set to 1 (multiple clock outputs). diff --git a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt index d93d49342e60..c4ba2adb0b4f 100644 --- a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt +++ b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt @@ -12,6 +12,9 @@ This binding uses the common clock binding[1]. Required properties: - compatible : shall be: "st,quadfs" + "st,quadfs-d0" + "st,quadfs-d2" + "st,quadfs-d3" "st,quadfs-pll" diff --git a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml index 6b419a9878f3..9b537bc876b5 100644 --- a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml +++ b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml @@ -12,7 +12,9 @@ maintainers: properties: compatible: items: - - const: ti,am654-ehrpwm-tbclk + - enum: + - ti,am654-ehrpwm-tbclk + - ti,am64-epwm-tbclk - const: syscon "#clock-cells": diff --git a/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml b/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml new file mode 100644 index 000000000000..bd8173848253 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml @@ -0,0 +1,209 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/ti,lmk04832.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for the Texas Instruments LMK04832 + +maintainers: + - Liam Beguin <liambeguin@gmail.com> + +description: | + Devicetree binding for the LMK04832, a clock conditioner with JEDEC JESD204B + support. The LMK04832 is pin compatible with the LMK0482x family. + + Link to datasheet, https://www.ti.com/lit/ds/symlink/lmk04832.pdf + +properties: + compatible: + enum: + - ti,lmk04832 + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + '#clock-cells': + const: 1 + + spi-max-frequency: + maximum: 5000000 + + clocks: + items: + - description: PLL2 reference clock. + + clock-names: + items: + - const: oscin + + reset-gpios: + maxItems: 1 + + ti,spi-4wire-rdbk: + description: | + Select SPI 4wire readback pin configuration. + Available readback pins are, + CLKin_SEL0 0 + CLKin_SEL1 1 + RESET 2 + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + default: 1 + + ti,vco-hz: + description: Optional to set VCO frequency of the PLL in Hertz. + + ti,sysref-ddly: + description: SYSREF digital delay value. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 8 + maximum: 8191 + default: 8 + + ti,sysref-mux: + description: | + SYSREF Mux configuration. + Available options are, + Normal SYNC 0 + Re-clocked 1 + SYSREF Pulser 2 + SYSREF Continuous 3 + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 3 + + ti,sync-mode: + description: SYNC pin configuration. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + default: 1 + + ti,sysref-pulse-count: + description: + Number of SYSREF pulses to send when SYSREF is not in continuous mode. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8] + default: 4 + +patternProperties: + "@[0-9a-d]+$": + type: object + description: + Child nodes used to configure output clocks. + + properties: + reg: + description: + clock output identifier. + minimum: 0 + maximum: 13 + + ti,clkout-fmt: + description: + Clock output format. + Available options are, + Powerdown 0x00 + LVDS 0x01 + HSDS 6 mA 0x02 + HSDS 8 mA 0x03 + LVPECL 1600 mV 0x04 + LVPECL 2000 mV 0x05 + LCPECL 0x06 + CML 16 mA 0x07 + CML 24 mA 0x08 + CML 32 mA 0x09 + CMOS (Off/Inverted) 0x0a + CMOS (Normal/Off) 0x0b + CMOS (Inverted/Inverted) 0x0c + CMOS (Inverted/Normal) 0x0d + CMOS (Normal/Inverted) 0x0e + CMOS (Normal/Normal) 0x0f + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + + ti,clkout-sysref: + description: + Select SYSREF clock path for output clock. + type: boolean + + required: + - reg + + additionalProperties: false + +required: + - compatible + - reg + - '#clock-cells' + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + clocks { + lmk04832_oscin: oscin { + compatible = "fixed-clock"; + + #clock-cells = <0>; + clock-frequency = <122880000>; + clock-output-names = "lmk04832-oscin"; + }; + }; + + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + lmk04832: clock-controller@0 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0>; + + compatible = "ti,lmk04832"; + spi-max-frequency = <781250>; + + reset-gpios = <&gpio_lmk 0 0 0>; + + #clock-cells = <1>; + clocks = <&lmk04832_oscin>; + clock-names = "oscin"; + + ti,spi-4wire-rdbk = <0>; + ti,vco-hz = <2457600000>; + + assigned-clocks = + <&lmk04832 0>, <&lmk04832 1>, + <&lmk04832 2>, <&lmk04832 3>, + <&lmk04832 4>, + <&lmk04832 6>, <&lmk04832 7>, + <&lmk04832 10>, <&lmk04832 11>; + assigned-clock-rates = + <122880000>, <384000>, + <122880000>, <384000>, + <122880000>, + <153600000>, <384000>, + <614400000>, <384000>; + + clkout0@0 { + reg = <0>; + ti,clkout-fmt = <0x01>; // LVDS + }; + + clkout1@1 { + reg = <1>; + ti,clkout-fmt = <0x01>; // LVDS + ti,clkout-sysref; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt deleted file mode 100644 index 4e59dc6b1778..000000000000 --- a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt +++ /dev/null @@ -1,36 +0,0 @@ -Texas Instruments TI-SCI Clocks -=============================== - -All clocks on Texas Instruments' SoCs that contain a System Controller, -are only controlled by this entity. Communication between a host processor -running an OS and the System Controller happens through a protocol known -as TI-SCI[1]. This clock implementation plugs into the common clock -framework and makes use of the TI-SCI protocol on clock API requests. - -[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt - -Required properties: -------------------- -- compatible: Must be "ti,k2g-sci-clk" -- #clock-cells: Shall be 2. - In clock consumers, this cell represents the device ID and clock ID - exposed by the PM firmware. The list of valid values for the device IDs - and clocks IDs for 66AK2G SoC are documented at - http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data - -Examples: --------- - -pmmc: pmmc { - compatible = "ti,k2g-sci"; - - k2g_clks: clocks { - compatible = "ti,k2g-sci-clk"; - #clock-cells = <2>; - }; -}; - -uart0: serial@2530c00 { - compatible = "ns16550a"; - clocks = <&k2g_clks 0x2c 0>; -}; diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml new file mode 100644 index 000000000000..0e370289a053 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI-SCI clock controller node bindings + +maintainers: + - Nishanth Menon <nm@ti.com> + +description: | + Some TI SoCs contain a system controller (like the Power Management Micro + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling + the state of the various hardware modules present on the SoC. Communication + between the host processor running an OS and the system controller happens + through a protocol called TI System Control Interface (TI-SCI protocol). + + This clock controller node uses the TI SCI protocol to perform various clock + management of various hardware modules (devices) present on the SoC. This + node must be a child node of the associated TI-SCI system controller node. + +properties: + $nodename: + pattern: "^clock-controller$" + + compatible: + const: ti,k2g-sci-clk + + "#clock-cells": + const: 2 + description: + The two cells represent values that the TI-SCI controller defines. + + The first cell should contain the device ID. + + The second cell should contain the clock ID. + + Please see http://processors.wiki.ti.com/index.php/TISCI for + protocol documentation for the values to be used for different devices. + +additionalProperties: false + +examples: + - | + k3_clks: clock-controller { + compatible = "ti,k2g-sci-clk"; + #clock-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt index df57009ff8e7..37a7cb6ad07d 100644 --- a/Documentation/devicetree/bindings/clock/ti/dpll.txt +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -42,6 +42,11 @@ Required properties: "idlest" - contains the idle status register base address "mult-div1" - contains the multiplier / divider register base address "autoidle" - contains the autoidle register base address (optional) + "ssc-deltam" - DPLL supports spread spectrum clocking (SSC), contains + the frequency spreading register base address (optional) + "ssc-modfreq" - DPLL supports spread spectrum clocking (SSC), contains + the modulation frequency register base address + (optional) ti,am3-* dpll types do not have autoidle register ti,omap2-* dpll type does not support idlest / autoidle registers @@ -51,6 +56,14 @@ Optional properties: - ti,low-power-stop : DPLL supports low power stop mode, gating output - ti,low-power-bypass : DPLL output matches rate of parent bypass clock - ti,lock : DPLL locks in programmed rate + - ti,min-div : the minimum divisor to start from to round the DPLL + target rate + - ti,ssc-deltam : DPLL supports spread spectrum clocking, frequency + spreading in permille (10th of a percent) + - ti,ssc-modfreq-hz : DPLL supports spread spectrum clocking, spread + spectrum modulation frequency + - ti,ssc-downspread : DPLL supports spread spectrum clocking, boolean + to enable the downspread feature Examples: dpll_core_ck: dpll_core_ck@44e00490 { @@ -83,3 +96,10 @@ Examples: clocks = <&sys_ck>, <&sys_ck>; reg = <0x0500>, <0x0540>; }; + + dpll_disp_ck: dpll_disp_ck { + #clock-cells = <0>; + compatible = "ti,am3-dpll-no-gate-clock"; + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; + reg = <0x0498>, <0x0448>, <0x0454>, <0x044c>, <0x0450>; + }; diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 32509b98142e..92b49bc37939 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -149,6 +149,17 @@ properties: maxItems: 6 $ref: /schemas/types.yaml#/definitions/uint32-array + sink-vdos-v1: + description: An array of u32 with each entry, a Vendor Defined Message Object (VDO), + providing additional information corresponding to the product, the detailed bit + definitions and the order of each VDO can be found in + "USB Power Delivery Specification Revision 2.0, Version 1.3" chapter 6.4.4.3.1 Discover + Identity. User can specify the VDO array via VDO_IDH/_CERT/_PRODUCT/_CABLE/_AMA defined in + dt-bindings/usb/pd.h. + minItems: 3 + maxItems: 6 + $ref: /schemas/types.yaml#/definitions/uint32-array + op-sink-microwatt: description: Sink required operating power in microwatt, if source can't offer the power, Capability Mismatch is set. Required for power sink and @@ -207,6 +218,10 @@ properties: SNK_READY for non-pd link. type: boolean +dependencies: + sink-vdos-v1: [ 'sink-vdos' ] + sink-vdos: [ 'sink-vdos-v1' ] + required: - compatible diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml index 6ab07eba7778..00648f9d9278 100644 --- a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml +++ b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml @@ -30,7 +30,6 @@ properties: - description: Module clock - description: MBus clock minItems: 2 - maxItems: 3 clock-names: items: @@ -38,7 +37,6 @@ properties: - const: mod - const: ram minItems: 2 - maxItems: 3 resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml b/Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml new file mode 100644 index 000000000000..9c97874a6dbd --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/arm,cryptocell.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm TrustZone CryptoCell cryptographic engine + +maintainers: + - Gilad Ben-Yossef <gilad@benyossef.com> + +properties: + compatible: + enum: + - arm,cryptocell-713-ree + - arm,cryptocell-703-ree + - arm,cryptocell-712-ree + - arm,cryptocell-710-ree + - arm,cryptocell-630p-ree + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dma-coherent: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + arm_cc712: crypto@80000000 { + compatible = "arm,cryptocell-712-ree"; + reg = <0x80000000 0x10000>; + interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt deleted file mode 100644 index 6130e6eb4af8..000000000000 --- a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt +++ /dev/null @@ -1,25 +0,0 @@ -Arm TrustZone CryptoCell cryptographic engine - -Required properties: -- compatible: Should be one of - - "arm,cryptocell-713-ree" - "arm,cryptocell-703-ree" - "arm,cryptocell-712-ree" - "arm,cryptocell-710-ree" - "arm,cryptocell-630p-ree" -- reg: Base physical address of the engine and length of memory mapped region. -- interrupts: Interrupt number for the device. - -Optional properties: -- clocks: Reference to the crypto engine clock. -- dma-coherent: Present if dma operations are coherent. - -Examples: - - arm_cc712: crypto@80000000 { - compatible = "arm,cryptocell-712-ree"; - interrupt-parent = <&intc>; - interrupts = < 0 30 4 >; - reg = < 0x80000000 0x10000 >; - - }; diff --git a/Documentation/devicetree/bindings/crypto/cortina,sl3516-crypto.yaml b/Documentation/devicetree/bindings/crypto/cortina,sl3516-crypto.yaml new file mode 100644 index 000000000000..b633b8d0e6f0 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/cortina,sl3516-crypto.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/cortina,sl3516-crypto.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SL3516 cryptographic offloader driver + +maintainers: + - Corentin Labbe <clabbe@baylibre.com> + +properties: + compatible: + enum: + - cortina,sl3516-crypto + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/cortina,gemini-clock.h> + #include <dt-bindings/reset/cortina,gemini-reset.h> + + crypto@62000000 { + compatible = "cortina,sl3516-crypto"; + reg = <0x62000000 0x10000>; + interrupts = <7 IRQ_TYPE_EDGE_RISING>; + resets = <&syscon GEMINI_RESET_SECURITY>; + clocks = <&syscon GEMINI_CLK_GATE_SECURITY>; + }; diff --git a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml index a30bf38a4a49..99be01539fcd 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml +++ b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml @@ -27,7 +27,6 @@ properties: - description: MXS DCP DCP interrupt - description: MXS DCP secure interrupt minItems: 2 - maxItems: 3 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml new file mode 100644 index 000000000000..9c53c27bd20a --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2018 Linaro Ltd. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/crypto/intel,ixp4xx-crypto.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Intel IXP4xx cryptographic engine + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + The Intel IXP4xx cryptographic engine makes use of the IXP4xx NPE + (Network Processing Engine). Since it is not a device on its own + it is defined as a subnode of the NPE, if crypto support is + available on the platform. + +properties: + compatible: + const: intel,ixp4xx-crypto + + intel,npe-handle: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + description: phandle to the NPE this crypto engine is using, the cell + describing the NPE instance to be used. + + queue-rx: + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + description: phandle to the RX queue on the NPE, the cell describing + the queue instance to be used. + + queue-txready: + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + description: phandle to the TX READY queue on the NPE, the cell describing + the queue instance to be used. + +required: + - compatible + - intel,npe-handle + - queue-rx + - queue-txready + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml b/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml new file mode 100644 index 000000000000..e3379d106728 --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/devfreq/nvidia,tegra30-actmon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra30 Activity Monitor + +maintainers: + - Dmitry Osipenko <digetx@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +description: | + The activity monitor block collects statistics about the behaviour of other + components in the system. This information can be used to derive the rate at + which the external memory needs to be clocked in order to serve all requests + from the monitored clients. + +properties: + compatible: + enum: + - nvidia,tegra30-actmon + - nvidia,tegra114-actmon + - nvidia,tegra124-actmon + - nvidia,tegra210-actmon + + reg: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: actmon + - const: emc + + resets: + maxItems: 1 + + reset-names: + items: + - const: actmon + + interrupts: + maxItems: 1 + + interconnects: + minItems: 1 + maxItems: 12 + + interconnect-names: + minItems: 1 + maxItems: 12 + description: + Should include name of the interconnect path for each interconnect + entry. Consult TRM documentation for information about available + memory clients, see MEMORY CONTROLLER and ACTIVITY MONITOR sections. + + operating-points-v2: + description: + Should contain freqs and voltages and opp-supported-hw property, which + is a bitfield indicating SoC speedo ID mask. + + "#cooling-cells": + const: 2 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - interrupts + - interconnects + - interconnect-names + - operating-points-v2 + - "#cooling-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/memory/tegra30-mc.h> + + mc: memory-controller@7000f000 { + compatible = "nvidia,tegra30-mc"; + reg = <0x7000f000 0x400>; + clocks = <&clk 32>; + clock-names = "mc"; + + interrupts = <0 77 4>; + + #iommu-cells = <1>; + #reset-cells = <1>; + #interconnect-cells = <1>; + }; + + emc: external-memory-controller@7000f400 { + compatible = "nvidia,tegra30-emc"; + reg = <0x7000f400 0x400>; + interrupts = <0 78 4>; + clocks = <&clk 57>; + + nvidia,memory-controller = <&mc>; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; + + #interconnect-cells = <0>; + }; + + actmon@6000c800 { + compatible = "nvidia,tegra30-actmon"; + reg = <0x6000c800 0x400>; + interrupts = <0 45 4>; + clocks = <&clk 119>, <&clk 57>; + clock-names = "actmon", "emc"; + resets = <&rst 119>; + reset-names = "actmon"; + operating-points-v2 = <&dvfs_opp_table>; + interconnects = <&mc TEGRA30_MC_MPCORER &emc>; + interconnect-names = "cpu-read"; + #cooling-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml index 12a7df0e38b2..3d8ea3c2d8dd 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml @@ -26,14 +26,12 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: Display Backend registers - description: SAT registers reg-names: minItems: 1 - maxItems: 2 items: - const: be - const: sat @@ -43,7 +41,6 @@ properties: clocks: minItems: 3 - maxItems: 4 items: - description: The backend interface clock - description: The backend module clock @@ -52,7 +49,6 @@ properties: clock-names: minItems: 3 - maxItems: 4 items: - const: ahb - const: mod @@ -61,14 +57,12 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: The Backend reset line - description: The SAT reset line reset-names: minItems: 1 - maxItems: 2 items: - const: be - const: sat diff --git a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml index a738d7c12a97..bf0bdf54e5f9 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml @@ -24,7 +24,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Bus Clock - description: Module Clock diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml index 907fb47cc84a..5d42d36608d9 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml @@ -46,7 +46,6 @@ properties: clocks: minItems: 3 - maxItems: 6 items: - description: Bus Clock - description: Register Clock @@ -57,7 +56,6 @@ properties: clock-names: minItems: 3 - maxItems: 6 items: - const: iahb - const: isfr @@ -68,14 +66,12 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: HDMI Controller Reset - description: HDCP Reset reset-names: minItems: 1 - maxItems: 2 items: - const: ctrl - const: hdcp diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml index 501cec16168c..a97366aaf924 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml @@ -27,7 +27,6 @@ properties: clocks: minItems: 2 - maxItems: 4 items: - description: Bus Clock - description: Module Clock @@ -36,7 +35,6 @@ properties: clock-names: minItems: 2 - maxItems: 4 items: - const: bus - const: mod diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml index ec21e8bf2767..61ef7b337218 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml @@ -48,7 +48,6 @@ properties: clocks: minItems: 2 - maxItems: 6 items: - description: The TCON TOP interface clock - description: The TCON TOP TV0 clock @@ -59,7 +58,6 @@ properties: clock-names: minItems: 2 - maxItems: 6 items: - const: bus - const: tcon-tv0 diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml index d900cc57b4ec..9b24081a0dbd 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml @@ -11,7 +11,9 @@ maintainers: properties: compatible: - const: brcm,bcm2835-vec + enum: + - brcm,bcm2711-vec + - brcm,bcm2835-vec reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt deleted file mode 100644 index 659523f538bf..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt +++ /dev/null @@ -1,143 +0,0 @@ -Analog Devices ADV7511(W)/13/33/35 HDMI Encoders ------------------------------------------------- - -The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video -transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space -conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for input -pixels, while the others support RGB interface. - -Required properties: - -- compatible: Should be one of: - "adi,adv7511" - "adi,adv7511w" - "adi,adv7513" - "adi,adv7533" - "adi,adv7535" - -- reg: I2C slave addresses - The ADV7511 internal registers are split into four pages exposed through - different I2C addresses, creating four register maps. Each map has it own - I2C address and acts as a standard slave device on the I2C bus. The main - address is mandatory, others are optional and revert to defaults if not - specified. - - -The ADV7511 supports a large number of input data formats that differ by their -color depth, color format, clock mode, bit justification and random -arrangement of components on the data bus. The combination of the following -properties describe the input and map directly to the video input tables of the -ADV7511 datasheet that document all the supported combinations. - -- adi,input-depth: Number of bits per color component at the input (8, 10 or - 12). -- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or - "yuv444". -- adi,input-clock: The input clock type, one of "1x" (one clock cycle per - pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel, - data driven on both edges). - -The following input format properties are required except in "rgb 1x" and -"yuv444 1x" modes, in which case they must not be specified. - -- adi,input-style: The input components arrangement variant (1, 2 or 3), as - listed in the input format tables in the datasheet. -- adi,input-justification: The input bit justification ("left", "evenly", - "right"). - -- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip. -- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip. -- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip. -- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V - on the chip. -- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is - needed only for ADV7511. - -The following properties are required for ADV7533 and ADV7535: - -- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should - be one of 1, 2, 3 or 4. -- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip. -- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip. -- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be - either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535. - -Optional properties: - -- interrupts: Specifier for the ADV7511 interrupt -- pd-gpios: Specifier for the GPIO connected to the power down signal - -- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps - (-1200 ps .. 1600 ps). Defaults to no delay. -- adi,embedded-sync: The input uses synchronization signals embedded in the - data stream (similar to BT.656). Defaults to separate H/V synchronization - signals. -- adi,disable-timing-generator: Only for ADV7533 and ADV7535. Disables the - internal timing generator. The chip will rely on the sync signals in the - DSI data lanes, rather than generate its own timings for HDMI output. -- clocks: from common clock binding: reference to the CEC clock. -- clock-names: from common clock binding: must be "cec". -- reg-names : Names of maps with programmable addresses. - It can contain any map needing a non-default address. - Possible maps names are : "main", "edid", "cec", "packet" - -Required nodes: - -The ADV7511 has two video ports. Their connections are modelled using the OF -graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the - remote endpoint phandle should be a reference to a valid mipi_dsi_host device - node. -- Video port 1 for the HDMI output -- Audio port 2 for the HDMI audio input - - -Example -------- - - adv7511w: hdmi@39 { - compatible = "adi,adv7511w"; - /* - * The EDID page will be accessible on address 0x66 on the I2C - * bus. All other maps continue to use their default addresses. - */ - reg = <0x39>, <0x66>; - reg-names = "main", "edid"; - interrupt-parent = <&gpio3>; - interrupts = <29 IRQ_TYPE_EDGE_FALLING>; - clocks = <&cec_clock>; - clock-names = "cec"; - - adi,input-depth = <8>; - adi,input-colorspace = "rgb"; - adi,input-clock = "1x"; - adi,input-style = <1>; - adi,input-justification = "evenly"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - adv7511w_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; - - port@1 { - reg = <1>; - adv7511_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; - }; - - port@2 { - reg = <2>; - codec_endpoint: endpoint { - remote-endpoint = <&i2s0_cpu_endpoint>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml new file mode 100644 index 000000000000..d3dd7a79b909 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml @@ -0,0 +1,240 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADV7511/11W/13 HDMI Encoders + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: | + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color + space conversion, S/PDIF, CEC and HDCP. The transmitter input is + parallel RGB or YUV data. + +properties: + compatible: + enum: + - adi,adv7511 + - adi,adv7511w + - adi,adv7513 + + reg: + description: | + I2C slave addresses. + + The ADV7511/11W/13 internal registers are split into four pages + exposed through different I2C addresses, creating four register + maps. Each map has it own I2C address and acts as a standard slave + device on the I2C bus. The main address is mandatory, others are + optional and revert to defaults if not specified. + minItems: 1 + maxItems: 4 + + reg-names: + description: + Names of maps with programmable addresses. It can contain any map + needing a non-default address. + minItems: 1 + items: + - const: main + - const: edid + - const: cec + - const: packet + + clocks: + description: Reference to the CEC clock. + maxItems: 1 + + clock-names: + const: cec + + interrupts: + maxItems: 1 + + pd-gpios: + description: GPIO connected to the power down signal. + maxItems: 1 + + avdd-supply: + description: A 1.8V supply that powers up the AVDD pin. + + dvdd-supply: + description: A 1.8V supply that powers up the DVDD pin. + + pvdd-supply: + description: A 1.8V supply that powers up the PVDD pin. + + dvdd-3v-supply: + description: A 3.3V supply that powers up the DVDD_3V pin. + + bgvdd-supply: + description: A 1.8V supply that powers up the BGVDD pin. + + adi,input-depth: + description: Number of bits per color component at the input. + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 8, 10, 12 ] + + adi,input-colorspace: + description: Input color space. + enum: [ rgb, yuv422, yuv444 ] + + adi,input-clock: + description: | + Input clock type. + "1x": one clock cycle per pixel + "2x": two clock cycles per pixel + "dd": one clock cycle per pixel, data driven on both edges + enum: [ 1x, 2x, dd ] + + adi,clock-delay: + description: + Video data clock delay relative to the pixel clock, in ps + (-1200ps .. 1600 ps). + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + + adi,embedded-sync: + description: + If defined, the input uses synchronization signals embedded in the + data stream (similar to BT.656). + type: boolean + + adi,input-style: + description: + Input components arrangement variant as listed in the input + format tables in the datasheet. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2, 3 ] + + adi,input-justification: + description: Input bit justification. + enum: [ left, evenly, right ] + + ports: + description: + The ADV7511(W)/13 has two video ports and one audio port. This node + models their connections as documented in + Documentation/devicetree/bindings/media/video-interfaces.txt + Documentation/devicetree/bindings/graph.txt + type: object + properties: + port@0: + description: Video port for the RGB or YUV input. + type: object + + port@1: + description: Video port for the HDMI output. + type: object + + port@2: + description: Audio port for the HDMI output. + type: object + +# adi,input-colorspace and adi,input-clock are required except in +# "rgb 1x" and "yuv444 1x" modes, in which case they must not be +# specified. +if: + not: + properties: + adi,input-colorspace: + contains: + enum: [ rgb, yuv444 ] + adi,input-clock: + contains: + const: 1x + +then: + required: + - adi,input-style + - adi,input-justification + +else: + properties: + adi,input-style: false + adi,input-justification: false + + +required: + - compatible + - reg + - ports + - adi,input-depth + - adi,input-colorspace + - adi,input-clock + - avdd-supply + - dvdd-supply + - pvdd-supply + - dvdd-3v-supply + - bgvdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c@e6500000 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0 0xe6500000>; + + adv7511w: hdmi@39 { + compatible = "adi,adv7511w"; + /* + * The EDID page will be accessible on address 0x66 on the I2C + * bus. All other maps continue to use their default addresses. + */ + reg = <0x39>, <0x66>; + reg-names = "main", "edid"; + interrupt-parent = <&gpio3>; + interrupts = <29 IRQ_TYPE_EDGE_FALLING>; + clocks = <&cec_clock>; + clock-names = "cec"; + avdd-supply = <&v1v8>; + dvdd-supply = <&v1v8>; + pvdd-supply = <&v1v8>; + dvdd-3v-supply = <&v3v3>; + bgvdd-supply = <&v1v8>; + + adi,input-depth = <8>; + adi,input-colorspace = "yuv422"; + adi,input-clock = "1x"; + + adi,input-style = <3>; + adi,input-justification = "right"; + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + adv7511w_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + adv7511_out: endpoint { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + + port@2 { + reg = <2>; + codec_endpoint: endpoint { + remote-endpoint = <&i2s0_cpu_endpoint>; + }; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml new file mode 100644 index 000000000000..f36209137c8a --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/adi,adv7533.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADV7533/35 HDMI Encoders + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: | + The ADV7533 and ADV7535 are HDMI audio and video transmitters + compatible with HDMI 1.4 and DVI 1.0. They support color space + conversion, S/PDIF, CEC and HDCP. The transmitter input is MIPI DSI. + +properties: + compatible: + enum: + - adi,adv7533 + - adi,adv7535 + + reg: + description: | + I2C slave addresses. + + The ADV7533/35 internal registers are split into four pages + exposed through different I2C addresses, creating four register + maps. Each map has it own I2C address and acts as a standard slave + device on the I2C bus. The main address is mandatory, others are + optional and revert to defaults if not specified. + minItems: 1 + maxItems: 4 + + reg-names: + description: + Names of maps with programmable addresses. It can contain any map + needing a non-default address. + minItems: 1 + items: + - const: main + - const: edid + - const: cec + - const: packet + + clocks: + description: Reference to the CEC clock. + maxItems: 1 + + clock-names: + const: cec + + interrupts: + maxItems: 1 + + pd-gpios: + description: GPIO connected to the power down signal. + maxItems: 1 + + avdd-supply: + description: A 1.8V supply that powers up the AVDD pin. + + dvdd-supply: + description: A 1.8V supply that powers up the DVDD pin. + + pvdd-supply: + description: A 1.8V supply that powers up the PVDD pin. + + a2vdd-supply: + description: A 1.8V supply that powers up the A2VDD pin. + + v3p3-supply: + description: A 3.3V supply that powers up the V3P3 pin. + + v1p2-supply: + description: + A supply that powers up the V1P2 pin. It can be either 1.2V + or 1.8V for ADV7533 but only 1.8V for ADV7535. + + adi,disable-timing-generator: + description: + Disables the internal timing generator. The chip will rely on the + sync signals in the DSI data lanes, rather than generating its own + timings for HDMI output. + type: boolean + + adi,dsi-lanes: + description: Number of DSI data lanes connected to the DSI host. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2, 3, 4 ] + + ports: + description: + The ADV7533/35 has two video ports and one audio port. This node + models their connections as documented in + Documentation/devicetree/bindings/media/video-interfaces.txt + Documentation/devicetree/bindings/graph.txt + type: object + properties: + port@0: + description: + Video port for the DSI input. The remote endpoint phandle + should be a reference to a valid mipi_dsi_host_device. + type: object + + port@1: + description: Video port for the HDMI output. + type: object + + port@2: + description: Audio port for the HDMI output. + type: object + +required: + - compatible + - reg + - ports + - adi,dsi-lanes + - avdd-supply + - dvdd-supply + - pvdd-supply + - a2vdd-supply + - v3p3-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c@e6500000 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0 0xe6500000>; + + adv7533: hdmi@39 { + compatible = "adi,adv7533"; + /* + * The EDID page will be accessible on address 0x66 on the I2C + * bus. All other maps continue to use their default addresses. + */ + reg = <0x39>, <0x66>; + reg-names = "main", "edid"; + interrupt-parent = <&gpio3>; + interrupts = <29 IRQ_TYPE_EDGE_FALLING>; + clocks = <&cec_clock>; + clock-names = "cec"; + adi,dsi-lanes = <4>; + avdd-supply = <&v1v8>; + dvdd-supply = <&v1v8>; + pvdd-supply = <&v1v8>; + a2vdd-supply = <&v1v8>; + v3p3-supply = <&v3v3>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + adv7533_in: endpoint { + remote-endpoint = <&dsi_out>; + }; + }; + + port@1 { + reg = <1>; + adv7533_out: endpoint { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + + port@2 { + reg = <2>; + codec_endpoint: endpoint { + remote-endpoint = <&i2s0_cpu_endpoint>; + }; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml index 63427878715e..b2e8bc6da9d0 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml @@ -18,7 +18,6 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: Register block of mhdptx apb registers up to PHY mapped area (AUX_CONFIG_P). @@ -26,13 +25,15 @@ properties: included in the associated PHY. - description: Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7 SoCs. + - description: + Register block of mhdptx sapb registers. reg-names: minItems: 1 - maxItems: 2 items: - const: mhdptx - const: j721e-intg + - const: mhdptx-sapb clocks: maxItems: 1 @@ -99,14 +100,18 @@ allOf: properties: reg: minItems: 2 + maxItems: 3 reg-names: minItems: 2 + maxItems: 3 else: properties: reg: - maxItems: 1 + minItems: 1 + maxItems: 2 reg-names: - maxItems: 1 + minItems: 1 + maxItems: 2 required: - compatible diff --git a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml new file mode 100644 index 000000000000..9f7cc6b757cb --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/google,cros-ec-anx7688.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ChromeOS EC ANX7688 HDMI to DP Converter through Type-C Port + +maintainers: + - Nicolas Boichat <drinkcat@chromium.org> + - Enric Balletbo i Serra <enric.balletbo@collabora.com> + +description: | + ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to + DisplayPort 1.3 Ultra-HDi (4096x2160p60). It is an Analogix ANX7688 chip + which is connected to and operated by the ChromeOS Embedded Controller + (See google,cros-ec.yaml). It is accessed using I2C tunneling through + the EC and therefore its node should be a child of an EC I2C tunnel node + (See google,cros-ec-i2c-tunnel.yaml). + +properties: + compatible: + const: google,cros-ec-anx7688 + + reg: + maxItems: 1 + description: I2C address of the device. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for HDMI input. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: USB Type-c connector. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - ports + +additionalProperties: false + +examples: + - | + i2c_tunnel_b: i2c-tunnel1 { + compatible = "google,cros-ec-i2c-tunnel"; + google,remote-bus = <1>; + #address-cells = <1>; + #size-cells = <0>; + + anx7688: anx7688@2c { + compatible = "google,cros-ec-anx7688"; + reg = <0x2c>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + anx7688_in: endpoint { + remote-endpoint = <&hdmi0_out>; + }; + }; + port@1 { + reg = <1>; + anx7688_out: endpoint { + remote-endpoint = <&typec_connector>; + }; + }; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml new file mode 100644 index 000000000000..6ec1d5fbb8bc --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ITE it66121 HDMI bridge Device Tree Bindings + +maintainers: + - Phong LE <ple@baylibre.com> + - Neil Armstrong <narmstrong@baylibre.com> + +description: | + The IT66121 is a high-performance and low-power single channel HDMI + transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward compatible + to DVI 1.0 specifications. + +properties: + compatible: + const: ite,it66121 + + reg: + maxItems: 1 + + reset-gpios: + maxItems: 1 + description: GPIO connected to active low reset + + vrf12-supply: + description: Regulator for 1.2V analog core power. + + vcn33-supply: + description: Regulator for 3.3V digital core power. + + vcn18-supply: + description: Regulator for 1.8V IO core power. + + interrupts: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: DPI input port. + + properties: + endpoint: + $ref: /schemas/graph.yaml#/$defs/endpoint-base + unevaluatedProperties: false + + properties: + bus-width: + description: + Endpoint bus width. + enum: + - 12 # 12 data lines connected and dual-edge mode + - 24 # 24 data lines connected and single-edge mode + default: 24 + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: HDMI Connector port. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - reset-gpios + - vrf12-supply + - vcn33-supply + - vcn18-supply + - interrupts + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + it66121hdmitx: hdmitx@4c { + compatible = "ite,it66121"; + pinctrl-names = "default"; + pinctrl-0 = <&ite_pins_default>; + vcn33-supply = <&mt6358_vcn33_wifi_reg>; + vcn18-supply = <&mt6358_vcn18_reg>; + vrf12-supply = <&mt6358_vrf12_reg>; + reset-gpios = <&pio 160 GPIO_ACTIVE_LOW>; + interrupt-parent = <&pio>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + reg = <0x4c>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + it66121_in: endpoint { + bus-width = <12>; + remote-endpoint = <&display_out>; + }; + }; + + port@1 { + reg = <1>; + hdmi_conn_out: endpoint { + remote-endpoint = <&hdmi_conn_in>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml index 735d0233a7d6..674891ee2f8e 100644 --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml @@ -29,7 +29,8 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Primary MIPI port for MIPI input diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml new file mode 100644 index 000000000000..d101233ae17f --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -0,0 +1,159 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip + +maintainers: + - Marek Vasut <marex@denx.de> + +description: | + Texas Instruments SN65DSI83 1x Single-link MIPI DSI + to 1x Single-link LVDS + https://www.ti.com/lit/gpn/sn65dsi83 + Texas Instruments SN65DSI84 1x Single-link MIPI DSI + to 1x Dual-link or 2x Single-link LVDS + https://www.ti.com/lit/gpn/sn65dsi84 + +properties: + compatible: + enum: + - ti,sn65dsi83 + - ti,sn65dsi84 + + reg: + enum: + - 0x2c + - 0x2d + + enable-gpios: + maxItems: 1 + description: GPIO specifier for bridge_en pin (active high). + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for MIPI DSI Channel-A input + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + maxItems: 4 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for MIPI DSI Channel-B input + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + maxItems: 4 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for LVDS Channel-A output (panel or bridge). + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for LVDS Channel-B output (panel or bridge). + + required: + - port@0 + - port@2 + +required: + - compatible + - reg + - enable-gpios + - ports + +allOf: + - if: + properties: + compatible: + contains: + const: ti,sn65dsi83 + then: + properties: + ports: + properties: + port@1: false + port@3: false + + - if: + properties: + compatible: + contains: + const: ti,sn65dsi84 + then: + properties: + ports: + properties: + port@1: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi83"; + reg = <0x2d>; + + enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + endpoint { + remote-endpoint = <&dsi0_out>; + data-lanes = <1 2 3 4>; + }; + }; + + port@2 { + reg = <2>; + + endpoint { + remote-endpoint = <&panel_in_lvds>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/faraday,tve200.txt b/Documentation/devicetree/bindings/display/faraday,tve200.txt deleted file mode 100644 index 82e3bc0b7485..000000000000 --- a/Documentation/devicetree/bindings/display/faraday,tve200.txt +++ /dev/null @@ -1,54 +0,0 @@ -* Faraday TV Encoder TVE200 - -Required properties: - -- compatible: must be one of: - "faraday,tve200" - "cortina,gemini-tvc", "faraday,tve200" - -- reg: base address and size of the control registers block - -- interrupts: contains an interrupt specifier for the interrupt - line from the TVE200 - -- clock-names: should contain "PCLK" for the clock line clocking the - silicon and "TVE" for the 27MHz clock to the video driver - -- clocks: contains phandle and clock specifier pairs for the entries - in the clock-names property. See - Documentation/devicetree/bindings/clock/clock-bindings.txt - -Optional properties: - -- resets: contains the reset line phandle for the block - -Required sub-nodes: - -- port: describes LCD panel signals, following the common binding - for video transmitter interfaces; see - Documentation/devicetree/bindings/media/video-interfaces.txt - This port should have the properties: - reg = <0>; - It should have one endpoint connected to a remote endpoint where - the display is connected. - -Example: - -display-controller@6a000000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "faraday,tve200"; - reg = <0x6a000000 0x1000>; - interrupts = <13 IRQ_TYPE_EDGE_RISING>; - resets = <&syscon GEMINI_RESET_TVC>; - clocks = <&syscon GEMINI_CLK_GATE_TVC>, - <&syscon GEMINI_CLK_TVC>; - clock-names = "PCLK", "TVE"; - - port@0 { - reg = <0>; - display_out: endpoint { - remote-endpoint = <&panel_in>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/faraday,tve200.yaml b/Documentation/devicetree/bindings/display/faraday,tve200.yaml new file mode 100644 index 000000000000..e2ee77767321 --- /dev/null +++ b/Documentation/devicetree/bindings/display/faraday,tve200.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/faraday,tve200.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Faraday TV Encoder TVE200 + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +properties: + compatible: + oneOf: + - const: faraday,tve200 + - items: + - const: cortina,gemini-tvc + - const: faraday,tve200 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + + clock-names: + items: + - const: PCLK + - const: TVE + + clocks: + minItems: 2 + + resets: + minItems: 1 + + port: + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - reg + - interrupts + - clock-names + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/cortina,gemini-clock.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/reset/cortina,gemini-reset.h> + display-controller@6a000000 { + compatible = "faraday,tve200"; + reg = <0x6a000000 0x1000>; + interrupts = <13 IRQ_TYPE_EDGE_RISING>; + resets = <&syscon GEMINI_RESET_TVC>; + clocks = <&syscon GEMINI_CLK_GATE_TVC>, + <&syscon GEMINI_CLK_TVC>; + clock-names = "PCLK", "TVE"; + + port { + display_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml new file mode 100644 index 000000000000..66288b9f0aa6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,cec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek HDMI CEC Controller Device Tree Bindings + +maintainers: + - CK Hu <ck.hu@mediatek.com> + - Jitao shi <jitao.shi@mediatek.com> + +description: | + The HDMI CEC controller handles hotplug detection and CEC communication. + +properties: + compatible: + enum: + - mediatek,mt7623-cec + - mediatek,mt8167-cec + - mediatek,mt8173-cec + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + cec: cec@10013000 { + compatible = "mediatek,mt8173-cec"; + reg = <0x10013000 0xbc>; + interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>; + clocks = <&infracfg CLK_INFRA_CEC>; + }; + +... diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml new file mode 100644 index 000000000000..b6fcdfb99ab2 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi-ddc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek HDMI DDC Device Tree Bindings + +maintainers: + - CK Hu <ck.hu@mediatek.com> + - Jitao shi <jitao.shi@mediatek.com> + +description: | + The HDMI DDC i2c controller is used to interface with the HDMI DDC pins. + +properties: + compatible: + enum: + - mediatek,mt7623-hdmi-ddc + - mediatek,mt8167-hdmi-ddc + - mediatek,mt8173-hdmi-ddc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ddc-i2c + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + hdmi_ddc0: i2c@11012000 { + compatible = "mediatek,mt8173-hdmi-ddc"; + reg = <0x11012000 0x1c>; + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>; + clocks = <&pericfg CLK_PERI_I2C5>; + clock-names = "ddc-i2c"; + }; + +... diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt deleted file mode 100644 index b284ca51b913..000000000000 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt +++ /dev/null @@ -1,136 +0,0 @@ -Mediatek HDMI Encoder -===================== - -The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from -its parallel input. - -Required properties: -- compatible: Should be "mediatek,<chip>-hdmi". -- the supported chips are mt2701, mt7623 and mt8173 -- reg: Physical base address and length of the controller's registers -- interrupts: The interrupt signal from the function block. -- clocks: device clocks - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: must contain "pixel", "pll", "bclk", and "spdif". -- phys: phandle link to the HDMI PHY node. - See Documentation/devicetree/bindings/phy/phy-bindings.txt for details. -- phy-names: must contain "hdmi" -- mediatek,syscon-hdmi: phandle link and register offset to the system - configuration registers. For mt8173 this must be offset 0x900 into the - MMSYS_CONFIG region: <&mmsys 0x900>. -- ports: A node containing input and output port nodes with endpoint - definitions as documented in Documentation/devicetree/bindings/graph.txt. -- port@0: The input port in the ports node should be connected to a DPI output - port. -- port@1: The output port in the ports node should be connected to the input - port of a connector node that contains a ddc-i2c-bus property, or to the - input port of an attached bridge chip, such as a SlimPort transmitter. - -HDMI CEC -======== - -The HDMI CEC controller handles hotplug detection and CEC communication. - -Required properties: -- compatible: Should be "mediatek,<chip>-cec" -- the supported chips are mt7623 and mt8173 -- reg: Physical base address and length of the controller's registers -- interrupts: The interrupt signal from the function block. -- clocks: device clock - -HDMI DDC -======== - -The HDMI DDC i2c controller is used to interface with the HDMI DDC pins. -The Mediatek's I2C controller is used to interface with I2C devices. - -Required properties: -- compatible: Should be "mediatek,<chip>-hdmi-ddc" -- the supported chips are mt7623 and mt8173 -- reg: Physical base address and length of the controller's registers -- clocks: device clock -- clock-names: Should be "ddc-i2c". - -HDMI PHY -======== -See phy/mediatek,hdmi-phy.yaml - -Example: - -cec: cec@10013000 { - compatible = "mediatek,mt8173-cec"; - reg = <0 0x10013000 0 0xbc>; - interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>; - clocks = <&infracfg CLK_INFRA_CEC>; -}; - -hdmi_phy: hdmi-phy@10209100 { - compatible = "mediatek,mt8173-hdmi-phy"; - reg = <0 0x10209100 0 0x24>; - clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>; - clock-names = "pll_ref"; - clock-output-names = "hdmitx_dig_cts"; - mediatek,ibias = <0xa>; - mediatek,ibias_up = <0x1c>; - #clock-cells = <0>; - #phy-cells = <0>; -}; - -hdmi_ddc0: i2c@11012000 { - compatible = "mediatek,mt8173-hdmi-ddc"; - reg = <0 0x11012000 0 0x1c>; - interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>; - clocks = <&pericfg CLK_PERI_I2C5>; - clock-names = "ddc-i2c"; -}; - -hdmi0: hdmi@14025000 { - compatible = "mediatek,mt8173-hdmi"; - reg = <0 0x14025000 0 0x400>; - interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_LOW>; - clocks = <&mmsys CLK_MM_HDMI_PIXEL>, - <&mmsys CLK_MM_HDMI_PLLCK>, - <&mmsys CLK_MM_HDMI_AUDIO>, - <&mmsys CLK_MM_HDMI_SPDIF>; - clock-names = "pixel", "pll", "bclk", "spdif"; - pinctrl-names = "default"; - pinctrl-0 = <&hdmi_pin>; - phys = <&hdmi_phy>; - phy-names = "hdmi"; - mediatek,syscon-hdmi = <&mmsys 0x900>; - assigned-clocks = <&topckgen CLK_TOP_HDMI_SEL>; - assigned-clock-parents = <&hdmi_phy>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - hdmi0_in: endpoint { - remote-endpoint = <&dpi0_out>; - }; - }; - - port@1 { - reg = <1>; - - hdmi0_out: endpoint { - remote-endpoint = <&hdmi_con_in>; - }; - }; - }; -}; - -connector { - compatible = "hdmi-connector"; - type = "a"; - ddc-i2c-bus = <&hdmiddc0>; - - port { - hdmi_con_in: endpoint { - remote-endpoint = <&hdmi0_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml new file mode 100644 index 000000000000..111967efa999 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml @@ -0,0 +1,133 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek HDMI Encoder Device Tree Bindings + +maintainers: + - CK Hu <ck.hu@mediatek.com> + - Jitao shi <jitao.shi@mediatek.com> + +description: | + The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from + its parallel input. + +properties: + compatible: + enum: + - mediatek,mt2701-hdmi + - mediatek,mt7623-hdmi + - mediatek,mt8167-hdmi + - mediatek,mt8173-hdmi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Pixel Clock + - description: HDMI PLL + - description: Bit Clock + - description: S/PDIF Clock + + clock-names: + items: + - const: pixel + - const: pll + - const: bclk + - const: spdif + + phys: + maxItems: 1 + + phy-names: + items: + - const: hdmi + + mediatek,syscon-hdmi: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + description: | + phandle link and register offset to the system configuration registers. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: | + Input port node. This port should be connected to a DPI output port. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: | + Output port node. This port should be connected to the input port of a connector + node that contains a ddc-i2c-bus property, or to the input port of an attached + bridge chip, such as a SlimPort transmitter. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - phys + - phy-names + - mediatek,syscon-hdmi + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + hdmi0: hdmi@14025000 { + compatible = "mediatek,mt8173-hdmi"; + reg = <0x14025000 0x400>; + interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_LOW>; + clocks = <&mmsys CLK_MM_HDMI_PIXEL>, + <&mmsys CLK_MM_HDMI_PLLCK>, + <&mmsys CLK_MM_HDMI_AUDIO>, + <&mmsys CLK_MM_HDMI_SPDIF>; + clock-names = "pixel", "pll", "bclk", "spdif"; + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_pin>; + phys = <&hdmi_phy>; + phy-names = "hdmi"; + mediatek,syscon-hdmi = <&mmsys 0x900>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + hdmi0_in: endpoint { + remote-endpoint = <&dpi0_out>; + }; + }; + + port@1 { + reg = <1>; + + hdmi0_out: endpoint { + remote-endpoint = <&hdmi_con_in>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml new file mode 100644 index 000000000000..64d8d9e5e47a --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dp-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MSM Display Port Controller + +maintainers: + - Kuogee Hsieh <khsieh@codeaurora.org> + +description: | + Device tree bindings for DisplayPort host controller for MSM targets + that are compatible with VESA DisplayPort interface specification. + +properties: + compatible: + enum: + - qcom,sc7180-dp + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: AHB clock to enable register access + - description: Display Port AUX clock + - description: Display Port Link clock + - description: Link interface clock between DP and PHY + - description: Display Port Pixel clock + + clock-names: + items: + - const: core_iface + - const: core_aux + - const: ctrl_link + - const: ctrl_link_iface + - const: stream_pixel + + assigned-clocks: + items: + - description: link clock source + - description: pixel clock source + + assigned-clock-parents: + items: + - description: phy 0 parent + - description: phy 1 parent + + phys: + maxItems: 1 + + phy-names: + items: + - const: dp + + operating-points-v2: + maxItems: 1 + + power-domains: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input endpoint of the controller + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Output endpoint of the controller + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - phys + - phy-names + - "#sound-dai-cells" + - power-domains + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,dispcc-sc7180.h> + #include <dt-bindings/power/qcom-aoss-qmp.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + displayport-controller@ae90000 { + compatible = "qcom,sc7180-dp"; + reg = <0xae90000 0x1400>; + interrupt-parent = <&mdss>; + interrupts = <12>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_DP_AUX_CLK>, + <&dispcc DISP_CC_MDSS_DP_LINK_CLK>, + <&dispcc DISP_CC_MDSS_DP_LINK_INTF_CLK>, + <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK>; + clock-names = "core_iface", "core_aux", + "ctrl_link", + "ctrl_link_iface", "stream_pixel"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_DP_LINK_CLK_SRC>, + <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK_SRC>; + + assigned-clock-parents = <&dp_phy 0>, <&dp_phy 1>; + + phys = <&dp_phy>; + phy-names = "dp"; + + #sound-dai-cells = <0>; + + power-domains = <&rpmhpd SC7180_CX>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dpu_intf0_out>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&typec>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml new file mode 100644 index 000000000000..12a86b1ec1bc --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml @@ -0,0 +1,228 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-sc7180.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DPU dt properties for SC7180 target + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +description: | + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree + bindings of MDSS and DPU are mentioned for SC7180 target. + +properties: + compatible: + items: + - const: qcom,sc7180-mdss + + reg: + maxItems: 1 + + reg-names: + const: mdss + + power-domains: + maxItems: 1 + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display AHB clock from dispcc + - description: Display core clock + + clock-names: + items: + - const: iface + - const: ahb + - const: core + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#address-cells": true + + "#size-cells": true + + "#interrupt-cells": + const: 1 + + iommus: + items: + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0 + + ranges: true + + interconnects: + items: + - description: Interconnect path specifying the port ids for data bus + + interconnect-names: + const: mdp0-mem + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + description: Node containing the properties of DPU. + + properties: + compatible: + items: + - const: qcom,sc7180-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for vbif register set + + reg-names: + items: + - const: mdp + - const: vbif + + clocks: + items: + - description: Display hf axi clock + - description: Display ahb clock + - description: Display rotator clock + - description: Display lut clock + - description: Display core clock + - description: Display vsync clock + + clock-names: + items: + - const: bus + - const: iface + - const: rot + - const: lut + - const: core + - const: vsync + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + operating-points-v2: true + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Contains the list of output ports from DPU device. These ports + connect to interfaces that are external to the DPU hardware, + such as DSI, DP etc. Each output port contains an endpoint that + describes how it is connected to an external interface. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF1 (DSI1) + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF0 (DP) + + required: + - port@0 + + required: + - compatible + - reg + - reg-names + - clocks + - interrupts + - power-domains + - operating-points-v2 + - ports + +required: + - compatible + - reg + - reg-names + - power-domains + - clocks + - interrupts + - interrupt-controller + - iommus + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sc7180.h> + #include <dt-bindings/clock/qcom,gcc-sc7180.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interconnect/qcom,sdm845.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-subsystem@ae00000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,sc7180-mdss"; + reg = <0xae00000 0x1000>; + reg-names = "mdss"; + power-domains = <&dispcc MDSS_GDSC>; + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "ahb", "core"; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>; + interconnect-names = "mdp0-mem"; + + iommus = <&apps_smmu 0x800 0x2>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,sc7180-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_ROT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", "iface", "rot", "lut", "core", + "vsync"; + + interrupt-parent = <&mdss>; + interrupts = <0>; + power-domains = <&rpmhpd SC7180_CX>; + operating-points-v2 = <&mdp_opp_table>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@2 { + reg = <2>; + dpu_intf0_out: endpoint { + remote-endpoint = <&dp_in>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml new file mode 100644 index 000000000000..b4ea7c92fb3d --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml @@ -0,0 +1,212 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-sdm845.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DPU dt properties for SDM845 target + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +description: | + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree + bindings of MDSS and DPU are mentioned for SDM845 target. + +properties: + compatible: + items: + - const: qcom,sdm845-mdss + + reg: + maxItems: 1 + + reg-names: + const: mdss + + power-domains: + maxItems: 1 + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display AXI clock + - description: Display core clock + + clock-names: + items: + - const: iface + - const: bus + - const: core + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#address-cells": true + + "#size-cells": true + + "#interrupt-cells": + const: 1 + + iommus: + items: + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0 + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port1 + + ranges: true + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + description: Node containing the properties of DPU. + + properties: + compatible: + items: + - const: qcom,sdm845-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for vbif register set + + reg-names: + items: + - const: mdp + - const: vbif + + clocks: + items: + - description: Display ahb clock + - description: Display axi clock + - description: Display core clock + - description: Display vsync clock + + clock-names: + items: + - const: iface + - const: bus + - const: core + - const: vsync + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + operating-points-v2: true + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Contains the list of output ports from DPU device. These ports + connect to interfaces that are external to the DPU hardware, + such as DSI, DP etc. Each output port contains an endpoint that + describes how it is connected to an external interface. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF1 (DSI1) + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF2 (DSI2) + + required: + - port@0 + - port@1 + + required: + - compatible + - reg + - reg-names + - clocks + - interrupts + - power-domains + - operating-points-v2 + - ports + +required: + - compatible + - reg + - reg-names + - power-domains + - clocks + - interrupts + - interrupt-controller + - iommus + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-subsystem@ae00000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,sdm845-mdss"; + reg = <0x0ae00000 0x1000>; + reg-names = "mdss"; + power-domains = <&dispcc MDSS_GDSC>; + + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "bus", "core"; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + iommus = <&apps_smmu 0x880 0x8>, + <&apps_smmu 0xc80 0x8>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,sdm845-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "iface", "bus", "core", "vsync"; + + interrupt-parent = <&mdss>; + interrupts = <0>; + power-domains = <&rpmhpd SDM845_CX>; + operating-points-v2 = <&mdp_opp_table>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + dpu_intf2_out: endpoint { + remote-endpoint = <&dsi1_in>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt b/Documentation/devicetree/bindings/display/msm/dpu.txt deleted file mode 100644 index 586e6eac5b08..000000000000 --- a/Documentation/devicetree/bindings/display/msm/dpu.txt +++ /dev/null @@ -1,141 +0,0 @@ -Qualcomm Technologies, Inc. DPU KMS - -Description: - -Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates -sub-blocks like DPU display controller, DSI and DP interfaces etc. -The DPU display controller is found in SDM845 SoC. - -MDSS: -Required properties: -- compatible: "qcom,sdm845-mdss", "qcom,sc7180-mdss" -- reg: physical base address and length of controller's registers. -- reg-names: register region names. The following region is required: - * "mdss" -- power-domains: a power domain consumer specifier according to - Documentation/devicetree/bindings/power/power_domain.txt -- clocks: list of clock specifiers for clocks needed by the device. -- clock-names: device clock names, must be in same order as clocks property. - The following clocks are required: - * "iface" - * "bus" - * "core" -- interrupts: interrupt signal from MDSS. -- interrupt-controller: identifies the node as an interrupt controller. -- #interrupt-cells: specifies the number of cells needed to encode an interrupt - source, should be 1. -- iommus: phandle of iommu device node. -- #address-cells: number of address cells for the MDSS children. Should be 1. -- #size-cells: Should be 1. -- ranges: parent bus address space is the same as the child bus address space. -- interconnects : interconnect path specifier for MDSS according to - Documentation/devicetree/bindings/interconnect/interconnect.txt. Should be - 2 paths corresponding to 2 AXI ports. -- interconnect-names : MDSS will have 2 port names to differentiate between the - 2 interconnect paths defined with interconnect specifier. - -Optional properties: -- assigned-clocks: list of clock specifiers for clocks needing rate assignment -- assigned-clock-rates: list of clock frequencies sorted in the same order as - the assigned-clocks property. - -MDP: -Required properties: -- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu" -- reg: physical base address and length of controller's registers. -- reg-names : register region names. The following region is required: - * "mdp" - * "vbif" -- clocks: list of clock specifiers for clocks needed by the device. -- clock-names: device clock names, must be in same order as clocks property. - The following clocks are required. - * "bus" - * "iface" - * "core" - * "vsync" -- interrupts: interrupt line from DPU to MDSS. -- ports: contains the list of output ports from DPU device. These ports connect - to interfaces that are external to the DPU hardware, such as DSI, DP etc. - - Each output port contains an endpoint that describes how it is connected to an - external interface. These are described by the standard properties documented - here: - Documentation/devicetree/bindings/graph.txt - Documentation/devicetree/bindings/media/video-interfaces.txt - - Port 0 -> DPU_INTF1 (DSI1) - Port 1 -> DPU_INTF2 (DSI2) - -Optional properties: -- assigned-clocks: list of clock specifiers for clocks needing rate assignment -- assigned-clock-rates: list of clock frequencies sorted in the same order as - the assigned-clocks property. - -Example: - - mdss: mdss@ae00000 { - compatible = "qcom,sdm845-mdss"; - reg = <0xae00000 0x1000>; - reg-names = "mdss"; - - power-domains = <&clock_dispcc 0>; - - clocks = <&gcc GCC_DISP_AHB_CLK>, <&gcc GCC_DISP_AXI_CLK>, - <&clock_dispcc DISP_CC_MDSS_MDP_CLK>; - clock-names = "iface", "bus", "core"; - - assigned-clocks = <&clock_dispcc DISP_CC_MDSS_MDP_CLK>; - assigned-clock-rates = <300000000>; - - interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; - interrupt-controller; - #interrupt-cells = <1>; - - interconnects = <&rsc_hlos MASTER_MDP0 &rsc_hlos SLAVE_EBI1>, - <&rsc_hlos MASTER_MDP1 &rsc_hlos SLAVE_EBI1>; - - interconnect-names = "mdp0-mem", "mdp1-mem"; - - iommus = <&apps_iommu 0>; - - #address-cells = <2>; - #size-cells = <1>; - ranges = <0 0 0xae00000 0xb2008>; - - mdss_mdp: mdp@ae01000 { - compatible = "qcom,sdm845-dpu"; - reg = <0 0x1000 0x8f000>, <0 0xb0000 0x2008>; - reg-names = "mdp", "vbif"; - - clocks = <&clock_dispcc DISP_CC_MDSS_AHB_CLK>, - <&clock_dispcc DISP_CC_MDSS_AXI_CLK>, - <&clock_dispcc DISP_CC_MDSS_MDP_CLK>, - <&clock_dispcc DISP_CC_MDSS_VSYNC_CLK>; - clock-names = "iface", "bus", "core", "vsync"; - - assigned-clocks = <&clock_dispcc DISP_CC_MDSS_MDP_CLK>, - <&clock_dispcc DISP_CC_MDSS_VSYNC_CLK>; - assigned-clock-rates = <0 0 300000000 19200000>; - - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - dpu_intf1_out: endpoint { - remote-endpoint = <&dsi0_in>; - }; - }; - - port@1 { - reg = <1>; - dpu_intf2_out: endpoint { - remote-endpoint = <&dsi1_in>; - }; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml new file mode 100644 index 000000000000..76348b71f736 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -0,0 +1,185 @@ +# 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# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI controller + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +allOf: + - $ref: "../dsi-controller.yaml#" + +properties: + compatible: + items: + - const: qcom,mdss-dsi-ctrl + + reg: + maxItems: 1 + + reg-names: + const: dsi_ctrl + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Display byte clock + - description: Display byte interface clock + - description: Display pixel clock + - description: Display escape clock + - description: Display AHB clock + - description: Display AXI clock + + clock-names: + items: + - const: byte + - const: byte_intf + - const: pixel + - const: core + - const: iface + - const: bus + + phys: + maxItems: 1 + + phy-names: + const: dsi + + "#address-cells": true + + "#size-cells": true + + syscon-sfpb: + description: A phandle to mmss_sfpb syscon node (only for DSIv2). + $ref: "/schemas/types.yaml#/definitions/phandle" + + qcom,dual-dsi-mode: + type: boolean + description: | + Indicates if the DSI controller is driving a panel which needs + 2 DSI links. + + power-domains: + maxItems: 1 + + operating-points-v2: true + + ports: + $ref: "/schemas/graph.yaml#/properties/ports" + description: | + Contains DSI controller input and output ports as children, each + containing one endpoint subnode. + + properties: + port@0: + $ref: "/schemas/graph.yaml#/properties/port" + description: | + Input endpoints of the controller. + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + properties: + data-lanes: + maxItems: 4 + minItems: 4 + items: + enum: [ 0, 1, 2, 3 ] + + port@1: + $ref: "/schemas/graph.yaml#/properties/port" + description: | + Output endpoints of the controller. + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + properties: + data-lanes: + maxItems: 4 + minItems: 4 + items: + enum: [ 0, 1, 2, 3 ] + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + - phys + - phy-names + - power-domains + - operating-points-v2 + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + dsi@ae94000 { + compatible = "qcom,mdss-dsi-ctrl"; + reg = <0x0ae94000 0x400>; + reg-names = "dsi_ctrl"; + + #address-cells = <1>; + #size-cells = <0>; + + interrupt-parent = <&mdss>; + interrupts = <4>; + + clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>, + <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK>, + <&dispcc DISP_CC_MDSS_ESC0_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + phys = <&dsi0_phy>; + phy-names = "dsi"; + + power-domains = <&rpmhpd SC7180_CX>; + operating-points-v2 = <&dsi_opp_table>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dsi0_in: endpoint { + remote-endpoint = <&dpu_intf1_out>; + }; + }; + + port@1 { + reg = <1>; + dsi0_out: endpoint { + remote-endpoint = <&sn65dsi86_in>; + data-lanes = <0 1 2 3>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml new file mode 100644 index 000000000000..4a26bef19360 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml @@ -0,0 +1,68 @@ +# 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# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 10nm PHY + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-10nm + - const: qcom,dsi-phy-10nm-8998 + + reg: + items: + - description: dsi phy register set + - description: dsi phy lane register set + - description: dsi pll register set + + reg-names: + items: + - const: dsi_phy + - const: dsi_phy_lane + - const: dsi_pll + + vdds-supply: + description: | + Connected to DSI0_MIPI_DSI_PLL_VDDA0P9 pin for sc7180 target and + connected to VDDA_MIPI_DSI_0_PLL_0P9 pin for sdm845 target + +required: + - compatible + - reg + - reg-names + - vdds-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + dsi-phy@ae94400 { + compatible = "qcom,dsi-phy-10nm"; + reg = <0x0ae94400 0x200>, + <0x0ae94600 0x280>, + <0x0ae94a00 0x1e0>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vdds-supply = <&vdda_mipi_dsi0_pll>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml new file mode 100644 index 000000000000..72a00cce0147 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml @@ -0,0 +1,66 @@ +# 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# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 14nm PHY + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-14nm + - const: qcom,dsi-phy-14nm-660 + + reg: + items: + - description: dsi phy register set + - description: dsi phy lane register set + - description: dsi pll register set + + reg-names: + items: + - const: dsi_phy + - const: dsi_phy_lane + - const: dsi_pll + + vcca-supply: + description: Phandle to vcca regulator device node. + +required: + - compatible + - reg + - reg-names + - vcca-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + dsi-phy@ae94400 { + compatible = "qcom,dsi-phy-14nm"; + reg = <0x0ae94400 0x200>, + <0x0ae94600 0x280>, + <0x0ae94a00 0x1e0>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vcca-supply = <&vcca_reg>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml new file mode 100644 index 000000000000..743806d61afe --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml @@ -0,0 +1,71 @@ +# 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# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 20nm PHY + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-20nm + + reg: + items: + - description: dsi pll register set + - description: dsi phy register set + - description: dsi phy regulator register set + + reg-names: + items: + - const: dsi_pll + - const: dsi_phy + - const: dsi_phy_regulator + + vcca-supply: + description: Phandle to vcca regulator device node. + + vddio-supply: + description: Phandle to vdd-io regulator device node. + +required: + - compatible + - reg + - reg-names + - vddio-supply + - vcca-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + dsi-phy@fd922a00 { + compatible = "qcom,dsi-phy-20nm"; + reg = <0xfd922a00 0xd4>, + <0xfd922b00 0x2b0>, + <0xfd922d80 0x7b>; + reg-names = "dsi_pll", + "dsi_phy", + "dsi_phy_regulator"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vcca-supply = <&vcca_reg>; + vddio-supply = <&vddio_reg>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml new file mode 100644 index 000000000000..b106007116b4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml @@ -0,0 +1,68 @@ +# 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# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 28nm PHY + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-28nm-hpm + - const: qcom,dsi-phy-28nm-lp + - const: qcom,dsi-phy-28nm-8960 + + reg: + items: + - description: dsi pll register set + - description: dsi phy register set + - description: dsi phy regulator register set + + reg-names: + items: + - const: dsi_pll + - const: dsi_phy + - const: dsi_phy_regulator + + vddio-supply: + description: Phandle to vdd-io regulator device node. + +required: + - compatible + - reg + - reg-names + - vddio-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + dsi-phy@fd922a00 { + compatible = "qcom,dsi-phy-28nm-lp"; + reg = <0xfd922a00 0xd4>, + <0xfd922b00 0x2b0>, + <0xfd922d80 0x7b>; + reg-names = "dsi_pll", + "dsi_phy", + "dsi_phy_regulator"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vddio-supply = <&vddio_reg>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml new file mode 100644 index 000000000000..502bdda90235 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml @@ -0,0 +1,40 @@ +# 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# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Description of Qualcomm Display DSI PHY common dt properties + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +description: | + This defines the DSI PHY dt properties which are common for all + dsi phy versions. + +properties: + "#clock-cells": + const: 1 + + "#phy-cells": + const: 0 + + clocks: + items: + - description: Display AHB clock + - description: Board XO source + + clock-names: + items: + - const: iface + - const: ref + +required: + - clocks + - clock-names + - "#clock-cells" + - "#phy-cells" + +additionalProperties: true +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt deleted file mode 100644 index b9a64d3ff184..000000000000 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ /dev/null @@ -1,249 +0,0 @@ -Qualcomm Technologies Inc. adreno/snapdragon DSI output - -DSI Controller: -Required properties: -- compatible: - * "qcom,mdss-dsi-ctrl" -- reg: Physical base address and length of the registers of controller -- reg-names: The names of register regions. The following regions are required: - * "dsi_ctrl" -- interrupts: The interrupt signal from the DSI block. -- power-domains: Should be <&mmcc MDSS_GDSC>. -- clocks: Phandles to device clocks. -- clock-names: the following clocks are required: - * "mdp_core" - * "iface" - * "bus" - * "core_mmss" - * "byte" - * "pixel" - * "core" - For DSIv2, we need an additional clock: - * "src" - For DSI6G v2.0 onwards, we need also need the clock: - * "byte_intf" -- assigned-clocks: Parents of "byte" and "pixel" for the given platform. -- assigned-clock-parents: The Byte clock and Pixel clock PLL outputs provided - by a DSI PHY block. See [1] for details on clock bindings. -- vdd-supply: phandle to vdd regulator device node -- vddio-supply: phandle to vdd-io regulator device node -- vdda-supply: phandle to vdda regulator device node -- phys: phandle to DSI PHY device node -- phy-names: the name of the corresponding PHY device -- syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2) -- ports: Contains 2 DSI controller ports as child nodes. Each port contains - an endpoint subnode as defined in [2] and [3]. - -Optional properties: -- panel@0: Node of panel connected to this DSI controller. - See files in [4] for each supported panel. -- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is - driving a panel which needs 2 DSI links. -- qcom,master-dsi: Boolean value indicating if the DSI controller is driving - the master link of the 2-DSI panel. -- qcom,sync-dual-dsi: Boolean value indicating if the DSI controller is - driving a 2-DSI panel whose 2 links need receive command simultaneously. -- pinctrl-names: the pin control state names; should contain "default" -- pinctrl-0: the default pinctrl state (active) -- pinctrl-n: the "sleep" pinctrl state -- ports: contains DSI controller input and output ports as children, each - containing one endpoint subnode. - - DSI Endpoint properties: - - remote-endpoint: For port@0, set to phandle of the connected panel/bridge's - input endpoint. For port@1, set to the MDP interface output. See [2] for - device graph info. - - - data-lanes: this describes how the physical DSI data lanes are mapped - to the logical lanes on the given platform. The value contained in - index n describes what physical lane is mapped to the logical lane n - (DATAn, where n lies between 0 and 3). The clock lane position is fixed - and can't be changed. Hence, they aren't a part of the DT bindings. See - [3] for more info on the data-lanes property. - - For example: - - data-lanes = <3 0 1 2>; - - The above mapping describes that the logical data lane DATA0 is mapped to - the physical data lane DATA3, logical DATA1 to physical DATA0, logic DATA2 - to phys DATA1 and logic DATA3 to phys DATA2. - - There are only a limited number of physical to logical mappings possible: - <0 1 2 3> - <1 2 3 0> - <2 3 0 1> - <3 0 1 2> - <0 3 2 1> - <1 0 3 2> - <2 1 0 3> - <3 2 1 0> - -DSI PHY: -Required properties: -- compatible: Could be the following - * "qcom,dsi-phy-28nm-hpm" - * "qcom,dsi-phy-28nm-lp" - * "qcom,dsi-phy-20nm" - * "qcom,dsi-phy-28nm-8960" - * "qcom,dsi-phy-14nm" - * "qcom,dsi-phy-14nm-660" - * "qcom,dsi-phy-10nm" - * "qcom,dsi-phy-10nm-8998" - * "qcom,dsi-phy-7nm" - * "qcom,dsi-phy-7nm-8150" -- reg: Physical base address and length of the registers of PLL, PHY. Some - revisions require the PHY regulator base address, whereas others require the - PHY lane base address. See below for each PHY revision. -- reg-names: The names of register regions. The following regions are required: - For DSI 28nm HPM/LP/8960 PHYs and 20nm PHY: - * "dsi_pll" - * "dsi_phy" - * "dsi_phy_regulator" - For DSI 14nm, 10nm and 7nm PHYs: - * "dsi_pll" - * "dsi_phy" - * "dsi_phy_lane" -- clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating - 2 clocks: A byte clock (index 0), and a pixel clock (index 1). -- power-domains: Should be <&mmcc MDSS_GDSC>. -- clocks: Phandles to device clocks. See [1] for details on clock bindings. -- clock-names: the following clocks are required: - * "iface" - * "ref" (only required for new DTS files/entries) - For 28nm HPM/LP, 28nm 8960 PHYs: -- vddio-supply: phandle to vdd-io regulator device node - For 20nm PHY: -- vddio-supply: phandle to vdd-io regulator device node -- vcca-supply: phandle to vcca regulator device node - For 14nm PHY: -- vcca-supply: phandle to vcca regulator device node - For 10nm and 7nm PHY: -- vdds-supply: phandle to vdds regulator device node - -Optional properties: -- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY - regulator is wanted. -- qcom,mdss-mdp-transfer-time-us: Specifies the dsi transfer time for command mode - panels in microseconds. Driver uses this number to adjust - the clock rate according to the expected transfer time. - Increasing this value would slow down the mdp processing - and can result in slower performance. - Decreasing this value can speed up the mdp processing, - but this can also impact power consumption. - As a rule this time should not be higher than the time - that would be expected with the processing at the - dsi link rate since anyways this would be the maximum - transfer time that could be achieved. - If ping pong split is enabled, this time should not be higher - than two times the dsi link rate time. - If the property is not specified, then the default value is 14000 us. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/graph.txt -[3] Documentation/devicetree/bindings/media/video-interfaces.txt -[4] Documentation/devicetree/bindings/display/panel/ - -Example: - dsi0: dsi@fd922800 { - compatible = "qcom,mdss-dsi-ctrl"; - qcom,dsi-host-index = <0>; - interrupt-parent = <&mdp>; - interrupts = <4 0>; - reg-names = "dsi_ctrl"; - reg = <0xfd922800 0x200>; - power-domains = <&mmcc MDSS_GDSC>; - clock-names = - "bus", - "byte", - "core", - "core_mmss", - "iface", - "mdp_core", - "pixel"; - clocks = - <&mmcc MDSS_AXI_CLK>, - <&mmcc MDSS_BYTE0_CLK>, - <&mmcc MDSS_ESC0_CLK>, - <&mmcc MMSS_MISC_AHB_CLK>, - <&mmcc MDSS_AHB_CLK>, - <&mmcc MDSS_MDP_CLK>, - <&mmcc MDSS_PCLK0_CLK>; - - assigned-clocks = - <&mmcc BYTE0_CLK_SRC>, - <&mmcc PCLK0_CLK_SRC>; - assigned-clock-parents = - <&dsi_phy0 0>, - <&dsi_phy0 1>; - - vdda-supply = <&pma8084_l2>; - vdd-supply = <&pma8084_l22>; - vddio-supply = <&pma8084_l12>; - - phys = <&dsi_phy0>; - phy-names ="dsi-phy"; - - qcom,dual-dsi-mode; - qcom,master-dsi; - qcom,sync-dual-dsi; - - qcom,mdss-mdp-transfer-time-us = <12000>; - - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&dsi_active>; - pinctrl-1 = <&dsi_suspend>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - dsi0_in: endpoint { - remote-endpoint = <&mdp_intf1_out>; - }; - }; - - port@1 { - reg = <1>; - dsi0_out: endpoint { - remote-endpoint = <&panel_in>; - data-lanes = <0 1 2 3>; - }; - }; - }; - - panel: panel@0 { - compatible = "sharp,lq101r1sx01"; - reg = <0>; - link2 = <&secondary>; - - power-supply = <...>; - backlight = <...>; - - port { - panel_in: endpoint { - remote-endpoint = <&dsi0_out>; - }; - }; - }; - }; - - dsi_phy0: dsi-phy@fd922a00 { - compatible = "qcom,dsi-phy-28nm-hpm"; - qcom,dsi-phy-index = <0>; - reg-names = - "dsi_pll", - "dsi_phy", - "dsi_phy_regulator"; - reg = <0xfd922a00 0xd4>, - <0xfd922b00 0x2b0>, - <0xfd922d80 0x7b>; - clock-names = "iface"; - clocks = <&mmcc MDSS_AHB_CLK>; - #clock-cells = <1>; - vddio-supply = <&pma8084_l12>; - - qcom,dsi-phy-regulator-ldo-mode; - }; diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml index 31164608ba1d..49460c9dceea 100644 --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml @@ -51,37 +51,37 @@ properties: - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and [VESA] specifications. Data are transferred as follows on 3 LVDS lanes. - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< - DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI] specifications. Data are transferred as follows on 4 LVDS lanes. - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< - DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< - DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< + DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< + DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification. Data are transferred as follows on 4 LVDS lanes. - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< - DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< - DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< Control signals are mapped as follows. diff --git a/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml new file mode 100644 index 000000000000..4cb75a5f2e3a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,lms397kf04.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung LMS397KF04 display panel + +description: The datasheet claims this is based around a display controller + named DB7430 with a separate backlight controller. + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,lms397kf04 + + reg: true + + reset-gpios: true + + vci-supply: + description: regulator that supplies the VCI analog voltage + usually around 3.0 V + + vccio-supply: + description: regulator that supplies the VCCIO voltage usually + around 1.8 V + + backlight: true + + spi-max-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: inherited as a SPI client node, the datasheet specifies + maximum 300 ns minimum cycle which gives around 3 MHz max frequency + maximum: 3000000 + + port: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "samsung,lms397kf04"; + spi-max-frequency = <3000000>; + reg = <0>; + vci-supply = <&lcd_3v0_reg>; + vccio-supply = <&lcd_1v8_reg>; + reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + backlight = <&ktd259>; + + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index 121596f106da..5f4345d43020 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -55,7 +55,7 @@ properties: maxItems: 1 ports: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/properties/ports description: | The connections to the DU output video ports are modeled using the OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml index 75cd9c686e98..da3b889ad8fc 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml @@ -29,7 +29,6 @@ properties: clocks: minItems: 2 - maxItems: 5 items: - {} - {} @@ -41,7 +40,6 @@ properties: clock-names: minItems: 2 - maxItems: 5 items: - {} - {} diff --git a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml index 679daed4124e..ed310bbe3afe 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml +++ b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml @@ -29,7 +29,6 @@ properties: - description: DSI bus clock - description: Pixel clock minItems: 2 - maxItems: 3 clock-names: items: @@ -37,7 +36,6 @@ properties: - const: ref - const: px_clk minItems: 2 - maxItems: 3 resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml index d54f9ca207af..4ae3d75492d3 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml @@ -22,7 +22,6 @@ properties: - description: events interrupt line. - description: errors interrupt line. minItems: 1 - maxItems: 2 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml index 403d57977ee7..d88bd93f4b80 100644 --- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml @@ -65,7 +65,6 @@ properties: The APB clock and at least one video clock are mandatory, the audio clock is optional. minItems: 2 - maxItems: 4 items: - description: dp_apb_clk is the APB clock - description: dp_aud_clk is the Audio clock @@ -78,13 +77,11 @@ properties: clock-names: oneOf: - minItems: 2 - maxItems: 3 items: - const: dp_apb_clk - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] - minItems: 3 - maxItems: 4 items: - const: dp_apb_clk - const: dp_aud_clk @@ -116,7 +113,6 @@ properties: maxItems: 2 phy-names: minItems: 1 - maxItems: 2 items: - const: dp-phy0 - const: dp-phy1 diff --git a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml new file mode 100644 index 000000000000..a4f9fe23dcd9 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/altr,msgdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Altera mSGDMA IP core + +maintainers: + - Olivier Dautricourt <olivier.dautricourt@orolia.com> + +description: | + Altera / Intel modular Scatter-Gather Direct Memory Access (mSGDMA) + intellectual property (IP) + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + const: altr,socfpga-msgdma + + reg: + items: + - description: Control and Status Register Slave Port + - description: Descriptor Slave Port + - description: Response Slave Port + + reg-names: + items: + - const: csr + - const: desc + - const: resp + + interrupts: + maxItems: 1 + + "#dma-cells": + const: 1 + description: + The cell identifies the channel id (must be 0) + +required: + - compatible + - reg + - reg-names + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + msgdma_controller: dma-controller@ff200b00 { + compatible = "altr,socfpga-msgdma"; + reg = <0xff200b00 0x100>, <0xff200c00 0x100>, <0xff200d00 0x100>; + reg-names = "csr", "desc", "resp"; + interrupts = <0 67 IRQ_TYPE_LEVEL_HIGH>; + #dma-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/dma/arm-pl08x.txt b/Documentation/devicetree/bindings/dma/arm-pl08x.txt deleted file mode 100644 index 0ba81f79266f..000000000000 --- a/Documentation/devicetree/bindings/dma/arm-pl08x.txt +++ /dev/null @@ -1,59 +0,0 @@ -* ARM PrimeCells PL080 and PL081 and derivatives DMA controller - -Required properties: -- compatible: "arm,pl080", "arm,primecell"; - "arm,pl081", "arm,primecell"; - "faraday,ftdmac020", "arm,primecell" -- arm,primecell-periphid: on the FTDMAC020 the primecell ID is not hard-coded - in the hardware and must be specified here as <0x0003b080>. This number - follows the PrimeCell standard numbering using the JEP106 vendor code 0x38 - for Faraday Technology. -- reg: Address range of the PL08x registers -- interrupt: The PL08x interrupt number -- clocks: The clock running the IP core clock -- clock-names: Must contain "apb_pclk" -- lli-bus-interface-ahb1: if AHB master 1 is eligible for fetching LLIs -- lli-bus-interface-ahb2: if AHB master 2 is eligible for fetching LLIs -- mem-bus-interface-ahb1: if AHB master 1 is eligible for fetching memory contents -- mem-bus-interface-ahb2: if AHB master 2 is eligible for fetching memory contents -- #dma-cells: must be <2>. First cell should contain the DMA request, - second cell should contain either 1 or 2 depending on - which AHB master that is used. - -Optional properties: -- dma-channels: contains the total number of DMA channels supported by the DMAC -- dma-requests: contains the total number of DMA requests supported by the DMAC -- memcpy-burst-size: the size of the bursts for memcpy: 1, 4, 8, 16, 32 - 64, 128 or 256 bytes are legal values -- memcpy-bus-width: the bus width used for memcpy in bits: 8, 16 or 32 are legal - values, the Faraday FTDMAC020 can also accept 64 bits - -Clients -Required properties: -- dmas: List of DMA controller phandle, request channel and AHB master id -- dma-names: Names of the aforementioned requested channels - -Example: - -dmac0: dma-controller@10130000 { - compatible = "arm,pl080", "arm,primecell"; - reg = <0x10130000 0x1000>; - interrupt-parent = <&vica>; - interrupts = <15>; - clocks = <&hclkdma0>; - clock-names = "apb_pclk"; - lli-bus-interface-ahb1; - lli-bus-interface-ahb2; - mem-bus-interface-ahb2; - memcpy-burst-size = <256>; - memcpy-bus-width = <32>; - #dma-cells = <2>; -}; - -device@40008000 { - ... - dmas = <&dmac0 0 2 - &dmac0 1 2>; - dma-names = "tx", "rx"; - ... -}; diff --git a/Documentation/devicetree/bindings/dma/arm-pl08x.yaml b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml new file mode 100644 index 000000000000..3bd9eea543ca --- /dev/null +++ b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml @@ -0,0 +1,136 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/arm-pl08x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM PrimeCells PL080 and PL081 and derivatives DMA controller + +maintainers: + - Vinod Koul <vkoul@kernel.org> + +allOf: + - $ref: "dma-controller.yaml#" + +# We need a select here so we don't match all nodes with 'arm,primecell' +select: + properties: + compatible: + contains: + enum: + - arm,pl080 + - arm,pl081 + required: + - compatible + +properties: + compatible: + oneOf: + - items: + - enum: + - arm,pl080 + - arm,pl081 + - const: arm,primecell + - items: + - const: faraday,ftdma020 + - const: arm,pl080 + - const: arm,primecell + + reg: + maxItems: 1 + description: Address range of the PL08x registers + + interrupts: + minItems: 1 + description: The PL08x interrupt number + + clocks: + minItems: 1 + description: The clock running the IP core clock + + clock-names: + maxItems: 1 + + lli-bus-interface-ahb1: + type: boolean + description: if AHB master 1 is eligible for fetching LLIs + + lli-bus-interface-ahb2: + type: boolean + description: if AHB master 2 is eligible for fetching LLIs + + mem-bus-interface-ahb1: + type: boolean + description: if AHB master 1 is eligible for fetching memory contents + + mem-bus-interface-ahb2: + type: boolean + description: if AHB master 2 is eligible for fetching memory contents + + memcpy-burst-size: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 1 + - 4 + - 8 + - 16 + - 32 + - 64 + - 128 + - 256 + description: the size of the bursts for memcpy + + memcpy-bus-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 8 + - 16 + - 32 + - 64 + description: bus width used for memcpy in bits. FTDMAC020 also accept 64 bits + +required: + - reg + - interrupts + - clocks + - clock-names + - "#dma-cells" + +unevaluatedProperties: false + +examples: + - | + dmac0: dma-controller@10130000 { + compatible = "arm,pl080", "arm,primecell"; + reg = <0x10130000 0x1000>; + interrupt-parent = <&vica>; + interrupts = <15>; + clocks = <&hclkdma0>; + clock-names = "apb_pclk"; + lli-bus-interface-ahb1; + lli-bus-interface-ahb2; + mem-bus-interface-ahb2; + memcpy-burst-size = <256>; + memcpy-bus-width = <32>; + #dma-cells = <2>; + }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/reset/cortina,gemini-reset.h> + #include <dt-bindings/clock/cortina,gemini-clock.h> + dma-controller@67000000 { + compatible = "faraday,ftdma020", "arm,pl080", "arm,primecell"; + /* Faraday Technology FTDMAC020 variant */ + arm,primecell-periphid = <0x0003b080>; + reg = <0x67000000 0x1000>; + interrupts = <9 IRQ_TYPE_EDGE_RISING>; + resets = <&syscon GEMINI_RESET_DMAC>; + clocks = <&syscon GEMINI_CLK_AHB>; + clock-names = "apb_pclk"; + /* Bus interface AHB1 (AHB0) is totally tilted */ + lli-bus-interface-ahb2; + mem-bus-interface-ahb2; + memcpy-burst-size = <256>; + memcpy-bus-width = <32>; + #dma-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml index e302147e53c6..e614fe3187bb 100644 --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -21,6 +21,7 @@ properties: enum: - qcom,sdm845-gpi-dma - qcom,sm8150-gpi-dma + - qcom,sm8250-gpi-dma reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml index 7f2a54bc732d..d8142cbd13d3 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml @@ -52,7 +52,6 @@ properties: interrupt-names: minItems: 9 - maxItems: 17 items: - const: error - pattern: "^ch([0-9]|1[0-5])$" diff --git a/Documentation/devicetree/bindings/dma/renesas,shdma.txt b/Documentation/devicetree/bindings/dma/renesas,shdma.txt deleted file mode 100644 index a91920a49433..000000000000 --- a/Documentation/devicetree/bindings/dma/renesas,shdma.txt +++ /dev/null @@ -1,84 +0,0 @@ -* SHDMA Device Tree bindings - -Sh-/r-mobile and R-Car systems often have multiple identical DMA controller -instances, capable of serving any of a common set of DMA slave devices, using -the same configuration. To describe this topology we require all compatible -SHDMA DT nodes to be placed under a DMA multiplexer node. All such compatible -DMAC instances have the same number of channels and use the same DMA -descriptors. Therefore respective DMA DT bindings can also all be placed in the -multiplexer node. Even if there is only one such DMAC instance on a system, it -still has to be placed under such a multiplexer node. - -* DMA multiplexer - -Required properties: -- compatible: should be "renesas,shdma-mux" -- #dma-cells: should be <1>, see "dmas" property below - -Optional properties (currently unused): -- dma-channels: number of DMA channels -- dma-requests: number of DMA request signals - -* DMA controller - -Required properties: -- compatible: should be of the form "renesas,shdma-<soc>", where <soc> should - be replaced with the desired SoC model, e.g. - "renesas,shdma-r8a73a4" for the system DMAC on r8a73a4 SoC - -Example: - dmac: dma-multiplexer@0 { - compatible = "renesas,shdma-mux"; - #dma-cells = <1>; - dma-channels = <20>; - dma-requests = <256>; - #address-cells = <2>; - #size-cells = <2>; - ranges; - - dma0: dma-controller@e6700020 { - compatible = "renesas,shdma-r8a73a4"; - reg = <0 0xe6700020 0 0x89e0>; - interrupt-parent = <&gic>; - interrupts = <0 220 4 - 0 200 4 - 0 201 4 - 0 202 4 - 0 203 4 - 0 204 4 - 0 205 4 - 0 206 4 - 0 207 4 - 0 208 4 - 0 209 4 - 0 210 4 - 0 211 4 - 0 212 4 - 0 213 4 - 0 214 4 - 0 215 4 - 0 216 4 - 0 217 4 - 0 218 4 - 0 219 4>; - interrupt-names = "error", - "ch0", "ch1", "ch2", "ch3", - "ch4", "ch5", "ch6", "ch7", - "ch8", "ch9", "ch10", "ch11", - "ch12", "ch13", "ch14", "ch15", - "ch16", "ch17", "ch18", "ch19"; - }; - }; - -* DMA client - -Required properties: -- dmas: a list of <[DMA multiplexer phandle] [MID/RID value]> pairs, - where MID/RID values are fixed handles, specified in the SoC - manual -- dma-names: a list of DMA channel names, one per "dmas" entry - -Example: - dmas = <&dmac 0xd1 - &dmac 0xd2>; - dma-names = "tx", "rx"; diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt index 29fcd37082e8..f719e1612b0a 100644 --- a/Documentation/devicetree/bindings/dma/ti-edma.txt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -33,7 +33,7 @@ The following are mandatory properties for 66AK2G SoCs only: - power-domains:Should contain a phandle to a PM domain provider node and an args specifier containing the device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Optional properties: ------------------- @@ -70,7 +70,7 @@ The following are mandatory properties for 66AK2G SoCs only: - power-domains:Should contain a phandle to a PM domain provider node and an args specifier containing the device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Optional properties: ------------------- diff --git a/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml b/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml index 57e5270a0741..4cfc3a187004 100644 --- a/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml +++ b/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml @@ -30,14 +30,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: uncorrectable error interrupt - description: correctable error interrupt interrupt-names: minItems: 1 - maxItems: 2 items: - const: ue - const: ce diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml index 021d8ae42da3..914a423ec449 100644 --- a/Documentation/devicetree/bindings/eeprom/at24.yaml +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml @@ -32,7 +32,6 @@ properties: oneOf: - allOf: - minItems: 1 - maxItems: 2 items: - pattern: "^(atmel|catalyst|microchip|nxp|ramtron|renesas|rohm|st),(24(c|cs|lc|mac)[0-9]+|spd)$" - pattern: "^atmel,(24(c|cs|mac)[0-9]+|spd)$" diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index a97f39109f8d..ff6ec65145cf 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml @@ -91,7 +91,6 @@ properties: interrupts: # Either 1 or 2 interrupts can be present minItems: 1 - maxItems: 2 items: - description: tx or combined interrupt - description: rx interrupt @@ -105,7 +104,6 @@ properties: interrupt-names: # minItems must be specified here because the default would be 2 minItems: 1 - maxItems: 2 items: - const: tx irq - const: rx irq diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml new file mode 100644 index 000000000000..cebf6ffe70d5 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -0,0 +1,341 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2021 ARM Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/arm,scmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: System Control and Management Interface (SCMI) Message Protocol bindings + +maintainers: + - Sudeep Holla <sudeep.holla@arm.com> + +description: | + The SCMI is intended to allow agents such as OSPM to manage various functions + that are provided by the hardware platform it is running on, including power + and performance functions. + + This binding is intended to define the interface the firmware implementing + the SCMI as described in ARM document number ARM DEN 0056 ("ARM System Control + and Management Interface Platform Design Document")[0] provide for OSPM in + the device tree. + + [0] https://developer.arm.com/documentation/den0056/latest + +properties: + $nodename: + const: scmi + + compatible: + oneOf: + - description: SCMI compliant firmware with mailbox transport + items: + - const: arm,scmi + - description: SCMI compliant firmware with ARM SMC/HVC transport + items: + - const: arm,scmi-smc + + interrupts: + description: + The interrupt that indicates message completion by the platform + rather than by the return of the smc call. This should not be used + except when the platform requires such behavior. + maxItems: 1 + + interrupt-names: + const: a2p + + mbox-names: + description: + Specifies the mailboxes used to communicate with SCMI compliant + firmware. + items: + - const: tx + - const: rx + + mboxes: + description: + List of phandle and mailbox channel specifiers. It should contain + exactly one or two mailboxes, one for transmitting messages("tx") + and another optional for receiving the notifications("rx") if supported. + minItems: 1 + maxItems: 2 + + shmem: + description: + List of phandle pointing to the shared memory(SHM) area, for each + transport channel specified. + minItems: 1 + maxItems: 2 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + arm,smc-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + SMC id required when using smc or hvc transports + + protocol@11: + type: object + properties: + reg: + const: 0x11 + + '#power-domain-cells': + const: 1 + + required: + - '#power-domain-cells' + + protocol@13: + type: object + properties: + reg: + const: 0x13 + + '#clock-cells': + const: 1 + + required: + - '#clock-cells' + + protocol@14: + type: object + properties: + reg: + const: 0x14 + + '#clock-cells': + const: 1 + + required: + - '#clock-cells' + + protocol@15: + type: object + properties: + reg: + const: 0x15 + + '#thermal-sensor-cells': + const: 1 + + required: + - '#thermal-sensor-cells' + + protocol@16: + type: object + properties: + reg: + const: 0x16 + + '#reset-cells': + const: 1 + + required: + - '#reset-cells' + + protocol@17: + type: object + properties: + reg: + const: 0x17 + + regulators: + type: object + description: + The list of all regulators provided by this SCMI controller. + + patternProperties: + '^regulators@[0-9a-f]+$': + type: object + $ref: "../regulator/regulator.yaml#" + + properties: + reg: + maxItems: 1 + description: Identifier for the voltage regulator. + + required: + - reg + +additionalProperties: false + +patternProperties: + '^protocol@[0-9a-f]+$': + type: object + description: + Each sub-node represents a protocol supported. If the platform + supports a dedicated communication channel for a particular protocol, + then the corresponding transport properties must be present. + + properties: + reg: + maxItems: 1 + + mbox-names: + items: + - const: tx + - const: rx + + mboxes: + minItems: 1 + maxItems: 2 + + shmem: + minItems: 1 + maxItems: 2 + + required: + - reg + +required: + - compatible + - shmem + +if: + properties: + compatible: + contains: + const: arm,scmi +then: + properties: + interrupts: false + interrupt-names: false + + required: + - mboxes + +else: + if: + properties: + compatible: + contains: + const: arm,scmi-smc + then: + required: + - arm,smc-id + +examples: + - | + firmware { + scmi { + compatible = "arm,scmi"; + mboxes = <&mhuB 0 0>, + <&mhuB 0 1>; + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_lpri0>, + <&cpu_scp_lpri1>; + + #address-cells = <1>; + #size-cells = <0>; + + scmi_devpd: protocol@11 { + reg = <0x11>; + #power-domain-cells = <1>; + }; + + scmi_dvfs: protocol@13 { + reg = <0x13>; + #clock-cells = <1>; + + mboxes = <&mhuB 1 0>, + <&mhuB 1 1>; + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_hpri0>, + <&cpu_scp_hpri1>; + }; + + scmi_clk: protocol@14 { + reg = <0x14>; + #clock-cells = <1>; + }; + + scmi_sensors: protocol@15 { + reg = <0x15>; + #thermal-sensor-cells = <1>; + }; + + scmi_reset: protocol@16 { + reg = <0x16>; + #reset-cells = <1>; + }; + + scmi_voltage: protocol@17 { + reg = <0x17>; + regulators { + #address-cells = <1>; + #size-cells = <0>; + + regulator_devX: regulator@0 { + reg = <0x0>; + regulator-max-microvolt = <3300000>; + }; + + regulator_devY: regulator@9 { + reg = <0x9>; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <4200000>; + }; + }; + }; + }; + }; + + soc { + #address-cells = <2>; + #size-cells = <2>; + + sram@50000000 { + compatible = "mmio-sram"; + reg = <0x0 0x50000000 0x0 0x10000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x50000000 0x10000>; + + cpu_scp_lpri0: scp-sram-section@0 { + compatible = "arm,scmi-shmem"; + reg = <0x0 0x80>; + }; + + cpu_scp_lpri1: scp-sram-section@80 { + compatible = "arm,scmi-shmem"; + reg = <0x80 0x80>; + }; + + cpu_scp_hpri0: scp-sram-section@100 { + compatible = "arm,scmi-shmem"; + reg = <0x100 0x80>; + }; + + cpu_scp_hpri2: scp-sram-section@180 { + compatible = "arm,scmi-shmem"; + reg = <0x180 0x80>; + }; + }; + }; + + - | + firmware { + scmi { + compatible = "arm,scmi-smc"; + shmem = <&cpu_scp_lpri0 &cpu_scp_lpri1>; + arm,smc-id = <0xc3000001>; + + #address-cells = <1>; + #size-cells = <0>; + + scmi_devpd1: protocol@11 { + reg = <0x11>; + #power-domain-cells = <1>; + }; + + }; + }; + +... diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml new file mode 100644 index 000000000000..d7113b06454b --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml @@ -0,0 +1,247 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2021 ARM Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/arm,scpi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: System Control and Power Interface (SCPI) Message Protocol bindings + +maintainers: + - Sudeep Holla <sudeep.holla@arm.com> + +description: | + Firmware implementing the SCPI described in ARM document number ARM DUI + 0922B ("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be + used by Linux to initiate various system control and power operations. + + This binding is intended to define the interface the firmware implementing + the SCPI provide for OSPM in the device tree. + + [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html + +properties: + $nodename: + const: scpi + + compatible: + description: + SCPI compliant firmware complying to SCPI v1.0 and above OR + SCPI compliant firmware complying to all unversioned releases + prior to SCPI v1.0 + oneOf: + - const: arm,scpi # SCPI v1.0 and above + - const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0 + - items: + - enum: + - amlogic,meson-gxbb-scpi + - const: arm,scpi-pre-1.0 + + mboxes: + description: + List of phandle and mailbox channel specifiers. All the channels reserved + by remote SCP firmware for use by SCPI message protocol should be + specified in any order. + minItems: 1 + + shmem: + description: + List of phandle pointing to the shared memory(SHM) area between the + processors using these mailboxes for IPC, one for each mailbox SHM can + be any memory reserved for the purpose of this communication between the + processors. + minItems: 1 + + power-controller: + type: object + description: + This sub-node represents SCPI power domain controller. + + properties: + compatible: + const: arm,scpi-power-domains + + '#power-domain-cells': + const: 1 + + num-domains: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Total number of power domains provided by SCPI. This is needed as + the SCPI message protocol lacks a mechanism to query this + information at runtime. + + required: + - compatible + - '#power-domain-cells' + - num-domains + + additionalProperties: false + + sensors: + type: object + description: | + This sub-node represents SCPI sensors controller. + + properties: + compatible: + oneOf: + - const: arm,scpi-sensors + - items: + - enum: + - amlogic,meson-gxbb-scpi-sensors + - const: arm,scpi-sensors + + '#thermal-sensor-cells': + const: 1 + + required: + - compatible + - '#thermal-sensor-cells' + + additionalProperties: false + + clocks: + type: object + description: + This is the container node. Each sub-node represents one of the types + of clock controller - indexed or full range. + + properties: + compatible: + const: arm,scpi-clocks + + patternProperties: + "^clocks-[0-9a-f]+$": + type: object + description: | + This sub-node represents one of the types of clock controller + - indexed or full range. + + "arm,scpi-dvfs-clocks" - all the clocks that are variable and index + based. These clocks don't provide an entire range of values between + the limits but only discrete points within the range. The firmware + provides the mapping for each such operating frequency and the index + associated with it. The firmware also manages the voltage scaling + appropriately with the clock scaling. + + "arm,scpi-variable-clocks" - all the clocks that are variable and + provide full range within the specified range. The firmware provides + the range of values within a specified range. + + properties: + compatible: + oneOf: + - const: arm,scpi-dvfs-clocks + - const: arm,scpi-variable-clocks + + '#clock-cells': + const: 1 + + clock-output-names: true + + clock-indices: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + The identifying number for the clocks(i.e.clock_id) in the node. + It can be non linear and hence provide the mapping of identifiers + into the clock-output-names array. + + required: + - compatible + - '#clock-cells' + - clock-output-names + - clock-indices + + additionalProperties: false + + required: + - compatible + + additionalProperties: false + +additionalProperties: false + +required: + - compatible + - mboxes + - shmem + +examples: + - | + firmware { + scpi { + compatible = "arm,scpi"; + mboxes = <&mhuA 1>; + shmem = <&cpu_scp_hpri>; /* HP-NonSecure */ + + scpi_devpd: power-controller { + compatible = "arm,scpi-power-domains"; + num-domains = <2>; + #power-domain-cells = <1>; + }; + + clocks { + compatible = "arm,scpi-clocks"; + + scpi_dvfs: clocks-0 { + compatible = "arm,scpi-dvfs-clocks"; + #clock-cells = <1>; + clock-indices = <0>, <1>, <2>; + clock-output-names = "atlclk", "aplclk","gpuclk"; + }; + + scpi_clk: clocks-1 { + compatible = "arm,scpi-variable-clocks"; + #clock-cells = <1>; + clock-indices = <3>, <4>; + clock-output-names = "pxlclk0", "pxlclk1"; + }; + }; + + scpi_sensors: sensors { + compatible = "arm,scpi-sensors"; + #thermal-sensor-cells = <1>; + }; + + }; + }; + + soc { + #address-cells = <2>; + #size-cells = <2>; + + sram@50000000 { + compatible = "mmio-sram"; + reg = <0x0 0x50000000 0x0 0x10000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x50000000 0x10000>; + + cpu_scp_lpri: scp-sram-section@0 { + compatible = "arm,scp-shmem"; + reg = <0x0 0x200>; + }; + + cpu_scp_hpri: scp-sram-section@200 { + compatible = "arm,scp-shmem"; + reg = <0x200 0x200>; + }; + }; + }; + + - | + firmware { + scpi { + compatible = "amlogic,meson-gxbb-scpi", "arm,scpi-pre-1.0"; + mboxes = <&mailbox 1 &mailbox 2>; + shmem = <&cpu_scp_lpri &cpu_scp_hpri>; + + scpi_sensors1: sensors { + compatible = "amlogic,meson-gxbb-scpi-sensors", "arm,scpi-sensors"; + #thermal-sensor-cells = <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 1bd2870c3a9c..c435c9f369a4 100644 --- a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml +++ b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml @@ -26,9 +26,16 @@ properties: reg: items: - - description: NPE0 register range - - description: NPE1 register range - - description: NPE2 register range + - description: NPE0 (NPE-A) register range + - description: NPE1 (NPE-B) register range + - description: NPE2 (NPE-C) register range + + crypto: + $ref: /schemas/crypto/intel,ixp4xx-crypto.yaml# + type: object + description: Optional node for the embedded crypto engine, the node + should be named with the instance number of the NPE engine used for + the crypto engine. required: - compatible @@ -38,8 +45,15 @@ additionalProperties: false examples: - | - npe@c8006000 { + npe: npe@c8006000 { compatible = "intel,ixp4xx-network-processing-engine"; reg = <0xc8006000 0x1000>, <0xc8007000 0x1000>, <0xc8008000 0x1000>; + + crypto { + compatible = "intel,ixp4xx-crypto"; + intel,npe-handle = <&npe 2>; + queue-rx = <&qmgr 30>; + queue-txready = <&qmgr 29>; + }; }; ... diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt deleted file mode 100644 index 7018aa896835..000000000000 --- a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt +++ /dev/null @@ -1,19 +0,0 @@ -Xilinx Zynq FPGA Manager - -Required properties: -- compatible: should contain "xlnx,zynq-devcfg-1.0" -- reg: base address and size for memory mapped io -- interrupts: interrupt for the FPGA manager device -- clocks: phandle for clocks required operation -- clock-names: name for the clock, should be "ref_clk" -- syscon: phandle for access to SLCR registers - -Example: - devcfg: devcfg@f8007000 { - compatible = "xlnx,zynq-devcfg-1.0"; - reg = <0xf8007000 0x100>; - interrupts = <0 8 4>; - clocks = <&clkc 12>; - clock-names = "ref_clk"; - syscon = <&slcr>; - }; diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml new file mode 100644 index 000000000000..29daca4be47f --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/xilinx-zynq-fpga-mgr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq FPGA Manager Device Tree Bindings + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +properties: + compatible: + const: xlnx,zynq-devcfg-1.0 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ref_clk + + syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to syscon block which provide access to SLCR registers + +required: + - compatible + - reg + - clocks + - clock-names + - syscon + +additionalProperties: false + +examples: + - | + devcfg: devcfg@f8007000 { + compatible = "xlnx,zynq-devcfg-1.0"; + reg = <0xf8007000 0x100>; + interrupts = <0 8 4>; + clocks = <&clkc 12>; + clock-names = "ref_clk"; + syscon = <&slcr>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt deleted file mode 100644 index 696ea46227d1..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt +++ /dev/null @@ -1,167 +0,0 @@ -Davinci/Keystone GPIO controller bindings - -Required Properties: -- compatible: should be "ti,dm6441-gpio": for Davinci da850 SoCs - "ti,keystone-gpio": for Keystone 2 66AK2H/K, 66AK2L, - 66AK2E SoCs - "ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G - "ti,am654-gpio", "ti,keystone-gpio": for TI K3 AM654 - "ti,j721e-gpio", "ti,keystone-gpio": for J721E SoCs - "ti,am64-gpio", "ti,keystone-gpio": for AM64 SoCs - -- reg: Physical base address of the controller and the size of memory mapped - registers. - -- gpio-controller : Marks the device node as a gpio controller. - -- #gpio-cells : Should be two. - - first cell is the pin number - - second cell is used to specify optional parameters (unused) - -- interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are - supported at a time. - -- ti,ngpio: The number of GPIO pins supported. - -- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual interrupt - line to processor. - -- clocks: Should contain the device's input clock, and should be defined as per - the appropriate clock bindings consumer usage in, - - Documentation/devicetree/bindings/clock/keystone-gate.txt - for 66AK2HK/66AK2L/66AK2E SoCs or, - - Documentation/devicetree/bindings/clock/ti,sci-clk.txt - for 66AK2G SoCs - -- clock-names: Name should be "gpio"; - -Currently clock-names and clocks are needed for all keystone 2 platforms -Davinci platforms do not have DT clocks as of now. - -The GPIO controller also acts as an interrupt controller. It uses the default -two cells specifier as described in Documentation/devicetree/bindings/ -interrupt-controller/interrupts.txt. - -Example: - -gpio: gpio@1e26000 { - compatible = "ti,dm6441-gpio"; - gpio-controller; - #gpio-cells = <2>; - reg = <0x226000 0x1000>; - interrupt-parent = <&intc>; - interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH - 44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH - 46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH - 48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH - 50 IRQ_TYPE_EDGE_BOTH>; - ti,ngpio = <144>; - ti,davinci-gpio-unbanked = <0>; - interrupt-controller; - #interrupt-cells = <2>; -}; - -leds { - compatible = "gpio-leds"; - - led1 { - label = "davinci:green:usr1"; - gpios = <&gpio 10 GPIO_ACTIVE_HIGH>; - ... - }; - - led2 { - label = "davinci:red:debug1"; - gpios = <&gpio 11 GPIO_ACTIVE_HIGH>; - ... - }; -}; - -Example for 66AK2G: - -gpio0: gpio@2603000 { - compatible = "ti,k2g-gpio", "ti,keystone-gpio"; - reg = <0x02603000 0x100>; - gpio-controller; - #gpio-cells = <2>; - interrupts = <GIC_SPI 432 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 434 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 435 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 437 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 438 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 439 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 440 IRQ_TYPE_EDGE_RISING>; - interrupt-controller; - #interrupt-cells = <2>; - ti,ngpio = <144>; - ti,davinci-gpio-unbanked = <0>; - clocks = <&k2g_clks 0x001b 0x0>; - clock-names = "gpio"; -}; - -Example for 66AK2HK/66AK2L/66AK2E: - -gpio0: gpio@260bf00 { - compatible = "ti,keystone-gpio"; - reg = <0x0260bf00 0x100>; - gpio-controller; - #gpio-cells = <2>; - /* HW Interrupts mapped to GPIO pins */ - interrupts = <GIC_SPI 120 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 121 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 123 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 124 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 125 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 126 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 127 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 128 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 130 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 131 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 133 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 135 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 136 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 137 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 138 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 139 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 140 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 141 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 142 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 143 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 144 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 145 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 146 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 147 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 148 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 149 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 150 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 151 IRQ_TYPE_EDGE_RISING>; - clocks = <&clkgpio>; - clock-names = "gpio"; - ti,ngpio = <32>; - ti,davinci-gpio-unbanked = <32>; -}; - -Example for K3 AM654: - -wkup_gpio0: wkup_gpio0@42110000 { - compatible = "ti,am654-gpio", "ti,keystone-gpio"; - reg = <0x42110000 0x100>; - gpio-controller; - #gpio-cells = <2>; - interrupt-parent = <&intr_wkup_gpio>; - interrupts = <59 128>, <59 129>, <59 130>, <59 131>; - interrupt-controller; - #interrupt-cells = <2>; - ti,ngpio = <56>; - ti,davinci-gpio-unbanked = <0>; - clocks = <&k3_clks 59 0>; - clock-names = "gpio"; -}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml b/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml new file mode 100644 index 000000000000..f32e09ef937c --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml @@ -0,0 +1,185 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-davinci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO controller for Davinci and keystone devices + +maintainers: + - Keerthy <j-keerthy@ti.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,k2g-gpio + - ti,am654-gpio + - ti,j721e-gpio + - ti,am64-gpio + - const: ti,keystone-gpio + + - items: + - enum: + - ti,dm6441-gpio + - ti,keystone-gpio + + reg: + maxItems: 1 + + gpio-controller: true + + gpio-ranges: true + + gpio-line-names: + description: strings describing the names of each gpio line. + minItems: 1 + maxItems: 100 + + "#gpio-cells": + const: 2 + description: + first cell is the pin number and second cell is used to specify optional parameters (unused). + + interrupts: + description: + The interrupts are specified as per the interrupt parent. Only banked + or unbanked IRQs are supported at a time. If the interrupts are + banked then provide list of interrupts corresponding to each bank, else + provide the list of interrupts for each gpio. + minItems: 1 + maxItems: 100 + + ti,ngpio: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The number of GPIO pins supported consecutively. + minimum: 1 + + ti,davinci-gpio-unbanked: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The number of GPIOs that have an individual interrupt line to processor. + minimum: 0 + + clocks: + maxItems: 1 + + clock-names: + const: gpio + + interrupt-controller: true + + power-domains: + maxItems: 1 + + "#interrupt-cells": + const: 2 + +patternProperties: + "^(.+-hog(-[0-9]+)?)$": + type: object + + required: + - gpio-hog + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - interrupts + - ti,ngpio + - ti,davinci-gpio-unbanked + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include<dt-bindings/interrupt-controller/arm-gic.h> + + gpio0: gpio@2603000 { + compatible = "ti,k2g-gpio", "ti,keystone-gpio"; + reg = <0x02603000 0x100>; + gpio-controller; + #gpio-cells = <2>; + interrupts = <GIC_SPI 432 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 434 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 435 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 437 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 438 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 439 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 440 IRQ_TYPE_EDGE_RISING>; + interrupt-controller; + #interrupt-cells = <2>; + ti,ngpio = <144>; + ti,davinci-gpio-unbanked = <0>; + clocks = <&k2g_clks 0x001b 0x0>; + clock-names = "gpio"; + }; + + - | + #include<dt-bindings/interrupt-controller/arm-gic.h> + + gpio1: gpio@260bf00 { + compatible = "ti,keystone-gpio"; + reg = <0x0260bf00 0x100>; + gpio-controller; + #gpio-cells = <2>; + /* HW Interrupts mapped to GPIO pins */ + interrupts = <GIC_SPI 120 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 121 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 123 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 124 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 125 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 126 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 127 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 128 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 130 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 131 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 133 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 135 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 136 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 137 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 138 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 139 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 140 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 141 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 142 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 143 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 144 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 145 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 146 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 147 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 148 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 149 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 150 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 151 IRQ_TYPE_EDGE_RISING>; + clocks = <&clkgpio>; + clock-names = "gpio"; + ti,ngpio = <32>; + ti,davinci-gpio-unbanked = <32>; + }; + + - | + wkup_gpio0: gpio0@42110000 { + compatible = "ti,am654-gpio", "ti,keystone-gpio"; + reg = <0x42110000 0x100>; + gpio-controller; + #gpio-cells = <2>; + interrupt-parent = <&intr_wkup_gpio>; + interrupts = <60>, <61>, <62>, <63>; + interrupt-controller; + #interrupt-cells = <2>; + ti,ngpio = <56>; + ti,davinci-gpio-unbanked = <0>; + clocks = <&k3_clks 59 0>; + clock-names = "gpio"; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt deleted file mode 100644 index e57b2cb28f6c..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt +++ /dev/null @@ -1,45 +0,0 @@ -OMAP GPIO controller bindings - -Required properties: -- compatible: - - "ti,omap2-gpio" for OMAP2 controllers - - "ti,omap3-gpio" for OMAP3 controllers - - "ti,omap4-gpio" for OMAP4 controllers -- reg : Physical base address of the controller and length of memory mapped - region. -- gpio-controller : Marks the device node as a GPIO controller. -- #gpio-cells : Should be two. - - first cell is the pin number - - second cell is used to specify optional parameters (unused) -- interrupt-controller: Mark the device node as an interrupt controller. -- #interrupt-cells : Should be 2. - The first cell is the GPIO number. - The second cell is used to specify flags: - bits[3:0] trigger type and level flags: - 1 = low-to-high edge triggered. - 2 = high-to-low edge triggered. - 4 = active high level-sensitive. - 8 = active low level-sensitive. -- interrupts : The interrupt the controller is rising as output when an - interrupt occures - -OMAP specific properties: -- ti,hwmods: Name of the hwmod associated to the GPIO: - "gpio<X>", <X> being the 1-based instance number - from the HW spec. -- ti,gpio-always-on: Indicates if a GPIO bank is always powered and - so will never lose its logic state. - - -Example: - -gpio0: gpio@44e07000 { - compatible = "ti,omap4-gpio"; - reg = <0x44e07000 0x1000>; - ti,hwmods = "gpio1"; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - interrupts = <96>; -}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt deleted file mode 100644 index a482455a205b..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt +++ /dev/null @@ -1,69 +0,0 @@ -* PCF857x-compatible I/O expanders - -The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be -driven high by a pull-up current source or driven low to ground. This combines -the direction and output level into a single bit per line, which can't be read -back. We can't actually know at initialization time whether a line is configured -(a) as output and driving the signal low/high, or (b) as input and reporting a -low/high value, without knowing the last value written since the chip came out -of reset (if any). The only reliable solution for setting up line direction is -thus to do it explicitly. - -Required Properties: - - - compatible: should be one of the following. - - "maxim,max7328": For the Maxim MAX7378 - - "maxim,max7329": For the Maxim MAX7329 - - "nxp,pca8574": For the NXP PCA8574 - - "nxp,pca8575": For the NXP PCA8575 - - "nxp,pca9670": For the NXP PCA9670 - - "nxp,pca9671": For the NXP PCA9671 - - "nxp,pca9672": For the NXP PCA9672 - - "nxp,pca9673": For the NXP PCA9673 - - "nxp,pca9674": For the NXP PCA9674 - - "nxp,pca9675": For the NXP PCA9675 - - "nxp,pcf8574": For the NXP PCF8574 - - "nxp,pcf8574a": For the NXP PCF8574A - - "nxp,pcf8575": For the NXP PCF8575 - - - reg: I2C slave address. - - - gpio-controller: Marks the device node as a gpio controller. - - #gpio-cells: Should be 2. The first cell is the GPIO number and the second - cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the - GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. - -Optional Properties: - - - lines-initial-states: Bitmask that specifies the initial state of each - line. When a bit is set to zero, the corresponding line will be initialized to - the input (pulled-up) state. When the bit is set to one, the line will be - initialized the low-level output state. If the property is not specified - all lines will be initialized to the input state. - - The I/O expander can detect input state changes, and thus optionally act as - an interrupt controller. When the expander interrupt line is connected all the - following properties must be set. For more information please see the - interrupt controller device tree bindings documentation available at - Documentation/devicetree/bindings/interrupt-controller/interrupts.txt. - - - interrupt-controller: Identifies the node as an interrupt controller. - - #interrupt-cells: Number of cells to encode an interrupt source, shall be 2. - - interrupts: Interrupt specifier for the controllers interrupt. - - -Please refer to gpio.txt in this directory for details of the common GPIO -bindings used by client devices. - -Example: PCF8575 I/O expander node - - pcf8575: gpio@20 { - compatible = "nxp,pcf8575"; - reg = <0x20>; - interrupt-parent = <&irqpin2>; - interrupts = <3 0>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt deleted file mode 100644 index 78458adbf4b7..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt +++ /dev/null @@ -1,42 +0,0 @@ -Lantiq SoC Serial To Parallel (STP) GPIO controller - -The Serial To Parallel (STP) is found on MIPS based Lantiq socs. It is a -peripheral controller used to drive external shift register cascades. At most -3 groups of 8 bits can be driven. The hardware is able to allow the DSL modem -to drive the 2 LSBs of the cascade automatically. - - -Required properties: -- compatible : Should be "lantiq,gpio-stp-xway" -- reg : Address and length of the register set for the device -- #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify optional parameters (currently - unused). -- gpio-controller : Marks the device node as a gpio controller. - -Optional properties: -- lantiq,shadow : The default value that we shall assume as already set on the - shift register cascade. -- lantiq,groups : Set the 3 bit mask to select which of the 3 groups are enabled - in the shift register cascade. -- lantiq,dsl : The dsl core can control the 2 LSBs of the gpio cascade. This 2 bit - property can enable this feature. -- lantiq,phy1 : The gphy1 core can control 3 bits of the gpio cascade. -- lantiq,phy2 : The gphy2 core can control 3 bits of the gpio cascade. -- lantiq,rising : use rising instead of falling edge for the shift register - -Example: - -gpio1: stp@e100bb0 { - compatible = "lantiq,gpio-stp-xway"; - reg = <0xE100BB0 0x40>; - #gpio-cells = <2>; - gpio-controller; - - lantiq,shadow = <0xffff>; - lantiq,groups = <0x7>; - lantiq,dsl = <0x3>; - lantiq,phy1 = <0x7>; - lantiq,phy2 = <0x7>; - /* lantiq,rising; */ -}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-stp-xway.yaml b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.yaml new file mode 100644 index 000000000000..d565c4b63dbf --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-stp-xway.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Lantiq SoC Serial To Parallel (STP) GPIO controller + +description: | + The Serial To Parallel (STP) is found on MIPS based Lantiq socs. It is a + peripheral controller used to drive external shift register cascades. At most + 3 groups of 8 bits can be driven. The hardware is able to allow the DSL modem + and Ethernet PHYs to drive some bytes of the cascade automatically. + +maintainers: + - John Crispin <john@phrozen.org> + +properties: + $nodename: + pattern: "^gpio@[0-9a-f]+$" + + compatible: + const: lantiq,gpio-stp-xway + + reg: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + description: + The first cell is the pin number and the second cell is used to specify + consumer flags. + const: 2 + + lantiq,shadow: + description: + The default value that we shall assume as already set on the + shift register cascade. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x000000 + maximum: 0xffffff + + lantiq,groups: + description: + Set the 3 bit mask to select which of the 3 groups are enabled + in the shift register cascade. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x7 + + lantiq,dsl: + description: + The dsl core can control the 2 LSBs of the gpio cascade. This 2 bit + property can enable this feature. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x3 + + lantiq,rising: + description: + Use rising instead of falling edge for the shift register. + type: boolean + +patternProperties: + "^lantiq,phy[1-4]$": + description: + The gphy core can control 3 bits of the gpio cascade. In the xRX200 family + phy[1-2] are available, in xRX330 phy[1-3] and in XRX330 phy[1-4]. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x7 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + gpio@e100bb0 { + compatible = "lantiq,gpio-stp-xway"; + reg = <0xE100BB0 0x40>; + #gpio-cells = <2>; + gpio-controller; + + pinctrl-0 = <&stp_pins>; + pinctrl-names = "default"; + + lantiq,shadow = <0xffffff>; + lantiq,groups = <0x7>; + lantiq,dsl = <0x3>; + lantiq,phy1 = <0x7>; + lantiq,phy2 = <0x7>; + }; +... diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt deleted file mode 100644 index f693e82b4c0f..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt +++ /dev/null @@ -1,36 +0,0 @@ -Xilinx Zynq GPIO controller Device Tree Bindings -------------------------------------------- - -Required properties: -- #gpio-cells : Should be two - - First cell is the GPIO line number - - Second cell is used to specify optional - parameters (unused) -- compatible : Should be "xlnx,zynq-gpio-1.0" or - "xlnx,zynqmp-gpio-1.0" or "xlnx,versal-gpio-1.0 - or "xlnx,pmc-gpio-1.0 -- clocks : Clock specifier (see clock bindings for details) -- gpio-controller : Marks the device node as a GPIO controller. -- interrupts : Interrupt specifier (see interrupt bindings for - details) -- interrupt-controller : Marks the device node as an interrupt controller. -- #interrupt-cells : Should be 2. The first cell is the GPIO number. - The second cell bits[3:0] is used to specify trigger type and level flags: - 1 = low-to-high edge triggered. - 2 = high-to-low edge triggered. - 4 = active high level-sensitive. - 8 = active low level-sensitive. -- reg : Address and length of the register set for the device - -Example: - gpio@e000a000 { - #gpio-cells = <2>; - compatible = "xlnx,zynq-gpio-1.0"; - clocks = <&clkc 42>; - gpio-controller; - interrupt-parent = <&intc>; - interrupts = <0 20 4>; - interrupt-controller; - #interrupt-cells = <2>; - reg = <0xe000a000 0x1000>; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml new file mode 100644 index 000000000000..378da2649e66 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-zynq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq GPIO controller Device Tree Bindings + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +properties: + compatible: + const: xlnx,zynq-gpio-1.0 + + reg: + maxItems: 1 + + "#gpio-cells": + const: 2 + + interrupts: + maxItems: 1 + + gpio-controller: true + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - "#gpio-cells" + - interrupts + - gpio-controller + - interrupt-controller + - "#interrupt-cells" + - clocks + +additionalProperties: false + +examples: + - | + gpio@e000a000 { + #gpio-cells = <2>; + compatible = "xlnx,zynq-gpio-1.0"; + clocks = <&clkc 42>; + gpio-controller; + interrupt-parent = <&intc>; + interrupts = <0 20 4>; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0xe000a000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/gpio/idt,32434-gpio.yaml b/Documentation/devicetree/bindings/gpio/idt,32434-gpio.yaml new file mode 100644 index 000000000000..d38de8144656 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/idt,32434-gpio.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/idt,32434-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IDT 79RC32434 GPIO controller + +maintainers: + - Thomas Bogendoerfer <tsbogend@alpha.franken.de> + +properties: + compatible: + const: idt,32434-gpio + + reg: + maxItems: 2 + + reg-names: + items: + - const: gpio + - const: pic + + gpio-controller: true + + "#gpio-cells": + const: 2 + + ngpios: + minimum: 1 + maximum: 32 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + gpio0: gpio@50004 { + compatible = "idt,32434-gpio"; + reg = <0x50004 0x10>, <0x38030 0x0c>; + reg-names = "gpio", "pic"; + + interrupt-controller; + #interrupt-cells = <2>; + + interrupt-parent = <&cpuintc>; + interrupts = <6>; + + gpio-controller; + #gpio-cells = <2>; + + ngpios = <14>; + }; diff --git a/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml new file mode 100644 index 000000000000..f0ff66c4c74e --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/nxp,pcf8575.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PCF857x-compatible I/O expanders + +maintainers: + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + +description: + The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be + driven high by a pull-up current source or driven low to ground. This + combines the direction and output level into a single bit per line, which + can't be read back. We can't actually know at initialization time whether a + line is configured (a) as output and driving the signal low/high, or (b) as + input and reporting a low/high value, without knowing the last value written + since the chip came out of reset (if any). The only reliable solution for + setting up line direction is thus to do it explicitly. + +properties: + compatible: + enum: + - maxim,max7328 + - maxim,max7329 + - nxp,pca8574 + - nxp,pca8575 + - nxp,pca9670 + - nxp,pca9671 + - nxp,pca9672 + - nxp,pca9673 + - nxp,pca9674 + - nxp,pca9675 + - nxp,pcf8574 + - nxp,pcf8574a + - nxp,pcf8575 + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + description: + The first cell is the GPIO number and the second cell specifies GPIO + flags, as defined in <dt-bindings/gpio/gpio.h>. Only the GPIO_ACTIVE_HIGH + and GPIO_ACTIVE_LOW flags are supported. + + lines-initial-states: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Bitmask that specifies the initial state of each line. + When a bit is set to zero, the corresponding line will be initialized to + the input (pulled-up) state. + When the bit is set to one, the line will be initialized to the + low-level output state. + If the property is not specified all lines will be initialized to the + input state. + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + wakeup-source: true + +patternProperties: + "^(.+-hog(-[0-9]+)?)$": + type: object + + required: + - gpio-hog + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pcf8575: gpio@20 { + compatible = "nxp,pcf8575"; + reg = <0x20>; + interrupt-parent = <&irqpin2>; + interrupts = <3 0>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt deleted file mode 100644 index f9231df17c2b..000000000000 --- a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt +++ /dev/null @@ -1,32 +0,0 @@ -Rockchip RK3328 GRF (General Register Files) GPIO controller. - -In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec mute -control, can also be used for general purpose. It is manipulated by the -GRF_SOC_CON10 register in GRF. Aside from the GPIO_MUTE pin, the HDMI pins can -also be set in the same way. - -Currently this GPIO controller only supports the mute pin. If needed in the -future, the HDMI pins support can also be added. - -Required properties: -- compatible: Should contain "rockchip,rk3328-grf-gpio". -- gpio-controller: Marks the device node as a gpio controller. -- #gpio-cells: Should be 2. The first cell is the pin number and - the second cell is used to specify the gpio polarity: - 0 = Active high, - 1 = Active low. - -Example: - - grf: syscon@ff100000 { - compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd"; - - grf_gpio: grf-gpio { - compatible = "rockchip,rk3328-grf-gpio"; - gpio-controller; - #gpio-cells = <2>; - }; - }; - -Note: The grf_gpio node should be declared as the child of the GRF (General -Register File) node. The GPIO_MUTE pin is referred to as <&grf_gpio 0>. diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml new file mode 100644 index 000000000000..d8cce73ea0ae --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/rockchip,rk3328-grf-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3328 General Register Files GPIO controller + +description: + The Rockchip RK3328 General Register File (GRF) outputs only the + GPIO_MUTE pin, originally for codec mute control, but it can also be used + for general purpose. It is manipulated by the GRF_SOC_CON10 register. + If needed in the future support for the HDMI pins can also be added. + The GPIO node should be declared as the child of the GRF node. + + The GPIO_MUTE pin is referred to in the format + + <&grf_gpio 0 GPIO_ACTIVE_LOW> + + The first cell is the pin number and + the second cell is used to specify the GPIO polarity + 0 = Active high + 1 = Active low + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + const: rockchip,rk3328-grf-gpio + + gpio-controller: true + + "#gpio-cells": + const: 2 + +required: + - compatible + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + grf_gpio: gpio { + compatible = "rockchip,rk3328-grf-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml new file mode 100644 index 000000000000..7087e4a5013f --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/ti,omap-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OMAP GPIO controller bindings + +maintainers: + - Grygorii Strashko <grygorii.strashko@ti.com> + +description: | + The general-purpose interface combines general-purpose input/output (GPIO) banks. + Each GPIO banks provides up to 32 dedicated general-purpose pins with input + and output capabilities; interrupt generation in active mode and wake-up + request generation in idle mode upon the detection of external events. + +properties: + compatible: + oneOf: + - enum: + - ti,omap2-gpio + - ti,omap3-gpio + - ti,omap4-gpio + - items: + - const: ti,am4372-gpio + - const: ti,omap4-gpio + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + interrupts: + maxItems: 1 + + gpio-ranges: true + + gpio-line-names: + minItems: 1 + maxItems: 32 + + ti,gpio-always-on: + $ref: /schemas/types.yaml#/definitions/flag + description: + Indicates if a GPIO bank is always powered and will never lose its logic state. + + ti,hwmods: + $ref: /schemas/types.yaml#/definitions/string + 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. + + 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. + +patternProperties: + "^(.+-hog(-[0-9]+)?)$": + type: object + + required: + - gpio-hog + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - interrupt-controller + - "#interrupt-cells" + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + gpio0: gpio@0 { + compatible = "ti,omap4-gpio"; + reg = <0x0 0x1000>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <96>; + ti,gpio-always-on; + + ls-buf-en-hog { + gpio-hog; + gpios = <10 GPIO_ACTIVE_HIGH>; + output-high; + line-name = "LS_BUF_EN"; + }; + }; diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 894ba217ab32..0f73f436bea7 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - amlogic,meson-g12a-mali + - mediatek,mt8183-mali - realtek,rtd1619-mali - rockchip,px30-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable @@ -41,10 +42,13 @@ properties: mali-supply: true + sram-supply: true + operating-points-v2: true power-domains: - maxItems: 1 + minItems: 1 + maxItems: 3 resets: maxItems: 2 @@ -89,6 +93,30 @@ allOf: then: required: - resets + - if: + properties: + compatible: + contains: + const: mediatek,mt8183-mali + then: + properties: + power-domains: + minItems: 3 + power-domain-names: + items: + - const: core0 + - const: core1 + - const: core2 + + required: + - sram-supply + - power-domains + - power-domain-names + else: + properties: + power-domains: + maxItems: 1 + sram-supply: false examples: - | diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml index 9d72264fa90a..e6485f7b046f 100644 --- a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml +++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml @@ -34,7 +34,6 @@ properties: - enum: [ bridge, gca ] - enum: [ bridge, gca ] minItems: 2 - maxItems: 4 interrupts: items: diff --git a/Documentation/devicetree/bindings/gpu/vivante,gc.yaml b/Documentation/devicetree/bindings/gpu/vivante,gc.yaml index 3ed172629974..93e7244cdc0e 100644 --- a/Documentation/devicetree/bindings/gpu/vivante,gc.yaml +++ b/Documentation/devicetree/bindings/gpu/vivante,gc.yaml @@ -36,7 +36,6 @@ properties: - description: AHB/slave interface clock (only required if GPU can gate slave interface independently) minItems: 1 - maxItems: 4 clock-names: items: diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml b/Documentation/devicetree/bindings/hwmon/lm75.yaml index 96eed5cc7841..72980d083c21 100644 --- a/Documentation/devicetree/bindings/hwmon/lm75.yaml +++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml @@ -30,6 +30,7 @@ properties: - st,stds75 - st,stlm75 - microchip,tcn75 + - ti,tmp1075 - ti,tmp100 - ti,tmp101 - ti,tmp105 diff --git a/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml b/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml index 33ee575bb09d..926be9a29044 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml @@ -49,7 +49,7 @@ examples: #size-cells = <0>; adc@48 { - comatible = "ti,ads7828"; + compatible = "ti,ads7828"; reg = <0x48>; vref-supply = <&vref>; ti,differential-input; diff --git a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml new file mode 100644 index 000000000000..ea643e6c3ef5 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/aspeed,i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED I2C on the AST24XX, AST25XX, and AST26XX SoCs Device Tree Bindings + +maintainers: + - Rayn Chen <rayn_chen@aspeedtech.com> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + enum: + - aspeed,ast2400-i2c-bus + - aspeed,ast2500-i2c-bus + - aspeed,ast2600-i2c-bus + + reg: + minItems: 1 + items: + - description: address offset and range of bus + - description: address offset and range of bus buffer + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + description: + root clock of bus, should reference the APB + clock in the second cell + + resets: + maxItems: 1 + + bus-frequency: + minimum: 500 + maximum: 4000000 + default: 100000 + description: frequency of the bus clock in Hz defaults to 100 kHz when not + specified + + multi-master: + type: boolean + description: + states that there is another master active on this bus + +required: + - reg + - compatible + - clocks + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/aspeed-clock.h> + i2c0: i2c-bus@40 { + #address-cells = <1>; + #size-cells = <0>; + #interrupt-cells = <1>; + compatible = "aspeed,ast2500-i2c-bus"; + reg = <0x40 0x40>; + clocks = <&syscon ASPEED_CLK_APB>; + resets = <&syscon ASPEED_RESET_I2C>; + bus-frequency = <100000>; + interrupts = <0>; + interrupt-parent = <&i2c_ic>; + }; diff --git a/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml b/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml index edbca2476128..7070c04469ed 100644 --- a/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml @@ -21,7 +21,6 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: BSC register range - description: Auto-I2C register range diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt deleted file mode 100644 index b47f6ccb196a..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt +++ /dev/null @@ -1,49 +0,0 @@ -Device tree configuration for the I2C busses on the AST24XX, AST25XX, and AST26XX SoCs. - -Required Properties: -- #address-cells : should be 1 -- #size-cells : should be 0 -- reg : address offset and range of bus -- compatible : should be "aspeed,ast2400-i2c-bus" - or "aspeed,ast2500-i2c-bus" - or "aspeed,ast2600-i2c-bus" -- clocks : root clock of bus, should reference the APB - clock in the second cell -- resets : phandle to reset controller with the reset number in - the second cell -- interrupts : interrupt number - -Optional Properties: -- bus-frequency : frequency of the bus clock in Hz defaults to 100 kHz when not - specified -- multi-master : states that there is another master active on this bus. - -Example: - -i2c { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x1e78a000 0x1000>; - - i2c_ic: interrupt-controller@0 { - #interrupt-cells = <1>; - compatible = "aspeed,ast2400-i2c-ic"; - reg = <0x0 0x40>; - interrupts = <12>; - interrupt-controller; - }; - - i2c0: i2c-bus@40 { - #address-cells = <1>; - #size-cells = <0>; - #interrupt-cells = <1>; - reg = <0x40 0x40>; - compatible = "aspeed,ast2400-i2c-bus"; - clocks = <&syscon ASPEED_CLK_APB>; - resets = <&syscon ASPEED_RESET_I2C>; - bus-frequency = <100000>; - interrupts = <0>; - interrupt-parent = <&i2c_ic>; - }; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt index b745f3706120..6590501c53d4 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt @@ -8,7 +8,7 @@ Required properties: - reg : Offset and length of the register set for the device - clocks: I2C functional clock phandle. For 66AK2G this property should be set per binding, - Documentation/devicetree/bindings/clock/ti,sci-clk.txt + Documentation/devicetree/bindings/clock/ti,sci-clk.yaml SoC-specific Required Properties: @@ -17,7 +17,7 @@ The following are mandatory properties for Keystone 2 66AK2G SoCs only: - power-domains: Should contain a phandle to a PM domain provider node and an args specifier containing the I2C device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Recommended properties : - interrupts : standard interrupt property. diff --git a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt index 81b5d55086fa..86b2e433a969 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt @@ -27,7 +27,7 @@ Required properties: - i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C parents. -Furthermore, I2C mux properties and child nodes. See i2c-mux.txt in this +Furthermore, I2C mux properties and child nodes. See i2c-mux.yaml in this directory. Example: diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml index 7b553d559c83..98c6fcf7bf26 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml @@ -46,6 +46,13 @@ properties: description: | I2C bus timeout in microseconds + fsl,i2c-erratum-a004447: + $ref: /schemas/types.yaml#/definitions/flag + description: | + Indicates the presence of QorIQ erratum A-004447, which + says that the standard i2c recovery scheme mechanism does + not work and an alternate implementation is needed. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt index 7f0194fdd0cc..5ea216ae7084 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt @@ -15,6 +15,7 @@ Required properties: "mediatek,mt8173-i2c": for MediaTek MT8173 "mediatek,mt8183-i2c": for MediaTek MT8183 "mediatek,mt8192-i2c": for MediaTek MT8192 + "mediatek,mt8195-i2c", "mediatek,mt8192-i2c": for MediaTek MT8195 "mediatek,mt8516-i2c", "mediatek,mt2712-i2c": for MediaTek MT8516 - reg: physical base address of the controller and dma base, length of memory mapped region. @@ -32,6 +33,7 @@ Optional properties: - mediatek,have-pmic: platform can control i2c form special pmic side. Only mt6589 and mt8135 support this feature. - mediatek,use-push-pull: IO config use push-pull mode. + - vbus-supply: phandle to the regulator that provides power to SCL/SDA. Example: diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt index 21da3ecbb370..d4cf10582a26 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt @@ -22,8 +22,8 @@ Required properties: - i2c-parent: The phandle of the I2C bus that this multiplexer's master-side port is connected to. - mux-gpios: list of gpios used to control the muxer -* Standard I2C mux properties. See i2c-mux.txt in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. +* Standard I2C mux properties. See i2c-mux.yaml in this directory. +* I2C child bus nodes. See i2c-mux.yaml in this directory. Optional properties: - idle-state: value to set the muxer to when idle. When no value is @@ -62,7 +62,6 @@ Example: reg = <0x3c>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7 1>; - reset-active-low; }; }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt deleted file mode 100644 index 8b444b94e92f..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt +++ /dev/null @@ -1,99 +0,0 @@ -General Purpose I2C Bus Mux - -This binding describes an I2C bus multiplexer that uses a mux controller -from the mux subsystem to route the I2C signals. - - .-----. .-----. - | dev | | dev | - .------------. '-----' '-----' - | SoC | | | - | | .--------+--------' - | .------. | .------+ child bus A, on MUX value set to 0 - | | I2C |-|--| Mux | - | '------' | '--+---+ child bus B, on MUX value set to 1 - | .------. | | '----------+--------+--------. - | | MUX- | | | | | | - | | Ctrl |-|-----+ .-----. .-----. .-----. - | '------' | | dev | | dev | | dev | - '------------' '-----' '-----' '-----' - -Required properties: -- compatible: i2c-mux -- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side - port is connected to. -- mux-controls: The phandle of the mux controller to use for operating the - mux. -* Standard I2C mux properties. See i2c-mux.txt in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. The sub-bus number - is also the mux-controller state described in ../mux/mux-controller.txt - -Optional properties: -- mux-locked: If present, explicitly allow unrelated I2C transactions on the - parent I2C adapter at these times: - + during setup of the multiplexer - + between setup of the multiplexer and the child bus I2C transaction - + between the child bus I2C transaction and releasing of the multiplexer - + during releasing of the multiplexer - However, I2C transactions to devices behind all I2C multiplexers connected - to the same parent adapter that this multiplexer is connected to are blocked - for the full duration of the complete multiplexed I2C transaction (i.e. - including the times covered by the above list). - If mux-locked is not present, the multiplexer is assumed to be parent-locked. - This means that no unrelated I2C transactions are allowed on the parent I2C - adapter for the complete multiplexed I2C transaction. - The properties of mux-locked and parent-locked multiplexers are discussed - in more detail in Documentation/i2c/i2c-topology.rst. - -For each i2c child node, an I2C child bus will be created. They will -be numbered based on their order in the device tree. - -Whenever an access is made to a device on a child bus, the value set -in the relevant node's reg property will be set as the state in the -mux controller. - -Example: - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - i2c-mux { - compatible = "i2c-mux"; - mux-locked; - i2c-parent = <&i2c1>; - - mux-controls = <&mux>; - - #address-cells = <1>; - #size-cells = <0>; - - i2c@1 { - reg = <1>; - #address-cells = <1>; - #size-cells = <0>; - - ssd1307: oled@3c { - compatible = "solomon,ssd1307fb-i2c"; - reg = <0x3c>; - pwms = <&pwm 4 3000>; - reset-gpios = <&gpio2 7 1>; - reset-active-low; - }; - }; - - i2c@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - pca9555: pca9555@20 { - compatible = "nxp,pca9555"; - gpio-controller; - #gpio-cells = <2>; - reg = <0x20>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml new file mode 100644 index 000000000000..9b0603a72f40 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mux-gpmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: General Purpose I2C Bus Mux + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: |+ + This binding describes an I2C bus multiplexer that uses a mux controller + from the mux subsystem to route the I2C signals. + + .-----. .-----. + | dev | | dev | + .------------. '-----' '-----' + | SoC | | | + | | .--------+--------' + | .------. | .------+ child bus A, on MUX value set to 0 + | | I2C |-|--| Mux | + | '------' | '--+---+ child bus B, on MUX value set to 1 + | .------. | | '----------+--------+--------. + | | MUX- | | | | | | + | | Ctrl |-|-----+ .-----. .-----. .-----. + | '------' | | dev | | dev | | dev | + '------------' '-----' '-----' '-----' + + + +allOf: + - $ref: /schemas/i2c/i2c-mux.yaml# + +properties: + compatible: + const: i2c-mux + + i2c-parent: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the I2C bus that this multiplexer's master-side port is + connected to. + + mux-controls: + maxItems: 1 + description: + The mux-controller states are the I2C sub-bus numbers. + + mux-locked: + type: boolean + description: | + Explicitly allow unrelated I2C transactions on the parent I2C adapter at + these times: + - during setup of the multiplexer + - between setup of the multiplexer and the child bus I2C transaction + - between the child bus I2C transaction and releasing of the multiplexer + - during releasing of the multiplexer + + However, I2C transactions to devices behind all I2C multiplexers connected + to the same parent adapter that this multiplexer is connected to are blocked + for the full duration of the complete multiplexed I2C transaction (i.e. + including the times covered by the above list). + If mux-locked is not present, the multiplexer is assumed to be parent-locked. + This means that no unrelated I2C transactions are allowed on the parent I2C + adapter for the complete multiplexed I2C transaction. + The properties of mux-locked and parent-locked multiplexers are discussed + in more detail in Documentation/i2c/i2c-topology.rst. + +required: + - compatible + - i2c-parent + - mux-controls + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + i2c-mux { + compatible = "i2c-mux"; + mux-locked; + i2c-parent = <&i2c1>; + + mux-controls = <&mux>; + + #address-cells = <1>; + #size-cells = <0>; + + i2c@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt index 8b1e49cdce3f..29c4550c9782 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt @@ -8,8 +8,8 @@ Required Properties: The following required properties are defined externally: - - Standard I2C mux properties. See i2c-mux.txt in this directory. - - I2C child bus nodes. See i2c-mux.txt in this directory. + - Standard I2C mux properties. See i2c-mux.yaml in this directory. + - I2C child bus nodes. See i2c-mux.yaml in this directory. Optional Properties: diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt deleted file mode 100644 index 7abda506b828..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt +++ /dev/null @@ -1,74 +0,0 @@ -* NXP PCA954x I2C bus switch - -The driver supports NXP PCA954x and PCA984x I2C mux/switch devices. - -Required Properties: - - - compatible: Must contain one of the following. - "nxp,pca9540", - "nxp,pca9542", - "nxp,pca9543", - "nxp,pca9544", - "nxp,pca9545", - "nxp,pca9546", "nxp,pca9846", - "nxp,pca9547", "nxp,pca9847", - "nxp,pca9548", "nxp,pca9848", - "nxp,pca9849" - - - reg: The I2C address of the device. - - The following required properties are defined externally: - - - Standard I2C mux properties. See i2c-mux.txt in this directory. - - I2C child bus nodes. See i2c-mux.txt in this directory. - -Optional Properties: - - - reset-gpios: Reference to the GPIO connected to the reset input. - - idle-state: if present, overrides i2c-mux-idle-disconnect, - Please refer to Documentation/devicetree/bindings/mux/mux-controller.txt - - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all - children in idle state. This is necessary for example, if there are several - multiplexers on the bus and the devices behind them use same I2C addresses. - - interrupts: Interrupt mapping for IRQ. - - interrupt-controller: Marks the device node as an interrupt controller. - - #interrupt-cells : Should be two. - - first cell is the pin number - - second cell is used to specify flags. - See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - -Example: - - i2c-switch@74 { - compatible = "nxp,pca9548"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x74>; - - interrupt-parent = <&ipic>; - interrupts = <17 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <2>; - - i2c@2 { - #address-cells = <1>; - #size-cells = <0>; - reg = <2>; - - eeprom@54 { - compatible = "atmel,24c08"; - reg = <0x54>; - }; - }; - - i2c@4 { - #address-cells = <1>; - #size-cells = <0>; - reg = <4>; - - rtc@51 { - compatible = "nxp,pcf8563"; - reg = <0x51>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml new file mode 100644 index 000000000000..9f1726d0356b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mux-pca954x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP PCA954x I2C bus switch + +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# + +properties: + compatible: + oneOf: + - enum: + - nxp,pca9540 + - nxp,pca9542 + - nxp,pca9543 + - nxp,pca9544 + - nxp,pca9545 + - nxp,pca9546 + - nxp,pca9547 + - nxp,pca9548 + - nxp,pca9846 + - nxp,pca9847 + - nxp,pca9848 + - nxp,pca9849 + - items: + - const: nxp,pca9646 + - const: nxp,pca9546 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#interrupt-cells": + const: 2 + + interrupt-controller: true + + reset-gpios: + maxItems: 1 + + i2c-mux-idle-disconnect: + type: boolean + description: Forces mux to disconnect all children in idle state. This is + necessary for example, if there are several multiplexers on the bus and + the devices behind them use same I2C addresses. + + idle-state: + description: if present, overrides i2c-mux-idle-disconnect + $ref: /schemas/mux/mux-controller.yaml#/properties/idle-state + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + i2c-mux@74 { + compatible = "nxp,pca9548"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x74>; + + interrupt-parent = <&ipic>; + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <2>; + + i2c@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + + eeprom@54 { + compatible = "atmel,24c08"; + reg = <0x54>; + }; + }; + + i2c@4 { + #address-cells = <1>; + #size-cells = <0>; + reg = <4>; + + rtc@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt index 33119a98e144..997a287ed3f6 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt @@ -28,9 +28,9 @@ Also required are: * Standard pinctrl properties that specify the pin mux state for each child bus. See ../pinctrl/pinctrl-bindings.txt. -* Standard I2C mux properties. See i2c-mux.txt in this directory. +* Standard I2C mux properties. See i2c-mux.yaml in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. +* I2C child bus nodes. See i2c-mux.yaml in this directory. For each named state defined in the pinctrl-names property, an I2C child bus will be created. I2C child bus numbers are assigned based on the index into diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt index de00d7fc450b..b9d9755e4172 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt @@ -7,8 +7,8 @@ Required properties: - compatible: i2c-mux-reg - i2c-parent: The phandle of the I2C bus that this multiplexer's master-side port is connected to. -* Standard I2C mux properties. See i2c-mux.txt in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. +* Standard I2C mux properties. See i2c-mux.yaml in this directory. +* I2C child bus nodes. See i2c-mux.yaml in this directory. Optional properties: - reg: this pair of <offset size> specifies the register to control the mux. diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux.txt b/Documentation/devicetree/bindings/i2c/i2c-mux.txt deleted file mode 100644 index b38f58a1c878..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mux.txt +++ /dev/null @@ -1,73 +0,0 @@ -Common i2c bus multiplexer/switch properties. - -An i2c bus multiplexer/switch will have several child busses that are -numbered uniquely in a device dependent manner. The nodes for an i2c bus -multiplexer/switch will have one child node for each child bus. - -Optional properties: -- #address-cells = <1>; - This property is required if the i2c-mux child node does not exist. - -- #size-cells = <0>; - This property is required if the i2c-mux child node does not exist. - -- i2c-mux - For i2c multiplexers/switches that have child nodes that are a mixture - of both i2c child busses and other child nodes, the 'i2c-mux' subnode - can be used for populating the i2c child busses. If an 'i2c-mux' - subnode is present, only subnodes of this will be considered as i2c - child busses. - -Required properties for the i2c-mux child node: -- #address-cells = <1>; -- #size-cells = <0>; - -Required properties for i2c child bus nodes: -- #address-cells = <1>; -- #size-cells = <0>; -- reg : The sub-bus number. - -Optional properties for i2c child bus nodes: -- Other properties specific to the multiplexer/switch hardware. -- Child nodes conforming to i2c bus binding - - -Example : - - /* - An NXP pca9548 8 channel I2C multiplexer at address 0x70 - with two NXP pca8574 GPIO expanders attached, one each to - ports 3 and 4. - */ - - mux@70 { - compatible = "nxp,pca9548"; - reg = <0x70>; - #address-cells = <1>; - #size-cells = <0>; - - i2c@3 { - #address-cells = <1>; - #size-cells = <0>; - reg = <3>; - - gpio1: gpio@38 { - compatible = "nxp,pca8574"; - reg = <0x38>; - #gpio-cells = <2>; - gpio-controller; - }; - }; - i2c@4 { - #address-cells = <1>; - #size-cells = <0>; - reg = <4>; - - gpio2: gpio@38 { - compatible = "nxp,pca8574"; - reg = <0x38>; - #gpio-cells = <2>; - gpio-controller; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux.yaml new file mode 100644 index 000000000000..24cac36037f5 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common i2c bus multiplexer/switch properties. + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: |+ + An i2c bus multiplexer/switch will have several child busses that are numbered + uniquely in a device dependent manner. The nodes for an i2c bus + multiplexer/switch will have one child node for each child bus. + + For i2c multiplexers/switches that have child nodes that are a mixture of both + i2c child busses and other child nodes, the 'i2c-mux' subnode can be used for + populating the i2c child busses. If an 'i2c-mux' subnode is present, only + subnodes of this will be considered as i2c child busses. + +properties: + $nodename: + pattern: '^(i2c-?)?mux' + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + '^i2c@[0-9a-f]+$': + $ref: /schemas/i2c/i2c-controller.yaml + unevaluatedProperties: false + + properties: + reg: + description: The mux selector sub-bus number for the child I2C bus. + maxItems: 1 + +additionalProperties: true + +examples: + - | + /* + * An NXP pca9548 8 channel I2C multiplexer at address 0x70 + * with two NXP pca8574 GPIO expanders attached, one each to + * ports 3 and 4. + */ + i2c { + #address-cells = <1>; + #size-cells = <0>; + + i2c-mux@70 { + compatible = "nxp,pca9548"; + reg = <0x70>; + #address-cells = <1>; + #size-cells = <0>; + + i2c@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + i2c@4 { + #address-cells = <1>; + #size-cells = <0>; + reg = <4>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/i2c/i2c-omap.txt b/Documentation/devicetree/bindings/i2c/i2c-omap.txt deleted file mode 100644 index a425b91af48f..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-omap.txt +++ /dev/null @@ -1,37 +0,0 @@ -I2C for OMAP platforms - -Required properties : -- compatible : Must be - "ti,omap2420-i2c" for OMAP2420 SoCs - "ti,omap2430-i2c" for OMAP2430 SoCs - "ti,omap3-i2c" for OMAP3 SoCs - "ti,omap4-i2c" for OMAP4+ SoCs - "ti,am654-i2c", "ti,omap4-i2c" for AM654 SoCs - "ti,j721e-i2c", "ti,omap4-i2c" for J721E SoCs - "ti,am64-i2c", "ti,omap4-i2c" for AM64 SoCs -- ti,hwmods : Must be "i2c<n>", n being the instance number (1-based) -- #address-cells = <1>; -- #size-cells = <0>; - -Recommended properties : -- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise - the default 100 kHz frequency will be used. - -Optional properties: -- Child nodes conforming to i2c bus binding - -Note: Current implementation will fetch base address, irq and dma -from omap hwmod data base during device registration. -Future plan is to migrate hwmod data base contents into device tree -blob so that, all the required data will be used from device tree dts -file. - -Examples : - -i2c1: i2c@0 { - compatible = "ti,omap3-i2c"; - #address-cells = <1>; - #size-cells = <0>; - ti,hwmods = "i2c1"; - clock-frequency = <400000>; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt index 569b16248514..1ff6f8487a2d 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt @@ -71,7 +71,7 @@ This is an example which is used on FalconFalls: /* This I2C controller has one gpio controller */ gpio@26 { #gpio-cells = <2>; - compatible = "ti,pcf8575"; + compatible = "nxp,pcf8575"; reg = <0x26>; gpio-controller; }; @@ -85,7 +85,7 @@ This is an example which is used on FalconFalls: gpio@26 { #gpio-cells = <2>; - compatible = "ti,pcf8575"; + compatible = "nxp,pcf8575"; reg = <0x26>; gpio-controller; }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt index c6668b7c66e6..7b9fc0c22eaf 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt @@ -9,6 +9,7 @@ PROPERTIES: "qcom,msm8916-cci" "qcom,msm8996-cci" "qcom,sdm845-cci" + "qcom,sm8250-cci" - reg Usage: required @@ -41,8 +42,8 @@ PROPERTIES: SUBNODES: -The CCI provides I2C masters for one (msm8916) or two i2c busses (msm8996 and -sdm845), described as subdevices named "i2c-bus@0" and "i2c-bus@1". +The CCI provides I2C masters for one (msm8916) or two i2c busses (msm8996, +sdm845 and sm8250), described as subdevices named "i2c-bus@0" and "i2c-bus@1". PROPERTIES: diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml index 7f254d79558c..5339dd4fc370 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml @@ -36,6 +36,7 @@ properties: - rockchip,px30-i2c - rockchip,rk3308-i2c - rockchip,rk3328-i2c + - rockchip,rk3568-i2c - const: rockchip,rk3399-i2c reg: diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index df41f72afc87..b864916e087f 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -89,8 +89,11 @@ wants to support one of the below features, it should adapt these bindings. - smbus states that additional SMBus restrictions and features apply to this bus. - Examples of features are SMBusHostNotify and SMBusAlert. Examples of - restrictions are more reserved addresses and timeout definitions. + An example of feature is SMBusHostNotify. Examples of restrictions are + more reserved addresses and timeout definitions. + +- smbus-alert + states that the optional SMBus-Alert feature apply to this bus. Required properties (per child device) -------------------------------------- diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml index eb72dd571def..f771c09aabfc 100644 --- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml @@ -43,14 +43,12 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Reference clock for the I2C bus - description: Bus clock (Only for Armada 7K/8K) clock-names: minItems: 1 - maxItems: 2 items: - const: core - const: reg diff --git a/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml b/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml index d2b401d062b9..93198d5d43a6 100644 --- a/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml +++ b/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml @@ -20,7 +20,6 @@ properties: reg: minItems: 3 - maxItems: 4 items: - description: Smbus block registers - description: Cause master registers diff --git a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt deleted file mode 100644 index 5762d2d1ab9c..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt +++ /dev/null @@ -1,67 +0,0 @@ -I2C for R-Car platforms - -Required properties: -- compatible: - "renesas,i2c-r8a7742" if the device is a part of a R8A7742 SoC. - "renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC. - "renesas,i2c-r8a7744" if the device is a part of a R8A7744 SoC. - "renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC. - "renesas,i2c-r8a77470" if the device is a part of a R8A77470 SoC. - "renesas,i2c-r8a774a1" if the device is a part of a R8A774A1 SoC. - "renesas,i2c-r8a774b1" if the device is a part of a R8A774B1 SoC. - "renesas,i2c-r8a774c0" if the device is a part of a R8A774C0 SoC. - "renesas,i2c-r8a774e1" if the device is a part of a R8A774E1 SoC. - "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC. - "renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC. - "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC. - "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC. - "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC. - "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC. - "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC. - "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC. - "renesas,i2c-r8a7796" if the device is a part of a R8A77960 SoC. - "renesas,i2c-r8a77961" if the device is a part of a R8A77961 SoC. - "renesas,i2c-r8a77965" if the device is a part of a R8A77965 SoC. - "renesas,i2c-r8a77970" if the device is a part of a R8A77970 SoC. - "renesas,i2c-r8a77980" if the device is a part of a R8A77980 SoC. - "renesas,i2c-r8a77990" if the device is a part of a R8A77990 SoC. - "renesas,i2c-r8a77995" if the device is a part of a R8A77995 SoC. - "renesas,i2c-r8a779a0" if the device is a part of a R8A779A0 SoC. - "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device. - "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 or RZ/G1 compatible - device. - "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 or RZ/G2 compatible - device. - "renesas,i2c-rcar" (deprecated) - - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first followed - by the generic version. - -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: interrupt specifier. - -Optional properties: -- clock-frequency: desired I2C bus clock frequency in Hz. The absence of this - property indicates the default frequency 100 kHz. -- clocks: clock specifier. -- dmas: Must contain a list of two references to DMA specifiers, one for - transmission, and one for reception. -- dma-names: Must contain a list of two DMA names, "tx" and "rx". - -- i2c-scl-falling-time-ns: see i2c.txt -- i2c-scl-internal-delay-ns: see i2c.txt -- i2c-scl-rising-time-ns: see i2c.txt - -Examples : - -i2c0: i2c@e6508000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c"; - reg = <0 0xe6508000 0 0x40>; - interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp9_clks R8A7791_CLK_I2C0>; - clock-frequency = <400000>; -}; diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt deleted file mode 100644 index 5ed1ea1c7e14..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt +++ /dev/null @@ -1,22 +0,0 @@ -Device tree configuration for Renesas EMEV2 IIC controller - -Required properties: -- compatible : "renesas,iic-emev2" -- reg : address start and address range size of device -- interrupts : specifier for the IIC controller interrupt -- clocks : phandle to the IP core SCLK -- clock-names : must be "sclk" -- #address-cells : should be <1> -- #size-cells : should be <0> - -Example: - - iic0: i2c@e0070000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "renesas,iic-emev2"; - reg = <0xe0070000 0x28>; - interrupts = <0 32 IRQ_TYPE_EDGE_RISING>; - clocks = <&iic0_sclk>; - clock-names = "sclk"; - }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml new file mode 100644 index 000000000000..17c1102562be --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,iic-emev2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas EMMA Mobile EV2 IIC Interface + +maintainers: + - Wolfram Sang <wsa+renesas@sang-engineering.com> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + const: renesas,iic-emev2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: sclk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - '#address-cells' + - '#size-cells' + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + iic0: i2c@e0070000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "renesas,iic-emev2"; + reg = <0xe0070000 0x28>; + interrupts = <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>; + clocks = <&iic0_sclk>; + clock-names = "sclk"; + }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic.txt b/Documentation/devicetree/bindings/i2c/renesas,iic.txt deleted file mode 100644 index 93d412832e66..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,iic.txt +++ /dev/null @@ -1,72 +0,0 @@ -Device tree configuration for Renesas IIC (sh_mobile) driver - -Required properties: -- compatible : - - "renesas,iic-r8a73a4" (R-Mobile APE6) - - "renesas,iic-r8a7740" (R-Mobile A1) - - "renesas,iic-r8a7742" (RZ/G1H) - - "renesas,iic-r8a7743" (RZ/G1M) - - "renesas,iic-r8a7744" (RZ/G1N) - - "renesas,iic-r8a7745" (RZ/G1E) - - "renesas,iic-r8a774a1" (RZ/G2M) - - "renesas,iic-r8a774b1" (RZ/G2N) - - "renesas,iic-r8a774c0" (RZ/G2E) - - "renesas,iic-r8a774e1" (RZ/G2H) - - "renesas,iic-r8a7790" (R-Car H2) - - "renesas,iic-r8a7791" (R-Car M2-W) - - "renesas,iic-r8a7792" (R-Car V2H) - - "renesas,iic-r8a7793" (R-Car M2-N) - - "renesas,iic-r8a7794" (R-Car E2) - - "renesas,iic-r8a7795" (R-Car H3) - - "renesas,iic-r8a7796" (R-Car M3-W) - - "renesas,iic-r8a77961" (R-Car M3-W+) - - "renesas,iic-r8a77965" (R-Car M3-N) - - "renesas,iic-r8a77990" (R-Car E3) - - "renesas,iic-sh73a0" (SH-Mobile AG5) - - "renesas,rcar-gen2-iic" (generic R-Car Gen2 or RZ/G1 - compatible device) - - "renesas,rcar-gen3-iic" (generic R-Car Gen3 or RZ/G2 - compatible device) - - "renesas,rmobile-iic" (generic device) - - When compatible with a generic R-Car version, nodes - must list the SoC-specific version corresponding to - the platform first followed by the generic R-Car - version. - - When compatible with "renesas,rmobile-iic" it should - be the last compatibility string listed. - - The r8a77990 (R-Car E3) and r8a774c0 (RZ/G2E) - controllers are not considered compatible with - "renesas,rcar-gen3-iic" or "renesas,rmobile-iic" - due to the absence of automatic transmission registers. - -- reg : address start and address range size of device -- interrupts : interrupt of device -- clocks : clock for device -- #address-cells : should be <1> -- #size-cells : should be <0> - -Optional properties: -- clock-frequency : frequency of bus clock in Hz. Default 100kHz if unset. -- dmas : Must contain a list of two references to DMA - specifiers, one for transmission, and one for - reception. -- dma-names : Must contain a list of two DMA names, "tx" and "rx". - - -Pinctrl properties might be needed, too. See there. - -Example: - - iic0: i2c@e6500000 { - compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic", - "renesas,rmobile-iic"; - reg = <0 0xe6500000 0 0x425>; - interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp3_clks R8A7790_CLK_IIC0>; - clock-frequency = <400000>; - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml new file mode 100644 index 000000000000..052aad44e781 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,rcar-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car I2C Controller + +maintainers: + - Wolfram Sang <wsa+renesas@sang-engineering.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,i2c-r8a7778 # R-Car M1A + - renesas,i2c-r8a7779 # R-Car H1 + - const: renesas,rcar-gen1-i2c # R-Car Gen1 + + - items: + - enum: + - renesas,i2c-r8a7742 # RZ/G1H + - renesas,i2c-r8a7743 # RZ/G1M + - renesas,i2c-r8a7744 # RZ/G1N + - renesas,i2c-r8a7745 # RZ/G1E + - renesas,i2c-r8a77470 # RZ/G1C + - renesas,i2c-r8a7790 # R-Car H2 + - renesas,i2c-r8a7791 # R-Car M2-W + - renesas,i2c-r8a7792 # R-Car V2H + - renesas,i2c-r8a7793 # R-Car M2-N + - renesas,i2c-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-i2c # R-Car Gen2 and RZ/G1 + + - items: + - enum: + - renesas,i2c-r8a774a1 # RZ/G2M + - renesas,i2c-r8a774b1 # RZ/G2N + - renesas,i2c-r8a774c0 # RZ/G2E + - renesas,i2c-r8a774e1 # RZ/G2H + - renesas,i2c-r8a7795 # R-Car H3 + - renesas,i2c-r8a7796 # R-Car M3-W + - renesas,i2c-r8a77961 # R-Car M3-W+ + - renesas,i2c-r8a77965 # R-Car M3-N + - renesas,i2c-r8a77970 # R-Car V3M + - renesas,i2c-r8a77980 # R-Car V3H + - renesas,i2c-r8a77990 # R-Car E3 + - renesas,i2c-r8a77995 # R-Car D3 + - renesas,i2c-r8a779a0 # R-Car V3U + - const: renesas,rcar-gen3-i2c # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-frequency: + description: + Desired I2C bus clock frequency in Hz. The absence of this property + indicates the default frequency 100 kHz. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + minItems: 2 + maxItems: 4 + description: + Must contain a list of pairs of references to DMA specifiers, one for + transmission, and one for reception. + + dma-names: + minItems: 2 + maxItems: 4 + items: + enum: + - tx + - rx + + i2c-scl-falling-time-ns: + default: 35 + description: + Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C + specification. + + i2c-scl-internal-delay-ns: + default: 50 + description: + Number of nanoseconds the IP core additionally needs to setup SCL. + + i2c-scl-rising-time-ns: + default: 200 + description: + Number of nanoseconds the SCL signal takes to rise; t(r) in the I2C + specification. + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - '#address-cells' + - '#size-cells' + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen1-i2c + - renesas,rcar-gen2-i2c + then: + properties: + dmas: false + dma-names: false + + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen2-i2c + - renesas,rcar-gen3-i2c + then: + required: + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7791-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7791-sysc.h> + + i2c0: i2c@e6508000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c"; + reg = <0xe6508000 0x40>; + interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <400000>; + clocks = <&cpg CPG_MOD 931>; + power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; + resets = <&cpg 931>; + i2c-scl-internal-delay-ns = <6>; + }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.txt b/Documentation/devicetree/bindings/i2c/renesas,riic.txt deleted file mode 100644 index e26fe3ad86a9..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.txt +++ /dev/null @@ -1,32 +0,0 @@ -Device tree configuration for Renesas RIIC driver - -Required properties: -- compatible : - "renesas,riic-r7s72100" if the device is a part of a R7S72100 SoC. - "renesas,riic-r7s9210" if the device is a part of a R7S9210 SoC. - "renesas,riic-rz" for a generic RZ/A compatible device. -- reg : address start and address range size of device -- interrupts : 8 interrupts (TEI, RI, TI, SPI, STI, NAKI, ALI, TMOI) -- clock-frequency : frequency of bus clock in Hz -- #address-cells : should be <1> -- #size-cells : should be <0> - -Pinctrl properties might be needed, too. See there. - -Example: - - i2c0: i2c@fcfee000 { - compatible = "renesas,riic-r7s72100", "renesas,riic-rz"; - reg = <0xfcfee000 0x44>; - interrupts = <0 157 IRQ_TYPE_LEVEL_HIGH>, - <0 158 IRQ_TYPE_EDGE_RISING>, - <0 159 IRQ_TYPE_EDGE_RISING>, - <0 160 IRQ_TYPE_LEVEL_HIGH>, - <0 161 IRQ_TYPE_LEVEL_HIGH>, - <0 162 IRQ_TYPE_LEVEL_HIGH>, - <0 163 IRQ_TYPE_LEVEL_HIGH>, - <0 164 IRQ_TYPE_LEVEL_HIGH>; - clock-frequency = <100000>; - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml new file mode 100644 index 000000000000..52d92ec7ec0b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,riic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/A and RZ/G2L I2C Bus Interface (RIIC) + +maintainers: + - Chris Brandt <chris.brandt@renesas.com> + - Wolfram Sang <wsa+renesas@sang-engineering.com> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + items: + - enum: + - renesas,riic-r7s72100 # RZ/A1H + - renesas,riic-r7s9210 # RZ/A2M + - renesas,riic-r9a07g044 # RZ/G2{L,LC} + - const: renesas,riic-rz # RZ/A or RZ/G2L + + reg: + maxItems: 1 + + interrupts: + items: + - description: Transmit End Interrupt (TEI) + - description: Receive Data Full Interrupt (RI) + - description: Transmit Data Empty Interrupt (TI) + - description: Stop Condition Detection Interrupt (SPI) + - description: Start Condition Detection Interrupt (STI) + - description: NACK Reception Interrupt (NAKI) + - description: Arbitration-Lost Interrupt (ALI) + - description: Timeout Interrupt (TMOI) + + clock-frequency: + description: + Desired I2C bus clock frequency in Hz. The absence of this property + indicates the default frequency 100 kHz. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-frequency + - power-domains + - '#address-cells' + - '#size-cells' + +if: + properties: + compatible: + contains: + enum: + - renesas,riic-r9a07g044 +then: + required: + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r7s72100-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2c0: i2c@fcfee000 { + compatible = "renesas,riic-r7s72100", "renesas,riic-rz"; + reg = <0xfcfee000 0x44>; + interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 158 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 159 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp9_clks R7S72100_CLK_I2C0>; + clock-frequency = <100000>; + power-domains = <&cpg_clocks>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml b/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml new file mode 100644 index 000000000000..04e4ffd80bc0 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml @@ -0,0 +1,149 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,rmobile-iic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Mobile I2C Bus Interface (IIC) + +maintainers: + - Wolfram Sang <wsa+renesas@sang-engineering.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,iic-r8a73a4 # R-Mobile APE6 + - renesas,iic-r8a7740 # R-Mobile A1 + - renesas,iic-sh73a0 # SH-Mobile AG5 + - const: renesas,rmobile-iic # Generic + + - items: + - enum: + - renesas,iic-r8a7742 # RZ/G1H + - renesas,iic-r8a7743 # RZ/G1M + - renesas,iic-r8a7744 # RZ/G1N + - renesas,iic-r8a7745 # RZ/G1E + - renesas,iic-r8a7790 # R-Car H2 + - renesas,iic-r8a7791 # R-Car M2-W + - renesas,iic-r8a7792 # R-Car V2H + - renesas,iic-r8a7793 # R-Car M2-N + - renesas,iic-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-iic # R-Car Gen2 and RZ/G1 + - const: renesas,rmobile-iic # Generic + + - items: + - enum: + - renesas,iic-r8a774a1 # RZ/G2M + - renesas,iic-r8a774b1 # RZ/G2N + - renesas,iic-r8a774c0 # RZ/G2E + - renesas,iic-r8a774e1 # RZ/G2H + - renesas,iic-r8a7795 # R-Car H3 + - renesas,iic-r8a7796 # R-Car M3-W + - renesas,iic-r8a77961 # R-Car M3-W+ + - renesas,iic-r8a77965 # R-Car M3-N + - renesas,iic-r8a77990 # R-Car E3 + - const: renesas,rcar-gen3-iic # R-Car Gen3 and RZ/G2 + - const: renesas,rmobile-iic # Generic + + reg: + maxItems: 1 + + interrupts: true + + clock-frequency: + description: + Desired I2C bus clock frequency in Hz. The absence of this property + indicates the default frequency 100 kHz. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + minItems: 2 + maxItems: 4 + description: + Must contain a list of pairs of references to DMA specifiers, one for + transmission, and one for reception. + + dma-names: + minItems: 2 + maxItems: 4 + items: + enum: + - tx + - rx + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - '#address-cells' + - '#size-cells' + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + + - if: + properties: + compatible: + contains: + enum: + - renesas,iic-r8a7740 + - renesas,iic-sh73a0 + then: + properties: + interrupts: + items: + - description: Arbitration Lost Interrupt (ALI) + - description: Non-acknowledge Detection Interrupt (TACKI) + - description: Wait Interrupt (WAITI) + - description: Data Transmit Enable interrupt (DTEI) + else: + properties: + interrupts: + items: + - description: Single combined interrupt + + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen2-iic + - renesas,rcar-gen3-iic + then: + required: + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7790-sysc.h> + + iic0: i2c@e6500000 { + compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic", + "renesas,rmobile-iic"; + reg = <0xe6500000 0x425>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 318>; + clock-frequency = <400000>; + dmas = <&dmac0 0x61>, <&dmac0 0x62>, <&dmac1 0x61>, <&dmac1 0x62>; + dma-names = "tx", "rx", "tx", "rx"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 318>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml new file mode 100644 index 000000000000..ff165ad1bee8 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/ti,omap4-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for I2C controllers on TI's OMAP and K3 SoCs + +maintainers: + - Vignesh Raghavendra <vigneshr@ti.com> + +properties: + compatible: + oneOf: + - enum: + - ti,omap2420-i2c + - ti,omap2430-i2c + - ti,omap3-i2c + - ti,omap4-i2c + - items: + - enum: + - ti,am4372-i2c + - ti,am64-i2c + - ti,am654-i2c + - ti,j721e-i2c + - const: ti,omap4-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: fck + + clock-frequency: true + + power-domains: true + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + ti,hwmods: + description: + Must be "i2c<n>", n being the instance number (1-based). + This property is applicable only on legacy platforms mainly omap2/3 + and ti81xx and should not be used on other platforms. + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + +# subnode's properties +patternProperties: + "@[0-9a-f]+$": + type: object + description: + Flash device uses the below defined properties in the subnode. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +if: + properties: + compatible: + oneOf: + - const: ti,omap2420-i2c + - const: ti,omap2430-i2c + - const: ti,omap3-i2c + - const: ti,omap4-i2c + +then: + properties: + ti,hwmods: + items: + - pattern: "^i2c([1-9])$" + +else: + properties: + ti,hwmods: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + main_i2c0: i2c@2000000 { + compatible = "ti,j721e-i2c", "ti,omap4-i2c"; + reg = <0x2000000 0x100>; + interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml index 3be8955587e4..7e8328e9ce13 100644 --- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml @@ -41,7 +41,6 @@ properties: clock-names: minItems: 2 - maxItems: 4 items: - const: clkin - const: core diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml index 6f2398cdc82d..733351dee252 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml @@ -38,14 +38,12 @@ properties: dfsdm clock can also feed CLKOUT, when CLKOUT is used. - description: audio clock can be used as an alternate to feed CLKOUT. minItems: 1 - maxItems: 2 clock-names: items: - const: dfsdm - const: audio minItems: 1 - maxItems: 2 "#address-cells": const: 1 @@ -102,7 +100,6 @@ patternProperties: st,adc-channel-names: description: List of single-ended channel names. - $ref: /schemas/types.yaml#/definitions/string-array st,filter-order: description: | diff --git a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt deleted file mode 100644 index 89647d714387..000000000000 --- a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt +++ /dev/null @@ -1,39 +0,0 @@ -I/O channel multiplexer bindings - -If a multiplexer is used to select which hardware signal is fed to -e.g. an ADC channel, these bindings describe that situation. - -Required properties: -- compatible : "io-channel-mux" -- io-channels : Channel node of the parent channel that has multiplexed - input. -- io-channel-names : Should be "parent". -- #address-cells = <1>; -- #size-cells = <0>; -- mux-controls : Mux controller node to use for operating the mux -- channels : List of strings, labeling the mux controller states. - -For each non-empty string in the channels property, an io-channel will -be created. The number of this io-channel is the same as the index into -the list of strings in the channels property, and also matches the mux -controller state. The mux controller state is described in -../mux/mux-controller.txt - -Example: - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - - channels = "sync", "in", "system-regulator"; - }; diff --git a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml new file mode 100644 index 000000000000..870b043406d8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/multiplexer/io-channel-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: I/O channel multiplexer bindings + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: | + If a multiplexer is used to select which hardware signal is fed to + e.g. an ADC channel, these bindings describe that situation. + + For each non-empty string in the channels property, an io-channel will be + created. The number of this io-channel is the same as the index into the list + of strings in the channels property, and also matches the mux controller + state. The mux controller state is described in + Documentation/devicetree/bindings/mux/mux-controller.yaml + +properties: + + compatible: + const: io-channel-mux + + io-channels: + maxItems: 1 + description: Channel node of the parent channel that has multiplexed input. + + io-channel-names: + const: parent + + mux-controls: true + mux-control-names: true + + channels: + $ref: /schemas/types.yaml#/definitions/string-array + description: + List of strings, labeling the mux controller states. + +required: + - compatible + - io-channels + - io-channel-names + - mux-controls + - channels + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux>; + channels = "sync", "in", "system-regulator"; + }; +... diff --git a/Documentation/devicetree/bindings/input/fsl-mma8450.txt b/Documentation/devicetree/bindings/input/fsl-mma8450.txt deleted file mode 100644 index 0b96e5737d3a..000000000000 --- a/Documentation/devicetree/bindings/input/fsl-mma8450.txt +++ /dev/null @@ -1,12 +0,0 @@ -* Freescale MMA8450 3-Axis Accelerometer - -Required properties: -- compatible : "fsl,mma8450". -- reg: the I2C address of MMA8450 - -Example: - -accelerometer: mma8450@1c { - compatible = "fsl,mma8450"; - reg = <0x1c>; -}; diff --git a/Documentation/devicetree/bindings/input/input.yaml b/Documentation/devicetree/bindings/input/input.yaml index 74244d21d2b3..d41d8743aad4 100644 --- a/Documentation/devicetree/bindings/input/input.yaml +++ b/Documentation/devicetree/bindings/input/input.yaml @@ -38,6 +38,5 @@ properties: Duration in seconds which the key should be kept pressed for device to reset automatically. Device with key pressed reset feature can specify this property. - $ref: /schemas/types.yaml#/definitions/uint32 additionalProperties: true diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt index 34ab5763f494..6cd08bca2c66 100644 --- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt +++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt @@ -8,6 +8,8 @@ PROPERTIES Definition: must be one of: "qcom,pm8941-pwrkey" "qcom,pm8941-resin" + "qcom,pmk8350-pwrkey" + "qcom,pmk8350-resin" - reg: Usage: required diff --git a/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml b/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml new file mode 100644 index 000000000000..762e56ee90cd --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml @@ -0,0 +1,148 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/cypress,cy8ctma340.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cypress CY8CTMA340 series touchscreen controller bindings + +description: The Cypress CY8CTMA340 series (also known as "CYTTSP" after + the marketing name Cypress TrueTouch Standard Product) touchscreens can + be connected to either I2C or SPI buses. + +maintainers: + - Javier Martinez Canillas <javier@dowhile0.org> + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: touchscreen.yaml# + +properties: + $nodename: + pattern: "^touchscreen(@.*)?$" + + compatible: + oneOf: + - const: cypress,cy8ctma340 + - const: cypress,cy8ctst341 + - const: cypress,cyttsp-spi + description: Legacy compatible for SPI connected CY8CTMA340 + deprecated: true + - const: cypress,cyttsp-i2c + description: Legacy compatible for I2C connected CY8CTMA340 + deprecated: true + + reg: + description: I2C address when used on the I2C bus, or the SPI chip + select index when used on the SPI bus + + clock-frequency: + description: I2C client clock frequency, defined for host when using + the device on the I2C bus + minimum: 0 + maximum: 400000 + + spi-max-frequency: + description: SPI clock frequency, defined for host, defined when using + the device on the SPI bus. The throughput is maximum 2 Mbps so the + typical value is 2000000, if higher rates are used the total throughput + needs to be restricted to 2 Mbps. + minimum: 0 + maximum: 6000000 + + interrupts: + description: Interrupt to host + maxItems: 1 + + vcpin-supply: + description: Analog power supply regulator on VCPIN pin + + vdd-supply: + description: Digital power supply regulator on VDD pin + + reset-gpios: + description: Reset line for the touchscreen, should be tagged + as GPIO_ACTIVE_LOW + + bootloader-key: + description: the 8-byte bootloader key that is required to switch + the chip from bootloader mode (default mode) to application mode + $ref: /schemas/types.yaml#/definitions/uint8-array + minItems: 8 + maxItems: 8 + + touchscreen-size-x: true + touchscreen-size-y: true + touchscreen-fuzz-x: true + touchscreen-fuzz-y: true + + active-distance: + description: the distance in pixels beyond which a touch must move + before movement is detected and reported by the device + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + + active-interval-ms: + description: the minimum period in ms between consecutive + scanning/processing cycles when the chip is in active mode + minimum: 0 + maximum: 255 + + lowpower-interval-ms: + description: the minimum period in ms between consecutive + scanning/processing cycles when the chip is in low-power mode + minimum: 0 + maximum: 2550 + + touch-timeout-ms: + description: minimum time in ms spent in the active power state while no + touches are detected before entering low-power mode + minimum: 0 + maximum: 2550 + + use-handshake: + description: enable register-based handshake (boolean). This should only + be used if the chip is configured to use 'blocking communication with + timeout' (in this case the device generates an interrupt at the end of + every scanning/processing cycle) + $ref: /schemas/types.yaml#/definitions/flag + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - bootloader-key + - touchscreen-size-x + - touchscreen-size-y + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + num-cs = <1>; + cs-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>; + + touchscreen@0 { + compatible = "cypress,cy8ctma340"; + reg = <0>; + interrupt-parent = <&gpio>; + interrupts = <20 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio 21 GPIO_ACTIVE_LOW>; + vdd-supply = <&ldo_aux1_reg>; + vcpin-supply = <&ldo_aux2_reg>; + bootloader-key = /bits/ 8 <0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07>; + touchscreen-size-x = <480>; + touchscreen-size-y = <800>; + active-interval-ms = <0>; + touch-timeout-ms = <255>; + lowpower-interval-ms = <10>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt b/Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt deleted file mode 100644 index 6ee274aa8b03..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt +++ /dev/null @@ -1,93 +0,0 @@ -* Cypress cyttsp touchscreen controller - -Required properties: - - compatible : must be "cypress,cyttsp-i2c" or "cypress,cyttsp-spi" - - reg : Device I2C address or SPI chip select number - - spi-max-frequency : Maximum SPI clocking speed of the device (for cyttsp-spi) - - interrupts : (gpio) interrupt to which the chip is connected - (see interrupt binding[0]). - - bootloader-key : the 8-byte bootloader key that is required to switch - the chip from bootloader mode (default mode) to - application mode. - This property has to be specified as an array of 8 - '/bits/ 8' values. - -Optional properties: - - reset-gpios : the reset gpio the chip is connected to - (see GPIO binding[1] for more details). - - touchscreen-size-x : horizontal resolution of touchscreen (in pixels) - - touchscreen-size-y : vertical resolution of touchscreen (in pixels) - - touchscreen-fuzz-x : horizontal noise value of the absolute input device - (in pixels) - - touchscreen-fuzz-y : vertical noise value of the absolute input device - (in pixels) - - active-distance : the distance in pixels beyond which a touch must move - before movement is detected and reported by the device. - Valid values: 0-15. - - active-interval-ms : the minimum period in ms between consecutive - scanning/processing cycles when the chip is in active mode. - Valid values: 0-255. - - lowpower-interval-ms : the minimum period in ms between consecutive - scanning/processing cycles when the chip is in low-power mode. - Valid values: 0-2550 - - touch-timeout-ms : minimum time in ms spent in the active power state while no - touches are detected before entering low-power mode. - Valid values: 0-2550 - - use-handshake : enable register-based handshake (boolean). This should - only be used if the chip is configured to use 'blocking - communication with timeout' (in this case the device - generates an interrupt at the end of every - scanning/processing cycle). - -[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt -[1]: Documentation/devicetree/bindings/gpio/gpio.txt - -Example: - &i2c1 { - /* ... */ - cyttsp@a { - compatible = "cypress,cyttsp-i2c"; - reg = <0xa>; - interrupt-parent = <&gpio0>; - interrupts = <28 0>; - reset-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>; - - touchscreen-size-x = <800>; - touchscreen-size-y = <480>; - touchscreen-fuzz-x = <4>; - touchscreen-fuzz-y = <7>; - - bootloader-key = /bits/ 8 <0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08>; - active-distance = <8>; - active-interval-ms = <0>; - lowpower-interval-ms = <200>; - touch-timeout-ms = <100>; - }; - - /* ... */ - }; - - &mcspi1 { - /* ... */ - cyttsp@0 { - compatible = "cypress,cyttsp-spi"; - spi-max-frequency = <6000000>; - reg = <0>; - interrupt-parent = <&gpio0>; - interrupts = <28 0>; - reset-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>; - - touchscreen-size-x = <800>; - touchscreen-size-y = <480>; - touchscreen-fuzz-x = <4>; - touchscreen-fuzz-y = <7>; - - bootloader-key = /bits/ 8 <0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08>; - active-distance = <8>; - active-interval-ms = <0>; - lowpower-interval-ms = <200>; - touch-timeout-ms = <100>; - }; - - /* ... */ - }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml index bfc3a8b5e118..2e8da7470513 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml @@ -56,6 +56,7 @@ properties: wakeup-source: true vcc-supply: true + iovcc-supply: true gain: description: Allows setting the sensitivity in the range from 0 to 31. diff --git a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt deleted file mode 100644 index af5223bb5bdd..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt +++ /dev/null @@ -1,33 +0,0 @@ -Generic resistive touchscreen ADC - -Required properties: - - - compatible: must be "resistive-adc-touch" -The device must be connected to an ADC device that provides channels for -position measurement and optional pressure. -Refer to -https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/iio-consumer.yaml -for details - - - iio-channels: must have at least two channels connected to an ADC device. -These should correspond to the channels exposed by the ADC device and should -have the right index as the ADC device registers them. These channels -represent the relative position on the "x" and "y" axes. - - iio-channel-names: must have all the channels' names. Mandatory channels -are "x" and "y". - -Optional properties: - - iio-channels: The third channel named "pressure" is optional and can be -used if the ADC device also measures pressure besides position. -If this channel is missing, pressure will be ignored and the touchscreen -will only report position. - - iio-channel-names: optional channel named "pressure". - -Example: - - resistive_touch: resistive_touch { - compatible = "resistive-adc-touch"; - touchscreen-min-pressure = <50000>; - io-channels = <&adc 24>, <&adc 25>, <&adc 26>; - io-channel-names = "x", "y", "pressure"; - }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml new file mode 100644 index 000000000000..7fc22a403d48 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/resistive-adc-touch.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic resistive touchscreen ADC + +maintainers: + - Oleksij Rempel <o.rempel@pengutronix.de> + +description: | + Generic ADC based resistive touchscreen controller + The device must be connected to an ADC device that provides channels for + position measurement and optional pressure. + +allOf: + - $ref: touchscreen.yaml# + +properties: + compatible: + const: resistive-adc-touch + + io-channels: + minItems: 2 + items: + - description: x + - description: y + - description: pressure (optional) + - description: z1 (optional) + - description: z2 (optional) + + io-channel-names: + oneOf: + - items: + - enum: [x, y] + - enum: [x, y] + - items: + - enum: [x, y, pressure] + - enum: [x, y, pressure] + - enum: [x, y, pressure] + - items: + - enum: [x, y, z1, z2] + - enum: [x, y, z1, z2] + - enum: [x, y, z1, z2] + - enum: [x, y, z1, z2] + + touchscreen-size-x: true + touchscreen-size-y: true + touchscreen-fuzz-x: true + touchscreen-fuzz-y: true + touchscreen-inverted-x: true + touchscreen-inverted-y: true + touchscreen-swapped-x-y: true + touchscreen-min-pressure: true + touchscreen-x-plate-ohms: true + +additionalProperties: false + +required: + - compatible + - io-channels + - io-channel-names + +examples: + - | + touchscreen { + compatible = "resistive-adc-touch"; + io-channels = <&adc 24>, <&adc 25>; + io-channel-names = "y", "x"; + }; + - | + touchscreen { + compatible = "resistive-adc-touch"; + touchscreen-min-pressure = <50000>; + io-channels = <&adc 24>, <&adc 25>, <&adc 26>; + io-channel-names = "y", "pressure", "x"; + }; + - | + touchscreen { + compatible = "resistive-adc-touch"; + touchscreen-min-pressure = <50000>; + io-channels = <&adc 1>, <&adc 2>, <&adc 3>, <&adc 4>; + io-channel-names = "x", "z1", "z2", "y"; + touchscreen-x-plate-ohms = <800>; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml new file mode 100644 index 000000000000..1d8ca19fd37a --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/sitronix,st1232.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sitronix st1232 or st1633 touchscreen controller + +maintainers: + - Bastian Hecht <hechtb@gmail.com> + +allOf: + - $ref: touchscreen.yaml# + +properties: + compatible: + enum: + - sitronix,st1232 + - sitronix,st1633 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + gpios: + description: A phandle to the reset GPIO + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen@55 { + compatible = "sitronix,st1232"; + reg = <0x55>; + interrupts = <2 0>; + gpios = <&gpio1 166 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt b/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt deleted file mode 100644 index 019373253b28..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt +++ /dev/null @@ -1,28 +0,0 @@ -* Sitronix st1232 or st1633 touchscreen controller - -Required properties: -- compatible: must contain one of - * "sitronix,st1232" - * "sitronix,st1633" -- reg: I2C address of the chip -- interrupts: interrupt to which the chip is connected - -Optional properties: -- gpios: a phandle to the reset GPIO - -For additional optional properties see: touchscreen.txt - -Example: - - i2c@00000000 { - /* ... */ - - touchscreen@55 { - compatible = "sitronix,st1232"; - reg = <0x55>; - interrupts = <2 0>; - gpios = <&gpio1 166 0>; - }; - - /* ... */ - }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml index 046ace461cc9..4b5b212c772c 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml @@ -74,6 +74,12 @@ properties: touchscreen-y-mm: description: vertical length in mm of the touchscreen + touchscreen-x-plate-ohms: + description: Resistance of the X-plate in Ohms + + touchscreen-y-plate-ohms: + description: Resistance of the Y-plate in Ohms + dependencies: touchscreen-size-x: [ touchscreen-size-y ] touchscreen-size-y: [ touchscreen-size-x ] diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index cb6498108b78..36c955965d90 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -92,7 +92,6 @@ properties: this interconnect to send RPMh commands. qcom,bcm-voter-names: - $ref: /schemas/types.yaml#/definitions/string-array description: | Names for each of the qcom,bcm-voters specified. diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml index 1ecd1831cf02..c84f9fe7f254 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml @@ -145,6 +145,19 @@ properties: required: - affinity + clocks: + maxItems: 1 + + clock-names: + items: + - const: aclk + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + dependencies: mbi-ranges: [ msi-controller ] msi-controller: [ mbi-ranges ] diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt deleted file mode 100644 index dd527216c5fb..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt +++ /dev/null @@ -1,41 +0,0 @@ -* ARM Vectored Interrupt Controller - -One or more Vectored Interrupt Controllers (VIC's) can be connected in an ARM -system for interrupt routing. For multiple controllers they can either be -nested or have the outputs wire-OR'd together. - -Required properties: - -- compatible : should be one of - "arm,pl190-vic" - "arm,pl192-vic" -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : The number of cells to define the interrupts. Must be 1 as - the VIC has no configuration options for interrupt sources. The cell is a u32 - and defines the interrupt number. -- reg : The register bank for the VIC. - -Optional properties: - -- interrupts : Interrupt source for parent controllers if the VIC is nested. -- valid-mask : A one cell big bit mask of valid interrupt sources. Each bit - represents single interrupt source, starting from source 0 at LSb and ending - at source 31 at MSb. A bit that is set means that the source is wired and - clear means otherwise. If unspecified, defaults to all valid. -- valid-wakeup-mask : A one cell big bit mask of interrupt sources that can be - configured as wake up source for the system. Order of bits is the same as for - valid-mask property. A set bit means that this interrupt source can be - configured as a wake up source for the system. If unspecied, defaults to all - interrupt sources configurable as wake up sources. - -Example: - - vic0: interrupt-controller@60000 { - compatible = "arm,pl192-vic"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0x60000 0x1000>; - - valid-mask = <0xffffff7f>; - valid-wakeup-mask = <0x0000ff7f>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml new file mode 100644 index 000000000000..0075e72fe8c1 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/arm,vic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Vectored Interrupt Controller + +maintainers: + - Rob Herring <robh@kernel.org> + +description: |+ + One or more Vectored Interrupt Controllers (VIC's) can be connected in an + ARM system for interrupt routing. For multiple controllers they can either + be nested or have the outputs wire-OR'd together. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + enum: + - arm,pl190-vic + - arm,pl192-vic + - arm,versatile-vic + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + description: + The number of cells to define the interrupts. It must be 1 as the + VIC has no configuration options for interrupt sources. The single + cell defines the interrupt number. + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + valid-mask: + description: + A one cell big bit mask of valid interrupt sources. Each bit + represents single interrupt source, starting from source 0 at + LSb and ending at source 31 at MSb. A bit that is set means + that the source is wired and clear means otherwise. If unspecified, + defaults to all valid. + $ref: /schemas/types.yaml#/definitions/uint32 + + valid-wakeup-mask: + description: + A one cell big bit mask of interrupt sources that can be configured + as wake up source for the system. Order of bits is the same as for + valid-mask property. A set bit means that this interrupt source + can be configured as a wake up source for the system. If unspecied, + defaults to all interrupt sources configurable as wake up sources. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - interrupt-controller + - "#interrupt-cells" + +additionalProperties: false + +examples: + - | + // PL192 VIC + vic0: interrupt-controller@60000 { + compatible = "arm,pl192-vic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x60000 0x1000>; + + valid-mask = <0xffffff7f>; + valid-wakeup-mask = <0x0000ff7f>; + }; + +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml index 3b11a1a15398..bcb5e20fa9ca 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml @@ -35,7 +35,6 @@ properties: - description: output interrupt 6 - description: output interrupt 7 minItems: 1 - maxItems: 8 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml index 067165c4b836..edf26452dc72 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml @@ -50,7 +50,6 @@ properties: - const: int2 - const: int3 minItems: 1 - maxItems: 4 '#interrupt-cells': const: 2 diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml index b67b8cbd33fc..abb22db3bb28 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml @@ -29,6 +29,7 @@ properties: - renesas,intc-ex-r8a774c0 # RZ/G2E - renesas,intc-ex-r8a7795 # R-Car H3 - renesas,intc-ex-r8a7796 # R-Car M3-W + - renesas,intc-ex-r8a77961 # R-Car M3-W+ - renesas,intc-ex-r8a77965 # R-Car M3-N - renesas,intc-ex-r8a77970 # R-Car V3M - renesas,intc-ex-r8a77980 # R-Car V3H diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml index 9731dd4421a1..051beb45d998 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml @@ -134,7 +134,7 @@ examples: /* AM4376 PRU-ICSS */ #include <dt-bindings/interrupt-controller/arm-gic.h> pruss@0 { - compatible = "ti,am4376-pruss"; + compatible = "ti,am4376-pruss1"; reg = <0x0 0x40000>; #address-cells = <1>; #size-cells = <1>; diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml index 5951c6f98c74..e87bfbcc6913 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml @@ -38,7 +38,6 @@ properties: If provided, then the combined interrupt will be used in preference to any others. - minItems: 2 - maxItems: 4 items: - const: eventq # Event Queue not empty - const: gerror # Global Error activated diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt b/Documentation/devicetree/bindings/iommu/iommu.txt index 3c36334e4f94..26ba9e530f13 100644 --- a/Documentation/devicetree/bindings/iommu/iommu.txt +++ b/Documentation/devicetree/bindings/iommu/iommu.txt @@ -92,6 +92,24 @@ Optional properties: tagging DMA transactions with an address space identifier. By default, this is 0, which means that the device only has one address space. +- dma-can-stall: When present, the master can wait for a transaction to + complete for an indefinite amount of time. Upon translation fault some + IOMMUs, instead of aborting the translation immediately, may first + notify the driver and keep the transaction in flight. This allows the OS + to inspect the fault and, for example, make physical pages resident + before updating the mappings and completing the transaction. Such IOMMU + accepts a limited number of simultaneous stalled transactions before + having to either put back-pressure on the master, or abort new faulting + transactions. + + Firmware has to opt-in stalling, because most buses and masters don't + support it. In particular it isn't compatible with PCI, where + transactions have to complete before a time limit. More generally it + won't work in systems and masters that haven't been designed for + stalling. For example the OS, in order to handle a stalled transaction, + may attempt to retrieve pages from secondary storage in a stalled + domain, leading to a deadlock. + Notes: ====== diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index dda44976acc1..02c69a95c332 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -49,7 +49,6 @@ properties: interrupts: minItems: 1 - maxItems: 2 description: Specifiers for the MMU fault interrupts. Not required for cache IPMMUs. items: diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt deleted file mode 100644 index 6ecefea1c6f9..000000000000 --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt +++ /dev/null @@ -1,38 +0,0 @@ -Rockchip IOMMU -============== - -A Rockchip DRM iommu translates io virtual addresses to physical addresses for -its master device. Each slave device is bound to a single master device, and -shares its clocks, power domain and irq. - -Required properties: -- compatible : Should be "rockchip,iommu" -- reg : Address space for the configuration registers -- interrupts : Interrupt specifier for the IOMMU instance -- interrupt-names : Interrupt name for the IOMMU instance -- #iommu-cells : Should be <0>. This indicates the iommu is a - "single-master" device, and needs no additional information - to associate with its master device. See: - Documentation/devicetree/bindings/iommu/iommu.txt -- clocks : A list of clocks required for the IOMMU to be accessible by - the host CPU. -- clock-names : Should contain the following: - "iface" - Main peripheral bus clock (PCLK/HCL) (required) - "aclk" - AXI bus clock (required) - -Optional properties: -- rockchip,disable-mmu-reset : Don't use the mmu reset operation. - Some mmu instances may produce unexpected results - when the reset operation is used. - -Example: - - vopl_mmu: iommu@ff940300 { - compatible = "rockchip,iommu"; - reg = <0xff940300 0x100>; - interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "vopl_mmu"; - clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>; - clock-names = "aclk", "iface"; - #iommu-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml new file mode 100644 index 000000000000..d2e28a9e3545 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip IOMMU + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +description: |+ + A Rockchip DRM iommu translates io virtual addresses to physical addresses for + its master device. Each slave device is bound to a single master device and + shares its clocks, power domain and irq. + + For information on assigning IOMMU controller to its peripheral devices, + see generic IOMMU bindings. + +properties: + compatible: + enum: + - rockchip,iommu + - rockchip,rk3568-iommu + + reg: + items: + - description: configuration registers for MMU instance 0 + - description: configuration registers for MMU instance 1 + minItems: 1 + maxItems: 2 + + interrupts: + items: + - description: interruption for MMU instance 0 + - description: interruption for MMU instance 1 + minItems: 1 + maxItems: 2 + + clocks: + items: + - description: Core clock + - description: Interface clock + + clock-names: + items: + - const: aclk + - const: iface + + "#iommu-cells": + const: 0 + + power-domains: + maxItems: 1 + + rockchip,disable-mmu-reset: + $ref: /schemas/types.yaml#/definitions/flag + description: | + Do not use the mmu reset operation. + Some mmu instances may produce unexpected results + when the reset operation is used. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - "#iommu-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3399-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + vopl_mmu: iommu@ff940300 { + compatible = "rockchip,iommu"; + reg = <0xff940300 0x100>; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>; + clock-names = "aclk", "iface"; + #iommu-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml new file mode 100644 index 000000000000..4ff6fabfcb30 --- /dev/null +++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ipmi/aspeed,ast2400-kcs-bmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED BMC KCS Devices + +maintainers: + - Andrew Jeffery <andrew@aj.id.au> + +description: | + The Aspeed BMC SoCs typically use the Keyboard-Controller-Style (KCS) + interfaces on the LPC bus for in-band IPMI communication with their host. + +properties: + compatible: + oneOf: + - description: Channel ID derived from reg + items: + enum: + - aspeed,ast2400-kcs-bmc-v2 + - aspeed,ast2500-kcs-bmc-v2 + - aspeed,ast2600-kcs-bmc + + - description: Old-style with explicit channel ID, no reg + deprecated: true + items: + enum: + - aspeed,ast2400-kcs-bmc + - aspeed,ast2500-kcs-bmc + + interrupts: + maxItems: 1 + + reg: + # maxItems: 3 + items: + - description: IDR register + - description: ODR register + - description: STR register + + aspeed,lpc-io-reg: + $ref: '/schemas/types.yaml#/definitions/uint32-array' + minItems: 1 + maxItems: 2 + description: | + The host CPU LPC IO data and status addresses for the device. For most + channels the status address is derived from the data address, but the + status address may be optionally provided. + + aspeed,lpc-interrupts: + $ref: "/schemas/types.yaml#/definitions/uint32-array" + minItems: 2 + maxItems: 2 + description: | + A 2-cell property expressing the LPC SerIRQ number and the interrupt + level/sense encoding (specified in the standard fashion). + + Note that the generated interrupt is issued from the BMC to the host, and + thus the target interrupt controller is not captured by the BMC's + devicetree. + + kcs_chan: + deprecated: true + $ref: '/schemas/types.yaml#/definitions/uint32' + description: The LPC channel number in the controller + + kcs_addr: + deprecated: true + $ref: '/schemas/types.yaml#/definitions/uint32' + description: The host CPU IO map address + +required: + - compatible + - interrupts + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + enum: + - aspeed,ast2400-kcs-bmc + - aspeed,ast2500-kcs-bmc + then: + required: + - kcs_chan + - kcs_addr + else: + required: + - reg + - aspeed,lpc-io-reg + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + kcs3: kcs@24 { + compatible = "aspeed,ast2600-kcs-bmc"; + reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>; + aspeed,lpc-io-reg = <0xca2>; + aspeed,lpc-interrupts = <11 IRQ_TYPE_LEVEL_LOW>; + interrupts = <8>; + }; diff --git a/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt deleted file mode 100644 index 193e71ca96b0..000000000000 --- a/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt +++ /dev/null @@ -1,33 +0,0 @@ -# Aspeed KCS (Keyboard Controller Style) IPMI interface - -The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs -(Baseboard Management Controllers) and the KCS interface can be -used to perform in-band IPMI communication with their host. - -## v1 -Required properties: -- compatible : should be one of - "aspeed,ast2400-kcs-bmc" - "aspeed,ast2500-kcs-bmc" -- interrupts : interrupt generated by the controller -- kcs_chan : The LPC channel number in the controller -- kcs_addr : The host CPU IO map address - -## v2 -Required properties: -- compatible : should be one of - "aspeed,ast2400-kcs-bmc-v2" - "aspeed,ast2500-kcs-bmc-v2" -- reg : The address and size of the IDR, ODR and STR registers -- interrupts : interrupt generated by the controller -- aspeed,lpc-io-reg : The host CPU LPC IO address for the device - -Example: - - kcs3: kcs@24 { - compatible = "aspeed,ast2500-kcs-bmc-v2"; - reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>; - aspeed,lpc-reg = <0xca2>; - interrupts = <8>; - status = "okay"; - }; diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6328.txt b/Documentation/devicetree/bindings/leds/leds-bcm6328.txt index ccebce597f37..a555d94084b7 100644 --- a/Documentation/devicetree/bindings/leds/leds-bcm6328.txt +++ b/Documentation/devicetree/bindings/leds/leds-bcm6328.txt @@ -4,8 +4,8 @@ This controller is present on BCM6318, BCM6328, BCM6362 and BCM63268. In these SoCs it's possible to control LEDs both as GPIOs or by hardware. However, on some devices there are Serial LEDs (LEDs connected to a 74x164 controller), which can either be controlled by software (exporting the 74x164 -as spi-gpio. See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or -by hardware using this driver. +as spi-gpio. See Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml), +or by hardware using this driver. Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and exporting the 74x164 as spi-gpio prevents those LEDs to be hardware controlled, so the only chance to keep them working is by using this driver. diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6358.txt b/Documentation/devicetree/bindings/leds/leds-bcm6358.txt index da5708e7b43b..6e51c6b91ee5 100644 --- a/Documentation/devicetree/bindings/leds/leds-bcm6358.txt +++ b/Documentation/devicetree/bindings/leds/leds-bcm6358.txt @@ -3,7 +3,7 @@ LEDs connected to Broadcom BCM6358 controller This controller is present on BCM6358 and BCM6368. In these SoCs there are Serial LEDs (LEDs connected to a 74x164 controller), which can either be controlled by software (exporting the 74x164 as spi-gpio. -See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or +See Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml), or by hardware using this driver. Required properties: diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml index d07eb00b97c8..bd49c201477d 100644 --- a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml +++ b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml @@ -101,11 +101,19 @@ examples: clocks = <&clock 0 2 1>; clock-names = "apb_pclk"; }; + }; - mhu_client_scb: scb@2e000000 { - compatible = "fujitsu,mb86s70-scb-1.0"; - reg = <0 0x2e000000 0 0x4000>; + firmware { + scpi { + compatible = "arm,scpi"; mboxes = <&mhuA 1>; /* HP-NonSecure */ + shmem = <&cpu_scp_hpri>; /* HP-NonSecure */ + + scpi_devpd: power-controller { + compatible = "arm,scpi-power-domains"; + num-domains = <2>; + #power-domain-cells = <1>; + }; }; }; @@ -125,10 +133,36 @@ examples: clocks = <&clock 0 2 1>; clock-names = "apb_pclk"; }; + }; - mhu_client_scpi: scpi@2f000000 { - compatible = "arm,scpi"; - reg = <0 0x2f000000 0 0x200>; - mboxes = <&mhuB 1 4>; /* HP-NonSecure, 5th doorbell */ + firmware { + scmi { + compatible = "arm,scmi"; + mboxes = <&mhuB 0 0>, /* LP-NonSecure, 1st doorbell */ + <&mhuB 0 1>; /* LP-NonSecure, 2nd doorbell */ + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_lpri0>, + <&cpu_scp_lpri1>; + + #address-cells = <1>; + #size-cells = <0>; + + scmi_devpd: protocol@11 { + reg = <0x11>; + #power-domain-cells = <1>; + }; + + scmi_dvfs: protocol@13 { + reg = <0x13>; + #clock-cells = <1>; + + mboxes = <&mhuB 1 2>, /* HP-NonSecure, 3rd doorbell */ + <&mhuB 1 3>; /* HP-NonSecure, 4th doorbell */ + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_hpri0>, + <&cpu_scp_hpri1>; + }; }; }; + +... diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml index 6608545ea66f..a4f1fe63659a 100644 --- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml @@ -192,18 +192,17 @@ examples: arm,mhuv2-protocols = <1 1>, <1 7>, <0 2>; }; - mhu_client: scb@2e000000 { - compatible = "fujitsu,mb86s70-scb-1.0"; - reg = <0 0x2e000000 0 0x4000>; - - mboxes = - //data-transfer protocol with 5 windows, mhu-tx - <&mhu_tx 2 0>, - //data-transfer protocol with 7 windows, mhu-tx - <&mhu_tx 3 0>, - //doorbell protocol channel 4, doorbell 27, mhu-tx - <&mhu_tx 4 27>, - //data-transfer protocol with 1 window, mhu-rx - <&mhu_rx 0 0>; + mhu_client: dsp@596e8000 { + compatible = "fsl,imx8qxp-dsp"; + reg = <0 0x596e8000 0 0x88000>; + clocks = <&adma_lpcg 0>, <&adma_lpcg 1>, <&adma_lpcg 2>; + clock-names = "ipg", "ocram", "core"; + power-domains = <&pd 0>, <&pd 1>, <&pd 2>, <&pd 3>; + mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1"; + mboxes = <&mhu_tx 2 0>, //data-transfer protocol with 5 windows, mhu-tx + <&mhu_tx 3 0>, //data-transfer protocol with 7 windows, mhu-tx + <&mhu_rx 2 27>, //doorbell protocol channel 2, doorbell 27, mhu-rx + <&mhu_rx 0 0>; //data-transfer protocol with 1 window, mhu-rx + memory-region = <&dsp_reserved>; }; }; diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index 1a3dff277e2b..675ad9de15bb 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -26,6 +26,7 @@ properties: oneOf: - const: fsl,imx6sx-mu - const: fsl,imx7ulp-mu + - const: fsl,imx8ulp-mu - const: fsl,imx8-mu-scu - items: - enum: diff --git a/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml new file mode 100644 index 000000000000..bbb173ea483c --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mailbox/microchip,polarfire-soc-mailbox.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) mailbox controller + +maintainers: + - Conor Dooley <conor.dooley@microchip.com> + +properties: + compatible: + const: microchip,polarfire-soc-mailbox + + reg: + items: + - description: mailbox data registers + - description: mailbox interrupt registers + + interrupts: + maxItems: 1 + + "#mbox-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + mbox: mailbox@37020000 { + compatible = "microchip,polarfire-soc-mailbox"; + reg = <0x0 0x37020000 0x0 0x1000>, <0x0 0x2000318c 0x0 0x40>; + interrupt-parent = <&L1>; + interrupts = <96>; + #mbox-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt deleted file mode 100644 index 12371f5c6cd9..000000000000 --- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt +++ /dev/null @@ -1,184 +0,0 @@ -OMAP2+ and K3 Mailbox -===================== - -The OMAP mailbox hardware facilitates communication between different processors -using a queued mailbox interrupt mechanism. The IP block is external to the -various processor subsystems and is connected on an interconnect bus. The -communication is achieved through a set of registers for message storage and -interrupt configuration registers. - -Each mailbox IP block/cluster has a certain number of h/w fifo queues and output -interrupt lines. An output interrupt line is routed to an interrupt controller -within a processor subsystem, and there can be more than one line going to a -specific processor's interrupt controller. The interrupt line connections are -fixed for an instance and are dictated by the IP integration into the SoC -(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is -programmable through a set of interrupt configuration registers, and have a rx -and tx interrupt source per h/w fifo. Communication between different processors -is achieved through the appropriate programming of the rx and tx interrupt -sources on the appropriate interrupt lines. - -The number of h/w fifo queues and interrupt lines dictate the usable registers. -All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP -instance. DRA7xx has multiple instances with different number of h/w fifo queues -and interrupt lines between different instances. The interrupt lines can also be -routed to different processor sub-systems on DRA7xx as they are routed through -the Crossbar, a kind of interrupt router/multiplexer. The K3 AM65x and J721E -SoCs has each of these instances form a cluster and combine multiple clusters -into a single IP block present within the Main NavSS. The interrupt lines from -all these clusters are multiplexed and routed to different processor subsystems -over a limited number of common interrupt output lines of an Interrupt Router. -The AM64x SoCS also uses a single IP block comprising of multiple clusters, -but the number of clusters are smaller, and the interrupt output lines are -connected directly to various processors. - -Mailbox Device Node: -==================== -A Mailbox device node is used to represent a Mailbox IP instance/cluster within -a SoC. The sub-mailboxes are represented as child nodes of this parent node. - -Required properties: --------------------- -- compatible: Should be one of the following, - "ti,omap2-mailbox" for OMAP2420, OMAP2430 SoCs - "ti,omap3-mailbox" for OMAP3430, OMAP3630 SoCs - "ti,omap4-mailbox" for OMAP44xx, OMAP54xx, AM33xx, - AM43xx and DRA7xx SoCs - "ti,am654-mailbox" for K3 AM65x and J721E SoCs - "ti,am64-mailbox" for K3 AM64x SoCs -- reg: Contains the mailbox register address range (base - address and length) -- interrupts: Contains the interrupt information for the mailbox - device. The format is dependent on which interrupt - controller the Mailbox device uses -- #mbox-cells: Common mailbox binding property to identify the number - of cells required for the mailbox specifier. Should be - 1 -- ti,mbox-num-users: Number of targets (processor devices) that the mailbox - device can interrupt -- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block - -SoC-specific Required properties: ---------------------------------- -The following are mandatory properties for the OMAP architecture based SoCs -only: -- ti,hwmods: Name of the hwmod associated with the mailbox. This - should be defined in the mailbox node only if the node - is not defined as a child node of a corresponding sysc - interconnect node. - -The following are mandatory properties for the K3 AM65x and J721E SoCs only: -- interrupt-parent: Should contain a phandle to the TI-SCI interrupt - controller node that is used to dynamically program - the interrupt routes between the IP and the main GIC - controllers. See the following binding for additional - details, - Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml - -Child Nodes: -============ -A child node is used for representing the actual sub-mailbox device that is -used for the communication between the host processor and a remote processor. -Each child node should have a unique node name across all the different -mailbox device nodes. - -Required properties: --------------------- -- ti,mbox-tx: sub-mailbox descriptor property defining a Tx fifo -- ti,mbox-rx: sub-mailbox descriptor property defining a Rx fifo - -Sub-mailbox Descriptor Data ---------------------------- -Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of -data that represent the following: - Cell #1 (fifo_id) - mailbox fifo id used either for transmitting - (ti,mbox-tx) or for receiving (ti,mbox-rx) - Cell #2 (irq_id) - irq identifier index number to use from the parent's - interrupts data. Should be 0 for most of the cases, a - positive index value is seen only on mailboxes that have - multiple interrupt lines connected to the MPU processor. - Cell #3 (usr_id) - mailbox user id for identifying the interrupt line - associated with generating a tx/rx fifo interrupt. - -Optional Properties: --------------------- -- ti,mbox-send-noirq: Quirk flag to allow the client user of this sub-mailbox - to send messages without triggering a Tx ready interrupt, - and to control the Tx ticker. Should be used only on - sub-mailboxes used to communicate with WkupM3 remote - processor on AM33xx/AM43xx SoCs. - -Mailbox Users: -============== -A device needing to communicate with a target processor device should specify -them using the common mailbox binding properties, "mboxes" and the optional -"mbox-names" (please see Documentation/devicetree/bindings/mailbox/mailbox.txt -for details). Each value of the mboxes property should contain a phandle to the -mailbox controller device node and an args specifier that will be the phandle to -the intended sub-mailbox child node to be used for communication. The equivalent -"mbox-names" property value can be used to give a name to the communication channel -to be used by the client user. - - -Example: --------- - -1. /* OMAP4 */ -mailbox: mailbox@4a0f4000 { - compatible = "ti,omap4-mailbox"; - reg = <0x4a0f4000 0x200>; - interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; - ti,hwmods = "mailbox"; - #mbox-cells = <1>; - ti,mbox-num-users = <3>; - ti,mbox-num-fifos = <8>; - mbox_ipu: mbox_ipu { - ti,mbox-tx = <0 0 0>; - ti,mbox-rx = <1 0 0>; - }; - mbox_dsp: mbox_dsp { - ti,mbox-tx = <3 0 0>; - ti,mbox-rx = <2 0 0>; - }; -}; - -dsp { - ... - mboxes = <&mailbox &mbox_dsp>; - ... -}; - -2. /* AM33xx */ -mailbox: mailbox@480c8000 { - compatible = "ti,omap4-mailbox"; - reg = <0x480C8000 0x200>; - interrupts = <77>; - ti,hwmods = "mailbox"; - #mbox-cells = <1>; - ti,mbox-num-users = <4>; - ti,mbox-num-fifos = <8>; - mbox_wkupm3: wkup_m3 { - ti,mbox-tx = <0 0 0>; - ti,mbox-rx = <0 0 3>; - }; -}; - -3. /* AM65x */ -&cbass_main { - cbass_main_navss: interconnect0 { - mailbox0_cluster0: mailbox@31f80000 { - compatible = "ti,am654-mailbox"; - reg = <0x00 0x31f80000 0x00 0x200>; - #mbox-cells = <1>; - ti,mbox-num-users = <4>; - ti,mbox-num-fifos = <16>; - interrupt-parent = <&intr_main_navss>; - interrupts = <164 0>; - - mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 { - ti,mbox-tx = <1 0 0>; - ti,mbox-rx = <0 0 0>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 5dc1173d03fd..8878ec00820e 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -19,6 +19,7 @@ properties: - qcom,ipq6018-apcs-apps-global - qcom,ipq8074-apcs-apps-global - qcom,msm8916-apcs-kpss-global + - qcom,msm8939-apcs-kpss-global - qcom,msm8994-apcs-kpss-global - qcom,msm8996-apcs-hmss-global - qcom,msm8998-apcs-hmss-global @@ -27,6 +28,7 @@ properties: - qcom,sc8180x-apss-shared - qcom,sdm660-apcs-hmss-global - qcom,sdm845-apss-shared + - qcom,sm6125-apcs-hmss-global - qcom,sm8150-apss-shared reg: @@ -75,6 +77,7 @@ allOf: - qcom,sc7180-apss-shared - qcom,sdm660-apcs-hmss-global - qcom,sdm845-apss-shared + - qcom,sm6125-apcs-hmss-global - qcom,sm8150-apss-shared then: properties: diff --git a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml index 3b7ab61a144f..b15da9ba90b2 100644 --- a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml @@ -32,7 +32,6 @@ properties: - description: tx channel free - description: wakeup source minItems: 2 - maxItems: 3 interrupt-names: items: @@ -40,7 +39,6 @@ properties: - const: tx - const: wakeup minItems: 2 - maxItems: 3 wakeup-source: true diff --git a/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml new file mode 100644 index 000000000000..e864d798168d --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml @@ -0,0 +1,308 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/ti,omap-mailbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI OMAP2+ and K3 Mailbox devices + +maintainers: + - Suman Anna <s-anna@ti.com> + +description: | + The OMAP Mailbox hardware facilitates communication between different + processors using a queued mailbox interrupt mechanism. The IP block is + external to the various processor subsystems and is connected on an + interconnect bus. The communication is achieved through a set of registers + for message storage and interrupt configuration registers. + + Each mailbox IP block/cluster has a certain number of h/w fifo queues and + output interrupt lines. An output interrupt line is routed to an interrupt + controller within a processor subsystem, and there can be more than one line + going to a specific processor's interrupt controller. The interrupt line + connections are fixed for an instance and are dictated by the IP integration + into the SoC (excluding the SoCs that have an Interrupt Crossbar or an + Interrupt Router IP). Each interrupt line is programmable through a set of + interrupt configuration registers, and have a rx and tx interrupt source per + h/w fifo. Communication between different processors is achieved through the + appropriate programming of the rx and tx interrupt sources on the appropriate + interrupt lines. + + The number of h/w fifo queues and interrupt lines dictate the usable + registers. All the current OMAP SoCs except for the newest DRA7xx SoC has a + single IP instance. DRA7xx has multiple instances with different number of + h/w fifo queues and interrupt lines between different instances. The interrupt + lines can also be routed to different processor sub-systems on DRA7xx as they + are routed through the Crossbar, a kind of interrupt router/multiplexer. The + K3 AM65x, J721E and J7200 SoCs has each of these instances form a cluster and + combine multiple clusters into a single IP block present within the Main + NavSS. The interrupt lines from all these clusters are multiplexed and routed + to different processor subsystems over a limited number of common interrupt + output lines of an Interrupt Router. The AM64x SoCS also uses a single IP + block comprising of multiple clusters, but the number of clusters are + smaller, and the interrupt output lines are connected directly to various + processors. + + Mailbox Controller Nodes + ========================= + A Mailbox device node is used to represent a Mailbox IP instance/cluster + within a SoC. The sub-mailboxes (actual communication channels) are + represented as child nodes of this parent node. + + Mailbox Users + ============== + A device needing to communicate with a target processor device should specify + them using the common mailbox binding properties, "mboxes" and the optional + "mbox-names" (please see Documentation/devicetree/bindings/mailbox/mailbox.txt + for details). Each value of the mboxes property should contain a phandle to + the mailbox controller device node and an args specifier that will be the + phandle to the intended sub-mailbox child node to be used for communication. + The equivalent "mbox-names" property value can be used to give a name to the + communication channel to be used by the client user. + +$defs: + omap-mbox-descriptor: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + The omap-mbox-descriptor is made of up of 3 cells and represents a single + uni-directional communication channel. A typical sub-mailbox device uses + two such channels - one for transmitting (Tx) and one for receiving (Rx). + items: + - description: + mailbox fifo id used either for transmitting on ti,mbox-tx channel or + for receiving on ti,mbox-rx channel (fifo_id). This is the hardware + fifo number within a mailbox cluster. + - description: + irq identifier index number to use from the parent's interrupts data. + Should be 0 for most of the cases, a positive index value is seen only + on mailboxes that have multiple interrupt lines connected to the MPU + processor (irq_id). This is an index number in the listed interrupts + property in the DT nodes. + - description: + mailbox user id for identifying the interrupt line associated with + generating a tx/rx fifo interrupt (usr_id). This is the hardware + user id number within a mailbox cluster. + + omap-sub-mailbox: + type: object + description: + The omap-sub-mailbox is a child node within a Mailbox controller device + node and represents the actual communication channel used to send and + receive messages between the host processor and a remote processor. Each + child node should have a unique node name across all the different mailbox + device nodes. + + properties: + ti,mbox-tx: + $ref: "#/$defs/omap-mbox-descriptor" + description: sub-mailbox descriptor property defining a Tx fifo. + + ti,mbox-rx: + $ref: "#/$defs/omap-mbox-descriptor" + description: sub-mailbox descriptor property defining a Rx fifo. + + ti,mbox-send-noirq: + type: boolean + description: + Quirk flag to allow the client user of this sub-mailbox to send + messages without triggering a Tx ready interrupt, and to control + the Tx ticker. Should be used only on sub-mailboxes used to + communicate with WkupM3 remote processor on AM33xx/AM43xx SoCs. + + required: + - ti,mbox-tx + - ti,mbox-rx + +properties: + compatible: + enum: + - ti,omap2-mailbox # for OMAP2420, OMAP2430 SoCs + - ti,omap3-mailbox # for OMAP3430, OMAP3630 SoCs + - ti,omap4-mailbox # for OMAP44xx, OMAP54xx, AM33xx, AM43xx and DRA7xx SoCs + - ti,am654-mailbox # for K3 AM65x, J721E and J7200 SoCs + - ti,am64-mailbox # for K3 AM64x SoCs + + reg: + maxItems: 1 + + interrupts: + description: + Contains the interrupt information for the mailbox device. The format is + dependent on which interrupt controller the Mailbox device uses. The + number of interrupts listed will at most be the value specified in + ti,mbox-num-users property, but is usually limited by the number of + interrupts reaching the main processor. An interrupt-parent property + is required on SoCs where the interrupt lines are connected through a + Interrupt Router before reaching the main processor's GIC. + + "#mbox-cells": + const: 1 + description: + The specifier is a phandle to an omap-sub-mailbox device. + + ti,mbox-num-users: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Number of targets (processor devices) that the mailbox device can + interrupt. + + ti,mbox-num-fifos: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of h/w fifo queues within the mailbox IP block. + + ti,hwmods: + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + description: + Name of the hwmod associated with the mailbox. This should be defined + in the mailbox node only if the node is not defined as a child node of + 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 + otherwise considered obsolete. + +patternProperties: + "^mbox-[a-z0-9-]+$": + $ref: "#/$defs/omap-sub-mailbox" + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + - ti,mbox-num-users + - ti,mbox-num-fifos + +allOf: + - if: + properties: + compatible: + enum: + - ti,am654-mailbox + then: + required: + - interrupt-parent + + - if: + properties: + compatible: + enum: + - ti,am654-mailbox + - ti,am64-mailbox + then: + properties: + ti,mbox-num-users: + const: 4 + ti,mbox-num-fifos: + const: 16 + interrupts: + minItems: 1 + maxItems: 4 + + - if: + properties: + compatible: + enum: + - ti,omap4-mailbox + then: + properties: + ti,mbox-num-users: + enum: [3, 4] + ti,mbox-num-fifos: + enum: [8, 12] + interrupts: + minItems: 1 + maxItems: 4 + + - if: + properties: + compatible: + enum: + - ti,omap3-mailbox + then: + properties: + ti,mbox-num-users: + const: 2 + ti,mbox-num-fifos: + const: 2 + interrupts: + minItems: 1 + maxItems: 1 + + - if: + properties: + compatible: + enum: + - ti,omap2-mailbox + then: + properties: + ti,mbox-num-users: + const: 4 + ti,mbox-num-fifos: + const: 6 + interrupts: + minItems: 1 + maxItems: 2 + +additionalProperties: false + +examples: + - | + /* OMAP4 */ + #include <dt-bindings/interrupt-controller/arm-gic.h> + mailbox: mailbox@4a0f4000 { + compatible = "ti,omap4-mailbox"; + reg = <0x4a0f4000 0x200>; + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; + #mbox-cells = <1>; + ti,mbox-num-users = <3>; + ti,mbox-num-fifos = <8>; + + mbox_ipu: mbox-ipu { + ti,mbox-tx = <0 0 0>; + ti,mbox-rx = <1 0 0>; + }; + mbox_dsp: mbox-dsp { + ti,mbox-tx = <3 0 0>; + ti,mbox-rx = <2 0 0>; + }; + }; + + dsp { + mboxes = <&mailbox &mbox_dsp>; + }; + + - | + /* AM33xx */ + mailbox1: mailbox@480c8000 { + compatible = "ti,omap4-mailbox"; + reg = <0x480c8000 0x200>; + interrupts = <77>; + #mbox-cells = <1>; + ti,mbox-num-users = <4>; + ti,mbox-num-fifos = <8>; + + mbox_wkupm3: mbox-wkup-m3 { + ti,mbox-tx = <0 0 0>; + ti,mbox-rx = <0 0 3>; + ti,mbox-send-noirq; + }; + }; + + - | + /* AM65x */ + mailbox0_cluster0: mailbox@31f80000 { + compatible = "ti,am654-mailbox"; + reg = <0x31f80000 0x200>; + #mbox-cells = <1>; + ti,mbox-num-users = <4>; + ti,mbox-num-fifos = <16>; + interrupt-parent = <&intr_main_navss>; + interrupts = <436>; + + mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 { + ti,mbox-tx = <1 0 0>; + ti,mbox-rx = <0 0 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml index b902495d278b..5044c4bb94e0 100644 --- a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml @@ -67,7 +67,6 @@ properties: clock-names: minItems: 4 - maxItems: 5 items: - const: dos_parser - const: dos diff --git a/Documentation/devicetree/bindings/media/atmel,isc.yaml b/Documentation/devicetree/bindings/media/atmel,isc.yaml new file mode 100644 index 000000000000..3e4bb8892d94 --- /dev/null +++ b/Documentation/devicetree/bindings/media/atmel,isc.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: GPL-2.0-only +# Copyright (C) 2016-2021 Microchip Technology, Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/atmel,isc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Image Sensor Controller (ISC) + +maintainers: + - Eugen Hristev <eugen.hristev@microchip.com> + +description: | + The Image Sensor Controller (ISC) device provides the video input capabilities for the + Atmel/Microchip AT91 SAMA family of devices. + + The ISC has a single parallel input that supports RAW Bayer, RGB or YUV video, + with both external synchronization and BT.656 synchronization for the latter. + +properties: + compatible: + const: atmel,sama5d2-isc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 3 + maxItems: 3 + + clock-names: + items: + - const: hclock + - const: iscck + - const: gck + + '#clock-cells': + const: 0 + + clock-output-names: + const: isc-mck + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + Input port node, single endpoint describing the input pad. + + properties: + endpoint: + $ref: video-interfaces.yaml# + + properties: + remote-endpoint: true + + bus-width: + enum: [8, 9, 10, 11, 12] + default: 12 + + hsync-active: + enum: [0, 1] + default: 1 + + vsync-active: + enum: [0, 1] + default: 1 + + pclk-sample: + enum: [0, 1] + default: 1 + + required: + - remote-endpoint + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - clock-output-names + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + isc: isc@f0008000 { + compatible = "atmel,sama5d2-isc"; + reg = <0xf0008000 0x4000>; + interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>; + clocks = <&isc_clk>, <&iscck>, <&isc_gclk>; + clock-names = "hclock", "iscck", "gck"; + #clock-cells = <0>; + clock-output-names = "isc-mck"; + + port { + isc_0: endpoint { + remote-endpoint = <&ov7740_0>; + hsync-active = <1>; + vsync-active = <0>; + pclk-sample = <1>; + bus-width = <8>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt b/Documentation/devicetree/bindings/media/atmel-isc.txt deleted file mode 100644 index bbe0e87c6188..000000000000 --- a/Documentation/devicetree/bindings/media/atmel-isc.txt +++ /dev/null @@ -1,65 +0,0 @@ -Atmel Image Sensor Controller (ISC) ----------------------------------------------- - -Required properties for ISC: -- compatible - Must be "atmel,sama5d2-isc". -- reg - Physical base address and length of the registers set for the device. -- interrupts - Should contain IRQ line for the ISC. -- clocks - List of clock specifiers, corresponding to entries in - the clock-names property; - Please refer to clock-bindings.txt. -- clock-names - Required elements: "hclock", "iscck", "gck". -- #clock-cells - Should be 0. -- clock-output-names - Should be "isc-mck". -- pinctrl-names, pinctrl-0 - Please refer to pinctrl-bindings.txt. - -ISC supports a single port node with parallel bus. It should contain one -'port' child node with child 'endpoint' node. Please refer to the bindings -defined in Documentation/devicetree/bindings/media/video-interfaces.txt. - -Example: -isc: isc@f0008000 { - compatible = "atmel,sama5d2-isc"; - reg = <0xf0008000 0x4000>; - interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>; - clocks = <&isc_clk>, <&iscck>, <&isc_gclk>; - clock-names = "hclock", "iscck", "gck"; - #clock-cells = <0>; - clock-output-names = "isc-mck"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_isc_base &pinctrl_isc_data_8bit &pinctrl_isc_data_9_10 &pinctrl_isc_data_11_12>; - - port { - isc_0: endpoint { - remote-endpoint = <&ov7740_0>; - hsync-active = <1>; - vsync-active = <0>; - pclk-sample = <1>; - }; - }; -}; - -i2c1: i2c@fc028000 { - ov7740: camera@21 { - compatible = "ovti,ov7740"; - reg = <0x21>; - clocks = <&isc>; - clock-names = "xvclk"; - assigned-clocks = <&isc>; - assigned-clock-rates = <24000000>; - - port { - ov7740_0: endpoint { - remote-endpoint = <&isc_0>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml index bcfd93739b4f..3ce4af143a3a 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml @@ -36,7 +36,13 @@ properties: maxItems: 1 port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false ports: true diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml index df634b0c1f8c..de15cebe2955 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml @@ -30,7 +30,6 @@ properties: reg-names: minItems: 1 - maxItems: 13 items: - const: main - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ] diff --git a/Documentation/devicetree/bindings/media/i2c/imx258.yaml b/Documentation/devicetree/bindings/media/i2c/imx258.yaml index 515317eff41a..cde0f7383b2a 100644 --- a/Documentation/devicetree/bindings/media/i2c/imx258.yaml +++ b/Documentation/devicetree/bindings/media/i2c/imx258.yaml @@ -49,7 +49,7 @@ properties: # See ../video-interfaces.txt for more details port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false properties: diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml index ee16102fdfe7..02f656e78700 100644 --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml @@ -111,17 +111,10 @@ properties: i2c-mux: type: object + $ref: /schemas/i2c/i2c-mux.yaml# + unevaluatedProperties: false description: | - Each GMSL link is modelled as a child bus of an i2c bus - multiplexer/switch, in accordance with bindings described in - Documentation/devicetree/bindings/i2c/i2c-mux.txt. - - properties: - '#address-cells': - const: 1 - - '#size-cells': - const: 0 + Each GMSL link is modelled as a child bus of an i2c bus multiplexer/switch. patternProperties: "^i2c@[0-3]$": @@ -133,12 +126,6 @@ properties: channels. properties: - '#address-cells': - const: 1 - - '#size-cells': - const: 0 - reg: description: The index of the GMSL channel. maxItems: 1 @@ -173,10 +160,6 @@ properties: additionalProperties: false - additionalProperties: false - - additionalProperties: false - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml index 9149f5685688..246dc5fec716 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml @@ -45,7 +45,7 @@ properties: port: description: MIPI CSI-2 transmitter port - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false properties: diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml index 0699c7e4fdeb..b962863e4f65 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml @@ -45,7 +45,7 @@ properties: port: description: MIPI CSI-2 transmitter port - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false properties: diff --git a/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml b/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml new file mode 100644 index 000000000000..f50e54a722eb --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/rda,rda5807.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Unisoc Communications RDA5807 FM radio receiver + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +properties: + compatible: + enum: + - rda,rda5807 + + reg: + description: I2C address. + maxItems: 1 + + power-supply: true + + rda,lnan: + description: Use LNAN input port. + type: boolean + + rda,lnap: + description: Use LNAP input port. + type: boolean + + rda,analog-out: + description: Enable analog audio output. + type: boolean + + rda,i2s-out: + description: Enable I2S digital audio output. + type: boolean + + rda,lna-microamp: + description: LNA working current, in micro-amperes. + default: 2500 + enum: [1800, 2100, 2500, 3000] + +required: + - compatible + - reg + - power-supply + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + radio@11 { + compatible = "rda,rda5807"; + reg = <0x11>; + + power-supply = <&ldo6>; + + rda,lnan; + rda,lnap; + rda,analog-out; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml index 27cc5b7ff613..f5055b9db693 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml @@ -37,7 +37,7 @@ properties: port: additionalProperties: false - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base properties: endpoint: diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml index c14c7d827b00..b39b84c5f012 100644 --- a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml +++ b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml @@ -43,7 +43,6 @@ properties: clocks: minItems: 1 - maxItems: 3 items: - description: AXI bus interface clock - description: Peripheral clock diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt index 06db6837cefd..ad1321e5a22d 100644 --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt @@ -9,6 +9,7 @@ Required properties: "mediatek,mt8173-vcodec-enc" for mt8173 avc encoder. "mediatek,mt8183-vcodec-enc" for MT8183 encoder. "mediatek,mt8173-vcodec-dec" for MT8173 decoder. + "mediatek,mt8192-vcodec-enc" for MT8192 encoder. - reg : Physical base address of the video codec registers and length of memory mapped region. - interrupts : interrupt number to the cpu. @@ -22,6 +23,7 @@ Required properties: - iommus : should point to the respective IOMMU block with master port as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. +- dma-ranges : describes the dma address range space that the codec hw access. One of the two following nodes: - mediatek,vpu : the node of the video processor unit, if using VPU. - mediatek,scp : the node of the SCP unit, if using SCP. diff --git a/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml new file mode 100644 index 000000000000..4b77103ca913 --- /dev/null +++ b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/microchip,sama5d4-vdec.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Hantro G1 VPU codec implemented on Microchip SAMA5D4 SoCs + +maintainers: + - Emil Velikov <emil.velikov@collabora.com> + +description: + Hantro G1 video decode accelerator present on Microchip SAMA5D4 SoCs. + +properties: + compatible: + const: microchip,sama5d4-vdec + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/interrupt-controller/irq.h> + + vdec0: vdec@300000 { + compatible = "microchip,sama5d4-vdec"; + reg = <0x00300000 0x100000>; + interrupts = <19 IRQ_TYPE_LEVEL_HIGH 4>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 19>; + }; diff --git a/Documentation/devicetree/bindings/media/microchip,xisc.yaml b/Documentation/devicetree/bindings/media/microchip,xisc.yaml new file mode 100644 index 000000000000..41afe2e5f133 --- /dev/null +++ b/Documentation/devicetree/bindings/media/microchip,xisc.yaml @@ -0,0 +1,129 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Microchip Technology, Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/microchip,xisc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip eXtended Image Sensor Controller (XISC) + +maintainers: + - Eugen Hristev <eugen.hristev@microchip.com> + +description: | + The eXtended Image Sensor Controller (XISC) device provides the video input capabilities for the + Microchip AT91 SAM family of devices. + + The XISC has a single internal parallel input that supports RAW Bayer, RGB or YUV video. + The source can be either a demuxer from a CSI2 type of bus, or a simple direct bridge to a + parallel sensor. + + The XISC provides one clock output that is used to clock the demuxer/bridge. + +properties: + compatible: + const: microchip,sama7g5-isc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: hclock + + '#clock-cells': + const: 0 + + clock-output-names: + const: isc-mck + + microchip,mipi-mode: + type: boolean + description: + As the XISC is usually connected to a demux/bridge, the XISC receives + the same type of input, however, it should be aware of the type of + signals received. The mipi-mode enables different internal handling + of the data and clock lines. + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + Input port node, single endpoint describing the input pad. + + properties: + endpoint: + $ref: video-interfaces.yaml# + + properties: + bus-type: + enum: [5, 6] + + remote-endpoint: true + + bus-width: + enum: [8, 9, 10, 11, 12] + default: 12 + + hsync-active: + enum: [0, 1] + default: 1 + + vsync-active: + enum: [0, 1] + default: 1 + + pclk-sample: + enum: [0, 1] + default: 1 + + required: + - remote-endpoint + - bus-type + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - clock-output-names + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/interrupt-controller/irq.h> + + xisc: xisc@e1408000 { + compatible = "microchip,sama7g5-isc"; + reg = <0xe1408000 0x2000>; + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 56>; + clock-names = "hclock"; + #clock-cells = <0>; + clock-output-names = "isc-mck"; + + port { + xisc_in: endpoint { + bus-type = <5>; /* Parallel */ + remote-endpoint = <&csi2dc_out>; + hsync-active = <1>; + vsync-active = <1>; + bus-width = <12>; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml index d8ed480482b9..7c09eec78ce5 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml @@ -4,15 +4,17 @@ $id: http://devicetree.org/schemas/media/nxp,imx7-mipi-csi2.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: NXP i.MX7 MIPI CSI-2 receiver +title: NXP i.MX7 and i.MX8 MIPI CSI-2 receiver maintainers: - Rui Miguel Silva <rmfrfs@gmail.com> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> description: |- - The NXP i.MX7 SoC family includes a MIPI CSI-2 receiver IP core, documented - as "CSIS V3.3". The IP core seems to originate from Samsung, and may be - compatible with some of the Exynos4 ad S5P SoCs. + The NXP i.MX7 and i.MX8 families contain SoCs that include a MIPI CSI-2 + receiver IP core named CSIS. The IP core originates from Samsung, and may be + compatible with some of the Exynos4 and S5P SoCs. i.MX7 SoCs use CSIS version + 3.3, and i.MX8 SoCs use CSIS version 3.6.3. While the CSI-2 receiver is separate from the MIPI D-PHY IP core, the PHY is completely wrapped by the CSIS and doesn't expose a control interface of its @@ -20,7 +22,9 @@ description: |- properties: compatible: - const: fsl,imx7-mipi-csi2 + enum: + - fsl,imx7-mipi-csi2 + - fsl,imx8mm-mipi-csi2 reg: maxItems: 1 @@ -29,16 +33,20 @@ properties: maxItems: 1 clocks: + minItems: 3 items: - description: The peripheral clock (a.k.a. APB clock) - description: The external clock (optionally used as the pixel clock) - description: The MIPI D-PHY clock + - description: The AXI clock clock-names: + minItems: 3 items: - const: pclk - const: wrap - const: phy + - const: axi power-domains: maxItems: 1 @@ -71,16 +79,30 @@ properties: properties: data-lanes: - oneOf: - - items: - - const: 1 - - items: - - const: 1 - - const: 2 + items: + minItems: 1 + maxItems: 4 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 required: - data-lanes + allOf: + - if: + properties: + compatible: + contains: + const: fsl,imx7-mipi-csi2 + then: + properties: + data-lanes: + items: + maxItems: 2 + port@1: $ref: /schemas/graph.yaml#/properties/port description: @@ -93,12 +115,29 @@ required: - clocks - clock-names - power-domains - - phy-supply - - resets - ports additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + const: fsl,imx7-mipi-csi2 + then: + required: + - phy-supply + - resets + else: + properties: + clocks: + minItems: 4 + clock-names: + minItems: 4 + phy-supply: false + resets: false + examples: - | #include <dt-bindings/clock/imx7d-clock.h> @@ -106,7 +145,7 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/reset/imx7-reset.h> - mipi_csi: mipi-csi@30750000 { + mipi-csi@30750000 { compatible = "fsl,imx7-mipi-csi2"; reg = <0x30750000 0x10000>; interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; @@ -144,4 +183,46 @@ examples: }; }; + - | + #include <dt-bindings/clock/imx8mm-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + mipi-csi@32e30000 { + compatible = "fsl,imx8mm-mipi-csi2"; + reg = <0x32e30000 0x1000>; + interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <333000000>; + clocks = <&clk IMX8MM_CLK_DISP_APB_ROOT>, + <&clk IMX8MM_CLK_CSI1_ROOT>, + <&clk IMX8MM_CLK_CSI1_PHY_REF>, + <&clk IMX8MM_CLK_DISP_AXI_ROOT>; + clock-names = "pclk", "wrap", "phy", "axi"; + power-domains = <&mipi_pd>; + + status = "disabled"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + imx8mm_mipi_csi_in: endpoint { + remote-endpoint = <&imx477_out>; + data-lanes = <1 2 3 4>; + }; + }; + + port@1 { + reg = <1>; + + imx8mm_mipi_csi_out: endpoint { + remote-endpoint = <&csi_in>; + }; + }; + }; + }; + ... diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml index 04013e5dd044..90b4af2c9724 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml @@ -30,7 +30,6 @@ properties: power-domain-names: minItems: 2 - maxItems: 3 items: - const: venus - const: vcodec0 diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml index 04b9af4db191..177bf81544b1 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml @@ -30,7 +30,6 @@ properties: power-domain-names: minItems: 3 - maxItems: 4 items: - const: venus - const: vcodec0 diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml index 7b81bd7f2399..ebf8f3d866a5 100644 --- a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml @@ -30,7 +30,6 @@ properties: power-domain-names: minItems: 2 - maxItems: 3 items: - const: venus - const: vcodec0 diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml index af9e7e59e5a1..d4c541c4b164 100644 --- a/Documentation/devicetree/bindings/media/rc.yaml +++ b/Documentation/devicetree/bindings/media/rc.yaml @@ -45,6 +45,7 @@ properties: - rc-cec - rc-cinergy - rc-cinergy-1400 + - rc-ct-90405 - rc-d680-dmb - rc-delock-61959 - rc-dib0700-nec @@ -125,7 +126,6 @@ properties: - rc-snapstream-firefly - rc-streamzap - rc-su3000 - - rc-tango - rc-tanix-tx3mini - rc-tanix-tx5max - rc-tbs-nec diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml index 20396f1be999..23703b767f5b 100644 --- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml +++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml @@ -25,6 +25,7 @@ properties: - renesas,r8a774e1-csi2 # RZ/G2H - renesas,r8a7795-csi2 # R-Car H3 - renesas,r8a7796-csi2 # R-Car M3-W + - renesas,r8a77961-csi2 # R-Car M3-W+ - renesas,r8a77965-csi2 # R-Car M3-N - renesas,r8a77970-csi2 # R-Car V3M - renesas,r8a77980-csi2 # R-Car V3H diff --git a/Documentation/devicetree/bindings/media/renesas,drif.yaml b/Documentation/devicetree/bindings/media/renesas,drif.yaml index f1bdaeab4053..817a6d566738 100644 --- a/Documentation/devicetree/bindings/media/renesas,drif.yaml +++ b/Documentation/devicetree/bindings/media/renesas,drif.yaml @@ -67,9 +67,7 @@ properties: maxItems: 1 clock-names: - maxItems: 1 - items: - - const: fck + const: fck resets: maxItems: 1 @@ -80,7 +78,6 @@ properties: dma-names: minItems: 1 - maxItems: 2 items: - const: rx - const: rx @@ -99,32 +96,26 @@ properties: Indicates that the channel acts as primary among the bonded channels. port: - type: object + $ref: /schemas/graph.yaml#/properties/port + unevaluatedProperties: false description: - Child port node corresponding to the data input, in accordance with the - video interface bindings defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. - The port node must contain at least one endpoint. + Child port node corresponding to the data input. The port node must + contain at least one endpoint. properties: endpoint: - type: object + $ref: /schemas/graph.yaml#/$defs/endpoint-base + unevaluatedProperties: false properties: - remote-endpoint: - description: - A phandle to the remote tuner endpoint subnode in remote node - port. - sync-active: + $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] description: Indicates sync signal polarity, 0/1 for low/high respectively. This property maps to SYNCAC bit in the hardware manual. The default is 1 (active high). - additionalProperties: false - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml new file mode 100644 index 000000000000..514857d36f6b --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml @@ -0,0 +1,196 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +# Copyright (C) 2021 Renesas Electronics Corp. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/renesas,isp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car ISP Channel Selector + +maintainers: + - Niklas Söderlund <niklas.soderlund@ragnatech.se> + +description: + The R-Car ISP Channel Selector provides MIPI CSI-2 VC and DT filtering + capabilities for the Renesas R-Car family of devices. It is used in + conjunction with the R-Car VIN and CSI-2 modules, which provides the video + capture capabilities. + +properties: + compatible: + items: + - enum: + - renesas,r8a779a0-isp # V3U + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Input port node, multiple endpoints describing the connected R-Car + CSI-2 receivers. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 0. + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 1. + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 2. + + port@4: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 3. + + port@5: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 4. + + port@6: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 5. + + port@7: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 6. + + port@8: + $ref: /schemas/graph.yaml#/properties/port + description: + Single endpoint describing the R-Car VIN connected to output port 7. + + required: + - port@0 + - port@1 + - port@2 + - port@3 + - port@4 + - port@5 + - port@6 + - port@7 + - port@8 + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - resets + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a779a0-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a779a0-sysc.h> + + isp1: isp@fed20000 { + compatible = "renesas,r8a779a0-isp"; + reg = <0xfed20000 0x10000>; + interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 613>; + power-domains = <&sysc R8A779A0_PD_A3ISP01>; + resets = <&cpg 613>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0>; + isp1csi41: endpoint@1 { + reg = <1>; + remote-endpoint = <&csi41isp1>; + }; + }; + + port@1 { + reg = <1>; + isp1vin08: endpoint { + remote-endpoint = <&vin08isp1>; + }; + }; + + port@2 { + reg = <2>; + isp1vin09: endpoint { + remote-endpoint = <&vin09isp1>; + }; + }; + + port@3 { + reg = <3>; + isp1vin10: endpoint { + remote-endpoint = <&vin10isp1>; + }; + }; + + port@4 { + reg = <4>; + isp1vin11: endpoint { + remote-endpoint = <&vin11isp1>; + }; + }; + + port@5 { + reg = <5>; + isp1vin12: endpoint { + remote-endpoint = <&vin12isp1>; + }; + }; + + port@6 { + reg = <6>; + isp1vin13: endpoint { + remote-endpoint = <&vin13isp1>; + }; + }; + + port@7 { + reg = <7>; + isp1vin14: endpoint { + remote-endpoint = <&vin14isp1>; + }; + }; + + port@8 { + reg = <8>; + isp1vin15: endpoint { + remote-endpoint = <&vin15isp1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml index dd1a5ce5896c..c0442e79cbb4 100644 --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml @@ -46,11 +46,13 @@ properties: - renesas,vin-r8a7779 # R-Car H1 - renesas,vin-r8a7795 # R-Car H3 - renesas,vin-r8a7796 # R-Car M3-W + - renesas,vin-r8a77961 # R-Car M3-W+ - renesas,vin-r8a77965 # R-Car M3-N - renesas,vin-r8a77970 # R-Car V3M - renesas,vin-r8a77980 # R-Car V3H - renesas,vin-r8a77990 # R-Car E3 - renesas,vin-r8a77995 # R-Car D3 + - renesas,vin-r8a779a0 # R-Car V3U reg: maxItems: 1 @@ -111,14 +113,15 @@ properties: description: VIN channel number $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 - maximum: 15 + maximum: 31 ports: $ref: /schemas/graph.yaml#/properties/ports properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Input port node, single endpoint describing a parallel input source. @@ -187,6 +190,29 @@ properties: - required: - endpoint@3 + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: + Input port node, multiple endpoints describing all the R-Car ISP + modules connected the VIN. + + properties: + endpoint@0: + $ref: /schemas/graph.yaml#/properties/endpoint + description: Endpoint connected to ISP0. + + endpoint@1: + $ref: /schemas/graph.yaml#/properties/endpoint + description: Endpoint connected to ISP1. + + endpoint@2: + $ref: /schemas/graph.yaml#/properties/endpoint + description: Endpoint connected to ISP2. + + endpoint@3: + $ref: /schemas/graph.yaml#/properties/endpoint + description: Endpoint connected to ISP3. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml index 8d35c327018b..089f11d21b25 100644 --- a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml +++ b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml @@ -15,7 +15,11 @@ description: |- properties: compatible: - const: rockchip,rk3399-vdec + oneOf: + - const: rockchip,rk3399-vdec + - items: + - const: rockchip,rk3228-vdec + - const: rockchip,rk3399-vdec reg: maxItems: 1 @@ -37,6 +41,10 @@ properties: - const: cabac - const: core + assigned-clocks: true + + assigned-clock-rates: true + power-domains: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index c81dbc3e8960..b88172a59de7 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -15,10 +15,19 @@ description: properties: compatible: - enum: - - rockchip,rk3288-vpu - - rockchip,rk3328-vpu - - rockchip,rk3399-vpu + oneOf: + - enum: + - rockchip,rk3036-vpu + - rockchip,rk3066-vpu + - rockchip,rk3288-vpu + - rockchip,rk3328-vpu + - rockchip,rk3399-vpu + - items: + - const: rockchip,rk3188-vpu + - const: rockchip,rk3066-vpu + - items: + - const: rockchip,rk3228-vpu + - const: rockchip,rk3399-vpu reg: maxItems: 1 @@ -35,12 +44,20 @@ properties: - const: vdpu clocks: - maxItems: 2 + oneOf: + - maxItems: 2 + - maxItems: 4 clock-names: - items: - - const: aclk - - const: hclk + oneOf: + - items: + - const: aclk + - const: hclk + - items: + - const: aclk_vdpu + - const: hclk_vdpu + - const: aclk_vepu + - const: hclk_vepu power-domains: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/tango-ir.txt b/Documentation/devicetree/bindings/media/tango-ir.txt deleted file mode 100644 index a9f00c2bf897..000000000000 --- a/Documentation/devicetree/bindings/media/tango-ir.txt +++ /dev/null @@ -1,21 +0,0 @@ -Sigma Designs Tango IR NEC/RC-5/RC-6 decoder (SMP86xx and SMP87xx) - -Required properties: - -- compatible: "sigma,smp8642-ir" -- reg: address/size of NEC+RC5 area, address/size of RC6 area -- interrupts: spec for IR IRQ -- clocks: spec for IR clock (typically the crystal oscillator) - -Optional properties: - -- linux,rc-map-name: see Documentation/devicetree/bindings/media/rc.txt - -Example: - - ir@10518 { - compatible = "sigma,smp8642-ir"; - reg = <0x10518 0x18>, <0x105e0 0x1c>; - interrupts = <21 IRQ_TYPE_EDGE_RISING>; - clocks = <&xtal>; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml new file mode 100644 index 000000000000..7a63c85ef8c5 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/arm,pl353-smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM PL353 Static Memory Controller (SMC) device-tree bindings + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> + +description: + The PL353 Static Memory Controller is a bus where you can connect two kinds + of memory interfaces, which are NAND and memory mapped interfaces (such as + SRAM or NOR). + +# We need a select here so we don't match all nodes with 'arm,primecell' +select: + properties: + compatible: + contains: + const: arm,pl353-smc-r2p1 + required: + - compatible + +properties: + $nodename: + pattern: "^memory-controller@[0-9a-f]+$" + + compatible: + items: + - const: arm,pl353-smc-r2p1 + - const: arm,primecell + + "#address-cells": + const: 2 + + "#size-cells": + const: 1 + + reg: + items: + - description: + Configuration registers for the host and sub-controllers. + The three chip select regions are defined in 'ranges'. + + clocks: + items: + - description: clock for the memory device bus + - description: main clock of the SMC + + clock-names: + items: + - const: memclk + - const: apb_pclk + + ranges: + minItems: 1 + maxItems: 3 + description: | + Memory bus areas for interacting with the devices. Reflects + the memory layout with four integer values following: + <cs-number> 0 <offset> <size> + items: + - description: NAND bank 0 + - description: NOR/SRAM bank 0 + - description: NOR/SRAM bank 1 + + interrupts: true + +patternProperties: + "@[0-3],[a-f0-9]+$": + type: object + description: | + The child device node represents the controller connected to the SMC + bus. The controller can be a NAND controller or a pair of any memory + mapped controllers such as NOR and SRAM controllers. + + properties: + compatible: + description: + Compatible of memory controller. + + reg: + items: + - items: + - description: | + Chip-select ID, as in the parent range property. + minimum: 0 + maximum: 2 + - description: | + Offset of the memory region requested by the device. + - description: | + Length of the memory region requested by the device. + + required: + - compatible + - reg + +required: + - compatible + - reg + - clock-names + - clocks + - "#address-cells" + - "#size-cells" + - ranges + +additionalProperties: false + +examples: + - | + smcc: memory-controller@e000e000 { + compatible = "arm,pl353-smc-r2p1", "arm,primecell"; + reg = <0xe000e000 0x0001000>; + clock-names = "memclk", "apb_pclk"; + clocks = <&clkc 11>, <&clkc 44>; + ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */ + 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */ + 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */ + #address-cells = <2>; + #size-cells = <1>; + + nfc0: nand-controller@0,0 { + compatible = "arm,pl353-nand-r2p1"; + reg = <0 0 0x1000000>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index a08a32340987..e87e4382807c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -53,14 +53,12 @@ properties: apb and smi are mandatory. the async is only for generation 1 smi HW. gals(global async local sync) also is optional, see below. minItems: 2 - maxItems: 4 items: - description: apb is Advanced Peripheral Bus clock, It's the clock for setting the register. - description: smi is the clock for transfer data and command. - - description: async is asynchronous clock, it help transform the smi - clock into the emi clock domain. - - description: gals0 is the path0 clock of gals. + - description: Either asynchronous clock to help transform the smi clock + into the emi clock domain on Gen1 h/w, or the path0 clock of gals. - description: gals1 is the path1 clock of gals. clock-names: diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index 7ed7839ff0a7..2353f6cf3c80 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -37,7 +37,6 @@ properties: description: | apb and smi are mandatory. gals(global async local sync) is optional. minItems: 2 - maxItems: 3 items: - description: apb is Advanced Peripheral Bus clock, It's the clock for setting the register. diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt deleted file mode 100644 index d2250498c36d..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt +++ /dev/null @@ -1,130 +0,0 @@ -Embedded Memory Controller - -Properties: -- name : Should be emc -- #address-cells : Should be 1 -- #size-cells : Should be 0 -- compatible : Should contain "nvidia,tegra20-emc". -- reg : Offset and length of the register set for the device -- nvidia,use-ram-code : If present, the sub-nodes will be addressed - and chosen using the ramcode board selector. If omitted, only one - set of tables can be present and said tables will be used - irrespective of ram-code configuration. -- interrupts : Should contain EMC General interrupt. -- clocks : Should contain EMC clock. -- nvidia,memory-controller : Phandle of the Memory Controller node. -- #interconnect-cells : Should be 0. -- operating-points-v2: See ../bindings/opp/opp.txt for details. - -For each opp entry in 'operating-points-v2' table: -- opp-supported-hw: One bitfield indicating SoC process ID mask - - A bitwise AND is performed against this value and if any bit - matches, the OPP gets enabled. - -Optional properties: -- power-domains: Phandle of the SoC "core" power domain. - -Child device nodes describe the memory settings for different configurations and clock rates. - -Example: - - opp_table: opp-table { - compatible = "operating-points-v2"; - - opp@36000000 { - opp-microvolt = <950000 950000 1300000>; - opp-hz = /bits/ 64 <36000000>; - }; - ... - }; - - memory-controller@7000f400 { - #address-cells = < 1 >; - #size-cells = < 0 >; - #interconnect-cells = <0>; - compatible = "nvidia,tegra20-emc"; - reg = <0x7000f400 0x400>; - interrupts = <0 78 0x04>; - clocks = <&tegra_car TEGRA20_CLK_EMC>; - nvidia,memory-controller = <&mc>; - power-domains = <&domain>; - operating-points-v2 = <&opp_table>; - } - - -Embedded Memory Controller ram-code table - -If the emc node has the nvidia,use-ram-code property present, then the -next level of nodes below the emc table are used to specify which settings -apply for which ram-code settings. - -If the emc node lacks the nvidia,use-ram-code property, this level is omitted -and the tables are stored directly under the emc node (see below). - -Properties: - -- name : Should be emc-tables -- nvidia,ram-code : the binary representation of the ram-code board strappings - for which this node (and children) are valid. - - - -Embedded Memory Controller configuration table - -This is a table containing the EMC register settings for the various -operating speeds of the memory controller. They are always located as -subnodes of the emc controller node. - -There are two ways of specifying which tables to use: - -* The simplest is if there is just one set of tables in the device tree, - and they will always be used (based on which frequency is used). - This is the preferred method, especially when firmware can fill in - this information based on the specific system information and just - pass it on to the kernel. - -* The slightly more complex one is when more than one memory configuration - might exist on the system. The Tegra20 platform handles this during - early boot by selecting one out of possible 4 memory settings based - on a 2-pin "ram code" bootstrap setting on the board. The values of - these strappings can be read through a register in the SoC, and thus - used to select which tables to use. - -Properties: -- name : Should be emc-table -- compatible : Should contain "nvidia,tegra20-emc-table". -- reg : either an opaque enumerator to tell different tables apart, or - the valid frequency for which the table should be used (in kHz). -- clock-frequency : the clock frequency for the EMC at which this - table should be used (in kHz). -- nvidia,emc-registers : a 46 word array of EMC registers to be programmed - for operation at the 'clock-frequency' setting. - The order and contents of the registers are: - RC, RFC, RAS, RP, R2W, W2R, R2P, W2P, RD_RCD, WR_RCD, RRD, REXT, - WDV, QUSE, QRST, QSAFE, RDV, REFRESH, BURST_REFRESH_NUM, PDEX2WR, - PDEX2RD, PCHG2PDEN, ACT2PDEN, AR2PDEN, RW2PDEN, TXSR, TCKE, TFAW, - TRPAB, TCLKSTABLE, TCLKSTOP, TREFBW, QUSE_EXTRA, FBIO_CFG6, ODT_WRITE, - ODT_READ, FBIO_CFG5, CFG_DIG_DLL, DLL_XFORM_DQS, DLL_XFORM_QUSE, - ZCAL_REF_CNT, ZCAL_WAIT_CNT, AUTO_CAL_INTERVAL, CFG_CLKTRIM_0, - CFG_CLKTRIM_1, CFG_CLKTRIM_2 - - emc-table@166000 { - reg = <166000>; - compatible = "nvidia,tegra20-emc-table"; - clock-frequency = < 166000 >; - nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 >; - }; - - emc-table@333000 { - reg = <333000>; - compatible = "nvidia,tegra20-emc-table"; - clock-frequency = < 333000 >; - nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 >; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml new file mode 100644 index 000000000000..cac6842dc8f1 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml @@ -0,0 +1,230 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra20-emc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20 SoC External Memory Controller + +maintainers: + - Dmitry Osipenko <digetx@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +description: | + The External Memory Controller (EMC) interfaces with the off-chip SDRAM to + service the request stream sent from Memory Controller. The EMC also has + various performance-affecting settings beyond the obvious SDRAM configuration + parameters and initialization settings. Tegra20 EMC supports multiple JEDEC + standard protocols: DDR1, LPDDR2 and DDR2. + +properties: + compatible: + const: nvidia,tegra20-emc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + "#interconnect-cells": + const: 0 + + nvidia,memory-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle of the Memory Controller node. + + power-domains: + maxItems: 1 + description: + Phandle of the SoC "core" power domain. + + operating-points-v2: + description: + Should contain freqs and voltages and opp-supported-hw property, which + is a bitfield indicating SoC process ID mask. + + nvidia,use-ram-code: + type: boolean + description: + If present, the emc-tables@ sub-nodes will be addressed. + +$defs: + emc-table: + type: object + properties: + compatible: + const: nvidia,tegra20-emc-table + + clock-frequency: + description: + Memory clock rate in kHz. + minimum: 1000 + maximum: 900000 + + reg: + maxItems: 1 + description: + Either an opaque enumerator to tell different tables apart, or + the valid frequency for which the table should be used (in kHz). + + nvidia,emc-registers: + description: + EMC timing characterization data. These are the registers + (see section "15.4.1 EMC Registers" in the TRM) whose values + need to be specified, according to the board documentation. + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: EMC_RC + - description: EMC_RFC + - description: EMC_RAS + - description: EMC_RP + - description: EMC_R2W + - description: EMC_W2R + - description: EMC_R2P + - description: EMC_W2P + - description: EMC_RD_RCD + - description: EMC_WR_RCD + - description: EMC_RRD + - description: EMC_REXT + - description: EMC_WDV + - description: EMC_QUSE + - description: EMC_QRST + - description: EMC_QSAFE + - description: EMC_RDV + - description: EMC_REFRESH + - description: EMC_BURST_REFRESH_NUM + - description: EMC_PDEX2WR + - description: EMC_PDEX2RD + - description: EMC_PCHG2PDEN + - description: EMC_ACT2PDEN + - description: EMC_AR2PDEN + - description: EMC_RW2PDEN + - description: EMC_TXSR + - description: EMC_TCKE + - description: EMC_TFAW + - description: EMC_TRPAB + - description: EMC_TCLKSTABLE + - description: EMC_TCLKSTOP + - description: EMC_TREFBW + - description: EMC_QUSE_EXTRA + - description: EMC_FBIO_CFG6 + - description: EMC_ODT_WRITE + - description: EMC_ODT_READ + - description: EMC_FBIO_CFG5 + - description: EMC_CFG_DIG_DLL + - description: EMC_DLL_XFORM_DQS + - description: EMC_DLL_XFORM_QUSE + - description: EMC_ZCAL_REF_CNT + - description: EMC_ZCAL_WAIT_CNT + - description: EMC_AUTO_CAL_INTERVAL + - description: EMC_CFG_CLKTRIM_0 + - description: EMC_CFG_CLKTRIM_1 + - description: EMC_CFG_CLKTRIM_2 + + required: + - clock-frequency + - compatible + - reg + - nvidia,emc-registers + + additionalProperties: false + +patternProperties: + "^emc-table@[0-9]+$": + $ref: "#/$defs/emc-table" + + "^emc-tables@[a-z0-9-]+$": + type: object + properties: + reg: + maxItems: 1 + description: + An opaque enumerator to tell different tables apart. + + nvidia,ram-code: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Value of RAM_CODE this timing set is used for. + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^emc-table@[0-9]+$": + $ref: "#/$defs/emc-table" + + required: + - nvidia,ram-code + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - nvidia,memory-controller + - "#interconnect-cells" + - operating-points-v2 + +additionalProperties: false + +examples: + - | + external-memory-controller@7000f400 { + compatible = "nvidia,tegra20-emc"; + reg = <0x7000f400 0x400>; + interrupts = <0 78 4>; + clocks = <&clock_controller 57>; + + nvidia,memory-controller = <&mc>; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; + + #interconnect-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; + + nvidia,use-ram-code; + + emc-tables@0 { + nvidia,ram-code = <0>; + reg = <0>; + + #address-cells = <1>; + #size-cells = <0>; + + emc-table@333000 { + reg = <333000>; + compatible = "nvidia,tegra20-emc-table"; + clock-frequency = <333000>; + nvidia,emc-registers = <0x00000018 0x00000033 + 0x00000012 0x00000004 0x00000004 0x00000005 + 0x00000003 0x0000000c 0x00000006 0x00000006 + 0x00000003 0x00000001 0x00000004 0x00000005 + 0x00000004 0x00000009 0x0000000d 0x00000bff + 0x00000000 0x00000003 0x00000003 0x00000006 + 0x00000006 0x00000001 0x00000011 0x000000c8 + 0x00000003 0x0000000e 0x00000007 0x00000008 + 0x00000002 0x00000000 0x00000000 0x00000002 + 0x00000000 0x00000000 0x00000083 0xf0440303 + 0x007fe010 0x00001414 0x00000000 0x00000000 + 0x00000000 0x00000000 0x00000000 0x00000000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt deleted file mode 100644 index d56615fd343a..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt +++ /dev/null @@ -1,47 +0,0 @@ -Device tree bindings for ARM PL353 static memory controller - -PL353 static memory controller supports two kinds of memory -interfaces.i.e NAND and SRAM/NOR interfaces. -The actual devices are instantiated from the child nodes of pl353 smc node. - -Required properties: -- compatible : Should be "arm,pl353-smc-r2p1", "arm,primecell". -- reg : Controller registers map and length. -- clock-names : List of input clock names - "memclk", "apb_pclk" - (See clock bindings for details). -- clocks : Clock phandles (see clock bindings for details). -- address-cells : Must be 2. -- size-cells : Must be 1. - -Child nodes: - For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash" drivers are -supported as child nodes. - -for NAND partition information please refer the below file -Documentation/devicetree/bindings/mtd/partition.txt - -Example: - smcc: memory-controller@e000e000 - compatible = "arm,pl353-smc-r2p1", "arm,primecell"; - clock-names = "memclk", "apb_pclk"; - clocks = <&clkc 11>, <&clkc 44>; - reg = <0xe000e000 0x1000>; - #address-cells = <2>; - #size-cells = <1>; - ranges = <0x0 0x0 0xe1000000 0x1000000 //Nand CS Region - 0x1 0x0 0xe2000000 0x2000000 //SRAM/NOR CS Region - 0x2 0x0 0xe4000000 0x2000000>; //SRAM/NOR CS Region - nand_0: flash@e1000000 { - compatible = "arm,pl353-nand-r2p1" - reg = <0 0 0x1000000>; - (...) - }; - nor0: flash@e2000000 { - compatible = "cfi-flash"; - reg = <1 0 0x2000000>; - }; - nor1: flash@e4000000 { - compatible = "cfi-flash"; - reg = <2 0 0x2000000>; - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt index b52e7a33f0f9..190230216de8 100644 --- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt +++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt @@ -16,8 +16,8 @@ Optional subnodes: The sub-functions of CPCAP get their own node with their own compatible values, which are described in the following files: -- Documentation/devicetree/bindings/power/supply/cpcap-battery.txt -- Documentation/devicetree/bindings/power/supply/cpcap-charger.txt +- Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml +- Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml - Documentation/devicetree/bindings/regulator/cpcap-regulator.txt - Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt - Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml index 19fcf59fd2fe..272832e9f8f2 100644 --- a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml @@ -43,12 +43,10 @@ properties: patternProperties: # Optional children - "^serdes-ln-ctrl@[0-9a-f]+$": + "^mux-controller@[0-9a-f]+$": type: object - description: | - This is the SERDES lane control mux. It should follow the bindings - specified in - Documentation/devicetree/bindings/mux/reg-mux.txt + description: + This is the SERDES lane control mux. required: - compatible @@ -68,9 +66,18 @@ examples: #size-cells = <1>; ranges; - serdes_ln_ctrl: serdes-ln-ctrl@4080 { + serdes_ln_ctrl: mux-controller@4080 { compatible = "mmio-mux"; reg = <0x00004080 0x50>; + + #mux-control-cells = <1>; + mux-reg-masks = + <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */ + <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */ + <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */ + <0x40b0 0x3>, <0x40b4 0x3>, /* SERDES3 lane0/1 select */ + <0x40c0 0x3>, <0x40c4 0x3>, <0x40c8 0x3>, <0x40cc 0x3>; + /* SERDES4 lane0/1/2/3 select */ }; }; ... diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml index e75b3a8ba816..4f62ad6ce50c 100644 --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml @@ -64,7 +64,6 @@ properties: clocks: minItems: 2 - maxItems: 4 items: - description: Bus Clock - description: Module Clock @@ -73,7 +72,6 @@ properties: clock-names: minItems: 2 - maxItems: 4 items: - const: ahb - const: mmc diff --git a/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml index 6f569fbfa134..2f63f2cdeb71 100644 --- a/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml @@ -21,6 +21,7 @@ properties: - brcm,bcm2711-emmc2 - brcm,sdhci-iproc-cygnus - brcm,sdhci-iproc + - brcm,bcm7211a0-sdhci reg: minItems: 1 diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index 369471814496..b5baf439fbac 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -116,7 +116,6 @@ properties: pinctrl-names: minItems: 1 - maxItems: 4 items: - const: default - const: state_100mhz diff --git a/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml index 04ba8b7fc054..546480f41141 100644 --- a/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml @@ -19,6 +19,7 @@ properties: - ingenic,jz4740-mmc - ingenic,jz4725b-mmc - ingenic,jz4760-mmc + - ingenic,jz4775-mmc - ingenic,jz4780-mmc - ingenic,x1000-mmc - items: diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index e141330c1114..25ac8e200970 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -220,6 +220,11 @@ properties: description: eMMC HS400 enhanced strobe mode is supported + no-mmc-hs400: + $ref: /schemas/types.yaml#/definitions/flag + description: + All eMMC HS400 modes are not supported. + dsr: description: Value the card Driver Stage Register (DSR) should be programmed @@ -358,22 +363,6 @@ additionalProperties: true examples: - | - mmc@ab000000 { - compatible = "sdhci"; - reg = <0xab000000 0x200>; - interrupts = <23>; - bus-width = <4>; - cd-gpios = <&gpio 69 0>; - cd-inverted; - wp-gpios = <&gpio 70 0>; - max-frequency = <50000000>; - keep-power-in-suspend; - wakeup-source; - mmc-pwrseq = <&sdhci0_pwrseq>; - clk-phase-sd-hs = <63>, <72>; - }; - - - | mmc3: mmc@1c12000 { #address-cells = <1>; #size-cells = <0>; @@ -385,9 +374,9 @@ examples: non-removable; mmc-pwrseq = <&sdhci0_pwrseq>; - brcmf: bcrmf@1 { + brcmf: wifi@1 { reg = <1>; - compatible = "brcm,bcm43xx-fmac"; + compatible = "brcm,bcm4329-fmac"; interrupt-parent = <&pio>; interrupts = <10 8>; interrupt-names = "host-wake"; diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index 8648d48dbbfd..e866e985549e 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -31,6 +31,8 @@ properties: - const: mediatek,mt2701-mmc - items: - const: mediatek,mt8192-mmc + - const: mediatek,mt8183-mmc + - items: - const: mediatek,mt8195-mmc - const: mediatek,mt8183-mmc @@ -38,7 +40,6 @@ properties: description: Should contain phandle for the clock feeding the MMC controller. minItems: 2 - maxItems: 8 items: - description: source clock (required). - description: HCLK which used for host (required). @@ -51,7 +52,6 @@ properties: clock-names: minItems: 2 - maxItems: 8 items: - const: source - const: hclk diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt deleted file mode 100644 index 291532ac0446..000000000000 --- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt +++ /dev/null @@ -1,53 +0,0 @@ -* Renesas Multi Media Card Interface (MMCIF) Controller - -This file documents differences between the core properties in mmc.txt -and the properties used by the MMCIF device. - - -Required properties: - -- compatible: should be "renesas,mmcif-<soctype>", "renesas,sh-mmcif" as a - fallback. Examples with <soctype> are: - - "renesas,mmcif-r7s72100" for the MMCIF found in r7s72100 SoCs - - "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs - - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs - - "renesas,mmcif-r8a7742" for the MMCIF found in r8a7742 SoCs - - "renesas,mmcif-r8a7743" for the MMCIF found in r8a7743 SoCs - - "renesas,mmcif-r8a7744" for the MMCIF found in r8a7744 SoCs - - "renesas,mmcif-r8a7745" for the MMCIF found in r8a7745 SoCs - - "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs - - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs - - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs - - "renesas,mmcif-r8a7793" for the MMCIF found in r8a7793 SoCs - - "renesas,mmcif-r8a7794" for the MMCIF found in r8a7794 SoCs - - "renesas,mmcif-sh73a0" for the MMCIF found in sh73a0 SoCs - -- interrupts: Some SoCs have only 1 shared interrupt, while others have either - 2 or 3 individual interrupts (error, int, card detect). Below is the number - of interrupts for each SoC: - 1: r8a73a4, r8a7742, r8a7743, r8a7744, r8a7745, r8a7778, r8a7790, r8a7791, - r8a7793, r8a7794 - 2: r8a7740, sh73a0 - 3: r7s72100 - -- clocks: reference to the functional clock - -- dmas: reference to the DMA channels, one per channel name listed in the - dma-names property. -- dma-names: must contain "tx" for the transmit DMA channel and "rx" for the - receive DMA channel. -- max-frequency: Maximum operating clock frequency, driver uses default clock - frequency if it is not set. - - -Example: R8A7790 (R-Car H2) MMCIF0 - - mmcif0: mmc@ee200000 { - compatible = "renesas,mmcif-r8a7790", "renesas,sh-mmcif"; - reg = <0 0xee200000 0 0x80>; - interrupts = <0 169 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp3_clks R8A7790_CLK_MMCIF0>; - dmas = <&dmac0 0xd1>, <&dmac0 0xd2>; - dma-names = "tx", "rx"; - max-frequency = <97500000>; - }; diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml b/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml new file mode 100644 index 000000000000..c36ba561c387 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/renesas,mmcif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas Multi Media Card Interface (MMCIF) Controller + +maintainers: + - Wolfram Sang <wsa+renesas@sang-engineering.com> + +allOf: + - $ref: "mmc-controller.yaml" + +properties: + compatible: + items: + - enum: + - renesas,mmcif-r7s72100 # RZ/A1H + - renesas,mmcif-r8a73a4 # R-Mobile APE6 + - renesas,mmcif-r8a7740 # R-Mobile A1 + - renesas,mmcif-r8a7742 # RZ/G1H + - renesas,mmcif-r8a7743 # RZ/G1M + - renesas,mmcif-r8a7744 # RZ/G1N + - renesas,mmcif-r8a7745 # RZ/G1E + - renesas,mmcif-r8a7778 # R-Car M1A + - renesas,mmcif-r8a7790 # R-Car H2 + - renesas,mmcif-r8a7791 # R-Car M2-W + - renesas,mmcif-r8a7793 # R-Car M2-N + - renesas,mmcif-r8a7794 # R-Car E2 + - renesas,mmcif-sh73a0 # SH-Mobile AG5 + - const: renesas,sh-mmcif + + reg: + maxItems: 1 + + interrupts: true + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + minItems: 2 + maxItems: 4 + description: + Must contain a list of pairs of references to DMA specifiers, one for + transmission, and one for reception. + + dma-names: + minItems: 2 + maxItems: 4 + items: + enum: + - tx + - rx + + max-frequency: true + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + +if: + properties: + compatible: + contains: + const: renesas,mmcif-r7s72100 +then: + properties: + interrupts: + items: + - description: Error interrupt + - description: Normal operation interrupt + - description: Card detection interrupt +else: + if: + properties: + compatible: + contains: + enum: + - renesas,mmcif-r8a7740 + - renesas,mmcif-sh73a0 + then: + properties: + interrupts: + items: + - description: Error interrupt + - description: Normal operation interrupt + else: + if: + properties: + compatible: + contains: + enum: + - renesas,mmcif-r8a73a4 + - renesas,mmcif-r8a7778 + then: + properties: + interrupts: + maxItems: 1 + else: + properties: + interrupts: + maxItems: 1 + required: + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7790-sysc.h> + + mmcif0: mmc@ee200000 { + compatible = "renesas,mmcif-r8a7790", "renesas,sh-mmcif"; + reg = <0xee200000 0x80>; + interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 315>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 315>; + dmas = <&dmac0 0xd1>, <&dmac0 0xd2>, <&dmac1 0xd1>, <&dmac1 0xd2>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <97500000>; + }; diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index 1118b6fa93c9..677989bc5924 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -75,7 +75,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: core - const: cd @@ -107,7 +106,6 @@ properties: pinctrl-names: minItems: 1 - maxItems: 2 items: - const: default - const: state_uhs diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml index 3762f1c8de96..54fb59820d2b 100644 --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml @@ -29,21 +29,15 @@ properties: - const: rockchip,rk3288-dw-mshc - items: - enum: - # for Rockchip PX30 - rockchip,px30-dw-mshc - # for Rockchip RK3036 + - rockchip,rk1808-dw-mshc - rockchip,rk3036-dw-mshc - # for Rockchip RK322x - rockchip,rk3228-dw-mshc - # for Rockchip RK3308 - rockchip,rk3308-dw-mshc - # for Rockchip RK3328 - rockchip,rk3328-dw-mshc - # for Rockchip RK3368 - rockchip,rk3368-dw-mshc - # for Rockchip RK3399 - rockchip,rk3399-dw-mshc - # for Rockchip RV1108 + - rockchip,rk3568-dw-mshc - rockchip,rv1108-dw-mshc - const: rockchip,rk3288-dw-mshc diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml index 3a79e39253d2..224303f5b913 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml @@ -19,7 +19,6 @@ properties: - const: ti,am654-sdhci-5.1 - const: ti,j721e-sdhci-8bit - const: ti,j721e-sdhci-4bit - - const: ti,j721e-sdhci-4bit - const: ti,am64-sdhci-8bit - const: ti,am64-sdhci-4bit - items: @@ -45,7 +44,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: clk_ahb - const: clk_xin diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml index aa12480648a5..1c87f4218e18 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml @@ -57,7 +57,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: io - const: core diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 4a9145ef15d6..57d077c0b7c1 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -25,10 +25,10 @@ The following are mandatory properties for 66AK2G SoCs only: - power-domains:Should contain a phandle to a PM domain provider node and an args specifier containing the MMC device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml - clocks: Must contain an entry for each entry in clock-names. Should be defined as per the he appropriate clock bindings consumer - usage in Documentation/devicetree/bindings/clock/ti,sci-clk.txt + usage in Documentation/devicetree/bindings/clock/ti,sci-clk.yaml - clock-names: Shall be "fck" for the functional clock, and "mmchsdb_fck" for the debounce clock. diff --git a/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml new file mode 100644 index 000000000000..5f126bb9b202 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/arm,pl353-nand-r2p1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PL353 NAND Controller device tree bindings + +allOf: + - $ref: "nand-controller.yaml" + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> + +properties: + compatible: + items: + - const: arm,pl353-nand-r2p1 + + reg: + items: + - items: + - description: CS with regard to the parent ranges property + - description: Offset of the memory region requested by the device + - description: Length of the memory region requested by the device + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + smcc: memory-controller@e000e000 { + compatible = "arm,pl353-smc-r2p1", "arm,primecell"; + reg = <0xe000e000 0x0001000>; + clock-names = "memclk", "apb_pclk"; + clocks = <&clkc 11>, <&clkc 44>; + ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */ + 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */ + 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */ + #address-cells = <2>; + #size-cells = <1>; + + nfc0: nand-controller@0,0 { + compatible = "arm,pl353-nand-r2p1"; + reg = <0 0 0x1000000>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/arm-versatile.txt b/Documentation/devicetree/bindings/mtd/arm-versatile.txt deleted file mode 100644 index 4ec28796a3c0..000000000000 --- a/Documentation/devicetree/bindings/mtd/arm-versatile.txt +++ /dev/null @@ -1,26 +0,0 @@ -Flash device on ARM Versatile board - -These flash chips are found in the ARM reference designs like Integrator, -Versatile, RealView, Versatile Express etc. - -They are regular CFI compatible (Intel or AMD extended) flash chips with -some special write protect/VPP bits that can be controlled by the machine's -system controller. - -Required properties: -- compatible : must be "arm,versatile-flash", "cfi-flash"; -- reg : memory address for the flash chip -- bank-width : width in bytes of flash interface. - -For the rest of the properties, see mtd-physmap.txt. - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - -flash@34000000 { - compatible = "arm,versatile-flash", "cfi-flash"; - reg = <0x34000000 0x4000000>; - bank-width = <4>; -}; diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt deleted file mode 100644 index 44335a4f8bfb..000000000000 --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt +++ /dev/null @@ -1,186 +0,0 @@ -* Broadcom STB NAND Controller - -The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND -flash chips. It has a memory-mapped register interface for both control -registers and for its data input/output buffer. On some SoCs, this controller is -paired with a custom DMA engine (inventively named "Flash DMA") which supports -basic PROGRAM and READ functions, among other features. - -This controller was originally designed for STB SoCs (BCM7xxx) but is now -available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and -iProc/Cygnus. Its history includes several similar (but not fully register -compatible) versions. - -Required properties: -- compatible : May contain an SoC-specific compatibility string (see below) - to account for any SoC-specific hardware bits that may be - added on top of the base core controller. - In addition, must contain compatibility information about - the core NAND controller, of the following form: - "brcm,brcmnand" and an appropriate version compatibility - string, like "brcm,brcmnand-v7.0" - Possible values: - brcm,brcmnand-v2.1 - brcm,brcmnand-v2.2 - brcm,brcmnand-v4.0 - brcm,brcmnand-v5.0 - brcm,brcmnand-v6.0 - brcm,brcmnand-v6.1 - brcm,brcmnand-v6.2 - brcm,brcmnand-v7.0 - brcm,brcmnand-v7.1 - brcm,brcmnand-v7.2 - brcm,brcmnand-v7.3 - brcm,brcmnand -- reg : the register start and length for NAND register region. - (optional) Flash DMA register range (if present) - (optional) NAND flash cache range (if at non-standard offset) -- reg-names : a list of the names corresponding to the previous register - ranges. Should contain "nand" and (optionally) - "flash-dma" or "flash-edu" and/or "nand-cache". -- interrupts : The NAND CTLRDY interrupt, (if Flash DMA is available) - FLASH_DMA_DONE and if EDU is avaialble and used FLASH_EDU_DONE -- interrupt-names : May be "nand_ctlrdy" or "flash_dma_done" or "flash_edu_done", - if broken out as individual interrupts. - May be "nand", if the SoC has the individual NAND - interrupts multiplexed behind another custom piece of - hardware -- #address-cells : <1> - subnodes give the chip-select number -- #size-cells : <0> - -Optional properties: -- clock : reference to the clock for the NAND controller -- clock-names : "nand" (required for the above clock) -- brcm,nand-has-wp : Some versions of this IP include a write-protect - (WP) control bit. It is always available on >= - v7.0. Use this property to describe the rare - earlier versions of this core that include WP - - -- Additional SoC-specific NAND controller properties -- - -The NAND controller is integrated differently on the variety of SoCs on which it -is found. Part of this integration involves providing status and enable bits -with which to control the 8 exposed NAND interrupts, as well as hardware for -configuring the endianness of the data bus. On some SoCs, these features are -handled via standard, modular components (e.g., their interrupts look like a -normal IRQ chip), but on others, they are controlled in unique and interesting -ways, sometimes with registers that lump multiple NAND-related functions -together. The former case can be described simply by the standard interrupts -properties in the main controller node. But for the latter exceptional cases, -we define additional 'compatible' properties and associated register resources within the NAND controller node above. - - - compatible: Can be one of several SoC-specific strings. Each SoC may have - different requirements for its additional properties, as described below each - bullet point below. - - * "brcm,nand-bcm63138" - - reg: (required) the 'NAND_INT_BASE' register range, with separate status - and enable registers - - reg-names: (required) "nand-int-base" - - * "brcm,nand-bcm6368" - - compatible: should contain "brcm,nand-bcm<soc>", "brcm,nand-bcm6368" - - reg: (required) the 'NAND_INTR_BASE' register range, with combined status - and enable registers, and boot address registers - - reg-names: (required) "nand-int-base" - - * "brcm,nand-iproc" - - reg: (required) the "IDM" register range, for interrupt enable and APB - bus access endianness configuration, and the "EXT" register range, - for interrupt status/ack. - - reg-names: (required) a list of the names corresponding to the previous - register ranges. Should contain "iproc-idm" and "iproc-ext". - - -* NAND chip-select - -Each controller (compatible: "brcm,brcmnand") may contain one or more subnodes -to represent enabled chip-selects which (may) contain NAND flash chips. Their -properties are as follows. - -Required properties: -- compatible : should contain "brcm,nandcs" -- reg : a single integer representing the chip-select - number (e.g., 0, 1, 2, etc.) -- #address-cells : see partition.txt -- #size-cells : see partition.txt - -Optional properties: -- nand-ecc-strength : see nand-controller.yaml -- nand-ecc-step-size : must be 512 or 1024. See nand-controller.yaml -- nand-on-flash-bbt : boolean, to enable the on-flash BBT for this - chip-select. See nand-controller.yaml -- brcm,nand-oob-sector-size : integer, to denote the spare area sector size - expected for the ECC layout in use. This size, in - addition to the strength and step-size, - determines how the hardware BCH engine will lay - out the parity bytes it stores on the flash. - This property can be automatically determined by - the flash geometry (particularly the NAND page - and OOB size) in many cases, but when booting - from NAND, the boot controller has only a limited - number of available options for its default ECC - layout. - -Each nandcs device node may optionally contain sub-nodes describing the flash -partition mapping. See partition.txt for more detail. - - -Example: - -nand@f0442800 { - compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand"; - reg = <0xF0442800 0x600>, - <0xF0443000 0x100>; - reg-names = "nand", "flash-dma"; - interrupt-parent = <&hif_intr2_intc>; - interrupts = <24>, <4>; - - #address-cells = <1>; - #size-cells = <0>; - - nandcs@1 { - compatible = "brcm,nandcs"; - reg = <1>; // Chip select 1 - nand-on-flash-bbt; - nand-ecc-strength = <12>; - nand-ecc-step-size = <512>; - - // Partitions - #address-cells = <1>; // <2>, for 64-bit offset - #size-cells = <1>; // <2>, for 64-bit length - flash0.rootfs@0 { - reg = <0 0x10000000>; - }; - flash0@0 { - reg = <0 0>; // MTDPART_SIZ_FULL - }; - flash0.kernel@10000000 { - reg = <0x10000000 0x400000>; - }; - }; -}; - -nand@10000200 { - compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368", - "brcm,brcmnand-v4.0", "brcm,brcmnand"; - reg = <0x10000200 0x180>, - <0x10000600 0x200>, - <0x100000b0 0x10>; - reg-names = "nand", "nand-cache", "nand-int-base"; - interrupt-parent = <&periph_intc>; - interrupts = <50>; - clocks = <&periph_clk 20>; - clock-names = "nand"; - - #address-cells = <1>; - #size-cells = <0>; - - nand0: nandcs@0 { - compatible = "brcm,nandcs"; - reg = <0>; - nand-on-flash-bbt; - nand-ecc-strength = <1>; - nand-ecc-step-size = <512>; - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml new file mode 100644 index 000000000000..e5f1a33332a5 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml @@ -0,0 +1,242 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/brcm,brcmnand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom STB NAND Controller + +maintainers: + - Brian Norris <computersforpeace@gmail.com> + - Kamal Dasu <kdasu.kdev@gmail.com> + +description: | + The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND + flash chips. It has a memory-mapped register interface for both control + registers and for its data input/output buffer. On some SoCs, this controller + is paired with a custom DMA engine (inventively named "Flash DMA") which + supports basic PROGRAM and READ functions, among other features. + + This controller was originally designed for STB SoCs (BCM7xxx) but is now + available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and + iProc/Cygnus. Its history includes several similar (but not fully register + compatible) versions. + + -- Additional SoC-specific NAND controller properties -- + + The NAND controller is integrated differently on the variety of SoCs on which + it is found. Part of this integration involves providing status and enable + bits with which to control the 8 exposed NAND interrupts, as well as hardware + for configuring the endianness of the data bus. On some SoCs, these features + are handled via standard, modular components (e.g., their interrupts look like + a normal IRQ chip), but on others, they are controlled in unique and + interesting ways, sometimes with registers that lump multiple NAND-related + functions together. The former case can be described simply by the standard + interrupts properties in the main controller node. But for the latter + exceptional cases, we define additional 'compatible' properties and associated + register resources within the NAND controller node above. + +properties: + compatible: + oneOf: + - items: + - enum: + - brcm,brcmnand-v2.1 + - brcm,brcmnand-v2.2 + - brcm,brcmnand-v4.0 + - brcm,brcmnand-v5.0 + - brcm,brcmnand-v6.0 + - brcm,brcmnand-v6.1 + - brcm,brcmnand-v6.2 + - brcm,brcmnand-v7.0 + - brcm,brcmnand-v7.1 + - brcm,brcmnand-v7.2 + - brcm,brcmnand-v7.3 + - const: brcm,brcmnand + - description: BCM63138 SoC-specific NAND controller + items: + - const: brcm,nand-bcm63138 + - enum: + - brcm,brcmnand-v7.0 + - brcm,brcmnand-v7.1 + - const: brcm,brcmnand + - description: iProc SoC-specific NAND controller + items: + - const: brcm,nand-iproc + - const: brcm,brcmnand-v6.1 + - const: brcm,brcmnand + - description: BCM63168 SoC-specific NAND controller + items: + - const: brcm,nand-bcm63168 + - const: brcm,nand-bcm6368 + - const: brcm,brcmnand-v4.0 + - const: brcm,brcmnand + + reg: + minItems: 1 + maxItems: 6 + + reg-names: + minItems: 1 + maxItems: 6 + items: + enum: [ nand, flash-dma, flash-edu, nand-cache, nand-int-base, iproc-idm, iproc-ext ] + + interrupts: + minItems: 1 + maxItems: 3 + items: + - description: NAND CTLRDY interrupt + - description: FLASH_DMA_DONE if flash DMA is available + - description: FLASH_EDU_DONE if EDU is available + + interrupt-names: + minItems: 1 + maxItems: 3 + items: + - const: nand_ctlrdy + - const: flash_dma_done + - const: flash_edu_done + + clocks: + maxItems: 1 + description: reference to the clock for the NAND controller + + clock-names: + const: nand + + brcm,nand-has-wp: + description: > + Some versions of this IP include a write-protect + (WP) control bit. It is always available on >= + v7.0. Use this property to describe the rare + earlier versions of this core that include WP + type: boolean + +patternProperties: + "^nand@[a-f0-9]$": + type: object + properties: + compatible: + const: brcm,nandcs + + nand-ecc-step-size: + enum: [ 512, 1024 ] + + brcm,nand-oob-sector-size: + description: | + integer, to denote the spare area sector size + expected for the ECC layout in use. This size, in + addition to the strength and step-size, + determines how the hardware BCH engine will lay + out the parity bytes it stores on the flash. + This property can be automatically determined by + the flash geometry (particularly the NAND page + and OOB size) in many cases, but when booting + from NAND, the boot controller has only a limited + number of available options for its default ECC + layout. + $ref: /schemas/types.yaml#/definitions/uint32 + +allOf: + - $ref: nand-controller.yaml# + - if: + properties: + compatible: + contains: + const: brcm,nand-bcm63138 + then: + properties: + reg-names: + minItems: 2 + maxItems: 2 + items: + - const: nand + - const: nand-int-base + - if: + properties: + compatible: + contains: + const: brcm,nand-bcm6368 + then: + properties: + reg-names: + minItems: 3 + maxItems: 3 + items: + - const: nand + - const: nand-int-base + - const: nand-cache + - if: + properties: + compatible: + contains: + const: brcm,nand-iproc + then: + properties: + reg-names: + minItems: 3 + maxItems: 3 + items: + - const: nand + - const: iproc-idm + - const: iproc-ext + +unevaluatedProperties: false + +required: + - reg + - reg-names + - interrupts + +examples: + - | + nand-controller@f0442800 { + compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand"; + reg = <0xf0442800 0x600>, + <0xf0443000 0x100>; + reg-names = "nand", "flash-dma"; + interrupt-parent = <&hif_intr2_intc>; + interrupts = <24>, <4>; + + #address-cells = <1>; + #size-cells = <0>; + + nand@1 { + compatible = "brcm,nandcs"; + reg = <1>; // Chip select 1 + nand-on-flash-bbt; + nand-ecc-strength = <12>; + nand-ecc-step-size = <512>; + + #address-cells = <1>; + #size-cells = <1>; + }; + }; + - | + nand-controller@10000200 { + compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368", + "brcm,brcmnand-v4.0", "brcm,brcmnand"; + reg = <0x10000200 0x180>, + <0x100000b0 0x10>, + <0x10000600 0x200>; + reg-names = "nand", "nand-int-base", "nand-cache"; + interrupt-parent = <&periph_intc>; + interrupts = <50>; + clocks = <&periph_clk 20>; + clock-names = "nand"; + + #address-cells = <1>; + #size-cells = <0>; + + nand@0 { + compatible = "brcm,nandcs"; + reg = <0>; + nand-on-flash-bbt; + nand-ecc-strength = <1>; + nand-ecc-step-size = <512>; + + #address-cells = <1>; + #size-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt index fc068b923d7a..ae16f9ea8606 100644 --- a/Documentation/devicetree/bindings/mtd/common.txt +++ b/Documentation/devicetree/bindings/mtd/common.txt @@ -1,15 +1 @@ -* Common properties of all MTD devices - -Optional properties: -- label: user-defined MTD device name. Can be used to assign user - friendly names to MTD devices (instead of the flash model or flash - controller based name) in order to ease flash device identification - and/or describe what they are used for. - -Example: - - flash@0 { - label = "System-firmware"; - - /* flash type specific properties */ - }; +This file has been moved to mtd.yaml. diff --git a/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt b/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt index 3fa1b34d69ad..efa5b2aba829 100644 --- a/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt +++ b/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt @@ -9,7 +9,7 @@ Required properties: - syscon : must be a phandle to the system controller - bank-width : width in bytes of flash interface, should be <2> -For the rest of the properties, see mtd-physmap.txt. +For the rest of the properties, see mtd-physmap.yaml. The device tree may optionally contain sub-nodes describing partitions of the address space. See partition.txt for more detail. diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperflash.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperflash.txt deleted file mode 100644 index ad42f4db32f1..000000000000 --- a/Documentation/devicetree/bindings/mtd/cypress,hyperflash.txt +++ /dev/null @@ -1,13 +0,0 @@ -Bindings for HyperFlash NOR flash chips compliant with Cypress HyperBus -specification and supports Cypress CFI specification 1.5 command set. - -Required properties: -- compatible : "cypress,hyperflash", "cfi-flash" for HyperFlash NOR chips -- reg : Address of flash's memory map - -Example: - - flash@0 { - compatible = "cypress,hyperflash", "cfi-flash"; - reg = <0x0 0x4000000>; - }; diff --git a/Documentation/devicetree/bindings/mtd/intel,ixp4xx-flash.txt b/Documentation/devicetree/bindings/mtd/intel,ixp4xx-flash.txt deleted file mode 100644 index 4bdcb92ae381..000000000000 --- a/Documentation/devicetree/bindings/mtd/intel,ixp4xx-flash.txt +++ /dev/null @@ -1,22 +0,0 @@ -Flash device on Intel IXP4xx SoC - -This flash is regular CFI compatible (Intel or AMD extended) flash chips with -specific big-endian or mixed-endian memory access pattern. - -Required properties: -- compatible : must be "intel,ixp4xx-flash", "cfi-flash"; -- reg : memory address for the flash chip -- bank-width : width in bytes of flash interface, should be <2> - -For the rest of the properties, see mtd-physmap.txt. - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - -flash@50000000 { - compatible = "intel,ixp4xx-flash", "cfi-flash"; - reg = <0x50000000 0x01000000>; - bank-width = <2>; -}; diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 5e7e5349f9a1..ed590d7c6e37 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -9,6 +9,9 @@ title: SPI NOR flash ST M25Pxx (and similar) serial flash chips maintainers: - Rob Herring <robh@kernel.org> +allOf: + - $ref: "mtd.yaml#" + properties: compatible: oneOf: @@ -82,6 +85,9 @@ patternProperties: '^partition@': type: object + "^otp(-[0-9]+)?$": + type: object + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml new file mode 100644 index 000000000000..2cdf6bf3dc4a --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml @@ -0,0 +1,45 @@ +# 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#" + +title: Microchip 48l640 (and similar) serial EERAM bindings + +maintainers: + - Heiko Schocher <hs@denx.de> + +description: | + The Microchip 48l640 is a 8KByte EERAM connected via SPI. + + datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20006055B.pdf + +properties: + compatible: + items: + - const: microchip,48l640 + + reg: + maxItems: 1 + + spi-max-frequency: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + eeram@0 { + compatible = "microchip,48l640"; + reg = <0>; + spi-max-frequency = <20000000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt deleted file mode 100644 index c69f4f065d23..000000000000 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt +++ /dev/null @@ -1,114 +0,0 @@ -CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...) - -Flash chips (Memory Technology Devices) are often used for solid state -file systems on embedded devices. - - - compatible : should contain the specific model of mtd chip(s) - used, if known, followed by either "cfi-flash", "jedec-flash", - "mtd-ram" or "mtd-rom". - - reg : Address range(s) of the mtd chip(s) - It's possible to (optionally) define multiple "reg" tuples so that - non-identical chips can be described in one node. - - bank-width : Width (in bytes) of the bank. Equal to the - device width times the number of interleaved chips. - - device-width : (optional) Width of a single mtd chip. If - omitted, assumed to be equal to 'bank-width'. - - #address-cells, #size-cells : Must be present if the device has - sub-nodes representing partitions (see below). In this case - both #address-cells and #size-cells must be equal to 1. - - no-unaligned-direct-access: boolean to disable the default direct - mapping of the flash. - On some platforms (e.g. MPC5200) a direct 1:1 mapping may cause - problems with JFFS2 usage, as the local bus (LPB) doesn't support - unaligned accesses as implemented in the JFFS2 code via memcpy(). - By defining "no-unaligned-direct-access", the flash will not be - exposed directly to the MTD users (e.g. JFFS2) any more. - - linux,mtd-name: allow to specify the mtd name for retro capability with - physmap-flash drivers as boot loader pass the mtd partition via the old - device name physmap-flash. - - use-advanced-sector-protection: boolean to enable support for the - advanced sector protection (Spansion: PPB - Persistent Protection - Bits) locking. - - addr-gpios : (optional) List of GPIO descriptors that will be used to - address the MSBs address lines. The order goes from LSB to MSB. - -For JEDEC compatible devices, the following additional properties -are defined: - - - vendor-id : Contains the flash chip's vendor id (1 byte). - - device-id : Contains the flash chip's device id (1 byte). - -For ROM compatible devices (and ROM fallback from cfi-flash), the following -additional (optional) property is defined: - - - erase-size : The chip's physical erase block size in bytes. - - The device tree may optionally contain endianness property. - little-endian or big-endian : It Represents the endianness that should be used - by the controller to properly read/write data - from/to the flash. If this property is missing, - the endianness is chosen by the system - (potentially based on extra configuration options). - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - - flash@ff000000 { - compatible = "amd,am29lv128ml", "cfi-flash"; - reg = <ff000000 01000000>; - bank-width = <4>; - device-width = <1>; - #address-cells = <1>; - #size-cells = <1>; - fs@0 { - label = "fs"; - reg = <0 f80000>; - }; - firmware@f80000 { - label ="firmware"; - reg = <f80000 80000>; - read-only; - }; - }; - -Here an example with multiple "reg" tuples: - - flash@f0000000,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "intel,PC48F4400P0VB", "cfi-flash"; - reg = <0 0x00000000 0x02000000 - 0 0x02000000 0x02000000>; - bank-width = <2>; - partition@0 { - label = "test-part1"; - reg = <0 0x04000000>; - }; - }; - -An example using SRAM: - - sram@2,0 { - compatible = "samsung,k6f1616u6a", "mtd-ram"; - reg = <2 0 0x00200000>; - bank-width = <2>; - }; - -An example using gpio-addrs - - flash@20000000 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "cfi-flash", "jedec-flash"; - reg = <0x20000000 0x02000000>; - ranges = <0 0x00000000 0x02000000 - 1 0x02000000 0x02000000>; - bank-width = <2>; - addr-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; - partition@0 { - label = "test-part1"; - reg = <0 0x04000000>; - }; - }; diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml new file mode 100644 index 000000000000..13c29cc91b59 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml @@ -0,0 +1,208 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/mtd-physmap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...) + +maintainers: + - Rob Herring <robh@kernel.org> + +description: | + Flash chips (Memory Technology Devices) are often used for solid state + file systems on embedded devices. + +properties: + compatible: + oneOf: + - items: + - enum: + - amd,s29gl01gp + - amd,s29gl032a + - amd,s29gl256n + - amd,s29gl512n + - arm,versatile-flash + - cortina,gemini-flash + - cypress,hyperflash + - ge,imp3a-firmware-mirror + - ge,imp3a-paged-flash + - gef,ppc9a-firmware-mirror + - gef,ppc9a-paged-flash + - gef,sbc310-firmware-mirror + - gef,sbc310-paged-flash + - gef,sbc610-firmware-mirror + - gef,sbc610-paged-flash + - intel,28f128j3 + - intel,dt28f160 + - intel,ixp4xx-flash + - intel,JS28F128 + - intel,JS28F640 + - intel,PC28F640P30T85 + - numonyx,js28f00a + - numonyx,js28f128 + - sst,sst39vf320 + - xlnx,xps-mch-emc-2.00.a + - const: cfi-flash + - items: + - enum: + - cypress,cy7c1019dv33-10zsxi + - arm,vexpress-psram + - const: mtd-ram + - enum: + - cfi-flash + - jedec-flash + - mtd-ram + - mtd-rom + + reg: + description: | + It's possible to (optionally) define multiple "reg" tuples so that + non-identical chips can be described in one node. + minItems: 1 + maxItems: 8 + + bank-width: + description: Width (in bytes) of the bank. Equal to the device width times + the number of interleaved chips. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2, 4 ] + + device-width: + description: + Width of a single mtd chip. If omitted, assumed to be equal to 'bank-width'. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2 ] + + no-unaligned-direct-access: + type: boolean + description: | + Disables the default direct mapping of the flash. + + On some platforms (e.g. MPC5200) a direct 1:1 mapping may cause problems + with JFFS2 usage, as the local bus (LPB) doesn't support unaligned + accesses as implemented in the JFFS2 code via memcpy(). By defining + "no-unaligned-direct-access", the flash will not be exposed directly to + the MTD users (e.g. JFFS2) any more. + + linux,mtd-name: + description: + Allows specifying the mtd name for retro capability with physmap-flash + drivers as boot loader pass the mtd partition via the old device name + physmap-flash. + $ref: /schemas/types.yaml#/definitions/string + + use-advanced-sector-protection: + type: boolean + description: | + Enables support for the advanced sector protection (Spansion: PPB - + Persistent Protection Bits) locking. + + erase-size: + description: The chip's physical erase block size in bytes. + $ref: /schemas/types.yaml#/definitions/uint32 + + addr-gpios: + description: + List of GPIO descriptors that will be used to address the MSBs address + lines. The order goes from LSB to MSB. + minItems: 1 + maxItems: 8 + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + big-endian: true + little-endian: true + +patternProperties: + '@[0-9a-f]+$': + $ref: partitions/partition.yaml + +required: + - compatible + - reg + +# FIXME: A parent bus may define timing properties +additionalProperties: true + +examples: + - | + + flash@ff000000 { + compatible = "cfi-flash"; + reg = <0xff000000 0x01000000>; + bank-width = <4>; + device-width = <1>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0xff000000 0x01000000>; + + fs@0 { + label = "fs"; + reg = <0 0xf80000>; + }; + firmware@f80000 { + label ="firmware"; + reg = <0xf80000 0x80000>; + read-only; + }; + }; + + - | + /* An example with multiple "reg" tuples */ + + flash@0 { + compatible = "intel,PC28F640P30T85", "cfi-flash"; + reg = <0x00000000 0x02000000>, + <0x02000000 0x02000000>; + bank-width = <2>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0 0x04000000>; + + partition@0 { + label = "test-part1"; + reg = <0 0x04000000>; + }; + }; + + - | + /* An example using SRAM */ + bus { + #address-cells = <2>; + #size-cells = <1>; + + sram@2,0 { + compatible = "mtd-ram"; + reg = <2 0 0x00200000>; + bank-width = <2>; + }; + }; + + - | + /* An example using addr-gpios */ + #include <dt-bindings/gpio/gpio.h> + + flash@20000000 { + compatible = "cfi-flash"; + reg = <0x20000000 0x02000000>; + bank-width = <2>; + addr-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x00000000 0x02000000>, + <1 0x02000000 0x02000000>; + + partition@0 { + label = "test-part1"; + reg = <0 0x04000000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml b/Documentation/devicetree/bindings/mtd/mtd.yaml new file mode 100644 index 000000000000..376b679cfc70 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mtd.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/mtd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MTD (Memory Technology Device) Device Tree Bindings + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + - Richard Weinberger <richard@nod.at> + +properties: + $nodename: + pattern: "^flash(@.*)?$" + + label: + description: + User-defined MTD device name. Can be used to assign user friendly + names to MTD devices (instead of the flash model or flash controller + based name) in order to ease flash device identification and/or + describe what they are used for. + +patternProperties: + "^otp(-[0-9]+)?$": + type: object + $ref: ../nvmem/nvmem.yaml# + + description: | + An OTP memory region. Some flashes provide a one-time-programmable + memory whose content can either be programmed by a user or is already + pre-programmed by the factory. Some flashes might provide both. + + properties: + compatible: + enum: + - user-otp + - factory-otp + + required: + - compatible + +additionalProperties: true + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + reg = <0>; + compatible = "jedec,spi-nor"; + label = "System-firmware"; + }; + }; + + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + reg = <0>; + compatible = "jedec,spi-nor"; + + otp-1 { + compatible = "factory-otp"; + #address-cells = <1>; + #size-cells = <1>; + + electronic-serial-number@0 { + reg = <0 8>; + }; + }; + + otp-2 { + compatible = "user-otp"; + #address-cells = <1>; + #size-cells = <1>; + + mac-address@0 { + reg = <0 6>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index 678b39952502..bd217e6f5018 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -38,6 +38,17 @@ properties: ranges: true + cs-gpios: + minItems: 1 + maxItems: 8 + description: + Array of chip-select available to the controller. The first + entries are a 1:1 mapping of the available chip-select on the + NAND controller (even if they are not used). As many additional + chip-select as needed may follow and should be phandles of GPIO + lines. 'reg' entries of the NAND chip subnodes become indexes of + this array when this property is present. + patternProperties: "^nand@[a-f0-9]$": type: object @@ -164,14 +175,19 @@ examples: nand-controller { #address-cells = <1>; #size-cells = <0>; + cs-gpios = <0>, <&gpioA 1>; /* A single native CS is available */ /* controller specific properties */ nand@0 { - reg = <0>; + reg = <0>; /* Native CS */ nand-use-soft-ecc-engine; nand-ecc-algo = "bch"; /* controller specific properties */ }; + + nand@1 { + reg = <1>; /* GPIO CS */ + }; }; diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt b/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt index b677147ca4e1..c2175d3c82ec 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt +++ b/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt @@ -28,6 +28,11 @@ detected by a software parsing TRX header. Required properties: - compatible : (required) must be "brcm,trx" +Optional properties: + +- brcm,trx-magic: TRX magic, if it is different from the default magic + 0x30524448 as a u32. + Example: flash@0 { diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt deleted file mode 100644 index faa81c2e5da6..000000000000 --- a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt +++ /dev/null @@ -1,51 +0,0 @@ -Bindings for HyperBus Memory Controller (HBMC) on TI's K3 family of SoCs - -Required properties: -- compatible : "ti,am654-hbmc" for AM654 SoC -- reg : Two entries: - First entry pointed to the register space of HBMC controller - Second entry pointing to the memory map region dedicated for - MMIO access to attached flash devices -- ranges : Address translation from offset within CS to allocated MMIO - space in SoC - -Optional properties: -- mux-controls : phandle to the multiplexer that controls selection of - HBMC vs OSPI inside Flash SubSystem (FSS). Default is OSPI, - if property is absent. - See Documentation/devicetree/bindings/mux/reg-mux.txt - for mmio-mux binding details - -Example: - - system-controller@47000000 { - compatible = "syscon", "simple-mfd"; - reg = <0x0 0x47000000 0x0 0x100>; - #address-cells = <2>; - #size-cells = <2>; - ranges; - - hbmc_mux: multiplexer { - compatible = "mmio-mux"; - #mux-control-cells = <1>; - mux-reg-masks = <0x4 0x2>; /* 0: reg 0x4, bit 1 */ - }; - }; - - hbmc: hyperbus@47034000 { - compatible = "ti,am654-hbmc"; - reg = <0x0 0x47034000 0x0 0x100>, - <0x5 0x00000000 0x1 0x0000000>; - power-domains = <&k3_pds 55>; - #address-cells = <2>; - #size-cells = <1>; - ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ - <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */ - mux-controls = <&hbmc_mux 0>; - - /* Slave flash node */ - flash@0,0 { - compatible = "cypress,hyperflash", "cfi-flash"; - reg = <0x0 0x0 0x4000000>; - }; - }; diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml new file mode 100644 index 000000000000..30b458c41cac --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/ti,am654-hbmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HyperBus Memory Controller (HBMC) on TI's K3 family of SoCs + +maintainers: + - Vignesh Raghavendra <vigneshr@ti.com> + +properties: + compatible: + const: ti,am654-hbmc + + reg: + maxItems: 2 + + power-domains: true + '#address-cells': true + '#size-cells': true + ranges: true + + mux-controls: + description: MMIO mux controller node to select b/w OSPI and HBMC. + + clocks: + maxItems: 1 + +patternProperties: + "^flash@[0-1],[0-9a-f]+$": + type: object + +required: + - compatible + - reg + - ranges + - clocks + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + hbmc: memory-controller@47034000 { + compatible = "ti,am654-hbmc"; + reg = <0x0 0x47034000 0x0 0x100>, + <0x5 0x00000000 0x1 0x0000000>; + ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ + <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */ + clocks = <&k3_clks 102 0>; + #address-cells = <2>; + #size-cells = <1>; + power-domains = <&k3_pds 55>; + mux-controls = <&hbmc_mux 0>; + + flash@0,0 { + compatible = "cypress,hyperflash", "cfi-flash"; + reg = <0x0 0x0 0x4000000>; + #address-cells = <1>; + #size-cells = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mux/adi,adg792a.txt b/Documentation/devicetree/bindings/mux/adi,adg792a.txt index 96b787a69f50..b0e5bf6903d8 100644 --- a/Documentation/devicetree/bindings/mux/adi,adg792a.txt +++ b/Documentation/devicetree/bindings/mux/adi,adg792a.txt @@ -5,7 +5,7 @@ Required properties: - #mux-control-cells : <0> if parallel (the three muxes are bound together with a single mux controller controlling all three muxes), or <1> if not (one mux controller for each mux). -* Standard mux-controller bindings as described in mux-controller.txt +* Standard mux-controller bindings as described in mux-controller.yaml Optional properties for ADG792G: - gpio-controller : if present, #gpio-cells below is required. diff --git a/Documentation/devicetree/bindings/mux/adi,adgs1408.txt b/Documentation/devicetree/bindings/mux/adi,adgs1408.txt index be6947f4d86b..453a38961c13 100644 --- a/Documentation/devicetree/bindings/mux/adi,adgs1408.txt +++ b/Documentation/devicetree/bindings/mux/adi,adgs1408.txt @@ -4,7 +4,7 @@ Required properties: - compatible : Should be one of * "adi,adgs1408" * "adi,adgs1409" -* Standard mux-controller bindings as described in mux-controller.txt +* Standard mux-controller bindings as described in mux-controller.yaml Optional properties for ADGS1408/1409: - gpio-controller : if present, #gpio-cells is required. diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.txt b/Documentation/devicetree/bindings/mux/gpio-mux.txt deleted file mode 100644 index b8f746344d80..000000000000 --- a/Documentation/devicetree/bindings/mux/gpio-mux.txt +++ /dev/null @@ -1,69 +0,0 @@ -GPIO-based multiplexer controller bindings - -Define what GPIO pins are used to control a multiplexer. Or several -multiplexers, if the same pins control more than one multiplexer. - -Required properties: -- compatible : "gpio-mux" -- mux-gpios : list of gpios used to control the multiplexer, least - significant bit first. -- #mux-control-cells : <0> -* Standard mux-controller bindings as decribed in mux-controller.txt - -Optional properties: -- idle-state : if present, the state the mux will have when idle. The - special state MUX_IDLE_AS_IS is the default. - -The multiplexer state is defined as the number represented by the -multiplexer GPIO pins, where the first pin is the least significant -bit. An active pin is a binary 1, an inactive pin is a binary 0. - -Example: - - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - - channels = "sync-1", "in", "out", "sync-2"; - }; - - i2c-mux { - compatible = "i2c-mux"; - i2c-parent = <&i2c1>; - - mux-controls = <&mux>; - - #address-cells = <1>; - #size-cells = <0>; - - i2c@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - ssd1307: oled@3c { - /* ... */ - }; - }; - - i2c@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - pca9555: pca9555@20 { - /* ... */ - }; - }; - }; diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.yaml b/Documentation/devicetree/bindings/mux/gpio-mux.yaml new file mode 100644 index 000000000000..0a7c8d64981a --- /dev/null +++ b/Documentation/devicetree/bindings/mux/gpio-mux.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/gpio-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO-based multiplexer controller bindings + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: |+ + Define what GPIO pins are used to control a multiplexer. Or several + multiplexers, if the same pins control more than one multiplexer. + + The multiplexer state is defined as the number represented by the + multiplexer GPIO pins, where the first pin is the least significant + bit. An active pin is a binary 1, an inactive pin is a binary 0. + +properties: + compatible: + const: gpio-mux + + mux-gpios: + description: + List of gpios used to control the multiplexer, least significant bit first. + + '#mux-control-cells': + const: 0 + + idle-state: + default: -1 + +required: + - compatible + - mux-gpios + - "#mux-control-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux>; + + channels = "sync-1", "in", "out", "sync-2"; + }; + + i2c-mux { + compatible = "i2c-mux"; + i2c-parent = <&i2c1>; + + mux-controls = <&mux>; + + #address-cells = <1>; + #size-cells = <0>; + + i2c@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + ssd1307: oled@3c { + reg = <0x3c>; + }; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + pca9555: pca9555@20 { + reg = <0x20>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml new file mode 100644 index 000000000000..7af93298ab5c --- /dev/null +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/mux-consumer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common multiplexer controller consumer bindings + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: | + Mux controller consumers should specify a list of mux controllers that they + want to use with a property containing a 'mux-ctrl-list': + + mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list] + single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier] + mux-ctrl-phandle : phandle to mux controller node + mux-ctrl-specifier : array of #mux-control-cells specifying the + given mux controller (controller specific) + + Mux controller properties should be named "mux-controls". The exact meaning of + each mux controller property must be documented in the device tree binding for + each consumer. An optional property "mux-control-names" may contain a list of + strings to label each of the mux controllers listed in the "mux-controls" + property. + + mux-ctrl-specifier typically encodes the chip-relative mux controller number. + If the mux controller chip only provides a single mux controller, the + mux-ctrl-specifier can typically be left out. + +select: true + +properties: + mux-controls: + $ref: /schemas/types.yaml#/definitions/phandle-array + + mux-control-names: + description: + Devices that use more than a single mux controller can use the + "mux-control-names" property to map the name of the requested mux + controller to an index into the list given by the "mux-controls" property. + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/mux/mux-controller.txt b/Documentation/devicetree/bindings/mux/mux-controller.txt deleted file mode 100644 index 4f47e4bd2fa0..000000000000 --- a/Documentation/devicetree/bindings/mux/mux-controller.txt +++ /dev/null @@ -1,157 +0,0 @@ -Common multiplexer controller bindings -====================================== - -A multiplexer (or mux) controller will have one, or several, consumer devices -that uses the mux controller. Thus, a mux controller can possibly control -several parallel multiplexers. Presumably there will be at least one -multiplexer needed by each consumer, but a single mux controller can of course -control several multiplexers for a single consumer. - -A mux controller provides a number of states to its consumers, and the state -space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer, -0-7 for an 8-way multiplexer, etc. - - -Consumers ---------- - -Mux controller consumers should specify a list of mux controllers that they -want to use with a property containing a 'mux-ctrl-list': - - mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list] - single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier] - mux-ctrl-phandle : phandle to mux controller node - mux-ctrl-specifier : array of #mux-control-cells specifying the - given mux controller (controller specific) - -Mux controller properties should be named "mux-controls". The exact meaning of -each mux controller property must be documented in the device tree binding for -each consumer. An optional property "mux-control-names" may contain a list of -strings to label each of the mux controllers listed in the "mux-controls" -property. - -Drivers for devices that use more than a single mux controller can use the -"mux-control-names" property to map the name of the requested mux controller -to an index into the list given by the "mux-controls" property. - -mux-ctrl-specifier typically encodes the chip-relative mux controller number. -If the mux controller chip only provides a single mux controller, the -mux-ctrl-specifier can typically be left out. - -Example: - - /* One consumer of a 2-way mux controller (one GPIO-line) */ - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - mux-control-names = "adc"; - - channels = "sync", "in"; - }; - -Note that in the example above, specifying the "mux-control-names" is redundant -because there is only one mux controller in the list. However, if the driver -for the consumer node in fact asks for a named mux controller, that name is of -course still required. - - /* - * Two consumers (one for an ADC line and one for an i2c bus) of - * parallel 4-way multiplexers controlled by the same two GPIO-lines. - */ - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - - channels = "sync-1", "in", "out", "sync-2"; - }; - - i2c-mux { - compatible = "i2c-mux"; - i2c-parent = <&i2c1>; - - mux-controls = <&mux>; - - #address-cells = <1>; - #size-cells = <0>; - - i2c@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - ssd1307: oled@3c { - /* ... */ - }; - }; - - i2c@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - pca9555: pca9555@20 { - /* ... */ - }; - }; - }; - - -Mux controller nodes --------------------- - -Mux controller nodes must specify the number of cells used for the -specifier using the '#mux-control-cells' property. - -Optionally, mux controller nodes can also specify the state the mux should -have when it is idle. The idle-state property is used for this. If the -idle-state is not present, the mux controller is typically left as is when -it is idle. For multiplexer chips that expose several mux controllers, the -idle-state property is an array with one idle state for each mux controller. - -The special value (-1) may be used to indicate that the mux should be left -as is when it is idle. This is the default, but can still be useful for -mux controller chips with more than one mux controller, particularly when -there is a need to "step past" a mux controller and set some other idle -state for a mux controller with a higher index. - -Some mux controllers have the ability to disconnect the input/output of the -multiplexer. Using this disconnected high-impedance state as the idle state -is indicated with idle state (-2). - -These constants are available in - - #include <dt-bindings/mux/mux.h> - -as MUX_IDLE_AS_IS (-1) and MUX_IDLE_DISCONNECT (-2). - -An example mux controller node look like this (the adg972a chip is a triple -4-way multiplexer): - - mux: mux-controller@50 { - compatible = "adi,adg792a"; - reg = <0x50>; - #mux-control-cells = <1>; - - idle-state = <MUX_IDLE_DISCONNECT MUX_IDLE_AS_IS 2>; - }; diff --git a/Documentation/devicetree/bindings/mux/mux-controller.yaml b/Documentation/devicetree/bindings/mux/mux-controller.yaml new file mode 100644 index 000000000000..736a84c3b6a5 --- /dev/null +++ b/Documentation/devicetree/bindings/mux/mux-controller.yaml @@ -0,0 +1,182 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/mux-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common multiplexer controller provider bindings + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: | + A multiplexer (or mux) controller will have one, or several, consumer devices + that uses the mux controller. Thus, a mux controller can possibly control + several parallel multiplexers. Presumably there will be at least one + multiplexer needed by each consumer, but a single mux controller can of course + control several multiplexers for a single consumer. + + A mux controller provides a number of states to its consumers, and the state + space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer, + 0-7 for an 8-way multiplexer, etc. + + + Mux controller nodes + -------------------- + + Mux controller nodes must specify the number of cells used for the + specifier using the '#mux-control-cells' property. + + Optionally, mux controller nodes can also specify the state the mux should + have when it is idle. The idle-state property is used for this. If the + idle-state is not present, the mux controller is typically left as is when + it is idle. For multiplexer chips that expose several mux controllers, the + idle-state property is an array with one idle state for each mux controller. + + The special value (-1) may be used to indicate that the mux should be left + as is when it is idle. This is the default, but can still be useful for + mux controller chips with more than one mux controller, particularly when + there is a need to "step past" a mux controller and set some other idle + state for a mux controller with a higher index. + + Some mux controllers have the ability to disconnect the input/output of the + multiplexer. Using this disconnected high-impedance state as the idle state + is indicated with idle state (-2). + + These constants are available in + + #include <dt-bindings/mux/mux.h> + + as MUX_IDLE_AS_IS (-1) and MUX_IDLE_DISCONNECT (-2). + + An example mux controller node look like this (the adg972a chip is a triple + 4-way multiplexer): + + mux: mux-controller@50 { + compatible = "adi,adg792a"; + reg = <0x50>; + #mux-control-cells = <1>; + + idle-state = <MUX_IDLE_DISCONNECT MUX_IDLE_AS_IS 2>; + }; + +select: + anyOf: + - properties: + $nodename: + pattern: '^mux-controller' + - required: + - '#mux-control-cells' + +properties: + $nodename: + pattern: '^mux-controller(@.*|-[0-9a-f]+)?$' + + '#mux-control-cells': + enum: [ 0, 1 ] + + idle-state: + $ref: /schemas/types.yaml#/definitions/int32 + minimum: -2 + + idle-states: + description: | + Mux controller nodes can specify the state the mux should have when it is + idle. If the idle-state is not present, the mux controller is typically + left as is when it is idle. For multiplexer chips that expose several mux + controllers, the idle-state property is an array with one idle state for + each mux controller. + + The special value (-1) may be used to indicate that the mux should be left + as is when it is idle. This is the default, but can still be useful for + mux controller chips with more than one mux controller, particularly when + there is a need to "step past" a mux controller and set some other idle + state for a mux controller with a higher index. + + Some mux controllers have the ability to disconnect the input/output of the + multiplexer. Using this disconnected high-impedance state as the idle state + is indicated with idle state (-2). + $ref: /schemas/types.yaml#/definitions/int32-array + items: + minimum: -2 + +additionalProperties: true + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + /* One consumer of a 2-way mux controller (one GPIO-line) */ + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux>; + mux-control-names = "adc"; + + channels = "sync", "in"; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + + /* + * Two consumers (one for an ADC line and one for an i2c bus) of + * parallel 4-way multiplexers controlled by the same two GPIO-lines. + */ + mux2: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux2>; + + channels = "sync-1", "in", "out", "sync-2"; + }; + + i2c-mux { + compatible = "i2c-mux"; + i2c-parent = <&i2c1>; + + mux-controls = <&mux2>; + + #address-cells = <1>; + #size-cells = <0>; + + i2c@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + ssd1307: oled@3c { + reg = <0x3c>; + }; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + pca9555: pca9555@20 { + reg = <0x20>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mux/reg-mux.txt b/Documentation/devicetree/bindings/mux/reg-mux.txt deleted file mode 100644 index 4afd7ba73d60..000000000000 --- a/Documentation/devicetree/bindings/mux/reg-mux.txt +++ /dev/null @@ -1,129 +0,0 @@ -Generic register bitfield-based multiplexer controller bindings - -Define register bitfields to be used to control multiplexers. The parent -device tree node must be a device node to provide register r/w access. - -Required properties: -- compatible : should be one of - "reg-mux" : if parent device of mux controller is not syscon device - "mmio-mux" : if parent device of mux controller is syscon device -- #mux-control-cells : <1> -- mux-reg-masks : an array of register offset and pre-shifted bitfield mask - pairs, each describing a single mux control. -* Standard mux-controller bindings as decribed in mux-controller.txt - -Optional properties: -- idle-states : if present, the state the muxes will have when idle. The - special state MUX_IDLE_AS_IS is the default. - -The multiplexer state of each multiplexer is defined as the value of the -bitfield described by the corresponding register offset and bitfield mask -pair in the mux-reg-masks array. - -Example 1: -The parent device of mux controller is not a syscon device. - -&i2c0 { - fpga@66 { // fpga connected to i2c - compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c", - "simple-mfd"; - reg = <0x66>; - - mux: mux-controller { - compatible = "reg-mux"; - #mux-control-cells = <1>; - mux-reg-masks = <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ - <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ - }; - }; -}; - -mdio-mux-1 { - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 0>; - mdio-parent-bus = <&emdio1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@8 { - reg = <0x8>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; - -mdio-mux-2 { - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 1>; - mdio-parent-bus = <&emdio2>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@1 { - reg = <0x1>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; - -Example 2: -The parent device of mux controller is syscon device. - -syscon { - compatible = "syscon"; - - mux: mux-controller { - compatible = "mmio-mux"; - #mux-control-cells = <1>; - - mux-reg-masks = <0x3 0x30>, /* 0: reg 0x3, bits 5:4 */ - <0x3 0x40>, /* 1: reg 0x3, bit 6 */ - idle-states = <MUX_IDLE_AS_IS>, <0>; - }; -}; - -video-mux { - compatible = "video-mux"; - mux-controls = <&mux 0>; - #address-cells = <1>; - #size-cells = <0>; - - ports { - /* inputs 0..3 */ - port@0 { - reg = <0>; - }; - port@1 { - reg = <1>; - }; - port@2 { - reg = <2>; - }; - port@3 { - reg = <3>; - }; - - /* output */ - port@4 { - reg = <4>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mux/reg-mux.yaml b/Documentation/devicetree/bindings/mux/reg-mux.yaml new file mode 100644 index 000000000000..60d5746eb39d --- /dev/null +++ b/Documentation/devicetree/bindings/mux/reg-mux.yaml @@ -0,0 +1,143 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/reg-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic register bitfield-based multiplexer controller bindings + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: |+ + Define register bitfields to be used to control multiplexers. The parent + device tree node must be a device node to provide register r/w access. + +properties: + compatible: + enum: + - reg-mux # parent device of mux controller is not syscon device + - mmio-mux # parent device of mux controller is syscon device + + reg: true + + '#mux-control-cells': + const: 1 + + mux-reg-masks: + description: an array of register offset and pre-shifted bitfield mask + pairs, each describing a single mux control. + + idle-states: true + +required: + - compatible + - mux-reg-masks + - '#mux-control-cells' + +additionalProperties: false + +examples: + - | + /* The parent device of mux controller is not a syscon device. */ + + #include <dt-bindings/mux/mux.h> + + mux-controller { + compatible = "reg-mux"; + #mux-control-cells = <1>; + mux-reg-masks = + <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ + <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ + }; + + mdio-mux-1 { + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux1 0>; + mdio-parent-bus = <&emdio1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@8 { + reg = <0x8>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + mdio-mux-2 { + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux1 1>; + mdio-parent-bus = <&emdio2>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@1 { + reg = <0x1>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + - | + /* The parent device of mux controller is syscon device. */ + + #include <dt-bindings/mux/mux.h> + syscon@1000 { + compatible = "fsl,imx7d-iomuxc-gpr", "fsl,imx6q-iomuxc-gpr", "syscon", "simple-mfd"; + reg = <0x1000 0x100>; + + mux2: mux-controller { + compatible = "mmio-mux"; + #mux-control-cells = <1>; + + mux-reg-masks = + <0x3 0x30>, /* 0: reg 0x3, bits 5:4 */ + <0x3 0x40>; /* 1: reg 0x3, bit 6 */ + idle-states = <MUX_IDLE_AS_IS>, <0>; + }; + }; + + video-mux { + compatible = "video-mux"; + mux-controls = <&mux2 0>; + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + /* inputs 0..3 */ + port@0 { + reg = <0>; + }; + port@1 { + reg = <1>; + }; + port@2 { + reg = <2>; + }; + port@3 { + reg = <3>; + }; + + /* output */ + port@4 { + reg = <4>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index 0467441d7037..608e1d62bed5 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -43,7 +43,6 @@ allOf: properties: clocks: minItems: 3 - maxItems: 4 items: - description: GMAC main clock - description: First parent clock of the internal mux @@ -52,7 +51,6 @@ allOf: clock-names: minItems: 3 - maxItems: 4 items: - const: stmmaceth - const: clkin0 diff --git a/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml b/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml index 2f46e45dcd60..a93d2f165899 100644 --- a/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml +++ b/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml @@ -23,14 +23,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: RX interrupt - description: TX interrupt interrupt-names: minItems: 1 - maxItems: 2 items: - const: rx - const: tx diff --git a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt deleted file mode 100644 index 8ba9ed11d716..000000000000 --- a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt +++ /dev/null @@ -1,23 +0,0 @@ -* Broadcom iProc MDIO bus controller - -Required properties: -- compatible: should be "brcm,iproc-mdio" -- reg: address and length of the register set for the MDIO interface -- #size-cells: must be 1 -- #address-cells: must be 0 - -Child nodes of this MDIO bus controller node are standard Ethernet PHY device -nodes as described in Documentation/devicetree/bindings/net/phy.txt - -Example: - -mdio@18002000 { - compatible = "brcm,iproc-mdio"; - reg = <0x18002000 0x8>; - #size-cells = <1>; - #address-cells = <0>; - - enet-gphy@0 { - reg = <0>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.yaml new file mode 100644 index 000000000000..3031395f7e6e --- /dev/null +++ b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/brcm,iproc-mdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom iProc MDIO bus controller + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +allOf: + - $ref: mdio.yaml# + +properties: + compatible: + const: brcm,iproc-mdio + + reg: + maxItems: 1 + +unevaluatedProperties: false + +required: + - reg + +examples: + - | + mdio@18002000 { + compatible = "brcm,iproc-mdio"; + reg = <0x18002000 0x8>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@0 { + reg = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt index b58843f29591..deb9e852ea27 100644 --- a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt +++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt @@ -17,7 +17,7 @@ Optional properties: - clocks: phandle of the core clock which drives the mdio block. Additional information regarding generic multiplexer properties can be found -at- Documentation/devicetree/bindings/net/mdio-mux.txt +at- Documentation/devicetree/bindings/net/mdio-mux.yaml for example: diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 798fa5fb7bb2..f84e31348d80 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -30,14 +30,12 @@ properties: - description: interrupt line0 - description: interrupt line1 minItems: 1 - maxItems: 2 interrupt-names: items: - const: int0 - const: int1 minItems: 1 - maxItems: 2 clocks: items: diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt index 2d504256b0d8..366479806acb 100644 --- a/Documentation/devicetree/bindings/net/can/c_can.txt +++ b/Documentation/devicetree/bindings/net/can/c_can.txt @@ -19,10 +19,10 @@ The following are mandatory properties for Keystone 2 66AK2G SoCs only: - power-domains : Should contain a phandle to a PM domain provider node and an args specifier containing the DCAN device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml - clocks : CAN functional clock phandle. This property is as per the binding, - Documentation/devicetree/bindings/clock/ti,sci-clk.txt + Documentation/devicetree/bindings/clock/ti,sci-clk.yaml Optional properties: - syscon-raminit : Handle to system control region that contains the diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt deleted file mode 100644 index 90ac4fef23f5..000000000000 --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt +++ /dev/null @@ -1,80 +0,0 @@ -Renesas R-Car CAN controller Device Tree Bindings -------------------------------------------------- - -Required properties: -- compatible: "renesas,can-r8a7742" if CAN controller is a part of R8A7742 SoC. - "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC. - "renesas,can-r8a7744" if CAN controller is a part of R8A7744 SoC. - "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC. - "renesas,can-r8a77470" if CAN controller is a part of R8A77470 SoC. - "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC. - "renesas,can-r8a774b1" if CAN controller is a part of R8A774B1 SoC. - "renesas,can-r8a774c0" if CAN controller is a part of R8A774C0 SoC. - "renesas,can-r8a774e1" if CAN controller is a part of R8A774E1 SoC. - "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC. - "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC. - "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC. - "renesas,can-r8a7791" if CAN controller is a part of R8A7791 SoC. - "renesas,can-r8a7792" if CAN controller is a part of R8A7792 SoC. - "renesas,can-r8a7793" if CAN controller is a part of R8A7793 SoC. - "renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC. - "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC. - "renesas,can-r8a7796" if CAN controller is a part of R8A77960 SoC. - "renesas,can-r8a77961" if CAN controller is a part of R8A77961 SoC. - "renesas,can-r8a77965" if CAN controller is a part of R8A77965 SoC. - "renesas,can-r8a77990" if CAN controller is a part of R8A77990 SoC. - "renesas,can-r8a77995" if CAN controller is a part of R8A77995 SoC. - "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device. - "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1 - compatible device. - "renesas,rcar-gen3-can" for a generic R-Car Gen3 or RZ/G2 - compatible device. - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first - followed by the generic version. - -- reg: physical base address and size of the R-Car CAN register map. -- interrupts: interrupt specifier for the sole interrupt. -- clocks: phandles and clock specifiers for 3 CAN clock inputs. -- clock-names: 3 clock input name strings: "clkp1", "clkp2", and "can_clk". -- pinctrl-0: pin control group to be used for this controller. -- pinctrl-names: must be "default". - -Required properties for R8A774A1, R8A774B1, R8A774C0, R8A774E1, R8A7795, -R8A77960, R8A77961, R8A77965, R8A77990, and R8A77995: -For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock and can -be used by both CAN and CAN FD controller at the same time. It needs to be -scaled to maximum frequency if any of these controllers use it. This is done -using the below properties: - -- assigned-clocks: phandle of clkp2(CANFD) clock. -- assigned-clock-rates: maximum frequency of this clock. - -Optional properties: -- renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values are: - <0x0> (default) : Peripheral clock (clkp1) - <0x1> : Peripheral clock (clkp2) - <0x3> : External input clock - -Example -------- - -SoC common .dtsi file: - - can0: can@e6e80000 { - compatible = "renesas,can-r8a7791", "renesas,rcar-gen2-can"; - reg = <0 0xe6e80000 0 0x1000>; - interrupts = <0 186 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp9_clks R8A7791_CLK_RCAN0>, - <&cpg_clocks R8A7791_CLK_RCAN>, <&can_clk>; - clock-names = "clkp1", "clkp2", "can_clk"; - status = "disabled"; - }; - -Board specific .dts file: - -&can0 { - pinctrl-0 = <&can0_pins>; - pinctrl-names = "default"; - status = "okay"; -}; diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt deleted file mode 100644 index 248c4ed97a0a..000000000000 --- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt +++ /dev/null @@ -1,107 +0,0 @@ -Renesas R-Car CAN FD controller Device Tree Bindings ----------------------------------------------------- - -Required properties: -- compatible: Must contain one or more of the following: - - "renesas,rcar-gen3-canfd" for R-Car Gen3 and RZ/G2 compatible controllers. - - "renesas,r8a774a1-canfd" for R8A774A1 (RZ/G2M) compatible controller. - - "renesas,r8a774b1-canfd" for R8A774B1 (RZ/G2N) compatible controller. - - "renesas,r8a774c0-canfd" for R8A774C0 (RZ/G2E) compatible controller. - - "renesas,r8a774e1-canfd" for R8A774E1 (RZ/G2H) compatible controller. - - "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller. - - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller. - - "renesas,r8a77965-canfd" for R8A77965 (R-Car M3-N) compatible controller. - - "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller. - - "renesas,r8a77980-canfd" for R8A77980 (R-Car V3H) compatible controller. - - "renesas,r8a77990-canfd" for R8A77990 (R-Car E3) compatible controller. - - "renesas,r8a77995-canfd" for R8A77995 (R-Car D3) compatible controller. - - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first, followed by the - family-specific and/or generic versions. - -- reg: physical base address and size of the R-Car CAN FD register map. -- interrupts: interrupt specifiers for the Channel & Global interrupts -- clocks: phandles and clock specifiers for 3 clock inputs. -- clock-names: 3 clock input name strings: "fck", "canfd", "can_clk". -- pinctrl-0: pin control group to be used for this controller. -- pinctrl-names: must be "default". - -Required child nodes: -The controller supports two channels and each is represented as a child node. -The name of the child nodes are "channel0" and "channel1" respectively. Each -child node supports the "status" property only, which is used to -enable/disable the respective channel. - -Required properties for R8A774A1, R8A774B1, R8A774C0, R8A774E1, R8A7795, -R8A7796, R8A77965, R8A77990, and R8A77995: -In the denoted SoCs, canfd clock is a div6 clock and can be used by both CAN -and CAN FD controller at the same time. It needs to be scaled to maximum -frequency if any of these controllers use it. This is done using the below -properties: - -- assigned-clocks: phandle of canfd clock. -- assigned-clock-rates: maximum frequency of this clock. - -Optional property: -The controller can operate in either CAN FD only mode (default) or -Classical CAN only mode. The mode is global to both the channels. In order to -enable the later, define the following optional property. - - renesas,no-can-fd: puts the controller in Classical CAN only mode. - -Example -------- - -SoC common .dtsi file: - - canfd: can@e66c0000 { - compatible = "renesas,r8a7795-canfd", - "renesas,rcar-gen3-canfd"; - reg = <0 0xe66c0000 0 0x8000>; - interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 914>, - <&cpg CPG_CORE R8A7795_CLK_CANFD>, - <&can_clk>; - clock-names = "fck", "canfd", "can_clk"; - assigned-clocks = <&cpg CPG_CORE R8A7795_CLK_CANFD>; - assigned-clock-rates = <40000000>; - power-domains = <&cpg>; - status = "disabled"; - - channel0 { - status = "disabled"; - }; - - channel1 { - status = "disabled"; - }; - }; - -Board specific .dts file: - -E.g. below enables Channel 1 alone in the board in Classical CAN only mode. - -&canfd { - pinctrl-0 = <&canfd1_pins>; - pinctrl-names = "default"; - renesas,no-can-fd; - status = "okay"; - - channel1 { - status = "okay"; - }; -}; - -E.g. below enables Channel 0 alone in the board using External clock -as fCAN clock. - -&canfd { - pinctrl-0 = <&canfd0_pins>, <&can_clk_pins>; - pinctrl-names = "default"; - status = "okay"; - - channel0 { - status = "okay"; - }; -}; diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml new file mode 100644 index 000000000000..fadc871fd6b0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml @@ -0,0 +1,139 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/renesas,rcar-can.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car CAN Controller + +maintainers: + - Sergei Shtylyov <sergei.shtylyov@gmail.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,can-r8a7778 # R-Car M1-A + - renesas,can-r8a7779 # R-Car H1 + - const: renesas,rcar-gen1-can # R-Car Gen1 + + - items: + - enum: + - renesas,can-r8a7742 # RZ/G1H + - renesas,can-r8a7743 # RZ/G1M + - renesas,can-r8a7744 # RZ/G1N + - renesas,can-r8a7745 # RZ/G1E + - renesas,can-r8a77470 # RZ/G1C + - renesas,can-r8a7790 # R-Car H2 + - renesas,can-r8a7791 # R-Car M2-W + - renesas,can-r8a7792 # R-Car V2H + - renesas,can-r8a7793 # R-Car M2-N + - renesas,can-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-can # R-Car Gen2 and RZ/G1 + + - items: + - enum: + - renesas,can-r8a774a1 # RZ/G2M + - renesas,can-r8a774b1 # RZ/G2N + - renesas,can-r8a774c0 # RZ/G2E + - renesas,can-r8a774e1 # RZ/G2H + - renesas,can-r8a7795 # R-Car H3 + - renesas,can-r8a7796 # R-Car M3-W + - renesas,can-r8a77961 # R-Car M3-W+ + - renesas,can-r8a77965 # R-Car M3-N + - renesas,can-r8a77990 # R-Car E3 + - renesas,can-r8a77995 # R-Car D3 + - const: renesas,rcar-gen3-can # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 3 + + clock-names: + items: + - const: clkp1 + - const: clkp2 + - const: can_clk + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + renesas,can-clock-select: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 3 ] + default: 0 + description: | + R-Car CAN Clock Source Select. Valid values are: + <0x0> (default) : Peripheral clock (clkp1) + <0x1> : Peripheral clock (clkp2) + <0x3> : External input clock + + assigned-clocks: + description: + Reference to the clkp2 (CANFD) clock. + On R-Car Gen3 and RZ/G2 SoCs, "clkp2" is the CANFD clock. This is a div6 + clock and can be used by both CAN and CAN FD controllers at the same + time. It needs to be scaled to maximum frequency if any of these + controllers use it. + + assigned-clock-rates: + description: Maximum frequency of the CANFD clock. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + +allOf: + - $ref: can-controller.yaml# + + - if: + not: + properties: + compatible: + contains: + const: renesas,rcar-gen1-can + then: + required: + - resets + + - if: + properties: + compatible: + contains: + const: renesas,rcar-gen3-can + then: + required: + - assigned-clocks + - assigned-clock-rates + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7791-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7791-sysc.h> + + can0: can@e6e80000 { + compatible = "renesas,can-r8a7791", "renesas,rcar-gen2-can"; + reg = <0xe6e80000 0x1000>; + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 916>, + <&cpg CPG_CORE R8A7791_CLK_RCAN>, <&can_clk>; + clock-names = "clkp1", "clkp2", "can_clk"; + power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; + resets = <&cpg 916>; + }; diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml new file mode 100644 index 000000000000..0b33ba9ccb47 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml @@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/renesas,rcar-canfd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car CAN FD Controller + +maintainers: + - Fabrizio Castro <fabrizio.castro.jz@renesas.com> + +allOf: + - $ref: can-controller.yaml# + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,r8a774a1-canfd # RZ/G2M + - renesas,r8a774b1-canfd # RZ/G2N + - renesas,r8a774c0-canfd # RZ/G2E + - renesas,r8a774e1-canfd # RZ/G2H + - renesas,r8a7795-canfd # R-Car H3 + - renesas,r8a7796-canfd # R-Car M3-W + - renesas,r8a77965-canfd # R-Car M3-N + - renesas,r8a77970-canfd # R-Car V3M + - renesas,r8a77980-canfd # R-Car V3H + - renesas,r8a77990-canfd # R-Car E3 + - renesas,r8a77995-canfd # R-Car D3 + - const: renesas,rcar-gen3-canfd # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + items: + - description: Channel interrupt + - description: Global interrupt + + clocks: + maxItems: 3 + + clock-names: + items: + - const: fck + - const: canfd + - const: can_clk + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + renesas,no-can-fd: + $ref: /schemas/types.yaml#/definitions/flag + description: + The controller can operate in either CAN FD only mode (default) or + Classical CAN only mode. The mode is global to both the channels. + Specify this property to put the controller in Classical CAN only mode. + + assigned-clocks: + description: + Reference to the CANFD clock. The CANFD clock is a div6 clock and can be + used by both CAN (if present) and CAN FD controllers at the same time. + It needs to be scaled to maximum frequency if any of these controllers + use it. + + assigned-clock-rates: + description: Maximum frequency of the CANFD clock. + +patternProperties: + "^channel[01]$": + type: object + description: + The controller supports two channels and each is represented as a child + node. Each child node supports the "status" property only, which + is used to enable/disable the respective channel. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - resets + - assigned-clocks + - assigned-clock-rates + - channel0 + - channel1 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7795-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7795-sysc.h> + + canfd: can@e66c0000 { + compatible = "renesas,r8a7795-canfd", + "renesas,rcar-gen3-canfd"; + reg = <0xe66c0000 0x8000>; + interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 914>, + <&cpg CPG_CORE R8A7795_CLK_CANFD>, + <&can_clk>; + clock-names = "fck", "canfd", "can_clk"; + assigned-clocks = <&cpg CPG_CORE R8A7795_CLK_CANFD>; + assigned-clock-rates = <40000000>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 914>; + + channel0 { + }; + + channel1 { + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml index d730fe5a4355..d159ac78cec1 100644 --- a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml +++ b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml @@ -48,14 +48,12 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: switch's main clock - description: dividing of the switch core clock clock-names: minItems: 1 - maxItems: 2 items: - const: sw_switch - const: sw_switch_mdiv diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt index de04626a8e9d..18247ebfc487 100644 --- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt +++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt @@ -81,6 +81,12 @@ Optional properties: - gpio-controller: Boolean; if defined, MT7530's LED controller will run on GPIO mode. - #gpio-cells: Must be 2 if gpio-controller is defined. +- interrupt-controller: Boolean; Enables the internal interrupt controller. + +If interrupt-controller is defined, the following properties are required. + +- #interrupt-cells: Must be 1. +- interrupts: Parent interrupt for the interrupt controller. See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional required, optional properties and how the integrated switch subnodes must diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml new file mode 100644 index 000000000000..0b8a05dd52e6 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/nxp,sja1105.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP SJA1105 Automotive Ethernet Switch Family Device Tree Bindings + +description: + The SJA1105 SPI interface requires a CS-to-CLK time (t2 in UM10944.pdf) of at + least one half of t_CLK. At an SPI frequency of 1MHz, this means a minimum + cs_sck_delay of 500ns. Ensuring that this SPI timing requirement is observed + depends on the SPI bus master driver. + +allOf: + - $ref: "dsa.yaml#" + +maintainers: + - Vladimir Oltean <vladimir.oltean@nxp.com> + +properties: + compatible: + enum: + - nxp,sja1105e + - nxp,sja1105t + - nxp,sja1105p + - nxp,sja1105q + - nxp,sja1105r + - nxp,sja1105s + - nxp,sja1110a + - nxp,sja1110b + - nxp,sja1110c + - nxp,sja1110d + + reg: + maxItems: 1 + + # Optional container node for the 2 internal MDIO buses of the SJA1110 + # (one for the internal 100base-T1 PHYs and the other for the single + # 100base-TX PHY). The "reg" property does not have physical significance. + # The PHY addresses to port correspondence is as follows: for 100base-T1, + # port 5 has PHY 1, port 6 has PHY 2 etc, while for 100base-TX, port 1 has + # PHY 1. + mdios: + type: object + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + "^mdio@[0-1]$": + type: object + + allOf: + - $ref: "http://devicetree.org/schemas/net/mdio.yaml#" + + properties: + compatible: + oneOf: + - enum: + - nxp,sja1110-base-t1-mdio + - nxp,sja1110-base-tx-mdio + + reg: + oneOf: + - enum: + - 0 + - 1 + + required: + - compatible + - reg + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-switch@1 { + reg = <0x1>; + compatible = "nxp,sja1105t"; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + phy-handle = <&rgmii_phy6>; + phy-mode = "rgmii-id"; + reg = <0>; + }; + + port@1 { + phy-handle = <&rgmii_phy3>; + phy-mode = "rgmii-id"; + reg = <1>; + }; + + port@2 { + phy-handle = <&rgmii_phy4>; + phy-mode = "rgmii-id"; + reg = <2>; + }; + + port@3 { + phy-mode = "rgmii-id"; + reg = <3>; + }; + + port@4 { + ethernet = <&enet2>; + phy-mode = "rgmii"; + reg = <4>; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt index ccbc6d89325d..8c73f67c43ca 100644 --- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.txt @@ -3,6 +3,7 @@ Required properties: - compatible: should be one of: + "qca,qca8327" "qca,qca8334" "qca,qca8337" @@ -20,6 +21,10 @@ described in dsa/dsa.txt. If the QCA8K switch is connect to a SoC's external mdio-bus each subnode describing a port needs to have a valid phandle referencing the internal PHY it is connected to. This is because there's no N:N mapping of port and PHY id. +To declare the internal mdio-bus configuration, declare a mdio node in the +switch node and declare the phandle for the port referencing the internal +PHY is connected to. In this config a internal mdio-bus is registered and +the mdio MASTER is used as communication. Don't use mixed external and internal mdio-bus configurations, as this is not supported by the hardware. @@ -149,26 +154,61 @@ for the internal master mdio-bus configuration: port@1 { reg = <1>; label = "lan1"; + phy-mode = "internal"; + phy-handle = <&phy_port1>; }; port@2 { reg = <2>; label = "lan2"; + phy-mode = "internal"; + phy-handle = <&phy_port2>; }; port@3 { reg = <3>; label = "lan3"; + phy-mode = "internal"; + phy-handle = <&phy_port3>; }; port@4 { reg = <4>; label = "lan4"; + phy-mode = "internal"; + phy-handle = <&phy_port4>; }; port@5 { reg = <5>; label = "wan"; + phy-mode = "internal"; + phy-handle = <&phy_port5>; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + phy_port1: phy@0 { + reg = <0>; + }; + + phy_port2: phy@1 { + reg = <1>; + }; + + phy_port3: phy@2 { + reg = <2>; + }; + + phy_port4: phy@3 { + reg = <3>; + }; + + phy_port5: phy@4 { + reg = <4>; }; }; }; diff --git a/Documentation/devicetree/bindings/net/dsa/sja1105.txt b/Documentation/devicetree/bindings/net/dsa/sja1105.txt deleted file mode 100644 index 13fd21074d48..000000000000 --- a/Documentation/devicetree/bindings/net/dsa/sja1105.txt +++ /dev/null @@ -1,156 +0,0 @@ -NXP SJA1105 switch driver -========================= - -Required properties: - -- compatible: - Must be one of: - - "nxp,sja1105e" - - "nxp,sja1105t" - - "nxp,sja1105p" - - "nxp,sja1105q" - - "nxp,sja1105r" - - "nxp,sja1105s" - - Although the device ID could be detected at runtime, explicit bindings - are required in order to be able to statically check their validity. - For example, SGMII can only be specified on port 4 of R and S devices, - and the non-SGMII devices, while pin-compatible, are not equal in terms - of support for RGMII internal delays (supported on P/Q/R/S, but not on - E/T). - -Optional properties: - -- sja1105,role-mac: -- sja1105,role-phy: - Boolean properties that can be assigned under each port node. By - default (unless otherwise specified) a port is configured as MAC if it - is driving a PHY (phy-handle is present) or as PHY if it is PHY-less - (fixed-link specified, presumably because it is connected to a MAC). - The effect of this property (in either its implicit or explicit form) - is: - - In the case of MII or RMII it specifies whether the SJA1105 port is a - clock source or sink for this interface (not applicable for RGMII - where there is a Tx and an Rx clock). - - In the case of RGMII it affects the behavior regarding internal - delays: - 1. If sja1105,role-mac is specified, and the phy-mode property is one - of "rgmii-id", "rgmii-txid" or "rgmii-rxid", then the entity - designated to apply the delay/clock skew necessary for RGMII - is the PHY. The SJA1105 MAC does not apply any internal delays. - 2. If sja1105,role-phy is specified, and the phy-mode property is one - of the above, the designated entity to apply the internal delays - is the SJA1105 MAC (if hardware-supported). This is only supported - by the second-generation (P/Q/R/S) hardware. On a first-generation - E or T device, it is an error to specify an RGMII phy-mode other - than "rgmii" for a port that is in fixed-link mode. In that case, - the clock skew must either be added by the MAC at the other end of - the fixed-link, or by PCB serpentine traces on the board. - These properties are required, for example, in the case where SJA1105 - ports are at both ends of a MII/RMII PHY-less setup. One end would need - to have sja1105,role-mac, while the other sja1105,role-phy. - -See Documentation/devicetree/bindings/net/dsa/dsa.txt for the list of standard -DSA required and optional properties. - -Other observations ------------------- - -The SJA1105 SPI interface requires a CS-to-CLK time (t2 in UM10944) of at least -one half of t_CLK. At an SPI frequency of 1MHz, this means a minimum -cs_sck_delay of 500ns. Ensuring that this SPI timing requirement is observed -depends on the SPI bus master driver. - -Example -------- - -Ethernet switch connected via SPI to the host, CPU port wired to enet2: - -arch/arm/boot/dts/ls1021a-tsn.dts: - -/* SPI controller of the LS1021 */ -&dspi0 { - sja1105@1 { - reg = <0x1>; - #address-cells = <1>; - #size-cells = <0>; - compatible = "nxp,sja1105t"; - spi-max-frequency = <4000000>; - fsl,spi-cs-sck-delay = <1000>; - fsl,spi-sck-cs-delay = <1000>; - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - /* ETH5 written on chassis */ - label = "swp5"; - phy-handle = <&rgmii_phy6>; - phy-mode = "rgmii-id"; - reg = <0>; - /* Implicit "sja1105,role-mac;" */ - }; - port@1 { - /* ETH2 written on chassis */ - label = "swp2"; - phy-handle = <&rgmii_phy3>; - phy-mode = "rgmii-id"; - reg = <1>; - /* Implicit "sja1105,role-mac;" */ - }; - port@2 { - /* ETH3 written on chassis */ - label = "swp3"; - phy-handle = <&rgmii_phy4>; - phy-mode = "rgmii-id"; - reg = <2>; - /* Implicit "sja1105,role-mac;" */ - }; - port@3 { - /* ETH4 written on chassis */ - phy-handle = <&rgmii_phy5>; - label = "swp4"; - phy-mode = "rgmii-id"; - reg = <3>; - /* Implicit "sja1105,role-mac;" */ - }; - port@4 { - /* Internal port connected to eth2 */ - ethernet = <&enet2>; - phy-mode = "rgmii"; - reg = <4>; - /* Implicit "sja1105,role-phy;" */ - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - }; -}; - -/* MDIO controller of the LS1021 */ -&mdio0 { - /* BCM5464 */ - rgmii_phy3: ethernet-phy@3 { - reg = <0x3>; - }; - rgmii_phy4: ethernet-phy@4 { - reg = <0x4>; - }; - rgmii_phy5: ethernet-phy@5 { - reg = <0x5>; - }; - rgmii_phy6: ethernet-phy@6 { - reg = <0x6>; - }; -}; - -/* Ethernet master port of the LS1021 */ -&enet2 { - phy-connection-type = "rgmii"; - status = "ok"; - fixed-link { - speed = <1000>; - full-duplex; - }; -}; diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index e8f04687a3e0..b0933a8c295a 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -68,6 +68,7 @@ properties: - tbi - rev-mii - rmii + - rev-rmii # RX and TX delays are added by the MAC when required - rgmii @@ -97,6 +98,7 @@ properties: - 10gbase-kr - usxgmii - 10gbase-r + - 25gbase-r phy-mode: $ref: "#/properties/phy-connection-type" diff --git a/Documentation/devicetree/bindings/net/ingenic,mac.yaml b/Documentation/devicetree/bindings/net/ingenic,mac.yaml new file mode 100644 index 000000000000..d08a88125a5c --- /dev/null +++ b/Documentation/devicetree/bindings/net/ingenic,mac.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/ingenic,mac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for MAC in Ingenic SoCs + +maintainers: + - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> + +description: + The Ethernet Media Access Controller in Ingenic SoCs. + +properties: + compatible: + enum: + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-names: + const: macirq + + clocks: + maxItems: 1 + + clock-names: + const: stmmaceth + + mode-reg: + description: An extra syscon register that control ethernet interface and timing delay + + rx-clk-delay-ps: + description: RGMII receive clock delay defined in pico seconds + + tx-clk-delay-ps: + description: RGMII transmit clock delay defined in pico seconds + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - mode-reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/x1000-cgu.h> + + mac: ethernet@134b0000 { + compatible = "ingenic,x1000-mac"; + reg = <0x134b0000 0x2000>; + + interrupt-parent = <&intc>; + interrupts = <55>; + interrupt-names = "macirq"; + + clocks = <&cgu X1000_CLK_MAC>; + clock-names = "stmmaceth"; + + mode-reg = <&mac_phy_ctrl>; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.txt b/Documentation/devicetree/bindings/net/mdio-gpio.txt deleted file mode 100644 index 4d91a36c5cf5..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-gpio.txt +++ /dev/null @@ -1,27 +0,0 @@ -MDIO on GPIOs - -Currently defined compatibles: -- virtual,gpio-mdio -- microchip,mdio-smi0 - -MDC and MDIO lines connected to GPIO controllers are listed in the -gpios property as described in section VIII.1 in the following order: - -MDC, MDIO. - -Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases" -node. - -Example: - -aliases { - mdio-gpio0 = &mdio0; -}; - -mdio0: mdio { - compatible = "virtual,mdio-gpio"; - #address-cells = <1>; - #size-cells = <0>; - gpios = <&qe_pio_a 11 - &qe_pio_c 6>; -}; diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.yaml b/Documentation/devicetree/bindings/net/mdio-gpio.yaml new file mode 100644 index 000000000000..1d83b8dcce2c --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-gpio.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MDIO on GPIOs + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Heiner Kallweit <hkallweit1@gmail.com> + - Russell King <linux@armlinux.org.uk> + +allOf: + - $ref: "mdio.yaml#" + +properties: + compatible: + enum: + - virtual,mdio-gpio + - microchip,mdio-smi0 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + gpios: + minItems: 2 + items: + - description: MDC + - description: MDIO + - description: MDO + +#Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases" +#node. +additionalProperties: + type: object + +examples: + - | + aliases { + mdio-gpio0 = &mdio0; + }; + + mdio0: mdio { + compatible = "virtual,mdio-gpio"; + #address-cells = <1>; + #size-cells = <0>; + gpios = <&qe_pio_a 11>, + <&qe_pio_c 6>; + ethphy0: ethernet-phy@0 { + reg = <0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt b/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt deleted file mode 100644 index 694987d3c17a..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt +++ /dev/null @@ -1,119 +0,0 @@ -Properties for an MDIO bus multiplexer/switch controlled by GPIO pins. - -This is a special case of a MDIO bus multiplexer. One or more GPIO -lines are used to control which child bus is connected. - -Required properties in addition to the generic multiplexer properties: - -- compatible : mdio-mux-gpio. -- gpios : GPIO specifiers for each GPIO line. One or more must be specified. - - -Example : - - /* The parent MDIO bus. */ - smi1: mdio@1180000001900 { - compatible = "cavium,octeon-3860-mdio"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x11800 0x00001900 0x0 0x40>; - }; - - /* - An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a - pair of GPIO lines. Child busses 2 and 3 populated with 4 - PHYs each. - */ - mdio-mux { - compatible = "mdio-mux-gpio"; - gpios = <&gpio1 3 0>, <&gpio1 4 0>; - mdio-parent-bus = <&smi1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@2 { - reg = <2>; - #address-cells = <1>; - #size-cells = <0>; - - phy11: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy12: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy13: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy14: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - }; - - mdio@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - phy21: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy22: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy23: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy24: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml b/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml new file mode 100644 index 000000000000..71c25c4580ea --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Properties for an MDIO bus multiplexer/switch controlled by GPIO pins. + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + +description: + This is a special case of a MDIO bus multiplexer. One or more GPIO + lines are used to control which child bus is connected. + +allOf: + - $ref: /schemas/net/mdio-mux.yaml# + +properties: + compatible: + const: mdio-mux-gpio + + gpios: + description: + List of GPIOs used to control the multiplexer, least significant bit first. + minItems: 1 + maxItems: 32 + +required: + - compatible + - gpios + +unevaluatedProperties: false + +examples: + - | + /* + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a + pair of GPIO lines. Child busses 2 and 3 populated with 4 + PHYs each. + */ + mdio-mux { + compatible = "mdio-mux-gpio"; + gpios = <&gpio1 3 0>, <&gpio1 4 0>; + mdio-parent-bus = <&smi1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@2 { + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@1 { + reg = <1>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + ethernet-phy@2 { + reg = <2>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + ethernet-phy@3 { + reg = <3>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + ethernet-phy@4 { + reg = <4>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + }; + + mdio@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@1 { + reg = <1>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + ethernet-phy@2 { + reg = <2>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + ethernet-phy@3 { + reg = <3>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + ethernet-phy@4 { + reg = <4>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt deleted file mode 100644 index 065e8bdb957d..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt +++ /dev/null @@ -1,75 +0,0 @@ -Properties for an MDIO bus multiplexer controlled by a memory-mapped device - -This is a special case of a MDIO bus multiplexer. A memory-mapped device, -like an FPGA, is used to control which child bus is connected. The mdio-mux -node must be a child of the memory-mapped device. The driver currently only -supports devices with 8, 16 or 32-bit registers. - -Required properties in addition to the generic multiplexer properties: - -- compatible : string, must contain "mdio-mux-mmioreg" - -- reg : integer, contains the offset of the register that controls the bus - multiplexer. The size field in the 'reg' property is the size of - register, and must therefore be 1, 2, or 4. - -- mux-mask : integer, contains an eight-bit mask that specifies which - bits in the register control the actual bus multiplexer. The - 'reg' property of each child mdio-mux node must be constrained by - this mask. - -Example: - -The FPGA node defines a memory-mapped FPGA with a register space of 0x30 bytes. -For the "EMI2" MDIO bus, register 9 (BRDCFG1) controls the mux on that bus. -A bitmask of 0x6 means that bits 1 and 2 (bit 0 is lsb) are the bits on -BRDCFG1 that control the actual mux. - - /* The FPGA node */ - fpga: board-control@3,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,p5020ds-fpga", "fsl,fpga-ngpixis"; - reg = <3 0 0x30>; - ranges = <0 3 0 0x30>; - - mdio-mux-emi2 { - compatible = "mdio-mux-mmioreg", "mdio-mux"; - mdio-parent-bus = <&xmdio0>; - #address-cells = <1>; - #size-cells = <0>; - reg = <9 1>; // BRDCFG1 - mux-mask = <0x6>; // EMI2 - - emi2_slot1: mdio@0 { // Slot 1 XAUI (FM2) - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - phy_xgmii_slot1: ethernet-phy@0 { - compatible = "ethernet-phy-ieee802.3-c45"; - reg = <4>; - }; - }; - - emi2_slot2: mdio@2 { // Slot 2 XAUI (FM1) - reg = <2>; - #address-cells = <1>; - #size-cells = <0>; - - phy_xgmii_slot2: ethernet-phy@4 { - compatible = "ethernet-phy-ieee802.3-c45"; - reg = <0>; - }; - }; - }; - }; - - /* The parent MDIO bus. */ - xmdio0: mdio@f1000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,fman-xmdio"; - reg = <0xf1000 0x1000>; - interrupts = <100 1 0 0>; - }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.yaml b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.yaml new file mode 100644 index 000000000000..cf86bb0b0b62 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux-mmioreg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Properties for an MDIO bus multiplexer controlled by a memory-mapped device + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + +description: |+ + This is a special case of a MDIO bus multiplexer. A memory-mapped device, + like an FPGA, is used to control which child bus is connected. The mdio-mux + node must be a child of the memory-mapped device. The driver currently only + supports devices with 8, 16 or 32-bit registers. + +allOf: + - $ref: /schemas/net/mdio-mux.yaml# + +properties: + compatible: + items: + - const: mdio-mux-mmioreg + - const: mdio-mux + + reg: + description: Contains the offset of the register that controls the bus + multiplexer. The size field in the 'reg' property is the size of register, + and must therefore be 1, 2, or 4. + maxItems: 1 + + mux-mask: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Contains an eight-bit mask that specifies which bits in the + register control the actual bus multiplexer. The 'reg' property of each + child mdio-mux node must be constrained by this mask. + +required: + - compatible + - reg + - mux-mask + +unevaluatedProperties: false + +examples: + - | + mdio-mux@9 { + compatible = "mdio-mux-mmioreg", "mdio-mux"; + mdio-parent-bus = <&xmdio0>; + #address-cells = <1>; + #size-cells = <0>; + reg = <9 1>; // BRDCFG1 + mux-mask = <0x6>; // EMI2 + + mdio@0 { // Slot 1 XAUI (FM2) + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + phy_xgmii_slot1: ethernet-phy@4 { + compatible = "ethernet-phy-ieee802.3-c45"; + reg = <4>; + }; + }; + + mdio@2 { // Slot 2 XAUI (FM1) + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@4 { + compatible = "ethernet-phy-ieee802.3-c45"; + reg = <4>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt deleted file mode 100644 index 534e38058fe0..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt +++ /dev/null @@ -1,82 +0,0 @@ -Properties for an MDIO bus multiplexer consumer device - -This is a special case of MDIO mux when MDIO mux is defined as a consumer -of a mux producer device. The mux producer can be of any type like mmio mux -producer, gpio mux producer or generic register based mux producer. - -Required properties in addition to the MDIO Bus multiplexer properties: - -- compatible : should be "mmio-mux-multiplexer" -- mux-controls : mux controller node to use for operating the mux -- mdio-parent-bus : phandle to the parent MDIO bus. - -each child node of mdio bus multiplexer consumer device represent a mdio -bus. - -for more information please refer -Documentation/devicetree/bindings/mux/mux-controller.txt -and Documentation/devicetree/bindings/net/mdio-mux.txt - -Example: -In below example the Mux producer and consumer are separate nodes. - -&i2c0 { - fpga@66 { // fpga connected to i2c - compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c", - "simple-mfd"; - reg = <0x66>; - - mux: mux-controller { // Mux Producer - compatible = "reg-mux"; - #mux-control-cells = <1>; - mux-reg-masks = <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ - <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ - }; - }; -}; - -mdio-mux-1 { // Mux consumer - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 0>; - mdio-parent-bus = <&emdio1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@8 { - reg = <0x8>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; - -mdio-mux-2 { // Mux consumer - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 1>; - mdio-parent-bus = <&emdio2>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@1 { - reg = <0x1>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; diff --git a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml new file mode 100644 index 000000000000..282987074ee4 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux-multiplexer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Properties for an MDIO bus multiplexer consumer device + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + +description: |+ + This is a special case of MDIO mux when MDIO mux is defined as a consumer + of a mux producer device. The mux producer can be of any type like mmio mux + producer, gpio mux producer or generic register based mux producer. + + +allOf: + - $ref: /schemas/net/mdio-mux.yaml# + +properties: + compatible: + const: mdio-mux-multiplexer + + mux-controls: + maxItems: 1 + +required: + - compatible + - mux-controls + +unevaluatedProperties: false + +examples: + - | + mux: mux-controller { // Mux Producer + compatible = "reg-mux"; + #mux-control-cells = <1>; + mux-reg-masks = <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ + <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ + }; + + mdio-mux-1 { // Mux consumer + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux 0>; + mdio-parent-bus = <&emdio1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@8 { + reg = <0x8>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + mdio-mux-2 { // Mux consumer + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux 1>; + mdio-parent-bus = <&emdio2>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@1 { + reg = <0x1>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt deleted file mode 100644 index f58571f36570..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux.txt +++ /dev/null @@ -1,129 +0,0 @@ -Common MDIO bus multiplexer/switch properties. - -An MDIO bus multiplexer/switch will have several child busses that are -numbered uniquely in a device dependent manner. The nodes for an MDIO -bus multiplexer/switch will have one child node for each child bus. - -Required properties: -- #address-cells = <1>; -- #size-cells = <0>; - -Optional properties: -- mdio-parent-bus : phandle to the parent MDIO bus. - -- Other properties specific to the multiplexer/switch hardware. - -Required properties for child nodes: -- #address-cells = <1>; -- #size-cells = <0>; -- reg : The sub-bus number. - - -Example : - - /* The parent MDIO bus. */ - smi1: mdio@1180000001900 { - compatible = "cavium,octeon-3860-mdio"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x11800 0x00001900 0x0 0x40>; - }; - - /* - An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a - pair of GPIO lines. Child busses 2 and 3 populated with 4 - PHYs each. - */ - mdio-mux { - compatible = "mdio-mux-gpio"; - gpios = <&gpio1 3 0>, <&gpio1 4 0>; - mdio-parent-bus = <&smi1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@2 { - reg = <2>; - #address-cells = <1>; - #size-cells = <0>; - - phy11: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy12: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy13: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy14: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - }; - - mdio@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - phy21: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy22: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy23: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy24: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux.yaml b/Documentation/devicetree/bindings/net/mdio-mux.yaml new file mode 100644 index 000000000000..d169adf5d9f4 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common MDIO bus multiplexer/switch properties. + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + +description: |+ + An MDIO bus multiplexer/switch will have several child busses that are + numbered uniquely in a device dependent manner. The nodes for an MDIO + bus multiplexer/switch will have one child node for each child bus. + +properties: + $nodename: + pattern: '^mdio-mux[\-@]?' + + mdio-parent-bus: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the MDIO bus that this multiplexer's master-side port is + connected to. + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + '^mdio@[0-9a-f]+$': + type: object + + properties: + reg: + maxItems: 1 + description: The sub-bus number. + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml new file mode 100644 index 000000000000..347b912a46bb --- /dev/null +++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml @@ -0,0 +1,226 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/microchip,sparx5-switch.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Sparx5 Ethernet switch controller + +maintainers: + - Steen Hegelund <steen.hegelund@microchip.com> + - Lars Povlsen <lars.povlsen@microchip.com> + +description: | + The SparX-5 Enterprise Ethernet switch family provides a rich set of + Enterprise switching features such as advanced TCAM-based VLAN and + QoS processing enabling delivery of differentiated services, and + security through TCAM-based frame processing using versatile content + aware processor (VCAP). + + IPv4/IPv6 Layer 3 (L3) unicast and multicast routing is supported + with up to 18K IPv4/9K IPv6 unicast LPM entries and up to 9K IPv4/3K + IPv6 (S,G) multicast groups. + + L3 security features include source guard and reverse path + forwarding (uRPF) tasks. Additional L3 features include VRF-Lite and + IP tunnels (IP over GRE/IP). + + The SparX-5 switch family targets managed Layer 2 and Layer 3 + equipment in SMB, SME, and Enterprise where high port count + 1G/2.5G/5G/10G switching with 10G/25G aggregation links is required. + +properties: + $nodename: + pattern: "^switch@[0-9a-f]+$" + + compatible: + const: microchip,sparx5-switch + + reg: + items: + - description: cpu target + - description: devices target + - description: general control block target + + reg-names: + items: + - const: cpu + - const: devices + - const: gcb + + interrupts: + minItems: 1 + items: + - description: register based extraction + - description: frame dma based extraction + + interrupt-names: + minItems: 1 + items: + - const: xtr + - const: fdma + + resets: + items: + - description: Reset controller used for switch core reset (soft reset) + + reset-names: + items: + - const: switch + + mac-address: true + + ethernet-ports: + type: object + patternProperties: + "^port@[0-9a-f]+$": + type: object + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + reg: + description: Switch port number + + phys: + maxItems: 1 + description: + phandle of a Ethernet SerDes PHY. This defines which SerDes + instance will handle the Ethernet traffic. + + phy-mode: + description: + This specifies the interface used by the Ethernet SerDes towards + the PHY or SFP. + + microchip,bandwidth: + description: Specifies bandwidth in Mbit/s allocated to the port. + $ref: "/schemas/types.yaml#/definitions/uint32" + maximum: 25000 + + phy-handle: + description: + phandle of a Ethernet PHY. This is optional and if provided it + points to the cuPHY used by the Ethernet SerDes. + + sfp: + description: + phandle of an SFP. This is optional and used when not specifying + a cuPHY. It points to the SFP node that describes the SFP used by + the Ethernet SerDes. + + managed: true + + microchip,sd-sgpio: + description: + Index of the ports Signal Detect SGPIO in the set of 384 SGPIOs + This is optional, and only needed if the default used index is + is not correct. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 383 + + required: + - reg + - phys + - phy-mode + - microchip,bandwidth + + oneOf: + - required: + - phy-handle + - required: + - sfp + - managed + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - resets + - reset-names + - ethernet-ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + switch: switch@600000000 { + compatible = "microchip,sparx5-switch"; + reg = <0 0x401000>, + <0x10004000 0x7fc000>, + <0x11010000 0xaf0000>; + reg-names = "cpu", "devices", "gcb"; + interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "xtr"; + resets = <&reset 0>; + reset-names = "switch"; + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port0: port@0 { + reg = <0>; + microchip,bandwidth = <1000>; + phys = <&serdes 13>; + phy-handle = <&phy0>; + phy-mode = "qsgmii"; + }; + /* ... */ + /* Then the 25G interfaces */ + port60: port@60 { + reg = <60>; + microchip,bandwidth = <25000>; + phys = <&serdes 29>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth60>; + managed = "in-band-status"; + microchip,sd-sgpio = <365>; + }; + port61: port@61 { + reg = <61>; + microchip,bandwidth = <25000>; + phys = <&serdes 30>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth61>; + managed = "in-band-status"; + microchip,sd-sgpio = <369>; + }; + port62: port@62 { + reg = <62>; + microchip,bandwidth = <25000>; + phys = <&serdes 31>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth62>; + managed = "in-band-status"; + microchip,sd-sgpio = <373>; + }; + port63: port@63 { + reg = <63>; + microchip,bandwidth = <25000>; + phys = <&serdes 32>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth63>; + managed = "in-band-status"; + microchip,sd-sgpio = <377>; + }; + /* Finally the Management interface */ + port64: port@64 { + reg = <64>; + microchip,bandwidth = <1000>; + phys = <&serdes 0>; + phy-handle = <&phy64>; + phy-mode = "sgmii"; + mac-address = [ 00 00 00 01 02 03 ]; + }; + }; + }; + +... +# vim: set ts=2 sw=2 sts=2 tw=80 et cc=80 ft=yaml : diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml index 477066e2b821..081742c2b726 100644 --- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml +++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml @@ -27,6 +27,9 @@ properties: reg: maxItems: 1 + clocks: + maxItems: 1 + wake-gpios: maxItems: 1 description: @@ -80,6 +83,8 @@ examples: en-gpios = <&gpf1 4 GPIO_ACTIVE_HIGH>; wake-gpios = <&gpj0 2 GPIO_ACTIVE_HIGH>; + + clocks = <&rpmcc 20>; }; }; # UART example on Raspberry Pi diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 7443490d4cc6..ed88ba4b94df 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -44,6 +44,7 @@ description: properties: compatible: enum: + - qcom,msm8998-ipa - qcom,sc7180-ipa - qcom,sc7280-ipa - qcom,sdm845-ipa @@ -105,7 +106,6 @@ properties: - description: Whether the IPA clock is enabled (if valid) qcom,smem-state-names: - $ref: /schemas/types.yaml#/definitions/string-array description: The names of the state bits used for SMP2P output items: - const: ipa-clock-enabled-valid diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt deleted file mode 100644 index 709ca6d51650..000000000000 --- a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt +++ /dev/null @@ -1,69 +0,0 @@ -Qualcomm Bluetooth Chips ---------------------- - -This documents the binding structure and common properties for serial -attached Qualcomm devices. - -Serial attached Qualcomm devices shall be a child node of the host UART -device the slave device is attached to. - -Required properties: - - compatible: should contain one of the following: - * "qcom,qca6174-bt" - * "qcom,qca9377-bt" - * "qcom,wcn3990-bt" - * "qcom,wcn3991-bt" - * "qcom,wcn3998-bt" - * "qcom,qca6390-bt" - -Optional properties for compatible string qcom,qca6174-bt: - - - enable-gpios: gpio specifier used to enable chip - - clocks: clock provided to the controller (SUSCLK_32KHZ) - - firmware-name: specify the name of nvm firmware to load - -Optional properties for compatible string qcom,qca9377-bt: - - - max-speed: see Documentation/devicetree/bindings/serial/serial.yaml - -Required properties for compatible string qcom,wcn399x-bt: - - - vddio-supply: VDD_IO supply regulator handle. - - vddxo-supply: VDD_XO supply regulator handle. - - vddrf-supply: VDD_RF supply regulator handle. - - vddch0-supply: VDD_CH0 supply regulator handle. - -Optional properties for compatible string qcom,wcn399x-bt: - - - max-speed: see Documentation/devicetree/bindings/serial/serial.yaml - - firmware-name: specify the name of nvm firmware to load - - clocks: clock provided to the controller - -Examples: - -serial@7570000 { - label = "BT-UART"; - status = "okay"; - - bluetooth { - compatible = "qcom,qca6174-bt"; - - enable-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>; - clocks = <&divclk4>; - firmware-name = "nvm_00440302.bin"; - }; -}; - -serial@898000 { - bluetooth { - compatible = "qcom,wcn3990-bt"; - - vddio-supply = <&vreg_s4a_1p8>; - vddxo-supply = <&vreg_l7a_1p8>; - vddrf-supply = <&vreg_l17a_1p3>; - vddch0-supply = <&vreg_l25a_3p3>; - max-speed = <3200000>; - firmware-name = "crnv21.bin"; - clocks = <&rpmhcc RPMH_RF_CLK2>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml new file mode 100644 index 000000000000..f93c6e7a1b59 --- /dev/null +++ b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml @@ -0,0 +1,183 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/qualcomm-bluetooth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Bluetooth Chips + +maintainers: + - Balakrishna Godavarthi <bgodavar@codeaurora.org> + - Rocky Liao <rjliao@codeaurora.org> + +description: + This binding describes Qualcomm UART-attached bluetooth chips. + +properties: + compatible: + enum: + - qcom,qca6174-bt + - qcom,qca9377-bt + - qcom,wcn3990-bt + - qcom,wcn3991-bt + - qcom,wcn3998-bt + - qcom,qca6390-bt + - qcom,wcn6750-bt + + enable-gpios: + maxItems: 1 + description: gpio specifier used to enable chip + + swctrl-gpios: + maxItems: 1 + description: gpio specifier is used to find status + of clock supply to SoC + + clocks: + maxItems: 1 + description: clock provided to the controller (SUSCLK_32KHZ) + + vddio-supply: + description: VDD_IO supply regulator handle + + vddxo-supply: + description: VDD_XO supply regulator handle + + vddrf-supply: + description: VDD_RF supply regulator handle + + vddch0-supply: + description: VDD_CH0 supply regulator handle + + vddaon-supply: + description: VDD_AON supply regulator handle + + vddbtcxmx-supply: + description: VDD_BT_CXMX supply regulator handle + + vddrfacmn-supply: + description: VDD_RFA_CMN supply regulator handle + + vddrfa0p8-supply: + description: VDD_RFA_0P8 suppply regulator handle + + vddrfa1p7-supply: + description: VDD_RFA_1P7 supply regulator handle + + vddrfa1p2-supply: + description: VDD_RFA_1P2 supply regulator handle + + vddrfa2p2-supply: + description: VDD_RFA_2P2 supply regulator handle + + vddasd-supply: + description: VDD_ASD supply regulator handle + + max-speed: + description: see Documentation/devicetree/bindings/serial/serial.yaml + + firmware-name: + description: specify the name of nvm firmware to load + + local-bd-address: + description: see Documentation/devicetree/bindings/net/bluetooth.txt + + +required: + - compatible + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,qca6174-bt + then: + required: + - enable-gpios + - clocks + + - if: + properties: + compatible: + contains: + enum: + - qcom,wcn3990-bt + - qcom,wcn3991-bt + - qcom,wcn3998-bt + then: + required: + - vddio-supply + - vddxo-supply + - vddrf-supply + - vddch0-supply + + - if: + properties: + compatible: + contains: + enum: + - qcom,wcn6750-bt + then: + required: + - enable-gpios + - swctrl-gpios + - vddio-supply + - vddaon-supply + - vddbtcxmx-supply + - vddrfacmn-supply + - vddrfa0p8-supply + - vddrfa1p7-supply + - vddrfa1p2-supply + - vddasd-supply + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + serial { + + bluetooth { + compatible = "qcom,qca6174-bt"; + enable-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>; + clocks = <&divclk4>; + firmware-name = "nvm_00440302.bin"; + }; + }; + - | + serial { + + bluetooth { + compatible = "qcom,wcn3990-bt"; + vddio-supply = <&vreg_s4a_1p8>; + vddxo-supply = <&vreg_l7a_1p8>; + vddrf-supply = <&vreg_l17a_1p3>; + vddch0-supply = <&vreg_l25a_3p3>; + max-speed = <3200000>; + firmware-name = "crnv21.bin"; + }; + }; + - | + serial { + + bluetooth { + compatible = "qcom,wcn6750-bt"; + pinctrl-names = "default"; + pinctrl-0 = <&bt_en_default>; + enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>; + swctrl-gpios = <&tlmm 86 GPIO_ACTIVE_HIGH>; + vddio-supply = <&vreg_l19b_1p8>; + vddaon-supply = <&vreg_s7b_0p9>; + vddbtcxmx-supply = <&vreg_s7b_0p9>; + vddrfacmn-supply = <&vreg_s7b_0p9>; + vddrfa0p8-supply = <&vreg_s7b_0p9>; + vddrfa1p7-supply = <&vreg_s1b_1p8>; + vddrfa1p2-supply = <&vreg_s8b_1p2>; + vddrfa2p2-supply = <&vreg_s1c_2p2>; + vddasd-supply = <&vreg_l11c_2p8>; + max-speed = <3200000>; + firmware-name = "msnv11.bin"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml new file mode 100644 index 000000000000..bb94a2388520 --- /dev/null +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0+ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/realtek,rtl82xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek RTL82xx PHY + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Florian Fainelli <f.fainelli@gmail.com> + - Heiner Kallweit <hkallweit1@gmail.com> + +description: + Bindings for Realtek RTL82xx PHYs + +allOf: + - $ref: ethernet-phy.yaml# + +properties: + realtek,clkout-disable: + type: boolean + description: + Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset. + + + realtek,aldps-enable: + type: boolean + description: + Enable ALDPS mode, ALDPS mode default is disabled after hardware reset. + +unevaluatedProperties: false + +examples: + - | + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethphy1: ethernet-phy@1 { + reg = <1>; + realtek,clkout-disable; + realtek,aldps-enable; + }; + }; diff --git a/Documentation/devicetree/bindings/net/renesas,ether.yaml b/Documentation/devicetree/bindings/net/renesas,ether.yaml index 8ce5ed8a58dd..c101a1ec846e 100644 --- a/Documentation/devicetree/bindings/net/renesas,ether.yaml +++ b/Documentation/devicetree/bindings/net/renesas,ether.yaml @@ -10,7 +10,7 @@ allOf: - $ref: ethernet-controller.yaml# maintainers: - - Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> + - Sergei Shtylyov <sergei.shtylyov@gmail.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml index 5acddb6171bf..083623c8d718 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml @@ -19,10 +19,12 @@ select: - rockchip,rk3128-gmac - rockchip,rk3228-gmac - rockchip,rk3288-gmac + - rockchip,rk3308-gmac - rockchip,rk3328-gmac - rockchip,rk3366-gmac - rockchip,rk3368-gmac - rockchip,rk3399-gmac + - rockchip,rk3568-gmac - rockchip,rv1108-gmac required: - compatible @@ -32,17 +34,23 @@ allOf: properties: compatible: - items: - - enum: - - rockchip,px30-gmac - - rockchip,rk3128-gmac - - rockchip,rk3228-gmac - - rockchip,rk3288-gmac - - rockchip,rk3328-gmac - - rockchip,rk3366-gmac - - rockchip,rk3368-gmac - - rockchip,rk3399-gmac - - rockchip,rv1108-gmac + oneOf: + - items: + - enum: + - rockchip,px30-gmac + - rockchip,rk3128-gmac + - rockchip,rk3228-gmac + - rockchip,rk3288-gmac + - rockchip,rk3308-gmac + - rockchip,rk3328-gmac + - rockchip,rk3366-gmac + - rockchip,rk3368-gmac + - rockchip,rk3399-gmac + - rockchip,rv1108-gmac + - items: + - enum: + - rockchip,rk3568-gmac + - const: snps,dwmac-4.20a clocks: minItems: 5 diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 2edd8bea993e..d7652596a09b 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -51,11 +51,20 @@ properties: - allwinner,sun8i-r40-emac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac - amlogic,meson6-dwmac - amlogic,meson8b-dwmac - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac - rockchip,px30-gmac - rockchip,rk3128-gmac - rockchip,rk3228-gmac @@ -82,7 +91,6 @@ properties: interrupts: minItems: 1 - maxItems: 3 items: - description: Combined signal for various interrupt events - description: The interrupt to manage the remote wake-up packet detection @@ -90,7 +98,6 @@ properties: interrupt-names: minItems: 1 - maxItems: 3 items: - const: macirq - const: eth_wake_irq @@ -310,6 +317,11 @@ allOf: - allwinner,sun8i-r40-emac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac @@ -353,6 +365,13 @@ allOf: - allwinner,sun8i-r40-emac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index 27eb6066793f..19c7bd482a51 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -46,7 +46,6 @@ properties: clocks: minItems: 3 - maxItems: 5 items: - description: GMAC main clock - description: MAC TX clock diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt index d479ad977e24..b6791702bcfc 100644 --- a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt +++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt @@ -9,7 +9,6 @@ Required properties: "mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173 "mediatek,mt8192-efuse", "mediatek,efuse": for MT8192 "mediatek,mt8516-efuse", "mediatek,efuse": for MT8516 - "mediatek,mt8192-efuse", "mediatek,efuse": for MT8192 - reg: Should contain registers location and length = Data cells = diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml index f90557f6deb8..b9589a0daa5c 100644 --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml @@ -25,14 +25,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: PCIe host controller - description: builtin MSI controller interrupt-names: minItems: 1 - maxItems: 2 items: - const: pcie - const: msi diff --git a/Documentation/devicetree/bindings/pci/loongson.yaml b/Documentation/devicetree/bindings/pci/loongson.yaml index 81bae060cbde..82bc6c486ca3 100644 --- a/Documentation/devicetree/bindings/pci/loongson.yaml +++ b/Documentation/devicetree/bindings/pci/loongson.yaml @@ -24,7 +24,6 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: CFG0 standard config space register - description: CFG1 extended config space register diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml index e7b1f9892da4..742206dbd965 100644 --- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml @@ -70,7 +70,6 @@ properties: reset-names: minItems: 1 - maxItems: 2 items: - const: phy - const: mac diff --git a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml index 04251d71f56b..fb95c276a986 100644 --- a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml @@ -26,14 +26,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: PCIe host controller - description: builtin MSI controller interrupt-names: minItems: 1 - maxItems: 2 items: - const: pcie - const: msi diff --git a/Documentation/devicetree/bindings/pci/pci-keystone.txt b/Documentation/devicetree/bindings/pci/pci-keystone.txt deleted file mode 100644 index 47202a2938f2..000000000000 --- a/Documentation/devicetree/bindings/pci/pci-keystone.txt +++ /dev/null @@ -1,115 +0,0 @@ -TI Keystone PCIe interface - -Keystone PCI host Controller is based on the Synopsys DesignWare PCI -hardware version 3.65. It shares common functions with the PCIe DesignWare -core driver and inherits common properties defined in -Documentation/devicetree/bindings/pci/designware-pcie.txt - -Please refer to Documentation/devicetree/bindings/pci/designware-pcie.txt -for the details of DesignWare DT bindings. Additional properties are -described here as well as properties that are not applicable. - -Required Properties:- - -compatibility: Should be "ti,keystone-pcie" for RC on Keystone2 SoC - Should be "ti,am654-pcie-rc" for RC on AM654x SoC -reg: Three register ranges as listed in the reg-names property -reg-names: "dbics" for the DesignWare PCIe registers, "app" for the - TI specific application registers, "config" for the - configuration space address - -pcie_msi_intc : Interrupt controller device node for MSI IRQ chip - interrupt-cells: should be set to 1 - interrupts: GIC interrupt lines connected to PCI MSI interrupt lines - (required if the compatible is "ti,keystone-pcie") -msi-map: As specified in Documentation/devicetree/bindings/pci/pci-msi.txt - (required if the compatible is "ti,am654-pcie-rc". - -ti,syscon-pcie-id : phandle to the device control module required to set device - id and vendor id. -ti,syscon-pcie-mode : phandle to the device control module required to configure - PCI in either RC mode or EP mode. - - Example: - pcie_msi_intc: msi-interrupt-controller { - interrupt-controller; - #interrupt-cells = <1>; - interrupt-parent = <&gic>; - interrupts = <GIC_SPI 30 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 31 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 33 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 34 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 37 IRQ_TYPE_EDGE_RISING>; - }; - -pcie_intc: Interrupt controller device node for Legacy IRQ chip - interrupt-cells: should be set to 1 - - Example: - pcie_intc: legacy-interrupt-controller { - interrupt-controller; - #interrupt-cells = <1>; - interrupt-parent = <&gic>; - interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 27 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 28 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 29 IRQ_TYPE_EDGE_RISING>; - }; - -Optional properties:- - phys: phandle to generic Keystone SerDes PHY for PCI - phy-names: name of the generic Keystone SerDes PHY for PCI - - If boot loader already does PCI link establishment, then phys and - phy-names shouldn't be present. - interrupts: platform interrupt for error interrupts. - -DesignWare DT Properties not applicable for Keystone PCI - -1. pcie_bus clock-names not used. Instead, a phandle to phys is used. - -AM654 PCIe Endpoint -=================== - -Required Properties:- - -compatibility: Should be "ti,am654-pcie-ep" for EP on AM654x SoC -reg: Four register ranges as listed in the reg-names property -reg-names: "dbics" for the DesignWare PCIe registers, "app" for the - TI specific application registers, "atu" for the - Address Translation Unit configuration registers and - "addr_space" used to map remote RC address space -num-ib-windows: As specified in - Documentation/devicetree/bindings/pci/designware-pcie.txt -num-ob-windows: As specified in - Documentation/devicetree/bindings/pci/designware-pcie.txt -num-lanes: As specified in - Documentation/devicetree/bindings/pci/designware-pcie.txt -power-domains: As documented by the generic PM domain bindings in - Documentation/devicetree/bindings/power/power_domain.txt. -ti,syscon-pcie-mode: phandle to the device control module required to configure - PCI in either RC mode or EP mode. - -Optional properties:- - -phys: list of PHY specifiers (used by generic PHY framework) -phy-names: must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the - number of lanes as specified in *num-lanes* property. -("phys" and "phy-names" DT bindings are specified in -Documentation/devicetree/bindings/phy/phy-bindings.txt) -interrupts: platform interrupt for error interrupts. - -pcie-ep { - compatible = "ti,am654-pcie-ep"; - reg = <0x5500000 0x1000>, <0x5501000 0x1000>, - <0x10000000 0x8000000>, <0x5506000 0x1000>; - reg-names = "app", "dbics", "addr_space", "atu"; - power-domains = <&k3_pds 120>; - ti,syscon-pcie-mode = <&pcie0_mode>; - num-lanes = <1>; - num-ib-windows = <16>; - num-ob-windows = <16>; - interrupts = <GIC_SPI 340 IRQ_TYPE_EDGE_RISING>; -}; diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml new file mode 100644 index 000000000000..78c217d362a7 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/ti,am65-pci-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM65 PCI Endpoint + +maintainers: + - Kishon Vijay Abraham I <kishon@ti.com> + +allOf: + - $ref: pci-ep.yaml# + +properties: + compatible: + enum: + - ti,am654-pcie-ep + + reg: + maxItems: 4 + + reg-names: + items: + - const: app + - const: dbics + - const: addr_space + - const: atu + + power-domains: + maxItems: 1 + + ti,syscon-pcie-mode: + description: Phandle to the SYSCON entry required for configuring PCIe in RC or EP mode. + $ref: /schemas/types.yaml#/definitions/phandle + + interrupts: + minItems: 1 + + dma-coherent: true + +required: + - compatible + - reg + - reg-names + - max-link-speed + - power-domains + - ti,syscon-pcie-mode + - dma-coherent + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/soc/ti,sci_pm_domain.h> + + pcie0_ep: pcie-ep@5500000 { + compatible = "ti,am654-pcie-ep"; + reg = <0x5500000 0x1000>, + <0x5501000 0x1000>, + <0x10000000 0x8000000>, + <0x5506000 0x1000>; + reg-names = "app", "dbics", "addr_space", "atu"; + power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>; + ti,syscon-pcie-mode = <&pcie0_mode>; + num-ib-windows = <16>; + num-ob-windows = <16>; + max-link-speed = <2>; + dma-coherent; + interrupts = <GIC_SPI 340 IRQ_TYPE_EDGE_RISING>; + }; diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml new file mode 100644 index 000000000000..834dc1c1743c --- /dev/null +++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM65 PCI Host + +maintainers: + - Kishon Vijay Abraham I <kishon@ti.com> + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + enum: + - ti,am654-pcie-rc + - ti,keystone-pcie + + reg: + maxItems: 4 + + reg-names: + items: + - const: app + - const: dbics + - const: config + - const: atu + + power-domains: + maxItems: 1 + + ti,syscon-pcie-id: + description: Phandle to the SYSCON entry required for getting PCIe device/vendor ID + $ref: /schemas/types.yaml#/definitions/phandle + + ti,syscon-pcie-mode: + description: Phandle to the SYSCON entry required for configuring PCIe in RC or EP mode. + $ref: /schemas/types.yaml#/definitions/phandle + + msi-map: true + + dma-coherent: true + +required: + - compatible + - reg + - reg-names + - max-link-speed + - ti,syscon-pcie-id + - ti,syscon-pcie-mode + - ranges + +if: + properties: + compatible: + enum: + - ti,am654-pcie-rc +then: + required: + - dma-coherent + - power-domains + - msi-map + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/soc/ti,sci_pm_domain.h> + + pcie0_rc: pcie@5500000 { + compatible = "ti,am654-pcie-rc"; + reg = <0x5500000 0x1000>, + <0x5501000 0x1000>, + <0x10000000 0x2000>, + <0x5506000 0x1000>; + reg-names = "app", "dbics", "config", "atu"; + power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>; + #address-cells = <3>; + #size-cells = <2>; + ranges = <0x81000000 0 0 0x10020000 0 0x00010000>, + <0x82000000 0 0x10030000 0x10030000 0 0x07FD0000>; + ti,syscon-pcie-id = <&pcie_devid>; + ti,syscon-pcie-mode = <&pcie0_mode>; + bus-range = <0x0 0xff>; + num-viewport = <16>; + max-link-speed = <2>; + dma-coherent; + interrupts = <GIC_SPI 340 IRQ_TYPE_EDGE_RISING>; + msi-map = <0x0 &gic_its 0x0 0x10000>; + device_type = "pci"; + }; diff --git a/Documentation/devicetree/bindings/perf/arm,cmn.yaml b/Documentation/devicetree/bindings/perf/arm,cmn.yaml index e4fcc0de25e2..42424ccbdd0c 100644 --- a/Documentation/devicetree/bindings/perf/arm,cmn.yaml +++ b/Documentation/devicetree/bindings/perf/arm,cmn.yaml @@ -21,7 +21,6 @@ properties: interrupts: minItems: 1 - maxItems: 4 items: - description: Overflow interrupt for DTC0 - description: Overflow interrupt for DTC1 diff --git a/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml index 9a2e779e6d38..0f0bcde9eb88 100644 --- a/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml @@ -28,7 +28,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: usbh - const: usb_ref diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml index 5f9e91bfb5ff..43a4b880534c 100644 --- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml @@ -22,7 +22,6 @@ properties: reg: minItems: 1 - maxItems: 6 items: - description: the base CTRL register - description: XHCI EC register @@ -33,7 +32,6 @@ properties: reg-names: minItems: 1 - maxItems: 6 items: - const: ctrl - const: xhci_ec @@ -51,7 +49,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: sw_usb - const: sw_usb3 diff --git a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml index 04edda504ab6..cb1aa325336f 100644 --- a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml @@ -35,7 +35,6 @@ properties: reg-names: minItems: 1 - maxItems: 2 items: - const: phy - const: phy-ctrl diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index b8a7651a3d9a..ef9d9d4e6875 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -131,7 +131,6 @@ patternProperties: clocks: minItems: 1 - maxItems: 2 items: - description: Reference clock, (HS is 48Mhz, SS/P is 24~27Mhz) - description: Reference clock of analog phy @@ -141,7 +140,6 @@ patternProperties: clock-names: minItems: 1 - maxItems: 2 items: - const: ref - const: da_ref diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml index 84383e2e0b34..e71b32c9c0d1 100644 --- a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml +++ b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml @@ -31,14 +31,12 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: Sierra PHY reset. - description: Sierra APB reset. This is optional. reset-names: minItems: 1 - maxItems: 2 items: - const: sierra_reset - const: sierra_apb diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml index 01dcd14e7b2a..bd9ae11c9994 100644 --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml @@ -52,28 +52,24 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: Offset of the Torrent PHY configuration registers. - description: Offset of the DPTX PHY configuration registers. reg-names: minItems: 1 - maxItems: 2 items: - const: torrent_phy - const: dptx_phy resets: minItems: 1 - maxItems: 2 items: - description: Torrent PHY reset. - description: Torrent APB reset. This is optional. reset-names: minItems: 1 - maxItems: 2 items: - const: torrent_reset - const: torrent_apb @@ -118,7 +114,7 @@ patternProperties: description: Specifies the Spread Spectrum Clocking mode used. It can be NO_SSC, EXTERNAL_SSC or INTERNAL_SSC. - Refer include/dt-bindings/phy/phy-cadence-torrent.h for the constants to be used. + Refer include/dt-bindings/phy/phy-cadence.h for the constants to be used. $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1, 2] default: 0 diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml index 17f132ce5516..35296c588e78 100644 --- a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml @@ -30,7 +30,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: ref - const: xo diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml index 17fd7f6b83bb..6cf5c6c06072 100644 --- a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml @@ -30,7 +30,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: ref - const: xo diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index 7808ec8bc712..a2de5202eb5e 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -49,7 +49,6 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: Address and length of PHY's common serdes block. - description: Address and length of PHY's DP_COM control block. diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index 9f9cf07b7d45..930da598c969 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -36,7 +36,6 @@ properties: clocks: minItems: 2 - maxItems: 3 items: - description: phy config clock - description: 19.2 MHz ref clk @@ -44,7 +43,6 @@ properties: clock-names: minItems: 2 - maxItems: 3 items: - const: cfg_ahb - const: ref diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml index 0f358d5b84ef..d5dc5a3cdceb 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml @@ -39,7 +39,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: fck - const: usb_x1 @@ -61,7 +60,6 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: reset of USB 2.0 host side - description: reset of USB 2.0 peripheral side diff --git a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml index f3ef738a3ff6..b8483f9edbfc 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml @@ -33,7 +33,6 @@ properties: # If you want to use the ssc, the clock-frequency of usb_extal # must not be 0. minItems: 2 - maxItems: 3 items: - const: usb3-if # The funcional clock - const: usb3s_clk # The usb3's external clock diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml index ccdd9e3820d7..3f94f6944740 100644 --- a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml @@ -26,7 +26,6 @@ properties: - description: PAD Pull Control + PAD Schmitt Trigger Enable + PAD Control - description: PAD Drive Capacity Select minItems: 1 - maxItems: 4 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml new file mode 100644 index 000000000000..d50571affd1f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/apple,pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple GPIO controller + +maintainers: + - Mark Kettenis <kettenis@openbsd.org> + +description: | + The Apple GPIO controller is a simple combined pin and GPIO + controller present on Apple ARM SoC platforms, including various + iPhone and iPad devices and the "Apple Silicon" Macs. + +properties: + compatible: + items: + - const: apple,t8103-pinctrl + - const: apple,pinctrl + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + gpio-ranges: + maxItems: 1 + + interrupts: + description: One interrupt for each of the (up to 7) interrupt + groups supported by the controller sorted by interrupt group + number in ascending order. + minItems: 1 + maxItems: 7 + + interrupt-controller: true + +patternProperties: + '-pins$': + type: object + $ref: pinmux-node.yaml# + + properties: + pinmux: + description: + Values are constructed from pin number and alternate function + configuration number using the APPLE_PINMUX() helper macro + defined in include/dt-bindings/pinctrl/apple.h. + + required: + - pinmux + + additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/apple-aic.h> + #include <dt-bindings/pinctrl/apple.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pinctrl: pinctrl@23c100000 { + compatible = "apple,t8103-pinctrl", "apple,pinctrl"; + reg = <0x2 0x3c100000 0x0 0x100000>; + clocks = <&gpio_clk>; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl 0 0 212>; + + interrupt-controller; + interrupt-parent = <&aic>; + interrupts = <AIC_IRQ 16 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 17 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 18 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 19 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 20 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 21 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 22 IRQ_TYPE_LEVEL_HIGH>; + + pcie_pins: pcie-pins { + pinmux = <APPLE_PINMUX(150, 1)>, + <APPLE_PINMUX(151, 1)>, + <APPLE_PINMUX(32, 1)>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index ad91c0bc54da..ad2866c99738 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -46,8 +46,8 @@ patternProperties: 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, SGPS1, SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, - SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2, + 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, @@ -74,9 +74,9 @@ patternProperties: 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, SGPS1, SIOONCTRL, - SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, - SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, + 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, diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm4708-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm4708-pinmux.txt deleted file mode 100644 index 8ab2d468dbdb..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm4708-pinmux.txt +++ /dev/null @@ -1,55 +0,0 @@ -Broadcom Northstar pins mux controller - -Some of Northstar SoCs's pins can be used for various purposes thanks to the mux -controller. This binding allows describing mux controller and listing available -functions. They can be referenced later by other bindings to let system -configure controller correctly. - -A list of pins varies across chipsets so few bindings are available. - -Node of the pinmux must be nested in the CRU (Central Resource Unit) "syscon" -noce. - -Required properties: -- compatible: must be one of: - "brcm,bcm4708-pinmux" - "brcm,bcm4709-pinmux" - "brcm,bcm53012-pinmux" -- offset: offset of pin registers in the CRU block - -Functions and their groups available for all chipsets: -- "spi": "spi_grp" -- "i2c": "i2c_grp" -- "pwm": "pwm0_grp", "pwm1_grp", "pwm2_grp", "pwm3_grp" -- "uart1": "uart1_grp" - -Additionally available on BCM4709 and BCM53012: -- "mdio": "mdio_grp" -- "uart2": "uart2_grp" -- "sdio": "sdio_pwr_grp", "sdio_1p8v_grp" - -For documentation of subnodes see: -Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt - -Example: - dmu@1800c000 { - compatible = "simple-bus"; - ranges = <0 0x1800c000 0x1000>; - #address-cells = <1>; - #size-cells = <1>; - - cru@100 { - compatible = "syscon", "simple-mfd"; - reg = <0x100 0x1a4>; - - pinctrl { - compatible = "brcm,bcm4708-pinmux"; - offset = <0xc0>; - - spi-pins { - function = "spi"; - groups = "spi_grp"; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml new file mode 100644 index 000000000000..470aff599c27 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/brcm,ns-pinmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Northstar pins mux controller + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +description: + Some of Northstar SoCs's pins can be used for various purposes thanks to the + mux controller. This binding allows describing mux controller and listing + available functions. They can be referenced later by other bindings to let + system configure controller correctly. + + A list of pins varies across chipsets so few bindings are available. + + Node of the pinmux must be nested in the CRU (Central Resource Unit) "syscon" + node. + +properties: + compatible: + enum: + - brcm,bcm4708-pinmux + - brcm,bcm4709-pinmux + - brcm,bcm53012-pinmux + + offset: + description: offset of pin registers in the CRU block + maxItems: 1 + $ref: /schemas/types.yaml#/definitions/uint32-array + +patternProperties: + '-pins$': + type: object + description: pin node + $ref: pinmux-node.yaml# + + properties: + function: + enum: [ spi, i2c, pwm, uart1, mdio, uart2, sdio ] + groups: + minItems: 1 + maxItems: 4 + items: + enum: [ spi_grp, i2c_grp, pwm0_grp, pwm1_grp, pwm2_grp, pwm3_grp, + uart1_grp, mdio_grp, uart2_grp, sdio_pwr_grp, sdio_1p8v_grp ] + + required: + - function + - groups + + additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: brcm,bcm4708-pinmux + then: + patternProperties: + '-pins$': + properties: + function: + enum: [ spi, i2c, pwm, uart1 ] + groups: + items: + enum: [ spi_grp, i2c_grp, pwm0_grp, pwm1_grp, pwm2_grp, pwm3_grp, + uart1_grp ] + +required: + - offset + +additionalProperties: false + +examples: + - | + cru@1800c100 { + compatible = "syscon", "simple-mfd"; + reg = <0x1800c100 0x1a4>; + + pinctrl { + compatible = "brcm,bcm4708-pinmux"; + offset = <0xc0>; + + spi-pins { + function = "spi"; + groups = "spi_grp"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt index 6ec3c8d79f49..2fa5edac7a35 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt @@ -49,6 +49,7 @@ Optional properties: - interrupt-controller: Marks the device node as a interrupt controller. - drive-open-drain: Sets the ODR flag in the IOCON register. This configures the IRQ output as open drain active low. +- reset-gpios: Corresponds to the active-low RESET# pin for the chip Optional device specific properties: - microchip,irq-mirror: Sets the mirror flag in the IOCON register. Devices @@ -135,6 +136,7 @@ gpio21: gpio@21 { microchip,irq-mirror; pinctrl-names = "default"; pinctrl-0 = <&i2cgpio0irq>, <&gpio21pullups>; + reset-gpios = <&gpio6 15 GPIO_ACTIVE_LOW>; gpio21pullups: pinmux { pins = "gpio0", "gpio1", "gpio2", "gpio3", diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt index 360e59c9301a..5fe2c26c28bf 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt @@ -12,6 +12,7 @@ Required properties: "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl. "mediatek,mt8167-pinctrl", compatible with mt8167 pinctrl. "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl. + "mediatek,mt8365-pinctrl", compatible with mt8365 pinctrl. "mediatek,mt8516-pinctrl", compatible with mt8516 pinctrl. - pins-are-numbered: Specify the subnodes are using numbered pinmux to specify pins. diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt index f6a9760558a6..161216daf463 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -31,6 +31,7 @@ PMIC's from Qualcomm. "qcom,pm8350b-gpio" "qcom,pm8350c-gpio" "qcom,pmk8350-gpio" + "qcom,pm7325-gpio" "qcom,pmr735a-gpio" "qcom,pmr735b-gpio" "qcom,pm6150-gpio" @@ -120,6 +121,7 @@ to specify in a pin configuration subnode: gpio1-gpio8 for pm8350b gpio1-gpio9 for pm8350c gpio1-gpio4 for pmk8350 + gpio1-gpio10 for pm7325 gpio1-gpio4 for pmr735a gpio1-gpio4 for pmr735b gpio1-gpio10 for pm6150 diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt index 0ba07bc96c55..5363d44cbb74 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt @@ -21,6 +21,7 @@ of PMIC's from Qualcomm. "qcom,pmi8950-mpp", "qcom,pm8994-mpp", "qcom,pma8084-mpp", + "qcom,pmi8994-mpp", And must contain either "qcom,spmi-mpp" or "qcom,ssbi-mpp" if the device is on an spmi bus or an ssbi bus respectively. diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml new file mode 100644 index 000000000000..5f7adaa81f83 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm6125-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# +title: Qualcomm Technologies, Inc. SM6125 TLMM block + +maintainers: + - Martin Botka <martin.botka@somainline.org> + +description: | + This binding describes the Top Level Mode Multiplexer (TLMM) block found + in the SM6125 platform. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,sm6125-tlmm + + reg: + minItems: 3 + maxItems: 3 + + reg-names: + items: + - const: "west" + - const: "south" + - const: "east" + + interrupts: true + interrupt-controller: true + '#interrupt-cells': true + gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': true + gpio-ranges: true + wakeup-parent: true + +required: + - compatible + - reg + - reg-names + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sm6125-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sm6125-tlmm-state" + +$defs: + qcom-sm6125-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio[0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-2]$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ adsp_ext, agera_pll, atest_char, atest_char0, atest_char1, + atest_char2, atest_char3, atest_tsens, atest_tsens2, atest_usb1, + atest_usb10, atest_usb11, atest_usb12, atest_usb13, atest_usb2, + atest_usb20, atest_usb21, atest_usb22, atest_usb23, aud_sb, + audio_ref, cam_mclk, cci_async, cci_i2c, cci_timer0, cci_timer1, + cci_timer2, cci_timer3, cci_timer4, copy_gp, copy_phase, cri_trng, + cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, + ddr_pxi2, ddr_pxi3, debug_hot, dmic0_clk, dmic0_data, dmic1_clk, + dmic1_data, dp_hot, edp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3, + gp_pdm0, gp_pdm1, gp_pdm2, gpio, gps_tx, jitter_bist, ldo_en, + ldo_update, m_voc, mclk1, mclk2, mdp_vsync, mdp_vsync0, mdp_vsync1, + mdp_vsync2, mdp_vsync3, mdp_vsync4, mdp_vsync5, mpm_pwr, mss_lte, + nav_pps, pa_indicator, phase_flag, pll_bist, pll_bypassnl, pll_reset, + pri_mi2s, pri_mi2s_ws, prng_rosc, qca_sb, qdss_cti, qdss, qlink_enable, + qlink_request, qua_mi2s, qui_mi2s, qup00, qup01, qup02, qup03, qup04, + qup10, qup11, qup12, qup13, qup14, sd_write, sec_mi2s, sp_cmu, swr_rx, + swr_tx, ter_mi2s, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm, + uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data, + uim2_present, uim2_reset, unused1, unused2, usb_phy, vfr_1, vsense_trigger, + wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk, wsa_data ] + + + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + pinctrl@500000 { + compatible = "qcom,sm6125-tlmm"; + reg = <0x00500000 0x400000>, + <0x00900000 0x400000>, + <0x00d00000 0x400000>; + reg-names = "west", "south", "east"; + interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + gpio-ranges = <&tlmm 0 0 134>; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml index d30f85cc395e..f005abac7079 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml +++ b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml @@ -37,7 +37,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: vpu - const: vapb diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt deleted file mode 100644 index 49aba15dff8b..000000000000 --- a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt +++ /dev/null @@ -1,100 +0,0 @@ -DT bindings for the Renesas R-Mobile System Controller - -== System Controller Node == - -The R-Mobile System Controller provides the following functions: - - Boot mode management, - - Reset generation, - - Power management. - -Required properties: -- compatible: Should be "renesas,sysc-<soctype>", "renesas,sysc-rmobile" as - fallback. - Examples with soctypes are: - - "renesas,sysc-r8a73a4" (R-Mobile APE6) - - "renesas,sysc-r8a7740" (R-Mobile A1) - - "renesas,sysc-sh73a0" (SH-Mobile AG5) -- reg: Two address start and address range blocks for the device: - - The first block refers to the normally accessible registers, - - the second block refers to the registers protected by the HPB - semaphore. - -Optional nodes: -- pm-domains: This node contains a hierarchy of PM domain nodes, which should - match the Power Area Hierarchy in the Power Domain Specifications section of - the device's datasheet. - - -== PM Domain Nodes == - -Each of the PM domain nodes represents a PM domain, as documented by the -generic PM domain bindings in -Documentation/devicetree/bindings/power/power-domain.yaml. - -The nodes should be named by the real power area names, and thus their names -should be unique. - -Required properties: - - #power-domain-cells: Must be 0. - -Optional properties: -- reg: If the PM domain is not always-on, this property must contain the bit - index number for the corresponding power area in the various Power - Control and Status Registers. The parent's node must contain the - following two properties: - - #address-cells: Must be 1, - - #size-cells: Must be 0. - If the PM domain is always-on, this property must be omitted. - - -Example: - -This shows a subset of the r8a7740 PM domain hierarchy, containing the -C5 "always-on" domain, 2 of its subdomains (A4S and A4SU), and the A3SP domain, -which is a subdomain of A4S. - - sysc: system-controller@e6180000 { - compatible = "renesas,sysc-r8a7740", "renesas,sysc-rmobile"; - reg = <0xe6180000 0x8000>, <0xe6188000 0x8000>; - - pm-domains { - pd_c5: c5 { - #address-cells = <1>; - #size-cells = <0>; - #power-domain-cells = <0>; - - pd_a4s: a4s@10 { - reg = <10>; - #address-cells = <1>; - #size-cells = <0>; - #power-domain-cells = <0>; - - pd_a3sp: a3sp@11 { - reg = <11>; - #power-domain-cells = <0>; - }; - }; - - pd_a4su: a4su@20 { - reg = <20>; - #power-domain-cells = <0>; - }; - }; - }; - }; - - -== PM Domain Consumers == - -Hardware blocks belonging to a PM domain should contain a "power-domains" -property that is a phandle pointing to the corresponding PM domain node. - -Example: - - tpu: pwm@e6600000 { - compatible = "renesas,tpu-r8a7740", "renesas,tpu"; - reg = <0xe6600000 0x100>; - clocks = <&mstp3_clks R8A7740_CLK_TPU0>; - power-domains = <&pd_a3sp>; - #pwm-cells = <3>; - }; diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml new file mode 100644 index 000000000000..559718997de7 --- /dev/null +++ b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/renesas,sysc-rmobile.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Mobile System Controller + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + - Magnus Damm <magnus.damm@gmail.com> + +description: | + The R-Mobile System Controller provides the following functions: + - Boot mode management, + - Reset generation, + - Power management. + +properties: + compatible: + items: + - enum: + - renesas,sysc-r8a73a4 # R-Mobile APE6 + - renesas,sysc-r8a7740 # R-Mobile A1 + - renesas,sysc-sh73a0 # SH-Mobile AG5 + - const: renesas,sysc-rmobile # Generic SH/R-Mobile + + reg: + items: + - description: Normally accessible register block + - description: Register block protected by the HPB semaphore + + pm-domains: + type: object + description: | + This node contains a hierarchy of PM domain nodes, which should match the + Power Area Hierarchy in the Power Domain Specifications section of the + device's datasheet. + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + additionalProperties: + $ref: "#/$defs/pd-node" + +required: + - compatible + - reg + - pm-domains + +additionalProperties: false + +$defs: + pd-node: + type: object + description: + PM domain node representing a PM domain. This node hould be named by + the real power area name, and thus its name should be unique. + + properties: + reg: + maxItems: 1 + description: + If the PM domain is not always-on, this property must contain the + bit index number for the corresponding power area in the various + Power Control and Status Registers. + If the PM domain is always-on, this property must be omitted. + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + '#power-domain-cells': + const: 0 + + required: + - '#power-domain-cells' + + additionalProperties: + $ref: "#/$defs/pd-node" + +examples: + - | + // This shows a subset of the r8a7740 PM domain hierarchy, containing the + // C5 "always-on" domain, 2 of its subdomains (A4S and A4SU), and the A3SP + // domain, which is a subdomain of A4S. + sysc: system-controller@e6180000 { + compatible = "renesas,sysc-r8a7740", "renesas,sysc-rmobile"; + reg = <0xe6180000 0x8000>, <0xe6188000 0x8000>; + + pm-domains { + pd_c5: c5 { + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <0>; + + pd_a4s: a4s@10 { + reg = <10>; + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <0>; + + pd_a3sp: a3sp@11 { + reg = <11>; + #power-domain-cells = <0>; + }; + }; + + pd_a4su: a4su@20 { + reg = <20>; + #power-domain-cells = <0>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml b/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml index db1aa238cda5..b62c2431f94e 100644 --- a/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml @@ -20,7 +20,7 @@ properties: maxItems: 1 phys: - $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 description: phandle to the USB phy monitored-battery: diff --git a/Documentation/devicetree/bindings/property-units.txt b/Documentation/devicetree/bindings/property-units.txt deleted file mode 100644 index 218f99fa311f..000000000000 --- a/Documentation/devicetree/bindings/property-units.txt +++ /dev/null @@ -1,48 +0,0 @@ -Standard Unit Suffixes for Property names - -Properties which have a unit of measure are recommended to have a unit -suffix appended to the property name. The list below contains the -recommended suffixes. Other variations exist in bindings, but should not -be used in new bindings or added here. The inconsistency in the unit -prefixes is due to selecting the most commonly used variants. - -It is also recommended to use the units listed here and not add additional -unit prefixes. - -Time/Frequency ----------------------------------------- --mhz : megahertz --hz : hertz (preferred) --sec : second --ms : millisecond --us : microsecond --ns : nanosecond --ps : picosecond - -Distance ----------------------------------------- --mm : millimeter - -Electricity ----------------------------------------- --microamp : microampere --microamp-hours : microampere hour --ohms : ohm --micro-ohms : microohm --microwatt-hours: microwatt hour --microvolt : microvolt --picofarads : picofarad --femtofarads : femtofarad - -Temperature ----------------------------------------- --celsius : degree Celsius --millicelsius : millidegree Celsius - -Pressure ----------------------------------------- --kpascal : kilopascal - -Throughput ----------------------------------------- --kBps : kilobytes per second diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml index 7dcab2bf8128..54a7700df08f 100644 --- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml @@ -37,7 +37,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Module Clock - description: Bus Clock diff --git a/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.txt b/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.txt deleted file mode 100644 index 655f6cd4ef46..000000000000 --- a/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.txt +++ /dev/null @@ -1,21 +0,0 @@ -Broadcom iProc PWM controller device tree bindings - -This controller has 4 channels. - -Required Properties : -- compatible: must be "brcm,iproc-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@18031000 { - compatible = "brcm,iproc-pwm"; - reg = <0x18031000 0x28>; - clocks = <&osc>; - #pwm-cells = <3>; -}; diff --git a/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.yaml b/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.yaml new file mode 100644 index 000000000000..218ab06c34d1 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/brcm,iproc-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom iProc PWM controller + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +description: + This controller has 4 channels. + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + const: brcm,iproc-pwm + + reg: + maxItems: 1 + + clocks: + description: external clock + maxItems: 1 + + "#pwm-cells": + const: 3 + +unevaluatedProperties: false + +required: + - reg + - clocks + +examples: + - | + pwm@18031000 { + compatible = "brcm,iproc-pwm"; + reg = <0x18031000 0x28>; + clocks = <&osc>; + #pwm-cells = <3>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm.yaml b/Documentation/devicetree/bindings/pwm/pwm.yaml index 7d1f687cee9c..2effe6c0de6b 100644 --- a/Documentation/devicetree/bindings/pwm/pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm.yaml @@ -24,8 +24,9 @@ additionalProperties: true examples: - | - pwm: pwm@7000a000 { - compatible = "nvidia,tegra20-pwm"; - reg = <0x7000a000 0x100>; - #pwm-cells = <2>; + pwm: pwm@1c20e00 { + compatible = "allwinner,sun7i-a20-pwm"; + reg = <0x01c20e00 0xc>; + clocks = <&osc24M>; + #pwm-cells = <3>; }; diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml index 3c2fa2e93d1b..7ea1070b4b3a 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml @@ -61,6 +61,19 @@ required: - reg - '#pwm-cells' - clocks + - power-domains + +if: + not: + properties: + compatible: + contains: + enum: + - renesas,pwm-r8a7778 + - renesas,pwm-r8a7779 +then: + required: + - resets additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml index aa9a4570c906..81ccb2110162 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml @@ -9,6 +9,15 @@ title: Renesas R-Car Timer Pulse Unit PWM Controller maintainers: - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> +select: + properties: + compatible: + contains: + const: renesas,tpu + required: + - compatible + - '#pwm-cells' + properties: compatible: items: @@ -58,6 +67,23 @@ required: - compatible - reg - '#pwm-cells' + - clocks + - power-domains + +allOf: + - $ref: pwm.yaml# + + - if: + not: + properties: + compatible: + contains: + enum: + - renesas,tpu-r8a73a4 + - renesas,tpu-r8a7740 + then: + required: + - resets additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/max8893.yaml b/Documentation/devicetree/bindings/regulator/max8893.yaml new file mode 100644 index 000000000000..2b5e977bf409 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/max8893.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/max8893.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Regulator driver for MAX8893 PMIC from Maxim Integrated. + +maintainers: + - Sergey Larin <cerg2010cerg2010@mail.ru> + +description: | + The device has 5 LDO regulators and a single BUCK regulator. + Programming is done through I2C bus. + +properties: + compatible: + const: maxim,max8893 + + reg: + maxItems: 1 + + regulators: + type: object + + patternProperties: + "^(ldo[1-5]|buck)$": + $ref: "regulator.yaml#" + + additionalProperties: false + +additionalProperties: false + +required: + - compatible + - reg + - regulators + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@3e { + compatible = "maxim,max8893"; + reg = <0x3e>; + + regulators { + /* Front camera - s5k6aafx, back - m5mo */ + /* Numbers used to indicate the sequence */ + front_1_back_1: buck { + regulator-name = "cam_isp_core_1v2"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + }; + + front_4_back_5: ldo1 { + regulator-name = "vt_io_1v8,cam_isp_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + front_3_back_4: ldo2 { + regulator-name = "vt_core_1v5"; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1500000>; + }; + + front_5_back_6: ldo3 { + regulator-name = "vt_cam_1v8,vt_sensor_io_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + ldo4 { + /* not used */ + }; + + back_7: ldo5 { + regulator-name = "cam_sensor_io_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index e561a5b941e4..34de38377aa6 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -33,6 +33,9 @@ description: | The names used for regulator nodes must match those supported by a given PMIC. Supported regulator node names are + For PM6150, smps1 - smps5, ldo1 - ldo19 + For PM6150L, smps1 - smps8, ldo1 - ldo11, bob + For PM7325, smps1 - smps8, ldo1 - ldo19 For PM8005, smps1 - smps4 For PM8009, smps1 - smps2, ldo1 - ldo7 For PM8150, smps1 - smps10, ldo1 - ldo18 @@ -41,15 +44,15 @@ description: | For PM8350C, smps1 - smps10, ldo1 - ldo13, bob For PM8998, smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2 For PMI8998, bob - For PM6150, smps1 - smps5, ldo1 - ldo19 - For PM6150L, smps1 - smps8, ldo1 - ldo11, bob - For PMX55, smps1 - smps7, ldo1 - ldo16 - For PM7325, smps1 - smps8, ldo1 - ldo19 For PMR735A, smps1 - smps3, ldo1 - ldo7 + For PMX55, smps1 - smps7, ldo1 - ldo16 properties: compatible: enum: + - qcom,pm6150-rpmh-regulators + - qcom,pm6150l-rpmh-regulators + - qcom,pm7325-rpmh-regulators - qcom,pm8005-rpmh-regulators - qcom,pm8009-rpmh-regulators - qcom,pm8009-1-rpmh-regulators @@ -59,11 +62,9 @@ properties: - qcom,pm8350c-rpmh-regulators - qcom,pm8998-rpmh-regulators - qcom,pmi8998-rpmh-regulators - - qcom,pm6150-rpmh-regulators - - qcom,pm6150l-rpmh-regulators - - qcom,pmx55-rpmh-regulators - - qcom,pm7325-rpmh-regulators + - qcom,pmm8155au-rpmh-regulators - qcom,pmr735a-rpmh-regulators + - qcom,pmx55-rpmh-regulators qcom,pmic-id: description: | diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index a35c6cb9bf97..83b53579f463 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -24,6 +24,10 @@ description: For mp5496, s2 + For pm8226, s1, s2, s3, s4, s5, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, + l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, + l26, l27, l28, lvs1 + For pm8841, s1, s2, s3, s4, s5, s6, s7, s8 For pm8916, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, @@ -68,6 +72,7 @@ properties: compatible: enum: - qcom,rpm-mp5496-regulators + - qcom,rpm-pm8226-regulators - qcom,rpm-pm8841-regulators - qcom,rpm-pm8916-regulators - qcom,rpm-pm8941-regulators diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index 6d0bc9cd4040..a6ae9ecae5cc 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -117,6 +117,88 @@ properties: description: Enable over current protection. type: boolean + regulator-oc-protection-microamp: + description: Set over current protection limit. This is a limit where + hardware performs emergency shutdown. Zero can be passed to disable + protection and value '1' indicates that protection should be enabled but + limit setting can be omitted. + + 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. + Zero can be passed to disable error detection and value '1' indicates + that detection should be enabled but limit setting can be omitted. + + regulator-oc-warn-microamp: + description: Set over current warning limit. This is a limit where hardware + is assumed still to be functional but approaching limit where it gets + damaged. Recovery actions should be initiated. Zero can be passed to + disable detection and value '1' indicates that detection should + be enabled but limit setting can be omitted. + + regulator-ov-protection-microvolt: + description: Set over voltage protection limit. This is a limit where + hardware performs emergency shutdown. Zero can be passed to disable + protection and value '1' indicates that protection should be enabled but + limit setting can be omitted. Limit is given as microvolt offset from + voltage set to regulator. + + 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 + 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. + + regulator-ov-warn-microvolt: + description: Set over voltage warning limit. This is a limit where hardware + is assumed still to be functional but approaching limit where it gets + damaged. Recovery actions should be initiated. Zero can be passed to + disable 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. + + regulator-uv-protection-microvolt: + description: Set over under voltage protection limit. This is a limit where + hardware performs emergency shutdown. Zero can be passed to disable + protection and value '1' indicates that protection should be enabled but + limit setting can be omitted. Limit is given as microvolt offset from + voltage set to regulator. + + 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 + 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. + + regulator-uv-warn-microvolt: + description: Set over under voltage warning limit. This is a limit where + hardware is assumed still to be functional but approaching limit where + it gets damaged. Recovery actions should be initiated. Zero can be passed + to disable 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. + + regulator-temp-protection-kelvin: + description: Set over temperature protection limit. This is a limit where + hardware performs emergency shutdown. Zero can be passed to disable + protection and value '1' indicates that protection should be enabled but + limit setting can be omitted. + + 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 + Zero can be passed to disable error detection and value '1' indicates + that detection should be enabled but limit setting can be omitted. + + regulator-temp-warn-kelvin: + description: Set over temperature warning limit. This is a limit where + hardware is assumed still to be functional but approaching limit where it + gets damaged. Recovery actions should be initiated. Zero can be passed to + disable detection and value '1' indicates that detection should + be enabled but limit setting can be omitted. + regulator-active-discharge: description: | tristate, enable/disable active discharge of regulators. The values are: diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt6160-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt6160-regulator.yaml new file mode 100644 index 000000000000..0534b0d68359 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt6160-regulator.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt6160-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT6160 BuckBoost converter + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + The RT6160 is a high-efficiency buck-boost converter that can provide + up to 3A output current from 2025mV to 5200mV. And it support the wide + input voltage range from 2200mV to 5500mV. + + Datasheet is available at + https://www.richtek.com/assets/product_file/RT6160A/DS6160A-00.pdf + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - richtek,rt6160 + + reg: + maxItems: 1 + + enable-gpios: + description: A connection of the 'enable' gpio line. + maxItems: 1 + + richtek,vsel-active-low: + description: | + Used to indicate the 'vsel' pin active level. if not specified, use + high active level as the default. + type: boolean + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rt6160@75 { + compatible = "richtek,rt6160"; + reg = <0x75>; + enable-gpios = <&gpio26 2 0>; + regulator-name = "rt6160-buckboost"; + regulator-min-microvolt = <2025000>; + regulator-max-microvolt = <5200000>; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml new file mode 100644 index 000000000000..796ceac87445 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt6245-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT6245 High Current Voltage Regulator + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + The RT6245 is a high-performance, synchronous step-down converter + that can deliver up to 14A output current with an input supply + voltage range of 4.5V to 17V. + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - richtek,rt6245 + + reg: + maxItems: 1 + + enable-gpios: + description: | + A connection of the chip 'enable' gpio line. If not provided, + it will be treat as a default-on power. + maxItems: 1 + + richtek,oc-level-select: + $ref: "/schemas/types.yaml#/definitions/uint8" + enum: [0, 1, 2, 3] + description: | + Over current level selection. Each respective value means the current + limit 8A, 14A, 12A, 10A. If this property is missing then keep in + in chip default. + + richtek,ot-level-select: + $ref: "/schemas/types.yaml#/definitions/uint8" + enum: [0, 1, 2] + description: | + Over temperature level selection. Each respective value means the degree + 150'c, 130'c, 170'c. If this property is missing then keep in chip + default. + + richtek,pgdly-time-select: + $ref: "/schemas/types.yaml#/definitions/uint8" + enum: [0, 1, 2, 3] + description: | + Power good signal delay time selection. Each respective value means the + delay time 0us, 10us, 20us, 40us. If this property is missing then keep + in chip default. + + + richtek,switch-freq-select: + $ref: "/schemas/types.yaml#/definitions/uint8" + enum: [0, 1, 2] + description: | + Buck switch frequency selection. Each respective value means 400KHz, + 800KHz, 1200KHz. If this property is missing then keep in chip default. + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rt6245@34 { + compatible = "richtek,rt6245"; + status = "okay"; + reg = <0x34>; + enable-gpios = <&gpio26 2 0>; + + regulator-name = "rt6245-regulator"; + regulator-min-microvolt = <437500>; + regulator-max-microvolt = <1387500>; + regulator-boot-on; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml index b6515a0cee62..7cb74cc8c5d9 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml @@ -27,6 +27,12 @@ patternProperties: Properties for single regulator. $ref: "regulator.yaml#" + properties: + rohm,ocw-fet-ron-micro-ohms: + description: | + External FET's ON-resistance. Required if VoutS1 OCP/OCW is + to be set. + required: - regulator-name diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index 64afdcfb613d..1e6225677e00 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -72,7 +72,6 @@ properties: - from local to remote, where ACK from the remote means that communnication as been stopped on the remote side. minItems: 1 - maxItems: 4 mbox-names: items: @@ -81,7 +80,6 @@ properties: - const: shutdown - const: detach minItems: 1 - maxItems: 4 memory-region: description: diff --git a/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt b/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt index 461dc1d8d570..463a97c11eff 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt +++ b/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt @@ -48,7 +48,7 @@ The following are the mandatory properties: bindings for the reset argument specifier as per SoC, Documentation/devicetree/bindings/reset/ti-syscon-reset.txt for 66AK2HK/66AK2L/66AK2E SoCs or, - Documentation/devicetree/bindings/reset/ti,sci-reset.txt + Documentation/devicetree/bindings/reset/ti,sci-reset.yaml for 66AK2G SoCs - interrupts: Should contain an entry for each value in 'interrupt-names'. @@ -82,7 +82,7 @@ The following are mandatory properties for Keystone 2 66AK2G SoCs only: - power-domains: Should contain a phandle to a PM domain provider node and an args specifier containing the DSP device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Optional properties: -------------------- diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml index 73400bc6e91d..c6c12129d6b7 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml @@ -65,7 +65,7 @@ properties: OMAP Mailbox specifier denoting the sub-mailbox, to be used for communication with the remote processor. The specifier format is as per the bindings, - Documentation/devicetree/bindings/mailbox/omap-mailbox.txt + Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml This property should match with the sub-mailbox node used in the firmware image. @@ -116,7 +116,6 @@ properties: list, in the specified order, each representing the corresponding internal RAM memory region. minItems: 1 - maxItems: 3 items: - const: l2ram - const: l1pram diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml index 27c5e34a3ac6..b11ac533f914 100644 --- a/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml +++ b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml @@ -59,7 +59,6 @@ properties: - description: SRC interrupt - description: CPU WDOG interrupts out of SRC minItems: 1 - maxItems: 2 '#reset-cells': const: 1 diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt deleted file mode 100644 index 8b1cf022f18a..000000000000 --- a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt +++ /dev/null @@ -1,62 +0,0 @@ -Texas Instruments System Control Interface (TI-SCI) Reset Controller -===================================================================== - -Some TI SoCs contain a system controller (like the Power Management Micro -Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling -the state of the various hardware modules present on the SoC. Communication -between the host processor running an OS and the system controller happens -through a protocol called TI System Control Interface (TI-SCI protocol). -For TI SCI details, please refer to the document, -Documentation/devicetree/bindings/arm/keystone/ti,sci.txt - -TI-SCI Reset Controller Node -============================ -This reset controller node uses the TI SCI protocol to perform the reset -management of various hardware modules present on the SoC. Must be a child -node of the associated TI-SCI system controller node. - -Required properties: --------------------- - - compatible : Should be "ti,sci-reset" - - #reset-cells : Should be 2. Please see the reset consumer node below for - usage details. - -TI-SCI Reset Consumer Nodes -=========================== -Each of the reset consumer nodes should have the following properties, -in addition to their own properties. - -Required properties: --------------------- - - resets : A phandle and reset specifier pair, one pair for each reset - signal that affects the device, or that the device manages. - The phandle should point to the TI-SCI reset controller node, - and the reset specifier should have 2 cell-values. The first - cell should contain the device ID. The second cell should - contain the reset mask value used by system controller. - Please refer to the protocol documentation for these values - to be used for different devices, - http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data - -Please also refer to Documentation/devicetree/bindings/reset/reset.txt for -common reset controller usage by consumers. - -Example: --------- -The following example demonstrates both a TI-SCI reset controller node and a -consumer (a DSP device) on the 66AK2G SoC. - -pmmc: pmmc { - compatible = "ti,k2g-sci"; - - k2g_reset: reset-controller { - compatible = "ti,sci-reset"; - #reset-cells = <2>; - }; -}; - -dsp0: dsp@10800000 { - ... - resets = <&k2g_reset 0x0046 0x1>; - ... -}; diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml new file mode 100644 index 000000000000..4639d2cec557 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/ti,sci-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI-SCI reset controller node bindings + +maintainers: + - Nishanth Menon <nm@ti.com> + +description: | + Some TI SoCs contain a system controller (like the Power Management Micro + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling + the state of the various hardware modules present on the SoC. Communication + between the host processor running an OS and the system controller happens + through a protocol called TI System Control Interface (TI-SCI protocol). + + This reset controller node uses the TI SCI protocol to perform the reset + management of various hardware modules present on the SoC. Must be a child + node of the associated TI-SCI system controller node. + +properties: + $nodename: + pattern: "^reset-controller$" + + compatible: + const: ti,sci-reset + + "#reset-cells": + const: 2 + description: + The two cells represent values that the TI-SCI controller defines. + + The first cell should contain the device ID. + + The second cell should contain the reset mask corresponding to the device + used by system controller. + + Please see http://processors.wiki.ti.com/index.php/TISCI for + protocol documentation for the values to be used for different devices. + + +additionalProperties: false + +examples: + - | + k3_reset: reset-controller { + compatible = "ti,sci-reset"; + #reset-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml index 23b227614366..1d38ff76d18f 100644 --- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml +++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml @@ -56,7 +56,6 @@ properties: interrupts: minItems: 3 - maxItems: 4 items: - description: DirError interrupt - description: DataError interrupt diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt b/Documentation/devicetree/bindings/rng/mtk-rng.txt deleted file mode 100644 index dfdcb5cd2ea8..000000000000 --- a/Documentation/devicetree/bindings/rng/mtk-rng.txt +++ /dev/null @@ -1,22 +0,0 @@ -Device-Tree bindings for Mediatek random number generator -found in MediaTek SoC family - -Required properties: -- compatible : Should be - "mediatek,mt7622-rng", "mediatek,mt7623-rng" : for MT7622 - "mediatek,mt7629-rng", "mediatek,mt7623-rng" : for MT7629 - "mediatek,mt7623-rng" : for MT7623 - "mediatek,mt8516-rng", "mediatek,mt7623-rng" : for MT8516 -- clocks : list of clock specifiers, corresponding to - entries in clock-names property; -- clock-names : Should contain "rng" entries; -- reg : Specifies base physical address and size of the registers - -Example: - -rng: rng@1020f000 { - compatible = "mediatek,mt7623-rng"; - reg = <0 0x1020f000 0 0x1000>; - clocks = <&infracfg CLK_INFRA_TRNG>; - clock-names = "rng"; -}; diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml new file mode 100644 index 000000000000..61888e07bda0 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/rng/mtk-rng.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Random number generator + +maintainers: + - Sean Wang <sean.wang@mediatek.com> + +properties: + $nodename: + pattern: "^rng@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - mediatek,mt7623-rng + - items: + - enum: + - mediatek,mt7622-rng + - mediatek,mt7629-rng + - mediatek,mt8365-rng + - mediatek,mt8516-rng + - const: mediatek,mt7623-rng + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: rng + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt2701-clk.h> + rng: rng@1020f000 { + compatible = "mediatek,mt7623-rng"; + reg = <0x1020f000 0x1000>; + clocks = <&infracfg CLK_INFRA_TRNG>; + clock-names = "rng"; + }; diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml index b1b0ee769b71..beeb90e55727 100644 --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml @@ -32,7 +32,6 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: RTC Alarm 0 - description: RTC Alarm 1 diff --git a/Documentation/devicetree/bindings/rtc/arm,pl031.yaml b/Documentation/devicetree/bindings/rtc/arm,pl031.yaml new file mode 100644 index 000000000000..fa5f2eda372e --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/arm,pl031.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/arm,pl031.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm Primecell PL031 Real Time Clock + +select: + properties: + compatible: + contains: + const: arm,pl031 + required: + - compatible + +allOf: + - $ref: rtc.yaml# + +maintainers: + - Rob Herring <robh@kernel.org> + +properties: + compatible: + items: + - const: arm,pl031 + - const: arm,primecell + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + + start-year: true + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + rtc@10017000 { + compatible = "arm,pl031", "arm,primecell"; + reg = <0x10017000 0x1000>; + clocks = <&pclk>; + clock-names = "apb_pclk"; + }; diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml index 06bd737821c1..4807c95a663c 100644 --- a/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml @@ -21,7 +21,6 @@ properties: - description: rtc alarm interrupt - description: dryice security violation interrupt minItems: 1 - maxItems: 2 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml new file mode 100644 index 000000000000..a98b72752349 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/nxp,pcf8563.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Philips PCF8563/Epson RTC8564 Real Time Clock + +maintainers: + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + enum: + - epson,rtc8564 + - microcrystal,rv8564 + - nxp,pca8565 + - nxp,pcf8563 + - nxp,pcf85263 + - nxp,pcf85363 + + reg: + maxItems: 1 + + "#clock-cells": + const: 0 + + clock-output-names: + maxItems: 1 + + interrupts: + maxItems: 1 + + start-year: true + wakeup-source: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + #clock-cells = <0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/rtc/pcf85363.txt b/Documentation/devicetree/bindings/rtc/pcf85363.txt deleted file mode 100644 index 94adc1cf93d9..000000000000 --- a/Documentation/devicetree/bindings/rtc/pcf85363.txt +++ /dev/null @@ -1,17 +0,0 @@ -NXP PCF85263/PCF85363 Real Time Clock -============================ - -Required properties: -- compatible: Should contain "nxp,pcf85263" or "nxp,pcf85363". -- reg: I2C address for chip. - -Optional properties: -- interrupts: IRQ line for the RTC (not implemented). - -Example: - -pcf85363: pcf85363@51 { - compatible = "nxp,pcf85363"; - reg = <0x51>; -}; - diff --git a/Documentation/devicetree/bindings/rtc/pcf8563.txt b/Documentation/devicetree/bindings/rtc/pcf8563.txt deleted file mode 100644 index 0a900f7c8977..000000000000 --- a/Documentation/devicetree/bindings/rtc/pcf8563.txt +++ /dev/null @@ -1,29 +0,0 @@ -* Philips PCF8563/Epson RTC8564 Real Time Clock - -Philips PCF8563/Epson RTC8564 Real Time Clock - -Required properties: -- compatible: Should contain "nxp,pcf8563", - "epson,rtc8564" or - "microcrystal,rv8564" or - "nxp,pca8565" -- reg: I2C address for chip. - -Optional property: -- #clock-cells: Should be 0. -- clock-output-names: - overwrite the default clock name "pcf8563-clkout" - -Example: - -pcf8563: pcf8563@51 { - compatible = "nxp,pcf8563"; - reg = <0x51>; - #clock-cells = <0>; -}; - -device { -... - clocks = <&pcf8563>; -... -}; diff --git a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml new file mode 100644 index 000000000000..bdb72d3ddf2a --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/xlnx,zynqmp-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq Ultrascale+ MPSoC Real Time Clock + +description: + RTC controller for the Xilinx Zynq MPSoC Real Time Clock. + The RTC controller has separate IRQ lines for seconds and alarm. + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + const: xlnx,zynqmp-rtc + + reg: + maxItems: 1 + + interrupts: + minItems: 2 + + interrupt-names: + items: + - const: alarm + - const: sec + + calibration: + description: | + calibration value for 1 sec period which will + be programmed directly to calibration register. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x1 + maximum: 0x1FFFFF + default: 0x198233 + +required: + - compatible + - reg + - interrupts + - interrupt-names + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + rtc: rtc@ffa60000 { + compatible = "xlnx,zynqmp-rtc"; + reg = <0x0 0xffa60000 0x0 0x100>; + interrupt-parent = <&gic>; + interrupts = <0 26 4>, <0 27 4>; + interrupt-names = "alarm", "sec"; + calibration = <0x198233>; + }; + }; diff --git a/Documentation/devicetree/bindings/rtc/xlnx-rtc.txt b/Documentation/devicetree/bindings/rtc/xlnx-rtc.txt deleted file mode 100644 index 0df6f016b1b7..000000000000 --- a/Documentation/devicetree/bindings/rtc/xlnx-rtc.txt +++ /dev/null @@ -1,25 +0,0 @@ -* Xilinx Zynq Ultrascale+ MPSoC Real Time Clock - -RTC controller for the Xilinx Zynq MPSoC Real Time Clock -Separate IRQ lines for seconds and alarm - -Required properties: -- compatible: Should be "xlnx,zynqmp-rtc" -- reg: Physical base address of the controller and length - of memory mapped region. -- interrupts: IRQ lines for the RTC. -- interrupt-names: interrupt line names eg. "sec" "alarm" - -Optional: -- calibration: calibration value for 1 sec period which will - be programmed directly to calibration register - -Example: -rtc: rtc@ffa60000 { - compatible = "xlnx,zynqmp-rtc"; - reg = <0x0 0xffa60000 0x100>; - interrupt-parent = <&gic>; - interrupts = <0 26 4>, <0 27 4>; - interrupt-names = "alarm", "sec"; - calibration = <0x198233>; -}; diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index bd21060d26e0..a90c971b4f1f 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -36,14 +36,12 @@ properties: - description: ipg clock - description: baud clock minItems: 1 - maxItems: 2 clock-names: items: - const: ipg - const: baud minItems: 1 - maxItems: 2 dmas: items: diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 97ec8a093bf3..3ec3822bd114 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -44,7 +44,6 @@ properties: clock-names: description: N = 0 is allowed for SoCs without internal baud clock mux. minItems: 2 - maxItems: 5 items: - const: uart - pattern: '^clk_uart_baud[0-3]$' diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml new file mode 100644 index 000000000000..2cd3bc6bd8d6 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/microchip/microchip,polarfire-soc-sys-controller.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) system controller + +maintainers: + - Conor Dooley <conor.dooley@microchip.com> + +description: | + The PolarFire SoC system controller is communicated with via a mailbox. + This document describes the bindings for the client portion of that mailbox. + + +properties: + mboxes: + maxItems: 1 + + compatible: + const: microchip,polarfire-soc-sys-controller + +required: + - compatible + - mboxes + +additionalProperties: false + +examples: + - | + syscontroller: syscontroller { + compatible = "microchip,polarfire-soc-sys-controller"; + mboxes = <&mbox 0>; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index 84671950ca0d..4663c2bcad50 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -164,7 +164,6 @@ patternProperties: interrupts: minItems: 1 - maxItems: 2 items: - description: UART core irq - description: Wakeup irq (RX GPIO) diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt deleted file mode 100644 index 6217e64309de..000000000000 --- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt +++ /dev/null @@ -1,65 +0,0 @@ -Texas Instruments TI-SCI Generic Power Domain ---------------------------------------------- - -Some TI SoCs contain a system controller (like the PMMC, etc...) that is -responsible for controlling the state of the IPs that are present. -Communication between the host processor running an OS and the system -controller happens through a protocol known as TI-SCI [1]. - -[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt - -PM Domain Node -============== -The PM domain node represents the global PM domain managed by the PMMC, which -in this case is the implementation as documented by the generic PM domain -bindings in Documentation/devicetree/bindings/power/power-domain.yaml. Because -this relies on the TI SCI protocol to communicate with the PMMC it must be a -child of the pmmc node. - -Required Properties: --------------------- -- compatible: should be "ti,sci-pm-domain" -- #power-domain-cells: Can be one of the following: - 1: Containing the device id of each node - 2: First entry should be device id - Second entry should be one of the floowing: - TI_SCI_PD_EXCLUSIVE: To allow device to be - exclusively controlled by - the requesting hosts. - TI_SCI_PD_SHARED: To allow device to be shared - by multiple hosts. - -Example (K2G): -------------- - pmmc: pmmc { - compatible = "ti,k2g-sci"; - ... - - k2g_pds: power-controller { - compatible = "ti,sci-pm-domain"; - #power-domain-cells = <1>; - }; - }; - -PM Domain Consumers -=================== -Hardware blocks belonging to a PM domain should contain a "power-domains" -property that is a phandle pointing to the corresponding PM domain node -along with an index representing the device id to be passed to the PMMC -for device control. - -Required Properties: --------------------- -- power-domains: phandle pointing to the corresponding PM domain node - and an ID representing the device. - -See http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data for the list -of valid identifiers for k2g. - -Example (K2G): --------------------- - uart0: serial@2530c00 { - compatible = "ns16550a"; - ... - power-domains = <&k2g_pds 0x002c>; - }; diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml new file mode 100644 index 000000000000..9e6cb4ee9755 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml @@ -0,0 +1,59 @@ +# 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# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI-SCI generic power domain node bindings + +maintainers: + - Nishanth Menon <nm@ti.com> + +allOf: + - $ref: /schemas/power/power-domain.yaml# + +description: | + Some TI SoCs contain a system controller (like the Power Management Micro + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling + the state of the various hardware modules present on the SoC. Communication + between the host processor running an OS and the system controller happens + through a protocol called TI System Control Interface (TI-SCI protocol). + + This PM domain node represents the global PM domain managed by the TI-SCI + controller. Since this relies on the TI SCI protocol to communicate with + the TI-SCI controller, it must be a child of the TI-SCI controller node. + +properties: + compatible: + const: ti,sci-pm-domain + + "#power-domain-cells": + enum: [1, 2] + description: + The two cells represent values that the TI-SCI controller defines. + + The first cell should contain the device ID. + + The second cell, if cell-value is 2, should be one of the following + TI_SCI_PD_EXCLUSIVE - Allows the device to be exclusively controlled + or + TI_SCI_PD_SHARED - Allows the device to be shared by multiple hosts. + Please refer to dt-bindings/soc/ti,sci_pm_domain.h for the definitions. + + Please see http://processors.wiki.ti.com/index.php/TISCI for + protocol documentation for the values to be used for different devices. + +additionalProperties: false + +examples: + - | + k2g_pds: power-controller { + compatible = "ti,sci-pm-domain"; + #power-domain-cells = <1>; + }; + + - | + k3_pds: power-controller { + compatible = "ti,sci-pm-domain"; + #power-domain-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index dbc62821c60b..9790617af1bc 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -100,7 +100,6 @@ patternProperties: properties: reg: minItems: 2 # On AM437x one of two PRUSS units don't contain Shared RAM. - maxItems: 3 items: - description: Address and size of the Data RAM0. - description: Address and size of the Data RAM1. @@ -111,7 +110,6 @@ patternProperties: reg-names: minItems: 2 - maxItems: 3 items: - const: dram0 - const: dram1 diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml index 67405e6d8168..19f111f40225 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml @@ -12,7 +12,11 @@ maintainers: properties: "#sound-dai-cells": - const: 0 + minimum: 0 + maximum: 1 + description: + A value of 0 is deprecated. When used, it only allows access to + the ADC/DAC and AIF1 (the CPU DAI), not the other two AIFs/DAIs. compatible: oneOf: @@ -50,7 +54,7 @@ additionalProperties: false examples: - | audio-codec@1c22e00 { - #sound-dai-cells = <0>; + #sound-dai-cells = <1>; compatible = "allwinner,sun8i-a33-codec"; reg = <0x01c22e00 0x400>; interrupts = <0 29 4>; diff --git a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml index db61f0731a20..2e35aeaa8781 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml @@ -57,7 +57,7 @@ patternProperties: rate sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle-array description: phandle of the CPU DAI patternProperties: @@ -71,7 +71,7 @@ patternProperties: properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle-array description: phandle of the codec DAI required: diff --git a/Documentation/devicetree/bindings/sound/cs42l42.txt b/Documentation/devicetree/bindings/sound/cs42l42.txt index 7dfaa2ab906f..5d416fdaf023 100644 --- a/Documentation/devicetree/bindings/sound/cs42l42.txt +++ b/Documentation/devicetree/bindings/sound/cs42l42.txt @@ -81,6 +81,13 @@ Optional properties: < x1 x2 x3 x4 > Default = < 15 8 4 1> + - cirrus,hs-bias-sense-disable: This is boolean property. If present the + HSBIAS sense is disabled. Configures HSBIAS output current sense through + the external 2.21-k resistor. HSBIAS_SENSE is hardware feature to reduce + the potential pop noise during the headset plug out slowly. But on some + platforms ESD voltage will affect it causing test to fail, especially + with CTIA headset type. For different hardware setups, a designer might + want to tweak default behavior. Example: diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml index b4c190bddd84..61802a11baf4 100644 --- a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml @@ -49,7 +49,7 @@ properties: maxItems: 1 memory-region: - $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 description: phandle to a node describing reserved memory (System RAM memory) The M core can't access all the DDR memory space on some platform, diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml index 4454aca34d56..f226ec13167a 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml @@ -25,6 +25,7 @@ properties: - fsl,imx8mq-spdif - fsl,imx8mm-spdif - fsl,imx8mn-spdif + - fsl,imx8ulp-spdif reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt b/Documentation/devicetree/bindings/sound/fsl-sai.txt index 0dc83cc4a236..c71c5861d787 100644 --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt @@ -9,8 +9,10 @@ Required properties: - compatible : Compatible list, contains "fsl,vf610-sai", "fsl,imx6sx-sai", "fsl,imx6ul-sai", - "fsl,imx7ulp-sai", "fsl,imx8mq-sai" or - "fsl,imx8qm-sai". + "fsl,imx7ulp-sai", "fsl,imx8mq-sai", + "fsl,imx8qm-sai", "fsl,imx8mm-sai", + "fsl,imx8mn-sai", "fsl,imx8mp-sai", or + "fsl,imx8ulp-sai". - reg : Offset and length of the register set for the device. diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml new file mode 100644 index 000000000000..d1816dd061cf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml @@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/imx-audio-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX audio sound card. + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + +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: + Each subnode represents a dai link. Subnodes of each dai links would be + cpu/codec dais. + + type: object + + properties: + link-name: + description: Indicates dai-link name and PCM stream name. + $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 + + format: + description: audio format. + items: + enum: + - i2s + - dsp_b + + dai-tdm-slot-num: + description: see tdm-slot.txt. + $ref: /schemas/types.yaml#/definitions/uint32 + + dai-tdm-slot-width: + description: see tdm-slot.txt. + $ref: /schemas/types.yaml#/definitions/uint32 + + cpu: + description: Holds subnode which indicates cpu dai. + type: object + properties: + sound-dai: true + + codec: + description: Holds subnode which indicates codec dai. + type: object + properties: + sound-dai: true + + fsl,mclk-equal-bclk: + description: Indicates mclk can be equal to bclk, especially for sai interface + $ref: /schemas/types.yaml#/definitions/flag + + required: + - link-name + - cpu + + additionalProperties: false + +required: + - compatible + - model + +additionalProperties: false + +examples: + - | + sound-ak4458 { + compatible = "fsl,imx-audio-card"; + model = "ak4458-audio"; + pri-dai-link { + link-name = "akcodec"; + format = "i2s"; + fsl,mclk-equal-bclk; + cpu { + sound-dai = <&sai1>; + }; + codec { + sound-dai = <&ak4458_1>, <&ak4458_2>; + }; + }; + fe-dai-link { + link-name = "HiFi-ASRC-FE"; + format = "i2s"; + cpu { + sound-dai = <&easrc>; + }; + }; + be-dai-link { + link-name = "HiFi-ASRC-BE"; + format = "dsp_b"; + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + fsl,mclk-equal-bclk; + cpu { + sound-dai = <&sai1>; + }; + codec { + sound-dai = <&ak4458_1>, <&ak4458_2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/imx-audmux.txt b/Documentation/devicetree/bindings/sound/imx-audmux.txt deleted file mode 100644 index 2db4dcbee1b9..000000000000 --- a/Documentation/devicetree/bindings/sound/imx-audmux.txt +++ /dev/null @@ -1,28 +0,0 @@ -Freescale Digital Audio Mux (AUDMUX) device - -Required properties: - - - compatible : "fsl,imx21-audmux" for AUDMUX version firstly used - on i.MX21, or "fsl,imx31-audmux" for the version - firstly used on i.MX31. - - - reg : Should contain AUDMUX registers location and length. - -An initial configuration can be setup using child nodes. - -Required properties of optional child nodes: - - - fsl,audmux-port : Integer of the audmux port that is configured by this - child node. - - - fsl,port-config : List of configuration options for the specific port. - For imx31-audmux and above, it is a list of tuples - <ptcr pdcr>. For imx21-audmux it is a list of pcr - values. - -Example: - -audmux@21d8000 { - compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux"; - reg = <0x021d8000 0x4000>; -}; diff --git a/Documentation/devicetree/bindings/sound/imx-audmux.yaml b/Documentation/devicetree/bindings/sound/imx-audmux.yaml new file mode 100644 index 000000000000..dab45c310670 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/imx-audmux.yaml @@ -0,0 +1,119 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/imx-audmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Digital Audio Mux device + +maintainers: + - Oleksij Rempel <o.rempel@pengutronix.de> + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx27-audmux + - const: fsl,imx21-audmux + - items: + - enum: + - fsl,imx25-audmux + - fsl,imx35-audmux + - fsl,imx50-audmux + - fsl,imx51-audmux + - fsl,imx53-audmux + - fsl,imx6q-audmux + - fsl,imx6sl-audmux + - fsl,imx6sll-audmux + - fsl,imx6sx-audmux + - const: fsl,imx31-audmux + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: audmux + +patternProperties: + "^mux-[0-9a-z]*$": + type: object + properties: + fsl,audmux-port: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Integer of the audmux port that is configured by this child node + + fsl,port-config: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + List of configuration options for the specific port. + For imx31-audmux and above, it is a list of tuples ptcr pdcr. + For imx21-audmux it is a list of pcr values. + + required: + - fsl,audmux-port + - fsl,port-config + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + audmux@21d8000 { + compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux"; + reg = <0x021d8000 0x4000>; + }; + - | + audmux@10016000 { + compatible = "fsl,imx27-audmux", "fsl,imx21-audmux"; + reg = <0x10016000 0x1000>; + clocks = <&clks 1>; + clock-names = "audmux"; + + mux-ssi0 { + fsl,audmux-port = <0>; + fsl,port-config = <0xcb205000>; + }; + + mux-pins4 { + fsl,audmux-port = <2>; + fsl,port-config = <0x00001000>; + }; + }; + - | + #include <dt-bindings/sound/fsl-imx-audmux.h> + audmux@21d8000 { + compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux"; + reg = <0x021d8000 0x4000>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_audmux>; + + mux-ssi1 { + fsl,audmux-port = <0>; + fsl,port-config = < + IMX_AUDMUX_V2_PTCR_SYN 0 + IMX_AUDMUX_V2_PTCR_TFSEL(2) 0 + IMX_AUDMUX_V2_PTCR_TCSEL(2) 0 + IMX_AUDMUX_V2_PTCR_TFSDIR 0 + IMX_AUDMUX_V2_PTCR_TCLKDIR IMX_AUDMUX_V2_PDCR_RXDSEL(2) + >; + }; + + mux-pins3 { + fsl,audmux-port = <2>; + fsl,port-config = < + IMX_AUDMUX_V2_PTCR_SYN IMX_AUDMUX_V2_PDCR_RXDSEL(0) + 0 IMX_AUDMUX_V2_PDCR_TXRXEN + >; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml index 249970952202..5bdd30a8a404 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml @@ -28,7 +28,6 @@ properties: minItems: 2 clock-names: - minItems: 2 items: - const: pll_a - const: plla_out0 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml index 38e52e7dbb40..63370709c768 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml @@ -34,7 +34,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: I2S bit clock - description: @@ -48,7 +47,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: i2s - const: sync_input diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml new file mode 100644 index 000000000000..ffb8fcfeb629 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nxp,tfa989x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP/Goodix TFA989X (TFA1) Audio Amplifiers + +maintainers: + - Stephan Gerhold <stephan@gerhold.net> + +properties: + compatible: + enum: + - nxp,tfa9895 + - nxp,tfa9897 + + reg: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + + sound-name-prefix: + $ref: /schemas/types.yaml#/definitions/string + description: + Used as prefix for sink/source names of the component. Must be a + unique string among multiple instances of the same component. + + vddd-supply: + description: regulator phandle for the VDDD power supply. + +required: + - compatible + - reg + - '#sound-dai-cells' + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + audio-codec@34 { + compatible = "nxp,tfa9895"; + reg = <0x34>; + sound-name-prefix = "Speaker Left"; + #sound-dai-cells = <0>; + }; + audio-codec@36 { + compatible = "nxp,tfa9895"; + reg = <0x36>; + sound-name-prefix = "Speaker Right"; + #sound-dai-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml index e8f716b5f875..9b225dbf8b79 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml @@ -77,6 +77,31 @@ properties: minimum: 1800000 maximum: 2850000 + qcom,hphl-jack-type-normally-closed: + description: Indicates that HPHL jack switch type is normally closed + type: boolean + + qcom,ground-jack-type-normally-closed: + description: Indicates that Headset Ground switch type is normally closed + type: boolean + + qcom,mbhc-headset-vthreshold-microvolt: + description: Voltage threshold value for headset detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-headphone-vthreshold-microvolt: + description: Voltage threshold value for headphone detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-buttons-vthreshold-microvolt: + description: + Array of 8 Voltage threshold values corresponding to headset + button0 - button7 + minItems: 8 + maxItems: 8 + clock-output-names: const: mclk @@ -159,6 +184,11 @@ examples: qcom,micbias2-microvolt = <1800000>; qcom,micbias3-microvolt = <1800000>; qcom,micbias4-microvolt = <1800000>; + qcom,hphl-jack-type-normally-closed; + qcom,ground-jack-type-normally-closed; + qcom,mbhc-buttons-vthreshold-microvolt = <75000 150000 237000 500000 500000 500000 500000 500000>; + qcom,mbhc-headset-vthreshold-microvolt = <1700000>; + qcom,mbhc-headphone-vthreshold-microvolt = <50000>; clock-names = "extclk"; clocks = <&rpmhcc 2>; diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml new file mode 100644 index 000000000000..49a267b306f6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wcd938x-sdw.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for Qualcomm SoundWire Slave devices on WCD9380/WCD9385 + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + Qualcomm WCD9380/WCD9385 Codec is a standalone Hi-Fi audio codec IC. + It has RX and TX Soundwire slave devices. This bindings is for the + slave devices. + +properties: + compatible: + const: sdw20217010d00 + + reg: + maxItems: 1 + + qcom,tx-port-mapping: + description: | + Specifies static port mapping between slave and master tx ports. + In the order of slave port index. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 4 + maxItems: 4 + + qcom,rx-port-mapping: + description: | + Specifies static port mapping between slave and master rx ports. + In the order of slave port index. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 5 + maxItems: 5 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + soundwire@3210000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03210000 0x2000>; + wcd938x_rx: codec@0,4 { + compatible = "sdw20217010d00"; + reg = <0 4>; + qcom,rx-port-mapping = <1 2 3 4 5>; + }; + }; + + soundwire@3230000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03230000 0x2000>; + wcd938x_tx: codec@0,3 { + compatible = "sdw20217010d00"; + reg = <0 3>; + qcom,tx-port-mapping = <2 3 4 5>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml new file mode 100644 index 000000000000..cb74ce40c2e6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wcd938x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for Qualcomm WCD9380/WCD9385 Audio Codec + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + Qualcomm WCD9380/WCD9385 Codec is a standalone Hi-Fi audio codec IC. + It has RX and TX Soundwire slave devices. + +properties: + compatible: + enum: + - qcom,wcd9380-codec + - qcom,wcd9385-codec + + reset-gpios: + description: GPIO spec for reset line to use + maxItems: 1 + + vdd-buck-supply: + description: A reference to the 1.8V buck supply + + vdd-rxtx-supply: + description: A reference to the 1.8V rx supply + + vdd-io-supply: + description: A reference to the 1.8V I/O supply + + qcom,tx-device: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: A reference to Soundwire tx device phandle + + qcom,rx-device: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: A reference to Soundwire rx device phandle + + qcom,micbias1-microvolt: + description: micbias1 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,micbias2-microvolt: + description: micbias2 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,micbias3-microvolt: + description: micbias3 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,micbias4-microvolt: + description: micbias4 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,hphl-jack-type-normally-closed: + description: Indicates that HPHL jack switch type is normally closed + type: boolean + + qcom,ground-jack-type-normally-closed: + description: Indicates that Headset Ground switch type is normally closed + type: boolean + + qcom,mbhc-headset-vthreshold-microvolt: + description: Voltage threshold value for headset detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-headphone-vthreshold-microvolt: + description: Voltage threshold value for headphone detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-buttons-vthreshold-microvolt: + description: + Array of 8 Voltage threshold values corresponding to headset + button0 - button7 + minItems: 8 + maxItems: 8 + + '#sound-dai-cells': + const: 1 + +required: + - compatible + - reset-gpios + - qcom,tx-device + - qcom,rx-device + - qcom,micbias1-microvolt + - qcom,micbias2-microvolt + - qcom,micbias3-microvolt + - qcom,micbias4-microvolt + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + codec { + compatible = "qcom,wcd9380-codec"; + reset-gpios = <&tlmm 32 0>; + #sound-dai-cells = <1>; + qcom,tx-device = <&wcd938x_tx>; + qcom,rx-device = <&wcd938x_rx>; + qcom,micbias1-microvolt = <1800000>; + qcom,micbias2-microvolt = <1800000>; + qcom,micbias3-microvolt = <1800000>; + qcom,micbias4-microvolt = <1800000>; + qcom,hphl-jack-type-normally-closed; + qcom,ground-jack-type-normally-closed; + qcom,mbhc-buttons-vthreshold-microvolt = <75000 150000 237000 500000 500000 500000 500000 500000>; + qcom,mbhc-headphone-vthreshold-microvolt = <50000>; + }; + + /* ... */ + + soundwire@3210000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03210000 0x2000>; + wcd938x_rx: codec@0,4 { + compatible = "sdw20217010d00"; + reg = <0 4>; + qcom,rx-port-mapping = <1 2 3 4 5>; + }; + }; + + soundwire@3230000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03230000 0x2000>; + wcd938x_tx: codec@0,3 { + compatible = "sdw20217010d00"; + reg = <0 3>; + qcom,tx-port-mapping = <2 3 4 5>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 605de3a5847f..ee936d1aa724 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -86,9 +86,11 @@ properties: power-domains: true resets: + minItems: 1 maxItems: 11 reset-names: + minItems: 1 maxItems: 11 clocks: @@ -110,6 +112,13 @@ properties: - pattern: '^dvc\.[0-1]$' - pattern: '^clk_(a|b|c|i)$' + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port(@[0-9a-f]+)?: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + port: $ref: audio-graph-port.yaml# unevaluatedProperties: false @@ -257,7 +266,6 @@ required: - "#sound-dai-cells" allOf: - - $ref: audio-graph.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.yaml b/Documentation/devicetree/bindings/sound/sgtl5000.yaml index 70b4a8831073..e762c320b574 100644 --- a/Documentation/devicetree/bindings/sound/sgtl5000.yaml +++ b/Documentation/devicetree/bindings/sound/sgtl5000.yaml @@ -75,6 +75,10 @@ properties: $ref: "/schemas/types.yaml#/definitions/uint32" enum: [ 0, 1, 2, 3 ] + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index f2443b651282..06e83461705c 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -26,7 +26,6 @@ properties: - description: Base address and size of SAI common register set. - description: Base address and size of SAI identification register set. minItems: 1 - maxItems: 2 ranges: maxItems: 1 @@ -81,14 +80,12 @@ patternProperties: - description: sai_ck clock feeding the internal clock generator. - description: MCLK clock from a SAI set as master clock provider. minItems: 1 - maxItems: 2 clock-names: items: - const: sai_ck - const: MCLK minItems: 1 - maxItems: 2 dmas: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt index ca75890f0d07..f59125bc79d1 100644 --- a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt +++ b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt @@ -6,6 +6,7 @@ Required properties: - compatible - "string" - One of: "ti,tlv320aic32x4" TLV320AIC3204 "ti,tlv320aic32x6" TLV320AIC3206, TLV320AIC3256 + "ti,tas2505" TAS2505, TAS2521 - reg: I2C slave address - supply-*: Required supply regulators are: "iov" - digital IO power supply diff --git a/Documentation/devicetree/bindings/sound/wm8750.txt b/Documentation/devicetree/bindings/sound/wm8750.txt deleted file mode 100644 index 682f221f6f38..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8750.txt +++ /dev/null @@ -1,18 +0,0 @@ -WM8750 and WM8987 audio CODECs - -These devices support both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8750" or "wlf,wm8987" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Example: - -wm8750: codec@1a { - compatible = "wlf,wm8750"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8750.yaml b/Documentation/devicetree/bindings/sound/wm8750.yaml new file mode 100644 index 000000000000..24246ac7bbdf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wm8750.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/wm8750.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8750 and WM8987 audio CODECs + +description: | + These devices support both I2C and SPI (configured with pin strapping + on the board). + +maintainers: + - Mark Brown <broonie@kernel.org> + +properties: + compatible: + enum: + - wlf,wm8750 + - wlf,wm8987 + + reg: + description: + The I2C address of the device for I2C, the chip select number for SPI + maxItems: 1 + +additionalProperties: false + +required: + - reg + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + compatible = "wlf,wm8750"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml index e3fb553d9180..4d46c49ec32b 100644 --- a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml +++ b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml @@ -35,7 +35,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: controller register bus clock - description: baud rate generator and delay control clock diff --git a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml index 6ee19d49fd3c..ec5873919170 100644 --- a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml @@ -56,7 +56,6 @@ properties: reg-names: minItems: 1 - maxItems: 5 items: - const: mspi - const: bspi @@ -71,7 +70,6 @@ properties: interrupt-names: oneOf: - minItems: 1 - maxItems: 7 items: - const: mspi_done - const: mspi_halted diff --git a/Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt b/Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt deleted file mode 100644 index fb1a6728638d..000000000000 --- a/Documentation/devicetree/bindings/spi/renesas,rzn1-spi.txt +++ /dev/null @@ -1,11 +0,0 @@ -Renesas RZ/N1 SPI Controller - -This controller is based on the Synopsys DW Synchronous Serial Interface and -inherits all properties defined in snps,dw-apb-ssi.txt except for the -compatible property. - -Required properties: -- compatible : The device specific string followed by the generic RZ/N1 string. - Therefore it must be one of: - "renesas,r9a06g032-spi", "renesas,rzn1-spi" - "renesas,r9a06g033-spi", "renesas,rzn1-spi" diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml index 4825157cd92e..ca91201a9926 100644 --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml @@ -67,6 +67,12 @@ properties: const: baikal,bt1-sys-ssi - description: Canaan Kendryte K210 SoS SPI Controller const: canaan,k210-spi + - description: Renesas RZ/N1 SPI Controller + items: + - enum: + - renesas,r9a06g032-spi # RZ/N1D + - renesas,r9a06g033-spi # RZ/N1S + - const: renesas,rzn1-spi # RZ/N1 reg: minItems: 1 diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.txt b/Documentation/devicetree/bindings/spi/spi-cadence.txt deleted file mode 100644 index 05a2ef945664..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-cadence.txt +++ /dev/null @@ -1,30 +0,0 @@ -Cadence SPI controller Device Tree Bindings -------------------------------------------- - -Required properties: -- compatible : Should be "cdns,spi-r1p6" or "xlnx,zynq-spi-r1p6". -- reg : Physical base address and size of SPI registers map. -- interrupts : Property with a value describing the interrupt - number. -- clock-names : List of input clock names - "ref_clk", "pclk" - (See clock bindings for details). -- clocks : Clock phandles (see clock bindings for details). - -Optional properties: -- num-cs : Number of chip selects used. - If a decoder is used, this will be the number of - chip selects after the decoder. -- is-decoded-cs : Flag to indicate whether decoder is used or not. - -Example: - - spi@e0007000 { - compatible = "xlnx,zynq-spi-r1p6"; - clock-names = "ref_clk", "pclk"; - clocks = <&clkc 26>, <&clkc 35>; - interrupt-parent = <&intc>; - interrupts = <0 49 4>; - num-cs = <4>; - is-decoded-cs = <0>; - reg = <0xe0007000 0x1000>; - } ; diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.yaml b/Documentation/devicetree/bindings/spi/spi-cadence.yaml new file mode 100644 index 000000000000..9787be21318e --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-cadence.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-cadence.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence SPI controller Device Tree Bindings + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +allOf: + - $ref: "spi-controller.yaml#" + +properties: + compatible: + enum: + - cdns,spi-r1p6 + - xlnx,zynq-spi-r1p6 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-names: + items: + - const: ref_clk + - const: pclk + + clocks: + maxItems: 2 + + num-cs: + description: | + Number of chip selects used. If a decoder is used, + this will be the number of chip selects after the + decoder. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 4 + default: 4 + + is-decoded-cs: + description: | + Flag to indicate whether decoder is used or not. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1 ] + default: 0 + +unevaluatedProperties: false + +examples: + - | + spi@e0007000 { + compatible = "xlnx,zynq-spi-r1p6"; + clock-names = "ref_clk", "pclk"; + clocks = <&clkc 26>, <&clkc 35>; + interrupt-parent = <&intc>; + interrupts = <0 49 4>; + num-cs = <4>; + is-decoded-cs = <0>; + reg = <0xe0007000 0x1000>; + }; +... diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 0477396e4945..faef4f6f55b8 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -114,8 +114,11 @@ patternProperties: Compatible of the SPI device. reg: - minimum: 0 - maximum: 256 + minItems: 1 + maxItems: 256 + items: + minimum: 0 + maximum: 256 description: Chip select used by the device. diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt b/Documentation/devicetree/bindings/spi/spi-davinci.txt index e2198a389484..200c7fc7b089 100644 --- a/Documentation/devicetree/bindings/spi/spi-davinci.txt +++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt @@ -25,7 +25,7 @@ Required properties: - interrupts: interrupt number mapped to CPU. - clocks: spi clk phandle For 66AK2G this property should be set per binding, - Documentation/devicetree/bindings/clock/ti,sci-clk.txt + Documentation/devicetree/bindings/clock/ti,sci-clk.yaml SoC-specific Required Properties: diff --git a/Documentation/devicetree/bindings/spi/spi-mux.yaml b/Documentation/devicetree/bindings/spi/spi-mux.yaml index d09c6355e22d..51c7622dc20b 100644 --- a/Documentation/devicetree/bindings/spi/spi-mux.yaml +++ b/Documentation/devicetree/bindings/spi/spi-mux.yaml @@ -72,7 +72,7 @@ examples: mux-controls = <&mux>; - spi-flash@0 { + flash@0 { compatible = "jedec,spi-nor"; reg = <0>; spi-max-frequency = <40000000>; diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml index 1e6cf29e6388..7f987e79337c 100644 --- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml +++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml @@ -33,6 +33,7 @@ properties: - rockchip,rk3328-spi - rockchip,rk3368-spi - rockchip,rk3399-spi + - rockchip,rv1126-spi - const: rockchip,rk3066-spi reg: diff --git a/Documentation/devicetree/bindings/spi/spi-xilinx.txt b/Documentation/devicetree/bindings/spi/spi-xilinx.txt deleted file mode 100644 index 5f4ed3e5c994..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-xilinx.txt +++ /dev/null @@ -1,23 +0,0 @@ -Xilinx SPI controller Device Tree Bindings -------------------------------------------------- - -Required properties: -- compatible : Should be "xlnx,xps-spi-2.00.a", "xlnx,xps-spi-2.00.b" or "xlnx,axi-quad-spi-1.00.a" -- reg : Physical base address and size of SPI registers map. -- interrupts : Property with a value describing the interrupt - number. - -Optional properties: -- xlnx,num-ss-bits : Number of chip selects used. -- xlnx,num-transfer-bits : Number of bits per transfer. This will be 8 if not specified - -Example: - axi_quad_spi@41e00000 { - compatible = "xlnx,xps-spi-2.00.a"; - interrupt-parent = <&intc>; - interrupts = <0 31 1>; - reg = <0x41e00000 0x10000>; - xlnx,num-ss-bits = <0x1>; - xlnx,num-transfer-bits = <32>; - }; - diff --git a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml new file mode 100644 index 000000000000..593f7693bace --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-xilinx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx SPI controller Device Tree Bindings + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +allOf: + - $ref: "spi-controller.yaml#" + +properties: + compatible: + enum: + - xlnx,xps-spi-2.00.a + - xlnx,xps-spi-2.00.b + - xlnx,axi-quad-spi-1.00.a + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + xlnx,num-ss-bits: + description: Number of chip selects used. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 32 + + xlnx,num-transfer-bits: + description: Number of bits per transfer. This will be 8 if not specified. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16, 32] + default: 8 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + spi0: spi@41e00000 { + compatible = "xlnx,xps-spi-2.00.a"; + interrupt-parent = <&intc>; + interrupts = <0 31 1>; + reg = <0x41e00000 0x10000>; + xlnx,num-ss-bits = <0x1>; + xlnx,num-transfer-bits = <32>; + }; +... diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt deleted file mode 100644 index 0f6d37ff541c..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt +++ /dev/null @@ -1,25 +0,0 @@ -Xilinx Zynq UltraScale+ MPSoC GQSPI controller Device Tree Bindings -------------------------------------------------------------------- - -Required properties: -- compatible : Should be "xlnx,zynqmp-qspi-1.0". -- reg : Physical base address and size of GQSPI registers map. -- interrupts : Property with a value describing the interrupt - number. -- clock-names : List of input clock names - "ref_clk", "pclk" - (See clock bindings for details). -- clocks : Clock phandles (see clock bindings for details). - -Optional properties: -- num-cs : Number of chip selects used. - -Example: - qspi: spi@ff0f0000 { - compatible = "xlnx,zynqmp-qspi-1.0"; - clock-names = "ref_clk", "pclk"; - clocks = <&misc_clk &misc_clk>; - interrupts = <0 15 4>; - interrupt-parent = <&gic>; - num-cs = <1>; - reg = <0x0 0xff0f0000 0x1000>,<0x0 0xc0000000 0x8000000>; - }; diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml new file mode 100644 index 000000000000..ea72c8001256 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-zynqmp-qspi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq UltraScale+ MPSoC GQSPI controller Device Tree Bindings + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +allOf: + - $ref: "spi-controller.yaml#" + +properties: + compatible: + const: xlnx,zynqmp-qspi-1.0 + + reg: + maxItems: 2 + + interrupts: + maxItems: 1 + + clock-names: + items: + - const: ref_clk + - const: pclk + + clocks: + maxItems: 2 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/xlnx-zynqmp-clk.h> + soc { + #address-cells = <2>; + #size-cells = <2>; + + qspi: spi@ff0f0000 { + compatible = "xlnx,zynqmp-qspi-1.0"; + clocks = <&zynqmp_clk QSPI_REF>, <&zynqmp_clk LPD_LSBUS>; + clock-names = "ref_clk", "pclk"; + interrupts = <0 15 4>; + interrupt-parent = <&gic>; + reg = <0x0 0xff0f0000 0x0 0x1000>, + <0x0 0xc0000000 0x0 0x8000000>; + }; + }; diff --git a/Documentation/devicetree/bindings/spmi/spmi.yaml b/Documentation/devicetree/bindings/spmi/spmi.yaml index 173940930719..1d243faef2f8 100644 --- a/Documentation/devicetree/bindings/spmi/spmi.yaml +++ b/Documentation/devicetree/bindings/spmi/spmi.yaml @@ -40,14 +40,15 @@ patternProperties: properties: reg: - minItems: 1 - maxItems: 2 items: - - minimum: 0 - maximum: 0xf - - enum: [ 0 ] - description: | - 0 means user ID address. 1 is reserved for group ID address. + - minItems: 1 + items: + - minimum: 0 + maximum: 0xf + - enum: [ 0 ] + description: + 0 means user ID address. 1 is reserved for group ID + address. required: - reg diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index c1a5afa73cfe..3eda5049d183 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -28,6 +28,8 @@ properties: contains: enum: - mmio-sram + - amlogic,meson-gxbb-sram + - arm,juno-sram-ns - atmel,sama5d2-securam - rockchip,rk3288-pmu-sram @@ -80,6 +82,9 @@ patternProperties: - amlogic,meson8b-smp-sram - amlogic,meson-gxbb-scp-shmem - amlogic,meson-axg-scp-shmem + - arm,juno-scp-shmem + - arm,scmi-shmem + - arm,scp-shmem - renesas,smp-sram - rockchip,rk3066-smp-sram - samsung,exynos4210-sysram diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst index 104fa8fb2c17..8087780f1685 100644 --- a/Documentation/devicetree/bindings/submitting-patches.rst +++ b/Documentation/devicetree/bindings/submitting-patches.rst @@ -7,8 +7,8 @@ Submitting Devicetree (DT) binding patches I. For patch submitters ======================= - 0) Normal patch submission rules from Documentation/process/submitting-patches.rst - applies. + 0) Normal patch submission rules from + Documentation/process/submitting-patches.rst applies. 1) The Documentation/ and include/dt-bindings/ portion of the patch should be a separate patch. The preferred subject prefix for binding patches is:: @@ -25,8 +25,8 @@ I. For patch submitters make dt_binding_check - See Documentation/devicetree/bindings/writing-schema.rst for more details about - schema and tools setup. + See Documentation/devicetree/bindings/writing-schema.rst for more details + about schema and tools setup. 3) DT binding files should be dual licensed. The preferred license tag is (GPL-2.0-only OR BSD-2-Clause). @@ -84,7 +84,8 @@ II. For kernel maintainers III. Notes ========== - 0) Please see :doc:`ABI` for details regarding devicetree ABI. + 0) Please see Documentation/devicetree/bindings/ABI.rst for details + regarding devicetree ABI. 1) This document is intended as a general familiarization with the process as decided at the 2013 Kernel Summit. When in doubt, the current word of the diff --git a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml index bf97d1fb33e7..6e0b110153b0 100644 --- a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml +++ b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml @@ -23,14 +23,12 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Bus Clock - description: Module Clock clock-names: minItems: 1 - maxItems: 2 items: - const: bus - const: mod diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 0242fd91b622..0b3b6af7bd5b 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -77,7 +77,6 @@ properties: nvmem-cell-names: minItems: 1 - maxItems: 2 items: - const: calib - enum: diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml index b6a6d03a08b2..2ecac754e1cd 100644 --- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml +++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml @@ -24,7 +24,6 @@ properties: interrupts: minItems: 2 - maxItems: 4 items: - description: Timer 0 Interrupt - description: Timer 1 Interrupt diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml index 7f5e3af58255..df8ce87fd54b 100644 --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml @@ -35,7 +35,6 @@ properties: interrupts: minItems: 1 - maxItems: 5 items: - description: secure timer irq - description: non-secure timer irq diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml index d83a1f97f911..cd2176cad53a 100644 --- a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml @@ -71,14 +71,12 @@ patternProperties: interrupts: minItems: 1 - maxItems: 2 items: - description: physical timer irq - description: virtual timer irq reg: minItems: 1 - maxItems: 2 items: - description: 1st view base address - description: 2nd optional view base address diff --git a/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml new file mode 100644 index 000000000000..5684df6448ef --- /dev/null +++ b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/arm,twd-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Timer-Watchdog Timer + +maintainers: + - Rob Herring <robh@kernel.org> + +description: + ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core + Timer-Watchdog (aka TWD), which provides both a per-cpu local timer + and watchdog. + + The TWD is usually attached to a GIC to deliver its two per-processor + interrupts. + +properties: + compatible: + enum: + - arm,cortex-a9-twd-timer + - arm,cortex-a5-twd-timer + - arm,arm11mp-twd-timer + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + always-on: + description: + If present, the timer is powered through an always-on power domain, + therefore it never loses context. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + timer@2c000600 { + compatible = "arm,arm11mp-twd-timer"; + reg = <0x2c000600 0x20>; + interrupts = <GIC_PPI 13 0xf01>; + }; diff --git a/Documentation/devicetree/bindings/timer/arm,twd.txt b/Documentation/devicetree/bindings/timer/arm,twd.txt deleted file mode 100644 index 383ea19c2bf0..000000000000 --- a/Documentation/devicetree/bindings/timer/arm,twd.txt +++ /dev/null @@ -1,53 +0,0 @@ -* ARM Timer Watchdog - -ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core -Timer-Watchdog (aka TWD), which provides both a per-cpu local timer -and watchdog. - -The TWD is usually attached to a GIC to deliver its two per-processor -interrupts. - -** Timer node required properties: - -- compatible : Should be one of: - "arm,cortex-a9-twd-timer" - "arm,cortex-a5-twd-timer" - "arm,arm11mp-twd-timer" - -- interrupts : One interrupt to each core - -- reg : Specify the base address and the size of the TWD timer - register window. - -Optional - -- always-on : a boolean property. If present, the timer is powered through - an always-on power domain, therefore it never loses context. - -Example: - - twd-timer@2c000600 { - compatible = "arm,arm11mp-twd-timer""; - reg = <0x2c000600 0x20>; - interrupts = <1 13 0xf01>; - }; - -** Watchdog node properties: - -- compatible : Should be one of: - "arm,cortex-a9-twd-wdt" - "arm,cortex-a5-twd-wdt" - "arm,arm11mp-twd-wdt" - -- interrupts : One interrupt to each core - -- reg : Specify the base address and the size of the TWD watchdog - register window. - -Example: - - twd-watchdog@2c000620 { - compatible = "arm,arm11mp-twd-wdt"; - reg = <0x2c000620 0x20>; - interrupts = <1 14 0xf01>; - }; diff --git a/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml index a8de99b0c0f9..f32575d4b5aa 100644 --- a/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml +++ b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml @@ -22,7 +22,6 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: Timer 1 interrupt - description: Timer 2 interrupt diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml index f0f0f121c355..c57169118b68 100644 --- a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml @@ -36,6 +36,7 @@ properties: - renesas,tmu-r8a77980 # R-Car V3H - renesas,tmu-r8a77990 # R-Car E3 - renesas,tmu-r8a77995 # R-Car D3 + - renesas,tmu-r8a779a0 # R-Car V3U - const: renesas,tmu reg: diff --git a/Documentation/devicetree/bindings/timer/renesas,tpu.txt b/Documentation/devicetree/bindings/timer/renesas,tpu.txt deleted file mode 100644 index 1d46f9de4feb..000000000000 --- a/Documentation/devicetree/bindings/timer/renesas,tpu.txt +++ /dev/null @@ -1,21 +0,0 @@ -* Renesas H8/300 Timer Pulse Unit - -The TPU is a 16bit timer/counter with configurable clock inputs and -programmable compare match. -This implementation support only cascade mode. - -Required Properties: - - - compatible: must contain "renesas,tpu" - - reg: base address and length of the registers block in 2 channel. - - clocks: a list of phandle, one for each entry in clock-names. - - clock-names: must contain "peripheral_clk" for the functional clock. - - -Example: - tpu: tpu@ffffe0 { - compatible = "renesas,tpu"; - reg = <0xffffe0 16>, <0xfffff0 12>; - clocks = <&pclk>; - clock-names = "peripheral_clk"; - }; diff --git a/Documentation/devicetree/bindings/timer/renesas,tpu.yaml b/Documentation/devicetree/bindings/timer/renesas,tpu.yaml new file mode 100644 index 000000000000..01554dff23d8 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,tpu.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/renesas,tpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas H8/300 Timer Pulse Unit + +maintainers: + - Yoshinori Sato <ysato@users.sourceforge.jp> + +description: + The TPU is a 16bit timer/counter with configurable clock inputs and + programmable compare match. + This implementation supports only cascade mode. + +select: + properties: + compatible: + contains: + const: renesas,tpu + '#pwm-cells': false + required: + - compatible + +properties: + compatible: + const: renesas,tpu + + reg: + items: + - description: First channel + - description: Second channel + + clocks: + maxItems: 1 + + clock-names: + const: fck + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + tpu: tpu@ffffe0 { + compatible = "renesas,tpu"; + reg = <0xffffe0 16>, <0xfffff0 12>; + clocks = <&pclk>; + clock-names = "fck"; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 8341e9d23c1e..a3edbd2bcd15 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -73,6 +73,8 @@ properties: - dallas,ds4510 # Digital Thermometer and Thermostat - dallas,ds75 + # Delta Electronics DPS920AB 920W 54V Power Supply + - delta,dps920ab # 1/4 Brick DC/DC Regulated Power Module - delta,q54sj108a2 # Devantech SRF02 ultrasonic ranger in I2C mode @@ -103,6 +105,8 @@ properties: - fsl,mpl3115 # MPR121: Proximity Capacitive Touch Sensor Controller - fsl,mpr121 + # Monolithic Power Systems Inc. multi-phase controller mp2888 + - mps,mp2888 # Monolithic Power Systems Inc. multi-phase controller mp2975 - mps,mp2975 # G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface @@ -268,6 +272,8 @@ properties: # Socionext SynQuacer TPM MMIO module - socionext,synquacer-tpm-mmio # i2c serial eeprom (24cxx) + - sparkfun,qwiic-joystick + # SparkFun Qwiic Joystick (COM-15168) with i2c interface - st,24c256 # Ambient Light Sensor with SMBUS/Two Wire Serial Interface - taos,tsl2550 diff --git a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml index a407e1143cf4..8dedfa16c992 100644 --- a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml +++ b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml @@ -28,9 +28,9 @@ properties: interrupts: minItems: 3 items: - - description: OTG/DRD controller interrupt - description: XHCI host controller interrupt - description: Device controller interrupt + - description: OTG/DRD controller interrupt - description: interrupt used to wake up core, e.g when usbcmd.rs is cleared by xhci core, this interrupt is optional diff --git a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml index 4241d38d5864..1d893d3d3432 100644 --- a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml +++ b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml @@ -30,14 +30,12 @@ properties: - description: usb irq from max3420 - description: vbus detection irq minItems: 1 - maxItems: 2 interrupt-names: items: - const: udc - const: vbus minItems: 1 - maxItems: 2 spi-max-frequency: maximum: 26000000 diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml index e60e590dbe12..8428415896ce 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml @@ -25,7 +25,6 @@ properties: reg: minItems: 2 - maxItems: 3 items: - description: XUSB device controller registers - description: XUSB device PCI Config registers @@ -33,7 +32,6 @@ properties: reg-names: minItems: 2 - maxItems: 3 items: - const: base - const: fpci @@ -45,7 +43,6 @@ properties: clocks: minItems: 4 - maxItems: 5 items: - description: Clock to enable core XUSB dev clock. - description: Clock to enable XUSB super speed clock. @@ -55,7 +52,6 @@ properties: clock-names: minItems: 4 - maxItems: 5 items: - const: dev - const: ss diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index e67223d90bb7..ad73339ffe1d 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml @@ -53,7 +53,6 @@ properties: clocks: minItems: 1 - maxItems: 3 items: - description: USB 2.0 host - description: USB 2.0 peripheral @@ -86,7 +85,6 @@ properties: dma-names: minItems: 2 - maxItems: 4 items: - const: ch0 - const: ch1 @@ -100,7 +98,6 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: USB 2.0 host - description: USB 2.0 peripheral diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index 7ec87a783c5c..a634774c537c 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml @@ -27,7 +27,7 @@ properties: description: PM domain provider node and an args specifier containing the USB device id value. See, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml maxItems: 1 clocks: diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml index 9a068d3bc73b..f6e91a5fd8fe 100644 --- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml @@ -47,7 +47,7 @@ properties: description: Should contain a phandle to a PM domain provider node and an args specifier containing the USB device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml phys: maxItems: 1 diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b868cefc7c55..2bbc27aae977 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -472,7 +472,7 @@ patternProperties: "^hirschmann,.*": description: Hirschmann Automation and Control GmbH "^hisilicon,.*": - description: Hisilicon Limited. + description: HiSilicon Limited. "^hit,.*": description: Hitachi Ltd. "^hitex,.*": @@ -533,6 +533,8 @@ patternProperties: description: Innolux Corporation "^inside-secure,.*": description: INSIDE Secure + "^insignal,.*": + description: Insignal Ltd. "^inspur,.*": description: Inspur Corporation "^intel,.*": @@ -830,6 +832,8 @@ patternProperties: description: Opal Kelly Incorporated "^opencores,.*": description: OpenCores.org + "^openembed,.*": + description: OpenEmbed "^openrisc,.*": description: OpenRISC.io "^option,.*": @@ -1076,6 +1080,8 @@ patternProperties: description: Sony Corporation "^spansion,.*": description: Spansion Inc. + "^sparkfun,.*": + description: SparkFun Electronics "^sprd,.*": description: Spreadtrum Communications Inc. "^sst,.*": @@ -1085,6 +1091,8 @@ patternProperties: (formerly part of MStar Semiconductor, Inc.) "^st,.*": description: STMicroelectronics + "^starfive,.*": + description: StarFive Technology Co. Ltd. "^starry,.*": description: Starry Electronic Technology (ShenZhen) Co., LTD "^startek,.*": diff --git a/Documentation/devicetree/bindings/virtio/mmio.txt b/Documentation/devicetree/bindings/virtio/mmio.txt deleted file mode 100644 index 0a575f329f6e..000000000000 --- a/Documentation/devicetree/bindings/virtio/mmio.txt +++ /dev/null @@ -1,47 +0,0 @@ -* virtio memory mapped device - -See https://ozlabs.org/~rusty/virtio-spec/ for more details. - -Required properties: - -- compatible: "virtio,mmio" compatibility string -- reg: control registers base address and size including configuration space -- interrupts: interrupt generated by the device - -Required properties for virtio-iommu: - -- #iommu-cells: When the node corresponds to a virtio-iommu device, it is - linked to DMA masters using the "iommus" or "iommu-map" - properties [1][2]. #iommu-cells specifies the size of the - "iommus" property. For virtio-iommu #iommu-cells must be - 1, each cell describing a single endpoint ID. - -Optional properties: - -- iommus: If the device accesses memory through an IOMMU, it should - have an "iommus" property [1]. Since virtio-iommu itself - does not access memory through an IOMMU, the "virtio,mmio" - node cannot have both an "#iommu-cells" and an "iommus" - property. - -Example: - - virtio_block@3000 { - compatible = "virtio,mmio"; - reg = <0x3000 0x100>; - interrupts = <41>; - - /* Device has endpoint ID 23 */ - iommus = <&viommu 23> - } - - viommu: iommu@3100 { - compatible = "virtio,mmio"; - reg = <0x3100 0x100>; - interrupts = <42>; - - #iommu-cells = <1> - } - -[1] Documentation/devicetree/bindings/iommu/iommu.txt -[2] Documentation/devicetree/bindings/pci/pci-iommu.txt diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml b/Documentation/devicetree/bindings/virtio/mmio.yaml new file mode 100644 index 000000000000..d46597028cf1 --- /dev/null +++ b/Documentation/devicetree/bindings/virtio/mmio.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/virtio/mmio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: virtio memory mapped devices + +maintainers: + - Jean-Philippe Brucker <jean-philippe@linaro.org> + +description: + See https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio for + more details. + +properties: + compatible: + const: virtio,mmio + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#iommu-cells': + description: Required when the node corresponds to a virtio-iommu device. + const: 1 + + iommus: + description: Required for devices making accesses thru an IOMMU. + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + virtio@3000 { + compatible = "virtio,mmio"; + reg = <0x3000 0x100>; + interrupts = <41>; + + /* Device has endpoint ID 23 */ + iommus = <&viommu 23>; + }; + + viommu: iommu@3100 { + compatible = "virtio,mmio"; + reg = <0x3100 0x100>; + interrupts = <42>; + + #iommu-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml b/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml new file mode 100644 index 000000000000..6bfa46353c4e --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/arm,sbsa-gwdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SBSA (Server Base System Architecture) Generic Watchdog + +maintainers: + - Fu Wei <fu.wei@linaro.org> + +description: | + The SBSA Generic Watchdog Timer is used to force a reset of the system after + two stages of timeout have elapsed. A detailed definition of the watchdog + timer can be found in the ARM document: ARM-DEN-0029 - Server Base System + Architecture (SBSA) + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + const: arm,sbsa-gwdt + + reg: + items: + - description: Watchdog control frame + - description: Refresh frame + + interrupts: + description: The Watchdog Signal 0 (WS0) SPI (Shared Peripheral Interrupt) + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + + watchdog@2a440000 { + compatible = "arm,sbsa-gwdt"; + reg = <0x2a440000 0x1000>, + <0x2a450000 0x1000>; + interrupts = <0 27 4>; + timeout-sec = <30>; + }; +... diff --git a/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml b/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml new file mode 100644 index 000000000000..bb8901854222 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/arm,twd-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Timer-Watchdog Watchdog + +maintainers: + - Rob Herring <robh@kernel.org> + +description: + ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core + Timer-Watchdog (aka TWD), which provides both a per-cpu local timer + and watchdog. + + The TWD is usually attached to a GIC to deliver its two per-processor + interrupts. + +properties: + compatible: + enum: + - arm,cortex-a9-twd-wdt + - arm,cortex-a5-twd-wdt + - arm,arm11mp-twd-wdt + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + watchdog@2c000620 { + compatible = "arm,arm11mp-twd-wdt"; + reg = <0x2c000620 0x20>; + interrupts = <GIC_PPI 14 0xf01>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt deleted file mode 100644 index 6f2d5f91964d..000000000000 --- a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt +++ /dev/null @@ -1,31 +0,0 @@ -* SBSA (Server Base System Architecture) Generic Watchdog - -The SBSA Generic Watchdog Timer is used to force a reset of the system -after two stages of timeout have elapsed. A detailed definition of the -watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server -Base System Architecture (SBSA) - -Required properties: -- compatible: Should at least contain "arm,sbsa-gwdt". - -- reg: Each entry specifies the base physical address of a register frame - and the length of that frame; currently, two frames must be defined, - in this order: - 1: Watchdog control frame; - 2: Refresh frame. - -- interrupts: Should contain the Watchdog Signal 0 (WS0) SPI (Shared - Peripheral Interrupt) number of SBSA Generic Watchdog. - -Optional properties -- timeout-sec: Watchdog timeout values (in seconds). - -Example for FVP Foundation Model v8: - -watchdog@2a440000 { - compatible = "arm,sbsa-gwdt"; - reg = <0x0 0x2a440000 0 0x1000>, - <0x0 0x2a450000 0 0x1000>; - interrupts = <0 27 4>; - timeout-sec = <30>; -}; diff --git a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml index 3f1ba1d6c6b5..481bf91f988a 100644 --- a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml +++ b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml @@ -27,7 +27,6 @@ properties: - description: Low speed clock - description: Optional peripheral clock minItems: 1 - maxItems: 2 clock-names: items: diff --git a/Documentation/devicetree/bindings/writing-bindings.rst b/Documentation/devicetree/bindings/writing-bindings.rst index 45ff426d0019..f7dfb98c156e 100644 --- a/Documentation/devicetree/bindings/writing-bindings.rst +++ b/Documentation/devicetree/bindings/writing-bindings.rst @@ -52,7 +52,8 @@ Properties constraints specific to the device. - DO use common property unit suffixes for properties with scientific units. - See property-units.txt. + Recommended suffixes are listed at + https://github.com/devicetree-org/dt-schema/blob/master/schemas/property-units.yaml - DO define properties in terms of constraints. How many entries? What are possible values? What is the order? diff --git a/Documentation/doc-guide/contributing.rst b/Documentation/doc-guide/contributing.rst index 67ee3691f91f..207fd93d7c80 100644 --- a/Documentation/doc-guide/contributing.rst +++ b/Documentation/doc-guide/contributing.rst @@ -237,10 +237,10 @@ We have been trying to improve the situation through the creation of a set of "books" that group documentation for specific readers. These include: - - :doc:`../admin-guide/index` - - :doc:`../core-api/index` - - :doc:`../driver-api/index` - - :doc:`../userspace-api/index` + - Documentation/admin-guide/index.rst + - Documentation/core-api/index.rst + - Documentation/driver-api/index.rst + - Documentation/userspace-api/index.rst As well as this book on documentation itself. diff --git a/Documentation/driver-api/acpi/linuxized-acpica.rst b/Documentation/driver-api/acpi/linuxized-acpica.rst index 6bee03383225..cc234353d2c4 100644 --- a/Documentation/driver-api/acpi/linuxized-acpica.rst +++ b/Documentation/driver-api/acpi/linuxized-acpica.rst @@ -276,4 +276,4 @@ before they become available from the ACPICA release process. # git clone https://github.com/acpica/acpica # git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git # cd acpica - # generate/linux/divergences.sh -s ../linux + # generate/linux/divergence.sh -s ../linux diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index 1bad466f9167..487ce4f41d77 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -22,16 +22,22 @@ This section covers the driver infrastructure for a CXL memory device. CXL Memory Device ----------------- -.. kernel-doc:: drivers/cxl/mem.c - :doc: cxl mem +.. kernel-doc:: drivers/cxl/pci.c + :doc: cxl pci -.. kernel-doc:: drivers/cxl/mem.c +.. kernel-doc:: drivers/cxl/pci.c :internal: -CXL Bus -------- -.. kernel-doc:: drivers/cxl/bus.c - :doc: cxl bus +CXL Core +-------- +.. kernel-doc:: drivers/cxl/cxl.h + :doc: cxl objects + +.. kernel-doc:: drivers/cxl/cxl.h + :internal: + +.. kernel-doc:: drivers/cxl/core.c + :doc: cxl core External Interfaces =================== diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 7f37ec30d9fd..7f21425d9435 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -178,6 +178,15 @@ DMA Fence Array .. kernel-doc:: include/linux/dma-fence-array.h :internal: +DMA Fence Chain +~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence-chain.c + :export: + +.. kernel-doc:: include/linux/dma-fence-chain.h + :internal: + DMA Fence uABI/Sync File ~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/driver-api/gpio/using-gpio.rst b/Documentation/driver-api/gpio/using-gpio.rst index dda069444032..64c8d3f76c3a 100644 --- a/Documentation/driver-api/gpio/using-gpio.rst +++ b/Documentation/driver-api/gpio/using-gpio.rst @@ -9,13 +9,13 @@ with them. For examples of already existing generic drivers that will also be good examples for any other kernel drivers you want to author, refer to -:doc:`drivers-on-gpio` +Documentation/driver-api/gpio/drivers-on-gpio.rst For any kind of mass produced system you want to support, such as servers, laptops, phones, tablets, routers, and any consumer or office or business goods using appropriate kernel drivers is paramount. Submit your code for inclusion in the upstream Linux kernel when you feel it is mature enough and you will get -help to refine it, see :doc:`../../process/submitting-patches`. +help to refine it, see Documentation/process/submitting-patches.rst. In Linux GPIO lines also have a userspace ABI. diff --git a/Documentation/driver-api/ioctl.rst b/Documentation/driver-api/ioctl.rst index c455db0e1627..35795f6a151a 100644 --- a/Documentation/driver-api/ioctl.rst +++ b/Documentation/driver-api/ioctl.rst @@ -25,16 +25,16 @@ ioctl commands that follow modern conventions: ``_IO``, ``_IOR``, with the correct parameters: _IO/_IOR/_IOW/_IOWR - The macro name specifies how the argument will be used. It may be a + The macro name specifies how the argument will be used. It may be a pointer to data to be passed into the kernel (_IOW), out of the kernel - (_IOR), or both (_IOWR). _IO can indicate either commands with no + (_IOR), or both (_IOWR). _IO can indicate either commands with no argument or those passing an integer value instead of a pointer. It is recommended to only use _IO for commands without arguments, and use pointers for passing data. type An 8-bit number, often a character literal, specific to a subsystem - or driver, and listed in :doc:`../userspace-api/ioctl/ioctl-number` + or driver, and listed in Documentation/userspace-api/ioctl/ioctl-number.rst nr An 8-bit number identifying the specific command, unique for a give @@ -200,10 +200,10 @@ cause an information leak, which can be used to defeat kernel address space layout randomization (KASLR), helping in an attack. For this reason (and for compat support) it is best to avoid any -implicit padding in data structures. Where there is implicit padding +implicit padding in data structures. Where there is implicit padding in an existing structure, kernel drivers must be careful to fully initialize an instance of the structure before copying it to user -space. This is usually done by calling memset() before assigning to +space. This is usually done by calling memset() before assigning to individual members. Subsystem abstractions diff --git a/Documentation/driver-api/media/drivers/bttv-devel.rst b/Documentation/driver-api/media/drivers/bttv-devel.rst index c9aa8b95a5e5..0885a04563a9 100644 --- a/Documentation/driver-api/media/drivers/bttv-devel.rst +++ b/Documentation/driver-api/media/drivers/bttv-devel.rst @@ -21,7 +21,7 @@ log, telling which card type is used. Like this one:: You should verify this is correct. If it isn't, you have to pass the correct board type as insmod argument, ``insmod bttv card=2`` for -example. The file :doc:`/admin-guide/media/bttv-cardlist` has a list +example. The file Documentation/admin-guide/media/bttv-cardlist.rst has a list of valid arguments for card. If your card isn't listed there, you might check the source code for diff --git a/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc b/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc index f2042acc8a45..bbf9213c3388 100644 --- a/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc +++ b/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc @@ -210,7 +210,7 @@ pll_multiplier 0x0306 16 op_pix_clk_div 0x0308 16 op_sys_clk_div 0x030a 16 op_pre_pll_clk_div 0x030c 16 -op_pll_multiplier 0x031e 16 +op_pll_multiplier 0x030e 16 pll_mode 0x0310 8 - f 0 0 - e single 0 diff --git a/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs b/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs index 6668deaf2f19..2a4edc7e051a 100755 --- a/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs +++ b/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs @@ -72,13 +72,14 @@ $uc_header =~ s/[^A-Z0-9]/_/g; my $copyright = "/* Copyright (C) 2019--2020 Intel Corporation */\n"; my $license = "SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause"; +my $note = "/*\n * Generated by $0;\n * do not modify.\n */\n"; for my $fh ($A, $LC) { - print $fh "// $license\n$copyright\n" if defined $fh; + print $fh "// $license\n$copyright$note\n" if defined $fh; } for my $fh ($H, $LH) { - print $fh "/* $license */\n$copyright\n"; + print $fh "/* $license */\n$copyright$note\n"; } sub bit_def($) { diff --git a/Documentation/driver-api/media/drivers/zoran.rst b/Documentation/driver-api/media/drivers/zoran.rst index 83cbae9cedef..b205e10c3154 100644 --- a/Documentation/driver-api/media/drivers/zoran.rst +++ b/Documentation/driver-api/media/drivers/zoran.rst @@ -319,7 +319,7 @@ Conexant bt866 TV encoder ~~~~~~~~~~~~~~~~~~~~~~~~~ - is used in AVS6EYES, and -- can generate: NTSC/PAL, PALM, PALN +- can generate: NTSC/PAL, PAL-M, PAL-N The adv717x, should be able to produce PAL N. But you find nothing PAL N specific in the registers. Seem that you have to reuse a other standard diff --git a/Documentation/driver-api/media/index.rst b/Documentation/driver-api/media/index.rst index 2ad71dfa8828..813d7db59da7 100644 --- a/Documentation/driver-api/media/index.rst +++ b/Documentation/driver-api/media/index.rst @@ -11,11 +11,13 @@ its supported drivers. Please see: -- :doc:`/admin-guide/media/index` - for usage information about media subsystem and supported drivers; +Documentation/admin-guide/media/index.rst -- :doc:`/userspace-api/media/index` - for the userspace APIs used on media devices. + - for usage information about media subsystem and supported drivers; + +Documentation/userspace-api/media/index.rst + + - for the userspace APIs used on media devices. .. only:: html diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst index ef6d59e0978e..1d8302b89bd4 100644 --- a/Documentation/driver-api/nvdimm/nvdimm.rst +++ b/Documentation/driver-api/nvdimm/nvdimm.rst @@ -4,7 +4,7 @@ LIBNVDIMM: Non-Volatile Devices libnvdimm - kernel / libndctl - userspace helper library -linux-nvdimm@lists.01.org +nvdimm@lists.linux.dev Version 13 diff --git a/Documentation/driver-api/pin-control.rst b/Documentation/driver-api/pin-control.rst index e2474425fb0c..71eefe5a023f 100644 --- a/Documentation/driver-api/pin-control.rst +++ b/Documentation/driver-api/pin-control.rst @@ -95,7 +95,7 @@ this in our driver:: To enable the pinctrl subsystem and the subgroups for PINMUX and PINCONF and selected drivers, you need to select them from your machine's Kconfig entry, since these are so tightly integrated with the machines they are used on. -See for example arch/arm/mach-u300/Kconfig for an example. +See for example arch/arm/mach-ux500/Kconfig for an example. Pins usually have fancier names than this. You can find these in the datasheet for your chip. Notice that the core pinctrl.h file provides a fancy macro diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index 6b3bfd29fd84..d448cb57df86 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -217,7 +217,7 @@ system-wide transition to a sleep state even though its :c:member:`runtime_auto` flag is clear. For more information about the runtime power management framework, refer to -:file:`Documentation/power/runtime_pm.rst`. +Documentation/power/runtime_pm.rst. Calling Drivers to Enter and Leave System Sleep States @@ -655,7 +655,7 @@ been thawed. Generally speaking, the PM notifiers are suitable for performing actions that either require user space to be available, or at least won't interfere with user space. -For details refer to :doc:`notifiers`. +For details refer to Documentation/driver-api/pm/notifiers.rst. Device Low-Power (suspend) States @@ -726,7 +726,7 @@ it into account in any way. Devices may be defined as IRQ-safe which indicates to the PM core that their runtime PM callbacks may be invoked with disabled interrupts (see -:file:`Documentation/power/runtime_pm.rst` for more information). If an +Documentation/power/runtime_pm.rst for more information). If an IRQ-safe device belongs to a PM domain, the runtime PM of the domain will be disallowed, unless the domain itself is defined as IRQ-safe. However, it makes sense to define a PM domain as IRQ-safe only if all the devices in it @@ -805,7 +805,7 @@ The ``DPM_FLAG_MAY_SKIP_RESUME`` Driver Flag -------------------------------------------- During system-wide resume from a sleep state it's easiest to put devices into -the full-power state, as explained in :file:`Documentation/power/runtime_pm.rst`. +the full-power state, as explained in Documentation/power/runtime_pm.rst. [Refer to that document for more information regarding this particular issue as well as for information on the device runtime power management framework in general.] However, it often is desirable to leave devices in suspend after diff --git a/Documentation/driver-api/serial/index.rst b/Documentation/driver-api/serial/index.rst index 21351b8c95a4..8f7d7af3b90b 100644 --- a/Documentation/driver-api/serial/index.rst +++ b/Documentation/driver-api/serial/index.rst @@ -19,7 +19,6 @@ Serial drivers moxa-smartio n_gsm - rocket serial-iso7816 serial-rs485 diff --git a/Documentation/driver-api/surface_aggregator/clients/cdev.rst b/Documentation/driver-api/surface_aggregator/clients/cdev.rst index 248c1372d879..0134a841a079 100644 --- a/Documentation/driver-api/surface_aggregator/clients/cdev.rst +++ b/Documentation/driver-api/surface_aggregator/clients/cdev.rst @@ -1,9 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0+ -.. |u8| replace:: :c:type:`u8 <u8>` -.. |u16| replace:: :c:type:`u16 <u16>` .. |ssam_cdev_request| replace:: :c:type:`struct ssam_cdev_request <ssam_cdev_request>` .. |ssam_cdev_request_flags| replace:: :c:type:`enum ssam_cdev_request_flags <ssam_cdev_request_flags>` +.. |ssam_cdev_event| replace:: :c:type:`struct ssam_cdev_event <ssam_cdev_event>` ============================== User-Space EC Interface (cdev) @@ -23,6 +22,40 @@ These IOCTLs and their respective input/output parameter structs are defined in A small python library and scripts for accessing this interface can be found at https://github.com/linux-surface/surface-aggregator-module/tree/master/scripts/ssam. +.. contents:: + + +Receiving Events +================ + +Events can be received by reading from the device-file. The are represented by +the |ssam_cdev_event| datatype. + +Before events are available to be read, however, the desired notifiers must be +registered via the ``SSAM_CDEV_NOTIF_REGISTER`` IOCTL. Notifiers are, in +essence, callbacks, called when the EC sends an event. They are, in this +interface, associated with a specific target category and device-file-instance. +They forward any event of this category to the buffer of the corresponding +instance, from which it can then be read. + +Notifiers themselves do not enable events on the EC. Thus, it may additionally +be necessary to enable events via the ``SSAM_CDEV_EVENT_ENABLE`` IOCTL. While +notifiers work per-client (i.e. per-device-file-instance), events are enabled +globally, for the EC and all of its clients (regardless of userspace or +non-userspace). The ``SSAM_CDEV_EVENT_ENABLE`` and ``SSAM_CDEV_EVENT_DISABLE`` +IOCTLs take care of reference counting the events, such that an event is +enabled as long as there is a client that has requested it. + +Note that enabled events are not automatically disabled once the client +instance is closed. Therefore any client process (or group of processes) should +balance their event enable calls with the corresponding event disable calls. It +is, however, perfectly valid to enable and disable events on different client +instances. For example, it is valid to set up notifiers and read events on +client instance ``A``, enable those events on instance ``B`` (note that these +will also be received by A since events are enabled/disabled globally), and +after no more events are desired, disable the previously enabled events via +instance ``C``. + Controller IOCTLs ================= @@ -45,9 +78,33 @@ The following IOCTLs are provided: - ``REQUEST`` - Perform synchronous SAM request. + * - ``0xA5`` + - ``2`` + - ``W`` + - ``NOTIF_REGISTER`` + - Register event notifier. -``REQUEST`` ------------ + * - ``0xA5`` + - ``3`` + - ``W`` + - ``NOTIF_UNREGISTER`` + - Unregister event notifier. + + * - ``0xA5`` + - ``4`` + - ``W`` + - ``EVENT_ENABLE`` + - Enable event source. + + * - ``0xA5`` + - ``5`` + - ``W`` + - ``EVENT_DISABLE`` + - Disable event source. + + +``SSAM_CDEV_REQUEST`` +--------------------- Defined as ``_IOWR(0xA5, 1, struct ssam_cdev_request)``. @@ -82,6 +139,66 @@ submitted, and completed (i.e. handed back to user-space) successfully from inside the IOCTL, but the request ``status`` member may still be negative in case the actual execution of the request failed after it has been submitted. -A full definition of the argument struct is provided below: +A full definition of the argument struct is provided below. + +``SSAM_CDEV_NOTIF_REGISTER`` +---------------------------- + +Defined as ``_IOW(0xA5, 2, struct ssam_cdev_notifier_desc)``. + +Register a notifier for the event target category specified in the given +notifier description with the specified priority. Notifiers registration is +required to receive events, but does not enable events themselves. After a +notifier for a specific target category has been registered, all events of that +category will be forwarded to the userspace client and can then be read from +the device file instance. Note that events may have to be enabled, e.g. via the +``SSAM_CDEV_EVENT_ENABLE`` IOCTL, before the EC will send them. + +Only one notifier can be registered per target category and client instance. If +a notifier has already been registered, this IOCTL will fail with ``-EEXIST``. + +Notifiers will automatically be removed when the device file instance is +closed. + +``SSAM_CDEV_NOTIF_UNREGISTER`` +------------------------------ + +Defined as ``_IOW(0xA5, 3, struct ssam_cdev_notifier_desc)``. + +Unregisters the notifier associated with the specified target category. The +priority field will be ignored by this IOCTL. If no notifier has been +registered for this client instance and the given category, this IOCTL will +fail with ``-ENOENT``. + +``SSAM_CDEV_EVENT_ENABLE`` +-------------------------- + +Defined as ``_IOW(0xA5, 4, struct ssam_cdev_event_desc)``. + +Enable the event associated with the given event descriptor. + +Note that this call will not register a notifier itself, it will only enable +events on the controller. If you want to receive events by reading from the +device file, you will need to register the corresponding notifier(s) on that +instance. + +Events are not automatically disabled when the device file is closed. This must +be done manually, via a call to the ``SSAM_CDEV_EVENT_DISABLE`` IOCTL. + +``SSAM_CDEV_EVENT_DISABLE`` +--------------------------- + +Defined as ``_IOW(0xA5, 5, struct ssam_cdev_event_desc)``. + +Disable the event associated with the given event descriptor. + +Note that this will not unregister any notifiers. Events may still be received +and forwarded to user-space after this call. The only safe way of stopping +events from being received is unregistering all previously registered +notifiers. + + +Structures and Enums +==================== .. kernel-doc:: include/uapi/linux/surface_aggregator/cdev.h diff --git a/Documentation/driver-api/surface_aggregator/clients/index.rst b/Documentation/driver-api/surface_aggregator/clients/index.rst index 98ea9946b8a2..30160513afa5 100644 --- a/Documentation/driver-api/surface_aggregator/clients/index.rst +++ b/Documentation/driver-api/surface_aggregator/clients/index.rst @@ -5,7 +5,8 @@ Client Driver Documentation =========================== This is the documentation for client drivers themselves. Refer to -:doc:`../client` for documentation on how to write client drivers. +Documentation/driver-api/surface_aggregator/client.rst for documentation +on how to write client drivers. .. toctree:: :maxdepth: 1 diff --git a/Documentation/driver-api/surface_aggregator/internal.rst b/Documentation/driver-api/surface_aggregator/internal.rst index 72704734982a..8c7c80c9f418 100644 --- a/Documentation/driver-api/surface_aggregator/internal.rst +++ b/Documentation/driver-api/surface_aggregator/internal.rst @@ -87,10 +87,11 @@ native SSAM devices, i.e. devices that are not defined in ACPI and not implemented as platform devices, via |ssam_device| and |ssam_device_driver| simplify management of client devices and client drivers. -Refer to :doc:`client` for documentation regarding the client device/driver -API and interface options for other kernel drivers. It is recommended to -familiarize oneself with that chapter and the :doc:`ssh` before continuing -with the architectural overview below. +Refer to Documentation/driver-api/surface_aggregator/client.rst for +documentation regarding the client device/driver API and interface options +for other kernel drivers. It is recommended to familiarize oneself with +that chapter and the Documentation/driver-api/surface_aggregator/ssh.rst +before continuing with the architectural overview below. Packet Transport Layer @@ -190,9 +191,9 @@ with success on the transmitter thread. Transmission of sequenced packets is limited by the number of concurrently pending packets, i.e. a limit on how many packets may be waiting for an ACK -from the EC in parallel. This limit is currently set to one (see :doc:`ssh` -for the reasoning behind this). Control packets (i.e. ACK and NAK) can -always be transmitted. +from the EC in parallel. This limit is currently set to one (see +Documentation/driver-api/surface_aggregator/ssh.rst for the reasoning behind +this). Control packets (i.e. ACK and NAK) can always be transmitted. Receiver Thread --------------- diff --git a/Documentation/driver-api/surface_aggregator/overview.rst b/Documentation/driver-api/surface_aggregator/overview.rst index 1e9d57e50063..26415e1ab7da 100644 --- a/Documentation/driver-api/surface_aggregator/overview.rst +++ b/Documentation/driver-api/surface_aggregator/overview.rst @@ -73,5 +73,7 @@ being a direct response to a previous request. We may also refer to requests without response as commands. In general, events need to be enabled via one of multiple dedicated requests before they are sent by the EC. -See :doc:`ssh` for a more technical protocol documentation and -:doc:`internal` for an overview of the internal driver architecture. +See Documentation/driver-api/surface_aggregator/ssh.rst for a +more technical protocol documentation and +Documentation/driver-api/surface_aggregator/internal.rst for an +overview of the internal driver architecture. diff --git a/Documentation/driver-api/thermal/sysfs-api.rst b/Documentation/driver-api/thermal/sysfs-api.rst index 4b638c14bc16..c93fa5e961a0 100644 --- a/Documentation/driver-api/thermal/sysfs-api.rst +++ b/Documentation/driver-api/thermal/sysfs-api.rst @@ -740,21 +740,15 @@ possible. 5. thermal_emergency_poweroff ============================= -On an event of critical trip temperature crossing. Thermal framework -allows the system to shutdown gracefully by calling orderly_poweroff(). -In the event of a failure of orderly_poweroff() to shut down the system -we are in danger of keeping the system alive at undesirably high -temperatures. To mitigate this high risk scenario we program a work -queue to fire after a pre-determined number of seconds to start -an emergency shutdown of the device using the kernel_power_off() -function. In case kernel_power_off() fails then finally -emergency_restart() is called in the worst case. +On an event of critical trip temperature crossing the thermal framework +shuts down the system by calling hw_protection_shutdown(). The +hw_protection_shutdown() first attempts to perform an orderly shutdown +but accepts a delay after which it proceeds doing a forced power-off +or as last resort an emergency_restart. The delay should be carefully profiled so as to give adequate time for -orderly_poweroff(). In case of failure of an orderly_poweroff() the -emergency poweroff kicks in after the delay has elapsed and shuts down -the system. +orderly poweroff. -If set to 0 emergency poweroff will not be supported. So a carefully -profiled non-zero positive value is a must for emergency poweroff to be -triggered. +If the delay is set to 0 emergency poweroff will not be supported. So a +carefully profiled non-zero positive value is a must for emergency +poweroff to be triggered. diff --git a/Documentation/driver-api/usb/dma.rst b/Documentation/driver-api/usb/dma.rst index 2b3dbd3265b4..d32c27e11b90 100644 --- a/Documentation/driver-api/usb/dma.rst +++ b/Documentation/driver-api/usb/dma.rst @@ -10,7 +10,7 @@ API overview The big picture is that USB drivers can continue to ignore most DMA issues, though they still must provide DMA-ready buffers (see -:doc:`/core-api/dma-api-howto`). That's how they've worked through +Documentation/core-api/dma-api-howto.rst). That's how they've worked through the 2.4 (and earlier) kernels, or they can now be DMA-aware. DMA-aware usb drivers: @@ -60,7 +60,7 @@ and effects like cache-trashing can impose subtle penalties. force a consistent memory access ordering by using memory barriers. It's not using a streaming DMA mapping, so it's good for small transfers on systems where the I/O would otherwise thrash an IOMMU mapping. (See - :doc:`/core-api/dma-api-howto` for definitions of "coherent" and + Documentation/core-api/dma-api-howto.rst for definitions of "coherent" and "streaming" DMA mappings.) Asking for 1/Nth of a page (as well as asking for N pages) is reasonably @@ -91,7 +91,7 @@ Working with existing buffers Existing buffers aren't usable for DMA without first being mapped into the DMA address space of the device. However, most buffers passed to your driver can safely be used with such DMA mapping. (See the first section -of :doc:`/core-api/dma-api-howto`, titled "What memory is DMA-able?") +of Documentation/core-api/dma-api-howto.rst, titled "What memory is DMA-able?") - When you're using scatterlists, you can map everything at once. On some systems, this kicks in an IOMMU and turns the scatterlists into single diff --git a/Documentation/driver-api/usb/usb.rst b/Documentation/driver-api/usb/usb.rst index 543e70434da2..2c94ff2f4385 100644 --- a/Documentation/driver-api/usb/usb.rst +++ b/Documentation/driver-api/usb/usb.rst @@ -109,16 +109,21 @@ well as to make sure they aren't relying on some HCD-specific behavior. USB-Standard Types ================== -In ``drivers/usb/common/common.c`` and ``drivers/usb/common/debug.c`` you -will find the USB data types defined in chapter 9 of the USB specification. -These data types are used throughout USB, and in APIs including this host -side API, gadget APIs, usb character devices and debugfs interfaces. +In ``include/uapi/linux/usb/ch9.h`` you will find the USB data types defined +in chapter 9 of the USB specification. These data types are used throughout +USB, and in APIs including this host side API, gadget APIs, usb character +devices and debugfs interfaces. That file is itself included by +``include/linux/usb/ch9.h``, which also contains declarations of a few +utility routines for manipulating these data types; the implementations +are in ``drivers/usb/common/common.c``. .. kernel-doc:: drivers/usb/common/common.c :export: -.. kernel-doc:: drivers/usb/common/debug.c - :export: +In addition, some functions useful for creating debugging output are +defined in ``drivers/usb/common/debug.c``. + +.. _usb_header: Host-Side Data Types and Macros =============================== diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst index 1779b85f014e..9f26079cacae 100644 --- a/Documentation/driver-api/vfio-mediated-device.rst +++ b/Documentation/driver-api/vfio-mediated-device.rst @@ -93,7 +93,7 @@ interfaces: Registration Interface for a Mediated Bus Driver ------------------------------------------------ -The registration interface for a mediated bus driver provides the following +The registration interface for a mediated device driver provides the following structure to represent a mediated device's driver:: /* @@ -136,37 +136,26 @@ The structures in the mdev_parent_ops structure are as follows: * dev_attr_groups: attributes of the parent device * mdev_attr_groups: attributes of the mediated device * supported_config: attributes to define supported configurations +* device_driver: device driver to bind for mediated device instances -The functions in the mdev_parent_ops structure are as follows: +The mdev_parent_ops also still has various functions pointers. Theses exist +for historical reasons only and shall not be used for new drivers. -* create: allocate basic resources in a driver for a mediated device -* remove: free resources in a driver when a mediated device is destroyed - -(Note that mdev-core provides no implicit serialization of create/remove -callbacks per mdev parent device, per mdev type, or any other categorization. -Vendor drivers are expected to be fully asynchronous in this respect or -provide their own internal resource protection.) - -The callbacks in the mdev_parent_ops structure are as follows: - -* open: open callback of mediated device -* close: close callback of mediated device -* ioctl: ioctl callback of mediated device -* read : read emulation callback -* write: write emulation callback -* mmap: mmap emulation callback - -A driver should use the mdev_parent_ops structure in the function call to -register itself with the mdev core driver:: +When a driver wants to add the GUID creation sysfs to an existing device it has +probe'd to then it should call:: extern int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops); -However, the mdev_parent_ops structure is not required in the function call -that a driver should use to unregister itself with the mdev core driver:: +This will provide the 'mdev_supported_types/XX/create' files which can then be +used to trigger the creation of a mdev_device. The created mdev_device will be +attached to the specified driver. + +When the driver needs to remove itself it calls:: extern void mdev_unregister_device(struct device *dev); +Which will unbind and destroy all the created mdevs and remove the sysfs files. Mediated Device Management Interface Through sysfs ================================================== diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst index 31ecfe44e5b4..f47d05ed0d94 100644 --- a/Documentation/fault-injection/fault-injection.rst +++ b/Documentation/fault-injection/fault-injection.rst @@ -78,8 +78,10 @@ configuration of fault-injection capabilities. - /sys/kernel/debug/fail*/times: - specifies how many times failures may happen at most. - A value of -1 means "no limit". + specifies how many times failures may happen at most. A value of -1 + means "no limit". Note, though, that this file only accepts unsigned + values. So, if you want to specify -1, you better use 'printf' instead + of 'echo', e.g.: $ printf %#x -1 > times - /sys/kernel/debug/fail*/space: @@ -167,11 +169,13 @@ configuration of fault-injection capabilities. - ERRNO: retval must be -1 to -MAX_ERRNO (-4096). - ERR_NULL: retval must be 0 or -1 to -MAX_ERRNO (-4096). -- /sys/kernel/debug/fail_function/<functiuon-name>/retval: +- /sys/kernel/debug/fail_function/<function-name>/retval: - specifies the "error" return value to inject to the given - function for given function. This will be created when - user specifies new injection entry. + specifies the "error" return value to inject to the given function. + This will be created when the user specifies a new injection entry. + Note that this file only accepts unsigned values. So, if you want to + use a negative errno, you better use 'printf' instead of 'echo', e.g.: + $ printf %#x -12 > retval Boot option ^^^^^^^^^^^ @@ -255,7 +259,7 @@ Application Examples echo Y > /sys/kernel/debug/$FAILTYPE/task-filter echo 10 > /sys/kernel/debug/$FAILTYPE/probability echo 100 > /sys/kernel/debug/$FAILTYPE/interval - echo -1 > /sys/kernel/debug/$FAILTYPE/times + printf %#x -1 > /sys/kernel/debug/$FAILTYPE/times echo 0 > /sys/kernel/debug/$FAILTYPE/space echo 2 > /sys/kernel/debug/$FAILTYPE/verbose echo 1 > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait @@ -309,7 +313,7 @@ Application Examples echo N > /sys/kernel/debug/$FAILTYPE/task-filter echo 10 > /sys/kernel/debug/$FAILTYPE/probability echo 100 > /sys/kernel/debug/$FAILTYPE/interval - echo -1 > /sys/kernel/debug/$FAILTYPE/times + printf %#x -1 > /sys/kernel/debug/$FAILTYPE/times echo 0 > /sys/kernel/debug/$FAILTYPE/space echo 2 > /sys/kernel/debug/$FAILTYPE/verbose echo 1 > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait @@ -336,11 +340,11 @@ Application Examples FAILTYPE=fail_function FAILFUNC=open_ctree echo $FAILFUNC > /sys/kernel/debug/$FAILTYPE/inject - echo -12 > /sys/kernel/debug/$FAILTYPE/$FAILFUNC/retval + printf %#x -12 > /sys/kernel/debug/$FAILTYPE/$FAILFUNC/retval echo N > /sys/kernel/debug/$FAILTYPE/task-filter echo 100 > /sys/kernel/debug/$FAILTYPE/probability echo 0 > /sys/kernel/debug/$FAILTYPE/interval - echo -1 > /sys/kernel/debug/$FAILTYPE/times + printf %#x -1 > /sys/kernel/debug/$FAILTYPE/times echo 0 > /sys/kernel/debug/$FAILTYPE/space echo 1 > /sys/kernel/debug/$FAILTYPE/verbose diff --git a/Documentation/filesystems/dax.rst b/Documentation/filesystems/dax.rst new file mode 100644 index 000000000000..9a1b8fd9e82b --- /dev/null +++ b/Documentation/filesystems/dax.rst @@ -0,0 +1,291 @@ +======================= +Direct Access for files +======================= + +Motivation +---------- + +The page cache is usually used to buffer reads and writes to files. +It is also used to provide the pages which are mapped into userspace +by a call to mmap. + +For block devices that are memory-like, the page cache pages would be +unnecessary copies of the original storage. The `DAX` code removes the +extra copy by performing reads and writes directly to the storage device. +For file mappings, the storage device is mapped directly into userspace. + + +Usage +----- + +If you have a block device which supports `DAX`, you can make a filesystem +on it as usual. The `DAX` code currently only supports files with a block +size equal to your kernel's `PAGE_SIZE`, so you may need to specify a block +size when creating the filesystem. + +Currently 3 filesystems support `DAX`: ext2, ext4 and xfs. Enabling `DAX` on them +is different. + +Enabling DAX on ext2 +-------------------- + +When mounting the filesystem, use the ``-o dax`` option on the command line or +add 'dax' to the options in ``/etc/fstab``. This works to enable `DAX` on all files +within the filesystem. It is equivalent to the ``-o dax=always`` behavior below. + + +Enabling DAX on xfs and ext4 +---------------------------- + +Summary +------- + + 1. There exists an in-kernel file access mode flag `S_DAX` that corresponds to + the statx flag `STATX_ATTR_DAX`. See the manpage for statx(2) for details + about this access mode. + + 2. There exists a persistent flag `FS_XFLAG_DAX` that can be applied to regular + files and directories. This advisory flag can be set or cleared at any + time, but doing so does not immediately affect the `S_DAX` state. + + 3. If the persistent `FS_XFLAG_DAX` flag is set on a directory, this flag will + be inherited by all regular files and subdirectories that are subsequently + created in this directory. Files and subdirectories that exist at the time + this flag is set or cleared on the parent directory are not modified by + this modification of the parent directory. + + 4. There exist dax mount options which can override `FS_XFLAG_DAX` in the + setting of the `S_DAX` flag. Given underlying storage which supports `DAX` the + following hold: + + ``-o dax=inode`` means "follow `FS_XFLAG_DAX`" and is the default. + + ``-o dax=never`` means "never set `S_DAX`, ignore `FS_XFLAG_DAX`." + + ``-o dax=always`` means "always set `S_DAX` ignore `FS_XFLAG_DAX`." + + ``-o dax`` is a legacy option which is an alias for ``dax=always``. + + .. warning:: + + The option ``-o dax`` may be removed in the future so ``-o dax=always`` is + the preferred method for specifying this behavior. + + .. note:: + + Modifications to and the inheritance behavior of `FS_XFLAG_DAX` remain + the same even when the filesystem is mounted with a dax option. However, + in-core inode state (`S_DAX`) will be overridden until the filesystem is + remounted with dax=inode and the inode is evicted from kernel memory. + + 5. The `S_DAX` policy can be changed via: + + a) Setting the parent directory `FS_XFLAG_DAX` as needed before files are + created + + b) Setting the appropriate dax="foo" mount option + + c) Changing the `FS_XFLAG_DAX` flag on existing regular files and + directories. This has runtime constraints and limitations that are + described in 6) below. + + 6. When changing the `S_DAX` policy via toggling the persistent `FS_XFLAG_DAX` + flag, the change to existing regular files won't take effect until the + files are closed by all processes. + + +Details +------- + +There are 2 per-file dax flags. One is a persistent inode setting (`FS_XFLAG_DAX`) +and the other is a volatile flag indicating the active state of the feature +(`S_DAX`). + +`FS_XFLAG_DAX` is preserved within the filesystem. This persistent config +setting can be set, cleared and/or queried using the `FS_IOC_FS`[`GS`]`ETXATTR` ioctl +(see ioctl_xfs_fsgetxattr(2)) or an utility such as 'xfs_io'. + +New files and directories automatically inherit `FS_XFLAG_DAX` from +their parent directory **when created**. Therefore, setting `FS_XFLAG_DAX` at +directory creation time can be used to set a default behavior for an entire +sub-tree. + +To clarify inheritance, here are 3 examples: + +Example A: + +.. code-block:: shell + + mkdir -p a/b/c + xfs_io -c 'chattr +x' a + mkdir a/b/c/d + mkdir a/e + + ------[outcome]------ + + dax: a,e + no dax: b,c,d + +Example B: + +.. code-block:: shell + + mkdir a + xfs_io -c 'chattr +x' a + mkdir -p a/b/c/d + + ------[outcome]------ + + dax: a,b,c,d + no dax: + +Example C: + +.. code-block:: shell + + mkdir -p a/b/c + xfs_io -c 'chattr +x' c + mkdir a/b/c/d + + ------[outcome]------ + + dax: c,d + no dax: a,b + +The current enabled state (`S_DAX`) is set when a file inode is instantiated in +memory by the kernel. It is set based on the underlying media support, the +value of `FS_XFLAG_DAX` and the filesystem's dax mount option. + +statx can be used to query `S_DAX`. + +.. note:: + + That only regular files will ever have `S_DAX` set and therefore statx + will never indicate that `S_DAX` is set on directories. + +Setting the `FS_XFLAG_DAX` flag (specifically or through inheritance) occurs even +if the underlying media does not support dax and/or the filesystem is +overridden with a mount option. + + +Implementation Tips for Block Driver Writers +-------------------------------------------- + +To support `DAX` in your block driver, implement the 'direct_access' +block device operation. It is used to translate the sector number +(expressed in units of 512-byte sectors) to a page frame number (pfn) +that identifies the physical page for the memory. It also returns a +kernel virtual address that can be used to access the memory. + +The direct_access method takes a 'size' parameter that indicates the +number of bytes being requested. The function should return the number +of bytes that can be contiguously accessed at that offset. It may also +return a negative errno if an error occurs. + +In order to support this method, the storage must be byte-accessible by +the CPU at all times. If your device uses paging techniques to expose +a large amount of memory through a smaller window, then you cannot +implement direct_access. Equally, if your device can occasionally +stall the CPU for an extended period, you should also not attempt to +implement direct_access. + +These block devices may be used for inspiration: +- brd: RAM backed block device driver +- dcssblk: s390 dcss block device driver +- pmem: NVDIMM persistent memory driver + + +Implementation Tips for Filesystem Writers +------------------------------------------ + +Filesystem support consists of: + +* Adding support to mark inodes as being `DAX` by setting the `S_DAX` flag in + i_flags +* Implementing ->read_iter and ->write_iter operations which use + :c:func:`dax_iomap_rw()` when inode has `S_DAX` flag set +* Implementing an mmap file operation for `DAX` files which sets the + `VM_MIXEDMAP` and `VM_HUGEPAGE` flags on the `VMA`, and setting the vm_ops to + include handlers for fault, pmd_fault, page_mkwrite, pfn_mkwrite. These + handlers should probably call :c:func:`dax_iomap_fault()` passing the + appropriate fault size and iomap operations. +* Calling :c:func:`iomap_zero_range()` passing appropriate iomap operations + instead of :c:func:`block_truncate_page()` for `DAX` files +* Ensuring that there is sufficient locking between reads, writes, + truncates and page faults + +The iomap handlers for allocating blocks must make sure that allocated blocks +are zeroed out and converted to written extents before being returned to avoid +exposure of uninitialized data through mmap. + +These filesystems may be used for inspiration: + +.. seealso:: + + ext2: see Documentation/filesystems/ext2.rst + +.. seealso:: + + xfs: see Documentation/admin-guide/xfs.rst + +.. seealso:: + + ext4: see Documentation/filesystems/ext4/ + + +Handling Media Errors +--------------------- + +The libnvdimm subsystem stores a record of known media error locations for +each pmem block device (in gendisk->badblocks). If we fault at such location, +or one with a latent error not yet discovered, the application can expect +to receive a `SIGBUS`. Libnvdimm also allows clearing of these errors by simply +writing the affected sectors (through the pmem driver, and if the underlying +NVDIMM supports the clear_poison DSM defined by ACPI). + +Since `DAX` IO normally doesn't go through the ``driver/bio`` path, applications or +sysadmins have an option to restore the lost data from a prior ``backup/inbuilt`` +redundancy in the following ways: + +1. Delete the affected file, and restore from a backup (sysadmin route): + This will free the filesystem blocks that were being used by the file, + and the next time they're allocated, they will be zeroed first, which + happens through the driver, and will clear bad sectors. + +2. Truncate or hole-punch the part of the file that has a bad-block (at least + an entire aligned sector has to be hole-punched, but not necessarily an + entire filesystem block). + +These are the two basic paths that allow `DAX` filesystems to continue operating +in the presence of media errors. More robust error recovery mechanisms can be +built on top of this in the future, for example, involving redundancy/mirroring +provided at the block layer through DM, or additionally, at the filesystem +level. These would have to rely on the above two tenets, that error clearing +can happen either by sending an IO through the driver, or zeroing (also through +the driver). + + +Shortcomings +------------ + +Even if the kernel or its modules are stored on a filesystem that supports +`DAX` on a block device that supports `DAX`, they will still be copied into RAM. + +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 +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 +how to do this). In the non struct page cases `O_DIRECT` reads/writes to +those memory ranges from a non-`DAX` file will fail + + +.. note:: + + `O_DIRECT` reads/writes _of a `DAX` file do work, it is the memory that + is being accessed that is key here). Other things that will not work in + the non struct page case include RDMA, :c:func:`sendfile()` and + :c:func:`splice()`. diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt deleted file mode 100644 index e03c20564f3a..000000000000 --- a/Documentation/filesystems/dax.txt +++ /dev/null @@ -1,257 +0,0 @@ -Direct Access for files ------------------------ - -Motivation ----------- - -The page cache is usually used to buffer reads and writes to files. -It is also used to provide the pages which are mapped into userspace -by a call to mmap. - -For block devices that are memory-like, the page cache pages would be -unnecessary copies of the original storage. The DAX code removes the -extra copy by performing reads and writes directly to the storage device. -For file mappings, the storage device is mapped directly into userspace. - - -Usage ------ - -If you have a block device which supports DAX, you can make a filesystem -on it as usual. The DAX code currently only supports files with a block -size equal to your kernel's PAGE_SIZE, so you may need to specify a block -size when creating the filesystem. - -Currently 3 filesystems support DAX: ext2, ext4 and xfs. Enabling DAX on them -is different. - -Enabling DAX on ext2 ------------------------------ - -When mounting the filesystem, use the "-o dax" option on the command line or -add 'dax' to the options in /etc/fstab. This works to enable DAX on all files -within the filesystem. It is equivalent to the '-o dax=always' behavior below. - - -Enabling DAX on xfs and ext4 ----------------------------- - -Summary -------- - - 1. There exists an in-kernel file access mode flag S_DAX that corresponds to - the statx flag STATX_ATTR_DAX. See the manpage for statx(2) for details - about this access mode. - - 2. There exists a persistent flag FS_XFLAG_DAX that can be applied to regular - files and directories. This advisory flag can be set or cleared at any - time, but doing so does not immediately affect the S_DAX state. - - 3. If the persistent FS_XFLAG_DAX flag is set on a directory, this flag will - be inherited by all regular files and subdirectories that are subsequently - created in this directory. Files and subdirectories that exist at the time - this flag is set or cleared on the parent directory are not modified by - this modification of the parent directory. - - 4. There exist dax mount options which can override FS_XFLAG_DAX in the - setting of the S_DAX flag. Given underlying storage which supports DAX the - following hold: - - "-o dax=inode" means "follow FS_XFLAG_DAX" and is the default. - - "-o dax=never" means "never set S_DAX, ignore FS_XFLAG_DAX." - - "-o dax=always" means "always set S_DAX ignore FS_XFLAG_DAX." - - "-o dax" is a legacy option which is an alias for "dax=always". - This may be removed in the future so "-o dax=always" is - the preferred method for specifying this behavior. - - NOTE: Modifications to and the inheritance behavior of FS_XFLAG_DAX remain - the same even when the filesystem is mounted with a dax option. However, - in-core inode state (S_DAX) will be overridden until the filesystem is - remounted with dax=inode and the inode is evicted from kernel memory. - - 5. The S_DAX policy can be changed via: - - a) Setting the parent directory FS_XFLAG_DAX as needed before files are - created - - b) Setting the appropriate dax="foo" mount option - - c) Changing the FS_XFLAG_DAX flag on existing regular files and - directories. This has runtime constraints and limitations that are - described in 6) below. - - 6. When changing the S_DAX policy via toggling the persistent FS_XFLAG_DAX - flag, the change to existing regular files won't take effect until the - files are closed by all processes. - - -Details -------- - -There are 2 per-file dax flags. One is a persistent inode setting (FS_XFLAG_DAX) -and the other is a volatile flag indicating the active state of the feature -(S_DAX). - -FS_XFLAG_DAX is preserved within the filesystem. This persistent config -setting can be set, cleared and/or queried using the FS_IOC_FS[GS]ETXATTR ioctl -(see ioctl_xfs_fsgetxattr(2)) or an utility such as 'xfs_io'. - -New files and directories automatically inherit FS_XFLAG_DAX from -their parent directory _when_ _created_. Therefore, setting FS_XFLAG_DAX at -directory creation time can be used to set a default behavior for an entire -sub-tree. - -To clarify inheritance, here are 3 examples: - -Example A: - -mkdir -p a/b/c -xfs_io -c 'chattr +x' a -mkdir a/b/c/d -mkdir a/e - - dax: a,e - no dax: b,c,d - -Example B: - -mkdir a -xfs_io -c 'chattr +x' a -mkdir -p a/b/c/d - - dax: a,b,c,d - no dax: - -Example C: - -mkdir -p a/b/c -xfs_io -c 'chattr +x' c -mkdir a/b/c/d - - dax: c,d - no dax: a,b - - -The current enabled state (S_DAX) is set when a file inode is instantiated in -memory by the kernel. It is set based on the underlying media support, the -value of FS_XFLAG_DAX and the filesystem's dax mount option. - -statx can be used to query S_DAX. NOTE that only regular files will ever have -S_DAX set and therefore statx will never indicate that S_DAX is set on -directories. - -Setting the FS_XFLAG_DAX flag (specifically or through inheritance) occurs even -if the underlying media does not support dax and/or the filesystem is -overridden with a mount option. - - - -Implementation Tips for Block Driver Writers --------------------------------------------- - -To support DAX in your block driver, implement the 'direct_access' -block device operation. It is used to translate the sector number -(expressed in units of 512-byte sectors) to a page frame number (pfn) -that identifies the physical page for the memory. It also returns a -kernel virtual address that can be used to access the memory. - -The direct_access method takes a 'size' parameter that indicates the -number of bytes being requested. The function should return the number -of bytes that can be contiguously accessed at that offset. It may also -return a negative errno if an error occurs. - -In order to support this method, the storage must be byte-accessible by -the CPU at all times. If your device uses paging techniques to expose -a large amount of memory through a smaller window, then you cannot -implement direct_access. Equally, if your device can occasionally -stall the CPU for an extended period, you should also not attempt to -implement direct_access. - -These block devices may be used for inspiration: -- brd: RAM backed block device driver -- dcssblk: s390 dcss block device driver -- pmem: NVDIMM persistent memory driver - - -Implementation Tips for Filesystem Writers ------------------------------------------- - -Filesystem support consists of -- adding support to mark inodes as being DAX by setting the S_DAX flag in - i_flags -- implementing ->read_iter and ->write_iter operations which use dax_iomap_rw() - when inode has S_DAX flag set -- implementing an mmap file operation for DAX files which sets the - VM_MIXEDMAP and VM_HUGEPAGE flags on the VMA, and setting the vm_ops to - include handlers for fault, pmd_fault, page_mkwrite, pfn_mkwrite. These - handlers should probably call dax_iomap_fault() passing the appropriate - fault size and iomap operations. -- calling iomap_zero_range() passing appropriate iomap operations instead of - block_truncate_page() for DAX files -- ensuring that there is sufficient locking between reads, writes, - truncates and page faults - -The iomap handlers for allocating blocks must make sure that allocated blocks -are zeroed out and converted to written extents before being returned to avoid -exposure of uninitialized data through mmap. - -These filesystems may be used for inspiration: -- ext2: see Documentation/filesystems/ext2.rst -- ext4: see Documentation/filesystems/ext4/ -- xfs: see Documentation/admin-guide/xfs.rst - - -Handling Media Errors ---------------------- - -The libnvdimm subsystem stores a record of known media error locations for -each pmem block device (in gendisk->badblocks). If we fault at such location, -or one with a latent error not yet discovered, the application can expect -to receive a SIGBUS. Libnvdimm also allows clearing of these errors by simply -writing the affected sectors (through the pmem driver, and if the underlying -NVDIMM supports the clear_poison DSM defined by ACPI). - -Since DAX IO normally doesn't go through the driver/bio path, applications or -sysadmins have an option to restore the lost data from a prior backup/inbuilt -redundancy in the following ways: - -1. Delete the affected file, and restore from a backup (sysadmin route): - This will free the filesystem blocks that were being used by the file, - and the next time they're allocated, they will be zeroed first, which - happens through the driver, and will clear bad sectors. - -2. Truncate or hole-punch the part of the file that has a bad-block (at least - an entire aligned sector has to be hole-punched, but not necessarily an - entire filesystem block). - -These are the two basic paths that allow DAX filesystems to continue operating -in the presence of media errors. More robust error recovery mechanisms can be -built on top of this in the future, for example, involving redundancy/mirroring -provided at the block layer through DM, or additionally, at the filesystem -level. These would have to rely on the above two tenets, that error clearing -can happen either by sending an IO through the driver, or zeroing (also through -the driver). - - -Shortcomings ------------- - -Even if the kernel or its modules are stored on a filesystem that supports -DAX on a block device that supports DAX, they will still be copied into RAM. - -The DAX code does not work correctly on architectures which have virtually -mapped caches such as ARM, MIPS and SPARC. - -Calling 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 -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 -how to do this). In the non struct page cases O_DIRECT reads/writes to -those memory ranges from a non-DAX file will fail (note that O_DIRECT -reads/writes _of a DAX file_ do work, it is the memory that is being -accessed that is key here). Other things that will not work in the -non struct page case include RDMA, sendfile() and splice(). diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst index bf145171c2bf..832839fcf4c3 100644 --- a/Documentation/filesystems/erofs.rst +++ b/Documentation/filesystems/erofs.rst @@ -50,8 +50,8 @@ Here is the main features of EROFS: - Support POSIX.1e ACLs by using xattrs; - - Support transparent file compression as an option: - LZ4 algorithm with 4 KB fixed-sized output compression for high performance. + - Support transparent data compression as an option: + LZ4 algorithm with the fixed-sized output compression for high performance. The following git tree provides the file system user-space tools under development (ex, formatting tool mkfs.erofs): @@ -113,31 +113,31 @@ may not. All metadatas can be now observed in two different spaces (views): :: - |-> aligned with 8B - |-> followed closely - + meta_blkaddr blocks |-> another slot - _____________________________________________________________________ - | ... | inode | xattrs | extents | data inline | ... | inode ... - |________|_______|(optional)|(optional)|__(optional)_|_____|__________ - |-> aligned with the inode slot size - . . - . . - . . - . . - . . - . . - .____________________________________________________|-> aligned with 4B - | xattr_ibody_header | shared xattrs | inline xattrs | - |____________________|_______________|_______________| - |-> 12 bytes <-|->x * 4 bytes<-| . - . . . - . . . - . . . - ._______________________________.______________________. - | id | id | id | id | ... | id | ent | ... | ent| ... | - |____|____|____|____|______|____|_____|_____|____|_____| - |-> aligned with 4B - |-> aligned with 4B + |-> aligned with 8B + |-> followed closely + + meta_blkaddr blocks |-> another slot + _____________________________________________________________________ + | ... | inode | xattrs | extents | data inline | ... | inode ... + |________|_______|(optional)|(optional)|__(optional)_|_____|__________ + |-> aligned with the inode slot size + . . + . . + . . + . . + . . + . . + .____________________________________________________|-> aligned with 4B + | xattr_ibody_header | shared xattrs | inline xattrs | + |____________________|_______________|_______________| + |-> 12 bytes <-|->x * 4 bytes<-| . + . . . + . . . + . . . + ._______________________________.______________________. + | id | id | id | id | ... | id | ent | ... | ent| ... | + |____|____|____|____|______|____|_____|_____|____|_____| + |-> aligned with 4B + |-> aligned with 4B Inode could be 32 or 64 bytes, which can be distinguished from a common field which all inode versions have -- i_format:: @@ -175,13 +175,13 @@ may not. All metadatas can be now observed in two different spaces (views): Each share xattr can also be directly found by the following formula: xattr offset = xattr_blkaddr * block_size + 4 * xattr_id - :: +:: - |-> aligned by 4 bytes - + xattr_blkaddr blocks |-> aligned with 4 bytes - _________________________________________________________________________ - | ... | xattr_entry | xattr data | ... | xattr_entry | xattr data ... - |________|_____________|_____________|_____|______________|_______________ + |-> aligned by 4 bytes + + xattr_blkaddr blocks |-> aligned with 4 bytes + _________________________________________________________________________ + | ... | xattr_entry | xattr data | ... | xattr_entry | xattr data ... + |________|_____________|_____________|_____|______________|_______________ Directories ----------- @@ -193,48 +193,77 @@ algorithm (could refer to the related source code). :: - ___________________________ - / | - / ______________|________________ - / / | nameoff1 | nameoffN-1 - ____________.______________._______________v________________v__________ - | dirent | dirent | ... | dirent | filename | filename | ... | filename | - |___.0___|____1___|_____|___N-1__|____0_____|____1_____|_____|___N-1____| - \ ^ - \ | * could have - \ | trailing '\0' - \________________________| nameoff0 - - Directory block + ___________________________ + / | + / ______________|________________ + / / | nameoff1 | nameoffN-1 + ____________.______________._______________v________________v__________ + | dirent | dirent | ... | dirent | filename | filename | ... | filename | + |___.0___|____1___|_____|___N-1__|____0_____|____1_____|_____|___N-1____| + \ ^ + \ | * could have + \ | trailing '\0' + \________________________| nameoff0 + Directory block Note that apart from the offset of the first filename, nameoff0 also indicates the total number of directory entries in this block since it is no need to introduce another on-disk field at all. -Compression ------------ -Currently, EROFS supports 4KB fixed-sized output transparent file compression, -as illustrated below:: - - |---- Variant-Length Extent ----|-------- VLE --------|----- VLE ----- - clusterofs clusterofs clusterofs - | | | logical data - _________v_______________________________v_____________________v_______________ - ... | . | | . | | . | ... - ____|____.________|_____________|________.____|_____________|__.__________|____ - |-> cluster <-|-> cluster <-|-> cluster <-|-> cluster <-|-> cluster <-| - size size size size size - . . . . - . . . . - . . . . - _______._____________._____________._____________._____________________ - ... | | | | ... physical data - _______|_____________|_____________|_____________|_____________________ - |-> cluster <-|-> cluster <-|-> cluster <-| - size size size - -Currently each on-disk physical cluster can contain 4KB (un)compressed data -at most. For each logical cluster, there is a corresponding on-disk index to -describe its cluster type, physical cluster address, etc. - -See "struct z_erofs_vle_decompressed_index" in erofs_fs.h for more details. +Data compression +---------------- +EROFS implements LZ4 fixed-sized output compression which generates fixed-sized +compressed data blocks from variable-sized input in contrast to other existing +fixed-sized input solutions. Relatively higher compression ratios can be gotten +by using fixed-sized output compression since nowadays popular data compression +algorithms are mostly LZ77-based and such fixed-sized output approach can be +benefited from the historical dictionary (aka. sliding window). + +In details, original (uncompressed) data is turned into several variable-sized +extents and in the meanwhile, compressed into physical clusters (pclusters). +In order to record each variable-sized extent, logical clusters (lclusters) are +introduced as the basic unit of compress indexes to indicate whether a new +extent is generated within the range (HEAD) or not (NONHEAD). Lclusters are now +fixed in block size, as illustrated below:: + + |<- variable-sized extent ->|<- VLE ->| + clusterofs clusterofs clusterofs + | | | + _________v_________________________________v_______________________v________ + ... | . | | . | | . ... + ____|____._________|______________|________.___ _|______________|__.________ + |-> lcluster <-|-> lcluster <-|-> lcluster <-|-> lcluster <-| + (HEAD) (NONHEAD) (HEAD) (NONHEAD) . + . CBLKCNT . . + . . . + . . . + _______._____________________________.______________._________________ + ... | | | | ... + _______|______________|______________|______________|_________________ + |-> big pcluster <-|-> pcluster <-| + +A physical cluster can be seen as a container of physical compressed blocks +which contains compressed data. Previously, only lcluster-sized (4KB) pclusters +were supported. After big pcluster feature is introduced (available since +Linux v5.13), pcluster can be a multiple of lcluster size. + +For each HEAD lcluster, clusterofs is recorded to indicate where a new extent +starts and blkaddr is used to seek the compressed data. For each NONHEAD +lcluster, delta0 and delta1 are available instead of blkaddr to indicate the +distance to its HEAD lcluster and the next HEAD lcluster. A PLAIN lcluster is +also a HEAD lcluster except that its data is uncompressed. See the comments +around "struct z_erofs_vle_decompressed_index" in erofs_fs.h for more details. + +If big pcluster is enabled, pcluster size in lclusters needs to be recorded as +well. Let the delta0 of the first NONHEAD lcluster store the compressed block +count with a special flag as a new called CBLKCNT NONHEAD lcluster. It's easy +to understand its delta0 is constantly 1, as illustrated below:: + + __________________________________________________________ + | HEAD | NONHEAD | NONHEAD | ... | NONHEAD | HEAD | HEAD | + |__:___|_(CBLKCNT)_|_________|_____|_________|__:___|____:_| + |<----- a big pcluster (with CBLKCNT) ------>|<-- -->| + a lcluster-sized pcluster (without CBLKCNT) ^ + +If another HEAD follows a HEAD lcluster, there is no room to record CBLKCNT, +but it's easy to know the size of such pcluster is 1 lcluster as well. diff --git a/Documentation/filesystems/ext2.rst b/Documentation/filesystems/ext2.rst index c2fce22cfd03..154101cf0e4f 100644 --- a/Documentation/filesystems/ext2.rst +++ b/Documentation/filesystems/ext2.rst @@ -25,7 +25,7 @@ check=none, nocheck (*) Don't do extra checking of bitmaps on mount (check=normal and check=strict options removed) dax Use direct access (no page cache). See - Documentation/filesystems/dax.txt. + Documentation/filesystems/dax.rst. debug Extra debugging information is sent to the kernel syslog. Useful for developers. diff --git a/Documentation/filesystems/ext4/blockgroup.rst b/Documentation/filesystems/ext4/blockgroup.rst index 3da156633339..d5d652addce5 100644 --- a/Documentation/filesystems/ext4/blockgroup.rst +++ b/Documentation/filesystems/ext4/blockgroup.rst @@ -84,7 +84,7 @@ Without the option META\_BG, for safety concerns, all block group descriptors copies are kept in the first block group. Given the default 128MiB(2^27 bytes) block group size and 64-byte group descriptors, ext4 can have at most 2^27/64 = 2^21 block groups. This limits the entire -filesystem size to 2^21 ∗ 2^27 = 2^48bytes or 256TiB. +filesystem size to 2^21 * 2^27 = 2^48bytes or 256TiB. The solution to this problem is to use the metablock group feature (META\_BG), which is already in ext3 for all 2.6 releases. With the diff --git a/Documentation/filesystems/ext4/journal.rst b/Documentation/filesystems/ext4/journal.rst index cdbfec473167..5fad38860f17 100644 --- a/Documentation/filesystems/ext4/journal.rst +++ b/Documentation/filesystems/ext4/journal.rst @@ -4,14 +4,14 @@ Journal (jbd2) -------------- Introduced in ext3, the ext4 filesystem employs a journal to protect the -filesystem against corruption in the case of a system crash. A small -continuous region of disk (default 128MiB) is reserved inside the -filesystem as a place to land “important” data writes on-disk as quickly -as possible. Once the important data transaction is fully written to the -disk and flushed from the disk write cache, a record of the data being -committed is also written to the journal. At some later point in time, -the journal code writes the transactions to their final locations on -disk (this could involve a lot of seeking or a lot of small +filesystem against metadata inconsistencies in the case of a system crash. Up +to 10,240,000 file system blocks (see man mke2fs(8) for more details on journal +size limits) can be reserved inside the filesystem as a place to land +“important” data writes on-disk as quickly as possible. Once the important +data transaction is fully written to the disk and flushed from the disk write +cache, a record of the data being committed is also written to the journal. At +some later point in time, the journal code writes the transactions to their +final locations on disk (this could involve a lot of seeking or a lot of small read-write-erases) before erasing the commit record. Should the system crash during the second slow write, the journal can be replayed all the way to the latest commit record, guaranteeing the atomicity of whatever @@ -731,3 +731,26 @@ point, the refcount for inode 11 is not reliable, but that gets fixed by the replay of last inode 11 tag. Thus, by converting a non-idempotent procedure into a series of idempotent outcomes, fast commits ensured idempotence during the replay. + +Journal Checkpoint +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Checkpointing the journal ensures all transactions and their associated buffers +are submitted to the disk. In-progress transactions are waited upon and included +in the checkpoint. Checkpointing is used internally during critical updates to +the filesystem including journal recovery, filesystem resizing, and freeing of +the journal_t structure. + +A journal checkpoint can be triggered from userspace via the ioctl +EXT4_IOC_CHECKPOINT. This ioctl takes a single, u64 argument for flags. +Currently, three flags are supported. First, EXT4_IOC_CHECKPOINT_FLAG_DRY_RUN +can be used to verify input to the ioctl. It returns error if there is any +invalid input, otherwise it returns success without performing +any checkpointing. This can be used to check whether the ioctl exists on a +system and to verify there are no issues with arguments or flags. The +other two flags are EXT4_IOC_CHECKPOINT_FLAG_DISCARD and +EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT. These flags cause the journal blocks to be +discarded or zero-filled, respectively, after the journal checkpoint is +complete. EXT4_IOC_CHECKPOINT_FLAG_DISCARD and EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT +cannot both be set. The ioctl may be useful when snapshotting a system or for +complying with content deletion SLOs. diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index d4853cb919d2..246af51b277a 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -77,6 +77,7 @@ Documentation for filesystem implementations. coda configfs cramfs + dax debugfs dlmfs ecryptfs diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 1e894480115b..2183fd8cc350 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -480,7 +480,7 @@ prototypes:: locking rules: ======================= =================== -ops bd_mutex +ops open_mutex ======================= =================== open: yes release: yes diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index c482e1619e77..2b2df6aa5432 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -448,15 +448,17 @@ described. If it finds a ``LAST_NORM`` component it first calls filesystem to revalidate the result if it is that sort of filesystem. If that doesn't get a good result, it calls "``lookup_slow()``" which takes ``i_rwsem``, rechecks the cache, and then asks the filesystem -to find a definitive answer. Each of these will call -``follow_managed()`` (as described below) to handle any mount points. - -In the absence of symbolic links, ``walk_component()`` creates a new -``struct path`` containing a counted reference to the new dentry and a -reference to the new ``vfsmount`` which is only counted if it is -different from the previous ``vfsmount``. It then calls -``path_to_nameidata()`` to install the new ``struct path`` in the -``struct nameidata`` and drop the unneeded references. +to find a definitive answer. + +As the last step of walk_component(), step_into() will be called either +directly from walk_component() or from handle_dots(). It calls +handle_mounts(), to check and handle mount points, in which a new +``struct path`` is created containing a counted reference to the new dentry and +a reference to the new ``vfsmount`` which is only counted if it is +different from the previous ``vfsmount``. Then if there is +a symbolic link, step_into() calls pick_link() to deal with it, +otherwise it installs the new ``struct path`` in the ``struct nameidata``, and +drops the unneeded references. This "hand-over-hand" sequencing of getting a reference to the new dentry before dropping the reference to the previous dentry may @@ -470,8 +472,8 @@ Handling the final component ``nd->last_type`` to refer to the final component of the path. It does not call ``walk_component()`` that last time. Handling that final component remains for the caller to sort out. Those callers are -``path_lookupat()``, ``path_parentat()``, ``path_mountpoint()`` and -``path_openat()`` each of which handles the differing requirements of +path_lookupat(), path_parentat() and +path_openat() each of which handles the differing requirements of different system calls. ``path_parentat()`` is clearly the simplest - it just wraps a little bit @@ -486,20 +488,18 @@ perform their operation. object is wanted such as by ``stat()`` or ``chmod()``. It essentially just calls ``walk_component()`` on the final component through a call to ``lookup_last()``. ``path_lookupat()`` returns just the final dentry. - -``path_mountpoint()`` handles the special case of unmounting which must -not try to revalidate the mounted filesystem. It effectively -contains, through a call to ``mountpoint_last()``, an alternate -implementation of ``lookup_slow()`` which skips that step. This is -important when unmounting a filesystem that is inaccessible, such as +It is worth noting that when flag ``LOOKUP_MOUNTPOINT`` is set, +path_lookupat() will unset LOOKUP_JUMPED in nameidata so that in the +subsequent path traversal d_weak_revalidate() won't be called. +This is important when unmounting a filesystem that is inaccessible, such as one provided by a dead NFS server. Finally ``path_openat()`` is used for the ``open()`` system call; it -contains, in support functions starting with "``do_last()``", all the +contains, in support functions starting with "open_last_lookups()", all the complexity needed to handle the different subtleties of O_CREAT (with or without O_EXCL), final "``/``" characters, and trailing symbolic links. We will revisit this in the final part of this series, which -focuses on those symbolic links. "``do_last()``" will sometimes, but +focuses on those symbolic links. "open_last_lookups()" will sometimes, but not always, take ``i_rwsem``, depending on what it finds. Each of these, or the functions which call them, need to be alert to @@ -535,8 +535,7 @@ covered in greater detail in autofs.txt in the Linux documentation tree, but a few notes specifically related to path lookup are in order here. -The Linux VFS has a concept of "managed" dentries which is reflected -in function names such as "``follow_managed()``". There are three +The Linux VFS has a concept of "managed" dentries. There are three potentially interesting things about these dentries corresponding to three different flags that might be set in ``dentry->d_flags``: @@ -652,10 +651,10 @@ RCU-walk finds it cannot stop gracefully, it simply gives up and restarts from the top with REF-walk. This pattern of "try RCU-walk, if that fails try REF-walk" can be -clearly seen in functions like ``filename_lookup()``, -``filename_parentat()``, ``filename_mountpoint()``, -``do_filp_open()``, and ``do_file_open_root()``. These five -correspond roughly to the four ``path_*()`` functions we met earlier, +clearly seen in functions like filename_lookup(), +filename_parentat(), +do_filp_open(), and do_file_open_root(). These four +correspond roughly to the three ``path_*()`` functions we met earlier, each of which calls ``link_path_walk()``. The ``path_*()`` functions are called using different mode flags until a mode is found which works. They are first called with ``LOOKUP_RCU`` set to request "RCU-walk". If @@ -993,8 +992,8 @@ is 4096. There are a number of reasons for this limit; not letting the kernel spend too much time on just one path is one of them. With symbolic links you can effectively generate much longer paths so some sort of limit is needed for the same reason. Linux imposes a limit of -at most 40 symlinks in any one path lookup. It previously imposed a -further limit of eight on the maximum depth of recursion, but that was +at most 40 (MAXSYMLINKS) symlinks in any one path lookup. It previously imposed +a further limit of eight on the maximum depth of recursion, but that was raised to 40 when a separate stack was implemented, so there is now just the one limit. @@ -1061,42 +1060,26 @@ filesystem cannot successfully get a reference in RCU-walk mode, it must return ``-ECHILD`` and ``unlazy_walk()`` will be called to return to REF-walk mode in which the filesystem is allowed to sleep. -The place for all this to happen is the ``i_op->follow_link()`` inode -method. In the present mainline code this is never actually called in -RCU-walk mode as the rewrite is not quite complete. It is likely that -in a future release this method will be passed an ``inode`` pointer when -called in RCU-walk mode so it both (1) knows to be careful, and (2) has the -validated pointer. Much like the ``i_op->permission()`` method we -looked at previously, ``->follow_link()`` would need to be careful that +The place for all this to happen is the ``i_op->get_link()`` inode +method. This is called both in RCU-walk and REF-walk. In RCU-walk the +``dentry*`` argument is NULL, ``->get_link()`` can return -ECHILD to drop out of +RCU-walk. Much like the ``i_op->permission()`` method we +looked at previously, ``->get_link()`` would need to be careful that all the data structures it references are safe to be accessed while -holding no counted reference, only the RCU lock. Though getting a -reference with ``->follow_link()`` is not yet done in RCU-walk mode, the -code is ready to release the reference when that does happen. - -This need to drop the reference to a symlink adds significant -complexity. It requires a reference to the inode so that the -``i_op->put_link()`` inode operation can be called. In REF-walk, that -reference is kept implicitly through a reference to the dentry, so -keeping the ``struct path`` of the symlink is easiest. For RCU-walk, -the pointer to the inode is kept separately. To allow switching from -RCU-walk back to REF-walk in the middle of processing nested symlinks -we also need the seq number for the dentry so we can confirm that -switching back was safe. - -Finally, when providing a reference to a symlink, the filesystem also -provides an opaque "cookie" that must be passed to ``->put_link()`` so that it -knows what to free. This might be the allocated memory area, or a -pointer to the ``struct page`` in the page cache, or something else -completely. Only the filesystem knows what it is. +holding no counted reference, only the RCU lock. A callback +``struct delayed_called`` will be passed to ``->get_link()``: +file systems can set their own put_link function and argument through +set_delayed_call(). Later on, when VFS wants to put link, it will call +do_delayed_call() to invoke that callback function with the argument. In order for the reference to each symlink to be dropped when the walk completes, whether in RCU-walk or REF-walk, the symlink stack needs to contain, along with the path remnants: -- the ``struct path`` to provide a reference to the inode in REF-walk -- the ``struct inode *`` to provide a reference to the inode in RCU-walk +- the ``struct path`` to provide a reference to the previous path +- the ``const char *`` to provide a reference to the to previous name - the ``seq`` to allow the path to be safely switched from RCU-walk to REF-walk -- the ``cookie`` that tells ``->put_path()`` what to put. +- the ``struct delayed_call`` for later invocation. This means that each entry in the symlink stack needs to hold five pointers and an integer instead of just one pointer (the path @@ -1120,12 +1103,10 @@ doesn't need to notice. Getting this ``name`` variable on and off the stack is very straightforward; pushing and popping the references is a little more complex. -When a symlink is found, ``walk_component()`` returns the value ``1`` -(``0`` is returned for any other sort of success, and a negative number -is, as usual, an error indicator). This causes ``get_link()`` to be -called; it then gets the link from the filesystem. Providing that -operation is successful, the old path ``name`` is placed on the stack, -and the new value is used as the ``name`` for a while. When the end of +When a symlink is found, walk_component() calls pick_link() via step_into() +which returns the link from the filesystem. +Providing that operation is successful, the old path ``name`` is placed on the +stack, and the new value is used as the ``name`` for a while. When the end of the path is found (i.e. ``*name`` is ``'\0'``) the old ``name`` is restored off the stack and path walking continues. @@ -1142,23 +1123,23 @@ stack in ``walk_component()`` immediately when the symlink is found; old symlink as it walks that last component. So it is quite convenient for ``walk_component()`` to release the old symlink and pop the references just before pushing the reference information for the -new symlink. It is guided in this by two flags; ``WALK_GET``, which -gives it permission to follow a symlink if it finds one, and -``WALK_PUT``, which tells it to release the current symlink after it has been -followed. ``WALK_PUT`` is tested first, leading to a call to -``put_link()``. ``WALK_GET`` is tested subsequently (by -``should_follow_link()``) leading to a call to ``pick_link()`` which sets -up the stack frame. +new symlink. It is guided in this by three flags: ``WALK_NOFOLLOW`` which +forbids it from following a symlink if it finds one, ``WALK_MORE`` +which indicates that it is yet too early to release the +current symlink, and ``WALK_TRAILING`` which indicates that it is on the final +component of the lookup, so we will check userspace flag ``LOOKUP_FOLLOW`` to +decide whether follow it when it is a symlink and call ``may_follow_link()`` to +check if we have privilege to follow it. Symlinks with no final component ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A pair of special-case symlinks deserve a little further explanation. Both result in a new ``struct path`` (with mount and dentry) being set -up in the ``nameidata``, and result in ``get_link()`` returning ``NULL``. +up in the ``nameidata``, and result in pick_link() returning ``NULL``. The more obvious case is a symlink to "``/``". All symlinks starting -with "``/``" are detected in ``get_link()`` which resets the ``nameidata`` +with "``/``" are detected in pick_link() which resets the ``nameidata`` to point to the effective filesystem root. If the symlink only contains "``/``" then there is nothing more to do, no components at all, so ``NULL`` is returned to indicate that the symlink can be released and @@ -1175,12 +1156,11 @@ something that looks like a symlink. It is really a reference to the target file, not just the name of it. When you ``readlink`` these objects you get a name that might refer to the same file - unless it has been unlinked or mounted over. When ``walk_component()`` follows -one of these, the ``->follow_link()`` method in "procfs" doesn't return -a string name, but instead calls ``nd_jump_link()`` which updates the -``nameidata`` in place to point to that target. ``->follow_link()`` then -returns ``NULL``. Again there is no final component and ``get_link()`` -reports this by leaving the ``last_type`` field of ``nameidata`` as -``LAST_BIND``. +one of these, the ``->get_link()`` method in "procfs" doesn't return +a string name, but instead calls nd_jump_link() which updates the +``nameidata`` in place to point to that target. ``->get_link()`` then +returns ``NULL``. Again there is no final component and pick_link() +returns ``NULL``. Following the symlink in the final component -------------------------------------------- @@ -1197,42 +1177,38 @@ potentially need to call ``link_path_walk()`` again and again on successive symlinks until one is found that doesn't point to another symlink. -This case is handled by the relevant caller of ``link_path_walk()``, such as -``path_lookupat()`` using a loop that calls ``link_path_walk()``, and then -handles the final component. If the final component is a symlink -that needs to be followed, then ``trailing_symlink()`` is called to set -things up properly and the loop repeats, calling ``link_path_walk()`` -again. This could loop as many as 40 times if the last component of -each symlink is another symlink. - -The various functions that examine the final component and possibly -report that it is a symlink are ``lookup_last()``, ``mountpoint_last()`` -and ``do_last()``, each of which use the same convention as -``walk_component()`` of returning ``1`` if a symlink was found that needs -to be followed. - -Of these, ``do_last()`` is the most interesting as it is used for -opening a file. Part of ``do_last()`` runs with ``i_rwsem`` held and this -part is in a separate function: ``lookup_open()``. - -Explaining ``do_last()`` completely is beyond the scope of this article, -but a few highlights should help those interested in exploring the -code. - -1. Rather than just finding the target file, ``do_last()`` needs to open +This case is handled by relevant callers of link_path_walk(), such as +path_lookupat(), path_openat() using a loop that calls link_path_walk(), +and then handles the final component by calling open_last_lookups() or +lookup_last(). If it is a symlink that needs to be followed, +open_last_lookups() or lookup_last() will set things up properly and +return the path so that the loop repeats, calling +link_path_walk() again. This could loop as many as 40 times if the last +component of each symlink is another symlink. + +Of the various functions that examine the final component, +open_last_lookups() is the most interesting as it works in tandem +with do_open() for opening a file. Part of open_last_lookups() runs +with ``i_rwsem`` held and this part is in a separate function: lookup_open(). + +Explaining open_last_lookups() and do_open() completely is beyond the scope +of this article, but a few highlights should help those interested in exploring +the code. + +1. Rather than just finding the target file, do_open() is used after + open_last_lookup() to open it. If the file was found in the dcache, then ``vfs_open()`` is used for this. If not, then ``lookup_open()`` will either call ``atomic_open()`` (if the filesystem provides it) to combine the final lookup with the open, or - will perform the separate ``lookup_real()`` and ``vfs_create()`` steps + will perform the separate ``i_op->lookup()`` and ``i_op->create()`` steps directly. In the later case the actual "open" of this newly found or - created file will be performed by ``vfs_open()``, just as if the name + created file will be performed by vfs_open(), just as if the name were found in the dcache. -2. ``vfs_open()`` can fail with ``-EOPENSTALE`` if the cached information - wasn't quite current enough. Rather than restarting the lookup from - the top with ``LOOKUP_REVAL`` set, ``lookup_open()`` is called instead, - giving the filesystem a chance to resolve small inconsistencies. - If that doesn't work, only then is the lookup restarted from the top. +2. vfs_open() can fail with ``-EOPENSTALE`` if the cached information + wasn't quite current enough. If it's in RCU-walk ``-ECHILD`` will be returned + otherwise ``-ESTALE`` is returned. When ``-ESTALE`` is returned, the caller may + retry with ``LOOKUP_REVAL`` flag set. 3. An open with O_CREAT **does** follow a symlink in the final component, unlike other creation system calls (like ``mkdir``). So the sequence:: @@ -1242,8 +1218,8 @@ code. will create a file called ``/tmp/bar``. This is not permitted if ``O_EXCL`` is set but otherwise is handled for an O_CREAT open much - like for a non-creating open: ``should_follow_link()`` returns ``1``, and - so does ``do_last()`` so that ``trailing_symlink()`` gets called and the + like for a non-creating open: lookup_last() or open_last_lookup() + returns a non ``NULL`` value, and link_path_walk() gets called and the open process continues on the symlink that was found. Updating the access time @@ -1321,18 +1297,18 @@ to lookup: RCU-walk, REF-walk, and REF-walk with forced revalidation. yet. This is primarily used to tell the audit subsystem the full context of a particular access being audited. -``LOOKUP_ROOT`` indicates that the ``root`` field in the ``nameidata`` was +``ND_ROOT_PRESET`` indicates that the ``root`` field in the ``nameidata`` was provided by the caller, so it shouldn't be released when it is no longer needed. -``LOOKUP_JUMPED`` means that the current dentry was chosen not because +``ND_JUMPED`` means that the current dentry was chosen not because it had the right name but for some other reason. This happens when following "``..``", following a symlink to ``/``, crossing a mount point or accessing a "``/proc/$PID/fd/$FD``" symlink (also known as a "magic link"). In this case the filesystem has not been asked to revalidate the name (with ``d_revalidate()``). In such cases the inode may still need to be revalidated, so ``d_op->d_weak_revalidate()`` is called if -``LOOKUP_JUMPED`` is set when the look completes - which may be at the +``ND_JUMPED`` is set when the look completes - which may be at the final component or, when creating, unlinking, or renaming, at the penultimate component. Resolution-restriction flags diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index 0302035781be..bf19fd6b86e7 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -890,3 +890,21 @@ been called or returned with non -EIOCBQUEUED code. mnt_want_write_file() can now only be paired with mnt_drop_write_file(), whereas previously it could be paired with mnt_drop_write() as well. + +--- + +**mandatory** + +iov_iter_copy_from_user_atomic() is gone; use copy_page_from_iter_atomic(). +The difference is copy_page_from_iter_atomic() advances the iterator and +you don't need iov_iter_advance() after it. However, if you decide to use +only a part of obtained data, you should do iov_iter_revert(). + +--- + +**mandatory** + +Calling conventions for file_open_root() changed; now it takes struct path * +instead of passing mount and dentry separately. For callers that used to +pass <mnt, mnt->mnt_root> pair (i.e. the root of given mount), a new helper +is provided - file_open_root_mnt(). In-tree users adjusted. diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 81bfe3c800cc..042c418f4090 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -933,8 +933,15 @@ meminfo ~~~~~~~ Provides information about distribution and utilization of memory. This -varies by architecture and compile options. The following is from a -16GB PIII, which has highmem enabled. You may not have all of these fields. +varies by architecture and compile options. Some of the counters reported +here overlap. The memory reported by the non overlapping counters may not +add up to the overall memory usage and the difference for some workloads +can be substantial. In many cases there are other means to find out +additional memory using subsystem specific interfaces, for instance +/proc/net/sockstat for TCP memory allocations. + +The following is from a 16GB PIII, which has highmem enabled. +You may not have all of these fields. :: @@ -1913,18 +1920,20 @@ if precise results are needed. 3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file --------------------------------------------------------------- This file provides information associated with an opened file. The regular -files have at least three fields -- 'pos', 'flags' and 'mnt_id'. The 'pos' -represents the current offset of the opened file in decimal form [see lseek(2) -for details], 'flags' denotes the octal O_xxx mask the file has been -created with [see open(2) for details] and 'mnt_id' represents mount ID of -the file system containing the opened file [see 3.5 /proc/<pid>/mountinfo -for details]. +files have at least four fields -- 'pos', 'flags', 'mnt_id' and 'ino'. +The 'pos' represents the current offset of the opened file in decimal +form [see lseek(2) for details], 'flags' denotes the octal O_xxx mask the +file has been created with [see open(2) for details] and 'mnt_id' represents +mount ID of the file system containing the opened file [see 3.5 +/proc/<pid>/mountinfo for details]. 'ino' represents the inode number of +the file. A typical output is:: pos: 0 flags: 0100002 mnt_id: 19 + ino: 63107 All locks associated with a file descriptor are shown in its fdinfo too:: @@ -1941,6 +1950,7 @@ Eventfd files pos: 0 flags: 04002 mnt_id: 9 + ino: 63107 eventfd-count: 5a where 'eventfd-count' is hex value of a counter. @@ -1953,6 +1963,7 @@ Signalfd files pos: 0 flags: 04002 mnt_id: 9 + ino: 63107 sigmask: 0000000000000200 where 'sigmask' is hex value of the signal mask associated @@ -1966,6 +1977,7 @@ Epoll files pos: 0 flags: 02 mnt_id: 9 + ino: 63107 tfd: 5 events: 1d data: ffffffffffffffff pos:0 ino:61af sdev:7 where 'tfd' is a target file descriptor number in decimal form, @@ -1982,6 +1994,8 @@ For inotify files the format is the following:: pos: 0 flags: 02000000 + mnt_id: 9 + ino: 63107 inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7e9e0000640d1b6d where 'wd' is a watch descriptor in decimal form, i.e. a target file @@ -2004,6 +2018,7 @@ For fanotify files the format is:: pos: 0 flags: 02 mnt_id: 9 + ino: 63107 fanotify flags:10 event-flags:0 fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003 fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4 @@ -2028,6 +2043,7 @@ Timerfd files pos: 0 flags: 02 mnt_id: 9 + ino: 63107 clockid: 0 ticks: 0 settime flags: 01 @@ -2042,6 +2058,22 @@ details]. 'it_value' is remaining time until the timer expiration. with TIMER_ABSTIME option which will be shown in 'settime flags', but 'it_value' still exhibits timer's remaining time. +DMA Buffer files +~~~~~~~~~~~~~~~~ + +:: + + pos: 0 + flags: 04002 + mnt_id: 9 + ino: 63107 + size: 32768 + count: 2 + exp_name: system-heap + +where 'size' is the size of the DMA buffer in bytes. 'count' is the file count of +the DMA buffer file. 'exp_name' is the name of the DMA buffer exporter. + 3.9 /proc/<pid>/map_files - Information about memory mapped files --------------------------------------------------------------------- This directory contains symbolic links which represent memory mapped files diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst index 9b17dc77d18c..b7ad47df49de 100644 --- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst +++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst @@ -79,7 +79,8 @@ the ANOD object which is also the final target node of the reference. }) } -Please also see a graph example in :doc:`graph`. +Please also see a graph example in +Documentation/firmware-guide/acpi/dsd/graph.rst. References ========== diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst b/Documentation/firmware-guide/acpi/dsd/graph.rst index 7072db801aeb..4341299aa937 100644 --- a/Documentation/firmware-guide/acpi/dsd/graph.rst +++ b/Documentation/firmware-guide/acpi/dsd/graph.rst @@ -174,4 +174,4 @@ References referenced 2016-10-04. [7] _DSD Device Properties Usage Rules. - :doc:`../DSD-properties-rules` + Documentation/firmware-guide/acpi/DSD-properties-rules.rst diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst b/Documentation/firmware-guide/acpi/dsd/phy.rst new file mode 100644 index 000000000000..680ad179e5f9 --- /dev/null +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst @@ -0,0 +1,199 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +MDIO bus and PHYs in ACPI +========================= + +The PHYs on an MDIO bus [1] are probed and registered using +fwnode_mdiobus_register_phy(). + +Later, for connecting these PHYs to their respective MACs, the PHYs registered +on the MDIO bus have to be referenced. + +This document introduces two _DSD properties that are to be used +for connecting PHYs on the MDIO bus [3] to the MAC layer. + +These properties are defined in accordance with the "Device +Properties UUID For _DSD" [2] document and the +daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device +Data Descriptors containing them. + +phy-handle +---------- +For each MAC node, a device property "phy-handle" is used to reference +the PHY that is registered on an MDIO bus. This is mandatory for +network interfaces that have PHYs connected to MAC via MDIO bus. + +During the MDIO bus driver initialization, PHYs on this bus are probed +using the _ADR object as shown below and are registered on the MDIO bus. + +.. code-block:: none + + Scope(\_SB.MDI0) + { + Device(PHY1) { + Name (_ADR, 0x1) + } // end of PHY1 + + Device(PHY2) { + Name (_ADR, 0x2) + } // end of PHY2 + } + +Later, during the MAC driver initialization, the registered PHY devices +have to be retrieved from the MDIO bus. For this, the MAC driver needs +references to the previously registered PHYs which are provided +as device object references (e.g. \_SB.MDI0.PHY1). + +phy-mode +-------- +The "phy-mode" _DSD property is used to describe the connection to +the PHY. The valid values for "phy-mode" are defined in [4]. + +managed +------- +Optional property, which specifies the PHY management type. +The valid values for "managed" are defined in [4]. + +fixed-link +---------- +The "fixed-link" is described by a data-only subnode of the +MAC port, which is linked in the _DSD package via +hierarchical data extension (UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b +in accordance with [5] "_DSD Implementation Guide" document). +The subnode should comprise a required property ("speed") and +possibly the optional ones - complete list of parameters and +their values are specified in [4]. + +The following ASL example illustrates the usage of these properties. + +DSDT entry for MDIO node +------------------------ + +The MDIO bus has an SoC component (MDIO controller) and a platform +component (PHYs on the MDIO bus). + +a) Silicon Component +This node describes the MDIO controller, MDI0 +--------------------------------------------- + +.. code-block:: none + + Scope(_SB) + { + Device(MDI0) { + Name(_HID, "NXP0006") + Name(_CCA, 1) + Name(_UID, 0) + Name(_CRS, ResourceTemplate() { + Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN) + Interrupt(ResourceConsumer, Level, ActiveHigh, Shared) + { + MDI0_IT + } + }) // end of _CRS for MDI0 + } // end of MDI0 + } + +b) Platform Component +The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0 +--------------------------------------------------------------------- + +.. code-block:: none + + Scope(\_SB.MDI0) + { + Device(PHY1) { + Name (_ADR, 0x1) + } // end of PHY1 + + Device(PHY2) { + Name (_ADR, 0x2) + } // end of PHY2 + } + +DSDT entries representing MAC nodes +----------------------------------- + +Below are the MAC nodes where PHY nodes are referenced. +phy-mode and phy-handle are used as explained earlier. +------------------------------------------------------ + +.. code-block:: none + + Scope(\_SB.MCE0.PR17) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package (2) {"phy-mode", "rgmii-id"}, + Package (2) {"phy-handle", \_SB.MDI0.PHY1} + } + }) + } + + Scope(\_SB.MCE0.PR18) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package (2) {"phy-mode", "rgmii-id"}, + Package (2) {"phy-handle", \_SB.MDI0.PHY2}} + } + }) + } + +MAC node example where "managed" property is specified. +------------------------------------------------------- + +.. code-block:: none + + Scope(\_SB.PP21.ETH0) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"phy-mode", "sgmii"}, + Package () {"managed", "in-band-status"} + } + }) + } + +MAC node example with a "fixed-link" subnode. +--------------------------------------------- + +.. code-block:: none + + Scope(\_SB.PP21.ETH1) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"phy-mode", "sgmii"}, + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () {"fixed-link", "LNK0"} + } + }) + Name (LNK0, Package(){ // Data-only subnode of port + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"speed", 1000}, + Package () {"full-duplex", 1} + } + }) + } + +References +========== + +[1] Documentation/networking/phy.rst + +[2] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf + +[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst + +[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml + +[5] https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 9f0d5c854fa4..18074eb71860 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -339,8 +339,8 @@ a code like this:: There are also devm_* versions of these functions which release the descriptors once the device is released. -See Documentation/firmware-guide/acpi/gpio-properties.rst for more information about the -_DSD binding related to GPIOs. +See Documentation/firmware-guide/acpi/gpio-properties.rst for more information +about the _DSD binding related to GPIOs. MFD devices =========== @@ -460,7 +460,8 @@ the _DSD of the device object itself or the _DSD of its ancestor in the Otherwise, the _DSD itself is regarded as invalid and therefore the "compatible" property returned by it is meaningless. -Refer to :doc:`DSD-properties-rules` for more information. +Refer to Documentation/firmware-guide/acpi/DSD-properties-rules.rst for more +information. PCI hierarchy representation ============================ diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index f72b5f1769fb..a99ee402b212 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -11,6 +11,7 @@ ACPI Support dsd/graph dsd/data-node-references dsd/leds + dsd/phy enumeration osi method-customizing diff --git a/Documentation/gpu/amdgpu-dc.rst b/Documentation/gpu/amdgpu-dc.rst index cc89b0fc11df..f7ff7e1309de 100644 --- a/Documentation/gpu/amdgpu-dc.rst +++ b/Documentation/gpu/amdgpu-dc.rst @@ -66,3 +66,9 @@ Display Core ============ **WIP** + +FreeSync Video +-------------- + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: FreeSync Video diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst index 2062a6023678..364680cdad2e 100644 --- a/Documentation/gpu/amdgpu.rst +++ b/Documentation/gpu/amdgpu.rst @@ -300,4 +300,25 @@ pcie_replay_count .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c :doc: pcie_replay_count ++GPU SmartShift Information +============================ + +GPU SmartShift information via sysfs + +smartshift_apu_power +-------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_apu_power +smartshift_dgpu_power +--------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_dgpu_power + +smartshift_bias +--------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_bias diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst new file mode 100644 index 000000000000..4411e6919a3d --- /dev/null +++ b/Documentation/gpu/driver-uapi.rst @@ -0,0 +1,8 @@ +=============== +DRM Driver uAPI +=============== + +drm/i915 uAPI +============= + +.. kernel-doc:: include/uapi/drm/i915_drm.h diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 12272b168580..06af044c882f 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -75,6 +75,18 @@ update it, its value is mostly useless. The DRM core prints it to the kernel log at initialization time and passes it to userspace through the DRM_IOCTL_VERSION ioctl. +Managing Ownership of the Framebuffer Aperture +---------------------------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_aperture.c + :doc: overview + +.. kernel-doc:: include/drm/drm_aperture.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_aperture.c + :export: + Device Instance and Driver Handling ----------------------------------- diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 21be6deadc12..d5a73fa2c9ef 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -469,8 +469,8 @@ DRM MM Range Allocator Function References .. kernel-doc:: drivers/gpu/drm/drm_mm.c :export: -DRM Cache Handling -================== +DRM Cache Handling and Fast WC memcpy() +======================================= .. kernel-doc:: drivers/gpu/drm/drm_cache.c :export: diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 486c720f3890..42ce0196930a 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -210,13 +210,13 @@ DPIO .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c :doc: DPIO -CSR firmware support for DMC ----------------------------- +DMC Firmware Support +-------------------- -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c - :doc: csr support for dmc +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c + :doc: DMC Firmware Support -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c :internal: Video BIOS Table (VBT) @@ -537,7 +537,7 @@ The HuC FW layout is the same as the GuC one, see `GuC Firmware Layout`_ DMC --- -See `CSR firmware support for DMC`_ +See `DMC Firmware Support`_ Tracing ======= diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index ec4bc72438e4..b9c1214d8f23 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide drm-kms drm-kms-helpers drm-uapi + driver-uapi drm-client drivers backlight diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst b/Documentation/gpu/rfc/i915_gem_lmem.rst new file mode 100644 index 000000000000..675ba8620d66 --- /dev/null +++ b/Documentation/gpu/rfc/i915_gem_lmem.rst @@ -0,0 +1,131 @@ +========================= +I915 DG1/LMEM RFC Section +========================= + +Upstream plan +============= +For upstream the overall plan for landing all the DG1 stuff and turning it for +real, with all the uAPI bits is: + +* Merge basic HW enabling of DG1(still without pciid) +* Merge the uAPI bits behind special CONFIG_BROKEN(or so) flag + * At this point we can still make changes, but importantly this lets us + start running IGTs which can utilize local-memory in CI +* Convert over to TTM, make sure it all keeps working. Some of the work items: + * TTM shrinker for discrete + * dma_resv_lockitem for full dma_resv_lock, i.e not just trylock + * Use TTM CPU pagefault handler + * Route shmem backend over to TTM SYSTEM for discrete + * TTM purgeable object support + * Move i915 buddy allocator over to TTM + * MMAP ioctl mode(see `I915 MMAP`_) + * SET/GET ioctl caching(see `I915 SET/GET CACHING`_) +* Send RFC(with mesa-dev on cc) for final sign off on the uAPI +* Add pciid for DG1 and turn on uAPI for real + +New object placement and region query uAPI +========================================== +Starting from DG1 we need to give userspace the ability to allocate buffers from +device local-memory. Currently the driver supports gem_create, which can place +buffers in system memory via shmem, and the usual assortment of other +interfaces, like dumb buffers and userptr. + +To support this new capability, while also providing a uAPI which will work +beyond just DG1, we propose to offer three new bits of uAPI: + +DRM_I915_QUERY_MEMORY_REGIONS +----------------------------- +New query ID which allows userspace to discover the list of supported memory +regions(like system-memory and local-memory) for a given device. We identify +each region with a class and instance pair, which should be unique. The class +here would be DEVICE or SYSTEM, and the instance would be zero, on platforms +like DG1. + +Side note: The class/instance design is borrowed from our existing engine uAPI, +where we describe every physical engine in terms of its class, and the +particular instance, since we can have more than one per class. + +In the future we also want to expose more information which can further +describe the capabilities of a region. + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :functions: drm_i915_gem_memory_class drm_i915_gem_memory_class_instance drm_i915_memory_region_info drm_i915_query_memory_regions + +GEM_CREATE_EXT +-------------- +New ioctl which is basically just gem_create but now allows userspace to provide +a chain of possible extensions. Note that if we don't provide any extensions and +set flags=0 then we get the exact same behaviour as gem_create. + +Side note: We also need to support PXP[1] in the near future, which is also +applicable to integrated platforms, and adds its own gem_create_ext extension, +which basically lets userspace mark a buffer as "protected". + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :functions: drm_i915_gem_create_ext + +I915_GEM_CREATE_EXT_MEMORY_REGIONS +---------------------------------- +Implemented as an extension for gem_create_ext, we would now allow userspace to +optionally provide an immutable list of preferred placements at creation time, +in priority order, for a given buffer object. For the placements we expect +them each to use the class/instance encoding, as per the output of the regions +query. Having the list in priority order will be useful in the future when +placing an object, say during eviction. + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :functions: drm_i915_gem_create_ext_memory_regions + +One fair criticism here is that this seems a little over-engineered[2]. If we +just consider DG1 then yes, a simple gem_create.flags or something is totally +all that's needed to tell the kernel to allocate the buffer in local-memory or +whatever. However looking to the future we need uAPI which can also support +upcoming Xe HP multi-tile architecture in a sane way, where there can be +multiple local-memory instances for a given device, and so using both class and +instance in our uAPI to describe regions is desirable, although specifically +for DG1 it's uninteresting, since we only have a single local-memory instance. + +Existing uAPI issues +==================== +Some potential issues we still need to resolve. + +I915 MMAP +--------- +In i915 there are multiple ways to MMAP GEM object, including mapping the same +object using different mapping types(WC vs WB), i.e multiple active mmaps per +object. TTM expects one MMAP at most for the lifetime of the object. If it +turns out that we have to backpedal here, there might be some potential +userspace fallout. + +I915 SET/GET CACHING +-------------------- +In i915 we have set/get_caching ioctl. TTM doesn't let us to change this, but +DG1 doesn't support non-snooped pcie transactions, so we can just always +allocate as WB for smem-only buffers. If/when our hw gains support for +non-snooped pcie transactions then we must fix this mode at allocation time as +a new GEM extension. + +This is related to the mmap problem, because in general (meaning, when we're +not running on intel cpus) the cpu mmap must not, ever, be inconsistent with +allocation mode. + +Possible idea is to let the kernel picks the mmap mode for userspace from the +following table: + +smem-only: WB. Userspace does not need to call clflush. + +smem+lmem: We only ever allow a single mode, so simply allocate this as uncached +memory, and always give userspace a WC mapping. GPU still does snooped access +here(assuming we can't turn it off like on DG1), which is a bit inefficient. + +lmem only: always WC + +This means on discrete you only get a single mmap mode, all others must be +rejected. That's probably going to be a new default mode or something like +that. + +Links +===== +[1] https://patchwork.freedesktop.org/series/86798/ + +[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5599#note_553791 diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index a8621f7dab8b..05670442ca1b 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -15,3 +15,7 @@ host such documentation: * Once the code has landed move all the documentation to the right places in the main core, helper or driver sections. + +.. toctree:: + + i915_gem_lmem.rst diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7ff9fac10d8b..12e61869939e 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -546,6 +546,8 @@ There's a bunch of issues with it: this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. +Previous RFC that hasn't landed yet: https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karugax@gmail.com/ + Contact: Daniel Vetter Level: Intermediate diff --git a/Documentation/hwmon/adm1177.rst b/Documentation/hwmon/adm1177.rst index 471be1e98d6f..1c85a2af92bf 100644 --- a/Documentation/hwmon/adm1177.rst +++ b/Documentation/hwmon/adm1177.rst @@ -20,7 +20,8 @@ Usage Notes ----------- This driver does not auto-detect devices. You will have to instantiate the -devices explicitly. Please see :doc:`/i2c/instantiating-devices` for details. +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst +for details. Sysfs entries diff --git a/Documentation/hwmon/dps920ab.rst b/Documentation/hwmon/dps920ab.rst new file mode 100644 index 000000000000..c33b4cdc0a60 --- /dev/null +++ b/Documentation/hwmon/dps920ab.rst @@ -0,0 +1,73 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver dps920ab +======================== + +Supported chips: + + * Delta DPS920AB + + Prefix: 'dps920ab' + + Addresses scanned: - + +Authors: + Robert Marko <robert.marko@sartura.hr> + + +Description +----------- + +This driver implements support for Delta DPS920AB 920W 54V DC single output +power supply with PMBus support. + +The driver is a client driver to the core PMBus driver. +Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers. + + +Usage Notes +----------- + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for +details. + + +Sysfs entries +------------- + +======================= ====================================================== +curr1_label "iin" +curr1_input Measured input current +curr1_alarm Input current high alarm + +curr2_label "iout1" +curr2_input Measured output current +curr2_max Maximum output current +curr2_rated_max Maximum rated output current + +in1_label "vin" +in1_input Measured input voltage +in1_alarm Input voltage alarm + +in2_label "vout1" +in2_input Measured output voltage +in2_rated_min Minimum rated output voltage +in2_rated_max Maximum rated output voltage +in2_alarm Output voltage alarm + +power1_label "pin" +power1_input Measured input power +power1_alarm Input power high alarm + +power2_label "pout1" +power2_input Measured output power +power2_rated_max Maximum rated output power + +temp[1-3]_input Measured temperature +temp[1-3]_alarm Temperature alarm + +fan1_alarm Fan 1 warning. +fan1_fault Fan 1 fault. +fan1_input Fan 1 speed in RPM. +======================= ====================================================== diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 9ed60fa84cbe..bc01601ea81a 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -53,6 +53,7 @@ Hardware Monitoring Kernel Drivers da9055 dell-smm-hwmon dme1737 + dps920ab drivetemp ds1621 ds620 @@ -137,6 +138,7 @@ Hardware Monitoring Kernel Drivers mcp3021 menf21bmc mlxreg-fan + mp2888 mp2975 nct6683 nct6775 @@ -150,6 +152,7 @@ Hardware Monitoring Kernel Drivers pc87360 pc87427 pcf8591 + pim4328 pm6764tr pmbus powr1220 @@ -164,6 +167,7 @@ Hardware Monitoring Kernel Drivers sht15 sht21 sht3x + sht4x shtc1 sis5595 sl28cpld diff --git a/Documentation/hwmon/ir36021.rst b/Documentation/hwmon/ir36021.rst index ca3436b04e20..1faa85c39f1b 100644 --- a/Documentation/hwmon/ir36021.rst +++ b/Documentation/hwmon/ir36021.rst @@ -19,7 +19,7 @@ Authors: Description ----------- -The IR36021 is a dual‐loop digital multi‐phase buck controller designed for +The IR36021 is a dual-loop digital multi-phase buck controller designed for point of load applications. Usage Notes diff --git a/Documentation/hwmon/lm75.rst b/Documentation/hwmon/lm75.rst index 81257d5fc48f..8d0ab4ad5fb5 100644 --- a/Documentation/hwmon/lm75.rst +++ b/Documentation/hwmon/lm75.rst @@ -93,9 +93,9 @@ Supported chips: https://www.st.com/resource/en/datasheet/stlm75.pdf - * Texas Instruments TMP100, TMP101, TMP105, TMP112, TMP75, TMP75B, TMP75C, TMP175, TMP275 + * Texas Instruments TMP100, TMP101, TMP105, TMP112, TMP75, TMP75B, TMP75C, TMP175, TMP275, TMP1075 - Prefixes: 'tmp100', 'tmp101', 'tmp105', 'tmp112', 'tmp175', 'tmp75', 'tmp75b', 'tmp75c', 'tmp275' + Prefixes: 'tmp100', 'tmp101', 'tmp105', 'tmp112', 'tmp175', 'tmp75', 'tmp75b', 'tmp75c', 'tmp275', 'tmp1075' Addresses scanned: none @@ -119,6 +119,8 @@ Supported chips: https://www.ti.com/product/tmp275 + https://www.ti.com/product/TMP1075 + * NXP LM75B, PCT2075 Prefix: 'lm75b', 'pct2075' diff --git a/Documentation/hwmon/ltc2992.rst b/Documentation/hwmon/ltc2992.rst index 46aa1aa84a1a..a0bcd867a0f5 100644 --- a/Documentation/hwmon/ltc2992.rst +++ b/Documentation/hwmon/ltc2992.rst @@ -19,7 +19,7 @@ This driver supports hardware monitoring for Linear Technology LTC2992 power mon LTC2992 is a rail-to-rail system monitor that measures current, voltage, and power of two supplies. -Two ADCs simultaneously measure each supply’s current. A third ADC monitors +Two ADCs simultaneously measure each supply's current. A third ADC monitors the input voltages and four auxiliary external voltages. diff --git a/Documentation/hwmon/max31790.rst b/Documentation/hwmon/max31790.rst index f301385d8cef..7b097c3b9b90 100644 --- a/Documentation/hwmon/max31790.rst +++ b/Documentation/hwmon/max31790.rst @@ -38,6 +38,7 @@ Sysfs entries fan[1-12]_input RO fan tachometer speed in RPM fan[1-12]_fault RO fan experienced fault fan[1-6]_target RW desired fan speed in RPM -pwm[1-6]_enable RW regulator mode, 0=disabled, 1=manual mode, 2=rpm mode -pwm[1-6] RW fan target duty cycle (0-255) +pwm[1-6]_enable RW regulator mode, 0=disabled (duty cycle=0%), 1=manual mode, 2=rpm mode +pwm[1-6] RW read: current pwm duty cycle, + write: target pwm duty cycle (0-255) ================== === ======================================================= diff --git a/Documentation/hwmon/mp2888.rst b/Documentation/hwmon/mp2888.rst new file mode 100644 index 000000000000..5e578fd7b147 --- /dev/null +++ b/Documentation/hwmon/mp2888.rst @@ -0,0 +1,113 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver mp2888 +==================== + +Supported chips: + + * MPS MP12254 + + Prefix: 'mp2888' + +Author: + + Vadim Pasternak <vadimp@nvidia.com> + +Description +----------- + +This driver implements support for Monolithic Power Systems, Inc. (MPS) +vendor dual-loop, digital, multi-phase controller MP2888. + +This device: supports: + +- One power rail. +- Programmable Multi-Phase up to 10 Phases. +- PWM-VID Interface +- One pages 0 for telemetry. +- Programmable pins for PMBus Address. +- Built-In EEPROM to Store Custom Configurations. + +Device complaint with: + +- PMBus rev 1.3 interface. + +Device supports direct format for reading output current, output voltage, +input and output power and temperature. +Device supports linear format for reading input voltage and input power. + +The driver provides the next attributes for the current: + +- for current out input and maximum alarm; +- for phase current: input and label. + +The driver exports the following attributes via the 'sysfs' files, where: + +- 'n' is number of configured phases (from 1 to 10); +- index 1 for "iout"; +- indexes 2 ... 1 + n for phases. + +**curr[1-{1+n}]_input** + +**curr[1-{1+n}]_label** + +**curr1_max** + +**curr1_max_alarm** + +The driver provides the next attributes for the voltage: + +- for voltage in: input, low and high critical thresholds, low and high + critical alarms; +- for voltage out: input and high alarm; + +The driver exports the following attributes via the 'sysfs' files, where + +**in1_crit** + +**in1_crit_alarm** + +**in1_input** + +**in1_label** + +**in1_min** + +**in1_min_alarm** + +**in2_alarm** + +**in2_input** + +**in2_label** + +The driver provides the next attributes for the power: + +- for power in alarm and input. +- for power out: cap, cap alarm an input. + +The driver exports the following attributes via the 'sysfs' files, where +- indexes 1 for "pin"; +- indexes 2 for "pout"; + +**power1_alarm** + +**power1_input** + +**power1_label** + +**power2_input** + +**power2_label** + +**power2_max** + +**power2_max_alarm** + +The driver provides the next attributes for the temperature: + +**temp1_input** + +**temp1_max** + +**temp1_max_alarm** diff --git a/Documentation/hwmon/pim4328.rst b/Documentation/hwmon/pim4328.rst new file mode 100644 index 000000000000..70c9e7a6882c --- /dev/null +++ b/Documentation/hwmon/pim4328.rst @@ -0,0 +1,105 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver pim4328 +===================== + +Supported chips: + + * Flex PIM4328 + + Prefix: 'pim4328', 'bmr455' + + Addresses scanned: - + + Datasheet: + +https://flexpowermodules.com/resources/fpm-techspec-pim4328 + + * Flex PIM4820 + + Prefixes: 'pim4820' + + Addresses scanned: - + + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-pim4820 + + * Flex PIM4006, PIM4106, PIM4206, PIM4306, PIM4406 + + Prefixes: 'pim4006', 'pim4106', 'pim4206', 'pim4306', 'pim4406' + + Addresses scanned: - + + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-pim4006 + +Author: Erik Rosen <erik.rosen@metormote.com> + + +Description +----------- + +This driver supports hardware monitoring for Flex PIM4328 and +compatible digital power interface modules. + +The driver is a client driver to the core PMBus driver. Please see +Documentation/hwmon/pmbus.rst and Documentation.hwmon/pmbus-core for details +on PMBus client drivers. + + +Usage Notes +----------- + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for +details. + + +Platform data support +--------------------- + +The driver supports standard PMBus driver platform data. + + +Sysfs entries +------------- + +The following attributes are supported. All attributes are read-only. + +======================= ======================================================== +in1_label "vin" +in1_input Measured input voltage. +in1_alarm Input voltage alarm. + +in2_label "vin.0" +in2_input Measured input voltage on input A. + + PIM4328 and PIM4X06 + +in3_label "vin.1" +in3_input Measured input voltage on input B. + + PIM4328 and PIM4X06 + +in4_label "vcap" +in4_input Measured voltage on holdup capacitor. + + PIM4328 + +curr1_label "iin.0" +curr1_input Measured input current on input A. + + PIM4X06 + +curr2_label "iin.1" +curr2_input Measured input current on input B. + + PIM4X06 + +currX_label "iout1" +currX_input Measured output current. +currX_alarm Output current alarm. + + X is 1 for PIM4820, 3 otherwise. + +temp1_input Measured temperature. +temp1_alarm High temperature alarm. +======================= ======================================================== diff --git a/Documentation/hwmon/pm6764tr.rst b/Documentation/hwmon/pm6764tr.rst index a1fb8fea2326..294a8ffc8bd8 100644 --- a/Documentation/hwmon/pm6764tr.rst +++ b/Documentation/hwmon/pm6764tr.rst @@ -20,7 +20,7 @@ Description: ------------ This driver supports the STMicroelectronics PM6764TR chip. The PM6764TR is a high -performance digital controller designed to power Intel’s VR12.5 processors and memories. +performance digital controller designed to power Intel's VR12.5 processors and memories. The device utilizes digital technology to implement all control and power management functions to provide maximum flexibility and performance. The NVM is embedded to store diff --git a/Documentation/hwmon/pmbus-core.rst b/Documentation/hwmon/pmbus-core.rst index 73e23ab42cc3..e7e0c9ef10be 100644 --- a/Documentation/hwmon/pmbus-core.rst +++ b/Documentation/hwmon/pmbus-core.rst @@ -289,12 +289,22 @@ PMBus driver platform data ========================== PMBus platform data is defined in include/linux/pmbus.h. Platform data -currently only provides a flag field with a single bit used:: +currently provides a flags field with four bits used:: - #define PMBUS_SKIP_STATUS_CHECK (1 << 0) + #define PMBUS_SKIP_STATUS_CHECK BIT(0) + + #define PMBUS_WRITE_PROTECTED BIT(1) + + #define PMBUS_NO_CAPABILITY BIT(2) + + #define PMBUS_READ_STATUS_AFTER_FAILED_CHECK BIT(3) struct pmbus_platform_data { u32 flags; /* Device specific flags */ + + /* regulator support */ + int num_regulators; + struct regulator_init_data *reg_init_data; }; @@ -302,8 +312,9 @@ Flags ----- PMBUS_SKIP_STATUS_CHECK - During register detection, skip checking the status register for - communication or command errors. + +During register detection, skip checking the status register for +communication or command errors. Some PMBus chips respond with valid data when trying to read an unsupported register. For such chips, checking the status register is mandatory when @@ -315,3 +326,26 @@ status register must be disabled. Some i2c controllers do not support single-byte commands (write commands with no data, i2c_smbus_write_byte()). With such controllers, clearing the status register is impossible, and the PMBUS_SKIP_STATUS_CHECK flag must be set. + +PMBUS_WRITE_PROTECTED + +Set if the chip is write protected and write protection is not determined +by the standard WRITE_PROTECT command. + +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. + +PMBUS_READ_STATUS_AFTER_FAILED_CHECK + +Read the STATUS register after each failed register check. + +Some PMBus chips end up in an undefined state when trying to read an +unsupported register. For such chips, it is necessary to reset the +chip pmbus controller to a known state after a failed register check. +This can be done by reading a known register. By setting this flag the +driver will try to read the STATUS register after each failed +register check. This read may fail, but it will put the chip into a +known state. diff --git a/Documentation/hwmon/pmbus.rst b/Documentation/hwmon/pmbus.rst index c44f14115413..7ecfec6ca2db 100644 --- a/Documentation/hwmon/pmbus.rst +++ b/Documentation/hwmon/pmbus.rst @@ -3,15 +3,18 @@ Kernel driver pmbus Supported chips: - * Ericsson BMR453, BMR454 + * Flex BMR310, BMR453, BMR454, BMR456, BMR457, BMR458, BMR480, + BMR490, BMR491, BMR492 - Prefixes: 'bmr453', 'bmr454' + Prefixes: 'bmr310', 'bmr453', 'bmr454', 'bmr456', 'bmr457', 'bmr458', 'bmr480', + 'bmr490', 'bmr491', 'bmr492' Addresses scanned: - - Datasheet: + Datasheets: + + https://flexpowermodules.com/products - http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146395 * ON Semiconductor ADP4000, NCP4200, NCP4208 diff --git a/Documentation/hwmon/sht4x.rst b/Documentation/hwmon/sht4x.rst new file mode 100644 index 000000000000..3b37abcd4a46 --- /dev/null +++ b/Documentation/hwmon/sht4x.rst @@ -0,0 +1,45 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver sht4x +=================== + +Supported Chips: + + * Sensirion SHT4X + + Prefix: 'sht4x' + + Addresses scanned: None + + Datasheet: + + English: https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/2_Humidity_Sensors/Datasheets/Sensirion_Humidity_Sensors_SHT4x_Datasheet.pdf + +Author: Navin Sankar Velliangiri <navin@linumiz.com> + + +Description +----------- + +This driver implements support for the Sensirion SHT4x chip, a humidity +and temperature sensor. Temperature is measured in degree celsius, relative +humidity is expressed as a percentage. In sysfs interface, all values are +scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500. + +Usage Notes +----------- + +The device communicates with the I2C protocol. Sensors can have the I2C +address 0x44. See Documentation/i2c/instantiating-devices.rst for methods +to instantiate the device. + +Sysfs entries +------------- + +=============== ============================================ +temp1_input Measured temperature in millidegrees Celcius +humidity1_input Measured humidity in %H +update_interval The minimum interval for polling the sensor, + in milliseconds. Writable. Must be at least + 2000. +============== ============================================= diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst index e195a7d14309..b3ef81475cf8 100644 --- a/Documentation/hwmon/tmp103.rst +++ b/Documentation/hwmon/tmp103.rst @@ -21,10 +21,10 @@ Description The TMP103 is a digital output temperature sensor in a four-ball wafer chip-scale package (WCSP). The TMP103 is capable of reading temperatures to a resolution of 1°C. The TMP103 is specified for -operation over a temperature range of –40°C to +125°C. +operation over a temperature range of -40°C to +125°C. Resolution: 8 Bits -Accuracy: ±1°C Typ (–10°C to +100°C) +Accuracy: ±1°C Typ (-10°C to +100°C) The driver provides the common sysfs-interface for temperatures (see Documentation/hwmon/sysfs-interface.rst under Temperatures). diff --git a/Documentation/hwmon/zl6100.rst b/Documentation/hwmon/zl6100.rst index 968aff10ce0a..d42ed9d3ac69 100644 --- a/Documentation/hwmon/zl6100.rst +++ b/Documentation/hwmon/zl6100.rst @@ -3,87 +3,103 @@ Kernel driver zl6100 Supported chips: - * Intersil / Zilker Labs ZL2004 + * Renesas / Intersil / Zilker Labs ZL2004 Prefix: 'zl2004' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6847.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2004-datasheet.pdf - * Intersil / Zilker Labs ZL2005 + * Renesas / Intersil / Zilker Labs ZL2005 Prefix: 'zl2005' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6848.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2005-datasheet.pdf - * Intersil / Zilker Labs ZL2006 + * Renesas / Intersil / Zilker Labs ZL2006 Prefix: 'zl2006' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6850.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2006-datasheet.pdf - * Intersil / Zilker Labs ZL2008 + * Renesas / Intersil / Zilker Labs ZL2008 Prefix: 'zl2008' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6859.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2008-datasheet.pdf - * Intersil / Zilker Labs ZL2105 + * Renesas / Intersil / Zilker Labs ZL2105 Prefix: 'zl2105' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6851.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2105-datasheet.pdf - * Intersil / Zilker Labs ZL2106 + * Renesas / Intersil / Zilker Labs ZL2106 Prefix: 'zl2106' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6852.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl2106-datasheet.pdf - * Intersil / Zilker Labs ZL6100 + * Renesas / Intersil / Zilker Labs ZL6100 Prefix: 'zl6100' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6876.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl6100-datasheet.pdf - * Intersil / Zilker Labs ZL6105 + * Renesas / Intersil / Zilker Labs ZL6105 Prefix: 'zl6105' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn6906.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl6105-datasheet.pdf - * Intersil / Zilker Labs ZL9101M + * Renesas / Intersil / Zilker Labs ZL8802 + + Prefix: 'zl8802' + + Addresses scanned: - + + Datasheet: https://www.renesas.com/us/en/document/dst/zl8802-datasheet + + * Renesas / Intersil / Zilker Labs ZL9101M Prefix: 'zl9101' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn7669.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl9101m-datasheet - * Intersil / Zilker Labs ZL9117M + * Renesas / Intersil / Zilker Labs ZL9117M Prefix: 'zl9117' Addresses scanned: - - Datasheet: http://www.intersil.com/data/fn/fn7914.pdf + Datasheet: https://www.renesas.com/us/en/document/dst/zl9117m-datasheet + + * Renesas / Intersil / Zilker Labs ZLS1003, ZLS4009 + + Prefix: 'zls1003', zls4009 + + Addresses scanned: - + + Datasheet: Not published - * Ericsson BMR450, BMR451 + * Flex BMR450, BMR451 Prefix: 'bmr450', 'bmr451' @@ -91,17 +107,39 @@ Supported chips: Datasheet: -http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146401 +https://flexpowermodules.com/resources/fpm-techspec-bmr450-digital-pol-regulators-20a - * Ericsson BMR462, BMR463, BMR464 + * Flex BMR462, BMR463, BMR464 Prefixes: 'bmr462', 'bmr463', 'bmr464' Addresses scanned: - - Datasheet: + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-bmr462 + + * Flex BMR465, BMR467 + + Prefixes: 'bmr465', 'bmr467' + + Addresses scanned: - + + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-bmr465-digital-pol + + * Flex BMR466 + + Prefixes: 'bmr466' + + Addresses scanned: - + + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-bmr466-8x12 - http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146256 + * Flex BMR469 + + Prefixes: 'bmr469' + + Addresses scanned: - + + Datasheet: https://flexpowermodules.com/resources/fpm-techspec-bmr4696001 Author: Guenter Roeck <linux@roeck-us.net> @@ -109,8 +147,8 @@ Author: Guenter Roeck <linux@roeck-us.net> Description ----------- -This driver supports hardware monitoring for Intersil / Zilker Labs ZL6100 and -compatible digital DC-DC controllers. +This driver supports hardware monitoring for Renesas / Intersil / Zilker Labs +ZL6100 and compatible digital DC-DC controllers. The driver is a client driver to the core PMBus driver. Please see Documentation/hwmon/pmbus.rst and Documentation.hwmon/pmbus-core for details @@ -147,12 +185,12 @@ Module parameters delay ----- -Intersil/Zilker Labs DC-DC controllers require a minimum interval between I2C -bus accesses. According to Intersil, the minimum interval is 2 ms, though 1 ms -appears to be sufficient and has not caused any problems in testing. The problem -is known to affect all currently supported chips. For manual override, the -driver provides a writeable module parameter, 'delay', which can be used to set -the interval to a value between 0 and 65,535 microseconds. +Renesas/Intersil/Zilker Labs DC-DC controllers require a minimum interval +between I2C bus accesses. According to Intersil, the minimum interval is 2 ms, +though 1 ms appears to be sufficient and has not caused any problems in testing. +The problem is known to affect all currently supported chips. For manual override, +the driver provides a writeable module parameter, 'delay', which can be used +to set the interval to a value between 0 and 65,535 microseconds. Sysfs entries @@ -182,24 +220,32 @@ in2_crit Critical maximum VMON/VDRV voltage. in2_lcrit_alarm VMON/VDRV voltage critical low alarm. in2_crit_alarm VMON/VDRV voltage critical high alarm. - vmon attributes are supported on ZL2004, ZL9101M, - and ZL9117M only. + vmon attributes are supported on ZL2004, ZL8802, + ZL9101M, ZL9117M and ZLS4009 only. -inX_label "vout1" +inX_label "vout[12]" inX_input Measured output voltage. inX_lcrit Critical minimum output Voltage. inX_crit Critical maximum output voltage. inX_lcrit_alarm Critical output voltage critical low alarm. inX_crit_alarm Critical output voltage critical high alarm. - X is 3 for ZL2004, ZL9101M, and ZL9117M, 2 otherwise. + X is 3 for ZL2004, ZL9101M, and ZL9117M, + 3, 4 for ZL8802 and 2 otherwise. + +curr1_label "iin" +curr1_input Measured input current. + + iin attributes are supported on ZL8802 only + +currY_label "iout[12]" +currY_input Measured output current. +currY_lcrit Critical minimum output current. +currY_crit Critical maximum output current. +currY_lcrit_alarm Output current critical low alarm. +currY_crit_alarm Output current critical high alarm. -curr1_label "iout1" -curr1_input Measured output current. -curr1_lcrit Critical minimum output current. -curr1_crit Critical maximum output current. -curr1_lcrit_alarm Output current critical low alarm. -curr1_crit_alarm Output current critical high alarm. + Y is 2, 3 for ZL8802, 1 otherwise temp[12]_input Measured temperature. temp[12]_min Minimum temperature. diff --git a/Documentation/i2c/i2c-sysfs.rst b/Documentation/i2c/i2c-sysfs.rst new file mode 100644 index 000000000000..6b68b95cd427 --- /dev/null +++ b/Documentation/i2c/i2c-sysfs.rst @@ -0,0 +1,395 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +Linux I2C Sysfs +=============== + +Overview +======== + +I2C topology can be complex because of the existence of I2C MUX +(I2C Multiplexer). The Linux +kernel abstracts the MUX channels into logical I2C bus numbers. However, there +is a gap of knowledge to map from the I2C bus physical number and MUX topology +to logical I2C bus number. This doc is aimed to fill in this gap, so the +audience (hardware engineers and new software developers for example) can learn +the concept of logical I2C buses in the kernel, by knowing the physical I2C +topology and navigating through the I2C sysfs in Linux shell. This knowledge is +useful and essential to use ``i2c-tools`` for the purpose of development and +debugging. + +Target audience +--------------- + +People who need to use Linux shell to interact with I2C subsystem on a system +which the Linux is running on. + +Prerequisites +------------- + +1. Knowledge of general Linux shell file system commands and operations. + +2. General knowledge of I2C, I2C MUX and I2C topology. + +Location of I2C Sysfs +===================== + +Typically, the Linux Sysfs filesystem is mounted at the ``/sys`` directory, +so you can find the I2C Sysfs under ``/sys/bus/i2c/devices`` +where you can directly ``cd`` to it. +There is a list of symbolic links under that directory. The links that +start with ``i2c-`` are I2C buses, which may be either physical or logical. The +other links that begin with numbers and end with numbers are I2C devices, where +the first number is I2C bus number, and the second number is I2C address. + +Google Pixel 3 phone for example:: + + blueline:/sys/bus/i2c/devices $ ls + 0-0008 0-0061 1-0028 3-0043 4-0036 4-0041 i2c-1 i2c-3 + 0-000c 0-0066 2-0049 4-000b 4-0040 i2c-0 i2c-2 i2c-4 + +``i2c-2`` is an I2C bus whose number is 2, and ``2-0049`` is an I2C device +on bus 2 address 0x49 bound with a kernel driver. + +Terminologies +============= + +First, let us define a couple of terminologies to avoid confusions in the later +sections. + +(Physical) I2C Bus Controller +----------------------------- + +The hardware system that the Linux kernel is running on may have multiple +physical I2C bus controllers. The controllers are hardware and physical, and the +system may define multiple registers in the memory space to manipulate the +controllers. Linux kernel has I2C bus drivers under source directory +``drivers/i2c/busses`` to translate kernel I2C API into register +operations for different systems. This terminology is not limited to Linux +kernel only. + +I2C Bus Physical Number +----------------------- + +For each physical I2C bus controller, the system vendor may assign a physical +number to each controller. For example, the first I2C bus controller which has +the lowest register addresses may be called ``I2C-0``. + +Logical I2C Bus +--------------- + +Every I2C bus number you see in Linux I2C Sysfs is a logical I2C bus with a +number assigned. This is similar to the fact that software code is usually +written upon virtual memory space, instead of physical memory space. + +Each logical I2C bus may be an abstraction of a physical I2C bus controller, or +an abstraction of a channel behind an I2C MUX. In case it is an abstraction of a +MUX channel, whenever we access an I2C device via a such logical bus, the kernel +will switch the I2C MUX for you to the proper channel as part of the +abstraction. + +Physical I2C Bus +---------------- + +If the logical I2C bus is a direct abstraction of a physical I2C bus controller, +let us call it a physical I2C bus. + +Caveat +------ + +This may be a confusing part for people who only know about the physical I2C +design of a board. It is actually possible to rename the I2C bus physical number +to a different number in logical I2C bus level in Device Tree Source (DTS) under +section ``aliases``. See +`arch/arm/boot/dts/nuvoton-npcm730-gsj.dts +<../../arch/arm/boot/dts/nuvoton-npcm730-gsj.dts>`_ +for an example of DTS file. + +Best Practice: **(To kernel software developers)** It is better to keep the I2C +bus physical number the same as their corresponding logical I2C bus number, +instead of renaming or mapping them, so that it may be less confusing to other +users. These physical I2C buses can be served as good starting points for I2C +MUX fanouts. For the following examples, we will assume that the physical I2C +bus has a number same as their I2C bus physical number. + +Walk through Logical I2C Bus +============================ + +For the following content, we will use a more complex I2C topology as an +example. Here is a brief graph for the I2C topology. If you do not understand +this graph at the first glance, do not be afraid to continue reading this doc +and review it when you finish reading. + +:: + + i2c-7 (physical I2C bus controller 7) + `-- 7-0071 (4-channel I2C MUX at 0x71) + |-- i2c-60 (channel-0) + |-- i2c-73 (channel-1) + | |-- 73-0040 (I2C sensor device with hwmon directory) + | |-- 73-0070 (I2C MUX at 0x70, exists in DTS, but failed to probe) + | `-- 73-0072 (8-channel I2C MUX at 0x72) + | |-- i2c-78 (channel-0) + | |-- ... (channel-1...6, i2c-79...i2c-84) + | `-- i2c-85 (channel-7) + |-- i2c-86 (channel-2) + `-- i2c-203 (channel-3) + +Distinguish Physical and Logical I2C Bus +---------------------------------------- + +One simple way to distinguish between a physical I2C bus and a logical I2C bus, +is to read the symbolic link ``device`` under the I2C bus directory by using +command ``ls -l`` or ``readlink``. + +An alternative symbolic link to check is ``mux_device``. This link only exists +in logical I2C bus directory which is fanned out from another I2C bus. +Reading this link will also tell you which I2C MUX device created +this logical I2C bus. + +If the symbolic link points to a directory ending with ``.i2c``, it should be a +physical I2C bus, directly abstracting a physical I2C bus controller. For +example:: + + $ readlink /sys/bus/i2c/devices/i2c-7/device + ../../f0087000.i2c + $ ls /sys/bus/i2c/devices/i2c-7/mux_device + ls: /sys/bus/i2c/devices/i2c-7/mux_device: No such file or directory + +In this case, ``i2c-7`` is a physical I2C bus, so it does not have the symbolic +link ``mux_device`` under its directory. And if the kernel software developer +follows the common practice by not renaming physical I2C buses, this should also +mean the physical I2C bus controller 7 of the system. + +On the other hand, if the symbolic link points to another I2C bus, the I2C bus +presented by the current directory has to be a logical bus. The I2C bus pointed +by the link is the parent bus which may be either a physical I2C bus or a +logical one. In this case, the I2C bus presented by the current directory +abstracts an I2C MUX channel under the parent bus. + +For example:: + + $ readlink /sys/bus/i2c/devices/i2c-73/device + ../../i2c-7 + $ readlink /sys/bus/i2c/devices/i2c-73/mux_device + ../7-0071 + +``i2c-73`` is a logical bus fanout by an I2C MUX under ``i2c-7`` +whose I2C address is 0x71. +Whenever we access an I2C device with bus 73, the kernel will always +switch the I2C MUX addressed 0x71 to the proper channel for you as part of the +abstraction. + +Finding out Logical I2C Bus Number +---------------------------------- + +In this section, we will describe how to find out the logical I2C bus number +representing certain I2C MUX channels based on the knowledge of physical +hardware I2C topology. + +In this example, we have a system which has a physical I2C bus 7 and not renamed +in DTS. There is a 4-channel MUX at address 0x71 on that bus. There is another +8-channel MUX at address 0x72 behind the channel 1 of the 0x71 MUX. Let us +navigate through Sysfs and find out the logical I2C bus number of the channel 3 +of the 0x72 MUX. + +First of all, let us go to the directory of ``i2c-7``:: + + ~$ cd /sys/bus/i2c/devices/i2c-7 + /sys/bus/i2c/devices/i2c-7$ ls + 7-0071 i2c-60 name subsystem + delete_device i2c-73 new_device uevent + device i2c-86 of_node + i2c-203 i2c-dev power + +There, we see the 0x71 MUX as ``7-0071``. Go inside it:: + + /sys/bus/i2c/devices/i2c-7$ cd 7-0071/ + /sys/bus/i2c/devices/i2c-7/7-0071$ ls -l + channel-0 channel-3 modalias power + channel-1 driver name subsystem + channel-2 idle_state of_node uevent + +Read the link ``channel-1`` using ``readlink`` or ``ls -l``:: + + /sys/bus/i2c/devices/i2c-7/7-0071$ readlink channel-1 + ../i2c-73 + +We find out that the channel 1 of 0x71 MUX on ``i2c-7`` is assigned +with a logical I2C bus number of 73. +Let us continue the journey to directory ``i2c-73`` in either ways:: + + # cd to i2c-73 under I2C Sysfs root + /sys/bus/i2c/devices/i2c-7/7-0071$ cd /sys/bus/i2c/devices/i2c-73 + /sys/bus/i2c/devices/i2c-73$ + + # cd the channel symbolic link + /sys/bus/i2c/devices/i2c-7/7-0071$ cd channel-1 + /sys/bus/i2c/devices/i2c-7/7-0071/channel-1$ + + # cd the link content + /sys/bus/i2c/devices/i2c-7/7-0071$ cd ../i2c-73 + /sys/bus/i2c/devices/i2c-7/i2c-73$ + +Either ways, you will end up in the directory of ``i2c-73``. Similar to above, +we can now find the 0x72 MUX and what logical I2C bus numbers +that its channels are assigned:: + + /sys/bus/i2c/devices/i2c-73$ ls + 73-0040 device i2c-83 new_device + 73-004e i2c-78 i2c-84 of_node + 73-0050 i2c-79 i2c-85 power + 73-0070 i2c-80 i2c-dev subsystem + 73-0072 i2c-81 mux_device uevent + delete_device i2c-82 name + /sys/bus/i2c/devices/i2c-73$ cd 73-0072 + /sys/bus/i2c/devices/i2c-73/73-0072$ ls + channel-0 channel-4 driver of_node + channel-1 channel-5 idle_state power + channel-2 channel-6 modalias subsystem + channel-3 channel-7 name uevent + /sys/bus/i2c/devices/i2c-73/73-0072$ readlink channel-3 + ../i2c-81 + +There, we find out the logical I2C bus number of the channel 3 of the 0x72 MUX +is 81. We can later use this number to switch to its own I2C Sysfs directory or +issue ``i2c-tools`` commands. + +Tip: Once you understand the I2C topology with MUX, command +`i2cdetect -l +<https://manpages.debian.org/unstable/i2c-tools/i2cdetect.8.en.html>`_ +in +`I2C Tools +<https://i2c.wiki.kernel.org/index.php/I2C_Tools>`_ +can give you +an overview of the I2C topology easily, if it is available on your system. For +example:: + + $ i2cdetect -l | grep -e '\-73' -e _7 | sort -V + i2c-7 i2c npcm_i2c_7 I2C adapter + i2c-73 i2c i2c-7-mux (chan_id 1) I2C adapter + i2c-78 i2c i2c-73-mux (chan_id 0) I2C adapter + i2c-79 i2c i2c-73-mux (chan_id 1) I2C adapter + i2c-80 i2c i2c-73-mux (chan_id 2) I2C adapter + i2c-81 i2c i2c-73-mux (chan_id 3) I2C adapter + i2c-82 i2c i2c-73-mux (chan_id 4) I2C adapter + i2c-83 i2c i2c-73-mux (chan_id 5) I2C adapter + i2c-84 i2c i2c-73-mux (chan_id 6) I2C adapter + i2c-85 i2c i2c-73-mux (chan_id 7) I2C adapter + +Pinned Logical I2C Bus Number +----------------------------- + +If not specified in DTS, when an I2C MUX driver is applied and the MUX device is +successfully probed, the kernel will assign the MUX channels with a logical bus +number based on the current biggest logical bus number incrementally. For +example, if the system has ``i2c-15`` as the highest logical bus number, and a +4-channel MUX is applied successfully, we will have ``i2c-16`` for the +MUX channel 0, and all the way to ``i2c-19`` for the MUX channel 3. + +The kernel software developer is able to pin the fanout MUX channels to a static +logical I2C bus number in the DTS. This doc will not go through the details on +how to implement this in DTS, but we can see an example in: +`arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts +<../../arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts>`_ + +In the above example, there is an 8-channel I2C MUX at address 0x70 on physical +I2C bus 2. The channel 2 of the MUX is defined as ``imux18`` in DTS, +and pinned to logical I2C bus number 18 with the line of ``i2c18 = &imux18;`` +in section ``aliases``. + +Take it further, it is possible to design a logical I2C bus number schema that +can be easily remembered by humans or calculated arithmetically. For example, we +can pin the fanout channels of a MUX on bus 3 to start at 30. So 30 will be the +logical bus number of the channel 0 of the MUX on bus 3, and 37 will be the +logical bus number of the channel 7 of the MUX on bus 3. + +I2C Devices +=========== + +In previous sections, we mostly covered the I2C bus. In this section, let us see +what we can learn from the I2C device directory whose link name is in the format +of ``${bus}-${addr}``. The ``${bus}`` part in the name is a logical I2C bus +decimal number, while the ``${addr}`` part is a hex number of the I2C address +of each device. + +I2C Device Directory Content +---------------------------- + +Inside each I2C device directory, there is a file named ``name``. +This file tells what device name it was used for the kernel driver to +probe this device. Use command ``cat`` to read its content. For example:: + + /sys/bus/i2c/devices/i2c-73$ cat 73-0040/name + ina230 + /sys/bus/i2c/devices/i2c-73$ cat 73-0070/name + pca9546 + /sys/bus/i2c/devices/i2c-73$ cat 73-0072/name + pca9547 + +There is a symbolic link named ``driver`` to tell what Linux kernel driver was +used to probe this device:: + + /sys/bus/i2c/devices/i2c-73$ readlink -f 73-0040/driver + /sys/bus/i2c/drivers/ina2xx + /sys/bus/i2c/devices/i2c-73$ readlink -f 73-0072/driver + /sys/bus/i2c/drivers/pca954x + +But if the link ``driver`` does not exist at the first place, +it may mean that the kernel driver failed to probe this device due to +some errors. The error may be found in ``dmesg``:: + + /sys/bus/i2c/devices/i2c-73$ ls 73-0070/driver + ls: 73-0070/driver: No such file or directory + /sys/bus/i2c/devices/i2c-73$ dmesg | grep 73-0070 + pca954x 73-0070: probe failed + pca954x 73-0070: probe failed + +Depending on what the I2C device is and what kernel driver was used to probe the +device, we may have different content in the device directory. + +I2C MUX Device +-------------- + +While you may be already aware of this in previous sections, an I2C MUX device +will have symbolic link ``channel-*`` inside its device directory. +These symbolic links point to their logical I2C bus directories:: + + /sys/bus/i2c/devices/i2c-73$ ls -l 73-0072/channel-* + lrwxrwxrwx ... 73-0072/channel-0 -> ../i2c-78 + lrwxrwxrwx ... 73-0072/channel-1 -> ../i2c-79 + lrwxrwxrwx ... 73-0072/channel-2 -> ../i2c-80 + lrwxrwxrwx ... 73-0072/channel-3 -> ../i2c-81 + lrwxrwxrwx ... 73-0072/channel-4 -> ../i2c-82 + lrwxrwxrwx ... 73-0072/channel-5 -> ../i2c-83 + lrwxrwxrwx ... 73-0072/channel-6 -> ../i2c-84 + lrwxrwxrwx ... 73-0072/channel-7 -> ../i2c-85 + +I2C Sensor Device / Hwmon +------------------------- + +I2C sensor device is also common to see. If they are bound by a kernel hwmon +(Hardware Monitoring) driver successfully, you will see a ``hwmon`` directory +inside the I2C device directory. Keep digging into it, you will find the Hwmon +Sysfs for the I2C sensor device:: + + /sys/bus/i2c/devices/i2c-73/73-0040/hwmon/hwmon17$ ls + curr1_input in0_lcrit_alarm name subsystem + device in1_crit power uevent + in0_crit in1_crit_alarm power1_crit update_interval + in0_crit_alarm in1_input power1_crit_alarm + in0_input in1_lcrit power1_input + in0_lcrit in1_lcrit_alarm shunt_resistor + +For more info on the Hwmon Sysfs, refer to the doc: + +`Naming and data format standards for sysfs files +<../hwmon/sysfs-interface.rst>`_ + +Instantiate I2C Devices in I2C Sysfs +------------------------------------ + +Refer to the doc: + +`How to instantiate I2C devices, Method 4: Instantiate from user-space +<instantiating-devices.rst#method-4-instantiate-from-user-space>`_ diff --git a/Documentation/i2c/instantiating-devices.rst b/Documentation/i2c/instantiating-devices.rst index e558e0a77e0c..890c9360ce19 100644 --- a/Documentation/i2c/instantiating-devices.rst +++ b/Documentation/i2c/instantiating-devices.rst @@ -59,7 +59,7 @@ Declare the I2C devices via ACPI ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ACPI can also describe I2C devices. There is special documentation for this -which is currently located at :doc:`../firmware-guide/acpi/enumeration`. +which is currently located at Documentation/firmware-guide/acpi/enumeration.rst. Declare the I2C devices in board files diff --git a/Documentation/i2c/old-module-parameters.rst b/Documentation/i2c/old-module-parameters.rst index 38e55829dee8..b08b6daabce9 100644 --- a/Documentation/i2c/old-module-parameters.rst +++ b/Documentation/i2c/old-module-parameters.rst @@ -17,7 +17,8 @@ address), ``force`` (to forcibly attach the driver to a given device) and With the conversion of the I2C subsystem to the standard device driver binding model, it became clear that these per-module parameters were no longer needed, and that a centralized implementation was possible. The new, -sysfs-based interface is described in :doc:`instantiating-devices`, section +sysfs-based interface is described in +Documentation/i2c/instantiating-devices.rst, section "Method 4: Instantiate from user-space". Below is a mapping from the old module parameters to the new interface. diff --git a/Documentation/i2c/smbus-protocol.rst b/Documentation/i2c/smbus-protocol.rst index 64689d19dd51..9e07e6bbe6a3 100644 --- a/Documentation/i2c/smbus-protocol.rst +++ b/Documentation/i2c/smbus-protocol.rst @@ -27,8 +27,8 @@ a different protocol operation entirely. Each transaction type corresponds to a functionality flag. Before calling a transaction function, a device driver should always check (just once) for the corresponding functionality flag to ensure that the underlying I2C -adapter supports the transaction in question. See :doc:`functionality` for -the details. +adapter supports the transaction in question. See +Documentation/i2c/functionality.rst for the details. Key to symbols diff --git a/Documentation/input/joydev/joystick-api.rst b/Documentation/input/joydev/joystick-api.rst index af5934c10c1c..5db6dc6fe1c5 100644 --- a/Documentation/input/joydev/joystick-api.rst +++ b/Documentation/input/joydev/joystick-api.rst @@ -263,7 +263,7 @@ possible overrun should the name be too long:: char name[128]; if (ioctl(fd, JSIOCGNAME(sizeof(name)), name) < 0) - strncpy(name, "Unknown", sizeof(name)); + strscpy(name, "Unknown", sizeof(name)); printf("Name: %s\n", name); diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst index 451523424942..df65c19aa7df 100644 --- a/Documentation/kernel-hacking/hacking.rst +++ b/Documentation/kernel-hacking/hacking.rst @@ -601,7 +601,7 @@ Defined in ``include/linux/export.h`` This is the variant of `EXPORT_SYMBOL()` that allows specifying a symbol namespace. Symbol Namespaces are documented in -:doc:`../core-api/symbol-namespaces` +Documentation/core-api/symbol-namespaces.rst :c:func:`EXPORT_SYMBOL_NS_GPL()` -------------------------------- @@ -610,7 +610,7 @@ Defined in ``include/linux/export.h`` This is the variant of `EXPORT_SYMBOL_GPL()` that allows specifying a symbol namespace. Symbol Namespaces are documented in -:doc:`../core-api/symbol-namespaces` +Documentation/core-api/symbol-namespaces.rst Routines and Conventions ======================== diff --git a/Documentation/locking/lockdep-design.rst b/Documentation/locking/lockdep-design.rst index 9f3cfca9f8a4..82f36cab61bd 100644 --- a/Documentation/locking/lockdep-design.rst +++ b/Documentation/locking/lockdep-design.rst @@ -453,9 +453,9 @@ There are simply four block conditions: Block condition matrix, Y means the row blocks the column, and N means otherwise. +---+---+---+---+ - | | E | r | R | + | | W | r | R | +---+---+---+---+ - | E | Y | Y | Y | + | W | Y | Y | Y | +---+---+---+---+ | r | Y | Y | N | +---+---+---+---+ diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst index 2ccc5644cc98..42576880aa4a 100644 --- a/Documentation/networking/af_xdp.rst +++ b/Documentation/networking/af_xdp.rst @@ -290,19 +290,19 @@ round-robin example of distributing packets is shown below: #define MAX_SOCKS 16 struct { - __uint(type, BPF_MAP_TYPE_XSKMAP); - __uint(max_entries, MAX_SOCKS); - __uint(key_size, sizeof(int)); - __uint(value_size, sizeof(int)); + __uint(type, BPF_MAP_TYPE_XSKMAP); + __uint(max_entries, MAX_SOCKS); + __uint(key_size, sizeof(int)); + __uint(value_size, sizeof(int)); } xsks_map SEC(".maps"); static unsigned int rr; SEC("xdp_sock") int xdp_sock_prog(struct xdp_md *ctx) { - rr = (rr + 1) & (MAX_SOCKS - 1); + rr = (rr + 1) & (MAX_SOCKS - 1); - return bpf_redirect_map(&xsks_map, rr, XDP_DROP); + return bpf_redirect_map(&xsks_map, rr, XDP_DROP); } Note, that since there is only a single set of FILL and COMPLETION @@ -379,7 +379,7 @@ would look like this for the TX path: .. code-block:: c if (xsk_ring_prod__needs_wakeup(&my_tx_ring)) - sendto(xsk_socket__fd(xsk_handle), NULL, 0, MSG_DONTWAIT, NULL, 0); + sendto(xsk_socket__fd(xsk_handle), NULL, 0, MSG_DONTWAIT, NULL, 0); I.e., only use the syscall if the flag is set. @@ -442,9 +442,9 @@ purposes. The supported statistics are shown below: .. code-block:: c struct xdp_statistics { - __u64 rx_dropped; /* Dropped for reasons other than invalid desc */ - __u64 rx_invalid_descs; /* Dropped due to invalid descriptor */ - __u64 tx_invalid_descs; /* Dropped due to invalid descriptor */ + __u64 rx_dropped; /* Dropped for reasons other than invalid desc */ + __u64 rx_invalid_descs; /* Dropped due to invalid descriptor */ + __u64 tx_invalid_descs; /* Dropped due to invalid descriptor */ }; XDP_OPTIONS getsockopt @@ -483,15 +483,15 @@ like this: .. code-block:: c // struct xdp_rxtx_ring { - // __u32 *producer; - // __u32 *consumer; - // struct xdp_desc *desc; + // __u32 *producer; + // __u32 *consumer; + // struct xdp_desc *desc; // }; // struct xdp_umem_ring { - // __u32 *producer; - // __u32 *consumer; - // __u64 *desc; + // __u32 *producer; + // __u32 *consumer; + // __u64 *desc; // }; // typedef struct xdp_rxtx_ring RING; diff --git a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst index 70643b58de05..4118384cf8eb 100644 --- a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst +++ b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst @@ -27,34 +27,136 @@ these MAP frames and send them to appropriate PDN's. 2. Packet format ================ -a. MAP packet (data / control) +a. MAP packet v1 (data / control) -MAP header has the same endianness of the IP packet. +MAP header fields are in big endian format. Packet format:: - Bit 0 1 2-7 8 - 15 16 - 31 + Bit 0 1 2-7 8-15 16-31 Function Command / Data Reserved Pad Multiplexer ID Payload length - Bit 32 - x - Function Raw Bytes + + Bit 32-x + Function Raw bytes Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command -or data packet. Control packet is used for transport level flow control. Data +or data packet. Command packet is used for transport level flow control. Data packets are standard IP packets. -Reserved bits are usually zeroed out and to be ignored by receiver. +Reserved bits must be zero when sent and ignored when received. -Padding is number of bytes to be added for 4 byte alignment if required by -hardware. +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. Multiplexer ID is to indicate the PDN on which data has to be sent. Payload length includes the padding length but does not include MAP header length. -b. MAP packet (command specific):: +b. Map packet v4 (data / control) + +MAP header fields are in big endian format. + +Packet format:: + + Bit 0 1 2-7 8-15 16-31 + Function Command / Data Reserved Pad Multiplexer ID Payload length + + Bit 32-(x-33) (x-32)-x + Function Raw bytes Checksum offload header + +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command +or data packet. Command packet is used for transport level flow control. Data +packets are standard IP packets. + +Reserved bits must be zero when sent and ignored when received. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Multiplexer ID is to indicate the PDN on which data has to be sent. + +Payload length includes the padding length but does not include MAP header +length. + +Checksum offload header, has the information about the checksum processing done +by the hardware.Checksum offload header fields are in big endian format. + +Packet format:: + + Bit 0-14 15 16-31 + Function Reserved Valid Checksum start offset + + Bit 31-47 48-64 + Function Checksum length Checksum value + +Reserved bits must be zero when sent and ignored when received. + +Valid bit indicates whether the partial checksum is calculated and is valid. +Set to 1, if its is valid. Set to 0 otherwise. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Checksum start offset, Indicates the offset in bytes from the beginning of the +IP header, from which modem computed checksum. + +Checksum length is the Length in bytes starting from CKSUM_START_OFFSET, +over which checksum is computed. + +Checksum value, indicates the checksum computed. + +c. MAP packet v5 (data / control) + +MAP header fields are in big endian format. + +Packet format:: + + Bit 0 1 2-7 8-15 16-31 + Function Command / Data Next header Pad Multiplexer ID Payload length + + Bit 32-x + Function Raw bytes + +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command +or data packet. Command packet is used for transport level flow control. Data +packets are standard IP packets. + +Next header is used to indicate the presence of another header, currently is +limited to checksum header. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Multiplexer ID is to indicate the PDN on which data has to be sent. + +Payload length includes the padding length but does not include MAP header +length. + +d. Checksum offload header v5 + +Checksum offload header fields are in big endian format. + + Bit 0 - 6 7 8-15 16-31 + Function Header Type Next Header Checksum Valid Reserved + +Header Type is to indicate the type of header, this usually is set to CHECKSUM + +Header types += ========================================== +0 Reserved +1 Reserved +2 checksum header + +Checksum Valid is to indicate whether the header checksum is valid. Value of 1 +implies that checksum is calculated on this packet and is valid, value of 0 +indicates that the calculated packet checksum is invalid. + +Reserved bits must be zero when sent and ignored when received. + +e. MAP packet v1/v5 (command specific):: - Bit 0 1 2-7 8 - 15 16 - 31 + Bit 0 1 2-7 8 - 15 16 - 31 Function Command Reserved Pad Multiplexer ID Payload length Bit 32 - 39 40 - 45 46 - 47 48 - 63 Function Command name Reserved Command Type Reserved @@ -74,7 +176,7 @@ Command types 3 is for error during processing of commands = ========================================== -c. Aggregation +f. Aggregation Aggregation is multiple MAP packets (can be data or command) delivered to rmnet in a single linear skb. rmnet will process the individual diff --git a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst index f8c6469f2bd2..01b2a69b0cb0 100644 --- a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst +++ b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst @@ -11,12 +11,12 @@ ENA is a networking interface designed to make good use of modern CPU features and system architectures. The ENA device exposes a lightweight management interface with a -minimal set of memory mapped registers and extendable command set +minimal set of memory mapped registers and extendible command set through an Admin Queue. The driver supports a range of ENA devices, is link-speed independent -(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc.), and has -a negotiated and extendable feature set. +(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc), and has +a negotiated and extendible feature set. Some ENA devices support SR-IOV. This driver is used for both the SR-IOV Physical Function (PF) and Virtual Function (VF) devices. @@ -27,9 +27,9 @@ is advertised by the device via the Admin Queue), a dedicated MSI-X interrupt vector per Tx/Rx queue pair, adaptive interrupt moderation, and CPU cacheline optimized data placement. -The ENA driver supports industry standard TCP/IP offload features such -as checksum offload and TCP transmit segmentation offload (TSO). -Receive-side scaling (RSS) is supported for multi-core scaling. +The ENA driver supports industry standard TCP/IP offload features such as +checksum offload. Receive-side scaling (RSS) is supported for multi-core +scaling. The ENA driver and its corresponding devices implement health monitoring mechanisms such as watchdog, enabling the device and driver @@ -38,22 +38,20 @@ debug logs. Some of the ENA devices support a working mode called Low-latency Queue (LLQ), which saves several more microseconds. - ENA Source Code Directory Structure =================================== ================= ====================================================== ena_com.[ch] Management communication layer. This layer is - responsible for the handling all the management - (admin) communication between the device and the - driver. + responsible for the handling all the management + (admin) communication between the device and the + driver. ena_eth_com.[ch] Tx/Rx data path. ena_admin_defs.h Definition of ENA management interface. ena_eth_io_defs.h Definition of ENA data path interface. ena_common_defs.h Common definitions for ena_com layer. ena_regs_defs.h Definition of ENA PCI memory-mapped (MMIO) registers. ena_netdev.[ch] Main Linux kernel driver. -ena_syfsfs.[ch] Sysfs files. ena_ethtool.c ethtool callbacks. ena_pci_id_tbl.h Supported device IDs. ================= ====================================================== @@ -69,7 +67,7 @@ ENA management interface is exposed by means of: - Asynchronous Event Notification Queue (AENQ) ENA device MMIO Registers are accessed only during driver -initialization and are not involved in further normal device +initialization and are not used during further normal device operation. AQ is used for submitting management commands, and the @@ -100,28 +98,27 @@ group may have multiple syndromes, as shown below The events are: - ==================== =============== - Group Syndrome - ==================== =============== - Link state change **X** - Fatal error **X** - Notification Suspend traffic - Notification Resume traffic - Keep-Alive **X** - ==================== =============== +==================== =============== +Group Syndrome +==================== =============== +Link state change **X** +Fatal error **X** +Notification Suspend traffic +Notification Resume traffic +Keep-Alive **X** +==================== =============== ACQ and AENQ share the same MSI-X vector. -Keep-Alive is a special mechanism that allows monitoring of the -device's health. The driver maintains a watchdog (WD) handler which, -if fired, logs the current state and statistics then resets and -restarts the ENA device and driver. A Keep-Alive event is delivered by -the device every second. The driver re-arms the WD upon reception of a -Keep-Alive event. A missed Keep-Alive event causes the WD handler to -fire. +Keep-Alive is a special mechanism that allows monitoring the device's health. +A Keep-Alive event is delivered by the device every second. +The driver maintains a watchdog (WD) handler which logs the current state and +statistics. If the keep-alive events aren't delivered as expected the WD resets +the device and the driver. Data Path Interface =================== + I/O operations are based on Tx and Rx Submission Queues (Tx SQ and Rx SQ correspondingly). Each SQ has a completion queue (CQ) associated with it. @@ -131,26 +128,24 @@ physical memory. The ENA driver supports two Queue Operation modes for Tx SQs: -- Regular mode +- **Regular mode:** + In this mode the Tx SQs reside in the host's memory. The ENA + device fetches the ENA Tx descriptors and packet data from host + memory. - * In this mode the Tx SQs reside in the host's memory. The ENA - device fetches the ENA Tx descriptors and packet data from host - memory. +- **Low Latency Queue (LLQ) mode or "push-mode":** + In this mode the driver pushes the transmit descriptors and the + first 128 bytes of the packet directly to the ENA device memory + space. The rest of the packet payload is fetched by the + device. For this operation mode, the driver uses a dedicated PCI + device memory BAR, which is mapped with write-combine capability. -- Low Latency Queue (LLQ) mode or "push-mode". - - * In this mode the driver pushes the transmit descriptors and the - first 128 bytes of the packet directly to the ENA device memory - space. The rest of the packet payload is fetched by the - device. For this operation mode, the driver uses a dedicated PCI - device memory BAR, which is mapped with write-combine capability. + **Note that** not all ENA devices support LLQ, and this feature is negotiated + with the device upon initialization. If the ENA device does not + support LLQ mode, the driver falls back to the regular mode. The Rx SQs support only the regular mode. -Note: Not all ENA devices support LLQ, and this feature is negotiated - with the device upon initialization. If the ENA device does not - support LLQ mode, the driver falls back to the regular mode. - The driver supports multi-queue for both Tx and Rx. This has various benefits: @@ -165,6 +160,7 @@ benefits: Interrupt Modes =============== + The driver assigns a single MSI-X vector per queue pair (for both Tx and Rx directions). The driver assigns an additional dedicated MSI-X vector for management (for ACQ and AENQ). @@ -190,20 +186,21 @@ unmasked by the driver after NAPI processing is complete. Interrupt Moderation ==================== + ENA driver and device can operate in conventional or adaptive interrupt moderation mode. -In conventional mode the driver instructs device to postpone interrupt +**In conventional mode** the driver instructs device to postpone interrupt posting according to static interrupt delay value. The interrupt delay -value can be configured through ethtool(8). The following ethtool -parameters are supported by the driver: tx-usecs, rx-usecs +value can be configured through `ethtool(8)`. The following `ethtool` +parameters are supported by the driver: ``tx-usecs``, ``rx-usecs`` -In adaptive interrupt moderation mode the interrupt delay value is +**In adaptive interrupt** moderation mode the interrupt delay value is updated by the driver dynamically and adjusted every NAPI cycle according to the traffic nature. -Adaptive coalescing can be switched on/off through ethtool(8) -adaptive_rx on|off parameter. +Adaptive coalescing can be switched on/off through `ethtool(8)`'s +:code:`adaptive_rx on|off` parameter. More information about Adaptive Interrupt Moderation (DIM) can be found in Documentation/networking/net_dim.rst @@ -214,17 +211,10 @@ The rx_copybreak is initialized by default to ENA_DEFAULT_RX_COPYBREAK and can be configured by the ETHTOOL_STUNABLE command of the SIOCETHTOOL ioctl. -SKB -=== -The driver-allocated SKB for frames received from Rx handling using -NAPI context. The allocation method depends on the size of the packet. -If the frame length is larger than rx_copybreak, napi_get_frags() -is used, otherwise netdev_alloc_skb_ip_align() is used, the buffer -content is copied (by CPU) to the SKB, and the buffer is recycled. - Statistics ========== -The user can obtain ENA device and driver statistics using ethtool. + +The user can obtain ENA device and driver statistics using `ethtool`. The driver can collect regular or extended statistics (including per-queue stats) from the device. @@ -232,22 +222,23 @@ In addition the driver logs the stats to syslog upon device reset. MTU === + The driver supports an arbitrarily large MTU with a maximum that is negotiated with the device. The driver configures MTU using the SetFeature command (ENA_ADMIN_MTU property). The user can change MTU -via ip(8) and similar legacy tools. +via `ip(8)` and similar legacy tools. Stateless Offloads ================== + The ENA driver supports: -- TSO over IPv4/IPv6 -- TSO with ECN - IPv4 header checksum offload - TCP/UDP over IPv4/IPv6 checksum offloads RSS === + - The ENA device supports RSS that allows flexible Rx traffic steering. - Toeplitz and CRC32 hash functions are supported. @@ -260,41 +251,42 @@ RSS function delivered in the Rx CQ descriptor is set in the received SKB. - The user can provide a hash key, hash function, and configure the - indirection table through ethtool(8). + indirection table through `ethtool(8)`. DATA PATH ========= + Tx -- -ena_start_xmit() is called by the stack. This function does the following: +:code:`ena_start_xmit()` is called by the stack. This function does the following: -- Maps data buffers (skb->data and frags). -- Populates ena_buf for the push buffer (if the driver and device are - in push mode.) +- Maps data buffers (``skb->data`` and frags). +- Populates ``ena_buf`` for the push buffer (if the driver and device are + in push mode). - Prepares ENA bufs for the remaining frags. -- Allocates a new request ID from the empty req_id ring. The request +- Allocates a new request ID from the empty ``req_id`` ring. The request ID is the index of the packet in the Tx info. This is used for - out-of-order TX completions. + out-of-order Tx completions. - Adds the packet to the proper place in the Tx ring. -- Calls ena_com_prepare_tx(), an ENA communication layer that converts - the ena_bufs to ENA descriptors (and adds meta ENA descriptors as - needed.) +- Calls :code:`ena_com_prepare_tx()`, an ENA communication layer that converts + the ``ena_bufs`` to ENA descriptors (and adds meta ENA descriptors as + needed). * This function also copies the ENA descriptors and the push buffer - to the Device memory space (if in push mode.) + to the Device memory space (if in push mode). -- Writes doorbell to the ENA device. +- Writes a doorbell to the ENA device. - When the ENA device finishes sending the packet, a completion interrupt is raised. - The interrupt handler schedules NAPI. -- The ena_clean_tx_irq() function is called. This function handles the +- The :code:`ena_clean_tx_irq()` function is called. This function handles the completion descriptors generated by the ENA, with a single completion descriptor per completed packet. - * req_id is retrieved from the completion descriptor. The tx_info of - the packet is retrieved via the req_id. The data buffers are - unmapped and req_id is returned to the empty req_id ring. + * ``req_id`` is retrieved from the completion descriptor. The ``tx_info`` of + the packet is retrieved via the ``req_id``. The data buffers are + unmapped and ``req_id`` is returned to the empty ``req_id`` ring. * The function stops when the completion descriptors are completed or the budget is reached. @@ -303,12 +295,11 @@ Rx - When a packet is received from the ENA device. - The interrupt handler schedules NAPI. -- The ena_clean_rx_irq() function is called. This function calls - ena_rx_pkt(), an ENA communication layer function, which returns the - number of descriptors used for a new unhandled packet, and zero if +- The :code:`ena_clean_rx_irq()` function is called. This function calls + :code:`ena_com_rx_pkt()`, an ENA communication layer function, which returns the + number of descriptors used for a new packet, and zero if no new packet is found. -- Then it calls the ena_clean_rx_irq() function. -- ena_eth_rx_skb() checks packet length: +- :code:`ena_rx_skb()` checks packet length: * If the packet is small (len < rx_copybreak), the driver allocates a SKB for the new packet, and copies the packet payload into the @@ -317,9 +308,10 @@ Rx - In this way the original data buffer is not passed to the stack and is reused for future Rx packets. - * Otherwise the function unmaps the Rx buffer, then allocates the - new SKB structure and hooks the Rx buffer to the SKB frags. + * Otherwise the function unmaps the Rx buffer, sets the first + descriptor as `skb`'s linear part and the other descriptors as the + `skb`'s frags. - The new SKB is updated with the necessary information (protocol, - checksum hw verify result, etc.), and then passed to the network - stack, using the NAPI interface function napi_gro_receive(). + checksum hw verify result, etc), and then passed to the network + stack, using the NAPI interface function :code:`napi_gro_receive()`. diff --git a/Documentation/networking/device_drivers/ethernet/google/gve.rst b/Documentation/networking/device_drivers/ethernet/google/gve.rst index 793693cef6e3..6d73ee78f3d7 100644 --- a/Documentation/networking/device_drivers/ethernet/google/gve.rst +++ b/Documentation/networking/device_drivers/ethernet/google/gve.rst @@ -47,13 +47,24 @@ The driver interacts with the device in the following ways: - Transmit and Receive Queues - See description below +Descriptor Formats +------------------ +GVE supports two descriptor formats: GQI and DQO. These two formats have +entirely different descriptors, which will be described below. + Registers --------- -All registers are MMIO and big endian. +All registers are MMIO. The registers are used for initializing and configuring the device as well as querying device status in response to management interrupts. +Endianness +---------- +- Admin Queue messages and registers are all Big Endian. +- GQI descriptors and datapath registers are Big Endian. +- DQO descriptors and datapath registers are Little Endian. + Admin Queue (AQ) ---------------- The Admin Queue is a PAGE_SIZE memory block, treated as an array of AQ @@ -97,10 +108,10 @@ the queues associated with that interrupt. The handler for these irqs schedule the napi for that block to run and poll the queues. -Traffic Queues --------------- -gVNIC's queues are composed of a descriptor ring and a buffer and are -assigned to a notification block. +GQI Traffic Queues +------------------ +GQI queues are composed of a descriptor ring and a buffer and are assigned to a +notification block. The descriptor rings are power-of-two-sized ring buffers consisting of fixed-size descriptors. They advance their head pointer using a __be32 @@ -121,3 +132,35 @@ Receive The buffers for receive rings are put into a data ring that is the same length as the descriptor ring and the head and tail pointers advance over the rings together. + +DQO Traffic Queues +------------------ +- Every TX and RX queue is assigned a notification block. + +- TX and RX buffers queues, which send descriptors to the device, use MMIO + doorbells to notify the device of new descriptors. + +- RX and TX completion queues, which receive descriptors from the device, use a + "generation bit" to know when a descriptor was populated by the device. The + driver initializes all bits with the "current generation". The device will + populate received descriptors with the "next generation" which is inverted + from the current generation. When the ring wraps, the current/next generation + are swapped. + +- It's the driver's responsibility to ensure that the RX and TX completion + queues are not overrun. This can be accomplished by limiting the number of + descriptors posted to HW. + +- TX packets have a 16 bit completion_tag and RX buffers have a 16 bit + buffer_id. These will be returned on the TX completion and RX queues + respectively to let the driver know which packet/buffer was completed. + +Transmit +~~~~~~~~ +A packet's buffers are DMA mapped for the device to access before transmission. +After the packet was successfully transmitted, the buffers are unmapped. + +Receive +~~~~~~~ +The driver posts fixed sized buffers to HW on the RX buffer queue. The packet +received on the associated RX queue may span multiple descriptors. diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst index 8a9b18573688..ac35bd472bdc 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst @@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the driver. To re-enable ATR, the sideband can be disabled with the ethtool -K option. For example:: - ethtool –K [adapter] ntuple [off|on] + ethtool -K [adapter] ntuple [off|on] If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is @@ -466,7 +466,7 @@ network. PTP support varies among Intel devices that support this driver. Use "ethtool -T <netdev name>" to get a definitive list of PTP capabilities supported by the device. -IEEE 802.1ad (QinQ) Support +IEEE 802.1ad (QinQ) Support --------------------------- The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as @@ -523,8 +523,8 @@ of a port's bandwidth (should it be available). The sum of all the values for Maximum Bandwidth is not restricted, because no more than 100% of a port's bandwidth can ever be used. -NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions -per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says +NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions +per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says "add vsi failed for VF N, aq_err 16". To workaround the issue, enable less than 64 virtual functions (VFs). @@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates. Totals must be equal or less than port speed. For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network -monitoring tools such as ifstat or sar –n DEV [interval] [number of samples] +monitoring tools such as `ifstat` or `sar -n DEV [interval] [number of samples]` 2. Enable HW TC offload on interface:: diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst index 52e037b11c97..151af0a8da9c 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst @@ -113,7 +113,7 @@ which the AVF is associated. The following are base mode features: - AVF device ID - HW mailbox is used for VF to PF communications (including on Windows) -IEEE 802.1ad (QinQ) Support +IEEE 802.1ad (QinQ) Support --------------------------- The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as @@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates. Totals must be equal or less than port speed. For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network -monitoring tools such as ifstat or sar –n DEV [interval] [number of samples] +monitoring tools such as ``ifstat`` or ``sar -n DEV [interval] [number of samples]`` NOTE: Setting up channels via ethtool (ethtool -L) is not supported when the diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst index 936a10f1942c..ef8cb62e82a1 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst @@ -12,6 +12,7 @@ Contents - `Enabling the driver and kconfig options`_ - `Devlink info`_ - `Devlink parameters`_ +- `Bridge offload`_ - `mlx5 subfunction`_ - `mlx5 function attributes`_ - `Devlink health reporters`_ @@ -217,6 +218,37 @@ users try to enable them. $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev +Bridge offload +============== +The mlx5 driver implements support for offloading bridge rules when in switchdev +mode. Linux bridge FDBs are automatically offloaded when mlx5 switchdev +representor is attached to bridge. + +- Change device to switchdev mode:: + + $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev + +- Attach mlx5 switchdev representor 'enp8s0f0' to bridge netdev 'bridge1':: + + $ ip link set enp8s0f0 master bridge1 + +VLANs +----- +Following bridge VLAN functions are supported by mlx5: + +- VLAN filtering (including multiple VLANs per port):: + + $ ip link set bridge1 type bridge vlan_filtering 1 + $ bridge vlan add dev enp8s0f0 vid 2-3 + +- VLAN push on bridge ingress:: + + $ bridge vlan add dev enp8s0f0 vid 3 pvid + +- VLAN pop on bridge egress:: + + $ bridge vlan add dev enp8s0f0 vid 3 untagged + mlx5 subfunction ================ mlx5 supports subfunction management using devlink port (see :ref:`Documentation/networking/devlink/devlink-port.rst <devlink_port>`) interface. @@ -568,3 +600,59 @@ tc and eswitch offloads tracepoints: $ cat /sys/kernel/debug/tracing/trace ... kworker/u48:7-2221 [009] ...1 1475.387435: mlx5e_rep_neigh_update: netdev: ens1f0 MAC: 24:8a:07:9a:17:9a IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_connected=1 + +Bridge offloads tracepoints: + +- mlx5_esw_bridge_fdb_entry_init: trace bridge FDB entry offloaded to mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_init >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + kworker/u20:9-2217 [003] ...1 318.582243: mlx5_esw_bridge_fdb_entry_init: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=0 flags=0 used=0 + +- mlx5_esw_bridge_fdb_entry_cleanup: trace bridge FDB entry deleted from mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_cleanup >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-2581 [005] ...1 318.629871: mlx5_esw_bridge_fdb_entry_cleanup: net_device=enp8s0f0_1 addr=e4:fd:05:08:00:03 vid=0 flags=0 used=16 + +- mlx5_esw_bridge_fdb_entry_refresh: trace bridge FDB entry offload refreshed in + mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_refresh >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + kworker/u20:8-3849 [003] ...1 466716: mlx5_esw_bridge_fdb_entry_refresh: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=3 flags=0 used=0 + +- mlx5_esw_bridge_vlan_create: trace bridge VLAN object add on mlx5 + representor:: + + $ echo mlx5:mlx5_esw_bridge_vlan_create >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-2560 [007] ...1 318.460258: mlx5_esw_bridge_vlan_create: vid=1 flags=6 + +- mlx5_esw_bridge_vlan_cleanup: trace bridge VLAN object delete from mlx5 + representor:: + + $ echo mlx5:mlx5_esw_bridge_vlan_cleanup >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + bridge-2582 [007] ...1 318.653496: mlx5_esw_bridge_vlan_cleanup: vid=2 flags=8 + +- mlx5_esw_bridge_vport_init: trace mlx5 vport assigned with bridge upper + device:: + + $ echo mlx5:mlx5_esw_bridge_vport_init >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-2560 [007] ...1 318.458915: mlx5_esw_bridge_vport_init: vport_num=1 + +- mlx5_esw_bridge_vport_cleanup: trace mlx5 vport removed from bridge upper + device:: + + $ echo mlx5:mlx5_esw_bridge_vport_cleanup >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-5387 [000] ...1 573713: mlx5_esw_bridge_vport_cleanup: vport_num=1 diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index d8279de7bf25..3a5a1d46e77e 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -18,6 +18,7 @@ Contents: qlogic/index wan/index wifi/index + wwan/index .. only:: subproject and html diff --git a/Documentation/networking/device_drivers/wwan/index.rst b/Documentation/networking/device_drivers/wwan/index.rst new file mode 100644 index 000000000000..1cb8c7371401 --- /dev/null +++ b/Documentation/networking/device_drivers/wwan/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +WWAN Device Drivers +=================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + iosm + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/wwan/iosm.rst b/Documentation/networking/device_drivers/wwan/iosm.rst new file mode 100644 index 000000000000..aceb0223eb46 --- /dev/null +++ b/Documentation/networking/device_drivers/wwan/iosm.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +.. Copyright (C) 2020-21 Intel Corporation + +.. _iosm_driver_doc: + +=========================================== +IOSM Driver for Intel M.2 PCIe based Modems +=========================================== +The IOSM (IPC over Shared Memory) driver is a WWAN PCIe host driver developed +for linux or chrome platform for data exchange over PCIe interface between +Host platform & Intel M.2 Modem. The driver exposes interface conforming to the +MBIM protocol [1]. Any front end application ( eg: Modem Manager) could easily +manage the MBIM interface to enable data communication towards WWAN. + +Basic usage +=========== +MBIM functions are inactive when unmanaged. The IOSM driver only provides a +userspace interface MBIM "WWAN PORT" representing MBIM control channel and does +not play any role in managing the functionality. It is the job of a userspace +application to detect port enumeration and enable MBIM functionality. + +Examples of few such userspace application are: +- mbimcli (included with the libmbim [2] library), and +- Modem Manager [3] + +Management Applications to carry out below required actions for establishing +MBIM IP session: +- open the MBIM control channel +- configure network connection settings +- connect to network +- configure IP network interface + +Management application development +================================== +The driver and userspace interfaces are described below. The MBIM protocol is +described in [1] Mobile Broadband Interface Model v1.0 Errata-1. + +MBIM control channel userspace ABI +---------------------------------- + +/dev/wwan0mbim0 character device +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The driver exposes an MBIM interface to the MBIM function by implementing +MBIM WWAN Port. The userspace end of the control channel pipe is a +/dev/wwan0mbim0 character device. Application shall use this interface for +MBIM protocol communication. + +Fragmentation +~~~~~~~~~~~~~ +The userspace application is responsible for all control message fragmentation +and defragmentation as per MBIM specification. + +/dev/wwan0mbim0 write() +~~~~~~~~~~~~~~~~~~~~~~~ +The MBIM control messages from the management application must not exceed the +negotiated control message size. + +/dev/wwan0mbim0 read() +~~~~~~~~~~~~~~~~~~~~~~ +The management application must accept control messages of up the negotiated +control message size. + +MBIM data channel userspace ABI +------------------------------- + +wwan0-X network device +~~~~~~~~~~~~~~~~~~~~~~ +The IOSM driver exposes IP link interface "wwan0-X" of type "wwan" for IP +traffic. Iproute network utility is used for creating "wwan0-X" network +interface and for associating it with MBIM IP session. The Driver supports +upto 8 IP sessions for simultaneous IP communication. + +The userspace management application is responsible for creating new IP link +prior to establishing MBIM IP session where the SessionId is greater than 0. + +For example, creating new IP link for a MBIM IP session with SessionId 1: + + ip link add dev wwan0-1 parentdev-name wwan0 type wwan linkid 1 + +The driver will automatically map the "wwan0-1" network device to MBIM IP +session 1. + +References +========== +[1] "MBIM (Mobile Broadband Interface Model) Errata-1" + - https://www.usb.org/document-library/ + +[2] libmbim - "a glib-based library for talking to WWAN modems and + devices which speak the Mobile Interface Broadband Model (MBIM) + protocol" + - http://www.freedesktop.org/wiki/Software/libmbim/ + +[3] Modem Manager - "a DBus-activated daemon which controls mobile + broadband (2G/3G/4G) devices and connections" + - http://www.freedesktop.org/wiki/Software/ModemManager/ diff --git a/Documentation/networking/devlink/devlink-port.rst b/Documentation/networking/devlink/devlink-port.rst index ab790e7980b8..7627b1da01f2 100644 --- a/Documentation/networking/devlink/devlink-port.rst +++ b/Documentation/networking/devlink/devlink-port.rst @@ -164,6 +164,41 @@ device to instantiate the subfunction device on particular PCI function. A subfunction device is created on the :ref:`Documentation/driver-api/auxiliary_bus.rst <auxiliary_bus>`. At this point a matching subfunction driver binds to the subfunction's auxiliary device. +Rate object management +====================== + +Devlink provides API to manage tx rates of single devlink port or a group. +This is done through rate objects, which can be one of the two types: + +``leaf`` + Represents a single devlink port; created/destroyed by the driver. Since leaf + have 1to1 mapping to its devlink port, in user space it is referred as + ``pci/<bus_addr>/<port_index>``; + +``node`` + Represents a group of rate objects (leafs and/or nodes); created/deleted by + request from the userspace; initially empty (no rate objects added). In + userspace it is referred as ``pci/<bus_addr>/<node_name>``, where + ``node_name`` can be any identifier, except decimal number, to avoid + collisions with leafs. + +API allows to configure following rate object's parameters: + +``tx_share`` + Minimum TX rate value shared among all other rate objects, or rate objects + that parts of the parent group, if it is a part of the same group. + +``tx_max`` + Maximum TX rate value. + +``parent`` + Parent node name. Parent node rate limits are considered as additional limits + to all node children limits. ``tx_max`` is an upper limit for children. + ``tx_share`` is a total bandwidth distributed among children. + +Driver implementations are allowed to support both or either rate object types +and setting methods of their parameters. + Terms and Definitions ===================== diff --git a/Documentation/networking/devlink/devlink-region.rst b/Documentation/networking/devlink/devlink-region.rst index 3654c3e9658f..58fe95e9a49d 100644 --- a/Documentation/networking/devlink/devlink-region.rst +++ b/Documentation/networking/devlink/devlink-region.rst @@ -22,7 +22,7 @@ The major benefit to creating a region is to provide access to internal address regions that are otherwise inaccessible to the user. Regions may also be used to provide an additional way to debug complex error -states, but see also :doc:`devlink-health` +states, but see also Documentation/networking/devlink/devlink-health.rst Regions may optionally support capturing a snapshot on demand via the ``DEVLINK_CMD_REGION_NEW`` netlink message. A driver wishing to allow diff --git a/Documentation/networking/devlink/devlink-trap.rst b/Documentation/networking/devlink/devlink-trap.rst index 935b6397e8cf..90d1381b88de 100644 --- a/Documentation/networking/devlink/devlink-trap.rst +++ b/Documentation/networking/devlink/devlink-trap.rst @@ -495,8 +495,9 @@ help debug packet drops caused by these exceptions. The following list includes links to the description of driver-specific traps registered by various device drivers: - * :doc:`netdevsim` - * :doc:`mlxsw` + * Documentation/networking/devlink/netdevsim.rst + * Documentation/networking/devlink/mlxsw.rst + * Documentation/networking/devlink/prestera.rst .. _Generic-Packet-Trap-Groups: diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index 8428a1220723..b3b9e0692088 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -46,3 +46,4 @@ parameters, info versions, and other features it supports. qed ti-cpsw-switch am65-nuss-cpsw-switch + prestera diff --git a/Documentation/networking/devlink/netdevsim.rst b/Documentation/networking/devlink/netdevsim.rst index 02c2d20dc673..8a292fb5aaea 100644 --- a/Documentation/networking/devlink/netdevsim.rst +++ b/Documentation/networking/devlink/netdevsim.rst @@ -57,6 +57,32 @@ entries, FIB rule entries and nexthops that the driver will allow. $ devlink resource set netdevsim/netdevsim0 path /nexthops size 16 $ devlink dev reload netdevsim/netdevsim0 +Rate objects +============ + +The ``netdevsim`` driver supports rate objects management, which includes: + +- registerging/unregistering leaf rate objects per VF devlink port; +- creation/deletion node rate objects; +- setting tx_share and tx_max rate values for any rate object type; +- setting parent node for any rate object type. + +Rate nodes and it's parameters are exposed in ``netdevsim`` debugfs in RO mode. +For example created rate node with name ``some_group``: + +.. code:: shell + + $ ls /sys/kernel/debug/netdevsim/netdevsim0/rate_groups/some_group + rate_parent tx_max tx_share + +Same parameters are exposed for leaf objects in corresponding ports directories. +For ex.: + +.. code:: shell + + $ ls /sys/kernel/debug/netdevsim/netdevsim0/ports/1 + dev ethtool rate_parent tx_max tx_share + Driver-specific Traps ===================== diff --git a/Documentation/networking/devlink/prestera.rst b/Documentation/networking/devlink/prestera.rst new file mode 100644 index 000000000000..49409d1d3081 --- /dev/null +++ b/Documentation/networking/devlink/prestera.rst @@ -0,0 +1,141 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================== +prestera devlink support +======================== + +This document describes the devlink features implemented by the ``prestera`` +device driver. + +Driver-specific Traps +===================== + +.. list-table:: List of Driver-specific Traps Registered by ``prestera`` + :widths: 5 5 90 + + * - Name + - Type + - Description +.. list-table:: List of Driver-specific Traps Registered by ``prestera`` + :widths: 5 5 90 + + * - Name + - Type + - Description + * - ``arp_bc`` + - ``trap`` + - Traps ARP broadcast packets (both requests/responses) + * - ``is_is`` + - ``trap`` + - Traps IS-IS packets + * - ``ospf`` + - ``trap`` + - Traps OSPF packets + * - ``ip_bc_mac`` + - ``trap`` + - Traps IPv4 packets with broadcast DA Mac address + * - ``stp`` + - ``trap`` + - Traps STP BPDU + * - ``lacp`` + - ``trap`` + - Traps LACP packets + * - ``lldp`` + - ``trap`` + - Traps LLDP packets + * - ``router_mc`` + - ``trap`` + - Traps multicast packets + * - ``vrrp`` + - ``trap`` + - Traps VRRP packets + * - ``dhcp`` + - ``trap`` + - Traps DHCP packets + * - ``mtu_error`` + - ``trap`` + - Traps (exception) packets that exceeded port's MTU + * - ``mac_to_me`` + - ``trap`` + - Traps packets with switch-port's DA Mac address + * - ``ttl_error`` + - ``trap`` + - Traps (exception) IPv4 packets whose TTL exceeded + * - ``ipv4_options`` + - ``trap`` + - Traps (exception) packets due to the malformed IPV4 header options + * - ``ip_default_route`` + - ``trap`` + - Traps packets that have no specific IP interface (IP to me) and no forwarding prefix + * - ``local_route`` + - ``trap`` + - Traps packets that have been send to one of switch IP interfaces addresses + * - ``ipv4_icmp_redirect`` + - ``trap`` + - Traps (exception) IPV4 ICMP redirect packets + * - ``arp_response`` + - ``trap`` + - Traps ARP replies packets that have switch-port's DA Mac address + * - ``acl_code_0`` + - ``trap`` + - Traps packets that have ACL priority set to 0 (tc pref 0) + * - ``acl_code_1`` + - ``trap`` + - Traps packets that have ACL priority set to 1 (tc pref 1) + * - ``acl_code_2`` + - ``trap`` + - Traps packets that have ACL priority set to 2 (tc pref 2) + * - ``acl_code_3`` + - ``trap`` + - Traps packets that have ACL priority set to 3 (tc pref 3) + * - ``acl_code_4`` + - ``trap`` + - Traps packets that have ACL priority set to 4 (tc pref 4) + * - ``acl_code_5`` + - ``trap`` + - Traps packets that have ACL priority set to 5 (tc pref 5) + * - ``acl_code_6`` + - ``trap`` + - Traps packets that have ACL priority set to 6 (tc pref 6) + * - ``acl_code_7`` + - ``trap`` + - Traps packets that have ACL priority set to 7 (tc pref 7) + * - ``ipv4_bgp`` + - ``trap`` + - Traps IPv4 BGP packets + * - ``ssh`` + - ``trap`` + - Traps SSH packets + * - ``telnet`` + - ``trap`` + - Traps Telnet packets + * - ``icmp`` + - ``trap`` + - Traps ICMP packets + * - ``rxdma_drop`` + - ``drop`` + - Drops packets (RxDMA) due to the lack of ingress buffers etc. + * - ``port_no_vlan`` + - ``drop`` + - Drops packets due to faulty-configured network or due to internal bug (config issue). + * - ``local_port`` + - ``drop`` + - Drops packets whose decision (FDB entry) is to bridge packet back to the incoming port/trunk. + * - ``invalid_sa`` + - ``drop`` + - Drops packets with multicast source MAC address. + * - ``illegal_ip_addr`` + - ``drop`` + - Drops packets with illegal SIP/DIP multicast/unicast addresses. + * - ``illegal_ipv4_hdr`` + - ``drop`` + - Drops packets with illegal IPV4 header. + * - ``ip_uc_dip_da_mismatch`` + - ``drop`` + - Drops packets with destination MAC being unicast, but destination IP address being multicast. + * - ``ip_sip_is_zero`` + - ``drop`` + - Drops packets with zero (0) IPV4 source address. + * - ``met_red`` + - ``drop`` + - Drops non-conforming packets (dropped by Ingress policer, metering drop), e.g. packet rate exceeded configured bandwith. diff --git a/Documentation/networking/dsa/configuration.rst b/Documentation/networking/dsa/configuration.rst index 774f0e76c746..2b08f1a772d3 100644 --- a/Documentation/networking/dsa/configuration.rst +++ b/Documentation/networking/dsa/configuration.rst @@ -292,3 +292,71 @@ configuration. # bring up the bridge devices ip link set br0 up + +Forwarding database (FDB) management +------------------------------------ + +The existing DSA switches do not have the necessary hardware support to keep +the software FDB of the bridge in sync with the hardware tables, so the two +tables are managed separately (``bridge fdb show`` queries both, and depending +on whether the ``self`` or ``master`` flags are being used, a ``bridge fdb +add`` or ``bridge fdb del`` command acts upon entries from one or both tables). + +Up until kernel v4.14, DSA only supported user space management of bridge FDB +entries using the bridge bypass operations (which do not update the software +FDB, just the hardware one) using the ``self`` flag (which is optional and can +be omitted). + + .. code-block:: sh + + bridge fdb add dev swp0 00:01:02:03:04:05 self static + # or shorthand + bridge fdb add dev swp0 00:01:02:03:04:05 static + +Due to a bug, the bridge bypass FDB implementation provided by DSA did not +distinguish between ``static`` and ``local`` FDB entries (``static`` are meant +to be forwarded, while ``local`` are meant to be locally terminated, i.e. sent +to the host port). Instead, all FDB entries with the ``self`` flag (implicit or +explicit) are treated by DSA as ``static`` even if they are ``local``. + + .. code-block:: sh + + # This command: + bridge fdb add dev swp0 00:01:02:03:04:05 static + # behaves the same for DSA as this command: + bridge fdb add dev swp0 00:01:02:03:04:05 local + # or shorthand, because the 'local' flag is implicit if 'static' is not + # specified, it also behaves the same as: + bridge fdb add dev swp0 00:01:02:03:04:05 + +The last command is an incorrect way of adding a static bridge FDB entry to a +DSA switch using the bridge bypass operations, and works by mistake. Other +drivers will treat an FDB entry added by the same command as ``local`` and as +such, will not forward it, as opposed to DSA. + +Between kernel v4.14 and v5.14, DSA has supported in parallel two modes of +adding a bridge FDB entry to the switch: the bridge bypass discussed above, as +well as a new mode using the ``master`` flag which installs FDB entries in the +software bridge too. + + .. code-block:: sh + + bridge fdb add dev swp0 00:01:02:03:04:05 master static + +Since kernel v5.14, DSA has gained stronger integration with the bridge's +software FDB, and the support for its bridge bypass FDB implementation (using +the ``self`` flag) has been removed. This results in the following changes: + + .. code-block:: sh + + # This is the only valid way of adding an FDB entry that is supported, + # compatible with v4.14 kernels and later: + bridge fdb add dev swp0 00:01:02:03:04:05 master static + # This command is no longer buggy and the entry is properly treated as + # 'local' instead of being forwarded: + bridge fdb add dev swp0 00:01:02:03:04:05 + # This command no longer installs a static FDB entry to hardware: + bridge fdb add dev swp0 00:01:02:03:04:05 static + +Script writers are therefore encouraged to use the ``master static`` set of +flags when working with bridge FDB entries on DSA switch interfaces. diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 8688009514cc..20baacf2bc5c 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -93,14 +93,15 @@ A tagging protocol may tag all packets with switch tags of the same length, or the tag length might vary (for example packets with PTP timestamps might require an extended switch tag, or there might be one tag length on TX and a different one on RX). Either way, the tagging protocol driver must populate the -``struct dsa_device_ops::overhead`` with the length in octets of the longest -switch frame header. The DSA framework will automatically adjust the MTU of the -master interface to accomodate for this extra size in order for DSA user ports -to support the standard MTU (L2 payload length) of 1500 octets. The ``overhead`` -is also used to request from the network stack, on a best-effort basis, the -allocation of packets with a ``needed_headroom`` or ``needed_tailroom`` -sufficient such that the act of pushing the switch tag on transmission of a -packet does not cause it to reallocate due to lack of memory. +``struct dsa_device_ops::needed_headroom`` and/or ``struct dsa_device_ops::needed_tailroom`` +with the length in octets of the longest switch frame header/trailer. The DSA +framework will automatically adjust the MTU of the master interface to +accommodate for this extra size in order for DSA user ports to support the +standard MTU (L2 payload length) of 1500 octets. The ``needed_headroom`` and +``needed_tailroom`` properties are also used to request from the network stack, +on a best-effort basis, the allocation of packets with enough extra space such +that the act of pushing the switch tag on transmission of a packet does not +cause it to reallocate due to lack of memory. Even though applications are not expected to parse DSA-specific frame headers, the format on the wire of the tagging protocol represents an Application Binary @@ -169,8 +170,8 @@ The job of this method is to prepare the skb in a way that the switch will understand what egress port the packet is for (and not deliver it towards other ports). Typically this is fulfilled by pushing a frame header. Checking for insufficient size in the skb headroom or tailroom is unnecessary provided that -the ``overhead`` and ``tail_tag`` properties were filled out properly, because -DSA ensures there is enough space before calling this method. +the ``needed_headroom`` and ``needed_tailroom`` properties were filled out +properly, because DSA ensures there is enough space before calling this method. The reception of a packet goes through the tagger's ``rcv`` function. The passed ``struct sk_buff *skb`` has ``skb->data`` pointing at diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst index 7395a33baaf9..da4057ba37f1 100644 --- a/Documentation/networking/dsa/sja1105.rst +++ b/Documentation/networking/dsa/sja1105.rst @@ -5,7 +5,7 @@ NXP SJA1105 switch driver Overview ======== -The NXP SJA1105 is a family of 6 devices: +The NXP SJA1105 is a family of 10 SPI-managed automotive switches: - SJA1105E: First generation, no TTEthernet - SJA1105T: First generation, TTEthernet @@ -13,9 +13,11 @@ The NXP SJA1105 is a family of 6 devices: - SJA1105Q: Second generation, TTEthernet, no SGMII - SJA1105R: Second generation, no TTEthernet, SGMII - SJA1105S: Second generation, TTEthernet, SGMII - -These are SPI-managed automotive switches, with all ports being gigabit -capable, and supporting MII/RMII/RGMII and optionally SGMII on one port. +- SJA1110A: Third generation, TTEthernet, SGMII, integrated 100base-T1 and + 100base-TX PHYs +- SJA1110B: Third generation, TTEthernet, SGMII, 100base-T1, 100base-TX +- SJA1110C: Third generation, TTEthernet, SGMII, 100base-T1, 100base-TX +- SJA1110D: Third generation, TTEthernet, SGMII, 100base-T1 Being automotive parts, their configuration interface is geared towards set-and-forget use, with minimal dynamic interaction at runtime. They @@ -579,3 +581,54 @@ A board would need to hook up the PHYs connected to the switch to any other MDIO bus available to Linux within the system (e.g. to the DSA master's MDIO bus). Link state management then works by the driver manually keeping in sync (over SPI commands) the MAC link speed with the settings negotiated by the PHY. + +By comparison, the SJA1110 supports an MDIO slave access point over which its +internal 100base-T1 PHYs can be accessed from the host. This is, however, not +used by the driver, instead the internal 100base-T1 and 100base-TX PHYs are +accessed through SPI commands, modeled in Linux as virtual MDIO buses. + +The microcontroller attached to the SJA1110 port 0 also has an MDIO controller +operating in master mode, however the driver does not support this either, +since the microcontroller gets disabled when the Linux driver operates. +Discrete PHYs connected to the switch ports should have their MDIO interface +attached to an MDIO controller from the host system and not to the switch, +similar to SJA1105. + +Port compatibility matrix +------------------------- + +The SJA1105 port compatibility matrix is: + +===== ============== ============== ============== +Port SJA1105E/T SJA1105P/Q SJA1105R/S +===== ============== ============== ============== +0 xMII xMII xMII +1 xMII xMII xMII +2 xMII xMII xMII +3 xMII xMII xMII +4 xMII xMII SGMII +===== ============== ============== ============== + + +The SJA1110 port compatibility matrix is: + +===== ============== ============== ============== ============== +Port SJA1110A SJA1110B SJA1110C SJA1110D +===== ============== ============== ============== ============== +0 RevMII (uC) RevMII (uC) RevMII (uC) RevMII (uC) +1 100base-TX 100base-TX 100base-TX + or SGMII SGMII +2 xMII xMII xMII xMII + or SGMII or SGMII +3 xMII xMII xMII + or SGMII or SGMII SGMII + or 2500base-X or 2500base-X or 2500base-X +4 SGMII SGMII SGMII SGMII + or 2500base-X or 2500base-X or 2500base-X or 2500base-X +5 100base-T1 100base-T1 100base-T1 100base-T1 +6 100base-T1 100base-T1 100base-T1 100base-T1 +7 100base-T1 100base-T1 100base-T1 100base-T1 +8 100base-T1 100base-T1 n/a n/a +9 100base-T1 100base-T1 n/a n/a +10 100base-T1 n/a n/a n/a +===== ============== ============== ============== ============== diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 25131df3c2bd..6ea91e41593f 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -1363,8 +1363,8 @@ in an implementation specific way. ``ETHTOOL_A_FEC_AUTO`` requests the driver to choose FEC mode based on SFP module parameters. This does not mean autonegotiation. -MODULE_EEPROM -============= +MODULE_EEPROM_GET +================= Fetch module EEPROM data dump. This interface is designed to allow dumps of at most 1/2 page at once. This @@ -1383,12 +1383,14 @@ Request contents: ``ETHTOOL_A_MODULE_EEPROM_I2C_ADDRESS`` u8 page I2C address ======================================= ====== ========================== +If ``ETHTOOL_A_MODULE_EEPROM_BANK`` is not specified, bank 0 is assumed. + Kernel response contents: +---------------------------------------------+--------+---------------------+ | ``ETHTOOL_A_MODULE_EEPROM_HEADER`` | nested | reply header | +---------------------------------------------+--------+---------------------+ - | ``ETHTOOL_A_MODULE_EEPROM_DATA`` | nested | array of bytes from | + | ``ETHTOOL_A_MODULE_EEPROM_DATA`` | binary | array of bytes from | | | | module EEPROM | +---------------------------------------------+--------+---------------------+ diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index c2ecc9894fd0..b3fa522e4cd9 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -99,6 +99,35 @@ fib_multipath_hash_policy - INTEGER - 0 - Layer 3 - 1 - Layer 4 - 2 - Layer 3 or inner Layer 3 if present + - 3 - Custom multipath hash. Fields used for multipath hash calculation + are determined by fib_multipath_hash_fields sysctl + +fib_multipath_hash_fields - UNSIGNED INTEGER + When fib_multipath_hash_policy is set to 3 (custom multipath hash), the + fields used for multipath hash calculation are determined by this + sysctl. + + This value is a bitmask which enables various fields for multipath hash + calculation. + + Possible fields are: + + ====== ============================ + 0x0001 Source IP address + 0x0002 Destination IP address + 0x0004 IP protocol + 0x0008 Unused (Flow Label) + 0x0010 Source port + 0x0020 Destination port + 0x0040 Inner source IP address + 0x0080 Inner destination IP address + 0x0100 Inner IP protocol + 0x0200 Inner Flow Label + 0x0400 Inner source port + 0x0800 Inner destination port + ====== ============================ + + Default: 0x0007 (source IP, destination IP and IP protocol) fib_sync_mem - UNSIGNED INTEGER Amount of dirty memory from fib entries that can be backlogged before @@ -732,6 +761,31 @@ tcp_syncookies - INTEGER network connections you can set this knob to 2 to enable unconditionally generation of syncookies. +tcp_migrate_req - BOOLEAN + The incoming connection is tied to a specific listening socket when + the initial SYN packet is received during the three-way handshake. + When a listener is closed, in-flight request sockets during the + handshake and established sockets in the accept queue are aborted. + + If the listener has SO_REUSEPORT enabled, other listeners on the + same port should have been able to accept such connections. This + option makes it possible to migrate such child sockets to another + listener after close() or shutdown(). + + The BPF_SK_REUSEPORT_SELECT_OR_MIGRATE type of eBPF program should + usually be used to define the policy to pick an alive listener. + Otherwise, the kernel will randomly pick an alive listener only if + this option is enabled. + + Note that migration between listeners with different settings may + crash applications. Let's say migration happens from listener A to + B, and only B has TCP_SAVE_SYN enabled. B cannot read SYN data from + the requests migrated from A. To avoid such a situation, cancel + migration by returning SK_DROP in the type of eBPF program, or + disable this option. + + Default: 0 + tcp_fastopen - INTEGER Enable TCP Fast Open (RFC7413) to send and accept data in the opening SYN packet. @@ -1743,6 +1797,35 @@ fib_multipath_hash_policy - INTEGER - 0 - Layer 3 (source and destination addresses plus flow label) - 1 - Layer 4 (standard 5-tuple) - 2 - Layer 3 or inner Layer 3 if present + - 3 - Custom multipath hash. Fields used for multipath hash calculation + are determined by fib_multipath_hash_fields sysctl + +fib_multipath_hash_fields - UNSIGNED INTEGER + When fib_multipath_hash_policy is set to 3 (custom multipath hash), the + fields used for multipath hash calculation are determined by this + sysctl. + + This value is a bitmask which enables various fields for multipath hash + calculation. + + Possible fields are: + + ====== ============================ + 0x0001 Source IP address + 0x0002 Destination IP address + 0x0004 IP protocol + 0x0008 Flow Label + 0x0010 Source port + 0x0020 Destination port + 0x0040 Inner source IP address + 0x0080 Inner destination IP address + 0x0100 Inner IP protocol + 0x0200 Inner Flow Label + 0x0400 Inner source port + 0x0800 Inner destination port + ====== ============================ + + Default: 0x0007 (source IP, destination IP and IP protocol) anycast_src_echo_reply - BOOLEAN Controls the use of anycast addresses as source addresses for ICMPv6 @@ -2751,6 +2834,18 @@ encap_port - INTEGER Default: 0 +plpmtud_probe_interval - INTEGER + The time interval (in milliseconds) for the PLPMTUD probe timer, + which is configured to expire after this period to receive an + acknowledgment to a probe packet. This is also the time interval + between the probes for the current pmtu when the probe search + is done. + + PLPMTUD will be disabled when 0 is set, and other values for it + must be >= 5000. + + Default: 0 + ``/proc/sys/net/core/*`` ======================== diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index 6af0196c4297..76d939e688b8 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -7,13 +7,13 @@ MPTCP Sysfs variables /proc/sys/net/mptcp/* Variables =============================== -enabled - INTEGER +enabled - BOOLEAN Control whether MPTCP sockets can be created. - MPTCP sockets can be created if the value is nonzero. This is - a per-namespace sysctl. + MPTCP sockets can be created if the value is 1. This is a + per-namespace sysctl. - Default: 1 + Default: 1 (enabled) add_addr_timeout - INTEGER (seconds) Set the timeout after which an ADD_ADDR control message will be @@ -24,3 +24,24 @@ add_addr_timeout - INTEGER (seconds) sysctl. Default: 120 + +checksum_enabled - BOOLEAN + Control whether DSS checksum can be enabled. + + DSS checksum can be enabled if the value is nonzero. This is a + per-namespace sysctl. + + Default: 0 + +allow_join_initial_addr_port - BOOLEAN + Allow peers to send join requests to the IP address and port number used + by the initial subflow if the value is 1. This controls a flag that is + sent to the peer at connection time, and whether such join requests are + accepted or denied. + + Joins to addresses advertised with ADD_ADDR are not affected by this + value. + + This is a per-namespace sysctl. + + Default: 1 diff --git a/Documentation/networking/nf_conntrack-sysctl.rst b/Documentation/networking/nf_conntrack-sysctl.rst index 11a9b76786cb..0467b30e4abe 100644 --- a/Documentation/networking/nf_conntrack-sysctl.rst +++ b/Documentation/networking/nf_conntrack-sysctl.rst @@ -177,3 +177,27 @@ nf_conntrack_gre_timeout_stream - INTEGER (seconds) This extended timeout will be used in case there is an GRE stream detected. + +nf_flowtable_tcp_timeout - INTEGER (seconds) + default 30 + + Control offload timeout for tcp connections. + TCP connections may be offloaded from nf conntrack to nf flow table. + Once aged, the connection is returned to nf conntrack with tcp pickup timeout. + +nf_flowtable_tcp_pickup - INTEGER (seconds) + default 120 + + TCP connection timeout after being aged from nf flow table offload. + +nf_flowtable_udp_timeout - INTEGER (seconds) + default 30 + + Control offload timeout for udp connections. + UDP connections may be offloaded from nf conntrack to nf flow table. + Once aged, the connection is returned to nf conntrack with udp pickup timeout. + +nf_flowtable_udp_pickup - INTEGER (seconds) + default 30 + + UDP connection timeout after being aged from nf flow table offload. diff --git a/Documentation/networking/packet_mmap.rst b/Documentation/networking/packet_mmap.rst index 500ef60b1b82..c5da1a5d93de 100644 --- a/Documentation/networking/packet_mmap.rst +++ b/Documentation/networking/packet_mmap.rst @@ -153,7 +153,7 @@ As capture, each frame contains two parts:: struct ifreq s_ifr; ... - strncpy (s_ifr.ifr_name, "eth0", sizeof(s_ifr.ifr_name)); + strscpy_pad (s_ifr.ifr_name, "eth0", sizeof(s_ifr.ifr_name)); /* get interface index of eth0 */ ioctl(this->socket, SIOCGIFINDEX, &s_ifr); diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst index 3f05d50ecd6e..571ba08386e7 100644 --- a/Documentation/networking/phy.rst +++ b/Documentation/networking/phy.rst @@ -292,6 +292,12 @@ Some of the interface modes are described below: Note: due to legacy usage, some 10GBASE-R usage incorrectly makes use of this definition. +``PHY_INTERFACE_MODE_25GBASER`` + This is the IEEE 802.3 PCS Clause 107 defined 25GBASE-R protocol. + The PCS is identical to 10GBASE-R, i.e. 64B/66B encoded + running 2.5 as fast, giving a fixed bit rate of 25.78125 Gbaud. + Please refer to the IEEE standard for further information. + ``PHY_INTERFACE_MODE_100BASEX`` This defines IEEE 802.3 Clause 24. The link operates at a fixed data rate of 125Mpbs using a 4B/5B encoding scheme, resulting in an underlying diff --git a/Documentation/networking/tuntap.rst b/Documentation/networking/tuntap.rst index a59d1dd6fdcc..4d7087f727be 100644 --- a/Documentation/networking/tuntap.rst +++ b/Documentation/networking/tuntap.rst @@ -107,7 +107,7 @@ Note that the character pointer becomes overwritten with the real device name */ ifr.ifr_flags = IFF_TUN; if( *dev ) - strncpy(ifr.ifr_name, dev, IFNAMSIZ); + strscpy_pad(ifr.ifr_name, dev, IFNAMSIZ); if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ){ close(fd); diff --git a/Documentation/power/runtime_pm.rst b/Documentation/power/runtime_pm.rst index 18ae21bf7f92..d6bf84f061f4 100644 --- a/Documentation/power/runtime_pm.rst +++ b/Documentation/power/runtime_pm.rst @@ -378,7 +378,11 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: `int pm_runtime_get_sync(struct device *dev);` - increment the device's usage counter, run pm_runtime_resume(dev) and - return its result + return its result; + note that it does not drop the device's usage counter on errors, so + consider using pm_runtime_resume_and_get() instead of it, especially + if its return value is checked by the caller, as this is likely to + result in cleaner code. `int pm_runtime_get_if_in_use(struct device *dev);` - return -EINVAL if 'power.disable_depth' is nonzero; otherwise, if the @@ -827,6 +831,15 @@ or driver about runtime power changes. Instead, the driver for the device's parent must take responsibility for telling the device's driver when the parent's power state changes. +Note that, in some cases it may not be desirable for subsystems/drivers to call +pm_runtime_no_callbacks() for their devices. This could be because a subset of +the runtime PM callbacks needs to be implemented, a platform dependent PM +domain could get attached to the device or that the device is power managed +through a supplier device link. For these reasons and to avoid boilerplate code +in subsystems/drivers, the PM core allows runtime PM callbacks to be +unassigned. More precisely, if a callback pointer is NULL, the PM core will act +as though there was a callback and it returned 0. + 9. Autosuspend, or automatically-delayed suspends ================================================= diff --git a/Documentation/powerpc/syscall64-abi.rst b/Documentation/powerpc/syscall64-abi.rst index dabee3729e5a..56490c4c0c07 100644 --- a/Documentation/powerpc/syscall64-abi.rst +++ b/Documentation/powerpc/syscall64-abi.rst @@ -109,6 +109,16 @@ auxiliary vector. scv 0 syscalls will always behave as PPC_FEATURE2_HTM_NOSC. +ptrace +------ +When ptracing system calls (PTRACE_SYSCALL), the pt_regs.trap value contains +the system call type that can be used to distinguish between sc and scv 0 +system calls, and the different register conventions can be accounted for. + +If the value of (pt_regs.trap & 0xfff0) is 0xc00 then the system call was +performed with the sc instruction, if it is 0x3000 then the system call was +performed with the scv 0 instruction. + vsyscall ======== diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index e5a1be476047..dc2d813b2e79 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -1,4 +1,4 @@ -.. _process_statement_kernel: +.. _process_statement_kernel: Linux Kernel Enforcement Statement ---------------------------------- diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index c66a19201deb..0852bcf73630 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -10,10 +10,11 @@ can greatly increase the chances of your change being accepted. This document contains a large number of suggestions in a relatively terse format. For detailed information on how the kernel development process -works, see :doc:`development-process`. Also, read :doc:`submit-checklist` +works, see Documentation/process/development-process.rst. Also, read +Documentation/process/submit-checklist.rst for a list of items to check before submitting code. If you are submitting -a driver, also read :doc:`submitting-drivers`; for device tree binding patches, -read :doc:`submitting-patches`. +a driver, also read Documentation/process/submitting-drivers.rst; for device +tree binding patches, read Documentation/process/submitting-patches.rst. This documentation assumes that you're using ``git`` to prepare your patches. If you're unfamiliar with ``git``, you would be well-advised to learn how to @@ -178,8 +179,7 @@ Style-check your changes ------------------------ Check your patch for basic style violations, details of which can be -found in -:ref:`Documentation/process/coding-style.rst <codingstyle>`. +found in Documentation/process/coding-style.rst. Failure to do so simply wastes the reviewers time and will get your patch rejected, probably without even being read. @@ -238,7 +238,7 @@ If you have a patch that fixes an exploitable security bug, send that patch to security@kernel.org. For severe bugs, a short embargo may be considered to allow distributors to get the patch out to users; in such cases, obviously, the patch should not be sent to any public lists. See also -:doc:`/admin-guide/security-bugs`. +Documentation/admin-guide/security-bugs.rst. Patches that fix a severe bug in a released kernel should be directed toward the stable maintainers by putting a line like this:: @@ -246,9 +246,8 @@ toward the stable maintainers by putting a line like this:: Cc: stable@vger.kernel.org into the sign-off area of your patch (note, NOT an email recipient). You -should also read -:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` -in addition to this file. +should also read Documentation/process/stable-kernel-rules.rst +in addition to this document. If changes affect userland-kernel interfaces, please send the MAN-PAGES maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at @@ -305,8 +304,8 @@ decreasing the likelihood of your MIME-attached change being accepted. Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME. -See :doc:`/process/email-clients` for hints about configuring your e-mail -client so that it sends your patches untouched. +See Documentation/process/email-clients.rst for hints about configuring +your e-mail client so that it sends your patches untouched. Respond to review comments -------------------------- @@ -324,7 +323,7 @@ for their time. Code review is a tiring and time-consuming process, and reviewers sometimes get grumpy. Even in that case, though, respond politely and address the problems they have pointed out. -See :doc:`email-clients` for recommendations on email +See Documentation/process/email-clients.rst for recommendations on email clients and mailing list etiquette. @@ -562,10 +561,10 @@ method for indicating a bug fixed by the patch. See :ref:`describe_changes` for more details. Note: Attaching a Fixes: tag does not subvert the stable kernel rules -process nor the requirement to Cc: stable@vger.kernel.org on all stable +process nor the requirement to Cc: stable@vger.kernel.org on all stable patch candidates. For more information, please read -:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` - +Documentation/process/stable-kernel-rules.rst. + .. _the_canonical_patch_format: The canonical patch format @@ -824,8 +823,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! <https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net> -Kernel Documentation/process/coding-style.rst: - :ref:`Documentation/process/coding-style.rst <codingstyle>` +Kernel Documentation/process/coding-style.rst Linus Torvalds's mail on the canonical patch format: <https://lore.kernel.org/r/Pine.LNX.4.58.0504071023190.28951@ppc970.osdl.org> diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst index 329d32098af4..b7f98930d38d 100644 --- a/Documentation/riscv/vm-layout.rst +++ b/Documentation/riscv/vm-layout.rst @@ -58,6 +58,6 @@ RISC-V Linux Kernel SV39 | ____________________________________________________________|____________________________________________________________ | | | | - ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules - ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel, BPF + ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF + ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel __________________|____________|__________________|_________|____________________________________________________________ diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst index e15436599086..f57ae621f33e 100644 --- a/Documentation/s390/vfio-ap.rst +++ b/Documentation/s390/vfio-ap.rst @@ -514,7 +514,6 @@ These are the steps: * S390_AP_IOMMU * VFIO * VFIO_MDEV - * VFIO_MDEV_DEVICE * KVM If using make menuconfig select the following to build the vfio_ap module:: diff --git a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst index 845eee659199..1fc73555f5c4 100644 --- a/Documentation/scheduler/sched-bwc.rst +++ b/Documentation/scheduler/sched-bwc.rst @@ -29,7 +29,7 @@ Quota and period are managed within the cpu subsystem via cgroupfs. .. note:: The cgroupfs files described in this section are only applicable to cgroup v1. For cgroup v2, see - :ref:`Documentation/admin-guide/cgroupv2.rst <cgroup-v2-cpu>`. + :ref:`Documentation/admin-guide/cgroup-v2.rst <cgroup-v2-cpu>`. - cpu.cfs_quota_us: the total available run-time within a period (in microseconds) diff --git a/Documentation/scheduler/sched-capacity.rst b/Documentation/scheduler/sched-capacity.rst index 9b7cbe43b2d1..805f85f330b5 100644 --- a/Documentation/scheduler/sched-capacity.rst +++ b/Documentation/scheduler/sched-capacity.rst @@ -284,8 +284,10 @@ whether the system exhibits asymmetric CPU capacities. Should that be the case: - The sched_asym_cpucapacity static key will be enabled. -- The SD_ASYM_CPUCAPACITY flag will be set at the lowest sched_domain level that - spans all unique CPU capacity values. +- The SD_ASYM_CPUCAPACITY_FULL flag will be set at the lowest sched_domain + level that spans all unique CPU capacity values. +- The SD_ASYM_CPUCAPACITY flag will be set for any sched_domain that spans + CPUs with any range of asymmetry. The sched_asym_cpucapacity static key is intended to guard sections of code that cater to asymmetric CPU capacity systems. Do note however that said key is diff --git a/Documentation/scheduler/sched-energy.rst b/Documentation/scheduler/sched-energy.rst index afe02d394402..8fbce5e767d9 100644 --- a/Documentation/scheduler/sched-energy.rst +++ b/Documentation/scheduler/sched-energy.rst @@ -328,7 +328,7 @@ section lists these dependencies and provides hints as to how they can be met. As mentioned in the introduction, EAS is only supported on platforms with asymmetric CPU topologies for now. This requirement is checked at run-time by -looking for the presence of the SD_ASYM_CPUCAPACITY flag when the scheduling +looking for the presence of the SD_ASYM_CPUCAPACITY_FULL flag when the scheduling domains are built. See Documentation/scheduler/sched-capacity.rst for requirements to be met for this diff --git a/Documentation/scheduler/sched-nice-design.rst b/Documentation/scheduler/sched-nice-design.rst index 0571f1b47e64..889bf2b737dc 100644 --- a/Documentation/scheduler/sched-nice-design.rst +++ b/Documentation/scheduler/sched-nice-design.rst @@ -60,7 +60,7 @@ within the constraints of HZ and jiffies and their nasty design level coupling to timeslices and granularity it was not really viable. The second (less frequent but still periodically occurring) complaint -about Linux's nice level support was its assymetry around the origo +about Linux's nice level support was its asymmetry around the origin (which you can see demonstrated in the picture above), or more accurately: the fact that nice level behavior depended on the _absolute_ nice level as well, while the nice API itself is fundamentally diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst index 096ffe9cae0e..63ddea2b9640 100644 --- a/Documentation/scsi/scsi_mid_low_api.rst +++ b/Documentation/scsi/scsi_mid_low_api.rst @@ -1172,10 +1172,9 @@ Members of interest: of 0 implies a successfully completed command (and all data (if any) has been transferred to or from the SCSI target device). 'result' is a 32 bit unsigned integer that - can be viewed as 4 related bytes. The SCSI status value is - in the LSB. See include/scsi/scsi.h status_byte(), - msg_byte(), host_byte() and driver_byte() macros and - related constants. + can be viewed as 2 related bytes. The SCSI status value is + in the LSB. See include/scsi/scsi.h status_byte() and + host_byte() macros and related constants. sense_buffer - an array (maximum size: SCSI_SENSE_BUFFERSIZE bytes) that should be written when the SCSI status (LSB of 'result') diff --git a/Documentation/security/IMA-templates.rst b/Documentation/security/IMA-templates.rst index c5a8432972ef..1a91d92950a7 100644 --- a/Documentation/security/IMA-templates.rst +++ b/Documentation/security/IMA-templates.rst @@ -70,9 +70,18 @@ descriptors by adding their identifier to the format string prefix is shown only if the hash algorithm is not SHA1 or MD5); - 'd-modsig': the digest of the event without the appended modsig; - 'n-ng': the name of the event, without size limitations; - - 'sig': the file signature; + - 'sig': the file signature, or the EVM portable signature if the file + signature is not found; - 'modsig' the appended file signature; - 'buf': the buffer data that was used to generate the hash without size limitations; + - 'evmsig': the EVM portable signature; + - 'iuid': the inode UID; + - 'igid': the inode GID; + - 'imode': the inode mode; + - 'xattrnames': a list of xattr names (separated by ``|``), only if the xattr is + present; + - 'xattrlengths': a list of xattr lengths (u32), only if the xattr is present; + - 'xattrvalues': a list of xattr values; Below, there is the list of defined template descriptors: @@ -82,6 +91,7 @@ Below, there is the list of defined template descriptors: - "ima-sig": its format is ``d-ng|n-ng|sig``; - "ima-buf": its format is ``d-ng|n-ng|buf``; - "ima-modsig": its format is ``d-ng|n-ng|sig|d-modsig|modsig``; + - "evm-sig": its format is ``d-ng|n-ng|evmsig|xattrnames|xattrlengths|xattrvalues|iuid|igid|imode``; Use diff --git a/Documentation/security/landlock.rst b/Documentation/security/landlock.rst index 2e84925ae971..3df68cb1d10f 100644 --- a/Documentation/security/landlock.rst +++ b/Documentation/security/landlock.rst @@ -25,7 +25,8 @@ Any user can enforce Landlock rulesets on their processes. They are merged and evaluated according to the inherited ones in a way that ensures that only more constraints can be added. -User space documentation can be found here: :doc:`/userspace-api/landlock`. +User space documentation can be found here: +Documentation/userspace-api/landlock.rst. Guiding principles for safe access controls =========================================== diff --git a/Documentation/security/tpm/xen-tpmfront.rst b/Documentation/security/tpm/xen-tpmfront.rst index 00d5b1db227d..31c67522f2ad 100644 --- a/Documentation/security/tpm/xen-tpmfront.rst +++ b/Documentation/security/tpm/xen-tpmfront.rst @@ -1,4 +1,4 @@ -============================= +============================= Virtual TPM interface for Xen ============================= diff --git a/Documentation/sound/hd-audio/controls.rst b/Documentation/sound/hd-audio/controls.rst index f2ebc4f79b44..dbe6483f4ff4 100644 --- a/Documentation/sound/hd-audio/controls.rst +++ b/Documentation/sound/hd-audio/controls.rst @@ -102,7 +102,7 @@ Conexant codecs --------------- Auto-Mute Mode - See Reatek codecs. + See Realtek codecs. Analog codecs diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index e6365836fa8b..01d59b8aea92 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -3508,14 +3508,15 @@ field must be set, though). “IEC958 Playback Con Mask” is used to return the bit-mask for the IEC958 status bits of consumer mode. Similarly, “IEC958 Playback Pro Mask” -returns the bitmask for professional mode. They are read-only controls, -and are defined as MIXER controls (iface = -``SNDRV_CTL_ELEM_IFACE_MIXER``). +returns the bitmask for professional mode. They are read-only controls. Meanwhile, “IEC958 Playback Default” control is defined for getting and -setting the current default IEC958 bits. Note that this one is usually -defined as a PCM control (iface = ``SNDRV_CTL_ELEM_IFACE_PCM``), -although in some places it's defined as a MIXER control. +setting the current default IEC958 bits. + +Due to historical reasons, both variants of the Playback Mask and the +Playback Default controls can be implemented on either a +``SNDRV_CTL_ELEM_IFACE_PCM`` or a ``SNDRV_CTL_ELEM_IFACE_MIXER`` iface. +Drivers should expose the mask and default on the same iface though. In addition, you can define the control switches to enable/disable or to set the raw bit mode. The implementation will depend on the chip, but diff --git a/Documentation/spi/pxa2xx.rst b/Documentation/spi/pxa2xx.rst index 882d3cc72cc2..6312968acfe9 100644 --- a/Documentation/spi/pxa2xx.rst +++ b/Documentation/spi/pxa2xx.rst @@ -2,43 +2,47 @@ PXA2xx SPI on SSP driver HOWTO ============================== -This a mini howto on the pxa2xx_spi driver. The driver turns a PXA2xx -synchronous serial port into a SPI master controller +This a mini HOWTO on the pxa2xx_spi driver. The driver turns a PXA2xx +synchronous serial port into an SPI master controller (see Documentation/spi/spi-summary.rst). The driver has the following features -- Support for any PXA2xx SSP +- Support for any PXA2xx and compatible SSP. - SSP PIO and SSP DMA data transfers. - External and Internal (SSPFRM) chip selects. - Per slave device (chip) configuration. - Full suspend, freeze, resume support. -The driver is built around a "spi_message" fifo serviced by workqueue and a -tasklet. The workqueue, "pump_messages", drives message fifo and the tasklet -(pump_transfer) is responsible for queuing SPI transactions and setting up and -launching the dma/interrupt driven transfers. +The driver is built around a &struct spi_message FIFO serviced by kernel +thread. The kernel thread, spi_pump_messages(), drives message FIFO and +is responsible for queuing SPI transactions and setting up and launching +the DMA or interrupt driven transfers. Declaring PXA2xx Master Controllers ----------------------------------- -Typically a SPI master is defined in the arch/.../mach-*/board-*.c as a -"platform device". The master configuration is passed to the driver via a table -found in include/linux/spi/pxa2xx_spi.h:: +Typically, for a legacy platform, an SPI master is defined in the +arch/.../mach-*/board-*.c as a "platform device". The master configuration +is passed to the driver via a table found in include/linux/spi/pxa2xx_spi.h:: struct pxa2xx_spi_controller { u16 num_chipselect; u8 enable_dma; + ... }; The "pxa2xx_spi_controller.num_chipselect" field is used to determine the number of slave device (chips) attached to this SPI master. The "pxa2xx_spi_controller.enable_dma" field informs the driver that SSP DMA should -be used. This caused the driver to acquire two DMA channels: rx_channel and -tx_channel. The rx_channel has a higher DMA service priority the tx_channel. +be used. This caused the driver to acquire two DMA channels: Rx channel and +Tx channel. The Rx channel has a higher DMA service priority than the Tx channel. See the "PXA2xx Developer Manual" section "DMA Controller". +For the new platforms the description of the controller and peripheral devices +comes from Device Tree or ACPI. + NSSP MASTER SAMPLE ------------------ -Below is a sample configuration using the PXA255 NSSP:: +Below is a sample configuration using the PXA255 NSSP for a legacy platform:: static struct resource pxa_spi_nssp_resources[] = { [0] = { @@ -79,9 +83,10 @@ Below is a sample configuration using the PXA255 NSSP:: Declaring Slave Devices ----------------------- -Typically each SPI slave (chip) is defined in the arch/.../mach-*/board-*.c -using the "spi_board_info" structure found in "linux/spi/spi.h". See -"Documentation/spi/spi-summary.rst" for additional information. +Typically, for a legacy platform, each SPI slave (chip) is defined in the +arch/.../mach-*/board-*.c using the "spi_board_info" structure found in +"linux/spi/spi.h". See "Documentation/spi/spi-summary.rst" for additional +information. Each slave device attached to the PXA must provide slave specific configuration information via the structure "pxa2xx_spi_chip" found in @@ -101,9 +106,9 @@ device. All fields are optional. }; The "pxa2xx_spi_chip.tx_threshold" and "pxa2xx_spi_chip.rx_threshold" fields are -used to configure the SSP hardware fifo. These fields are critical to the +used to configure the SSP hardware FIFO. These fields are critical to the performance of pxa2xx_spi driver and misconfiguration will result in rx -fifo overruns (especially in PIO mode transfers). Good default values are:: +FIFO overruns (especially in PIO mode transfers). Good default values are:: .tx_threshold = 8, .rx_threshold = 8, @@ -118,7 +123,7 @@ use a value of 8. The driver will determine a reasonable default if dma_burst_size == 0. The "pxa2xx_spi_chip.timeout" fields is used to efficiently handle -trailing bytes in the SSP receiver fifo. The correct value for this field is +trailing bytes in the SSP receiver FIFO. The correct value for this field is dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific slave device. Please note that the PXA2xx SSP 1 does not support trailing byte timeouts and must busy-wait any trailing bytes. @@ -131,19 +136,19 @@ testing. The "pxa2xx_spi_chip.cs_control" field is used to point to a board specific function for asserting/deasserting a slave device chip select. If the field is NULL, the pxa2xx_spi master controller driver assumes that the SSP port is -configured to use SSPFRM instead. +configured to use GPIO or SSPFRM instead. NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the chipselect is dropped after each spi_transfer. Most devices need chip select -asserted around the complete message. Use SSPFRM as a GPIO (through cs_control) +asserted around the complete message. Use SSPFRM as a GPIO (through a descriptor) to accommodate these chips. NSSP SLAVE SAMPLE ----------------- -The pxa2xx_spi_chip structure is passed to the pxa2xx_spi driver in the -"spi_board_info.controller_data" field. Below is a sample configuration using -the PXA255 NSSP. +For a legacy platform or in some other cases, the pxa2xx_spi_chip structure +is passed to the pxa2xx_spi driver in the "spi_board_info.controller_data" +field. Below is a sample configuration using the PXA255 NSSP. :: @@ -212,7 +217,9 @@ DMA and PIO I/O Support ----------------------- The pxa2xx_spi driver supports both DMA and interrupt driven PIO message transfers. The driver defaults to PIO mode and DMA transfers must be enabled -by setting the "enable_dma" flag in the "pxa2xx_spi_controller" structure. The DMA +by setting the "enable_dma" flag in the "pxa2xx_spi_controller" structure. +For the newer platforms, that are known to support DMA, the driver will enable +it automatically and try it first with a possible fallback to PIO. The DMA mode supports both coherent and stream based DMA mappings. The following logic is used to determine the type of I/O to be used on @@ -236,5 +243,4 @@ a per "spi_transfer" basis:: THANKS TO --------- - David Brownell and others for mentoring the development of this driver. diff --git a/Documentation/timers/no_hz.rst b/Documentation/timers/no_hz.rst index c4c70e1aada3..6cadad7c3aad 100644 --- a/Documentation/timers/no_hz.rst +++ b/Documentation/timers/no_hz.rst @@ -1,4 +1,4 @@ -====================================== +====================================== NO_HZ: Reducing Scheduling-Clock Ticks ====================================== diff --git a/Documentation/trace/boottime-trace.rst b/Documentation/trace/boottime-trace.rst index 89b64334929b..8053898cfeb4 100644 --- a/Documentation/trace/boottime-trace.rst +++ b/Documentation/trace/boottime-trace.rst @@ -99,6 +99,12 @@ These options are setting per-event options. ftrace.[instance.INSTANCE.]event.GROUP.EVENT.enable Enable GROUP:EVENT tracing. +ftrace.[instance.INSTANCE.]event.GROUP.enable + Enable all event tracing within GROUP. + +ftrace.[instance.INSTANCE.]event.enable + Enable all event tracing. + ftrace.[instance.INSTANCE.]event.GROUP.EVENT.filter = FILTER Set FILTER rule to the GROUP:EVENT. diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst index b64d9a9c79df..d25dfe86af9b 100644 --- a/Documentation/trace/coresight/coresight-etm4x-reference.rst +++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst @@ -427,7 +427,7 @@ the ‘TRC’ prefix. :Syntax: ``echo idx > vmid_idx`` - Where idx < numvmidc + Where idx < numvmidc ---- diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst index 169749efd8d1..1ec8dc35b1d8 100644 --- a/Documentation/trace/coresight/coresight.rst +++ b/Documentation/trace/coresight/coresight.rst @@ -315,7 +315,8 @@ intermediate links as required. Note: ``cti_sys0`` appears in two of the connections lists above. CTIs can connect to multiple devices and are arranged in a star topology -via the CTM. See (:doc:`coresight-ect`) [#fourth]_ for further details. +via the CTM. See (Documentation/trace/coresight/coresight-ect.rst) +[#fourth]_ for further details. Looking at this device we see 4 connections:: linaro-developer:~# ls -l /sys/bus/coresight/devices/cti_sys0/connections @@ -606,7 +607,8 @@ interface provided for that purpose by the generic STM API:: crw------- 1 root root 10, 61 Jan 3 18:11 /dev/stm0 root@genericarmv8:~# -Details on how to use the generic STM API can be found here:- :doc:`../stm` [#second]_. +Details on how to use the generic STM API can be found here: +- Documentation/trace/stm.rst [#second]_. The CTI & CTM Modules --------------------- @@ -616,7 +618,7 @@ individual CTIs and components, and can propagate these between all CTIs via channels on the CTM (Cross Trigger Matrix). A separate documentation file is provided to explain the use of these devices. -(:doc:`coresight-ect`) [#fourth]_. +(Documentation/trace/coresight/coresight-ect.rst) [#fourth]_. .. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index 62c98e9bbdd9..cfc81e98e0b8 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -40,7 +40,7 @@ See events.rst for more information. Implementation Details ---------------------- -See :doc:`ftrace-design` for details for arch porters and such. +See Documentation/trace/ftrace-design.rst for details for arch porters and such. The File System @@ -354,8 +354,8 @@ of ftrace. Here is a list of some of the key files: is being directly called by the function. If the count is greater than 1 it most likely will be ftrace_ops_list_func(). - If the callback of the function jumps to a trampoline that is - specific to a the callback and not the standard trampoline, + If the callback of a function jumps to a trampoline that is + specific to the callback and which is not the standard trampoline, its address will be printed as well as the function that the trampoline calls. diff --git a/Documentation/trace/hwlat_detector.rst b/Documentation/trace/hwlat_detector.rst index 5739349649c8..de94b499b0bc 100644 --- a/Documentation/trace/hwlat_detector.rst +++ b/Documentation/trace/hwlat_detector.rst @@ -76,8 +76,13 @@ in /sys/kernel/tracing: - tracing_cpumask - the CPUs to move the hwlat thread across - hwlat_detector/width - specified amount of time to spin within window (usecs) - hwlat_detector/window - amount of time between (width) runs (usecs) + - hwlat_detector/mode - the thread mode -The hwlat detector's kernel thread will migrate across each CPU specified in -tracing_cpumask between each window. To limit the migration, either modify -tracing_cpumask, or modify the hwlat kernel thread (named [hwlatd]) CPU -affinity directly, and the migration will stop. +By default, one hwlat detector's kernel thread will migrate across each CPU +specified in cpumask at the beginning of a new window, in a round-robin +fashion. This behavior can be changed by changing the thread mode, +the available options are: + + - none: do not force migration + - round-robin: migrate across each CPU specified in cpumask [default] + - per-cpu: create one thread for each cpu in tracing_cpumask diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst index f634b36fd3aa..3769b9b7aed8 100644 --- a/Documentation/trace/index.rst +++ b/Documentation/trace/index.rst @@ -23,6 +23,8 @@ Linux Tracing Technologies histogram-design boottime-trace hwlat_detector + osnoise-tracer + timerlat-tracer intel_th ring-buffer-design stm diff --git a/Documentation/trace/kprobes.rst b/Documentation/trace/kprobes.rst index b757b6dfd3d4..998149ce2fd9 100644 --- a/Documentation/trace/kprobes.rst +++ b/Documentation/trace/kprobes.rst @@ -362,14 +362,11 @@ register_kprobe #include <linux/kprobes.h> int register_kprobe(struct kprobe *kp); -Sets a breakpoint at the address kp->addr. When the breakpoint is -hit, Kprobes calls kp->pre_handler. After the probed instruction -is single-stepped, Kprobe calls kp->post_handler. If a fault -occurs during execution of kp->pre_handler or kp->post_handler, -or during single-stepping of the probed instruction, Kprobes calls -kp->fault_handler. Any or all handlers can be NULL. If kp->flags -is set KPROBE_FLAG_DISABLED, that kp will be registered but disabled, -so, its handlers aren't hit until calling enable_kprobe(kp). +Sets a breakpoint at the address kp->addr. When the breakpoint is hit, Kprobes +calls kp->pre_handler. After the probed instruction is single-stepped, Kprobe +calls kp->post_handler. Any or all handlers can be NULL. If kp->flags is set +KPROBE_FLAG_DISABLED, that kp will be registered but disabled, so, its handlers +aren't hit until calling enable_kprobe(kp). .. note:: @@ -415,17 +412,6 @@ User's post-handler (kp->post_handler):: p and regs are as described for the pre_handler. flags always seems to be zero. -User's fault-handler (kp->fault_handler):: - - #include <linux/kprobes.h> - #include <linux/ptrace.h> - int fault_handler(struct kprobe *p, struct pt_regs *regs, int trapnr); - -p and regs are as described for the pre_handler. trapnr is the -architecture-specific trap number associated with the fault (e.g., -on i386, 13 for a general protection fault or 14 for a page fault). -Returns 1 if it successfully handled the exception. - register_kretprobe ------------------ diff --git a/Documentation/trace/osnoise-tracer.rst b/Documentation/trace/osnoise-tracer.rst new file mode 100644 index 000000000000..b648cb9bf1f0 --- /dev/null +++ b/Documentation/trace/osnoise-tracer.rst @@ -0,0 +1,152 @@ +============== +OSNOISE Tracer +============== + +In the context of high-performance computing (HPC), the Operating System +Noise (*osnoise*) refers to the interference experienced by an application +due to activities inside the operating system. In the context of Linux, +NMIs, IRQs, SoftIRQs, and any other system thread can cause noise to the +system. Moreover, hardware-related jobs can also cause noise, for example, +via SMIs. + +hwlat_detector is one of the tools used to identify the most complex +source of noise: *hardware noise*. + +In a nutshell, the hwlat_detector creates a thread that runs +periodically for a given period. At the beginning of a period, the thread +disables interrupt and starts sampling. While running, the hwlatd +thread reads the time in a loop. As interrupts are disabled, threads, +IRQs, and SoftIRQs cannot interfere with the hwlatd thread. Hence, the +cause of any gap between two different reads of the time roots either on +NMI or in the hardware itself. At the end of the period, hwlatd enables +interrupts and reports the max observed gap between the reads. It also +prints a NMI occurrence counter. If the output does not report NMI +executions, the user can conclude that the hardware is the culprit for +the latency. The hwlat detects the NMI execution by observing +the entry and exit of a NMI. + +The osnoise tracer leverages the hwlat_detector by running a +similar loop with preemption, SoftIRQs and IRQs enabled, thus allowing +all the sources of *osnoise* during its execution. Using the same approach +of hwlat, osnoise takes note of the entry and exit point of any +source of interferences, increasing a per-cpu interference counter. The +osnoise tracer also saves an interference counter for each source of +interference. The interference counter for NMI, IRQs, SoftIRQs, and +threads is increased anytime the tool observes these interferences' entry +events. When a noise happens without any interference from the operating +system level, the hardware noise counter increases, pointing to a +hardware-related noise. In this way, osnoise can account for any +source of interference. At the end of the period, the osnoise tracer +prints the sum of all noise, the max single noise, the percentage of CPU +available for the thread, and the counters for the noise sources. + +Usage +----- + +Write the ASCII text "osnoise" into the current_tracer file of the +tracing system (generally mounted at /sys/kernel/tracing). + +For example:: + + [root@f32 ~]# cd /sys/kernel/tracing/ + [root@f32 tracing]# echo osnoise > current_tracer + +It is possible to follow the trace by reading the trace trace file:: + + [root@f32 tracing]# cat trace + # tracer: osnoise + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth MAX + # || / SINGLE Interference counters: + # |||| RUNTIME NOISE % OF CPU NOISE +-----------------------------+ + # TASK-PID CPU# |||| TIMESTAMP IN US IN US AVAILABLE IN US HW NMI IRQ SIRQ THREAD + # | | | |||| | | | | | | | | | | + <...>-859 [000] .... 81.637220: 1000000 190 99.98100 9 18 0 1007 18 1 + <...>-860 [001] .... 81.638154: 1000000 656 99.93440 74 23 0 1006 16 3 + <...>-861 [002] .... 81.638193: 1000000 5675 99.43250 202 6 0 1013 25 21 + <...>-862 [003] .... 81.638242: 1000000 125 99.98750 45 1 0 1011 23 0 + <...>-863 [004] .... 81.638260: 1000000 1721 99.82790 168 7 0 1002 49 41 + <...>-864 [005] .... 81.638286: 1000000 263 99.97370 57 6 0 1006 26 2 + <...>-865 [006] .... 81.638302: 1000000 109 99.98910 21 3 0 1006 18 1 + <...>-866 [007] .... 81.638326: 1000000 7816 99.21840 107 8 0 1016 39 19 + +In addition to the regular trace fields (from TASK-PID to TIMESTAMP), the +tracer prints a message at the end of each period for each CPU that is +running an osnoise/ thread. The osnoise specific fields report: + + - The RUNTIME IN US reports the amount of time in microseconds that + the osnoise thread kept looping reading the time. + - The NOISE IN US reports the sum of noise in microseconds observed + by the osnoise tracer during the associated runtime. + - The % OF CPU AVAILABLE reports the percentage of CPU available for + the osnoise thread during the runtime window. + - The MAX SINGLE NOISE IN US reports the maximum single noise observed + during the runtime window. + - The Interference counters display how many each of the respective + interference happened during the runtime window. + +Note that the example above shows a high number of HW noise samples. +The reason being is that this sample was taken on a virtual machine, +and the host interference is detected as a hardware interference. + +Tracer options +--------------------- + +The tracer has a set of options inside the osnoise directory, they are: + + - osnoise/cpus: CPUs at which a osnoise thread will execute. + - osnoise/period_us: the period of the osnoise thread. + - osnoise/runtime_us: how long an osnoise thread will look for noise. + - osnoise/stop_tracing_us: stop the system tracing if a single noise + higher than the configured value happens. Writing 0 disables this + option. + - osnoise/stop_tracing_total_us: stop the system tracing if total noise + higher than the configured value happens. Writing 0 disables this + option. + - tracing_threshold: the minimum delta between two time() reads to be + considered as noise, in us. When set to 0, the default value will + will be used, which is currently 5 us. + +Additional Tracing +------------------ + +In addition to the tracer, a set of tracepoints were added to +facilitate the identification of the osnoise source. + + - osnoise:sample_threshold: printed anytime a noise is higher than + the configurable tolerance_ns. + - osnoise:nmi_noise: noise from NMI, including the duration. + - osnoise:irq_noise: noise from an IRQ, including the duration. + - osnoise:softirq_noise: noise from a SoftIRQ, including the + duration. + - osnoise:thread_noise: noise from a thread, including the duration. + +Note that all the values are *net values*. For example, if while osnoise +is running, another thread preempts the osnoise thread, it will start a +thread_noise duration at the start. Then, an IRQ takes place, preempting +the thread_noise, starting a irq_noise. When the IRQ ends its execution, +it will compute its duration, and this duration will be subtracted from +the thread_noise, in such a way as to avoid the double accounting of the +IRQ execution. This logic is valid for all sources of noise. + +Here is one example of the usage of these tracepoints:: + + osnoise/8-961 [008] d.h. 5789.857532: irq_noise: local_timer:236 start 5789.857529929 duration 1845 ns + osnoise/8-961 [008] dNh. 5789.858408: irq_noise: local_timer:236 start 5789.858404871 duration 2848 ns + migration/8-54 [008] d... 5789.858413: thread_noise: migration/8:54 start 5789.858409300 duration 3068 ns + osnoise/8-961 [008] .... 5789.858413: sample_threshold: start 5789.858404555 duration 8812 ns interferences 2 + +In this example, a noise sample of 8 microseconds was reported in the last +line, pointing to two interferences. Looking backward in the trace, the +two previous entries were about the migration thread running after a +timer IRQ execution. The first event is not part of the noise because +it took place one millisecond before. + +It is worth noticing that the sum of the duration reported in the +tracepoints is smaller than eight us reported in the sample_threshold. +The reason roots in the overhead of the entry and exit code that happens +before and after any interference execution. This justifies the dual +approach: measuring thread and tracing. diff --git a/Documentation/trace/timerlat-tracer.rst b/Documentation/trace/timerlat-tracer.rst new file mode 100644 index 000000000000..c7cbb557aee7 --- /dev/null +++ b/Documentation/trace/timerlat-tracer.rst @@ -0,0 +1,181 @@ +############### +Timerlat tracer +############### + +The timerlat tracer aims to help the preemptive kernel developers to +find souces of wakeup latencies of real-time threads. Like cyclictest, +the tracer sets a periodic timer that wakes up a thread. The thread then +computes a *wakeup latency* value as the difference between the *current +time* and the *absolute time* that the timer was set to expire. The main +goal of timerlat is tracing in such a way to help kernel developers. + +Usage +----- + +Write the ASCII text "timerlat" into the current_tracer file of the +tracing system (generally mounted at /sys/kernel/tracing). + +For example:: + + [root@f32 ~]# cd /sys/kernel/tracing/ + [root@f32 tracing]# echo timerlat > current_tracer + +It is possible to follow the trace by reading the trace trace file:: + + [root@f32 tracing]# cat trace + # tracer: timerlat + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # || / + # |||| ACTIVATION + # TASK-PID CPU# |||| TIMESTAMP ID CONTEXT LATENCY + # | | | |||| | | | | + <idle>-0 [000] d.h1 54.029328: #1 context irq timer_latency 932 ns + <...>-867 [000] .... 54.029339: #1 context thread timer_latency 11700 ns + <idle>-0 [001] dNh1 54.029346: #1 context irq timer_latency 2833 ns + <...>-868 [001] .... 54.029353: #1 context thread timer_latency 9820 ns + <idle>-0 [000] d.h1 54.030328: #2 context irq timer_latency 769 ns + <...>-867 [000] .... 54.030330: #2 context thread timer_latency 3070 ns + <idle>-0 [001] d.h1 54.030344: #2 context irq timer_latency 935 ns + <...>-868 [001] .... 54.030347: #2 context thread timer_latency 4351 ns + + +The tracer creates a per-cpu kernel thread with real-time priority that +prints two lines at every activation. The first is the *timer latency* +observed at the *hardirq* context before the activation of the thread. +The second is the *timer latency* observed by the thread. The ACTIVATION +ID field serves to relate the *irq* execution to its respective *thread* +execution. + +The *irq*/*thread* splitting is important to clarify at which context +the unexpected high value is coming from. The *irq* context can be +delayed by hardware related actions, such as SMIs, NMIs, IRQs +or by a thread masking interrupts. Once the timer happens, the delay +can also be influenced by blocking caused by threads. For example, by +postponing the scheduler execution via preempt_disable(), by the +scheduler execution, or by masking interrupts. Threads can +also be delayed by the interference from other threads and IRQs. + +Tracer options +--------------------- + +The timerlat tracer is built on top of osnoise tracer. +So its configuration is also done in the osnoise/ config +directory. The timerlat configs are: + + - cpus: CPUs at which a timerlat thread will execute. + - timerlat_period_us: the period of the timerlat thread. + - osnoise/stop_tracing_us: stop the system tracing if a + timer latency at the *irq* context higher than the configured + value happens. Writing 0 disables this option. + - stop_tracing_total_us: stop the system tracing if a + timer latency at the *thread* context higher than the configured + value happens. Writing 0 disables this option. + - print_stack: save the stack of the IRQ ocurrence, and print + it afte the *thread context* event". + +timerlat and osnoise +---------------------------- + +The timerlat can also take advantage of the osnoise: traceevents. +For example:: + + [root@f32 ~]# cd /sys/kernel/tracing/ + [root@f32 tracing]# echo timerlat > current_tracer + [root@f32 tracing]# echo 1 > events/osnoise/enable + [root@f32 tracing]# echo 25 > osnoise/stop_tracing_total_us + [root@f32 tracing]# tail -10 trace + cc1-87882 [005] d..h... 548.771078: #402268 context irq timer_latency 13585 ns + cc1-87882 [005] dNLh1.. 548.771082: irq_noise: local_timer:236 start 548.771077442 duration 7597 ns + cc1-87882 [005] dNLh2.. 548.771099: irq_noise: qxl:21 start 548.771085017 duration 7139 ns + cc1-87882 [005] d...3.. 548.771102: thread_noise: cc1:87882 start 548.771078243 duration 9909 ns + timerlat/5-1035 [005] ....... 548.771104: #402268 context thread timer_latency 39960 ns + +In this case, the root cause of the timer latency does not point to a +single cause, but to multiple ones. Firstly, the timer IRQ was delayed +for 13 us, which may point to a long IRQ disabled section (see IRQ +stacktrace section). Then the timer interrupt that wakes up the timerlat +thread took 7597 ns, and the qxl:21 device IRQ took 7139 ns. Finally, +the cc1 thread noise took 9909 ns of time before the context switch. +Such pieces of evidence are useful for the developer to use other +tracing methods to figure out how to debug and optimize the system. + +It is worth mentioning that the *duration* values reported +by the osnoise: events are *net* values. For example, the +thread_noise does not include the duration of the overhead caused +by the IRQ execution (which indeed accounted for 12736 ns). But +the values reported by the timerlat tracer (timerlat_latency) +are *gross* values. + +The art below illustrates a CPU timeline and how the timerlat tracer +observes it at the top and the osnoise: events at the bottom. Each "-" +in the timelines means circa 1 us, and the time moves ==>:: + + External timer irq thread + clock latency latency + event 13585 ns 39960 ns + | ^ ^ + v | | + |-------------| | + |-------------+-------------------------| + ^ ^ + ======================================================================== + [tmr irq] [dev irq] + [another thread...^ v..^ v.......][timerlat/ thread] <-- CPU timeline + ========================================================================= + |-------| |-------| + |--^ v-------| + | | | + | | + thread_noise: 9909 ns + | +-> irq_noise: 6139 ns + +-> irq_noise: 7597 ns + +IRQ stacktrace +--------------------------- + +The osnoise/print_stack option is helpful for the cases in which a thread +noise causes the major factor for the timer latency, because of preempt or +irq disabled. For example:: + + [root@f32 tracing]# echo 500 > osnoise/stop_tracing_total_us + [root@f32 tracing]# echo 500 > osnoise/print_stack + [root@f32 tracing]# echo timerlat > current_tracer + [root@f32 tracing]# tail -21 per_cpu/cpu7/trace + insmod-1026 [007] dN.h1.. 200.201948: irq_noise: local_timer:236 start 200.201939376 duration 7872 ns + insmod-1026 [007] d..h1.. 200.202587: #29800 context irq timer_latency 1616 ns + insmod-1026 [007] dN.h2.. 200.202598: irq_noise: local_timer:236 start 200.202586162 duration 11855 ns + insmod-1026 [007] dN.h3.. 200.202947: irq_noise: local_timer:236 start 200.202939174 duration 7318 ns + insmod-1026 [007] d...3.. 200.203444: thread_noise: insmod:1026 start 200.202586933 duration 838681 ns + timerlat/7-1001 [007] ....... 200.203445: #29800 context thread timer_latency 859978 ns + timerlat/7-1001 [007] ....1.. 200.203446: <stack trace> + => timerlat_irq + => __hrtimer_run_queues + => hrtimer_interrupt + => __sysvec_apic_timer_interrupt + => asm_call_irq_on_stack + => sysvec_apic_timer_interrupt + => asm_sysvec_apic_timer_interrupt + => delay_tsc + => dummy_load_1ms_pd_init + => do_one_initcall + => do_init_module + => __do_sys_finit_module + => do_syscall_64 + => entry_SYSCALL_64_after_hwframe + +In this case, it is possible to see that the thread added the highest +contribution to the *timer latency* and the stack trace, saved during +the timerlat IRQ handler, points to a function named +dummy_load_1ms_pd_init, which had the following code (on purpose):: + + static int __init dummy_load_1ms_pd_init(void) + { + preempt_disable(); + mdelay(1); + preempt_enable(); + return 0; + + } diff --git a/Documentation/translations/index.rst b/Documentation/translations/index.rst index e446e5ed00a6..556b050884fc 100644 --- a/Documentation/translations/index.rst +++ b/Documentation/translations/index.rst @@ -18,6 +18,10 @@ Translations Disclaimer ---------- +.. raw:: latex + + \kerneldocCJKoff + Translation's purpose is to ease reading and understanding in languages other than English. Its aim is to help people who do not understand English or have doubts about its interpretation. Additionally, some people prefer to read diff --git a/Documentation/translations/it_IT/index.rst b/Documentation/translations/it_IT/index.rst index bb8fa7346939..e80a3097aa57 100644 --- a/Documentation/translations/it_IT/index.rst +++ b/Documentation/translations/it_IT/index.rst @@ -4,6 +4,10 @@ Traduzione italiana =================== +.. raw:: latex + + \kerneldocCJKoff + :manutentore: Federico Vaga <federico.vaga@vaga.pv.it> .. _it_disclaimer: diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst index 95f2e7c985e2..ecc74ba50d3e 100644 --- a/Documentation/translations/it_IT/process/coding-style.rst +++ b/Documentation/translations/it_IT/process/coding-style.rst @@ -62,7 +62,7 @@ i ``case``. Un esempio.: case 'K': case 'k': mem <<= 10; - /* fall through */ + fallthrough; default: break; } diff --git a/Documentation/translations/ja_JP/index.rst b/Documentation/translations/ja_JP/index.rst index 2f91b895e3c2..f94ba62d41c3 100644 --- a/Documentation/translations/ja_JP/index.rst +++ b/Documentation/translations/ja_JP/index.rst @@ -1,7 +1,8 @@ .. raw:: latex - \renewcommand\thesection* - \renewcommand\thesubsection* + \renewcommand\thesection* + \renewcommand\thesubsection* + \kerneldocCJKon Japanese translations ===================== diff --git a/Documentation/translations/ko_KR/index.rst b/Documentation/translations/ko_KR/index.rst index b9e27d20b039..6ae258118bdf 100644 --- a/Documentation/translations/ko_KR/index.rst +++ b/Documentation/translations/ko_KR/index.rst @@ -1,7 +1,8 @@ .. raw:: latex - \renewcommand\thesection* - \renewcommand\thesubsection* + \renewcommand\thesection* + \renewcommand\thesubsection* + \kerneldocCJKon 한국어 번역 =========== diff --git a/Documentation/translations/zh_CN/SecurityBugs b/Documentation/translations/zh_CN/SecurityBugs deleted file mode 100644 index 2d0fffd122ce..000000000000 --- a/Documentation/translations/zh_CN/SecurityBugs +++ /dev/null @@ -1,50 +0,0 @@ -Chinese translated version of Documentation/admin-guide/security-bugs.rst - -If you have any comment or update to the content, please contact the -original document maintainer directly. However, if you have a problem -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. - -Chinese maintainer: Harry Wei <harryxiyou@gmail.com> ---------------------------------------------------------------------- -Documentation/admin-guide/security-bugs.rst 的中文翻译 - -如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 -交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 -译存在问题，请联系中文版维护者。 - -中文版维护者： 贾威威 Harry Wei <harryxiyou@gmail.com> -中文版翻译者： 贾威威 Harry Wei <harryxiyou@gmail.com> -中文版校译者： 贾威威 Harry Wei <harryxiyou@gmail.com> - - -以下为正文 ---------------------------------------------------------------------- -Linux内核开发者认为安全非常重要。因此，我们想要知道当一个有关于 -安全的漏洞被发现的时候，并且它可能会被尽快的修复或者公开。请把这个安全 -漏洞报告给Linux内核安全团队。 - -1) 联系 - -linux内核安全团队可以通过email<security@kernel.org>来联系。这是 -一组独立的安全工作人员，可以帮助改善漏洞报告并且公布和取消一个修复。安 -全团队有可能会从部分的维护者那里引进额外的帮助来了解并且修复安全漏洞。 -当遇到任何漏洞，所能提供的信息越多就越能诊断和修复。如果你不清楚什么 -是有帮助的信息，那就请重温一下admin-guide/reporting-bugs.rst文件中的概述过程。任 -何攻击性的代码都是非常有用的，未经报告者的同意不会被取消，除非它已经 -被公布于众。 - -2) 公开 - -Linux内核安全团队的宗旨就是和漏洞提交者一起处理漏洞的解决方案直 -到公开。我们喜欢尽快地完全公开漏洞。当一个漏洞或者修复还没有被完全地理 -解，解决方案没有通过测试或者供应商协调，可以合理地延迟公开。然而，我们 -期望这些延迟尽可能的短些，是可数的几天，而不是几个星期或者几个月。公开 -日期是通过安全团队和漏洞提供者以及供应商洽谈后的结果。公开时间表是从很 -短（特殊的，它已经被公众所知道）到几个星期。作为一个基本的默认政策，我 -们所期望通知公众的日期是7天的安排。 - -3) 保密协议 - -Linux内核安全团队不是一个正式的团体，因此不能加入任何的保密协议。 diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst index be835ec8e632..460034cbc2ab 100644 --- a/Documentation/translations/zh_CN/admin-guide/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -65,6 +65,7 @@ Todolist: clearing-warn-once cpu-load + lockup-watchdogs unicode Todolist: @@ -100,7 +101,6 @@ Todolist: laptops/index lcd-panel-cgram ldm - lockup-watchdogs LSM/index md media/index diff --git a/Documentation/translations/zh_CN/admin-guide/lockup-watchdogs.rst b/Documentation/translations/zh_CN/admin-guide/lockup-watchdogs.rst new file mode 100644 index 000000000000..55ed3f4af442 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/lockup-watchdogs.rst @@ -0,0 +1,66 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/lockup-watchdogs.rst +:Translator: Hailong Liu <liu.hailong6@zte.com.cn> + +.. _cn_lockup-watchdogs: + + +================================================= +Softlockup与hardlockup检测机制(又名:nmi_watchdog) +================================================= + +Linux中内核实现了一种用以检测系统发生softlockup和hardlockup的看门狗机制。 + +Softlockup是一种会引发系统在内核态中一直循环超过20秒（详见下面“实现”小节）导致 +其他任务没有机会得到运行的BUG。一旦检测到'softlockup'发生，默认情况下系统会打 +印当前堆栈跟踪信息并进入锁定状态。也可配置使其在检测到'softlockup'后进入panic +状态；通过sysctl命令设置“kernel.softlockup_panic”、使用内核启动参数 +“softlockup_panic”（详见Documentation/admin-guide/kernel-parameters.rst）以及使 +能内核编译选项“BOOTPARAM_SOFTLOCKUP_PANIC”都可实现这种配置。 + +而'hardlockup'是一种会引发系统在内核态一直循环超过10秒钟（详见"实现"小节）导致其 +他中断没有机会运行的缺陷。与'softlockup'情况类似，除了使用sysctl命令设置 +'hardlockup_panic'、使能内核选项“BOOTPARAM_HARDLOCKUP_PANIC”以及使用内核参数 +"nmi_watchdog"(详见:”Documentation/admin-guide/kernel-parameters.rst“)外，一旦检 +测到'hardlockup'默认情况下系统打印当前堆栈跟踪信息，然后进入锁定状态。 + +这个panic选项也可以与panic_timeout结合使用（这个panic_timeout是通过稍具迷惑性的 +sysctl命令"kernel.panic"来设置），使系统在panic指定时间后自动重启。 + +实现 +==== + +Softlockup和hardlockup分别建立在hrtimer(高精度定时器)和perf两个子系统上而实现。 +这也就意味着理论上任何架构只要实现了这两个子系统就支持这两种检测机制。 + +Hrtimer用于周期性产生中断并唤醒watchdog线程；NMI perf事件则以”watchdog_thresh“ +(编译时默认初始化为10秒，也可通过”watchdog_thresh“这个sysctl接口来进行配置修改) +为间隔周期产生以检测 hardlockups。如果一个CPU在这个时间段内没有检测到hrtimer中 +断发生，'hardlockup 检测器'(即NMI perf事件处理函数)将会视系统配置而选择产生内核 +警告或者直接panic。 + +而watchdog线程本质上是一个高优先级内核线程，每调度一次就对时间戳进行一次更新。 +如果时间戳在2*watchdog_thresh(这个是softlockup的触发门限)这段时间都未更新,那么 +"softlocup 检测器"(内部hrtimer定时器回调函数)会将相关的调试信息打印到系统日志中， +然后如果系统配置了进入panic流程则进入panic，否则内核继续执行。 + +Hrtimer定时器的周期是2*watchdog_thresh/5，也就是说在hardlockup被触发前hrtimer有 +2~3次机会产生时钟中断。 + +如上所述,内核相当于为系统管理员提供了一个可调节hrtimer定时器和perf事件周期长度 +的调节旋钮。如何通过这个旋钮为特定使用场景配置一个合理的周期值要对lockups检测的 +响应速度和lockups检测开销这二者之间进行权衡。 + +默认情况下所有在线cpu上都会运行一个watchdog线程。不过在内核配置了”NO_HZ_FULL“的 +情况下watchdog线程默认只会运行在管家(housekeeping)cpu上，而”nohz_full“启动参数指 +定的cpu上则不会有watchdog线程运行。试想，如果我们允许watchdog线程在”nohz_full“指 +定的cpu上运行，这些cpu上必须得运行时钟定时器来激发watchdog线程调度；这样一来就会 +使”nohz_full“保护用户程序免受内核干扰的功能失效。当然，副作用就是”nohz_full“指定 +的cpu即使在内核产生了lockup问题我们也无法检测到。不过，至少我们可以允许watchdog +线程在管家(non-tickless)核上继续运行以便我们能继续正常的监测这些cpus上的lockups +事件。 + +不论哪种情况都可以通过sysctl命令kernel.watchdog_cpumask来对没有运行watchdog线程 +的cpu集合进行调节。对于nohz_full而言,如果nohz_full cpu上有异常挂住的情况，通过 +这种方式打开这些cpu上的watchdog进行调试可能会有所作用。 diff --git a/Documentation/translations/zh_CN/core-api/cachetlb.rst b/Documentation/translations/zh_CN/core-api/cachetlb.rst new file mode 100644 index 000000000000..8376485a534d --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/cachetlb.rst @@ -0,0 +1,336 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/cachetlb.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + 吴想成 Wu XiangCheng <bobwxc@email.cn> + +.. _cn_core-api_cachetlb: + +====================== +Linux下的缓存和TLB刷新 +====================== + +:作者: David S. Miller <davem@redhat.com> + +*译注：TLB，Translation Lookaside Buffer，页表缓存/变换旁查缓冲器* + +本文描述了由Linux虚拟内存子系统调用的缓存/TLB刷新接口。它列举了每个接 +口，描述了它的预期目的，以及接口被调用后的预期副作用。 + +下面描述的副作用是针对单处理器的实现，以及在单个处理器上发生的情况。若 +为SMP，则只需将定义简单地扩展一下，使发生在某个特定接口的副作用扩展到系 +统的所有处理器上。不要被这句话吓到，以为SMP的缓存/tlb刷新一定是很低 +效的，事实上，这是一个可以进行很多优化的领域。例如，如果可以证明一个用 +户地址空间从未在某个cpu上执行过（见mm_cpumask()），那么就不需要在该 +cpu上对这个地址空间进行刷新。 + +首先是TLB刷新接口，因为它们是最简单的。在Linux下，TLB被抽象为cpu +用来缓存从软件页表获得的虚拟->物理地址转换的东西。这意味着，如果软件页 +表发生变化，这个“TLB”缓存中就有可能出现过时（脏）的翻译。因此，当软件页表 +发生变化时，内核会在页表发生 *变化后* 调用以下一种刷新方法： + +1) ``void flush_tlb_all(void)`` + + 最严格的刷新。在这个接口运行后，任何以前的页表修改都会对cpu可见。 + + 这通常是在内核页表被改变时调用的，因为这种转换在本质上是“全局”的。 + +2) ``void flush_tlb_mm(struct mm_struct *mm)`` + + 这个接口从TLB中刷新整个用户地址空间。在运行后，这个接口必须确保 + 以前对地址空间‘mm’的任何页表修改对cpu来说是可见的。也就是说，在 + 运行后，TLB中不会有‘mm’的页表项。 + + 这个接口被用来处理整个地址空间的页表操作，比如在fork和exec过程 + 中发生的事情。 + +3) ``void flush_tlb_range(struct vm_area_struct *vma, + unsigned long start, unsigned long end)`` + + 这里我们要从TLB中刷新一个特定范围的（用户）虚拟地址转换。在运行后， + 这个接口必须确保以前对‘start’到‘end-1’范围内的地址空间‘vma->vm_mm’ + 的任何页表修改对cpu来说是可见的。也就是说，在运行后，TLB中不会有 + ‘mm’的页表项用于‘start’到‘end-1’范围内的虚拟地址。 + + “vma”是用于该区域的备份存储。主要是用于munmap()类型的操作。 + + 提供这个接口是希望端口能够找到一个合适的有效方法来从TLB中删除多 + 个页面大小的转换，而不是让内核为每个可能被修改的页表项调用 + flush_tlb_page(见下文)。 + +4) ``void flush_tlb_page(struct vm_area_struct *vma, unsigned long addr)`` + + 这一次我们需要从TLB中删除PAGE_SIZE大小的转换。‘vma’是Linux用来跟 + 踪进程的mmap区域的支持结构体，地址空间可以通过vma->vm_mm获得。另 + 外，可以通过测试（vma->vm_flags & VM_EXEC）来查看这个区域是否是 + 可执行的（因此在split-tlb类型的设置中可能在“指令TLB”中）。 + + 在运行后，这个接口必须确保之前对用户虚拟地址“addr”的地址空间 + “vma->vm_mm”的页表修改对cpu来说是可见的。也就是说，在运行后，TLB + 中不会有虚拟地址‘addr’的‘vma->vm_mm’的页表项。 + + 这主要是在故障处理时使用。 + +5) ``void update_mmu_cache(struct vm_area_struct *vma, + unsigned long address, pte_t *ptep)`` + + 在每个页面故障结束时，这个程序被调用，以告诉体系结构特定的代码，在 + 软件页表中，在地址空间“vma->vm_mm”的虚拟地址“地址”处，现在存在 + 一个翻译。 + + 可以用它所选择的任何方式使用这个信息来进行移植。例如，它可以使用这 + 个事件来为软件管理的TLB配置预装TLB转换。目前sparc64移植就是这么干 + 的。 + +接下来，我们有缓存刷新接口。一般来说，当Linux将现有的虚拟->物理映射 +改变为新的值时，其顺序将是以下形式之一:: + + 1) flush_cache_mm(mm); + change_all_page_tables_of(mm); + flush_tlb_mm(mm); + + 2) flush_cache_range(vma, start, end); + change_range_of_page_tables(mm, start, end); + flush_tlb_range(vma, start, end); + + 3) flush_cache_page(vma, addr, pfn); + set_pte(pte_pointer, new_pte_val); + flush_tlb_page(vma, addr); + +缓存级别的刷新将永远是第一位的，因为这允许我们正确处理那些缓存严格， +且在虚拟地址被从缓存中刷新时要求一个虚拟地址的虚拟->物理转换存在的系统。 +HyperSparc cpu就是这样一个具有这种属性的cpu。 + +下面的缓存刷新程序只需要在特定的cpu需要的范围内处理缓存刷新。大多数 +情况下，这些程序必须为cpu实现，这些cpu有虚拟索引的缓存，当虚拟->物 +理转换被改变或移除时，必须被刷新。因此，例如，IA32处理器的物理索引 +的物理标记的缓存没有必要实现这些接口，因为这些缓存是完全同步的，并 +且不依赖于翻译信息。 + +下面逐个列出这些程序: + +1) ``void flush_cache_mm(struct mm_struct *mm)`` + + 这个接口将整个用户地址空间从高速缓存中刷掉。也就是说，在运行后， + 将没有与‘mm’相关的缓存行。 + + 这个接口被用来处理整个地址空间的页表操作，比如在退出和执行过程 + 中发生的事情。 + +2) ``void flush_cache_dup_mm(struct mm_struct *mm)`` + + 这个接口将整个用户地址空间从高速缓存中刷新掉。也就是说，在运行 + 后，将没有与‘mm’相关的缓存行。 + + 这个接口被用来处理整个地址空间的页表操作，比如在fork过程中发生 + 的事情。 + + 这个选项与flush_cache_mm分开，以允许对VIPT缓存进行一些优化。 + +3) ``void flush_cache_range(struct vm_area_struct *vma, + unsigned long start, unsigned long end)`` + + 在这里，我们要从缓存中刷新一个特定范围的（用户）虚拟地址。运行 + 后，在“start”到“end-1”范围内的虚拟地址的“vma->vm_mm”的缓存中 + 将没有页表项。 + + “vma”是被用于该区域的备份存储。主要是用于munmap()类型的操作。 + + 提供这个接口是希望端口能够找到一个合适的有效方法来从缓存中删 + 除多个页面大小的区域， 而不是让内核为每个可能被修改的页表项调 + 用 flush_cache_page (见下文)。 + +4) ``void flush_cache_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn)`` + + 这一次我们需要从缓存中删除一个PAGE_SIZE大小的区域。“vma”是 + Linux用来跟踪进程的mmap区域的支持结构体，地址空间可以通过 + vma->vm_mm获得。另外，我们可以通过测试（vma->vm_flags & + VM_EXEC）来查看这个区域是否是可执行的（因此在“Harvard”类 + 型的缓存布局中可能是在“指令缓存”中）。 + + “pfn”表示“addr”所对应的物理页框（通过PAGE_SHIFT左移这个 + 值来获得物理地址）。正是这个映射应该从缓存中删除。 + + 在运行之后，对于虚拟地址‘addr’的‘vma->vm_mm’，在缓存中不会 + 有任何页表项，它被翻译成‘pfn’。 + + 这主要是在故障处理过程中使用。 + +5) ``void flush_cache_kmaps(void)`` + + 只有在平台使用高位内存的情况下才需要实现这个程序。它将在所有的 + kmaps失效之前被调用。 + + 运行后，内核虚拟地址范围PKMAP_ADDR(0)到PKMAP_ADDR(LAST_PKMAP) + 的缓存中将没有页表项。 + + 这个程序应该在asm/highmem.h中实现。 + +6) ``void flush_cache_vmap(unsigned long start, unsigned long end)`` + ``void flush_cache_vunmap(unsigned long start, unsigned long end)`` + + 在这里，在这两个接口中，我们从缓存中刷新一个特定范围的（内核） + 虚拟地址。运行后，在“start”到“end-1”范围内的虚拟地址的内核地 + 址空间的缓存中不会有页表项。 + + 这两个程序中的第一个是在vmap_range()安装了页表项之后调用的。 + 第二个是在vunmap_range()删除页表项之前调用的。 + +还有一类cpu缓存问题，目前需要一套完全不同的接口来正确处理。最大 +的问题是处理器的数据缓存中的虚拟别名。 + +.. note:: + + 这段内容有些晦涩，为了减轻中文阅读压力，特作此译注。 + + 别名（alias）属于缓存一致性问题，当不同的虚拟地址映射相同的 + 物理地址，而这些虚拟地址的index不同，此时就发生了别名现象(多 + 个虚拟地址被称为别名)。通俗点来说就是指同一个物理地址的数据被 + 加载到不同的cacheline中就会出现别名现象。 + + 常见的解决方法有两种：第一种是硬件维护一致性，设计特定的cpu电 + 路来解决问题（例如设计为PIPT的cache）；第二种是软件维护一致性， + 就是下面介绍的sparc的解决方案——页面染色，涉及的技术细节太多， + 译者不便展开，请读者自行查阅相关资料。 + +您的移植是否容易在其D-cache中出现虚拟别名？嗯，如果您的D-cache +是虚拟索引的，且cache大于PAGE_SIZE（页大小），并且不能防止同一 +物理地址的多个cache行同时存在，您就会遇到这个问题。 + +如果你的D-cache有这个问题，首先正确定义asm/shmparam.h SHMLBA， +它基本上应该是你的虚拟寻址D-cache的大小（或者如果大小是可变的， +则是最大的可能大小）。这个设置将迫使SYSv IPC层只允许用户进程在 +这个值的倍数的地址上对共享内存进行映射。 + +.. note:: + + 这并不能解决共享mmaps的问题，请查看sparc64移植解决 + 这个问题的一个方法（特别是 SPARC_FLAG_MMAPSHARED）。 + +接下来，你必须解决所有其他情况下的D-cache别名问题。请记住这个事 +实，对于一个给定的页面映射到某个用户地址空间，总是至少还有一个映 +射，那就是内核在其线性映射中从PAGE_OFFSET开始。因此，一旦第一个 +用户将一个给定的物理页映射到它的地址空间，就意味着D-cache的别名 +问题有可能存在，因为内核已经将这个页映射到它的虚拟地址。 + + ``void copy_user_page(void *to, void *from, unsigned long addr, struct page *page)`` + ``void clear_user_page(void *to, unsigned long addr, struct page *page)`` + + 这两个程序在用户匿名或COW页中存储数据。它允许一个端口有效地 + 避免用户空间和内核之间的D-cache别名问题。 + + 例如，一个端口可以在复制过程中把“from”和“to”暂时映射到内核 + 的虚拟地址上。这两个页面的虚拟地址的选择方式是，内核的加载/存 + 储指令发生在虚拟地址上，而这些虚拟地址与用户的页面映射是相同 + 的“颜色”。例如，Sparc64就使用这种技术。 + + “addr”参数告诉了用户最终要映射这个页面的虚拟地址，“page”参 + 数给出了一个指向目标页结构体的指针。 + + 如果D-cache别名不是问题，这两个程序可以简单地直接调用 + memcpy/memset而不做其他事情。 + + ``void flush_dcache_page(struct page *page)`` + + 任何时候，当内核写到一个页面缓存页，或者内核要从一个页面缓存 + 页中读出，并且这个页面的用户空间共享/可写映射可能存在时， + 这个程序就会被调用。 + + .. note:: + + 这个程序只需要为有可能被映射到用户进程的地址空间的 + 页面缓存调用。因此，例如，处理页面缓存中vfs符号链 + 接的VFS层代码根本不需要调用这个接口。 + + “内核写入页面缓存的页面”这句话的意思是，具体来说，内核执行存 + 储指令，在该页面的页面->虚拟映射处弄脏该页面的数据。在这里，通 + 过刷新的手段处理D-cache的别名是很重要的，以确保这些内核存储对 + 该页的用户空间映射是可见的。 + + 推论的情况也同样重要，如果有用户对这个文件有共享+可写的映射， + 我们必须确保内核对这些页面的读取会看到用户所做的最新的存储。 + + 如果D-cache别名不是一个问题，这个程序可以简单地定义为该架构上 + 的nop。 + + 在page->flags (PG_arch_1)中有一个位是“架构私有”。内核保证， + 对于分页缓存的页面，当这样的页面第一次进入分页缓存时，它将清除 + 这个位。 + + 这使得这些接口可以更有效地被实现。如果目前没有用户进程映射这个 + 页面，它允许我们“推迟”（也许是无限期）实际的刷新过程。请看 + sparc64的flush_dcache_page和update_mmu_cache实现，以了解如 + 何做到这一点。 + + 这个想法是，首先在flush_dcache_page()时，如果page->mapping->i_mmap + 是一个空树，只需标记架构私有页标志位。之后，在update_mmu_cache() + 中，会对这个标志位进行检查，如果设置了，就进行刷新，并清除标志位。 + + .. important:: + + 通常很重要的是，如果你推迟刷新，实际的刷新发生在同一个 + CPU上，因为它将cpu存储到页面上，使其变脏。同样，请看 + sparc64关于如何处理这个问题的例子。 + + ``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, + unsigned long user_vaddr, void *dst, void *src, int len)`` + + 当内核需要复制任意的数据进出任意的用户页时（比如ptrace()），它将使 + 用这两个程序。 + + 任何必要的缓存刷新或其他需要发生的一致性操作都应该在这里发生。如果 + 处理器的指令缓存没有对cpu存储进行窥探，那么你很可能需要为 + copy_to_user_page()刷新指令缓存。 + + ``void flush_anon_page(struct vm_area_struct *vma, struct page *page, + unsigned long vmaddr)`` + + 当内核需要访问一个匿名页的内容时，它会调用这个函数（目前只有 + get_user_pages()）。注意：flush_dcache_page()故意对匿名页不起作 + 用。默认的实现是nop（对于所有相干的架构应该保持这样）。对于不一致性 + 的架构，它应该刷新vmaddr处的页面缓存。 + + ``void flush_kernel_dcache_page(struct page *page)`` + + 当内核需要修改一个用kmap获得的用户页时，它会在所有修改完成后（但在 + kunmapping之前）调用这个函数，以使底层页面达到最新状态。这里假定用 + 户没有不一致性的缓存副本（即原始页面是从类似get_user_pages()的机制 + 中获得的）。默认的实现是一个nop，在所有相干的架构上都应该如此。在不 + 一致性的架构上，这应该刷新内核缓存中的页面（使用page_address(page)）。 + + + ``void flush_icache_range(unsigned long start, unsigned long end)`` + + 当内核存储到它将执行的地址中时（例如在加载模块时），这个函数被调用。 + + 如果icache不对存储进行窥探，那么这个程序将需要对其进行刷新。 + + ``void flush_icache_page(struct vm_area_struct *vma, struct page *page)`` + + flush_icache_page的所有功能都可以在flush_dcache_page和update_mmu_cache + 中实现。在未来，我们希望能够完全删除这个接口。 + +最后一类API是用于I/O到内核内特意设置的别名地址范围。这种别名是通过使用 +vmap/vmalloc API设置的。由于内核I/O是通过物理页进行的，I/O子系统假定用户 +映射和内核偏移映射是唯一的别名。这对vmap别名来说是不正确的，所以内核中任何 +试图对vmap区域进行I/O的东西都必须手动管理一致性。它必须在做I/O之前刷新vmap +范围，并在I/O返回后使其失效。 + + ``void flush_kernel_vmap_range(void *vaddr, int size)`` + + 刷新vmap区域中指定的虚拟地址范围的内核缓存。这是为了确保内核在vmap范围 + 内修改的任何数据对物理页是可见的。这个设计是为了使这个区域可以安全地执 + 行I/O。注意，这个API并 *没有* 刷新该区域的偏移映射别名。 + + ``void invalidate_kernel_vmap_range(void *vaddr, int size) invalidates`` + + 在vmap区域的一个给定的虚拟地址范围的缓存，这可以防止处理器在物理页的I/O + 发生时通过投机性地读取数据而使缓存变脏。这只对读入vmap区域的数据是必要的。 diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index f1fa71e45c77..b4bde9396339 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -19,12 +19,13 @@ 来的大量 kerneldoc 信息；有朝一日，若有人有动力的话，应当把它们拆分 出来。 -Todolist: +.. toctree:: + :maxdepth: 1 kernel-api - workqueue printk-basics printk-formats + workqueue symbol-namespaces 数据结构和低级实用程序 @@ -32,9 +33,13 @@ Todolist: 在整个内核中使用的函数库。 -Todolist: +.. toctree:: + :maxdepth: 1 kobject + +Todolist: + kref assoc_array xarray @@ -58,12 +63,12 @@ Linux如何让一切同时发生。 详情请参阅 :maxdepth: 1 irq/index - -Todolist: - refcount-vs-atomic local_ops padata + +Todolist: + ../RCU/index 低级硬件管理 @@ -71,9 +76,14 @@ Todolist: 缓存管理，CPU热插拔管理等。 -Todolist: +.. toctree:: + :maxdepth: 1 cachetlb + +Todolist: + + cpu_hotplug memory-hotplug genericirq diff --git a/Documentation/translations/zh_CN/core-api/kernel-api.rst b/Documentation/translations/zh_CN/core-api/kernel-api.rst new file mode 100644 index 000000000000..d6f815ec265b --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/kernel-api.rst @@ -0,0 +1,369 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/kernel-api.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_kernel-api.rst: + + +============ +Linux内核API +============ + + +列表管理函数 +============ + +该API在以下内核代码中: + +include/linux/list.h + +基本的C库函数 +============= + +在编写驱动程序时，一般不能使用C库中的例程。部分函数通常很有用，它们在 +下面被列出。这些函数的行为可能会与ANSI定义的略有不同，这些偏差会在文中 +注明。 + +字符串转换 +---------- + +该API在以下内核代码中: + +lib/vsprintf.c + +include/linux/kernel.h + +include/linux/kernel.h + +lib/kstrtox.c + +lib/string_helpers.c + +字符串处理 +---------- + +该API在以下内核代码中: + +lib/string.c + +include/linux/string.h + +mm/util.c + +基本的内核库函数 +================ + +Linux内核提供了很多实用的基本函数。 + +位运算 +------ + +该API在以下内核代码中: + +include/asm-generic/bitops/instrumented-atomic.h + +include/asm-generic/bitops/instrumented-non-atomic.h + +include/asm-generic/bitops/instrumented-lock.h + +位图运算 +-------- + +该API在以下内核代码中: + +lib/bitmap.c + +include/linux/bitmap.h + +include/linux/bitmap.h + +include/linux/bitmap.h + +lib/bitmap.c + +lib/bitmap.c + +include/linux/bitmap.h + +命令行解析 +---------- + +该API在以下内核代码中: + +lib/cmdline.c + +排序 +---- + +该API在以下内核代码中: + +lib/sort.c + +lib/list_sort.c + +文本检索 +-------- + +该API在以下内核代码中: + +lib/textsearch.c + +lib/textsearch.c + +include/linux/textsearch.h + +Linux中的CRC和数学函数 +====================== + + +CRC函数 +------- + +*译注：CRC，Cyclic Redundancy Check，循环冗余校验* + +该API在以下内核代码中: + +lib/crc4.c + +lib/crc7.c + +lib/crc8.c + +lib/crc16.c + +lib/crc32.c + +lib/crc-ccitt.c + +lib/crc-itu-t.c + +基数为2的对数和幂函数 +--------------------- + +该API在以下内核代码中: + +include/linux/log2.h + +整数幂函数 +---------- + +该API在以下内核代码中: + +lib/math/int_pow.c + +lib/math/int_sqrt.c + +除法函数 +-------- + +该API在以下内核代码中: + +include/asm-generic/div64.h + +include/linux/math64.h + +lib/math/div64.c + +lib/math/gcd.c + +UUID/GUID +--------- + +该API在以下内核代码中: + +lib/uuid.c + +内核IPC设备 +=========== + +IPC实用程序 +----------- + +该API在以下内核代码中: + +ipc/util.c + +FIFO 缓冲区 +=========== + +kfifo接口 +--------- + +该API在以下内核代码中: + +include/linux/kfifo.h + +转发接口支持 +============ + +转发接口支持旨在为工具和设备提供一种有效的机制，将大量数据从内核空间 +转发到用户空间。 + +转发接口 +-------- + +该API在以下内核代码中: + +kernel/relay.c + +kernel/relay.c + +模块支持 +======== + +模块加载 +-------- + +该API在以下内核代码中: + +kernel/kmod.c + +模块接口支持 +------------ + +更多信息请参考文件kernel/module.c。 + +硬件接口 +======== + + +该API在以下内核代码中: + +kernel/dma.c + +资源管理 +-------- + +该API在以下内核代码中: + +kernel/resource.c + +kernel/resource.c + +MTRR处理 +-------- + +该API在以下内核代码中: + +arch/x86/kernel/cpu/mtrr/mtrr.c + +安全框架 +======== + +该API在以下内核代码中: + +security/security.c + +security/inode.c + +审计接口 +======== + +该API在以下内核代码中: + +kernel/audit.c + +kernel/auditsc.c + +kernel/auditfilter.c + +核算框架 +======== + +该API在以下内核代码中: + +kernel/acct.c + +块设备 +====== + +该API在以下内核代码中: + +block/blk-core.c + +block/blk-core.c + +block/blk-map.c + +block/blk-sysfs.c + +block/blk-settings.c + +block/blk-exec.c + +block/blk-flush.c + +block/blk-lib.c + +block/blk-integrity.c + +kernel/trace/blktrace.c + +block/genhd.c + +block/genhd.c + +字符设备 +======== + +该API在以下内核代码中: + +fs/char_dev.c + +时钟框架 +======== + +时钟框架定义了编程接口，以支持系统时钟树的软件管理。该框架广泛用于系统级芯片（SOC）平 +台，以支持电源管理和各种可能需要自定义时钟速率的设备。请注意，这些 “时钟”与计时或实 +时时钟(RTC)无关，它们都有单独的框架。这些:c:type: `struct clk <clk>` 实例可用于管理 +各种时钟信号，例如一个96理例如96MHz的时钟信号，该信号可被用于总线或外设的数据交换，或以 +其他方式触发系统硬件中的同步状态机转换。 + +通过明确的软件时钟门控来支持电源管理：未使用的时钟被禁用，因此系统不会因为改变不在使用 +中的晶体管的状态而浪费电源。在某些系统中，这可能是由硬件时钟门控支持的，其中时钟被门控 +而不在软件中被禁用。芯片的部分，在供电但没有时钟的情况下，可能会保留其最后的状态。这种 +低功耗状态通常被称为*保留模式*。这种模式仍然会产生漏电流，特别是在电路几何结构较细的情 +况下，但对于CMOS电路来说，电能主要是随着时钟翻转而被消耗的。 + +电源感知驱动程序只有在其管理的设备处于活动使用状态时才会启用时钟。此外，系统睡眠状态通 +常根据哪些时钟域处于活动状态而有所不同：“待机”状态可能允许从多个活动域中唤醒，而 +"mem"（暂停到RAM）状态可能需要更全面地关闭来自高速PLL和振荡器的时钟，从而限制了可能 +的唤醒事件源的数量。驱动器的暂停方法可能需要注意目标睡眠状态的系统特定时钟约束。 + +一些平台支持可编程时钟发生器。这些可以被各种外部芯片使用，如其他CPU、多媒体编解码器以 +及对接口时钟有严格要求的设备。 + +该API在以下内核代码中: + +include/linux/clk.h + +同步原语 +======== + +读-复制-更新（RCU） +------------------- + +该API在以下内核代码中: + +include/linux/rcupdate.h + +kernel/rcu/tree.c + +kernel/rcu/tree_exp.h + +kernel/rcu/update.c + +include/linux/srcu.h + +kernel/rcu/srcutree.c + +include/linux/rculist_bl.h + +include/linux/rculist.h + +include/linux/rculist_nulls.h + +include/linux/rcu_sync.h + +kernel/rcu/sync.c diff --git a/Documentation/translations/zh_CN/core-api/kobject.rst b/Documentation/translations/zh_CN/core-api/kobject.rst new file mode 100644 index 000000000000..f0e6a4aeb372 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/kobject.rst @@ -0,0 +1,378 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/kobject.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_core_api_kobject.rst: + +======================================================= +关于kobjects、ksets和ktypes的一切你没想过需要了解的东西 +======================================================= + +:作者: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +:最后一次更新: December 19, 2007 + +根据Jon Corbet于2003年10月1日为lwn.net撰写的原创文章改编，网址是： +https://lwn.net/Articles/51437/ + +理解驱动模型和建立在其上的kobject抽象的部分的困难在于，没有明显的切入点。 +处理kobjects需要理解一些不同的类型，所有这些类型都会相互引用。为了使事情 +变得更简单，我们将多路并进，从模糊的术语开始，并逐渐增加细节。那么，先来 +了解一些我们将要使用的术语的简明定义吧。 + + - 一个kobject是一个kobject结构体类型的对象。Kobjects有一个名字和一个 + 引用计数。一个kobject也有一个父指针（允许对象被排列成层次结构），一个 + 特定的类型，并且，通常在sysfs虚拟文件系统中表示。 + + Kobjects本身通常并不引人关注；相反它们常常被嵌入到其他包含真正引人注目 + 的代码的结构体中。 + + 任何结构体都 **不应该** 有一个以上的kobject嵌入其中。如果有的话，对象的引用计 + 数肯定会被打乱，而且不正确，你的代码就会出现错误。所以不要这样做。 + + - ktype是嵌入一个kobject的对象的类型。每个嵌入kobject的结构体都需要一个 + 相应的ktype。ktype控制着kobject在被创建和销毁时的行为。 + + - 一个kset是一组kobjects。这些kobjects可以是相同的ktype或者属于不同的 + ktype。kset是kobjects集合的基本容器类型。Ksets包含它们自己的kobjects， + 但你可以安全地忽略这个实现细节，因为kset的核心代码会自动处理这个kobject。 + + 当你看到一个下面全是其他目录的sysfs目录时，通常这些目录中的每一个都对应 + 于同一个kset中的一个kobject。 + + 我们将研究如何创建和操作所有这些类型。将采取一种自下而上的方法，所以我们 + 将回到kobjects。 + + +嵌入kobjects +============= + +内核代码很少创建孤立的kobject，只有一个主要的例外，下面会解释。相反， +kobjects被用来控制对一个更大的、特定领域的对象的访问。为此，kobjects会被 +嵌入到其他结构中。如果你习惯于用面向对象的术语来思考问题，那么kobjects可 +以被看作是一个顶级的抽象类，其他的类都是从它派生出来的。一个kobject实现了 +一系列的功能，这些功能本身并不特别有用，但在其他对象中却很好用。C语言不允 +许直接表达继承，所以必须使用其他技术——比如结构体嵌入。 + +（对于那些熟悉内核链表实现的人来说，这类似于“list_head”结构本身很少有用， +但总是被嵌入到感兴趣的更大的对象中）。 + +例如， ``drivers/uio/uio.c`` 中的IO代码有一个结构体，定义了与uio设备相 +关的内存区域:: + + struct uio_map { + struct kobject kobj; + struct uio_mem *mem; + }; + +如果你有一个uio_map结构体，找到其嵌入的kobject只是一个使用kobj成员的问题。 +然而，与kobjects一起工作的代码往往会遇到相反的问题：给定一个结构体kobject +的指针，指向包含结构体的指针是什么？你必须避免使用一些技巧（比如假设 +kobject在结构的开头），相反，你得使用container_of()宏，其可以在 ``<linux/kernel.h>`` +中找到:: + + container_of(ptr, type, member) + +其中: + + * ``ptr`` 是一个指向嵌入kobject的指针， + * ``type`` 是包含结构体的类型， + * ``member`` 是 ``指针`` 所指向的结构体域的名称。 + +container_of()的返回值是一个指向相应容器类型的指针。因此，例如，一个嵌入到 +uio_map结构 **中** 的kobject结构体的指针kp可以被转换为一个指向 **包含** uio_map +结构体的指针，方法是:: + + struct uio_map *u_map = container_of(kp, struct uio_map, kobj); + +为了方便起见，程序员经常定义一个简单的宏，用于将kobject指针 **反推** 到包含 +类型。在早期的 ``drivers/uio/uio.c`` 中正是如此，你可以在这里看到:: + + struct uio_map { + struct kobject kobj; + struct uio_mem *mem; + }; + + #define to_map(map) container_of(map, struct uio_map, kobj) + +其中宏的参数“map”是一个指向有关的kobject结构体的指针。该宏随后被调用:: + + struct uio_map *map = to_map(kobj); + + +kobjects的初始化 +================ + +当然，创建kobject的代码必须初始化该对象。一些内部字段是通过（强制）调用kobject_init() +来设置的:: + + void kobject_init(struct kobject *kobj, struct kobj_type *ktype); + +ktype是正确创建kobject的必要条件，因为每个kobject都必须有一个相关的kobj_type。 +在调用kobject_init()后，为了向sysfs注册kobject，必须调用函数kobject_add():: + + int kobject_add(struct kobject *kobj, struct kobject *parent, + const char *fmt, ...); + +这将正确设置kobject的父级和kobject的名称。如果该kobject要与一个特定的kset相关 +联，在调用kobject_add()之前必须分配kobj->kset。如果kset与kobject相关联，则 +kobject的父级可以在调用kobject_add()时被设置为NULL，则kobject的父级将是kset +本身。 + +由于kobject的名字是在它被添加到内核时设置的，所以kobject的名字不应该被直接操作。 +如果你必须改变kobject的名字，请调用kobject_rename():: + + int kobject_rename(struct kobject *kobj, const char *new_name); + +kobject_rename()函数不会执行任何锁定操作，也不会对name进行可靠性检查，所以调用 +者自己检查和串行化操作是明智的选择 + +有一个叫kobject_set_name()的函数，但那是历史遗产，正在被删除。如果你的代码需 +要调用这个函数，那么它是不正确的，需要被修复。 + +要正确访问kobject的名称，请使用函数kobject_name():: + + const char *kobject_name(const struct kobject * kobj); + +有一个辅助函数可以同时初始化和添加kobject到内核中，令人惊讶的是，该函数被称为 +kobject_init_and_add():: + + int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype, + struct kobject *parent, const char *fmt, ...); + +参数与上面描述的单个kobject_init()和kobject_add()函数相同。 + + +Uevents +======= + +当一个kobject被注册到kobject核心后，你需要向全世界宣布它已经被创建了。这可以通 +过调用kobject_uevent()来实现:: + + int kobject_uevent(struct kobject *kobj, enum kobject_action action); + +当kobject第一次被添加到内核时，使用 *KOBJ_ADD* 动作。这应该在该kobject的任 +何属性或子对象被正确初始化后进行，因为当这个调用发生时，用户空间会立即开始寻 +找它们。 + +当kobject从内核中移除时（关于如何做的细节在下面）， **KOBJ_REMOVE** 的uevent +将由kobject核心自动创建，所以调用者不必担心手动操作。 + + +引用计数 +======== + +kobject的关键功能之一是作为它所嵌入的对象的一个引用计数器。只要对该对象的引用 +存在，该对象（以及支持它的代码）就必须继续存在。用于操作kobject的引用计数的低 +级函数是:: + + struct kobject *kobject_get(struct kobject *kobj); + void kobject_put(struct kobject *kobj); + +对kobject_get()的成功调用将增加kobject的引用计数器值并返回kobject的指针。 + +当引用被释放时，对kobject_put()的调用将递减引用计数值，并可能释放该对象。请注 +意，kobject_init()将引用计数设置为1，所以设置kobject的代码最终需要kobject_put() +来释放该引用。 + +因为kobjects是动态的，所以它们不能以静态方式或在堆栈中声明，而总是以动态方式分 +配。未来版本的内核将包含对静态创建的kobjects的运行时检查，并将警告开发者这种不 +当的使用。 + +如果你使用struct kobject只是为了给你的结构体提供一个引用计数器，请使用struct kref +来代替；kobject是多余的。关于如何使用kref结构体的更多信息，请参见Linux内核源代 +码树中的文件Documentation/core-api/kref.rst + + +创建“简单的”kobjects +==================== + +有时，开发者想要的只是在sysfs层次结构中创建一个简单的目录，而不必去搞那些复杂 +的ksets、显示和存储函数，以及其他细节。这是一个应该创建单个kobject的例外。要 +创建这样一个条目（即简单的目录），请使用函数:: + + struct kobject *kobject_create_and_add(const char *name, struct kobject *parent); + +这个函数将创建一个kobject，并将其放在sysfs中指定的父kobject下面的位置。要创 +建与此kobject相关的简单属性，请使用:: + + int sysfs_create_file(struct kobject *kobj, const struct attribute *attr); + +或者:: + + int sysfs_create_group(struct kobject *kobj, const struct attribute_group *grp); + +这里使用的两种类型的属性，与已经用kobject_create_and_add()创建的kobject， +都可以是kobj_attribute类型，所以不需要创建特殊的自定义属性。 + +参见示例模块， ``samples/kobject/kobject-example.c`` ，以了解一个简单的 +kobject和属性的实现。 + + + +ktypes和释放方法 +================ + +以上讨论中还缺少一件重要的事情，那就是当一个kobject的引用次数达到零的时候 +会发生什么。创建kobject的代码通常不知道何时会发生这种情况；首先，如果它知 +道，那么使用kobject就没有什么意义。当sysfs被引入时，即使是可预测的对象生命 +周期也会变得更加复杂，因为内核的其他部分可以获得在系统中注册的任何kobject +的引用。 + +最终的结果是，一个由kobject保护的结构体在其引用计数归零之前不能被释放。引 +用计数不受创建kobject的代码的直接控制。因此，每当它的一个kobjects的最后一 +个引用消失时，必须异步通知该代码。 + +一旦你通过kobject_add()注册了你的kobject，你绝对不能使用kfree()来直接释 +放它。唯一安全的方法是使用kobject_put()。在kobject_init()之后总是使用 +kobject_put()以避免错误的发生是一个很好的做法。 + +这个通知是通过kobject的release()方法完成的。通常这样的方法有如下形式:: + + void my_object_release(struct kobject *kobj) + { + struct my_object *mine = container_of(kobj, struct my_object, kobj); + + /* Perform any additional cleanup on this object, then... */ + kfree(mine); + } + +有一点很重要：每个kobject都必须有一个release()方法，而且这个kobject必 +须持续存在（处于一致的状态），直到这个方法被调用。如果这些约束条件没有 +得到满足，那么代码就是有缺陷的。注意，如果你忘记提供release()方法，内 +核会警告你。不要试图通过提供一个“空”的释放函数来摆脱这个警告。 + +如果你的清理函数只需要调用kfree()，那么你必须创建一个包装函数，该函数 +使用container_of()来向上造型到正确的类型（如上面的例子所示），然后在整个 +结构体上调用kfree()。 + +注意，kobject的名字在release函数中是可用的，但它不能在这个回调中被改 +变。否则，在kobject核心中会出现内存泄漏，这让人很不爽。 + +有趣的是，release()方法并不存储在kobject本身；相反，它与ktype相关。 +因此，让我们引入结构体kobj_type:: + + struct kobj_type { + void (*release)(struct kobject *kobj); + const struct sysfs_ops *sysfs_ops; + struct attribute **default_attrs; + const struct attribute_group **default_groups; + const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj); + const void *(*namespace)(struct kobject *kobj); + void (*get_ownership)(struct kobject *kobj, kuid_t *uid, kgid_t *gid); + }; + +这个结构提用来描述一个特定类型的kobject（或者更正确地说，包含对象的 +类型）。每个kobject都需要有一个相关的kobj_type结构；当你调用 +kobject_init()或kobject_init_and_add()时必须指定一个指向该结构的 +指针。 + +当然，kobj_type结构中的release字段是指向这种类型的kobject的release() +方法的一个指针。另外两个字段（sysfs_ops 和 default_attrs）控制这种 +类型的对象如何在 sysfs 中被表示；它们超出了本文的范围。 + +default_attrs 指针是一个默认属性的列表，它将为任何用这个 ktype 注册 +的 kobject 自动创建。 + + +ksets +===== + +一个kset仅仅是一个希望相互关联的kobjects的集合。没有限制它们必须是相 +同的ktype，但是如果它们不是相同的，就要非常小心。 + +一个kset有以下功能: + + - 它像是一个包含一组对象的袋子。一个kset可以被内核用来追踪“所有块 + 设备”或“所有PCI设备驱动”。 + + - kset也是sysfs中的一个子目录，与kset相关的kobjects可以在这里显示 + 出来。每个kset都包含一个kobject，它可以被设置为其他kobject的父对象； + sysfs层次结构的顶级目录就是以这种方式构建的。 + + - Ksets可以支持kobjects的 "热插拔"，并影响uevent事件如何被报告给 + 用户空间。 + + 在面向对象的术语中，“kset”是顶级的容器类；ksets包含它们自己的kobject， + 但是这个kobject是由kset代码管理的，不应该被任何其他用户所操纵。 + + kset在一个标准的内核链表中保存它的子对象。Kobjects通过其kset字段指向其 + 包含的kset。在几乎所有的情况下，属于一个kset的kobjects在它们的父 + 对象中都有那个kset（或者，严格地说，它的嵌入kobject）。 + + 由于kset中包含一个kobject，它应该总是被动态地创建，而不是静态地 + 或在堆栈中声明。要创建一个新的kset，请使用:: + + struct kset *kset_create_and_add(const char *name, + const struct kset_uevent_ops *uevent_ops, + struct kobject *parent_kobj); + +当你完成对kset的处理后，调用:: + + void kset_unregister(struct kset *k); + +来销毁它。这将从sysfs中删除该kset并递减其引用计数值。当引用计数 +为零时，该kset将被释放。因为对该kset的其他引用可能仍然存在， +释放可能发生在kset_unregister()返回之后。 + +一个使用kset的例子可以在内核树中的 ``samples/kobject/kset-example.c`` +文件中看到。 + +如果一个kset希望控制与它相关的kobjects的uevent操作，它可以使用 +结构体kset_uevent_ops来处理它:: + + struct kset_uevent_ops { + int (* const filter)(struct kset *kset, struct kobject *kobj); + const char *(* const name)(struct kset *kset, struct kobject *kobj); + int (* const uevent)(struct kset *kset, struct kobject *kobj, + struct kobj_uevent_env *env); + }; + + +过滤器函数允许kset阻止一个特定kobject的uevent被发送到用户空间。 +如果该函数返回0，该uevent将不会被发射出去。 + +name函数将被调用以覆盖uevent发送到用户空间的kset的默认名称。默 +认情况下，该名称将与kset本身相同，但这个函数，如果存在，可以覆盖 +该名称。 + +当uevent即将被发送至用户空间时，uevent函数将被调用，以允许更多 +的环境变量被添加到uevent中。 + +有人可能会问，鉴于没有提出执行该功能的函数，究竟如何将一个kobject +添加到一个kset中。答案是这个任务是由kobject_add()处理的。当一个 +kobject被传递给kobject_add()时，它的kset成员应该指向这个kobject +所属的kset。 kobject_add()将处理剩下的部分。 + +如果属于一个kset的kobject没有父kobject集，它将被添加到kset的目 +录中。并非所有的kset成员都必须住在kset目录中。如果在添加kobject +之前分配了一个明确的父kobject，那么该kobject将被注册到kset中， +但是被添加到父kobject下面。 + + +移除Kobject +=========== + +当一个kobject在kobject核心注册成功后，在代码使用完它时，必须将其 +清理掉。要做到这一点，请调用kobject_put()。通过这样做，kobject核 +心会自动清理这个kobject分配的所有内存。如果为这个对象发送了 ``KOBJ_ADD`` +uevent，那么相应的 ``KOBJ_REMOVE`` uevent也将被发送，任何其他的 +sysfs内务将被正确处理。 + +如果你需要分两次对kobject进行删除（比如说在你要销毁对象时无权睡眠）， +那么调用kobject_del()将从sysfs中取消kobject的注册。这使得kobject +“不可见”，但它并没有被清理掉，而且该对象的引用计数仍然是一样的。在稍 +后的时间调用kobject_put()来完成与该kobject相关的内存的清理。 + +kobject_del()可以用来放弃对父对象的引用，如果循环引用被构建的话。 +在某些情况下，一个父对象引用一个子对象是有效的。循环引用必须通过明 +确调用kobject_del()来打断，这样一个释放函数就会被调用，前一个循环 +中的对象会相互释放。 + + +示例代码出处 +============ + +关于正确使用ksets和kobjects的更完整的例子，请参见示例程序 +``samples/kobject/{kobject-example.c,kset-example.c}`` ，如果 +您选择 ``CONFIG_SAMPLE_KOBJECT`` ，它们将被构建为可加载模块。 diff --git a/Documentation/translations/zh_CN/core-api/local_ops.rst b/Documentation/translations/zh_CN/core-api/local_ops.rst new file mode 100644 index 000000000000..ee67379b6869 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/local_ops.rst @@ -0,0 +1,194 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/local_ops.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_local_ops: + + +======================== +本地原子操作的语义和行为 +======================== + +:作者: Mathieu Desnoyers + + +本文解释了本地原子操作的目的，如何为任何给定的架构实现这些操作，并说明了 +如何正确使用这些操作。它还强调了在内存写入顺序很重要的情况下，跨CPU读取 +这些本地变量时必须采取的预防措施。 + +.. note:: + + 注意，基于 ``local_t`` 的操作不建议用于一般内核操作。请使用 ``this_cpu`` + 操作来代替使用，除非真的有特殊目的。大多数内核中使用的 ``local_t`` 已 + 经被 ``this_cpu`` 操作所取代。 ``this_cpu`` 操作在一条指令中结合了重 + 定位和类似 ``local_t`` 的语义，产生了更紧凑和更快的执行代码。 + + +本地原子操作的目的 +================== + +本地原子操作的目的是提供快速和高度可重入的每CPU计数器。它们通过移除LOCK前 +缀和通常需要在CPU间同步的内存屏障，将标准原子操作的性能成本降到最低。 + +在许多情况下，拥有快速的每CPU原子计数器是很有吸引力的：它不需要禁用中断来保护中 +断处理程序，它允许在NMI（Non Maskable Interrupt）处理程序中使用连贯的计数器。 +它对追踪目的和各种性能监测计数器特别有用。 + +本地原子操作只保证在拥有数据的CPU上的变量修改的原子性。因此，必须注意确保只 +有一个CPU写到 ``local_t`` 的数据。这是通过使用每CPU的数据来实现的，并确 +保我们在一个抢占式安全上下文中修改它。然而，从任何一个CPU读取 ``local_t`` +数据都是允许的：这样它就会显得与所有者CPU的其他内存写入顺序不一致。 + + +针对特定架构的实现 +================== + +这可以通过稍微修改标准的原子操作来实现：只有它们的UP变体必须被保留。这通常 +意味着删除LOCK前缀（在i386和x86_64上）和任何SMP同步屏障。如果架构在SMP和 +UP之间没有不同的行为，在你的架构的 ``local.h`` 中包括 ``asm-generic/local.h`` +就足够了。 + +通过在一个结构体中嵌入一个 ``atomic_long_t`` ， ``local_t`` 类型被定义为 +一个不透明的 ``signed long`` 。这样做的目的是为了使从这个类型到 +``long`` 的转换失败。该定义看起来像:: + + typedef struct { atomic_long_t a; } local_t; + + +使用本地原子操作时应遵循的规则 +============================== + +* 被本地操作触及的变量必须是每cpu的变量。 + +* *只有* 这些变量的CPU所有者才可以写入这些变量。 + +* 这个CPU可以从任何上下文（进程、中断、软中断、nmi...）中使用本地操作来更新 + 它的local_t变量。 + +* 当在进程上下文中使用本地操作时，必须禁用抢占（或中断），以确保进程在获得每 + CPU变量和进行实际的本地操作之间不会被迁移到不同的CPU。 + +* 当在中断上下文中使用本地操作时，在主线内核上不需要特别注意，因为它们将在局 + 部CPU上运行，并且已经禁用了抢占。然而，我建议无论如何都要明确地禁用抢占， + 以确保它在-rt内核上仍能正确工作。 + +* 读取本地cpu变量将提供该变量的当前拷贝。 + +* 对这些变量的读取可以从任何CPU进行，因为对 “ ``long`` ”，对齐的变量的更新 + 总是原子的。由于写入程序的CPU没有进行内存同步，所以在读取 *其他* cpu的变 + 量时，可以读取该变量的过期副本。 + + +如何使用本地原子操作 +==================== + +:: + + #include <linux/percpu.h> + #include <asm/local.h> + + static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0); + + +计数器 +====== + +计数是在一个signed long的所有位上进行的。 + +在可抢占的上下文中，围绕本地原子操作使用 ``get_cpu_var()`` 和 +``put_cpu_var()`` ：它确保在对每个cpu变量进行写访问时，抢占被禁用。比如 +说:: + + local_inc(&get_cpu_var(counters)); + put_cpu_var(counters); + +如果你已经在一个抢占安全上下文中，你可以使用 ``this_cpu_ptr()`` 代替:: + + local_inc(this_cpu_ptr(&counters)); + + + +读取计数器 +========== + +那些本地计数器可以从外部的CPU中读取，以求得计数的总和。请注意，local_read +所看到的跨CPU的数据必须被认为是相对于拥有该数据的CPU上发生的其他内存写入来 +说不符合顺序的:: + + long sum = 0; + for_each_online_cpu(cpu) + sum += local_read(&per_cpu(counters, cpu)); + +如果你想使用远程local_read来同步CPU之间对资源的访问，必须在写入者和读取者 +的CPU上分别使用显式的 ``smp_wmb()`` 和 ``smp_rmb()`` 内存屏障。如果你使 +用 ``local_t`` 变量作为写在缓冲区中的字节的计数器，就会出现这种情况：在缓 +冲区写和计数器增量之间应该有一个 ``smp_wmb()`` ，在计数器读和缓冲区读之间 +也应有一个 ``smp_rmb()`` 。 + +下面是一个使用 ``local.h`` 实现每个cpu基本计数器的示例模块:: + + /* test-local.c + * + * Sample module for local.h usage. + */ + + + #include <asm/local.h> + #include <linux/module.h> + #include <linux/timer.h> + + static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0); + + static struct timer_list test_timer; + + /* IPI called on each CPU. */ + static void test_each(void *info) + { + /* Increment the counter from a non preemptible context */ + printk("Increment on cpu %d\n", smp_processor_id()); + local_inc(this_cpu_ptr(&counters)); + + /* This is what incrementing the variable would look like within a + * preemptible context (it disables preemption) : + * + * local_inc(&get_cpu_var(counters)); + * put_cpu_var(counters); + */ + } + + static void do_test_timer(unsigned long data) + { + int cpu; + + /* Increment the counters */ + on_each_cpu(test_each, NULL, 1); + /* Read all the counters */ + printk("Counters read from CPU %d\n", smp_processor_id()); + for_each_online_cpu(cpu) { + printk("Read : CPU %d, count %ld\n", cpu, + local_read(&per_cpu(counters, cpu))); + } + mod_timer(&test_timer, jiffies + 1000); + } + + static int __init test_init(void) + { + /* initialize the timer that will increment the counter */ + timer_setup(&test_timer, do_test_timer, 0); + mod_timer(&test_timer, jiffies + 1); + + return 0; + } + + static void __exit test_exit(void) + { + del_timer_sync(&test_timer); + } + + module_init(test_init); + module_exit(test_exit); + + MODULE_LICENSE("GPL"); + MODULE_AUTHOR("Mathieu Desnoyers"); + MODULE_DESCRIPTION("Local Atomic Ops"); diff --git a/Documentation/translations/zh_CN/core-api/padata.rst b/Documentation/translations/zh_CN/core-api/padata.rst new file mode 100644 index 000000000000..c627f8f131f9 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/padata.rst @@ -0,0 +1,158 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/padata.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_core_api_padata.rst: + +================== +padata并行执行机制 +================== + +:日期: 2020年5月 + +Padata是一种机制，内核可以通过此机制将工作分散到多个CPU上并行完成，同时 +可以选择保持它们的顺序。 + +它最初是为IPsec开发的，它需要在不对这些数据包重新排序的其前提下，为大量的数 +据包进行加密和解密。这是目前padata的序列化作业支持的唯一用途。 + +Padata还支持多线程作业，将作业平均分割，同时在线程之间进行负载均衡和协调。 + +执行序列化作业 +============== + +初始化 +------ + +使用padata执行序列化作业的第一步是建立一个padata_instance结构体，以全面 +控制作业的运行方式:: + + #include <linux/padata.h> + + struct padata_instance *padata_alloc(const char *name); + +'name'即标识了这个实例。 + +然后，通过分配一个padata_shell来完成padata的初始化:: + + struct padata_shell *padata_alloc_shell(struct padata_instance *pinst); + +一个padata_shell用于向padata提交一个作业，并允许一系列这样的作业被独立地 +序列化。一个padata_instance可以有一个或多个padata_shell与之相关联，每个 +都允许一系列独立的作业。 + +修改cpumasks +------------ + +用于运行作业的CPU可以通过两种方式改变，通过padata_set_cpumask()编程或通 +过sysfs。前者的定义是:: + + int padata_set_cpumask(struct padata_instance *pinst, int cpumask_type, + cpumask_var_t cpumask); + +这里cpumask_type是PADATA_CPU_PARALLEL（并行）或PADATA_CPU_SERIAL（串行）之一，其中并 +行cpumask描述了哪些处理器将被用来并行执行提交给这个实例的作业，串行cpumask +定义了哪些处理器被允许用作串行化回调处理器。 cpumask指定了要使用的新cpumask。 + +一个实例的cpumasks可能有sysfs文件。例如，pcrypt的文件在 +/sys/kernel/pcrypt/<instance-name>。在一个实例的目录中，有两个文件，parallel_cpumask +和serial_cpumask，任何一个cpumask都可以通过在文件中回显（echo）一个bitmask +来改变，比如说:: + + echo f > /sys/kernel/pcrypt/pencrypt/parallel_cpumask + +读取其中一个文件会显示用户提供的cpumask，它可能与“可用”的cpumask不同。 + +Padata内部维护着两对cpumask，用户提供的cpumask和“可用的”cpumask(每一对由一个 +并行和一个串行cpumask组成)。用户提供的cpumasks在实例分配时默认为所有可能的CPU， +并且可以如上所述进行更改。可用的cpumasks总是用户提供的cpumasks的一个子集，只包 +含用户提供的掩码中的在线CPU；这些是padata实际使用的cpumasks。因此，向padata提 +供一个包含离线CPU的cpumask是合法的。一旦用户提供的cpumask中的一个离线CPU上线， +padata就会使用它。 + +改变CPU掩码的操作代价很高，所以不应频繁更改。 + +运行一个作业 +------------- + +实际上向padata实例提交工作需要创建一个padata_priv结构体，它代表一个作业:: + + struct padata_priv { + /* Other stuff here... */ + void (*parallel)(struct padata_priv *padata); + void (*serial)(struct padata_priv *padata); + }; + +这个结构体几乎肯定会被嵌入到一些针对要做的工作的大结构体中。它的大部分字段对 +padata来说是私有的，但是这个结构在初始化时应该被清零，并且应该提供parallel()和 +serial()函数。在完成工作的过程中，这些函数将被调用，我们马上就会遇到。 + +工作的提交是通过:: + + int padata_do_parallel(struct padata_shell *ps, + struct padata_priv *padata, int *cb_cpu); + +ps和padata结构体必须如上所述进行设置；cb_cpu指向作业完成后用于最终回调的首选CPU； +它必须在当前实例的CPU掩码中（如果不是，cb_cpu指针将被更新为指向实际选择的CPU）。 +padata_do_parallel()的返回值在成功时为0，表示工作正在进行中。-EBUSY意味着有人 +在其他地方正在搞乱实例的CPU掩码，而当cb_cpu不在串行cpumask中、并行或串行cpumasks +中无在线CPU，或实例停止时，则会出现-EINVAL反馈。 + +每个提交给padata_do_parallel()的作业将依次传递给一个CPU上的上述parallel()函数 +的一个调用，所以真正的并行是通过提交多个作业来实现的。parallel()在运行时禁用软 +件中断，因此不能睡眠。parallel()函数把获得的padata_priv结构体指针作为其唯一的参 +数；关于实际要做的工作的信息可能是通过使用container_of()找到封装结构体来获得的。 + +请注意，parallel()没有返回值；padata子系统假定parallel()将从此时开始负责这项工 +作。作业不需要在这次调用中完成，但是，如果parallel()留下了未完成的工作，它应该准 +备在前一个作业完成之前，被以新的作业再次调用 + +序列化作业 +---------- + +当一个作业完成时，parallel()（或任何实际完成该工作的函数）应该通过调用通知padata此 +事:: + + void padata_do_serial(struct padata_priv *padata); + +在未来的某个时刻，padata_do_serial()将触发对padata_priv结构体中serial()函数的调 +用。这个调用将发生在最初要求调用padata_do_parallel()的CPU上；它也是在本地软件中断 +被禁用的情况下运行的。 +请注意，这个调用可能会被推迟一段时间，因为padata代码会努力确保作业按照提交的顺序完 +成。 + +销毁 +---- + +清理一个padata实例时，可以预见的是调用两个free函数，这两个函数对应于分配的逆过程:: + + void padata_free_shell(struct padata_shell *ps); + void padata_free(struct padata_instance *pinst); + +用户有责任确保在调用上述任何一项之前，所有未完成的工作都已完成。 + +运行多线程作业 +============== + +一个多线程作业有一个主线程和零个或多个辅助线程，主线程参与作业，然后等待所有辅助线 +程完成。padata将作业分割成称为chunk的单元，其中chunk是一个线程在一次调用线程函数 +中完成的作业片段。 + +用户必须做三件事来运行一个多线程作业。首先，通过定义一个padata_mt_job结构体来描述 +作业，这在接口部分有解释。这包括一个指向线程函数的指针，padata每次将作业块分配给线 +程时都会调用这个函数。然后，定义线程函数，它接受三个参数： ``start`` 、 ``end`` 和 ``arg`` ， +其中前两个参数限定了线程操作的范围，最后一个是指向作业共享状态的指针，如果有的话。 +准备好共享状态，它通常被分配在主线程的堆栈中。最后，调用padata_do_multithreaded()， +它将在作业完成后返回。 + +接口 +==== + +该API在以下内核代码中: + +include/linux/padata.h + +kernel/padata.c diff --git a/Documentation/translations/zh_CN/core-api/printk-basics.rst b/Documentation/translations/zh_CN/core-api/printk-basics.rst new file mode 100644 index 000000000000..2b20f6303a82 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/printk-basics.rst @@ -0,0 +1,110 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/printk-basics.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_printk-basics.rst: + + +================== +使用printk记录消息 +================== + +printk()是Linux内核中最广为人知的函数之一。它是我们打印消息的标准工具，通常也是追踪和调试 +的最基本方法。如果你熟悉printf(3)，你就能够知道printk()是基于它的，尽管它在功能上有一些不 +同之处: + + - printk() 消息可以指定日志级别。 + + - 格式字符串虽然与C99基本兼容，但并不遵循完全相同的规范。它有一些扩展和一些限制（没 + 有 ``%n`` 或浮点转换指定符）。参见:ref: `如何正确地获得printk格式指定符<printk-specifiers>` 。 + +所有的printk()消息都会被打印到内核日志缓冲区，这是一个通过/dev/kmsg输出到用户空间的环 +形缓冲区。读取它的通常方法是使用 ``dmesg`` 。 + +printk()的用法通常是这样的:: + + printk(KERN_INFO "Message: %s\n", arg); + +其中 ``KERN_INFO`` 是日志级别（注意，它与格式字符串连在一起，日志级别不是一个单独的参数）。 +可用的日志级别是： + + ++----------------+--------+-----------------------------------------------+ +| 名称 | 字符串 | 别名函数 | ++================+========+===============================================+ +| KERN_EMERG | "0" | pr_emerg() | ++----------------+--------+-----------------------------------------------+ +| KERN_ALERT | "1" | pr_alert() | ++----------------+--------+-----------------------------------------------+ +| KERN_CRIT | "2" | pr_crit() | ++----------------+--------+-----------------------------------------------+ +| KERN_ERR | "3" | pr_err() | ++----------------+--------+-----------------------------------------------+ +| KERN_WARNING | "4" | pr_warn() | ++----------------+--------+-----------------------------------------------+ +| KERN_NOTICE | "5" | pr_notice() | ++----------------+--------+-----------------------------------------------+ +| KERN_INFO | "6" | pr_info() | ++----------------+--------+-----------------------------------------------+ +| KERN_DEBUG | "7" | pr_debug() and pr_devel() 若定义了DEBUG | ++----------------+--------+-----------------------------------------------+ +| KERN_DEFAULT | "" | | ++----------------+--------+-----------------------------------------------+ +| KERN_CONT | "c" | pr_cont() | ++----------------+--------+-----------------------------------------------+ + + +日志级别指定了一条消息的重要性。内核根据日志级别和当前 *console_loglevel* （一个内核变量）决 +定是否立即显示消息（将其打印到当前控制台）。如果消息的优先级比 *console_loglevel* 高（日志级 +别值较低），消息将被打印到控制台。 + +如果省略了日志级别，则以 ``KERN_DEFAULT`` 级别打印消息。 + +你可以用以下方法检查当前的 *console_loglevel* :: + + $ cat /proc/sys/kernel/printk + 4 4 1 7 + +结果显示了 *current*, *default*, *minimum* 和 *boot-time-default* 日志级别 + +要改变当前的 console_loglevel，只需在 ``/proc/sys/kernel/printk`` 中写入所需的 +级别。例如，要打印所有的消息到控制台上:: + + # echo 8 > /proc/sys/kernel/printk + +另一种方式，使用 ``dmesg``:: + + # dmesg -n 5 + +设置 console_loglevel 打印 KERN_WARNING (4) 或更严重的消息到控制台。更多消息参 +见 ``dmesg(1)`` 。 + +作为printk()的替代方案，你可以使用 ``pr_*()`` 别名来记录日志。这个系列的宏在宏名中 +嵌入了日志级别。例如:: + + pr_info("Info message no. %d\n", msg_num); + +打印 ``KERN_INFO`` 消息。 + +除了比等效的printk()调用更简洁之外，它们还可以通过pr_fmt()宏为格式字符串使用一个通用 +的定义。例如，在源文件的顶部（在任何 ``#include`` 指令之前）定义这样的内容。:: + + #define pr_fmt(fmt) "%s:%s: " fmt, KBUILD_MODNAME, __func__ + +会在该文件中的每一条 pr_*() 消息前加上发起该消息的模块和函数名称。 + +为了调试，还有两个有条件编译的宏： +pr_debug()和pr_devel()，除非定义了 ``DEBUG`` (或者在pr_debug()的情况下定义了 +``CONFIG_DYNAMIC_DEBUG`` )，否则它们会被编译。 + + +函数接口 +======== + +该API在以下内核代码中: + +kernel/printk/printk.c + +include/linux/printk.h diff --git a/Documentation/translations/zh_CN/core-api/printk-formats.rst b/Documentation/translations/zh_CN/core-api/printk-formats.rst new file mode 100644 index 000000000000..a680c8f164c3 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/printk-formats.rst @@ -0,0 +1,595 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/printk-formats.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_printk-formats.rst: + + +============================== +如何获得正确的printk格式占位符 +============================== + + + +:作者: Randy Dunlap <rdunlap@infradead.org> +:作者: Andrew Murray <amurray@mpc-data.co.uk> + + +整数类型 +======== + +:: + + 若变量类型是Type，则使用printk格式占位符。 + ------------------------------------------- + char %d 或 %x + unsigned char %u 或 %x + short int %d 或 %x + unsigned short int %u 或 %x + int %d 或 %x + unsigned int %u 或 %x + long %ld 或 %lx + unsigned long %lu 或 %lx + long long %lld 或 %llx + unsigned long long %llu 或 %llx + size_t %zu 或 %zx + ssize_t %zd 或 %zx + s8 %d 或 %x + u8 %u 或 %x + s16 %d 或 %x + u16 %u 或 %x + s32 %d 或 %x + u32 %u 或 %x + s64 %lld 或 %llx + u64 %llu 或 %llx + + +如果 <type> 的大小依赖于配置选项 (例如 sector_t, blkcnt_t) 或其大小依赖于架构 +(例如 tcflag_t)，则使用其可能的最大类型的格式占位符并显式强制转换为它。 + +例如 + +:: + + printk("test: sector number/total blocks: %llu/%llu\n", + (unsigned long long)sector, (unsigned long long)blockcount); + +提醒：sizeof()返回类型为size_t。 + +内核的printf不支持%n。显而易见，浮点格式(%e, %f, %g, %a)也不被识别。使用任何不 +支持的占位符或长度限定符都会导致一个WARN并且终止vsnprintf()执行。 + +指针类型 +======== + +一个原始指针值可以用%p打印，它将在打印前对地址进行哈希处理。内核也支持扩展占位符来打印 +不同类型的指针。 + +一些扩展占位符会打印给定地址上的数据，而不是打印地址本身。在这种情况下，以下错误消息可能 +会被打印出来，而不是无法访问的消息:: + + (null) data on plain NULL address + (efault) data on invalid address + (einval) invalid data on a valid address + +普通指针 +---------- + +:: + + %p abcdef12 or 00000000abcdef12 + +没有指定扩展名的指针（即没有修饰符的%p）被哈希（hash），以防止内核内存布局消息的泄露。这 +样还有一个额外的好处，就是提供一个唯一的标识符。在64位机器上，前32位被清零。当没有足够的 +熵进行散列处理时，内核将打印(ptrval)代替 + +如果可能的话，使用专门的修饰符，如%pS或%pB（如下所述），以避免打印一个必须事后解释的非哈 +希地址。如果不可能，而且打印地址的目的是为调试提供更多的消息，使用%p，并在调试过程中 +用 ``no_hash_pointers`` 参数启动内核，这将打印所有未修改的%p地址。如果你 *真的* 想知 +道未修改的地址，请看下面的%px。 + +如果（也只有在）你将地址作为虚拟文件的内容打印出来，例如在procfs或sysfs中（使用 +seq_printf()，而不是printk()）由用户空间进程读取，使用下面描述的%pK修饰符，不 +要用%p或%px。 + + +错误指针 +-------- + +:: + + %pe -ENOSPC + +用于打印错误指针(即IS_ERR()为真的指针)的符号错误名。不知道符号名的错误值会以十进制打印， +而作为%pe参数传递的非ERR_PTR会被视为普通的%p。 + +符号/函数指针 +------------- + +:: + + %pS versatile_init+0x0/0x110 + %ps versatile_init + %pSR versatile_init+0x9/0x110 + (with __builtin_extract_return_addr() translation) + %pB prev_fn_of_versatile_init+0x88/0x88 + + +``S`` 和 ``s`` 占位符用于打印符号格式的指针。它们的结果是符号名称带有(S)或不带有(s)偏移 +量。如果禁用KALLSYMS，则打印符号地址。 + +``B`` 占位符的结果是带有偏移量的符号名，在打印堆栈回溯时应该使用。占位符将考虑编译器优化 +的影响，当使用尾部调用并使用noreturn GCC属性标记时，可能会发生这种优化。 + +如果指针在一个模块内，模块名称和可选的构建ID将被打印在符号名称之后，并在说明符的末尾添加 +一个额外的 ``b`` 。 + +:: + + %pS versatile_init+0x0/0x110 [module_name] + %pSb versatile_init+0x0/0x110 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e] + %pSRb versatile_init+0x9/0x110 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e] + (with __builtin_extract_return_addr() translation) + %pBb prev_fn_of_versatile_init+0x88/0x88 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e] + +来自BPF / tracing追踪的探查指针 +---------------------------------- + +:: + + %pks kernel string + %pus user string + +``k`` 和 ``u`` 指定符用于打印来自内核内存(k)或用户内存(u)的先前探测的内存。后面的 ``s`` 指 +定符的结果是打印一个字符串。对于直接在常规的vsnprintf()中使用时，(k)和(u)注释被忽略，但是，当 +在BPF的bpf_trace_printk()之外使用时，它会读取它所指向的内存，不会出现错误。 + +内核指针 +-------- + +:: + + %pK 01234567 or 0123456789abcdef + +用于打印应该对非特权用户隐藏的内核指针。%pK的行为取决于kptr_restrict sysctl——详见 +Documentation/admin-guide/sysctl/kernel.rst。 + +未经修改的地址 +-------------- + +:: + + %px 01234567 or 0123456789abcdef + +对于打印指针，当你 *真的* 想打印地址时。在用%px打印指针之前，请考虑你是否泄露了内核内 +存布局的敏感消息。%px在功能上等同于%lx（或%lu）。%px是首选，因为它在grep查找时更唯一。 +如果将来我们需要修改内核处理打印指针的方式，我们将能更好地找到调用点。 + +在使用%px之前，请考虑使用%p并在调试过程中启用' ' no_hash_pointer ' '内核参数是否足 +够(参见上面的%p描述)。%px的一个有效场景可能是在panic发生之前立即打印消息，这样无论如何 +都可以防止任何敏感消息被利用，使用%px就不需要用no_hash_pointer来重现panic。 + +指针差异 +-------- + +:: + + %td 2560 + %tx a00 + +为了打印指针的差异，使用ptrdiff_t的%t修饰符。 + +例如:: + + printk("test: difference between pointers: %td\n", ptr2 - ptr1); + +结构体资源（Resources） +----------------------- + +:: + + %pr [mem 0x60000000-0x6fffffff flags 0x2200] or + [mem 0x0000000060000000-0x000000006fffffff flags 0x2200] + %pR [mem 0x60000000-0x6fffffff pref] or + [mem 0x0000000060000000-0x000000006fffffff pref] + +用于打印结构体资源。 ``R`` 和 ``r`` 占位符的结果是打印出的资源带有（R）或不带有（r）解码标志 +成员。 + +通过引用传递。 + +物理地址类型 phys_addr_t +------------------------ + +:: + + %pa[p] 0x01234567 or 0x0123456789abcdef + +用于打印phys_addr_t类型（以及它的衍生物，如resource_size_t），该类型可以根据构建选项而 +变化，无论CPU数据真实物理地址宽度如何。 + +通过引用传递。 + +DMA地址类型dma_addr_t +--------------------- + +:: + + %pad 0x01234567 or 0x0123456789abcdef + +用于打印dma_addr_t类型，该类型可以根据构建选项而变化，而不考虑CPU数据路径的宽度。 + +通过引用传递。 + +原始缓冲区为转义字符串 +---------------------- + +:: + + %*pE[achnops] + +用于将原始缓冲区打印成转义字符串。对于以下缓冲区:: + + 1b 62 20 5c 43 07 22 90 0d 5d + +几个例子展示了如何进行转换（不包括两端的引号）。:: + + %*pE "\eb \C\a"\220\r]" + %*pEhp "\x1bb \C\x07"\x90\x0d]" + %*pEa "\e\142\040\\\103\a\042\220\r\135" + +转换规则是根据可选的标志组合来应用的(详见:c:func:`string_escape_mem` 内核文档): + + - a - ESCAPE_ANY + - c - ESCAPE_SPECIAL + - h - ESCAPE_HEX + - n - ESCAPE_NULL + - o - ESCAPE_OCTAL + - p - ESCAPE_NP + - s - ESCAPE_SPACE + +默认情况下，使用 ESCAPE_ANY_NP。 + +ESCAPE_ANY_NP是许多情况下的明智选择，特别是对于打印SSID。 + +如果字段宽度被省略，那么将只转义1个字节。 + +原始缓冲区为十六进制字符串 +-------------------------- + +:: + + %*ph 00 01 02 ... 3f + %*phC 00:01:02: ... :3f + %*phD 00-01-02- ... -3f + %*phN 000102 ... 3f + +对于打印小的缓冲区（最长64个字节），可以用一定的分隔符作为一个 +十六进制字符串。对于较大的缓冲区，可以考虑使用 +:c:func:`print_hex_dump` 。 + +MAC/FDDI地址 +------------ + +:: + + %pM 00:01:02:03:04:05 + %pMR 05:04:03:02:01:00 + %pMF 00-01-02-03-04-05 + %pm 000102030405 + %pmR 050403020100 + +用于打印以十六进制表示的6字节MAC/FDDI地址。 ``M`` 和 ``m`` 占位符导致打印的 +地址有(M)或没有(m)字节分隔符。默认的字节分隔符是冒号（：）。 + +对于FDDI地址，可以在 ``M`` 占位符之后使用 ``F`` 说明，以使用破折号(——)分隔符 +代替默认的分隔符。 + +对于蓝牙地址， ``R`` 占位符应使用在 ``M`` 占位符之后，以使用反转的字节顺序，适 +合于以小尾端顺序的蓝牙地址的肉眼可见的解析。 + +通过引用传递。 + +IPv4地址 +-------- + +:: + + %pI4 1.2.3.4 + %pi4 001.002.003.004 + %p[Ii]4[hnbl] + +用于打印IPv4点分隔的十进制地址。 ``I4`` 和 ``i4`` 占位符的结果是打印的地址 +有(i4)或没有(I4)前导零。 + +附加的 ``h`` 、 ``n`` 、 ``b`` 和 ``l`` 占位符分别用于指定主机、网络、大 +尾端或小尾端地址。如果没有提供占位符，则使用默认的网络/大尾端顺序。 + +通过引用传递。 + +IPv6 地址 +--------- + +:: + + %pI6 0001:0002:0003:0004:0005:0006:0007:0008 + %pi6 00010002000300040005000600070008 + %pI6c 1:2:3:4:5:6:7:8 + +用于打印IPv6网络顺序的16位十六进制地址。 ``I6`` 和 ``i6`` 占位符的结果是 +打印的地址有(I6)或没有(i6)分号。始终使用前导零。 + +额外的 ``c`` 占位符可与 ``I`` 占位符一起使用，以打印压缩的IPv6地址，如 +https://tools.ietf.org/html/rfc5952 所述 + +通过引用传递。 + +IPv4/IPv6地址(generic, with port, flowinfo, scope) +-------------------------------------------------- + +:: + + %pIS 1.2.3.4 or 0001:0002:0003:0004:0005:0006:0007:0008 + %piS 001.002.003.004 or 00010002000300040005000600070008 + %pISc 1.2.3.4 or 1:2:3:4:5:6:7:8 + %pISpc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345 + %p[Ii]S[pfschnbl] + +用于打印一个IP地址，不需要区分它的类型是AF_INET还是AF_INET6。一个指向有效结构 +体sockaddr的指针，通过 ``IS`` 或 ``IS`` 指定，可以传递给这个格式占位符。 + +附加的 ``p`` 、 ``f`` 和 ``s`` 占位符用于指定port(IPv4, IPv6)、 +flowinfo (IPv6)和sope(IPv6)。port有一个 ``:`` 前缀，flowinfo是 ``/`` 和 +范围是 ``%`` ，每个后面都跟着实际的值。 + +对于IPv6地址，如果指定了额外的指定符 ``c`` ，则使用 +https://tools.ietf.org/html/rfc5952 描述的压缩IPv6地址。 +如https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07 +所建议的，IPv6地址由'['，']'包围，以防止出现额外的占位符 ``p`` ， ``f`` 或 ``s`` 。 + +对于IPv4地址，也可以使用额外的 ``h`` ， ``n`` ， ``b`` 和 ``l`` 说 +明符，但对于IPv6地址则忽略。 + +通过引用传递。 + +更多例子:: + + %pISfc 1.2.3.4 or [1:2:3:4:5:6:7:8]/123456789 + %pISsc 1.2.3.4 or [1:2:3:4:5:6:7:8]%1234567890 + %pISpfc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345/123456789 + +UUID/GUID地址 +------------- + +:: + + %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f + %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F + %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f + %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F + +用于打印16字节的UUID/GUIDs地址。附加的 ``l`` , ``L`` , ``b`` 和 ``B`` 占位符用 +于指定小写(l)或大写(L)十六进制表示法中的小尾端顺序，以及小写(b)或大写(B)十六进制表 +示法中的大尾端顺序。 + +如果没有使用额外的占位符，则将打印带有小写十六进制表示法的默认大端顺序。 + +通过引用传递。 + +目录项（dentry）的名称 +---------------------- + +:: + + %pd{,2,3,4} + %pD{,2,3,4} + +用于打印dentry名称；如果我们用 :c:func:`d_move` 和它比较，名称可能是新旧混合的，但 +不会oops。 %pd dentry比较安全，其相当于我们以前用的%s dentry->d_name.name，%pd<n>打 +印 ``n`` 最后的组件。 %pD对结构文件做同样的事情。 + + +通过引用传递。 + +块设备（block_device）名称 +-------------------------- + +:: + + %pg sda, sda1 or loop0p1 + +用于打印block_device指针的名称。 + +va_format结构体 +--------------- + +:: + + %pV + +用于打印结构体va_format。这些结构包含一个格式字符串 +和va_list如下 + +:: + + struct va_format { + const char *fmt; + va_list *va; + }; + +实现 "递归vsnprintf"。 + +如果没有一些机制来验证格式字符串和va_list参数的正确性，请不要使用这个功能。 + +通过引用传递。 + +设备树节点 +---------- + +:: + + %pOF[fnpPcCF] + + +用于打印设备树节点结构。默认行为相当于%pOFf。 + + - f - 设备节点全称 + - n - 设备节点名 + - p - 设备节点句柄 + - P - 设备节点路径规范(名称+@单位) + - F - 设备节点标志 + - c - 主要兼容字符串 + - C - 全兼容字符串 + +当使用多个参数时，分隔符是':'。 + +例如 + +:: + + %pOF /foo/bar@0 - Node full name + %pOFf /foo/bar@0 - Same as above + %pOFfp /foo/bar@0:10 - Node full name + phandle + %pOFfcF /foo/bar@0:foo,device:--P- - Node full name + + major compatible string + + node flags + D - dynamic + d - detached + P - Populated + B - Populated bus + +通过引用传递。 + +Fwnode handles +-------------- + +:: + + %pfw[fP] + +用于打印fwnode_handles的消息。默认情况下是打印完整的节点名称，包括路径。 +这些修饰符在功能上等同于上面的%pOF。 + + - f - 节点的全名，包括路径。 + - P - 节点名称，包括地址（如果有的话）。 + +例如 (ACPI) + +:: + + %pfwf \_SB.PCI0.CIO2.port@1.endpoint@0 - Full node name + %pfwP endpoint@0 - Node name + +例如 (OF) + +:: + + %pfwf /ocp@68000000/i2c@48072000/camera@10/port/endpoint - Full name + %pfwP endpoint - Node name + +时间和日期 +---------- + +:: + + %pt[RT] YYYY-mm-ddTHH:MM:SS + %pt[RT]s YYYY-mm-dd HH:MM:SS + %pt[RT]d YYYY-mm-dd + %pt[RT]t HH:MM:SS + %pt[RT][dt][r][s] + +用于打印日期和时间:: + + R struct rtc_time structure + T time64_t type + +以我们（人类）可读的格式。 + +默认情况下，年将以1900为单位递增，月将以1为单位递增。 使用%pt[RT]r (raw) +来抑制这种行为。 + +%pt[RT]s（空格）将覆盖ISO 8601的分隔符，在日期和时间之间使用''（空格）而 +不是'T'（大写T）。当日期或时间被省略时，它不会有任何影响。 + +通过引用传递。 + +clk结构体 +--------- + +:: + + %pC pll1 + %pCn pll1 + +用于打印clk结构。%pC 和 %pCn 打印时钟的名称（通用时钟框架）或唯一的32位 +ID（传统时钟框架）。 + +通过引用传递。 + +位图及其衍生物，如cpumask和nodemask +----------------------------------- + +:: + + %*pb 0779 + %*pbl 0,3-6,8-10 + +对于打印位图（bitmap）及其派生的cpumask和nodemask，%*pb输出以字段宽度为位数的位图， +%*pbl输出以字段宽度为位数的范围列表。 + +字段宽度用值传递，位图用引用传递。可以使用辅助宏cpumask_pr_args()和 +nodemask_pr_args()来方便打印cpumask和nodemask。 + +标志位字段，如页标志、gfp_flags +------------------------------- + +:: + + %pGp referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff + %pGg GFP_USER|GFP_DMA32|GFP_NOWARN + %pGv read|exec|mayread|maywrite|mayexec|denywrite + +将flags位字段打印为构造值的符号常量集合。标志的类型由第三个字符给出。目前支持的 +是[p]age flags， [v]ma_flags(都期望 ``unsigned long *`` )和 +[g]fp_flags(期望 ``gfp_t *`` )。标志名称和打印顺序取决于特定的类型。 + +注意，这种格式不应该直接用于跟踪点的:c:func:`TP_printk()` 部分。相反，应使 +用 <trace/events/mmflags.h>中的show_*_flags()函数。 + +通过引用传递。 + +网络设备特性 +------------ + +:: + + %pNF 0x000000000000c000 + +用于打印netdev_features_t。 + +通过引用传递。 + +V4L2和DRM FourCC代码(像素格式) +------------------------------ + +:: + + %p4cc + +打印V4L2或DRM使用的FourCC代码，包括格式端序及其十六进制的数值。 + +通过引用传递。 + +例如:: + + %p4cc BG12 little-endian (0x32314742) + %p4cc Y10 little-endian (0x20303159) + %p4cc NV12 big-endian (0xb231564e) + +谢谢 +==== + +如果您添加了其他%p扩展，请在可行的情况下，用一个或多个测试用例扩展<lib/test_printf.c>。 + +谢谢你的合作和关注。 diff --git a/Documentation/translations/zh_CN/core-api/refcount-vs-atomic.rst b/Documentation/translations/zh_CN/core-api/refcount-vs-atomic.rst new file mode 100644 index 000000000000..ea834e38d2f6 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/refcount-vs-atomic.rst @@ -0,0 +1,154 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/refcount-vs-atomic.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_refcount-vs-atomic: + + +======================================= +与atomic_t相比，refcount_t的API是这样的 +======================================= + +.. contents:: :local: + +简介 +==== + +refcount_t API的目标是为实现对象的引用计数器提供一个最小的API。虽然来自 +lib/refcount.c的独立于架构的通用实现在下面使用了原子操作，但一些 ``refcount_*()`` +和 ``atomic_*()`` 函数在内存顺序保证方面有很多不同。本文档概述了这些差异，并 +提供了相应的例子，以帮助开发者根据这些内存顺序保证的变化来验证他们的代码。 + +本文档中使用的术语尽量遵循tools/memory-model/Documentation/explanation.txt +中定义的正式LKMM。 + +memory-barriers.txt和atomic_t.txt提供了更多关于内存顺序的背景，包括通用的 +和针对原子操作的。 + +内存顺序的相关类型 +================== + +.. note:: 下面的部分只涵盖了本文使用的与原子操作和引用计数器有关的一些内存顺 + 序类型。如果想了解更广泛的情况，请查阅memory-barriers.txt文件。 + +在没有任何内存顺序保证的情况下（即完全无序），atomics和refcounters只提供原 +子性和程序顺序（program order, po）关系（在同一个CPU上）。它保证每个 +``atomic_* ()`` 和 ``refcount_*()`` 操作都是原子性的，指令在单个CPU上按程序 +顺序执行。这是用READ_ONCE()/WRITE_ONCE()和比较并交换原语实现的。 + +强（完全）内存顺序保证在同一CPU上的所有较早加载和存储的指令（所有程序顺序较早 +[po-earlier]指令）在执行任何程序顺序较后指令（po-later）之前完成。它还保证 +同一CPU上储存的程序优先较早的指令和来自其他CPU传播的指令必须在该CPU执行任何 +程序顺序较后指令之前传播到其他CPU（A-累积属性）。这是用smp_mb()实现的。 + +RELEASE内存顺序保证了在同一CPU上所有较早加载和存储的指令（所有程序顺序较早 +指令）在此操作前完成。它还保证同一CPU上储存的程序优先较早的指令和来自其他CPU +传播的指令必须在释放（release）操作之前传播到所有其他CPU（A-累积属性）。这是用 +smp_store_release()实现的。 + +ACQUIRE内存顺序保证了同一CPU上的所有后加载和存储的指令（所有程序顺序较后 +指令）在获取（acquire）操作之后完成。它还保证在获取操作执行后，同一CPU上 +储存的所有程序顺序较后指令必须传播到所有其他CPU。这是用 +smp_acquire__after_ctrl_dep()实现的。 + +对Refcounters的控制依赖（取决于成功）保证了如果一个对象的引用被成功获得（引用计数 +器的增量或增加行为发生了，函数返回true），那么进一步的存储是针对这个操作的命令。对存 +储的控制依赖没有使用任何明确的屏障来实现，而是依赖于CPU不对存储进行猜测。这只是 +一个单一的CPU关系，对其他CPU不提供任何保证。 + + +函数的比较 +========== + +情况1） - 非 “读/修改/写”（RMW）操作 +------------------------------------ + +函数变化: + + * atomic_set() --> refcount_set() + * atomic_read() --> refcount_read() + +内存顺序保证变化: + + * none (两者都是完全无序的) + + +情况2） - 基于增量的操作，不返回任何值 +-------------------------------------- + +函数变化: + + * atomic_inc() --> refcount_inc() + * atomic_add() --> refcount_add() + +内存顺序保证变化: + + * none (两者都是完全无序的) + +情况3） - 基于递减的RMW操作，没有返回值 +--------------------------------------- + +函数变化: + + * atomic_dec() --> refcount_dec() + +内存顺序保证变化: + + * 完全无序的 --> RELEASE顺序 + + +情况4） - 基于增量的RMW操作，返回一个值 +--------------------------------------- + +函数变化: + + * atomic_inc_not_zero() --> refcount_inc_not_zero() + * 无原子性对应函数 --> refcount_add_not_zero() + +内存顺序保证变化: + + * 完全有序的 --> 控制依赖于存储的成功 + +.. note:: 此处 **假设** 了，必要的顺序是作为获得对象指针的结果而提供的。 + + +情况 5） - 基于Dec/Sub递减的通用RMW操作，返回一个值 +--------------------------------------------------- + +函数变化: + + * atomic_dec_and_test() --> refcount_dec_and_test() + * atomic_sub_and_test() --> refcount_sub_and_test() + +内存顺序保证变化: + + * 完全有序的 --> RELEASE顺序 + 成功后ACQUIRE顺序 + + +情况6）其他基于递减的RMW操作，返回一个值 +---------------------------------------- + +函数变化: + + * 无原子性对应函数 --> refcount_dec_if_one() + * ``atomic_add_unless(&var, -1, 1)`` --> ``refcount_dec_not_one(&var)`` + +内存顺序保证变化: + + * 完全有序的 --> RELEASE顺序 + 控制依赖 + +.. note:: atomic_add_unless()只在执行成功时提供完整的顺序。 + + +情况7）--基于锁的RMW +-------------------- + +函数变化: + + * atomic_dec_and_lock() --> refcount_dec_and_lock() + * atomic_dec_and_mutex_lock() --> refcount_dec_and_mutex_lock() + +内存顺序保证变化: + + * 完全有序 --> RELEASE顺序 + 控制依赖 + 持有 diff --git a/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst b/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst new file mode 100644 index 000000000000..ce05c29c7697 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst @@ -0,0 +1,142 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/symbol-namespaces.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_symbol-namespaces.rst: + + +================================= +符号命名空间（Symbol Namespaces） +================================= + +本文档描述了如何使用符号命名空间来构造通过EXPORT_SYMBOL()系列宏导出的内核内符号的导出面。 + +.. 目录 + + === 1 简介 + === 2 如何定义符号命名空间 + --- 2.1 使用EXPORT_SYMBOL宏 + --- 2.2 使用DEFAULT_SYMBOL_NAMESPACE定义 + === 3 如何使用命名空间中导出的符号 + === 4 加载使用命名空间符号的模块 + === 5 自动创建MODULE_IMPORT_NS声明 + +1. 简介 +======= + +符号命名空间已经被引入，作为构造内核内API的导出面的一种手段。它允许子系统维护者将 +他们导出的符号划分进独立的命名空间。这对于文档的编写非常有用（想想SUBSYSTEM_DEBUG +命名空间），也可以限制一组符号在内核其他部分的使用。今后，使用导出到命名空间的符号 +的模块必须导入命名空间。否则，内核将根据其配置，拒绝加载该模块或警告说缺少 +导入。 + +2. 如何定义符号命名空间 +======================= + +符号可以用不同的方法导出到命名空间。所有这些都在改变 EXPORT_SYMBOL 和与之类似的那些宏 +被检测到的方式，以创建 ksymtab 条目。 + +2.1 使用EXPORT_SYMBOL宏 +======================= + +除了允许将内核符号导出到内核符号表的宏EXPORT_SYMBOL()和EXPORT_SYMBOL_GPL()之外， +这些宏的变体还可以将符号导出到某个命名空间：EXPORT_SYMBOL_NS() 和 EXPORT_SYMBOL_NS_GPL()。 +它们需要一个额外的参数：命名空间（the namespace）。请注意，由于宏扩展，该参数需 +要是一个预处理器符号。例如，要把符号 ``usb_stor_suspend`` 导出到命名空间 ``USB_STORAGE``， +请使用:: + + EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE); + +相应的 ksymtab 条目结构体 ``kernel_symbol`` 将有相应的成员 ``命名空间`` 集。 +导出时未指明命名空间的符号将指向 ``NULL`` 。如果没有定义命名空间，则默认没有。 +``modpost`` 和kernel/module.c分别在构建时或模块加载时使用名称空间。 + +2.2 使用DEFAULT_SYMBOL_NAMESPACE定义 +==================================== + +为一个子系统的所有符号定义命名空间可能会非常冗长，并可能变得难以维护。因此，我 +们提供了一个默认定义（DEFAULT_SYMBOL_NAMESPACE），如果设置了这个定义， 它将成 +为所有没有指定命名空间的 EXPORT_SYMBOL() 和 EXPORT_SYMBOL_GPL() 宏扩展的默认 +定义。 + +有多种方法来指定这个定义，使用哪种方法取决于子系统和维护者的喜好。第一种方法是在 +子系统的 ``Makefile`` 中定义默认命名空间。例如，如果要将usb-common中定义的所有符号导 +出到USB_COMMON命名空间，可以在drivers/usb/common/Makefile中添加这样一行:: + + ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=USB_COMMON + +这将影响所有 EXPORT_SYMBOL() 和 EXPORT_SYMBOL_GPL() 语句。当这个定义存在时， +用EXPORT_SYMBOL_NS()导出的符号仍然会被导出到作为命名空间参数传递的命名空间中， +因为这个参数优先于默认的符号命名空间。 + +定义默认命名空间的第二个选项是直接在编译单元中作为预处理声明。上面的例子就会变 +成:: + + #undef DEFAULT_SYMBOL_NAMESPACE + #define DEFAULT_SYMBOL_NAMESPACE USB_COMMON + +应置于相关编译单元中任何 EXPORT_SYMBOL 宏之前 + +3. 如何使用命名空间中导出的符号 +=============================== + +为了使用被导出到命名空间的符号，内核模块需要明确地导入这些命名空间。 +否则内核可能会拒绝加载该模块。模块代码需要使用宏MODULE_IMPORT_NS来 +表示它所使用的命名空间的符号。例如，一个使用usb_stor_suspend符号的 +模块，需要使用如下语句导入命名空间USB_STORAGE:: + + MODULE_IMPORT_NS(USB_STORAGE); + +这将在模块中为每个导入的命名空间创建一个 ``modinfo`` 标签。这也顺带 +使得可以用modinfo检查模块已导入的命名空间:: + + $ modinfo drivers/usb/storage/ums-karma.ko + [...] + import_ns: USB_STORAGE + [...] + + +建议将 MODULE_IMPORT_NS() 语句添加到靠近其他模块元数据定义的地方， +如 MODULE_AUTHOR() 或 MODULE_LICENSE() 。关于自动创建缺失的导入 +语句的方法，请参考第5节。 + +4. 加载使用命名空间符号的模块 +============================= + +在模块加载时（比如 ``insmod`` ），内核将检查每个从模块中引用的符号是否可 +用，以及它可能被导出到的名字空间是否被模块导入。内核的默认行为是拒绝 +加载那些没有指明足以导入的模块。此错误会被记录下来，并且加载将以 +EINVAL方式失败。要允许加载不满足这个前提条件的模块，可以使用此配置选项： +设置 MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=y 将使加载不受影响，但会 +发出警告。 + +5. 自动创建MODULE_IMPORT_NS声明 +=============================== + +缺少命名空间的导入可以在构建时很容易被检测到。事实上，如果一个模块 +使用了一个命名空间的符号而没有导入它，modpost会发出警告。 +MODULE_IMPORT_NS()语句通常会被添加到一个明确的位置（和其他模块元 +数据一起）。为了使模块作者（和子系统维护者）的生活更加轻松，我们提 +供了一个脚本和make目标来修复丢失的导入。修复丢失的导入可以用:: + + $ make nsdeps + +对模块作者来说，以下情况可能很典型:: + + - 编写依赖未导入命名空间的符号的代码 + - ``make`` + - 注意 ``modpost`` 的警告，提醒你有一个丢失的导入。 + - 运行 ``make nsdeps``将导入添加到正确的代码位置。 + +对于引入命名空间的子系统维护者来说，其步骤非常相似。同样，make nsdeps最终将 +为树内模块添加缺失的命名空间导入:: + + - 向命名空间转移或添加符号（例如，使用EXPORT_SYMBOL_NS()）。 + - `make e`（最好是用allmodconfig来覆盖所有的内核模块）。 + - 注意 ``modpost`` 的警告，提醒你有一个丢失的导入。 + - 运行 ``maknsdeps``将导入添加到正确的代码位置。 + +你也可以为外部模块的构建运行nsdeps。典型的用法是:: + + $ make -C <path_to_kernel_src> M=$PWD nsdeps diff --git a/Documentation/translations/zh_CN/core-api/workqueue.rst b/Documentation/translations/zh_CN/core-api/workqueue.rst new file mode 100644 index 000000000000..0b8f730db6c0 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/workqueue.rst @@ -0,0 +1,337 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/workqueue.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_workqueue.rst: + + +========================= +并发管理的工作队列 (cmwq) +========================= + +:日期: September, 2010 +:作者: Tejun Heo <tj@kernel.org> +:作者: Florian Mickler <florian@mickler.org> + + +简介 +==== + +在很多情况下，需要一个异步进程的执行环境，工作队列（wq）API是这种情况下 +最常用的机制。 + +当需要这样一个异步执行上下文时，一个描述将要执行的函数的工作项（work， +即一个待执行的任务）被放在队列中。一个独立的线程作为异步执行环境。该队 +列被称为workqueue，线程被称为工作者（worker，即执行这一队列的线程）。 + +当工作队列上有工作项时，工作者会一个接一个地执行与工作项相关的函数。当 +工作队列中没有任何工作项时，工作者就会变得空闲。当一个新的工作项被排入 +队列时，工作者又开始执行。 + + +为什么要cmwq? +============= + +在最初的wq实现中，多线程（MT）wq在每个CPU上有一个工作者线程，而单线程 +（ST）wq在全系统有一个工作者线程。一个MT wq需要保持与CPU数量相同的工 +作者数量。这些年来，内核增加了很多MT wq的用户，随着CPU核心数量的不断 +增加，一些系统刚启动就达到了默认的32k PID的饱和空间。 + +尽管MT wq浪费了大量的资源，但所提供的并发性水平却不能令人满意。这个限 +制在ST和MT wq中都有，只是在MT中没有那么严重。每个wq都保持着自己独立的 +工作者池。一个MT wq只能为每个CPU提供一个执行环境，而一个ST wq则为整个 +系统提供一个。工作项必须竞争这些非常有限的执行上下文，从而导致各种问题， +包括在单一执行上下文周围容易发生死锁。 + +(MT wq)所提供的并发性水平和资源使用之间的矛盾也迫使其用户做出不必要的权衡，比 +如libata选择使用ST wq来轮询PIO，并接受一个不必要的限制，即没有两个轮 +询PIO可以同时进行。由于MT wq并没有提供更好的并发性，需要更高层次的并 +发性的用户，如async或fscache，不得不实现他们自己的线程池。 + +并发管理工作队列（cmwq）是对wq的重新实现，重点是以下目标。 + +* 保持与原始工作队列API的兼容性。 + +* 使用由所有wq共享的每CPU统一的工作者池，在不浪费大量资源的情况下按 +* 需提供灵活的并发水平。 + +* 自动调节工作者池和并发水平，使API用户不需要担心这些细节。 + + +设计 +==== + +为了简化函数的异步执行，引入了一个新的抽象概念，即工作项。 + +一个工作项是一个简单的结构，它持有一个指向将被异步执行的函数的指针。 +每当一个驱动程序或子系统希望一个函数被异步执行时，它必须建立一个指 +向该函数的工作项，并在工作队列中排队等待该工作项。（就是挂到workqueue +队列里面去） + +特定目的线程，称为工作线程（工作者），一个接一个地执行队列中的功能。 +如果没有工作项排队，工作者线程就会闲置。这些工作者线程被管理在所谓 +的工作者池中。 + +cmwq设计区分了面向用户的工作队列，子系统和驱动程序在上面排队工作， +以及管理工作者池和处理排队工作项的后端机制。 + +每个可能的CPU都有两个工作者池，一个用于正常的工作项，另一个用于高 +优先级的工作项，还有一些额外的工作者池，用于服务未绑定工作队列的工 +作项目——这些后备池的数量是动态的。 + +当他们认为合适的时候，子系统和驱动程序可以通过特殊的 +``workqueue API`` 函数创建和排队工作项。他们可以通过在工作队列上 +设置标志来影响工作项执行方式的某些方面，他们把工作项放在那里。这些 +标志包括诸如CPU定位、并发限制、优先级等等。要获得详细的概述，请参 +考下面的 ``alloc_workqueue()`` 的 API 描述。 + +当一个工作项被排入一个工作队列时，目标工作池将根据队列参数和工作队 +列属性确定，并被附加到工作池的共享工作列表上。例如，除非特别重写， +否则一个绑定的工作队列的工作项将被排在与发起线程运行的CPU相关的普 +通或高级工作工作者池的工作项列表中。 + +对于任何工作者池的实施，管理并发水平（有多少执行上下文处于活动状 +态）是一个重要问题。最低水平是为了节省资源，而饱和水平是指系统被 +充分使用。 + +每个与实际CPU绑定的worker-pool通过钩住调度器来实现并发管理。每当 +一个活动的工作者被唤醒或睡眠时，工作者池就会得到通知，并跟踪当前可 +运行的工作者的数量。一般来说，工作项不会占用CPU并消耗很多周期。这 +意味着保持足够的并发性以防止工作处理停滞应该是最优的。只要CPU上有 +一个或多个可运行的工作者，工作者池就不会开始执行新的工作，但是，当 +最后一个运行的工作者进入睡眠状态时，它会立即安排一个新的工作者，这 +样CPU就不会在有待处理的工作项目时闲置。这允许在不损失执行带宽的情 +况下使用最少的工作者。 + +除了kthreads的内存空间外，保留空闲的工作者并没有其他成本，所以cmwq +在杀死它们之前会保留一段时间的空闲。 + +对于非绑定的工作队列，后备池的数量是动态的。可以使用 +``apply_workqueue_attrs()`` 为非绑定工作队列分配自定义属性， +workqueue将自动创建与属性相匹配的后备工作者池。调节并发水平的责任在 +用户身上。也有一个标志可以将绑定的wq标记为忽略并发管理。 +详情请参考API部分。 + +前进进度的保证依赖于当需要更多的执行上下文时可以创建工作者，这也是 +通过使用救援工作者来保证的。所有可能在处理内存回收的代码路径上使用 +的工作项都需要在wq上排队，wq上保留了一个救援工作者，以便在内存有压 +力的情况下下执行。否则，工作者池就有可能出现死锁，等待执行上下文释 +放出来。 + + +应用程序编程接口 (API) +====================== + +``alloc_workqueue()`` 分配了一个wq。原来的 ``create_*workqueue()`` +函数已被废弃，并计划删除。 ``alloc_workqueue()`` 需要三个 +参数 - ``@name`` , ``@flags`` 和 ``@max_active`` 。 +``@name`` 是wq的名称，如果有的话，也用作救援线程的名称。 + +一个wq不再管理执行资源，而是作为前进进度保证、刷新(flush)和 +工作项属性的域。 ``@flags`` 和 ``@max_active`` 控制着工作 +项如何被分配执行资源、安排和执行。 + + +``flags`` +--------- + +``WQ_UNBOUND`` + 排队到非绑定wq的工作项由特殊的工作者池提供服务，这些工作者不 + 绑定在任何特定的CPU上。这使得wq表现得像一个简单的执行环境提 + 供者，没有并发管理。非绑定工作者池试图尽快开始执行工作项。非 + 绑定的wq牺牲了局部性，但在以下情况下是有用的。 + + * 预计并发水平要求会有很大的波动，使用绑定的wq最终可能会在不 + 同的CPU上产生大量大部分未使用的工作者，因为发起线程在不同 + 的CPU上跳转。 + + * 长期运行的CPU密集型工作负载，可以由系统调度器更好地管理。 + +``WQ_FREEZABLE`` + 一个可冻结的wq参与了系统暂停操作的冻结阶段。wq上的工作项被 + 排空，在解冻之前没有新的工作项开始执行。 + +``WQ_MEM_RECLAIM`` + 所有可能在内存回收路径中使用的wq都必须设置这个标志。无论内 + 存压力如何，wq都能保证至少有一个执行上下文。 + +``WQ_HIGHPRI`` + 高优先级wq的工作项目被排到目标cpu的高优先级工作者池中。高 + 优先级的工作者池由具有较高级别的工作者线程提供服务。 + + 请注意，普通工作者池和高优先级工作者池之间并不相互影响。他 + 们各自维护其独立的工作者池，并在其工作者之间实现并发管理。 + +``WQ_CPU_INTENSIVE`` + CPU密集型wq的工作项对并发水平没有贡献。换句话说，可运行的 + CPU密集型工作项不会阻止同一工作者池中的其他工作项开始执行。 + 这对于那些预计会占用CPU周期的绑定工作项很有用，这样它们的 + 执行就会受到系统调度器的监管。 + + 尽管CPU密集型工作项不会对并发水平做出贡献，但它们的执行开 + 始仍然受到并发管理的管制，可运行的非CPU密集型工作项会延迟 + CPU密集型工作项的执行。 + + 这个标志对于未绑定的wq来说是没有意义的。 + +请注意，标志 ``WQ_NON_REENTRANT`` 不再存在，因为现在所有的工作 +队列都是不可逆的——任何工作项都保证在任何时间内最多被整个系统的一 +个工作者执行。 + + +``max_active`` +-------------- + +``@max_active`` 决定了每个CPU可以分配给wq的工作项的最大执行上 +下文数量。例如，如果 ``@max_active为16`` ，每个CPU最多可以同 +时执行16个wq的工作项。 + +目前，对于一个绑定的wq， ``@max_active`` 的最大限制是512，当指 +定为0时使用的默认值是256。对于非绑定的wq，其限制是512和 +4 * ``num_possible_cpus()`` 中的较高值。这些值被选得足够高，所 +以它们不是限制性因素，同时会在失控情况下提供保护。 + +一个wq的活动工作项的数量通常由wq的用户来调节，更具体地说，是由用 +户在同一时间可以排列多少个工作项来调节。除非有特定的需求来控制活动 +工作项的数量，否则建议指定 为"0"。 + +一些用户依赖于ST wq的严格执行顺序。 ``@max_active`` 为1和 ``WQ_UNBOUND`` +的组合用来实现这种行为。这种wq上的工作项目总是被排到未绑定的工作池 +中，并且在任何时候都只有一个工作项目处于活动状态，从而实现与ST wq相 +同的排序属性。 + +在目前的实现中，上述配置只保证了特定NUMA节点内的ST行为。相反， +``alloc_ordered_queue()`` 应该被用来实现全系统的ST行为。 + + +执行场景示例 +============ + +下面的示例执行场景试图说明cmwq在不同配置下的行为。 + + 工作项w0、w1、w2被排到同一个CPU上的一个绑定的wq q0上。w0 + 消耗CPU 5ms，然后睡眠10ms，然后在完成之前再次消耗CPU 5ms。 + +忽略所有其他的任务、工作和处理开销，并假设简单的FIFO调度， +下面是一个高度简化的原始wq的可能事件序列的版本。:: + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 starts and burns CPU + 25 w1 sleeps + 35 w1 wakes up and finishes + 35 w2 starts and burns CPU + 40 w2 sleeps + 50 w2 wakes up and finishes + +And with cmwq with ``@max_active`` >= 3, :: + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 5 w1 starts and burns CPU + 10 w1 sleeps + 10 w2 starts and burns CPU + 15 w2 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 wakes up and finishes + 25 w2 wakes up and finishes + +如果 ``@max_active`` == 2, :: + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 5 w1 starts and burns CPU + 10 w1 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 wakes up and finishes + 20 w2 starts and burns CPU + 25 w2 sleeps + 35 w2 wakes up and finishes + +现在，我们假设w1和w2被排到了不同的wq q1上，这个wq q1 +有 ``WQ_CPU_INTENSIVE`` 设置:: + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 5 w1 and w2 start and burn CPU + 10 w1 sleeps + 15 w2 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 wakes up and finishes + 25 w2 wakes up and finishes + + +指南 +==== + +* 如果一个wq可能处理在内存回收期间使用的工作项目，请不 + 要忘记使用 ``WQ_MEM_RECLAIM`` 。每个设置了 + ``WQ_MEM_RECLAIM`` 的wq都有一个为其保留的执行环境。 + 如果在内存回收过程中使用的多个工作项之间存在依赖关系， + 它们应该被排在不同的wq中，每个wq都有 ``WQ_MEM_RECLAIM`` 。 + +* 除非需要严格排序，否则没有必要使用ST wq。 + +* 除非有特殊需要，建议使用0作为@max_active。在大多数使用情 + 况下，并发水平通常保持在默认限制之下。 + +* 一个wq作为前进进度保证（WQ_MEM_RECLAIM，冲洗（flush）和工 + 作项属性的域。不涉及内存回收的工作项，不需要作为工作项组的一 + 部分被刷新，也不需要任何特殊属性，可以使用系统中的一个wq。使 + 用专用wq和系统wq在执行特性上没有区别。 + +* 除非工作项预计会消耗大量的CPU周期，否则使用绑定的wq通常是有 + 益的，因为wq操作和工作项执行中的定位水平提高了。 + + +调试 +==== + +因为工作函数是由通用的工作者线程执行的，所以需要一些手段来揭示一些行为不端的工作队列用户。 + +工作者线程在进程列表中显示为: :: + + root 5671 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/0:1] + root 5672 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/1:2] + root 5673 0.0 0.0 0 0 ? S 12:12 0:00 [kworker/0:0] + root 5674 0.0 0.0 0 0 ? S 12:13 0:00 [kworker/1:0] + +如果kworkers失控了（使用了太多的cpu），有两类可能的问题: + + 1. 正在迅速调度的事情 + 2. 一个消耗大量cpu周期的工作项。 + +第一个可以用追踪的方式进行跟踪: :: + + $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace_pipe > out.txt + (wait a few secs) + +如果有什么东西在工作队列上忙着做循环，它就会主导输出，可以用工作项函数确定违规者。 + +对于第二类问题，应该可以只检查违规工作者线程的堆栈跟踪。 :: + + $ cat /proc/THE_OFFENDING_KWORKER/stack + +工作项函数在堆栈追踪中应该是微不足道的。 + + +内核内联文档参考 +================ + +该API在以下内核代码中: + +include/linux/workqueue.h + +kernel/workqueue.c diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst index fd73c479917b..e6c99f2f543f 100644 --- a/Documentation/translations/zh_CN/dev-tools/index.rst +++ b/Documentation/translations/zh_CN/dev-tools/index.rst @@ -19,13 +19,13 @@ :maxdepth: 2 gcov + kasan Todolist: - coccinelle - sparse - kcov - - kasan - ubsan - kmemleak - kcsan diff --git a/Documentation/translations/zh_CN/dev-tools/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst new file mode 100644 index 000000000000..23db9d419047 --- /dev/null +++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst @@ -0,0 +1,417 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/dev-tools/kasan.rst +:Translator: 万家兵 Wan Jiabing <wanjiabing@vivo.com> + +内核地址消毒剂(KASAN) +===================== + +概述 +---- + +KernelAddressSANitizer(KASAN)是一种动态内存安全错误检测工具，主要功能是 +检查内存越界访问和使用已释放内存的问题。KASAN有三种模式: + +1. 通用KASAN（与用户空间的ASan类似） +2. 基于软件标签的KASAN（与用户空间的HWASan类似） +3. 基于硬件标签的KASAN（基于硬件内存标签） + +由于通用KASAN的内存开销较大，通用KASAN主要用于调试。基于软件标签的KASAN +可用于dogfood测试，因为它具有较低的内存开销，并允许将其用于实际工作量。 +基于硬件标签的KASAN具有较低的内存和性能开销，因此可用于生产。同时可用于 +检测现场内存问题或作为安全缓解措施。 + +软件KASAN模式（#1和#2）使用编译时工具在每次内存访问之前插入有效性检查， +因此需要一个支持它的编译器版本。 + +通用KASAN在GCC和Clang受支持。GCC需要8.3.0或更高版本。任何受支持的Clang +版本都是兼容的，但从Clang 11才开始支持检测全局变量的越界访问。 + +基于软件标签的KASAN模式仅在Clang中受支持。 + +硬件KASAN模式（#3）依赖硬件来执行检查，但仍需要支持内存标签指令的编译器 +版本。GCC 10+和Clang 11+支持此模式。 + +两种软件KASAN模式都适用于SLUB和SLAB内存分配器，而基于硬件标签的KASAN目前 +仅支持SLUB。 + +目前x86_64、arm、arm64、xtensa、s390、riscv架构支持通用KASAN模式，仅 +arm64架构支持基于标签的KASAN模式。 + +用法 +---- + +要启用KASAN，请使用以下命令配置内核:: + + CONFIG_KASAN=y + +同时在 ``CONFIG_KASAN_GENERIC`` (启用通用KASAN模式)， ``CONFIG_KASAN_SW_TAGS`` +(启用基于硬件标签的KASAN模式)，和 ``CONFIG_KASAN_HW_TAGS`` (启用基于硬件标签 +的KASAN模式)之间进行选择。 + +对于软件模式，还可以在 ``CONFIG_KASAN_OUTLINE`` 和 ``CONFIG_KASAN_INLINE`` +之间进行选择。outline和inline是编译器插桩类型。前者产生较小的二进制文件， +而后者快1.1-2倍。 + +要将受影响的slab对象的alloc和free堆栈跟踪包含到报告中，请启用 +``CONFIG_STACKTRACE`` 。要包括受影响物理页面的分配和释放堆栈跟踪的话， +请启用 ``CONFIG_PAGE_OWNER`` 并使用 ``page_owner=on`` 进行引导。 + +错误报告 +~~~~~~~~ + +典型的KASAN报告如下所示:: + + ================================================================== + BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan] + Write of size 1 at addr ffff8801f44ec37b by task insmod/2760 + + CPU: 1 PID: 2760 Comm: insmod Not tainted 4.19.0-rc3+ #698 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 + Call Trace: + dump_stack+0x94/0xd8 + print_address_description+0x73/0x280 + kasan_report+0x144/0x187 + __asan_report_store1_noabort+0x17/0x20 + kmalloc_oob_right+0xa8/0xbc [test_kasan] + kmalloc_tests_init+0x16/0x700 [test_kasan] + do_one_initcall+0xa5/0x3ae + do_init_module+0x1b6/0x547 + load_module+0x75df/0x8070 + __do_sys_init_module+0x1c6/0x200 + __x64_sys_init_module+0x6e/0xb0 + do_syscall_64+0x9f/0x2c0 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + RIP: 0033:0x7f96443109da + RSP: 002b:00007ffcf0b51b08 EFLAGS: 00000202 ORIG_RAX: 00000000000000af + RAX: ffffffffffffffda RBX: 000055dc3ee521a0 RCX: 00007f96443109da + RDX: 00007f96445cff88 RSI: 0000000000057a50 RDI: 00007f9644992000 + RBP: 000055dc3ee510b0 R08: 0000000000000003 R09: 0000000000000000 + R10: 00007f964430cd0a R11: 0000000000000202 R12: 00007f96445cff88 + R13: 000055dc3ee51090 R14: 0000000000000000 R15: 0000000000000000 + + Allocated by task 2760: + save_stack+0x43/0xd0 + kasan_kmalloc+0xa7/0xd0 + kmem_cache_alloc_trace+0xe1/0x1b0 + kmalloc_oob_right+0x56/0xbc [test_kasan] + kmalloc_tests_init+0x16/0x700 [test_kasan] + do_one_initcall+0xa5/0x3ae + do_init_module+0x1b6/0x547 + load_module+0x75df/0x8070 + __do_sys_init_module+0x1c6/0x200 + __x64_sys_init_module+0x6e/0xb0 + do_syscall_64+0x9f/0x2c0 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + + Freed by task 815: + save_stack+0x43/0xd0 + __kasan_slab_free+0x135/0x190 + kasan_slab_free+0xe/0x10 + kfree+0x93/0x1a0 + umh_complete+0x6a/0xa0 + call_usermodehelper_exec_async+0x4c3/0x640 + ret_from_fork+0x35/0x40 + + The buggy address belongs to the object at ffff8801f44ec300 + which belongs to the cache kmalloc-128 of size 128 + The buggy address is located 123 bytes inside of + 128-byte region [ffff8801f44ec300, ffff8801f44ec380) + The buggy address belongs to the page: + page:ffffea0007d13b00 count:1 mapcount:0 mapping:ffff8801f7001640 index:0x0 + flags: 0x200000000000100(slab) + raw: 0200000000000100 ffffea0007d11dc0 0000001a0000001a ffff8801f7001640 + raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000 + page dumped because: kasan: bad access detected + + Memory state around the buggy address: + ffff8801f44ec200: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb + ffff8801f44ec280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc + >ffff8801f44ec300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 + ^ + ffff8801f44ec380: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb + ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc + ================================================================== + +报告标题总结了发生的错误类型以及导致该错误的访问类型。紧随其后的是错误访问的 +堆栈跟踪、所访问内存分配位置的堆栈跟踪（对于访问了slab对象的情况）以及对象 +被释放的位置的堆栈跟踪（对于访问已释放内存的问题报告）。接下来是对访问的 +slab对象的描述以及关于访问的内存页的信息。 + +最后，报告展示了访问地址周围的内存状态。在内部，KASAN单独跟踪每个内存颗粒的 +内存状态，根据KASAN模式分为8或16个对齐字节。报告的内存状态部分中的每个数字 +都显示了围绕访问地址的其中一个内存颗粒的状态。 + +对于通用KASAN，每个内存颗粒的大小为8个字节。每个颗粒的状态被编码在一个影子字节 +中。这8个字节可以是可访问的，部分访问的，已释放的或成为Redzone的一部分。KASAN +对每个影子字节使用以下编码:00表示对应内存区域的所有8个字节都可以访问；数字N +(1 <= N <= 7)表示前N个字节可访问，其他(8 - N)个字节不可访问；任何负值都表示 +无法访问整个8字节。KASAN使用不同的负值来区分不同类型的不可访问内存，如redzones +或已释放的内存（参见 mm/kasan/kasan.h）。 + +在上面的报告中，箭头指向影子字节 ``03`` ，表示访问的地址是部分可访问的。 + +对于基于标签的KASAN模式，报告最后的部分显示了访问地址周围的内存标签 +(参考 `实施细则`_ 章节)。 + +请注意，KASAN错误标题（如 ``slab-out-of-bounds`` 或 ``use-after-free`` ） +是尽量接近的:KASAN根据其拥有的有限信息打印出最可能的错误类型。错误的实际类型 +可能会有所不同。 + +通用KASAN还报告两个辅助调用堆栈跟踪。这些堆栈跟踪指向代码中与对象交互但不直接 +出现在错误访问堆栈跟踪中的位置。目前，这包括 call_rcu() 和排队的工作队列。 + +启动参数 +~~~~~~~~ + +KASAN受通用 ``panic_on_warn`` 命令行参数的影响。启用该功能后，KASAN在打印错误 +报告后会引起内核恐慌。 + +默认情况下，KASAN只为第一次无效内存访问打印错误报告。使用 ``kasan_multi_shot`` ， +KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告的 ``panic_on_warn`` 。 + +基于硬件标签的KASAN模式（请参阅下面有关各种模式的部分）旨在在生产中用作安全缓解 +措施。因此，它支持允许禁用KASAN或控制其功能的引导参数。 + +- ``kasan=off`` 或 ``=on`` 控制KASAN是否启用 (默认: ``on`` )。 + +- ``kasan.mode=sync`` 或 ``=async`` 控制KASAN是否配置为同步或异步执行模式(默认: + ``sync`` )。同步模式：当标签检查错误发生时，立即检测到错误访问。异步模式： + 延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的 + TFSR_EL1寄存器中）。内核会定期检查硬件，并且仅在这些检查期间报告标签错误。 + +- ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用alloc和free堆栈跟踪收集 + (默认: ``on`` )。 + +- ``kasan.fault=report`` 或 ``=panic`` 控制是只打印KASAN报告还是同时使内核恐慌 + (默认: ``report`` )。即使启用了 ``kasan_multi_shot`` ，也会发生内核恐慌。 + +实施细则 +-------- + +通用KASAN +~~~~~~~~~ + +软件KASAN模式使用影子内存来记录每个内存字节是否可以安全访问，并使用编译时工具 +在每次内存访问之前插入影子内存检查。 + +通用KASAN将1/8的内核内存专用于其影子内存（16TB以覆盖x86_64上的128TB），并使用 +具有比例和偏移量的直接映射将内存地址转换为其相应的影子地址。 + +这是将地址转换为其相应影子地址的函数:: + + static inline void *kasan_mem_to_shadow(const void *addr) + { + return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT) + + KASAN_SHADOW_OFFSET; + } + +在这里 ``KASAN_SHADOW_SCALE_SHIFT = 3`` 。 + +编译时工具用于插入内存访问检查。编译器在每次访问大小为1、2、4、8或16的内存之前 +插入函数调用( ``__asan_load*(addr)`` , ``__asan_store*(addr)``)。这些函数通过 +检查相应的影子内存来检查内存访问是否有效。 + +使用inline插桩，编译器不进行函数调用，而是直接插入代码来检查影子内存。此选项 +显著地增大了内核体积，但与outline插桩内核相比，它提供了x1.1-x2的性能提升。 + +通用KASAN是唯一一种通过隔离延迟重新使用已释放对象的模式 +（参见 mm/kasan/quarantine.c 以了解实现）。 + +基于软件标签的KASAN模式 +~~~~~~~~~~~~~~~~~~~~~~~ + +基于软件标签的KASAN使用软件内存标签方法来检查访问有效性。目前仅针对arm64架构实现。 + +基于软件标签的KASAN使用arm64 CPU的顶部字节忽略(TBI)特性在内核指针的顶部字节中 +存储一个指针标签。它使用影子内存来存储与每个16字节内存单元相关的内存标签(因此， +它将内核内存的1/16专用于影子内存)。 + +在每次内存分配时，基于软件标签的KASAN都会生成一个随机标签，用这个标签标记分配 +的内存，并将相同的标签嵌入到返回的指针中。 + +基于软件标签的KASAN使用编译时工具在每次内存访问之前插入检查。这些检查确保正在 +访问的内存的标签等于用于访问该内存的指针的标签。如果标签不匹配，基于软件标签 +的KASAN会打印错误报告。 + +基于软件标签的KASAN也有两种插桩模式（outline，发出回调来检查内存访问；inline， +执行内联的影子内存检查）。使用outline插桩模式，会从执行访问检查的函数打印错误 +报告。使用inline插桩，编译器会发出 ``brk`` 指令，并使用专用的 ``brk`` 处理程序 +来打印错误报告。 + +基于软件标签的KASAN使用0xFF作为匹配所有指针标签（不检查通过带有0xFF指针标签 +的指针进行的访问）。值0xFE当前保留用于标记已释放的内存区域。 + +基于软件标签的KASAN目前仅支持对Slab和page_alloc内存进行标记。 + +基于硬件标签的KASAN模式 +~~~~~~~~~~~~~~~~~~~~~~~ + +基于硬件标签的KASAN在概念上类似于软件模式，但它是使用硬件内存标签作为支持而 +不是编译器插桩和影子内存。 + +基于硬件标签的KASAN目前仅针对arm64架构实现，并且基于ARMv8.5指令集架构中引入 +的arm64内存标记扩展(MTE)和最高字节忽略(TBI)。 + +特殊的arm64指令用于为每次内存分配指定内存标签。相同的标签被指定给指向这些分配 +的指针。在每次内存访问时，硬件确保正在访问的内存的标签等于用于访问该内存的指针 +的标签。如果标签不匹配，则会生成故障并打印报告。 + +基于硬件标签的KASAN使用0xFF作为匹配所有指针标签（不检查通过带有0xFF指针标签的 +指针进行的访问）。值0xFE当前保留用于标记已释放的内存区域。 + +基于硬件标签的KASAN目前仅支持对Slab和page_alloc内存进行标记。 + +如果硬件不支持MTE（ARMv8.5之前），则不会启用基于硬件标签的KASAN。在这种情况下， +所有KASAN引导参数都将被忽略。 + +请注意，启用CONFIG_KASAN_HW_TAGS始终会导致启用内核中的TBI。即使提供了 +``kasan.mode=off`` 或硬件不支持MTE（但支持TBI）。 + +基于硬件标签的KASAN只报告第一个发现的错误。之后，MTE标签检查将被禁用。 + +影子内存 +-------- + +内核将内存映射到地址空间的几个不同部分。内核虚拟地址的范围很大：没有足够的真实 +内存来支持内核可以访问的每个地址的真实影子区域。因此，KASAN只为地址空间的某些 +部分映射真实的影子。 + +默认行为 +~~~~~~~~ + +默认情况下，体系结构仅将实际内存映射到用于线性映射的阴影区域（以及可能的其他 +小区域）。对于所有其他区域 —— 例如vmalloc和vmemmap空间 —— 一个只读页面被映射 +到阴影区域上。这个只读的影子页面声明所有内存访问都是允许的。 + +这给模块带来了一个问题：它们不存在于线性映射中，而是存在于专用的模块空间中。 +通过连接模块分配器，KASAN临时映射真实的影子内存以覆盖它们。例如，这允许检测 +对模块全局变量的无效访问。 + +这也造成了与 ``VMAP_STACK`` 的不兼容：如果堆栈位于vmalloc空间中，它将被分配 +只读页面的影子内存，并且内核在尝试为堆栈变量设置影子数据时会出错。 + +CONFIG_KASAN_VMALLOC +~~~~~~~~~~~~~~~~~~~~ + +使用 ``CONFIG_KASAN_VMALLOC`` ，KASAN可以以更大的内存使用为代价覆盖vmalloc +空间。目前，这在x86、riscv、s390和powerpc上受支持。 + +这通过连接到vmalloc和vmap并动态分配真实的影子内存来支持映射。 + +vmalloc空间中的大多数映射都很小，需要不到一整页的阴影空间。因此，为每个映射 +分配一个完整的影子页面将是一种浪费。此外，为了确保不同的映射使用不同的影子 +页面，映射必须与 ``KASAN_GRANULE_SIZE * PAGE_SIZE`` 对齐。 + +相反，KASAN跨多个映射共享后备空间。当vmalloc空间中的映射使用影子区域的特定 +页面时，它会分配一个后备页面。此页面稍后可以由其他vmalloc映射共享。 + +KASAN连接到vmap基础架构以懒清理未使用的影子内存。 + +为了避免交换映射的困难，KASAN预测覆盖vmalloc空间的阴影区域部分将不会被早期 +的阴影页面覆盖，但是将不会被映射。这将需要更改特定于arch的代码。 + +这允许在x86上支持 ``VMAP_STACK`` ，并且可以简化对没有固定模块区域的架构的支持。 + +对于开发者 +---------- + +忽略访问 +~~~~~~~~ + +软件KASAN模式使用编译器插桩来插入有效性检查。此类检测可能与内核的某些部分 +不兼容，因此需要禁用。 + +内核的其他部分可能会访问已分配对象的元数据。通常，KASAN会检测并报告此类访问， +但在某些情况下（例如，在内存分配器中），这些访问是有效的。 + +对于软件KASAN模式，要禁用特定文件或目录的检测，请将 ``KASAN_SANITIZE`` 添加 +到相应的内核Makefile中: + +- 对于单个文件(例如，main.o):: + + KASAN_SANITIZE_main.o := n + +- 对于一个目录下的所有文件:: + + KASAN_SANITIZE := n + +对于软件KASAN模式，要在每个函数的基础上禁用检测，请使用KASAN特定的 +``__no_sanitize_address`` 函数属性或通用的 ``noinstr`` 。 + +请注意，禁用编译器插桩（基于每个文件或每个函数）会使KASAN忽略在软件KASAN模式 +的代码中直接发生的访问。当访问是间接发生的（通过调用检测函数）或使用没有编译器 +插桩的基于硬件标签的模式时，它没有帮助。 + +对于软件KASAN模式，要在当前任务的一部分内核代码中禁用KASAN报告，请使用 +``kasan_disable_current()``/``kasan_enable_current()`` 部分注释这部分代码。 +这也会禁用通过函数调用发生的间接访问的报告。 + +对于基于标签的KASAN模式（包括硬件模式），要禁用访问检查，请使用 +``kasan_reset_tag()`` 或 ``page_kasan_tag_reset()`` 。请注意，通过 +``page_kasan_tag_reset()`` 临时禁用访问检查需要通过 ``page_kasan_tag`` +/ ``page_kasan_tag_set`` 保存和恢复每页KASAN标签。 + +测试 +~~~~ + +有一些KASAN测试可以验证KASAN是否正常工作并可以检测某些类型的内存损坏。 +测试由两部分组成: + +1. 与KUnit测试框架集成的测试。使用 ``CONFIG_KASAN_KUNIT_TEST`` 启用。 +这些测试可以通过几种不同的方式自动运行和部分验证；请参阅下面的说明。 + +2. 与KUnit不兼容的测试。使用 ``CONFIG_KASAN_MODULE_TEST`` 启用并且只能作为模块 +运行。这些测试只能通过加载内核模块并检查内核日志以获取KASAN报告来手动验证。 + +如果检测到错误，每个KUnit兼容的KASAN测试都会打印多个KASAN报告之一，然后测试打印 +其编号和状态。 + +当测试通过:: + + ok 28 - kmalloc_double_kzfree + +当由于 ``kmalloc`` 失败而导致测试失败时:: + + # kmalloc_large_oob_right: ASSERTION FAILED at lib/test_kasan.c:163 + Expected ptr is not null, but is + not ok 4 - kmalloc_large_oob_right + +当由于缺少KASAN报告而导致测试失败时:: + + # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629 + Expected kasan_data->report_expected == kasan_data->report_found, but + kasan_data->report_expected == 1 + kasan_data->report_found == 0 + not ok 28 - kmalloc_double_kzfree + +最后打印所有KASAN测试的累积状态。成功:: + + ok 1 - kasan + +或者，如果其中一项测试失败:: + + not ok 1 - kasan + +有几种方法可以运行与KUnit兼容的KASAN测试。 + +1. 可加载模块 + + 启用 ``CONFIG_KUNIT`` 后，KASAN-KUnit测试可以构建为可加载模块，并通过使用 + ``insmod`` 或 ``modprobe`` 加载 ``test_kasan.ko`` 来运行。 + +2. 内置 + + 通过内置 ``CONFIG_KUNIT`` ，也可以内置KASAN-KUnit测试。在这种情况下， + 测试将在启动时作为后期初始化调用运行。 + +3. 使用kunit_tool + + 通过内置 ``CONFIG_KUNIT`` 和 ``CONFIG_KASAN_KUNIT_TEST`` ，还可以使用 + ``kunit_tool`` 以更易读的方式查看KUnit测试结果。这不会打印通过测试 + 的KASAN报告。有关 ``kunit_tool`` 更多最新信息，请参阅 + `KUnit文档 <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_ 。 + +.. _KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index d56d6b7092e6..1f953d3439a5 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -4,6 +4,7 @@ \renewcommand\thesection* \renewcommand\thesubsection* + \kerneldocCJKon .. _linux_doc_zh: @@ -72,11 +73,11 @@ TODOlist: dev-tools/index doc-guide/index kernel-hacking/index + maintainer/index TODOList: * trace/index -* maintainer/index * fault-injection/index * livepatch/index * rust/index @@ -153,6 +154,7 @@ TODOList: arm64/index riscv/index openrisc/index + parisc/index TODOList: @@ -160,7 +162,6 @@ TODOList: * ia64/index * m68k/index * nios2/index -* parisc/index * powerpc/index * s390/index * sh/index diff --git a/Documentation/translations/zh_CN/maintainer/configure-git.rst b/Documentation/translations/zh_CN/maintainer/configure-git.rst new file mode 100644 index 000000000000..a45ea736f73b --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/configure-git.rst @@ -0,0 +1,62 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/configure-git.rst + +:译者: + + 吴想成 Wu XiangCheng <bobwxc@email.cn> + +.. _configuregit_zh: + +Git配置 +======= + +本章讲述了维护者级别的git配置。 + +Documentation/maintainer/pull-requests.rst 中使用的标记分支应使用开发人员的 +GPG公钥进行签名。可以通过将 ``-u`` 标志传递给 ``git tag`` 来创建签名标记。 +但是，由于 *通常* 对同一项目使用同一个密钥，因此可以设置:: + + git config user.signingkey "keyname" + +或者手动编辑你的 ``.git/config`` 或 ``~/.gitconfig`` 文件:: + + [user] + name = Jane Developer + email = jd@domain.org + signingkey = jd@domain.org + +你可能需要告诉 ``git`` 去使用 ``gpg2``:: + + [gpg] + program = /path/to/gpg2 + +你可能也需要告诉 ``gpg`` 去使用哪个 ``tty`` （添加到你的shell rc文件中）:: + + export GPG_TTY=$(tty) + + +创建链接到lore.kernel.org的提交 +------------------------------- + +http://lore.kernel.org 网站是所有涉及或影响内核开发的邮件列表的总存档。在这里 +存储补丁存档是推荐的做法，当维护人员将补丁应用到子系统树时，最好提供一个指向 +lore存档链接的标签，以便浏览提交历史的人可以找到某个更改背后的相关讨论和基本 +原理。链接标签如下所示： + + Link: https://lore.kernel.org/r/<message-id> + +通过在git中添加以下钩子，可以将此配置为在发布 ``git am`` 时自动执行： + +.. code-block:: none + + $ git config am.messageid true + $ cat >.git/hooks/applypatch-msg <<'EOF' + #!/bin/sh + . git-sh-setup + perl -pi -e 's|^Message-Id:\s*<?([^>]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1" + test -x "$GIT_DIR/hooks/commit-msg" && + exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"} + : + EOF + $ chmod a+x .git/hooks/applypatch-msg diff --git a/Documentation/translations/zh_CN/maintainer/index.rst b/Documentation/translations/zh_CN/maintainer/index.rst new file mode 100644 index 000000000000..eb75ccea9a21 --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/index.rst @@ -0,0 +1,21 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/index.rst + +============== +内核维护者手册 +============== + +本文档本是内核维护者手册的首页。 +本手册还需要大量完善！请自由提出（和编写）本手册的补充内容。 +*译注：指英文原版* + +.. toctree:: + :maxdepth: 2 + + configure-git + rebasing-and-merging + pull-requests + maintainer-entry-profile + modifying-patches + diff --git a/Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst b/Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst new file mode 100644 index 000000000000..a1ee99c4786e --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst @@ -0,0 +1,92 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/maintainer-entry-profile.rst + +:译者: + + 吴想成 Wu XiangCheng <bobwxc@email.cn> + +.. _maintainerentryprofile_zh: + +维护者条目概要 +============== + +维护人员条目概要补充了顶层过程文档（提交补丁，提交驱动程序……），增加了子系 +统/设备驱动程序本地习惯以及有关补丁提交生命周期的相关内容。贡献者使用此文档 +来调整他们的期望和避免常见错误；维护人员可以使用这些信息超越子系统层面查看 +是否有机会汇聚到通用实践中。 + + +总览 +---- + +提供了子系统如何操作的介绍。MAINTAINERS文件告诉了贡献者应发送某文件的补丁到哪， +但它没有传达其他子系统的本地基础设施和机制以协助开发。 + +请考虑以下问题： + +- 当补丁被本地树接纳或合并到上游时是否有通知？ +- 子系统是否使用patchwork实例？Patchwork状态变更是否有通知？ +- 是否有任何机器人或CI基础设施监视列表，或子系统是否使用自动测试反馈以便把 + 控接纳补丁？ +- 被拉入-next的Git分支是哪个？ +- 贡献者应针对哪个分支提交？ +- 是否链接到其他维护者条目概要？例如一个设备驱动可能指向其父子系统的条目。 + 这使得贡献者意识到某维护者可能对提交链中其他维护者负有的义务。 + + +提交检查单补遗 +-------------- + +列出强制性和咨询性标准，超出通用标准“提交检查表，以便维护者检查一个补丁是否 +足够健康。例如：“通过checkpatch.pl，没有错误、没有警告。通过单元测试详见某处”。 + +提交检查单补遗还可以包括有关硬件规格状态的详细信息。例如，子系统接受补丁之前 +是否需要考虑在某个修订版上发布的规范。 + + +开发周期的关键日期 +------------------ + +提交者常常会误以为补丁可以在合并窗口关闭之前的任何时间发送，且下一个-rc1时仍 +可以。事实上，大多数补丁都需要在下一个合并窗口打开之前提前进入linux-next中。 +向提交者澄清关键日期（以-rc发布周为标志）以明确什么时候补丁会被考虑合并以及 +何时需要等待下一个-rc。 + +至少需要讲明： + +- 最后一个可以提交新功能的-rc： + 针对下一个合并窗口的新功能提交应该在此点之前首次发布以供考虑。在此时间点 + 之后提交的补丁应该明确他们的目标为下下个合并窗口，或者给出应加快进度被接受 + 的充足理由。通常新特性贡献者的提交应出现在-rc5之前。 + +- 最后合并-rc：合并决策的最后期限。 + 向贡献者指出尚未接受的补丁集需要等待下下个合并窗口。当然，维护者没有义务 + 接受所有给定的补丁集，但是如果审阅在此时间点尚未结束，那么希望贡献者应该 + 等待并在下一个合并窗口重新提交。 + +可选项： + +- 开发基线分支的首个-rc，列在概述部分，视为已为新提交做好准备。 + + +审阅节奏 +-------- + +贡献者最担心的问题之一是：补丁集已发布却未收到反馈，应在多久后发送提醒。除了 +指定在重新提交之前要等待多长时间，还可以指示更新的首选样式；例如，重新发送 +整个系列，或私下发送提醒邮件。本节也可以列出本区域的代码审阅方式，以及获取 +不能直接从维护者那里得到的反馈的方法。 + + +现有概要 +-------- + +这里列出了现有的维护人员条目概要；我们可能会想要在不久的将来做一些不同的事情。 + +.. toctree:: + :maxdepth: 1 + + ../doc-guide/maintainer-profile + ../../../nvdimm/maintainer-entry-profile + ../../../riscv/patch-acceptance diff --git a/Documentation/translations/zh_CN/maintainer/modifying-patches.rst b/Documentation/translations/zh_CN/maintainer/modifying-patches.rst new file mode 100644 index 000000000000..7f6326137f6b --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/modifying-patches.rst @@ -0,0 +1,51 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/modifying-patches.rst + +:译者: + + 吴想成 Wu XiangCheng <bobwxc@email.cn> + +.. _modifyingpatches_zh: + +修改补丁 +======== + +如果你是子系统或者分支的维护者，由于代码在你的和提交者的树中并不完全相同， +有时你需要稍微修改一下收到的补丁以合并它们。 + +如果你严格遵守开发者来源证书的规则（c），你应该要求提交者重做，但这完全是会 +适得其反的时间、精力浪费。规则（b）允许你调整代码，但这样修改提交者的代码并 +让他背书你的错误是非常不礼貌的。为解决此问题，建议在你之前最后一个 +Signed-off-by标签和你的之间添加一行，以指示更改的性质。这没有强制性要求，最 +好在描述前面加上你的邮件和/或姓名，用方括号括住整行，以明显指出你对最后一刻 +的更改负责。例如:: + + Signed-off-by: Random J Developer <random@developer.example.org> + [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] + Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org> + +如果您维护着一个稳定的分支，并希望同时明确贡献、跟踪更改、合并修复，并保护 +提交者免受责难，这种做法尤其有用。请注意，在任何情况下都不得更改作者的身份 +（From头），因为它会在变更日志中显示。 + +向后移植（back-port）人员特别要注意：为了便于跟踪，请在提交消息的顶部（即主题行 +之后）插入补丁的来源，这是一种常见而有用的做法。例如，我们可以在3.x稳定版本 +中看到以下内容:: + + Date: Tue Oct 7 07:26:38 2014 -0400 + + libata: Un-break ATA blacklist + + commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream. + +下面是一个旧的内核在某补丁被向后移植后会出现的:: + + Date: Tue May 13 22:12:27 2008 +0200 + + wireless, airo: waitbusy() won't delay + + [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a] + +不管什么格式，这些信息都为人们跟踪你的树，以及试图解决你树中的错误的人提供了 +有价值的帮助。 diff --git a/Documentation/translations/zh_CN/maintainer/pull-requests.rst b/Documentation/translations/zh_CN/maintainer/pull-requests.rst new file mode 100644 index 000000000000..f46d6f3f2498 --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/pull-requests.rst @@ -0,0 +1,148 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/pull-requests.rst + +:译者: + + 吴想成 Wu XiangCheng <bobwxc@email.cn> + +.. _pullrequests_zh: + +如何创建拉取请求 +================ + +本章描述维护人员如何创建并向其他维护人员提交拉取请求。这对将更改从一个维护者 +树转移到另一个维护者树非常有用。 + +本文档由Tobin C. Harding（当时他尚不是一名经验丰富的维护人员）编写，内容主要 +来自Greg Kroah Hartman和Linus Torvalds在LKML上的评论。Jonathan Corbet和Mauro +Carvalho Chehab提出了一些建议和修改。错误不可避免，如有问题，请找Tobin C. +Harding <me@tobin.cc>。 + +原始邮件线程:: + + http://lkml.kernel.org/r/20171114110500.GA21175@kroah.com + + +创建分支 +-------- + +首先，您需要将希望包含拉取请求里的所有更改都放在单独分支中。通常您将基于某开发 +人员树的一个分支，一般是打算向其发送拉取请求的开发人员。 + +为了创建拉取请求，您必须首先标记刚刚创建的分支。建议您选择一个有意义的标记名， +以即使过了一段时间您和他人仍能理解的方式。在名称中包含源子系统和目标内核版本 +的指示也是一个好的做法。 + +Greg提供了以下内容。对于一个含有drivers/char中混杂事项、将应用于4.15-rc1内核的 +拉取请求，可以命名为 ``char-misc-4.15-rc1`` 。如果要在 ``char-misc-next`` 分支 +上打上此标记，您可以使用以下命令:: + + git tag -s char-misc-4.15-rc1 char-misc-next + +这将在 ``char-misc-next`` 分支的最后一个提交上创建一个名为 ``char-misc-4.15-rc1`` +的标记，并用您的gpg密钥签名（参见 Documentation/maintainer/configure-git.rst ）。 + +Linus只接受基于签名过的标记的拉取请求。其他维护者可能会有所不同。 + +当您运行上述命令时 ``git`` 会打开编辑器要求你描述一下这个标记。在本例中您需要 +描述拉取请求，所以请概述一下包含的内容，为什么要合并，是否完成任何测试。所有 +这些信息都将留在标记中，然后在维护者合并拉取请求时保留在合并提交中。所以把它 +写好，它将永远留在内核中。 + +正如Linus所说:: + + 不管怎么样，至少对我来说，重要的是 *信息* 。我需要知道我在拉取什么、 + 为什么我要拉取。我也希望将此消息用于合并消息，因此它不仅应该对我有 + 意义，也应该可以成为一个有意义的历史记录。 + + 注意，如果拉取请求有一些不寻常的地方，请详细说明。如果你修改了并非 + 由你维护的文件，请解释 **为什么** 。我总会在差异中看到的，如果你不 + 提的话，我只会觉得分外可疑。当你在合并窗口后给我发新东西的时候， + （甚至是比较重大的错误修复），不仅需要解释做了什么、为什么这么做， + 还请解释一下 **时间问题** 。为什么错过了合并窗口…… + + 我会看你写在拉取请求邮件和签名标记里面的内容，所以根据你的工作流， + 你可以在签名标记里面描述工作内容（也会自动放进拉取请求邮件），也 + 可以只在标记里面放个占位符，稍后在你实际发给我拉取请求时描述工作内容。 + + 是的，我会编辑这些消息。部分因为我需要做一些琐碎的格式调整（整体缩进、 + 括号等），也因为此消息可能对我有意义（描述了冲突或一些个人问题）而对 + 合并提交信息上下文没啥意义，因此我需要尽力让它有意义起来。我也会 + 修复一些拼写和语法错误，特别是非母语者（母语者也是;^）。但我也会删掉 + 或增加一些内容。 + + Linus + +Greg给出了一个拉取请求的例子:: + + Char/Misc patches for 4.15-rc1 + + Here is the big char/misc patch set for the 4.15-rc1 merge window. + Contained in here is the normal set of new functions added to all + of these crazy drivers, as well as the following brand new + subsystems: + - time_travel_controller: Finally a set of drivers for the + latest time travel bus architecture that provides i/o to + the CPU before it asked for it, allowing uninterrupted + processing + - relativity_shifters: due to the affect that the + time_travel_controllers have on the overall system, there + was a need for a new set of relativity shifter drivers to + accommodate the newly formed black holes that would + threaten to suck CPUs into them. This subsystem handles + this in a way to successfully neutralize the problems. + There is a Kconfig option to force these to be enabled + when needed, so problems should not occur. + + All of these patches have been successfully tested in the latest + linux-next releases, and the original problems that it found have + all been resolved (apologies to anyone living near Canberra for the + lack of the Kconfig options in the earlier versions of the + linux-next tree creations.) + + Signed-off-by: Your-name-here <your_email@domain> + + +此标记消息格式就像一个git提交。顶部有一行“总结标题”， 一定要在下面sign-off。 + +现在您已经有了一个本地签名标记，您需要将它推送到可以被拉取的位置:: + + git push origin char-misc-4.15-rc1 + + +创建拉取请求 +------------ + +最后要做的是创建拉取请求消息。可以使用 ``git request-pull`` 命令让 ``git`` +为你做这件事，但它需要确定你想拉取什么，以及拉取针对的基础（显示正确的拉取 +更改和变更状态）。以下命令将生成一个拉取请求:: + + git request-pull master git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ char-misc-4.15-rc1 + +引用Greg的话:: + + 此命令要求git比较从“char-misc-4.15-rc1”标记位置到“master”分支头（上述 + 例子中指向了我从Linus的树分叉的地方，通常是-rc发布）的差异，并去使用 + git:// 协议拉取。如果你希望使用 https:// 协议，也可以用在这里（但是请 + 注意，部分人由于防火墙问题没法用https协议拉取）。 + + 如果char-misc-4.15-rc1标记没有出现在我要求拉取的仓库中，git会提醒 + 它不在那里，所以记得推送到公开地方。 + + “git request-pull”会包含git树的地址和需要拉取的特定标记，以及标记 + 描述全文（详尽描述标记）。同时它也会创建此拉取请求的差异状态和单个 + 提交的缩短日志。 + +Linus回复说他倾向于 ``git://`` 协议。其他维护者可能有不同的偏好。另外，请注意 +如果你创建的拉取请求没有签名标记， ``https://`` 可能是更好的选择。完整的讨论 +请看原邮件。 + + +提交拉取请求 +------------ + +拉取请求的提交方式与普通补丁相同。向维护人员发送内联电子邮件并抄送LKML以及 +任何必要特定子系统的列表。对Linus的拉取请求通常有如下主题行:: + + [GIT PULL] <subsystem> changes for v4.15-rc1 diff --git a/Documentation/translations/zh_CN/maintainer/rebasing-and-merging.rst b/Documentation/translations/zh_CN/maintainer/rebasing-and-merging.rst new file mode 100644 index 000000000000..83b7dabfe88b --- /dev/null +++ b/Documentation/translations/zh_CN/maintainer/rebasing-and-merging.rst @@ -0,0 +1,165 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/maintainer/rebasing-and-merging.rst + +:译者: + + 吴想成 Wu XiangCheng <bobwxc@email.cn> + +========== +变基与合并 +========== + +一般来说，维护子系统需要熟悉Git源代码管理系统。Git是一个功能强大的工具，有 +很多功能；就像这类工具常出现的情况一样，使用这些功能的方法有对有错。本文档 +特别介绍了变基与合并的用法。维护者经常在错误使用这些工具时遇到麻烦，但避免 +问题实际上并不那么困难。 + +总的来说，需要注意的一点是：与许多其他项目不同，内核社区并不害怕在其开发历史 +中看到合并提交。事实上，考虑到该项目的规模，避免合并几乎是不可能的。维护者会 +在希望避免合并时遇到一些问题，而过于频繁的合并也会带来另一些问题。 + +变基 +==== + +“变基（Rebase）”是更改存储库中一系列提交的历史记录的过程。有两种不同型的操作 +都被称为变基，因为这两种操作都使用 ``git rebase`` 命令，但它们之间存在显著 +差异： + + - 更改一系列补丁的父提交（起始提交）。例如，变基操作可以将基于上一内核版本 + 的一个补丁集重建到当前版本上。在下面的讨论中，我们将此操作称为“变根”。 + + - 通过修复（或删除）损坏的提交、添加补丁、添加标记以更改一系列补丁的历史， + 来提交变更日志或更改已应用提交的顺序。在下文中，这种类型的操作称为“历史 + 修改” + +术语“变基”将用于指代上述两种操作。如果使用得当，变基可以产生更清晰、更整洁的 +开发历史；如果使用不当，它可能会模糊历史并引入错误。 + +以下一些经验法则可以帮助开发者避免最糟糕的变基风险： + + - 已经发布到你私人系统之外世界的历史通常不应更改。其他人可能会拉取你的树 + 的副本，然后基于它进行工作；修改你的树会给他们带来麻烦。如果工作需要变基， + 这通常是表明它还没有准备好提交到公共存储库的信号。 + + 但是，总有例外。有些树（linux-next是一个典型的例子）由于它们的需要经常 + 变基，开发人员知道不要基于它们来工作。开发人员有时会公开一个不稳定的分支， + 供其他人或自动测试服务进行测试。如果您确实以这种方式公开了一个可能不稳定 + 的分支，请确保潜在使用者知道不要基于它来工作。 + + - 不要在包含由他人创建的历史的分支上变基。如果你从别的开发者的仓库拉取了变更， + 那你现在就成了他们历史记录的保管人。你不应该改变它，除了少数例外情况。例如 + 树中有问题的提交必须显式恢复（即通过另一个补丁修复），而不是通过修改历史而 + 消失。 + + - 没有合理理由，不要对树变根。仅为了切换到更新的基或避免与上游储存库的合并 + 通常不是合理理由。 + + - 如果你必须对储存库进行变根，请不要随机选取一个提交作为新基。在发布节点之间 + 内核通常处于一个相对不稳定的状态；基于其中某点进行开发会增加遇到意外错误的 + 几率。当一系列补丁必须移动到新基时，请选择移动到一个稳定节点（例如-rc版本 + 节点）。 + + - 请知悉对补丁系列进行变根（或做明显的历史修改）会改变它们的开发环境，且很 + 可能使做过的大部分测试失效。一般来说，变基后的补丁系列应当像新代码一样对 + 待，并重新测试。 + +合并窗口麻烦的一个常见原因是，Linus收到了一个明显在拉取请求发送之前不久才变根 +（通常是变根到随机的提交上）的补丁系列。这样一个系列被充分测试的可能性相对较 +低，拉取请求被接受的几率也同样较低。 + +相反，如果变基仅限于私有树、提交基于一个通用的起点、且经过充分测试，则引起 +麻烦的可能性就很低。 + +合并 +==== + +内核开发过程中，合并是一个很常见的操作；5.1版本开发周期中有超过1126个合并 +——差不多占了整体的9%。内核开发工作积累在100多个不同的子系统树中，每个 +子系统树都可能包含多个主题分支；每个分支通常独立于其他分支进行开发。因此 +在任何给定分支进入上游储存库之前，至少需要一次合并。 + +许多项目要求拉取请求中的分支基于当前主干，这样历史记录中就不会出现合并提交。 +内核并不是这样；任何为了避免合并而重新对分支变基都很可能导致麻烦。 + +子系统维护人员发现他们必须进行两种类型的合并：从较低层级的子系统树和从其他 +子系统树（同级树或主线）进行合并。这两种情况下要遵循的最佳实践是不同的。 + +合并较低层级树 +-------------- + +较大的子系统往往有多个级别的维护人员，较低级别的维护人员向较高级别发送拉取 +请求。合并这样的请求执行几乎肯定会生成一个合并提交；这也是应该的。实际上， +子系统维护人员可能希望在极少数快进合并情况下使用 ``-–no-ff`` 标志来强制添加 +合并提交，以便记录合并的原因。 **任何** 类型的合并的变更日志必须说明 +*为什么* 合并。对于较低级别的树，“为什么”通常是对该取所带来的变化的总结。 + +各级维护人员都应在他们的拉取请求上使用经签名的标签，上游维护人员应在拉取分支 +时验证标签。不这样做会威胁整个开发过程的安全。 + +根据上面列出的规则，一旦您将其他人的历史记录合并到树中，您就不得对该分支进行 +变基，即使您能够这样做。 + +合并同级树或上游树 +------------------ + +虽然来自下游的合并是常见且不起眼的，但当需要将一个分支推向上游时，其中来自 +其他树的合并往往是一个危险信号。这种合并需要仔细考虑并加以充分证明，否则后续 +的拉取请求很可能会被拒绝。 + +想要将主分支合并到存储库中是很自然的；这种类型的合并通常被称为“反向合并” +。反向合并有助于确保与并行的开发没有冲突，并且通常会给人一种温暖、舒服的 +感觉，即处于最新。但这种诱惑几乎总是应该避免的。 + +为什么呢？反向合并将搅乱你自己分支的开发历史。它们会大大增加你遇到来自社区 +其他地方的错误的机会，且使你很难确保你所管理的工作稳定并准备好合入上游。 +频繁的合并还可以掩盖树中开发过程中的问题；它们会隐藏与其他树的交互，而这些 +交互不应该（经常）发生在管理良好的分支中。 + +也就是说，偶尔需要进行反向合并；当这种情况发生时，一定要在提交信息中记录 +*为什么* 。同样，在一个众所周知的稳定点进行合并，而不是随机提交。即使这样， +你也不应该反向合并一棵比你的直接上游树更高层级的树；如果确实需要更高级别的 +反向合并，应首先在上游树进行。 + +导致合并相关问题最常见的原因之一是：在发送拉取请求之前维护者合并上游以解决 +合并冲突。同样，这种诱惑很容易理解，但绝对应该避免。对于最终拉取请求来说 +尤其如此：Linus坚信他更愿意看到合并冲突，而不是不必要的反向合并。看到冲突 +可以让他了解潜在的问题所在。他做过很多合并（在5.1版本开发周期中是382次）， +而且在解决冲突方面也很在行——通常比参与的开发人员要强。 + +那么，当他们的子系统分支和主线之间发生冲突时，维护人员应该怎么做呢？最重要 +的一步是在拉取请求中提示Linus会发生冲突；如果啥都没说则表明您的分支可以正常 +合入。对于特别困难的冲突，创建并推送一个 *独立* 分支来展示你将如何解决问题。 +在拉取请求中提到该分支，但是请求本身应该针对未合并的分支。 + +即使不存在已知冲突，在发送拉取请求之前进行合并测试也是个好主意。它可能会提醒 +您一些在linux-next树中没有发现的问题，并帮助您准确地理解您正在要求上游做什么。 + +合并上游树或另一个子系统树的另一个原因是解决依赖关系。这些依赖性问题有时确实 +会发生，而且有时与另一棵树交叉合并是解决这些问题的最佳方法；同样，在这种情况 +下，合并提交应该解释为什么要进行合并。花点时间把它做好；会有人阅读这些变更 +日志。 + +然而依赖性问题通常表明需要改变方法。合并另一个子系统树以解决依赖性风险会带来 +其他缺陷，几乎永远不应这样做。如果该子系统树无法被合到上游，那么它的任何问题 +也都会阻碍你的树合并。更可取的选择包括与维护人员达成一致意见，在其中一个树中 +同时进行两组更改；或者创建一个主题分支专门处理可以合并到两个树中的先决条件提交。 +如果依赖关系与主要的基础结构更改相关，正确的解决方案可能是将依赖提交保留一个 +开发周期，以便这些更改有时间在主线上稳定。 + +最后 +==== + +在开发周期的开头合并主线是比较常见的，可以获取树中其他地方的更改和修复。同样， +这样的合并应该选择一个众所周知的发布点，而不是一些随机点。如果在合并窗口期间 +上游分支已完全清空到主线中，则可以使用以下命令向前拉取它:: + + git merge v5.2-rc1^0 + +“^0”使Git执行快进合并（在这种情况下这应该可以），从而避免多余的虚假合并提交。 + +上面列出的就是指导方针了。总是会有一些情况需要不同的解决方案，这些指导原则 +不应阻止开发人员在需要时做正确的事情。但是，我们应该时刻考虑是否真的出现了 +这样的需求，并准备好解释为什么需要做一些不寻常的事情。 diff --git a/Documentation/translations/zh_CN/parisc/debugging.rst b/Documentation/translations/zh_CN/parisc/debugging.rst new file mode 100644 index 000000000000..c21beb986e15 --- /dev/null +++ b/Documentation/translations/zh_CN/parisc/debugging.rst @@ -0,0 +1,42 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/parisc/debugging.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_parisc_debugging: + +================= +调试PA-RISC +================= + +好吧，这里有一些关于调试linux/parisc的较底层部分的信息。 + + +1. 绝对地址 +===================== + +很多汇编代码目前运行在实模式下，这意味着会使用绝对地址，而不是像内核其他 +部分那样使用虚拟地址。要将绝对地址转换为虚拟地址，你可以在System.map中查 +找，添加__PAGE_OFFSET（目前是0x10000000）。 + + +2. HPMCs +======== + +当实模式的代码试图访问不存在的内存时，会出现HPMC（high priority machine +check）而不是内核oops。若要调试HPMC，请尝试找到系统响应程序/请求程序地址。 +系统请求程序地址应该与（某）处理器的HPA（I/O范围内的高地址）相匹配；系统响应程 +序地址是实模式代码试图访问的地址。 + +系统响应程序地址的典型值是大于__PAGE_OFFSET （0x10000000）的地址，这意味着 +在实模式试图访问它之前，虚拟地址没有被翻译成物理地址。 + + +3. 有趣的Q位 +============ + +某些非常关键的代码必须清除PSW中的Q位。当Q位被清除时，CPU不会更新中断处理 +程序所读取的寄存器，以找出机器被中断的位置——所以如果你在清除Q位的指令和再 +次设置Q位的RFI之间遇到中断，你不知道它到底发生在哪里。如果你幸运的话，IAOQ +会指向清除Q位的指令，如果你不幸运的话，它会指向任何地方。通常Q位的问题会 +表现为无法解释的系统挂起或物理内存越界。 diff --git a/Documentation/translations/zh_CN/parisc/index.rst b/Documentation/translations/zh_CN/parisc/index.rst new file mode 100644 index 000000000000..a47454ebe32e --- /dev/null +++ b/Documentation/translations/zh_CN/parisc/index.rst @@ -0,0 +1,28 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/parisc/index.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_parisc_index: + +==================== +PA-RISC体系架构 +==================== + +.. toctree:: + :maxdepth: 2 + + debugging + registers + +Todolist: + + features + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/translations/zh_CN/parisc/registers.rst b/Documentation/translations/zh_CN/parisc/registers.rst new file mode 100644 index 000000000000..71e2404cd103 --- /dev/null +++ b/Documentation/translations/zh_CN/parisc/registers.rst @@ -0,0 +1,153 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/parisc/registers.rst +:Translator: Yanteng Si <siyanteng@loongson.cn> + +.. _cn_parisc_registers: + +========================= +Linux/PA-RISC的寄存器用法 +========================= + +[ 用星号表示目前尚未实现的计划用途。 ] + +ABI约定的通用寄存器 +=================== + +控制寄存器 +---------- + +============================ ================================= +CR 0 (恢复计数器) 用于ptrace +CR 1-CR 7(无定义) 未使用 +CR 8 (Protection ID) 每进程值* +CR 9, 12, 13 (PIDS) 未使用 +CR10 (CCR) FPU延迟保存* +CR11 按照ABI的规定（SAR） +CR14 (中断向量) 初始化为 fault_vector +CR15 (EIEM) 所有位初始化为1* +CR16 (间隔计时器) 读取周期数/写入开始时间间隔计时器 +CR17-CR22 中断参数 +CR19 中断指令寄存器 +CR20 中断空间寄存器 +CR21 中断偏移量寄存器 +CR22 中断 PSW +CR23 (EIRR) 读取未决中断/写入清除位 +CR24 (TR 0) 内核空间页目录指针 +CR25 (TR 1) 用户空间页目录指针 +CR26 (TR 2) 不使用 +CR27 (TR 3) 线程描述符指针 +CR28 (TR 4) 不使用 +CR29 (TR 5) 不使用 +CR30 (TR 6) 当前 / 0 +CR31 (TR 7) 临时寄存器，在不同地方使用 +============================ ================================= + +空间寄存器（内核模式） +---------------------- + +======== ============================== +SR0 临时空间寄存器 +SR4-SR7 设置为0 +SR1 临时空间寄存器 +SR2 内核不应该破坏它 +SR3 用于用户空间访问（当前进程） +======== ============================== + +空间寄存器（用户模式） +---------------------- + +======== ============================ +SR0 临时空间寄存器 +SR1 临时空间寄存器 +SR2 保存Linux gateway page的空间 +SR3 在内核中保存用户地址空间的值 +SR4-SR7 定义了用户/内核的短地址空间 +======== ============================ + + +处理器状态字 +------------ + +====================== ================================================ +W （64位地址） 0 +E （小尾端） 0 +S （安全间隔计时器） 0 +T （产生分支陷阱） 0 +H （高特权级陷阱） 0 +L （低特权级陷阱） 0 +N （撤销下一条指令） 被C代码使用 +X （数据存储中断禁用） 0 +B （产生分支） 被C代码使用 +C （代码地址转译） 1, 在执行实模式代码时为0 +V （除法步长校正） 被C代码使用 +M （HPMC 掩码） 0, 在执行HPMC操作*时为1 +C/B （进/借 位） 被C代码使用 +O （有序引用） 1* +F （性能监视器） 0 +R （回收计数器陷阱） 0 +Q （收集中断状态） 1 （在rfi之前的代码中为0） +P （保护标识符） 1* +D （数据地址转译） 1, 在执行实模式代码时为0 +I （外部中断掩码） 由cli()/sti()宏使用。 +====================== ================================================ + +“隐形”寄存器（影子寄存器） +--------------------------- + +============= =================== +PSW W 默认值 0 +PSW E 默认值 0 +影子寄存器 被中断处理代码使用 +TOC启用位 1 +============= =================== + +---------------------------------------------------------- + +PA-RISC架构定义了7个寄存器作为“影子寄存器”。这些寄存器在 +RETURN FROM INTERRUPTION AND RESTORE指令中使用，通过消 +除中断处理程序中对一般寄存器（GR）的保存和恢复的需要来减 +少状态保存和恢复时间。影子寄存器是GRs 1, 8, 9, 16, 17, +24和25。 + +------------------------------------------------------------------------- + +寄存器使用说明，最初由John Marvin提供，并由Randolph Chung提供一些补充说明。 + +对于通用寄存器: + +r1,r2,r19-r26,r28,r29 & r31可以在不保存它们的情况下被使用。当然，如果你 +关心它们，在调用另一个程序之前，你也需要保存它们。上面的一些寄存器确实 +有特殊的含义，你应该注意一下: + + r1: + addil指令是硬性规定将其结果放在r1中，所以如果你使用这条指令要 + 注意这点。 + + r2: + 这就是返回指针。一般来说，你不想使用它，因为你需要这个指针来返 + 回给你的调用者。然而，它与这组寄存器组合在一起，因为调用者不能 + 依赖你返回时的值是相同的，也就是说，你可以将r2复制到另一个寄存 + 器，并在作废r2后通过该寄存器返回，这应该不会给调用程序带来问题。 + + r19-r22: + 这些通常被认为是临时寄存器。 + 请注意，在64位中它们是arg7-arg4。 + + r23-r26: + 这些是arg3-arg0，也就是说，如果你不再关心传入的值，你可以使用 + 它们。 + + r28,r29: + 这俩是ret0和ret1。它们是你传入返回值的地方。r28是主返回值。当返回 + 小结构体时，r29也可以用来将数据传回给调用程序。 + + r30: + 栈指针 + + r31: + ble指令将返回指针放在这里。 + + + r3-r18,r27,r30需要被保存和恢复。r3-r18只是一般用途的寄存器。 + r27是数据指针，用来使对全局变量的引用更容易。r30是栈指针。 diff --git a/Documentation/translations/zh_CN/process/8.Conclusion.rst b/Documentation/translations/zh_CN/process/8.Conclusion.rst index 71c3e30efc6f..4707f0101964 100644 --- a/Documentation/translations/zh_CN/process/8.Conclusion.rst +++ b/Documentation/translations/zh_CN/process/8.Conclusion.rst @@ -19,7 +19,7 @@ :ref:`Documentation/translations/zh_CN/process/howto.rst <cn_process_howto>` 文件是一个重要的起点； :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>` -和 :ref:`Documentation/transaltions/zh_CN/process/submitting-drivers.rst <cn_submittingdrivers>` +和 :ref:`Documentation/translations/zh_CN/process/submitting-drivers.rst <cn_submittingdrivers>` 也是所有内核开发人员都应该阅读的内容。许多内部内核API都是使用kerneldoc机制 记录的；“make htmldocs”或“make pdfdocs”可用于以HTML或PDF格式生成这些文档 （尽管某些发行版提供的tex版本会遇到内部限制，无法正确处理文档）。 diff --git a/Documentation/translations/zh_CN/process/coding-style.rst b/Documentation/translations/zh_CN/process/coding-style.rst index 406d43a02c02..b8c484a84d10 100644 --- a/Documentation/translations/zh_CN/process/coding-style.rst +++ b/Documentation/translations/zh_CN/process/coding-style.rst @@ -61,7 +61,7 @@ Linux 内核代码风格 case 'K': case 'k': mem <<= 10; - /* fall through */ + fallthrough; default: break; } diff --git a/Documentation/usb/ehci.rst b/Documentation/usb/ehci.rst index 31f650e7c1b4..76190501907a 100644 --- a/Documentation/usb/ehci.rst +++ b/Documentation/usb/ehci.rst @@ -1,4 +1,4 @@ -=========== +=========== EHCI driver =========== diff --git a/Documentation/usb/gadget_configfs.rst b/Documentation/usb/gadget_configfs.rst index 158e48dab586..e4566ffb223f 100644 --- a/Documentation/usb/gadget_configfs.rst +++ b/Documentation/usb/gadget_configfs.rst @@ -140,7 +140,7 @@ is an arbitrary string allowed in a filesystem, e.g.:: Each function provides its specific set of attributes, with either read-only or read-write access. Where applicable they need to be written to as appropriate. -Please refer to Documentation/ABI/*/configfs-usb-gadget* for more information. +Please refer to Documentation/ABI/testing/configfs-usb-gadget for more information. 4. Associating the functions with their configurations ------------------------------------------------------ diff --git a/Documentation/usb/gadget_printer.rst b/Documentation/usb/gadget_printer.rst index 5e5516c69075..e611a6d91093 100644 --- a/Documentation/usb/gadget_printer.rst +++ b/Documentation/usb/gadget_printer.rst @@ -1,4 +1,4 @@ -=============================== +=============================== Linux USB Printer Gadget Driver =============================== diff --git a/Documentation/usb/mtouchusb.rst b/Documentation/usb/mtouchusb.rst index d1111b74bf75..5ae1f74fe74b 100644 --- a/Documentation/usb/mtouchusb.rst +++ b/Documentation/usb/mtouchusb.rst @@ -1,4 +1,4 @@ -================ +================ mtouchusb driver ================ diff --git a/Documentation/usb/usb-serial.rst b/Documentation/usb/usb-serial.rst index 8fa7dbd3da9a..69586aeb60bb 100644 --- a/Documentation/usb/usb-serial.rst +++ b/Documentation/usb/usb-serial.rst @@ -1,4 +1,4 @@ -========== +========== USB serial ========== diff --git a/Documentation/userspace-api/ioctl/hdio.rst b/Documentation/userspace-api/ioctl/hdio.rst index 817371bf94e9..6ee8fc88699f 100644 --- a/Documentation/userspace-api/ioctl/hdio.rst +++ b/Documentation/userspace-api/ioctl/hdio.rst @@ -7,8 +7,8 @@ Summary of `HDIO_` ioctl calls November, 2004 This document attempts to describe the ioctl(2) calls supported by -the HD/IDE layer. These are by-and-large implemented (as of Linux 2.6) -in drivers/ide/ide.c and drivers/block/scsi_ioctl.c +the HD/IDE layer. These are by-and-large implemented (as of Linux 5.11) +drivers/ata/libata-scsi.c. ioctl values are listed in <linux/hdreg.h>. As of this writing, they are as follows: @@ -17,50 +17,17 @@ are as follows: ======================= ======================================= HDIO_GETGEO get device geometry - HDIO_GET_UNMASKINTR get current unmask setting - HDIO_GET_MULTCOUNT get current IDE blockmode setting - HDIO_GET_QDMA get use-qdma flag - HDIO_SET_XFER set transfer rate via proc - HDIO_OBSOLETE_IDENTITY OBSOLETE, DO NOT USE - HDIO_GET_KEEPSETTINGS get keep-settings-on-reset flag HDIO_GET_32BIT get current io_32bit setting - HDIO_GET_NOWERR get ignore-write-error flag - HDIO_GET_DMA get use-dma flag - HDIO_GET_NICE get nice flags HDIO_GET_IDENTITY get IDE identification info - HDIO_GET_WCACHE get write cache mode on|off - HDIO_GET_ACOUSTIC get acoustic value - HDIO_GET_ADDRESS get sector addressing mode - HDIO_GET_BUSSTATE get the bus state of the hwif - HDIO_TRISTATE_HWIF execute a channel tristate - HDIO_DRIVE_RESET execute a device reset HDIO_DRIVE_TASKFILE execute raw taskfile HDIO_DRIVE_TASK execute task and special drive command HDIO_DRIVE_CMD execute a special drive command - HDIO_DRIVE_CMD_AEB HDIO_DRIVE_TASK ======================= ======================================= ioctls that pass non-pointer values: ======================= ======================================= - HDIO_SET_MULTCOUNT change IDE blockmode - HDIO_SET_UNMASKINTR permit other irqs during I/O - HDIO_SET_KEEPSETTINGS keep ioctl settings on reset HDIO_SET_32BIT change io_32bit flags - HDIO_SET_NOWERR change ignore-write-error flag - HDIO_SET_DMA change use-dma flag - HDIO_SET_PIO_MODE reconfig interface to new speed - HDIO_SCAN_HWIF register and (re)scan interface - HDIO_SET_NICE set nice flags - HDIO_UNREGISTER_HWIF unregister interface - HDIO_SET_WCACHE change write cache enable-disable - HDIO_SET_ACOUSTIC change acoustic behavior - HDIO_SET_BUSSTATE set the bus state of the hwif - HDIO_SET_QDMA change use-qdma flag - HDIO_SET_ADDRESS change lba addressing modes - - HDIO_SET_IDE_SCSI Set scsi emulation mode on/off - HDIO_SET_SCSI_IDE not implemented yet ======================= ======================================= @@ -137,143 +104,6 @@ HDIO_GETGEO - -HDIO_GET_UNMASKINTR - get current unmask setting - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_UNMASKINTR, &val); - - inputs: - none - - - - outputs: - The value of the drive's current unmask setting - - - - - -HDIO_SET_UNMASKINTR - permit other irqs during I/O - - - usage:: - - unsigned long val; - - ioctl(fd, HDIO_SET_UNMASKINTR, val); - - inputs: - New value for unmask flag - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - - -HDIO_GET_MULTCOUNT - get current IDE blockmode setting - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_MULTCOUNT, &val); - - inputs: - none - - - - outputs: - The value of the current IDE block mode setting. This - controls how many sectors the drive will transfer per - interrupt. - - - -HDIO_SET_MULTCOUNT - change IDE blockmode - - - usage:: - - int val; - - ioctl(fd, HDIO_SET_MULTCOUNT, val); - - inputs: - New value for IDE block mode setting. This controls how many - sectors the drive will transfer per interrupt. - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range supported by disk. - - EBUSY Controller busy or blockmode already set. - - EIO Drive did not accept new block mode. - - notes: - Source code comments read:: - - This is tightly woven into the driver->do_special cannot - touch. DON'T do it again until a total personality rewrite - is committed. - - If blockmode has already been set, this ioctl will fail with - -EBUSY - - - -HDIO_GET_QDMA - get use-qdma flag - - - Not implemented, as of 2.6.8.1 - - - -HDIO_SET_XFER - set transfer rate via proc - - - Not implemented, as of 2.6.8.1 - - - -HDIO_OBSOLETE_IDENTITY - OBSOLETE, DO NOT USE - - - Same as HDIO_GET_IDENTITY (see below), except that it only - returns the first 142 bytes of drive identity information. - - - HDIO_GET_IDENTITY get IDE identification info @@ -308,60 +138,6 @@ HDIO_GET_IDENTITY -HDIO_GET_KEEPSETTINGS - get keep-settings-on-reset flag - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_KEEPSETTINGS, &val); - - inputs: - none - - - - outputs: - The value of the current "keep settings" flag - - - - notes: - When set, indicates that kernel should restore settings - after a drive reset. - - - -HDIO_SET_KEEPSETTINGS - keep ioctl settings on reset - - - usage:: - - long val; - - ioctl(fd, HDIO_SET_KEEPSETTINGS, val); - - inputs: - New value for keep_settings flag - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - HDIO_GET_32BIT get current io_32bit setting @@ -387,288 +163,6 @@ HDIO_GET_32BIT - - -HDIO_GET_NOWERR - get ignore-write-error flag - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_NOWERR, &val); - - inputs: - none - - - - outputs: - The value of the current ignore-write-error flag - - - - - -HDIO_GET_DMA - get use-dma flag - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_DMA, &val); - - inputs: - none - - - - outputs: - The value of the current use-dma flag - - - - - -HDIO_GET_NICE - get nice flags - - - usage:: - - long nice; - - ioctl(fd, HDIO_GET_NICE, &nice); - - inputs: - none - - - - outputs: - The drive's "nice" values. - - - - notes: - Per-drive flags which determine when the system will give more - bandwidth to other devices sharing the same IDE bus. - - See <linux/hdreg.h>, near symbol IDE_NICE_DSC_OVERLAP. - - - - -HDIO_SET_NICE - set nice flags - - - usage:: - - unsigned long nice; - - ... - ioctl(fd, HDIO_SET_NICE, nice); - - inputs: - bitmask of nice flags. - - - - outputs: - none - - - - error returns: - - EACCES Access denied: requires CAP_SYS_ADMIN - - EPERM Flags other than DSC_OVERLAP and NICE_1 set. - - EPERM DSC_OVERLAP specified but not supported by drive - - notes: - This ioctl sets the DSC_OVERLAP and NICE_1 flags from values - provided by the user. - - Nice flags are listed in <linux/hdreg.h>, starting with - IDE_NICE_DSC_OVERLAP. These values represent shifts. - - - - - -HDIO_GET_WCACHE - get write cache mode on|off - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_WCACHE, &val); - - inputs: - none - - - - outputs: - The value of the current write cache mode - - - - - -HDIO_GET_ACOUSTIC - get acoustic value - - - usage:: - - long val; - - ioctl(fd, HDIO_GET_ACOUSTIC, &val); - - inputs: - none - - - - outputs: - The value of the current acoustic settings - - - - notes: - See HDIO_SET_ACOUSTIC - - - - - -HDIO_GET_ADDRESS - usage:: - - - long val; - - ioctl(fd, HDIO_GET_ADDRESS, &val); - - inputs: - none - - - - outputs: - The value of the current addressing mode: - - = =================== - 0 28-bit - 1 48-bit - 2 48-bit doing 28-bit - 3 64-bit - = =================== - - - -HDIO_GET_BUSSTATE - get the bus state of the hwif - - - usage:: - - long state; - - ioctl(fd, HDIO_SCAN_HWIF, &state); - - inputs: - none - - - - outputs: - Current power state of the IDE bus. One of BUSSTATE_OFF, - BUSSTATE_ON, or BUSSTATE_TRISTATE - - error returns: - - EACCES Access denied: requires CAP_SYS_ADMIN - - - - -HDIO_SET_BUSSTATE - set the bus state of the hwif - - - usage:: - - int state; - - ... - ioctl(fd, HDIO_SCAN_HWIF, state); - - inputs: - Desired IDE power state. One of BUSSTATE_OFF, BUSSTATE_ON, - or BUSSTATE_TRISTATE - - outputs: - none - - - - error returns: - - EACCES Access denied: requires CAP_SYS_RAWIO - - EOPNOTSUPP Hardware interface does not support bus power control - - - - -HDIO_TRISTATE_HWIF - execute a channel tristate - - - Not implemented, as of 2.6.8.1. See HDIO_SET_BUSSTATE - - - -HDIO_DRIVE_RESET - execute a device reset - - - usage:: - - int args[3] - - ... - ioctl(fd, HDIO_DRIVE_RESET, args); - - inputs: - none - - - - outputs: - none - - - - error returns: - - EACCES Access denied: requires CAP_SYS_ADMIN - - ENXIO No such device: phy dead or ctl_addr == 0 - - EIO I/O error: reset timed out or hardware error - - notes: - - - Execute a reset on the device as soon as the current IO - operation has completed. - - - Executes an ATAPI soft reset if applicable, otherwise - executes an ATA soft reset on the controller. - - - HDIO_DRIVE_TASKFILE execute raw taskfile @@ -1026,14 +520,6 @@ HDIO_DRIVE_TASK -HDIO_DRIVE_CMD_AEB - HDIO_DRIVE_TASK - - - Not implemented, as of 2.6.8.1 - - - HDIO_SET_32BIT change io_32bit flags @@ -1059,284 +545,3 @@ HDIO_SET_32BIT - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0 3] - EBUSY Controller busy - - - - -HDIO_SET_NOWERR - change ignore-write-error flag - - - usage:: - - int val; - - ioctl(fd, HDIO_SET_NOWERR, val); - - inputs: - New value for ignore-write-error flag. Used for ignoring - - - WRERR_STAT - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - -HDIO_SET_DMA - change use-dma flag - - - usage:: - - long val; - - ioctl(fd, HDIO_SET_DMA, val); - - inputs: - New value for use-dma flag - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - -HDIO_SET_PIO_MODE - reconfig interface to new speed - - - usage:: - - long val; - - ioctl(fd, HDIO_SET_PIO_MODE, val); - - inputs: - New interface speed. - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 255] - - EBUSY Controller busy - - - -HDIO_SCAN_HWIF - register and (re)scan interface - - - usage:: - - int args[3] - - ... - ioctl(fd, HDIO_SCAN_HWIF, args); - - inputs: - - ======= ========================= - args[0] io address to probe - - - args[1] control address to probe - args[2] irq number - ======= ========================= - - outputs: - none - - - - error returns: - - EACCES Access denied: requires CAP_SYS_RAWIO - - EIO Probe failed. - - notes: - This ioctl initializes the addresses and irq for a disk - controller, probes for drives, and creates /proc/ide - interfaces as appropriate. - - - -HDIO_UNREGISTER_HWIF - unregister interface - - - usage:: - - int index; - - ioctl(fd, HDIO_UNREGISTER_HWIF, index); - - inputs: - index index of hardware interface to unregister - - - - outputs: - none - - - - error returns: - - EACCES Access denied: requires CAP_SYS_RAWIO - - notes: - This ioctl removes a hardware interface from the kernel. - - Currently (2.6.8) this ioctl silently fails if any drive on - the interface is busy. - - - -HDIO_SET_WCACHE - change write cache enable-disable - - - usage:: - - int val; - - ioctl(fd, HDIO_SET_WCACHE, val); - - inputs: - New value for write cache enable - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - -HDIO_SET_ACOUSTIC - change acoustic behavior - - - usage:: - - int val; - - ioctl(fd, HDIO_SET_ACOUSTIC, val); - - inputs: - New value for drive acoustic settings - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 254] - - EBUSY Controller busy - - - -HDIO_SET_QDMA - change use-qdma flag - - - Not implemented, as of 2.6.8.1 - - - -HDIO_SET_ADDRESS - change lba addressing modes - - - usage:: - - int val; - - ioctl(fd, HDIO_SET_ADDRESS, val); - - inputs: - New value for addressing mode - - = =================== - 0 28-bit - 1 48-bit - 2 48-bit doing 28-bit - = =================== - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 2] - - EBUSY Controller busy - - EIO Drive does not support lba48 mode. - - -HDIO_SET_IDE_SCSI - usage:: - - - long val; - - ioctl(fd, HDIO_SET_IDE_SCSI, val); - - inputs: - New value for scsi emulation mode (?) - - - - outputs: - none - - - - error return: - - EINVAL Called on a partition instead of the whole disk device - - EACCES Access denied: requires CAP_SYS_ADMIN - - EINVAL value out of range [0 1] - - EBUSY Controller busy - - - -HDIO_SET_SCSI_IDE - Not implemented, as of 2.6.8.1 diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 9bfc2b510c64..1409e40e6345 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -325,7 +325,7 @@ Code Seq# Include File Comments 0xA3 90-9F linux/dtlk.h 0xA4 00-1F uapi/linux/tee.h Generic TEE subsystem 0xA4 00-1F uapi/asm/sgx.h <mailto:linux-sgx@vger.kernel.org> -0xA5 01 linux/surface_aggregator/cdev.h Microsoft Surface Platform System Aggregator +0xA5 01-05 linux/surface_aggregator/cdev.h Microsoft Surface Platform System Aggregator <mailto:luzmaximilian@gmail.com> 0xA5 20-2F linux/surface_aggregator/dtx.h Microsoft Surface DTX driver <mailto:luzmaximilian@gmail.com> diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst index 62c9361a3c7f..f35552ff19ba 100644 --- a/Documentation/userspace-api/landlock.rst +++ b/Documentation/userspace-api/landlock.rst @@ -145,7 +145,8 @@ Bind mounts and OverlayFS Landlock enables to restrict access to file hierarchies, which means that these access rights can be propagated with bind mounts (cf. -:doc:`/filesystems/sharedsubtree`) but not with :doc:`/filesystems/overlayfs`. +Documentation/filesystems/sharedsubtree.rst) but not with +Documentation/filesystems/overlayfs.rst. A bind mount mirrors a source file hierarchy to a destination. The destination hierarchy is then composed of the exact same files, on which Landlock rules can @@ -170,8 +171,8 @@ Inheritance Every new thread resulting from a :manpage:`clone(2)` inherits Landlock domain restrictions from its parent. This is similar to the seccomp inheritance (cf. -:doc:`/userspace-api/seccomp_filter`) or any other LSM dealing with task's -:manpage:`credentials(7)`. For instance, one process's thread may apply +Documentation/userspace-api/seccomp_filter.rst) or any other LSM dealing with +task's :manpage:`credentials(7)`. For instance, one process's thread may apply Landlock rules to itself, but they will not be automatically applied to other sibling threads (unlike POSIX thread credential changes, cf. :manpage:`nptl(7)`). @@ -278,7 +279,7 @@ Memory usage ------------ Kernel memory allocated to create rulesets is accounted and can be restricted -by the :doc:`/admin-guide/cgroup-v1/memory`. +by the Documentation/admin-guide/cgroup-v1/memory.rst. Questions and answers ===================== @@ -303,7 +304,7 @@ issues, especially when untrusted processes can manipulate them (cf. Additional documentation ======================== -* :doc:`/security/landlock` +* Documentation/security/landlock.rst * https://landlock.io .. Links diff --git a/Documentation/userspace-api/media/Makefile b/Documentation/userspace-api/media/Makefile index 81a4a1a53bce..00922aa7efde 100644 --- a/Documentation/userspace-api/media/Makefile +++ b/Documentation/userspace-api/media/Makefile @@ -7,8 +7,8 @@ PARSER = $(srctree)/Documentation/sphinx/parse-headers.pl UAPI = $(srctree)/include/uapi/linux KAPI = $(srctree)/include/linux -FILES = audio.h.rst ca.h.rst dmx.h.rst frontend.h.rst net.h.rst video.h.rst \ - videodev2.h.rst media.h.rst cec.h.rst lirc.h.rst +FILES = ca.h.rst dmx.h.rst frontend.h.rst net.h.rst \ + videodev2.h.rst media.h.rst cec.h.rst lirc.h.rst TARGETS := $(addprefix $(BUILDDIR)/, $(FILES)) @@ -21,9 +21,6 @@ quiet_gen_rst = echo ' PARSE $(patsubst $(srctree)/%,%,$<)'; \ silent_gen_rst = ${gen_rst} -$(BUILDDIR)/audio.h.rst: ${UAPI}/dvb/audio.h ${PARSER} $(SRC_DIR)/audio.h.rst.exceptions - @$($(quiet)gen_rst) - $(BUILDDIR)/ca.h.rst: ${UAPI}/dvb/ca.h ${PARSER} $(SRC_DIR)/ca.h.rst.exceptions @$($(quiet)gen_rst) @@ -36,9 +33,6 @@ $(BUILDDIR)/frontend.h.rst: ${UAPI}/dvb/frontend.h ${PARSER} $(SRC_DIR)/frontend $(BUILDDIR)/net.h.rst: ${UAPI}/dvb/net.h ${PARSER} $(SRC_DIR)/net.h.rst.exceptions @$($(quiet)gen_rst) -$(BUILDDIR)/video.h.rst: ${UAPI}/dvb/video.h ${PARSER} $(SRC_DIR)/video.h.rst.exceptions - @$($(quiet)gen_rst) - $(BUILDDIR)/videodev2.h.rst: ${UAPI}/videodev2.h ${PARSER} $(SRC_DIR)/videodev2.h.rst.exceptions @$($(quiet)gen_rst) diff --git a/Documentation/userspace-api/media/audio.h.rst.exceptions b/Documentation/userspace-api/media/audio.h.rst.exceptions deleted file mode 100644 index cf6620477f73..000000000000 --- a/Documentation/userspace-api/media/audio.h.rst.exceptions +++ /dev/null @@ -1,19 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 - -# Ignore header name -ignore define _DVBAUDIO_H_ - -# Undocumented audio caps, as this is a deprecated API anyway -ignore define AUDIO_CAP_DTS -ignore define AUDIO_CAP_LPCM -ignore define AUDIO_CAP_MP1 -ignore define AUDIO_CAP_MP2 -ignore define AUDIO_CAP_MP3 -ignore define AUDIO_CAP_AAC -ignore define AUDIO_CAP_OGG -ignore define AUDIO_CAP_SDDS -ignore define AUDIO_CAP_AC3 - -# some typedefs should point to struct/enums -replace typedef audio_mixer_t :c:type:`audio_mixer` -replace typedef audio_status_t :c:type:`audio_status` diff --git a/Documentation/userspace-api/media/drivers/hantro.rst b/Documentation/userspace-api/media/drivers/hantro.rst new file mode 100644 index 000000000000..cd9754b4e005 --- /dev/null +++ b/Documentation/userspace-api/media/drivers/hantro.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Hantro video decoder driver +=========================== + +The Hantro video decoder driver implements the following driver-specific controls: + +``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)`` + Specifies to Hantro HEVC video decoder driver the number of data (in bits) to + skip in the slice segment header. + If non-IDR, the bits to be skipped go from syntax element "pic_output_flag" + to before syntax element "slice_temporal_mvp_enabled_flag". + If IDR, the skipped bits are just "pic_output_flag" + (separate_colour_plane_flag is not supported). + +.. note:: + + This control is not yet part of the public kernel API and + it is expected to change. diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst index 1a9038f5f9fa..12e3c512d718 100644 --- a/Documentation/userspace-api/media/drivers/index.rst +++ b/Documentation/userspace-api/media/drivers/index.rst @@ -33,6 +33,7 @@ For more details see the file COPYING in the source distribution of Linux. ccs cx2341x-uapi + hantro imx-uapi max2175 meye-uapi diff --git a/Documentation/userspace-api/media/dvb/audio-bilingual-channel-select.rst b/Documentation/userspace-api/media/dvb/audio-bilingual-channel-select.rst deleted file mode 100644 index 33b5363317f1..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-bilingual-channel-select.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_BILINGUAL_CHANNEL_SELECT: - -============================== -AUDIO_BILINGUAL_CHANNEL_SELECT -============================== - -Name ----- - -AUDIO_BILINGUAL_CHANNEL_SELECT - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_BILINGUAL_CHANNEL_SELECT - -``int ioctl(int fd, AUDIO_BILINGUAL_CHANNEL_SELECT, struct audio_channel_select *select)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - audio_channel_select_t ch - - - Select the output format of the audio (mono left/right, stereo). - -Description ------------ - -This ioctl is obsolete. Do not use in new drivers. It has been replaced -by the V4L2 ``V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK`` control -for MPEG decoders controlled through V4L2. - -This ioctl call asks the Audio Device to select the requested channel -for bilingual streams if possible. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-channel-select.rst b/Documentation/userspace-api/media/dvb/audio-channel-select.rst deleted file mode 100644 index 74093df92a68..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-channel-select.rst +++ /dev/null @@ -1,57 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_CHANNEL_SELECT: - -==================== -AUDIO_CHANNEL_SELECT -==================== - -Name ----- - -AUDIO_CHANNEL_SELECT - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_CHANNEL_SELECT - -``int ioctl(int fd, AUDIO_CHANNEL_SELECT, struct audio_channel_select *select)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - audio_channel_select_t ch - - - Select the output format of the audio (mono left/right, stereo). - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 ``V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK`` control instead. - -This ioctl call asks the Audio Device to select the requested channel if -possible. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-clear-buffer.rst b/Documentation/userspace-api/media/dvb/audio-clear-buffer.rst deleted file mode 100644 index a0ebb0278260..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-clear-buffer.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_CLEAR_BUFFER: - -================== -AUDIO_CLEAR_BUFFER -================== - -Name ----- - -AUDIO_CLEAR_BUFFER - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_CLEAR_BUFFER - -``int ioctl(int fd, AUDIO_CLEAR_BUFFER)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This ioctl call asks the Audio Device to clear all software and hardware -buffers of the audio decoder device. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-continue.rst b/Documentation/userspace-api/media/dvb/audio-continue.rst deleted file mode 100644 index a2e9850f37f2..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-continue.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_CONTINUE: - -============== -AUDIO_CONTINUE -============== - -Name ----- - -AUDIO_CONTINUE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_CONTINUE - -``int ioctl(int fd, AUDIO_CONTINUE)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This ioctl restarts the decoding and playing process previously paused -with AUDIO_PAUSE command. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-fclose.rst b/Documentation/userspace-api/media/dvb/audio-fclose.rst deleted file mode 100644 index 77857d578e83..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-fclose.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _audio_fclose: - -======================== -Digital TV audio close() -======================== - -Name ----- - -Digital TV audio close() - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:function:: int close(int fd) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This system call closes a previously opened audio device. - -Return Value ------------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EBADF`` - - - fd is not a valid open file descriptor. diff --git a/Documentation/userspace-api/media/dvb/audio-fopen.rst b/Documentation/userspace-api/media/dvb/audio-fopen.rst deleted file mode 100644 index 774daaab3bad..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-fopen.rst +++ /dev/null @@ -1,103 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _audio_fopen: - -======================= -Digital TV audio open() -======================= - -Name ----- - -Digital TV audio open() - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:function:: int open(const char *deviceName, int flags) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - const char \*deviceName - - - Name of specific audio device. - - - .. row 2 - - - int flags - - - A bit-wise OR of the following flags: - - - .. row 3 - - - - - O_RDONLY read-only access - - - .. row 4 - - - - - O_RDWR read/write access - - - .. row 5 - - - - - O_NONBLOCK open in non-blocking mode - - - .. row 6 - - - - - (blocking mode is the default) - -Description ------------ - -This system call opens a named audio device (e.g. -/dev/dvb/adapter0/audio0) for subsequent use. When an open() call has -succeeded, the device will be ready for use. The significance of -blocking or non-blocking mode is described in the documentation for -functions where there is a difference. It does not affect the semantics -of the open() call itself. A device opened in blocking mode can later be -put into non-blocking mode (and vice versa) using the F_SETFL command -of the fcntl system call. This is a standard system call, documented in -the Linux manual page for fcntl. Only one user can open the Audio Device -in O_RDWR mode. All other attempts to open the device in this mode will -fail, and an error code will be returned. If the Audio Device is opened -in O_RDONLY mode, the only ioctl call that can be used is -AUDIO_GET_STATUS. All other call will return with an error code. - -Return Value ------------- - -.. tabularcolumns:: |p{2.5cm}|p{15.0cm}| - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``ENODEV`` - - - Device driver not loaded/available. - - - .. row 2 - - - ``EBUSY`` - - - Device or resource busy. - - - .. row 3 - - - ``EINVAL`` - - - Invalid argument. diff --git a/Documentation/userspace-api/media/dvb/audio-fwrite.rst b/Documentation/userspace-api/media/dvb/audio-fwrite.rst deleted file mode 100644 index 7b096ac2b6c4..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-fwrite.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _audio_fwrite: - -========================= -Digital TV audio write() -========================= - -Name ----- - -Digital TV audio write() - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:function:: size_t write(int fd, const void *buf, size_t count) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - void \*buf - - - Pointer to the buffer containing the PES data. - - - .. row 3 - - - size_t count - - - Size of buf. - -Description ------------ - -This system call can only be used if AUDIO_SOURCE_MEMORY is selected -in the ioctl call AUDIO_SELECT_SOURCE. The data provided shall be in -PES format. If O_NONBLOCK is not specified the function will block -until buffer space is available. The amount of data to be transferred is -implied by count. - -Return Value ------------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EPERM`` - - - Mode AUDIO_SOURCE_MEMORY not selected. - - - .. row 2 - - - ``ENOMEM`` - - - Attempted to write more data than the internal buffer can hold. - - - .. row 3 - - - ``EBADF`` - - - fd is not a valid open file descriptor. diff --git a/Documentation/userspace-api/media/dvb/audio-get-capabilities.rst b/Documentation/userspace-api/media/dvb/audio-get-capabilities.rst deleted file mode 100644 index 6d9eb71dad17..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-get-capabilities.rst +++ /dev/null @@ -1,54 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_GET_CAPABILITIES: - -====================== -AUDIO_GET_CAPABILITIES -====================== - -Name ----- - -AUDIO_GET_CAPABILITIES - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_GET_CAPABILITIES - -``int ioctl(int fd, AUDIO_GET_CAPABILITIES, unsigned int *cap)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - unsigned int \*cap - - - Returns a bit array of supported sound formats. - -Description ------------ - -This ioctl call asks the Audio Device to tell us about the decoding -capabilities of the audio hardware. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-get-status.rst b/Documentation/userspace-api/media/dvb/audio-get-status.rst deleted file mode 100644 index 7ae8db2e65e9..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-get-status.rst +++ /dev/null @@ -1,54 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_GET_STATUS: - -================ -AUDIO_GET_STATUS -================ - -Name ----- - -AUDIO_GET_STATUS - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_GET_STATUS - -``int ioctl(int fd, AUDIO_GET_STATUS, struct audio_status *status)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - struct audio_status \*status - - - Returns the current state of Audio Device. - -Description ------------ - -This ioctl call asks the Audio Device to return the current state of the -Audio Device. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-pause.rst b/Documentation/userspace-api/media/dvb/audio-pause.rst deleted file mode 100644 index d37d1ddce4df..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-pause.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_PAUSE: - -=========== -AUDIO_PAUSE -=========== - -Name ----- - -AUDIO_PAUSE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_PAUSE - -``int ioctl(int fd, AUDIO_PAUSE)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This ioctl call suspends the audio stream being played. Decoding and -playing are paused. It is then possible to restart again decoding and -playing process of the audio stream using AUDIO_CONTINUE command. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-play.rst b/Documentation/userspace-api/media/dvb/audio-play.rst deleted file mode 100644 index e591930b6ca7..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-play.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_PLAY: - -========== -AUDIO_PLAY -========== - -Name ----- - -AUDIO_PLAY - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_PLAY - -``int ioctl(int fd, AUDIO_PLAY)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This ioctl call asks the Audio Device to start playing an audio stream -from the selected source. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-select-source.rst b/Documentation/userspace-api/media/dvb/audio-select-source.rst deleted file mode 100644 index 6a0c0f365eb1..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-select-source.rst +++ /dev/null @@ -1,56 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SELECT_SOURCE: - -=================== -AUDIO_SELECT_SOURCE -=================== - -Name ----- - -AUDIO_SELECT_SOURCE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SELECT_SOURCE - -``int ioctl(int fd, AUDIO_SELECT_SOURCE, struct audio_stream_source *source)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - audio_stream_source_t source - - - Indicates the source that shall be used for the Audio stream. - -Description ------------ - -This ioctl call informs the audio device which source shall be used for -the input data. The possible sources are demux or memory. If -AUDIO_SOURCE_MEMORY is selected, the data is fed to the Audio Device -through the write command. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-av-sync.rst b/Documentation/userspace-api/media/dvb/audio-set-av-sync.rst deleted file mode 100644 index 85a8016bf025..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-av-sync.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_AV_SYNC: - -================= -AUDIO_SET_AV_SYNC -================= - -Name ----- - -AUDIO_SET_AV_SYNC - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_AV_SYNC - -``int ioctl(int fd, AUDIO_SET_AV_SYNC, boolean state)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - boolean state - - - Tells the Digital TV subsystem if A/V synchronization shall be ON or OFF. - - TRUE: AV-sync ON - - FALSE: AV-sync OFF - -Description ------------ - -This ioctl call asks the Audio Device to turn ON or OFF A/V -synchronization. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst b/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst deleted file mode 100644 index ecac02f1b2fc..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst +++ /dev/null @@ -1,62 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_BYPASS_MODE: - -===================== -AUDIO_SET_BYPASS_MODE -===================== - -Name ----- - -AUDIO_SET_BYPASS_MODE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_BYPASS_MODE - -``int ioctl(int fd, AUDIO_SET_BYPASS_MODE, boolean mode)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - boolean mode - - - Enables or disables the decoding of the current Audio stream in - the Digital TV subsystem. - - TRUE: Bypass is disabled - - FALSE: Bypass is enabled - -Description ------------ - -This ioctl call asks the Audio Device to bypass the Audio decoder and -forward the stream without decoding. This mode shall be used if streams -that can’t be handled by the Digital TV system shall be decoded. Dolby -DigitalTM streams are automatically forwarded by the Digital TV subsystem if -the hardware can handle it. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-id.rst b/Documentation/userspace-api/media/dvb/audio-set-id.rst deleted file mode 100644 index 39ad846d412d..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-id.rst +++ /dev/null @@ -1,59 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_ID: - -============ -AUDIO_SET_ID -============ - -Name ----- - -AUDIO_SET_ID - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_ID - -``int ioctl(int fd, AUDIO_SET_ID, int id)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - int id - - - audio sub-stream id - -Description ------------ - -This ioctl selects which sub-stream is to be decoded if a program or -system stream is sent to the video device. If no audio stream type is -set the id has to be in [0xC0,0xDF] for MPEG sound, in [0x80,0x87] for -AC3 and in [0xA0,0xA7] for LPCM. More specifications may follow for -other stream types. If the stream type is set the id just specifies the -substream id of the audio stream and only the first 5 bits are -recognized. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-mixer.rst b/Documentation/userspace-api/media/dvb/audio-set-mixer.rst deleted file mode 100644 index 45dbdf4801e0..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-mixer.rst +++ /dev/null @@ -1,53 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_MIXER: - -=============== -AUDIO_SET_MIXER -=============== - -Name ----- - -AUDIO_SET_MIXER - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_MIXER - -``int ioctl(int fd, AUDIO_SET_MIXER, struct audio_mixer *mix)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - audio_mixer_t \*mix - - - mixer settings. - -Description ------------ - -This ioctl lets you adjust the mixer settings of the audio decoder. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-mute.rst b/Documentation/userspace-api/media/dvb/audio-set-mute.rst deleted file mode 100644 index 987751f92967..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-mute.rst +++ /dev/null @@ -1,62 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_MUTE: - -============== -AUDIO_SET_MUTE -============== - -Name ----- - -AUDIO_SET_MUTE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_MUTE - -``int ioctl(int fd, AUDIO_SET_MUTE, boolean state)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - boolean state - - - Indicates if audio device shall mute or not. - - TRUE: Audio Mute - - FALSE: Audio Un-mute - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 :ref:`VIDIOC_DECODER_CMD` with the -``V4L2_DEC_CMD_START_MUTE_AUDIO`` flag instead. - -This ioctl call asks the audio device to mute the stream that is -currently being played. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio-set-streamtype.rst b/Documentation/userspace-api/media/dvb/audio-set-streamtype.rst deleted file mode 100644 index 77d73c74882f..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-set-streamtype.rst +++ /dev/null @@ -1,66 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_SET_STREAMTYPE: - -==================== -AUDIO_SET_STREAMTYPE -==================== - -Name ----- - -AUDIO_SET_STREAMTYPE - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_SET_STREAMTYPE - -``int ioctl(fd, AUDIO_SET_STREAMTYPE, int type)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - - - - int fd - - - File descriptor returned by a previous call to open(). - - - - - - int type - - - stream type - -Description ------------ - -This ioctl tells the driver which kind of audio stream to expect. This -is useful if the stream offers several audio sub-streams like LPCM and -AC3. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. - - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EINVAL`` - - - type is not a valid or supported stream type. diff --git a/Documentation/userspace-api/media/dvb/audio-stop.rst b/Documentation/userspace-api/media/dvb/audio-stop.rst deleted file mode 100644 index d77f786fd797..000000000000 --- a/Documentation/userspace-api/media/dvb/audio-stop.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.audio - -.. _AUDIO_STOP: - -========== -AUDIO_STOP -========== - -Name ----- - -AUDIO_STOP - -.. attention:: This ioctl is deprecated - -Synopsis --------- - -.. c:macro:: AUDIO_STOP - -``int ioctl(int fd, AUDIO_STOP)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This ioctl call asks the Audio Device to stop playing the current -stream. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/audio.rst b/Documentation/userspace-api/media/dvb/audio.rst deleted file mode 100644 index eaae5675a47d..000000000000 --- a/Documentation/userspace-api/media/dvb/audio.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _dvb_audio: - -####################### -Digital TV Audio Device -####################### - -The Digital TV audio device controls the MPEG2 audio decoder of the Digital -TV hardware. It can be accessed through ``/dev/dvb/adapter?/audio?``. Data -types and ioctl definitions can be accessed by including -``linux/dvb/audio.h`` in your application. - -Please note that some Digital TV cards don’t have their own MPEG decoder, which -results in the omission of the audio and video device. - -These ioctls were also used by V4L2 to control MPEG decoders implemented -in V4L2. The use of these ioctls for that purpose has been made obsolete -and proper V4L2 ioctls or controls have been created to replace that -functionality. - - -.. toctree:: - :maxdepth: 1 - - audio_data_types - audio_function_calls diff --git a/Documentation/userspace-api/media/dvb/audio_data_types.rst b/Documentation/userspace-api/media/dvb/audio_data_types.rst deleted file mode 100644 index 4744529136a8..000000000000 --- a/Documentation/userspace-api/media/dvb/audio_data_types.rst +++ /dev/null @@ -1,116 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _audio_data_types: - -**************** -Audio Data Types -**************** - -This section describes the structures, data types and defines used when -talking to the audio device. - -.. c:type:: audio_stream_source - -The audio stream source is set through the AUDIO_SELECT_SOURCE call -and can take the following values, depending on whether we are replaying -from an internal (demux) or external (user write) source. - - -.. code-block:: c - - typedef enum { - AUDIO_SOURCE_DEMUX, - AUDIO_SOURCE_MEMORY - } audio_stream_source_t; - -AUDIO_SOURCE_DEMUX selects the demultiplexer (fed either by the -frontend or the DVR device) as the source of the video stream. If -AUDIO_SOURCE_MEMORY is selected the stream comes from the application -through the ``write()`` system call. - - -.. c:type:: audio_play_state - -The following values can be returned by the AUDIO_GET_STATUS call -representing the state of audio playback. - - -.. code-block:: c - - typedef enum { - AUDIO_STOPPED, - AUDIO_PLAYING, - AUDIO_PAUSED - } audio_play_state_t; - - -.. c:type:: audio_channel_select - -The audio channel selected via AUDIO_CHANNEL_SELECT is determined by -the following values. - - -.. code-block:: c - - typedef enum { - AUDIO_STEREO, - AUDIO_MONO_LEFT, - AUDIO_MONO_RIGHT, - AUDIO_MONO, - AUDIO_STEREO_SWAPPED - } audio_channel_select_t; - - -.. c:type:: audio_status - -The AUDIO_GET_STATUS call returns the following structure informing -about various states of the playback operation. - - -.. code-block:: c - - typedef struct audio_status { - boolean AV_sync_state; - boolean mute_state; - audio_play_state_t play_state; - audio_stream_source_t stream_source; - audio_channel_select_t channel_select; - boolean bypass_mode; - audio_mixer_t mixer_state; - } audio_status_t; - - -.. c:type:: audio_mixer - -The following structure is used by the AUDIO_SET_MIXER call to set the -audio volume. - - -.. code-block:: c - - typedef struct audio_mixer { - unsigned int volume_left; - unsigned int volume_right; - } audio_mixer_t; - - -.. _audio_encodings: - -audio encodings -=============== - -A call to AUDIO_GET_CAPABILITIES returns an unsigned integer with the -following bits set according to the hardwares capabilities. - - -.. code-block:: c - - #define AUDIO_CAP_DTS 1 - #define AUDIO_CAP_LPCM 2 - #define AUDIO_CAP_MP1 4 - #define AUDIO_CAP_MP2 8 - #define AUDIO_CAP_MP3 16 - #define AUDIO_CAP_AAC 32 - #define AUDIO_CAP_OGG 64 - #define AUDIO_CAP_SDDS 128 - #define AUDIO_CAP_AC3 256 diff --git a/Documentation/userspace-api/media/dvb/audio_function_calls.rst b/Documentation/userspace-api/media/dvb/audio_function_calls.rst deleted file mode 100644 index fa5ba9539caf..000000000000 --- a/Documentation/userspace-api/media/dvb/audio_function_calls.rst +++ /dev/null @@ -1,30 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _audio_function_calls: - -******************** -Audio Function Calls -******************** - -.. toctree:: - :maxdepth: 1 - - audio-fopen - audio-fclose - audio-fwrite - audio-stop - audio-play - audio-pause - audio-continue - audio-select-source - audio-set-mute - audio-set-av-sync - audio-set-bypass-mode - audio-channel-select - audio-bilingual-channel-select - audio-get-status - audio-get-capabilities - audio-clear-buffer - audio-set-id - audio-set-mixer - audio-set-streamtype diff --git a/Documentation/userspace-api/media/dvb/dmx-fopen.rst b/Documentation/userspace-api/media/dvb/dmx-fopen.rst index 8f0a2b831d4a..50b36eb4371e 100644 --- a/Documentation/userspace-api/media/dvb/dmx-fopen.rst +++ b/Documentation/userspace-api/media/dvb/dmx-fopen.rst @@ -82,7 +82,7 @@ appropriately. :widths: 1 16 - - ``EMFILE`` - - “Too many open files”, i.e. no more filters available. + - "Too many open files", i.e. no more filters available. The generic error codes are described at the :ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/dmx-fread.rst b/Documentation/userspace-api/media/dvb/dmx-fread.rst index 78e9daef595a..88c4cddf7c30 100644 --- a/Documentation/userspace-api/media/dvb/dmx-fread.rst +++ b/Documentation/userspace-api/media/dvb/dmx-fread.rst @@ -34,7 +34,7 @@ Description This system call returns filtered data, which might be section or Packetized Elementary Stream (PES) data. The filtered data is transferred from -the driver’s internal circular buffer to ``buf``. The maximum amount of data +the driver's internal circular buffer to ``buf``. The maximum amount of data to be transferred is implied by count. .. note:: diff --git a/Documentation/userspace-api/media/dvb/dmx-set-filter.rst b/Documentation/userspace-api/media/dvb/dmx-set-filter.rst index f43455b7adae..1b8c8071b14f 100644 --- a/Documentation/userspace-api/media/dvb/dmx-set-filter.rst +++ b/Documentation/userspace-api/media/dvb/dmx-set-filter.rst @@ -37,7 +37,7 @@ parameters provided. A timeout may be defined stating number of seconds to wait for a section to be loaded. A value of 0 means that no timeout should be applied. Finally there is a flag field where it is possible to state whether a section should be CRC-checked, whether the filter should -be a ”one-shot” filter, i.e. if the filtering operation should be +be a "one-shot" filter, i.e. if the filtering operation should be stopped after the first section is received, and whether the filtering operation should be started immediately (without waiting for a :ref:`DMX_START` ioctl call). If a filter was previously set-up, this diff --git a/Documentation/userspace-api/media/dvb/headers.rst b/Documentation/userspace-api/media/dvb/headers.rst index 9743ffc35096..88c3eb33a89e 100644 --- a/Documentation/userspace-api/media/dvb/headers.rst +++ b/Documentation/userspace-api/media/dvb/headers.rst @@ -14,10 +14,3 @@ Digital TV uAPI headers .. kernel-include:: $BUILDDIR/ca.h.rst .. kernel-include:: $BUILDDIR/net.h.rst - -Legacy uAPI -*********** - -.. kernel-include:: $BUILDDIR/audio.h.rst - -.. kernel-include:: $BUILDDIR/video.h.rst diff --git a/Documentation/userspace-api/media/dvb/intro.rst b/Documentation/userspace-api/media/dvb/intro.rst index a935f3914e56..6784ae79657c 100644 --- a/Documentation/userspace-api/media/dvb/intro.rst +++ b/Documentation/userspace-api/media/dvb/intro.rst @@ -107,7 +107,7 @@ Audio and video decoder a Systems on a Chip (SoC) integrated circuit. It may also not be needed for certain usages (e.g. for data-only - uses like “internet over satellite”). + uses like "internet over satellite"). :ref:`stb_components` shows a crude schematic of the control and data flow between those components. @@ -148,9 +148,9 @@ individual devices are called: - ``/dev/dvb/adapterN/caM``, -where ``N`` enumerates the Digital TV cards in a system starting from 0, and +where ``N`` enumerates the Digital TV cards in a system starting from 0, and ``M`` enumerates the devices of each type within each adapter, starting -from 0, too. We will omit the “``/dev/dvb/adapterN/``\ ” in the further +from 0, too. We will omit the "``/dev/dvb/adapterN/``\ " in the further discussion of these devices. More details about the data structures and function calls of all the diff --git a/Documentation/userspace-api/media/dvb/legacy_dvb_apis.rst b/Documentation/userspace-api/media/dvb/legacy_dvb_apis.rst index 6104879d728a..b97d56ee543c 100644 --- a/Documentation/userspace-api/media/dvb/legacy_dvb_apis.rst +++ b/Documentation/userspace-api/media/dvb/legacy_dvb_apis.rst @@ -11,11 +11,6 @@ The APIs described here **should not** be used on new drivers or applications. The DVBv3 frontend API has issues with new delivery systems, including DVB-S2, DVB-T2, ISDB, etc. -There's just one driver for a very legacy hardware using the Digital TV -audio and video APIs. No modern drivers should use it. Instead, audio and -video should be using the V4L2 and ALSA APIs, and the pipelines should -be set via the Media Controller API. - .. attention:: The APIs described here doesn't necessarily reflect the current @@ -28,5 +23,3 @@ be set via the Media Controller API. :maxdepth: 1 frontend_legacy_dvbv3_api - video - audio diff --git a/Documentation/userspace-api/media/dvb/video-clear-buffer.rst b/Documentation/userspace-api/media/dvb/video-clear-buffer.rst deleted file mode 100644 index a7730559bbb2..000000000000 --- a/Documentation/userspace-api/media/dvb/video-clear-buffer.rst +++ /dev/null @@ -1,54 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_CLEAR_BUFFER: - -================== -VIDEO_CLEAR_BUFFER -================== - -Name ----- - -VIDEO_CLEAR_BUFFER - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_CLEAR_BUFFER - -``int ioctl(fd, VIDEO_CLEAR_BUFFER)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_CLEAR_BUFFER for this command. - -Description ------------ - -This ioctl call clears all video buffers in the driver and in the -decoder hardware. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-command.rst b/Documentation/userspace-api/media/dvb/video-command.rst deleted file mode 100644 index cae9445eb3af..000000000000 --- a/Documentation/userspace-api/media/dvb/video-command.rst +++ /dev/null @@ -1,96 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_COMMAND: - -============= -VIDEO_COMMAND -============= - -Name ----- - -VIDEO_COMMAND - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_COMMAND - -``int ioctl(int fd, VIDEO_COMMAND, struct video_command *cmd)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_COMMAND for this command. - - - .. row 3 - - - struct video_command \*cmd - - - Commands the decoder. - -Description ------------ - -This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders -this ioctl has been replaced by the -:ref:`VIDIOC_DECODER_CMD` ioctl. - -This ioctl commands the decoder. The ``video_command`` struct is a -subset of the ``v4l2_decoder_cmd`` struct, so refer to the -:ref:`VIDIOC_DECODER_CMD` documentation for -more information. - -.. c:type:: video_command - -.. code-block:: c - - /* The structure must be zeroed before use by the application - This ensures it can be extended safely in the future. */ - struct video_command { - __u32 cmd; - __u32 flags; - union { - struct { - __u64 pts; - } stop; - - struct { - /* 0 or 1000 specifies normal speed, - 1 specifies forward single stepping, - -1 specifies backward single stepping, - >1: playback at speed/1000 of the normal speed, - <-1: reverse playback at (-speed/1000) of the normal speed. */ - __s32 speed; - __u32 format; - } play; - - struct { - __u32 data[16]; - } raw; - }; - }; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-continue.rst b/Documentation/userspace-api/media/dvb/video-continue.rst deleted file mode 100644 index bc34bf3989e4..000000000000 --- a/Documentation/userspace-api/media/dvb/video-continue.rst +++ /dev/null @@ -1,57 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_CONTINUE: - -============== -VIDEO_CONTINUE -============== - -Name ----- - -VIDEO_CONTINUE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_CONTINUE - -``int ioctl(fd, VIDEO_CONTINUE)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_CONTINUE for this command. - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 :ref:`VIDIOC_DECODER_CMD` instead. - -This ioctl call restarts decoding and playing processes of the video -stream which was played before a call to VIDEO_FREEZE was made. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-fast-forward.rst b/Documentation/userspace-api/media/dvb/video-fast-forward.rst deleted file mode 100644 index e71fa8d6965b..000000000000 --- a/Documentation/userspace-api/media/dvb/video-fast-forward.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_FAST_FORWARD: - -================== -VIDEO_FAST_FORWARD -================== - -Name ----- - -VIDEO_FAST_FORWARD - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_FAST_FORWARD - -``int ioctl(fd, VIDEO_FAST_FORWARD, int nFrames)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_FAST_FORWARD for this command. - - - .. row 3 - - - int nFrames - - - The number of frames to skip. - -Description ------------ - -This ioctl call asks the Video Device to skip decoding of N number of -I-frames. This call can only be used if VIDEO_SOURCE_MEMORY is -selected. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. - - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EPERM`` - - - Mode VIDEO_SOURCE_MEMORY not selected. diff --git a/Documentation/userspace-api/media/dvb/video-fclose.rst b/Documentation/userspace-api/media/dvb/video-fclose.rst deleted file mode 100644 index 01d24d548439..000000000000 --- a/Documentation/userspace-api/media/dvb/video-fclose.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _video_fclose: - -================= -dvb video close() -================= - -Name ----- - -dvb video close() - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:function:: int close(int fd) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - -Description ------------ - -This system call closes a previously opened video device. - -Return Value ------------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EBADF`` - - - fd is not a valid open file descriptor. diff --git a/Documentation/userspace-api/media/dvb/video-fopen.rst b/Documentation/userspace-api/media/dvb/video-fopen.rst deleted file mode 100644 index 1371b083e4e8..000000000000 --- a/Documentation/userspace-api/media/dvb/video-fopen.rst +++ /dev/null @@ -1,111 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _video_fopen: - -================ -dvb video open() -================ - -Name ----- - -dvb video open() - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:function:: int open(const char *deviceName, int flags) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - const char \*deviceName - - - Name of specific video device. - - - .. row 2 - - - int flags - - - A bit-wise OR of the following flags: - - - .. row 3 - - - - - O_RDONLY read-only access - - - .. row 4 - - - - - O_RDWR read/write access - - - .. row 5 - - - - - O_NONBLOCK open in non-blocking mode - - - .. row 6 - - - - - (blocking mode is the default) - -Description ------------ - -This system call opens a named video device (e.g. -/dev/dvb/adapter0/video0) for subsequent use. - -When an open() call has succeeded, the device will be ready for use. The -significance of blocking or non-blocking mode is described in the -documentation for functions where there is a difference. It does not -affect the semantics of the open() call itself. A device opened in -blocking mode can later be put into non-blocking mode (and vice versa) -using the F_SETFL command of the fcntl system call. This is a standard -system call, documented in the Linux manual page for fcntl. Only one -user can open the Video Device in O_RDWR mode. All other attempts to -open the device in this mode will fail, and an error-code will be -returned. If the Video Device is opened in O_RDONLY mode, the only -ioctl call that can be used is VIDEO_GET_STATUS. All other call will -return an error code. - -Return Value ------------- - -.. tabularcolumns:: |p{2.5cm}|p{15.0cm}| - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``ENODEV`` - - - Device driver not loaded/available. - - - .. row 2 - - - ``EINTERNAL`` - - - Internal error. - - - .. row 3 - - - ``EBUSY`` - - - Device or resource busy. - - - .. row 4 - - - ``EINVAL`` - - - Invalid argument. diff --git a/Documentation/userspace-api/media/dvb/video-freeze.rst b/Documentation/userspace-api/media/dvb/video-freeze.rst deleted file mode 100644 index 4321f257cb70..000000000000 --- a/Documentation/userspace-api/media/dvb/video-freeze.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_FREEZE: - -============ -VIDEO_FREEZE -============ - -Name ----- - -VIDEO_FREEZE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_FREEZE - -``int ioctl(fd, VIDEO_FREEZE)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_FREEZE for this command. - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 :ref:`VIDIOC_DECODER_CMD` instead. - -This ioctl call suspends the live video stream being played. Decoding -and playing are frozen. It is then possible to restart the decoding and -playing process of the video stream using the VIDEO_CONTINUE command. -If VIDEO_SOURCE_MEMORY is selected in the ioctl call -VIDEO_SELECT_SOURCE, the Digital TV subsystem will not decode any more data -until the ioctl call VIDEO_CONTINUE or VIDEO_PLAY is performed. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-fwrite.rst b/Documentation/userspace-api/media/dvb/video-fwrite.rst deleted file mode 100644 index a07fd7d7a40e..000000000000 --- a/Documentation/userspace-api/media/dvb/video-fwrite.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _video_fwrite: - -================= -dvb video write() -================= - -Name ----- - -dvb video write() - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:function:: size_t write(int fd, const void *buf, size_t count) - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - void \*buf - - - Pointer to the buffer containing the PES data. - - - .. row 3 - - - size_t count - - - Size of buf. - -Description ------------ - -This system call can only be used if VIDEO_SOURCE_MEMORY is selected -in the ioctl call VIDEO_SELECT_SOURCE. The data provided shall be in -PES format, unless the capability allows other formats. If O_NONBLOCK -is not specified the function will block until buffer space is -available. The amount of data to be transferred is implied by count. - -Return Value ------------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EPERM`` - - - Mode VIDEO_SOURCE_MEMORY not selected. - - - .. row 2 - - - ``ENOMEM`` - - - Attempted to write more data than the internal buffer can hold. - - - .. row 3 - - - ``EBADF`` - - - fd is not a valid open file descriptor. diff --git a/Documentation/userspace-api/media/dvb/video-get-capabilities.rst b/Documentation/userspace-api/media/dvb/video-get-capabilities.rst deleted file mode 100644 index 01e09f56656c..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-capabilities.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_CAPABILITIES: - -====================== -VIDEO_GET_CAPABILITIES -====================== - -Name ----- - -VIDEO_GET_CAPABILITIES - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_CAPABILITIES - -``int ioctl(fd, VIDEO_GET_CAPABILITIES, unsigned int *cap)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_CAPABILITIES for this command. - - - .. row 3 - - - unsigned int \*cap - - - Pointer to a location where to store the capability information. - -Description ------------ - -This ioctl call asks the video device about its decoding capabilities. -On success it returns and integer which has bits set according to the -defines in section ??. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-get-event.rst b/Documentation/userspace-api/media/dvb/video-get-event.rst deleted file mode 100644 index 90382bc36cfe..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-event.rst +++ /dev/null @@ -1,105 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_EVENT: - -=============== -VIDEO_GET_EVENT -=============== - -Name ----- - -VIDEO_GET_EVENT - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_EVENT - -``int ioctl(fd, VIDEO_GET_EVENT, struct video_event *ev)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_EVENT for this command. - - - .. row 3 - - - struct video_event \*ev - - - Points to the location where the event, if any, is to be stored. - -Description ------------ - -This ioctl is for Digital TV devices only. To get events from a V4L2 decoder -use the V4L2 :ref:`VIDIOC_DQEVENT` ioctl instead. - -This ioctl call returns an event of type video_event if available. If -an event is not available, the behavior depends on whether the device is -in blocking or non-blocking mode. In the latter case, the call fails -immediately with errno set to ``EWOULDBLOCK``. In the former case, the call -blocks until an event becomes available. The standard Linux poll() -and/or select() system calls can be used with the device file descriptor -to watch for new events. For select(), the file descriptor should be -included in the exceptfds argument, and for poll(), POLLPRI should be -specified as the wake-up condition. Read-only permissions are sufficient -for this ioctl call. - -.. c:type:: video_event - -.. code-block:: c - - struct video_event { - __s32 type; - #define VIDEO_EVENT_SIZE_CHANGED 1 - #define VIDEO_EVENT_FRAME_RATE_CHANGED 2 - #define VIDEO_EVENT_DECODER_STOPPED 3 - #define VIDEO_EVENT_VSYNC 4 - long timestamp; - union { - video_size_t size; - unsigned int frame_rate; /* in frames per 1000sec */ - unsigned char vsync_field; /* unknown/odd/even/progressive */ - } u; - }; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EWOULDBLOCK`` - - - There is no event pending, and the device is in non-blocking mode. - - - .. row 2 - - - ``EOVERFLOW`` - - - Overflow in event queue - one or more events were lost. diff --git a/Documentation/userspace-api/media/dvb/video-get-frame-count.rst b/Documentation/userspace-api/media/dvb/video-get-frame-count.rst deleted file mode 100644 index b48ac8c58a41..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-frame-count.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_FRAME_COUNT: - -===================== -VIDEO_GET_FRAME_COUNT -===================== - -Name ----- - -VIDEO_GET_FRAME_COUNT - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_FRAME_COUNT - -``int ioctl(int fd, VIDEO_GET_FRAME_COUNT, __u64 *pts)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_FRAME_COUNT for this command. - - - .. row 3 - - - __u64 \*pts - - - Returns the number of frames displayed since the decoder was - started. - -Description ------------ - -This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders -this ioctl has been replaced by the ``V4L2_CID_MPEG_VIDEO_DEC_FRAME`` -control. - -This ioctl call asks the Video Device to return the number of displayed -frames since the decoder was started. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-get-pts.rst b/Documentation/userspace-api/media/dvb/video-get-pts.rst deleted file mode 100644 index fedaff41be0b..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-pts.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_PTS: - -============= -VIDEO_GET_PTS -============= - -Name ----- - -VIDEO_GET_PTS - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_PTS - -``int ioctl(int fd, VIDEO_GET_PTS, __u64 *pts)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_PTS for this command. - - - .. row 3 - - - __u64 \*pts - - - Returns the 33-bit timestamp as defined in ITU T-REC-H.222.0 / - ISO/IEC 13818-1. - - The PTS should belong to the currently played frame if possible, - but may also be a value close to it like the PTS of the last - decoded frame or the last PTS extracted by the PES parser. - -Description ------------ - -This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders -this ioctl has been replaced by the ``V4L2_CID_MPEG_VIDEO_DEC_PTS`` -control. - -This ioctl call asks the Video Device to return the current PTS -timestamp. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-get-size.rst b/Documentation/userspace-api/media/dvb/video-get-size.rst deleted file mode 100644 index de34331c5bd1..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-size.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_SIZE: - -============== -VIDEO_GET_SIZE -============== - -Name ----- - -VIDEO_GET_SIZE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_SIZE - -``int ioctl(int fd, VIDEO_GET_SIZE, video_size_t *size)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_SIZE for this command. - - - .. row 3 - - - video_size_t \*size - - - Returns the size and aspect ratio. - -Description ------------ - -This ioctl returns the size and aspect ratio. - -.. c:type:: video_size_t - -.. code-block::c - - typedef struct { - int w; - int h; - video_format_t aspect_ratio; - } video_size_t; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-get-status.rst b/Documentation/userspace-api/media/dvb/video-get-status.rst deleted file mode 100644 index 9b86fbf411d4..000000000000 --- a/Documentation/userspace-api/media/dvb/video-get-status.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_GET_STATUS: - -================ -VIDEO_GET_STATUS -================ - -Name ----- - -VIDEO_GET_STATUS - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_GET_STATUS - -``int ioctl(fd, VIDEO_GET_STATUS, struct video_status *status)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_GET_STATUS for this command. - - - .. row 3 - - - struct video_status \*status - - - Returns the current status of the Video Device. - -Description ------------ - -This ioctl call asks the Video Device to return the current status of -the device. - -.. c:type:: video_status - -.. code-block:: c - - struct video_status { - int video_blank; /* blank video on freeze? */ - video_play_state_t play_state; /* current state of playback */ - video_stream_source_t stream_source; /* current source (demux/memory) */ - video_format_t video_format; /* current aspect ratio of stream*/ - video_displayformat_t display_format;/* selected cropping mode */ - }; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-play.rst b/Documentation/userspace-api/media/dvb/video-play.rst deleted file mode 100644 index 35ac8b98fdbf..000000000000 --- a/Documentation/userspace-api/media/dvb/video-play.rst +++ /dev/null @@ -1,57 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_PLAY: - -========== -VIDEO_PLAY -========== - -Name ----- - -VIDEO_PLAY - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_PLAY - -``int ioctl(fd, VIDEO_PLAY)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_PLAY for this command. - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 :ref:`VIDIOC_DECODER_CMD` instead. - -This ioctl call asks the Video Device to start playing a video stream -from the selected source. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-select-source.rst b/Documentation/userspace-api/media/dvb/video-select-source.rst deleted file mode 100644 index 929a20985d53..000000000000 --- a/Documentation/userspace-api/media/dvb/video-select-source.rst +++ /dev/null @@ -1,76 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SELECT_SOURCE: - -=================== -VIDEO_SELECT_SOURCE -=================== - -Name ----- - -VIDEO_SELECT_SOURCE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SELECT_SOURCE - -``int ioctl(fd, VIDEO_SELECT_SOURCE, video_stream_source_t source)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SELECT_SOURCE for this command. - - - .. row 3 - - - video_stream_source_t source - - - Indicates which source shall be used for the Video stream. - -Description ------------ - -This ioctl is for Digital TV devices only. This ioctl was also supported by the -V4L2 ivtv driver, but that has been replaced by the ivtv-specific -``IVTV_IOC_PASSTHROUGH_MODE`` ioctl. - -This ioctl call informs the video device which source shall be used for -the input data. The possible sources are demux or memory. If memory is -selected, the data is fed to the video device through the write command. - -.. c:type:: video_stream_source_t - -.. code-block:: c - - typedef enum { - VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */ - VIDEO_SOURCE_MEMORY /* If this source is selected, the stream - comes from the user through the write - system call */ - } video_stream_source_t; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-set-blank.rst b/Documentation/userspace-api/media/dvb/video-set-blank.rst deleted file mode 100644 index 70249a6ba125..000000000000 --- a/Documentation/userspace-api/media/dvb/video-set-blank.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SET_BLANK: - -=============== -VIDEO_SET_BLANK -=============== - -Name ----- - -VIDEO_SET_BLANK - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SET_BLANK - -``int ioctl(fd, VIDEO_SET_BLANK, boolean mode)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SET_BLANK for this command. - - - .. row 3 - - - boolean mode - - - TRUE: Blank screen when stop. - - - .. row 4 - - - - - FALSE: Show last decoded frame. - -Description ------------ - -This ioctl call asks the Video Device to blank out the picture. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-set-display-format.rst b/Documentation/userspace-api/media/dvb/video-set-display-format.rst deleted file mode 100644 index 1de4f40ae732..000000000000 --- a/Documentation/userspace-api/media/dvb/video-set-display-format.rst +++ /dev/null @@ -1,60 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SET_DISPLAY_FORMAT: - -======================== -VIDEO_SET_DISPLAY_FORMAT -======================== - -Name ----- - -VIDEO_SET_DISPLAY_FORMAT - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SET_DISPLAY_FORMAT - -``int ioctl(fd, VIDEO_SET_DISPLAY_FORMAT)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SET_DISPLAY_FORMAT for this command. - - - .. row 3 - - - video_display_format_t format - - - Selects the video format to be used. - -Description ------------ - -This ioctl call asks the Video Device to select the video format to be -applied by the MPEG chip on the video. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-set-format.rst b/Documentation/userspace-api/media/dvb/video-set-format.rst deleted file mode 100644 index bb64e37ae081..000000000000 --- a/Documentation/userspace-api/media/dvb/video-set-format.rst +++ /dev/null @@ -1,82 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SET_FORMAT: - -================ -VIDEO_SET_FORMAT -================ - -Name ----- - -VIDEO_SET_FORMAT - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SET_FORMAT - -``int ioctl(fd, VIDEO_SET_FORMAT, video_format_t format)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SET_FORMAT for this command. - - - .. row 3 - - - video_format_t format - - - video format of TV as defined in section ??. - -Description ------------ - -This ioctl sets the screen format (aspect ratio) of the connected output -device (TV) so that the output of the decoder can be adjusted -accordingly. - -.. c:type:: video_format_t - -.. code-block:: c - - typedef enum { - VIDEO_FORMAT_4_3, /* Select 4:3 format */ - VIDEO_FORMAT_16_9, /* Select 16:9 format. */ - VIDEO_FORMAT_221_1 /* 2.21:1 */ - } video_format_t; - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. - - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EINVAL`` - - - format is not a valid video format. diff --git a/Documentation/userspace-api/media/dvb/video-set-streamtype.rst b/Documentation/userspace-api/media/dvb/video-set-streamtype.rst deleted file mode 100644 index 1f31c048bdbc..000000000000 --- a/Documentation/userspace-api/media/dvb/video-set-streamtype.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SET_STREAMTYPE: - -==================== -VIDEO_SET_STREAMTYPE -==================== - -Name ----- - -VIDEO_SET_STREAMTYPE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SET_STREAMTYPE - -``int ioctl(fd, VIDEO_SET_STREAMTYPE, int type)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SET_STREAMTYPE for this command. - - - .. row 3 - - - int type - - - stream type - -Description ------------ - -This ioctl tells the driver which kind of stream to expect being written -to it. If this call is not used the default of video PES is used. Some -drivers might not support this call and always expect PES. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-slowmotion.rst b/Documentation/userspace-api/media/dvb/video-slowmotion.rst deleted file mode 100644 index 1478fcc30cb8..000000000000 --- a/Documentation/userspace-api/media/dvb/video-slowmotion.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_SLOWMOTION: - -================ -VIDEO_SLOWMOTION -================ - -Name ----- - -VIDEO_SLOWMOTION - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_SLOWMOTION - -``int ioctl(fd, VIDEO_SLOWMOTION, int nFrames)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_SLOWMOTION for this command. - - - .. row 3 - - - int nFrames - - - The number of times to repeat each frame. - -Description ------------ - -This ioctl call asks the video device to repeat decoding frames N number -of times. This call can only be used if VIDEO_SOURCE_MEMORY is -selected. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. - - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - ``EPERM`` - - - Mode VIDEO_SOURCE_MEMORY not selected. diff --git a/Documentation/userspace-api/media/dvb/video-stillpicture.rst b/Documentation/userspace-api/media/dvb/video-stillpicture.rst deleted file mode 100644 index d25384222a20..000000000000 --- a/Documentation/userspace-api/media/dvb/video-stillpicture.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_STILLPICTURE: - -================== -VIDEO_STILLPICTURE -================== - -Name ----- - -VIDEO_STILLPICTURE - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_STILLPICTURE - -``int ioctl(fd, VIDEO_STILLPICTURE, struct video_still_picture *sp)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_STILLPICTURE for this command. - - - .. row 3 - - - struct video_still_picture \*sp - - - Pointer to a location where an I-frame and size is stored. - -Description ------------ - -This ioctl call asks the Video Device to display a still picture -(I-frame). The input data shall contain an I-frame. If the pointer is -NULL, then the current displayed still picture is blanked. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-stop.rst b/Documentation/userspace-api/media/dvb/video-stop.rst deleted file mode 100644 index 96f61c5b48a2..000000000000 --- a/Documentation/userspace-api/media/dvb/video-stop.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_STOP: - -========== -VIDEO_STOP -========== - -Name ----- - -VIDEO_STOP - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_STOP - -``int ioctl(fd, VIDEO_STOP, boolean mode)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_STOP for this command. - - - .. row 3 - - - Boolean mode - - - Indicates how the screen shall be handled. - - - .. row 4 - - - - - TRUE: Blank screen when stop. - - - .. row 5 - - - - - FALSE: Show last decoded frame. - -Description ------------ - -This ioctl is for Digital TV devices only. To control a V4L2 decoder use the -V4L2 :ref:`VIDIOC_DECODER_CMD` instead. - -This ioctl call asks the Video Device to stop playing the current -stream. Depending on the input parameter, the screen can be blanked out -or displaying the last decoded frame. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video-try-command.rst b/Documentation/userspace-api/media/dvb/video-try-command.rst deleted file mode 100644 index 79bf3dfb8a32..000000000000 --- a/Documentation/userspace-api/media/dvb/video-try-command.rst +++ /dev/null @@ -1,66 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later -.. c:namespace:: DTV.video - -.. _VIDEO_TRY_COMMAND: - -================= -VIDEO_TRY_COMMAND -================= - -Name ----- - -VIDEO_TRY_COMMAND - -.. attention:: This ioctl is deprecated. - -Synopsis --------- - -.. c:macro:: VIDEO_TRY_COMMAND - -``int ioctl(int fd, VIDEO_TRY_COMMAND, struct video_command *cmd)`` - -Arguments ---------- - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - - - .. row 1 - - - int fd - - - File descriptor returned by a previous call to open(). - - - .. row 2 - - - int request - - - Equals VIDEO_TRY_COMMAND for this command. - - - .. row 3 - - - struct video_command \*cmd - - - Try a decoder command. - -Description ------------ - -This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders -this ioctl has been replaced by the -:ref:`VIDIOC_TRY_DECODER_CMD <VIDIOC_DECODER_CMD>` ioctl. - -This ioctl tries a decoder command. The ``video_command`` struct is a -subset of the ``v4l2_decoder_cmd`` struct, so refer to the -:ref:`VIDIOC_TRY_DECODER_CMD <VIDIOC_DECODER_CMD>` documentation -for more information. - -Return Value ------------- - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/dvb/video.rst b/Documentation/userspace-api/media/dvb/video.rst deleted file mode 100644 index 38a8d39a1d25..000000000000 --- a/Documentation/userspace-api/media/dvb/video.rst +++ /dev/null @@ -1,36 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _dvb_video: - -####################### -Digital TV Video Device -####################### - -The Digital TV video device controls the MPEG2 video decoder of the Digital -TV hardware. It can be accessed through **/dev/dvb/adapter0/video0**. Data -types and ioctl definitions can be accessed by including -**linux/dvb/video.h** in your application. - -Note that the Digital TV video device only controls decoding of the MPEG video -stream, not its presentation on the TV or computer screen. On PCs this -is typically handled by an associated video4linux device, e.g. -**/dev/video**, which allows scaling and defining output windows. - -Some Digital TV cards don’t have their own MPEG decoder, which results in the -omission of the audio and video device as well as the video4linux -device. - -The ioctls that deal with SPUs (sub picture units) and navigation -packets are only supported on some MPEG decoders made for DVD playback. - -These ioctls were also used by V4L2 to control MPEG decoders implemented -in V4L2. The use of these ioctls for that purpose has been made obsolete -and proper V4L2 ioctls or controls have been created to replace that -functionality. - - -.. toctree:: - :maxdepth: 1 - - video_types - video_function_calls diff --git a/Documentation/userspace-api/media/dvb/video_function_calls.rst b/Documentation/userspace-api/media/dvb/video_function_calls.rst deleted file mode 100644 index 20a897be5dca..000000000000 --- a/Documentation/userspace-api/media/dvb/video_function_calls.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _video_function_calls: - -******************** -Video Function Calls -******************** - -.. toctree:: - :maxdepth: 1 - - video-fopen - video-fclose - video-fwrite - video-stop - video-play - video-freeze - video-continue - video-select-source - video-set-blank - video-get-status - video-get-frame-count - video-get-pts - video-get-event - video-command - video-try-command - video-get-size - video-set-display-format - video-stillpicture - video-fast-forward - video-slowmotion - video-get-capabilities - video-clear-buffer - video-set-streamtype - video-set-format diff --git a/Documentation/userspace-api/media/dvb/video_types.rst b/Documentation/userspace-api/media/dvb/video_types.rst deleted file mode 100644 index c4557d328b7a..000000000000 --- a/Documentation/userspace-api/media/dvb/video_types.rst +++ /dev/null @@ -1,248 +0,0 @@ -.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later - -.. _video_types: - -**************** -Video Data Types -**************** - - -.. _video-format-t: - -video_format_t -============== - -The ``video_format_t`` data type defined by - - -.. code-block:: c - - typedef enum { - VIDEO_FORMAT_4_3, /* Select 4:3 format */ - VIDEO_FORMAT_16_9, /* Select 16:9 format. */ - VIDEO_FORMAT_221_1 /* 2.21:1 */ - } video_format_t; - -is used in the VIDEO_SET_FORMAT function (??) to tell the driver which -aspect ratio the output hardware (e.g. TV) has. It is also used in the -data structures video_status (??) returned by VIDEO_GET_STATUS (??) -and video_event (??) returned by VIDEO_GET_EVENT (??) which report -about the display format of the current video stream. - - -.. _video-displayformat-t: - -video_displayformat_t -===================== - -In case the display format of the video stream and of the display -hardware differ the application has to specify how to handle the -cropping of the picture. This can be done using the -VIDEO_SET_DISPLAY_FORMAT call (??) which accepts - - -.. code-block:: c - - typedef enum { - VIDEO_PAN_SCAN, /* use pan and scan format */ - VIDEO_LETTER_BOX, /* use letterbox format */ - VIDEO_CENTER_CUT_OUT /* use center cut out format */ - } video_displayformat_t; - -as argument. - - -.. _video-stream-source-t: - -video_stream_source_t -===================== - -The video stream source is set through the VIDEO_SELECT_SOURCE call -and can take the following values, depending on whether we are replaying -from an internal (demuxer) or external (user write) source. - - -.. code-block:: c - - typedef enum { - VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */ - VIDEO_SOURCE_MEMORY /* If this source is selected, the stream - comes from the user through the write - system call */ - } video_stream_source_t; - -VIDEO_SOURCE_DEMUX selects the demultiplexer (fed either by the -frontend or the DVR device) as the source of the video stream. If -VIDEO_SOURCE_MEMORY is selected the stream comes from the application -through the **write()** system call. - - -.. _video-play-state-t: - -video_play_state_t -================== - -The following values can be returned by the VIDEO_GET_STATUS call -representing the state of video playback. - - -.. code-block:: c - - typedef enum { - VIDEO_STOPPED, /* Video is stopped */ - VIDEO_PLAYING, /* Video is currently playing */ - VIDEO_FREEZED /* Video is freezed */ - } video_play_state_t; - - -.. c:type:: video_command - -struct video_command -==================== - -The structure must be zeroed before use by the application This ensures -it can be extended safely in the future. - - -.. code-block:: c - - struct video_command { - __u32 cmd; - __u32 flags; - union { - struct { - __u64 pts; - } stop; - - struct { - /* 0 or 1000 specifies normal speed, - 1 specifies forward single stepping, - -1 specifies backward single stepping, - >>1: playback at speed/1000 of the normal speed, - <-1: reverse playback at (-speed/1000) of the normal speed. */ - __s32 speed; - __u32 format; - } play; - - struct { - __u32 data[16]; - } raw; - }; - }; - - -.. _video-size-t: - -video_size_t -============ - - -.. code-block:: c - - typedef struct { - int w; - int h; - video_format_t aspect_ratio; - } video_size_t; - - -.. c:type:: video_event - -struct video_event -================== - -The following is the structure of a video event as it is returned by the -VIDEO_GET_EVENT call. - - -.. code-block:: c - - struct video_event { - __s32 type; - #define VIDEO_EVENT_SIZE_CHANGED 1 - #define VIDEO_EVENT_FRAME_RATE_CHANGED 2 - #define VIDEO_EVENT_DECODER_STOPPED 3 - #define VIDEO_EVENT_VSYNC 4 - long timestamp; - union { - video_size_t size; - unsigned int frame_rate; /* in frames per 1000sec */ - unsigned char vsync_field; /* unknown/odd/even/progressive */ - } u; - }; - - -.. c:type:: video_status - -struct video_status -=================== - -The VIDEO_GET_STATUS call returns the following structure informing -about various states of the playback operation. - - -.. code-block:: c - - struct video_status { - int video_blank; /* blank video on freeze? */ - video_play_state_t play_state; /* current state of playback */ - video_stream_source_t stream_source; /* current source (demux/memory) */ - video_format_t video_format; /* current aspect ratio of stream */ - video_displayformat_t display_format;/* selected cropping mode */ - }; - -If video_blank is set video will be blanked out if the channel is -changed or if playback is stopped. Otherwise, the last picture will be -displayed. play_state indicates if the video is currently frozen, -stopped, or being played back. The stream_source corresponds to the -selected source for the video stream. It can come either from the -demultiplexer or from memory. The video_format indicates the aspect -ratio (one of 4:3 or 16:9) of the currently played video stream. -Finally, display_format corresponds to the selected cropping mode in -case the source video format is not the same as the format of the output -device. - - -.. c:type:: video_still_picture - -struct video_still_picture -========================== - -An I-frame displayed via the VIDEO_STILLPICTURE call is passed on -within the following structure. - - -.. code-block:: c - - /* pointer to and size of a single iframe in memory */ - struct video_still_picture { - char *iFrame; /* pointer to a single iframe in memory */ - int32_t size; - }; - - -.. _video_caps: - -video capabilities -================== - -A call to VIDEO_GET_CAPABILITIES returns an unsigned integer with the -following bits set according to the hardwares capabilities. - - -.. code-block:: c - - /* bit definitions for capabilities: */ - /* can the hardware decode MPEG1 and/or MPEG2? */ - #define VIDEO_CAP_MPEG1 1 - #define VIDEO_CAP_MPEG2 2 - /* can you send a system and/or program stream to video device? - (you still have to open the video and the audio device but only - send the stream to the video device) */ - #define VIDEO_CAP_SYS 4 - #define VIDEO_CAP_PROG 8 - /* can the driver also handle SPU, NAVI and CSS encoded data? - (CSS API is not present yet) */ - #define VIDEO_CAP_SPU 16 - #define VIDEO_CAP_NAVI 32 - #define VIDEO_CAP_CSS 64 diff --git a/Documentation/userspace-api/media/fdl-appendix.rst b/Documentation/userspace-api/media/fdl-appendix.rst index 683ebed87017..b1bc725b4ec7 100644 --- a/Documentation/userspace-api/media/fdl-appendix.rst +++ b/Documentation/userspace-api/media/fdl-appendix.rst @@ -13,14 +13,14 @@ GNU Free Documentation License =========== The purpose of this License is to make a manual, textbook, or other -written document “free” in the sense of freedom: to assure everyone the +written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. -This License is a kind of “copyleft”, which means that derivative works +This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. @@ -44,21 +44,21 @@ works whose purpose is instruction or reference. This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the -terms of this License. The “Document”, below, refers to any such manual +terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as -“you”. +"you". .. _fdl-modified: -A “Modified Version” of the Document means any work containing the +A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. .. _fdl-secondary: -A “Secondary Section” is a named appendix or a front-matter section of +A "Secondary Section" is a named appendix or a front-matter section of the :ref:`Document <fdl-document>` that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing @@ -72,7 +72,7 @@ regarding them. .. _fdl-invariant: -The “Invariant Sections” are certain +The "Invariant Sections" are certain :ref:`Secondary Sections <fdl-secondary>` whose titles are designated, as being those of Invariant Sections, in the notice that says that the :ref:`Document <fdl-document>` is released under this License. @@ -80,14 +80,14 @@ as being those of Invariant Sections, in the notice that says that the .. _fdl-cover-texts: -The “Cover Texts” are certain short passages of text that are listed, as +The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the :ref:`Document <fdl-document>` is released under this License. .. _fdl-transparent: -A “Transparent” copy of the :ref:`Document <fdl-document>` means a +A "Transparent" copy of the :ref:`Document <fdl-document>` means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images @@ -97,7 +97,7 @@ formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is -not “Transparent” is called “Opaque”. +not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML @@ -111,10 +111,10 @@ word processors for output purposes only. .. _fdl-title-page: -The “Title Page” means, for a printed book, the title page itself, plus +The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which -do not have any title page as such, “Title Page” means the text near the +do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. @@ -242,11 +242,11 @@ Modified Version: Include an unaltered copy of this License. - **I.** - Preserve the section entitled “History”, and its title, and add to it + Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the :ref:`Modified Version <fdl-modified>` as given on the :ref:`Title Page <fdl-title-page>`. If there is no section entitled - “History” in the :ref:`Document <fdl-document>`, create one stating + "History" in the :ref:`Document <fdl-document>`, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. @@ -256,13 +256,13 @@ Modified Version: :ref:`Document <fdl-document>` for public access to a :ref:`Transparent <fdl-transparent>` copy of the Document, and likewise the network locations given in the Document for previous - versions it was based on. These may be placed in the “History” + versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. - **K.** - In any section entitled “Acknowledgements” or “Dedications”, preserve + In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. @@ -274,11 +274,11 @@ Modified Version: part of the section titles. - **M.** - Delete any section entitled “Endorsements”. Such a section may not be + Delete any section entitled "Endorsements". Such a section may not be included in the :ref:`Modified Version <fdl-modified>`. - **N.** - Do not retitle any existing section as “Endorsements” or to conflict + Do not retitle any existing section as "Endorsements" or to conflict in title with any :ref:`Invariant Section <fdl-invariant>`. If the :ref:`Modified Version <fdl-modified>` includes new @@ -290,7 +290,7 @@ of :ref:`Invariant Sections <fdl-invariant>` in the Modified Version's license notice. These titles must be distinct from any other section titles. -You may add a section entitled “Endorsements”, provided it contains +You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your :ref:`Modified Version <fdl-modified>` by various parties--for example, statements of peer review or that the text has been approved by @@ -337,11 +337,11 @@ the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. -In the combination, you must combine any sections entitled “History” in -the various original documents, forming one section entitled “History”; -likewise combine any sections entitled “Acknowledgements”, and any -sections entitled “Dedications”. You must delete all sections entitled -“Endorsements.” +In the combination, you must combine any sections entitled "History" in +the various original documents, forming one section entitled "History"; +likewise combine any sections entitled "Acknowledgements", and any +sections entitled "Dedications". You must delete all sections entitled +"Endorsements." .. _fdl-section6: @@ -372,7 +372,7 @@ with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a :ref:`Modified Version <fdl-modified>` of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation -is called an “aggregate”, and this License does not apply to the other +is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document , on account of their being thus compiled, if they are not themselves derivative works of the Document. If the :ref:`Cover Text <fdl-cover-texts>` @@ -429,7 +429,7 @@ concerns. See Each version of the License is given a distinguishing version number. If the :ref:`Document <fdl-document>` specifies that a particular -numbered version of this License “or any later version” applies to it, +numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not @@ -455,13 +455,13 @@ notices just after the title page: being LIST THEIR TITLES, with the :ref:`Front-Cover Texts <fdl-cover-texts>` being LIST, and with the :ref:`Back-Cover Texts <fdl-cover-texts>` being LIST. A copy - of the license is included in the section entitled “GNU Free - Documentation License”. + of the license is included in the section entitled "GNU Free + Documentation License". -If you have no :ref:`Invariant Sections <fdl-invariant>`, write “with -no Invariant Sections” instead of saying which ones are invariant. If -you have no :ref:`Front-Cover Texts <fdl-cover-texts>`, write “no -Front-Cover Texts” instead of “Front-Cover Texts being LIST”; likewise +If you have no :ref:`Invariant Sections <fdl-invariant>`, write "with +no Invariant Sections" instead of saying which ones are invariant. If +you have no :ref:`Front-Cover Texts <fdl-cover-texts>`, write "no +Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise for :ref:`Back-Cover Texts <fdl-cover-texts>`. If your document contains nontrivial examples of program code, we diff --git a/Documentation/userspace-api/media/glossary.rst b/Documentation/userspace-api/media/glossary.rst index cb165d7176b7..96a360edbf3b 100644 --- a/Documentation/userspace-api/media/glossary.rst +++ b/Documentation/userspace-api/media/glossary.rst @@ -116,7 +116,7 @@ Glossary - :term:`RC API`; and - :term:`V4L2 API`. - See :doc:`index`. + See Documentation/userspace-api/media/index.rst. MC API **Media Controller API** diff --git a/Documentation/userspace-api/media/index.rst b/Documentation/userspace-api/media/index.rst index 7f42f83b9f59..d839904be085 100644 --- a/Documentation/userspace-api/media/index.rst +++ b/Documentation/userspace-api/media/index.rst @@ -11,12 +11,14 @@ used by media devices. Please see: -- :doc:`/admin-guide/media/index` - for usage information about media subsystem and supported drivers; +Documentation/admin-guide/media/index.rst -- :doc:`/driver-api/media/index` - for driver development information and Kernel APIs used by - media devices; + - for usage information about media subsystem and supported drivers; + +Documentation/driver-api/media/index.rst + + - for driver development information and Kernel APIs used by + media devices; .. only:: html diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst index 64d241daf63c..7b8e6738ff9e 100644 --- a/Documentation/userspace-api/media/v4l/biblio.rst +++ b/Documentation/userspace-api/media/v4l/biblio.rst @@ -51,7 +51,7 @@ ISO 13818-1 =========== -:title: ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology — Generic coding of moving pictures and associated audio information: Systems" +:title: ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology --- Generic coding of moving pictures and associated audio information: Systems" :author: International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch) @@ -61,7 +61,7 @@ ISO 13818-2 =========== -:title: ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology — Generic coding of moving pictures and associated audio information: Video" +:title: ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology --- Generic coding of moving pictures and associated audio information: Video" :author: International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch) @@ -150,7 +150,7 @@ ITU-T.81 ======== -:title: ITU-T Recommendation T.81 "Information Technology — Digital Compression and Coding of Continous-Tone Still Images — Requirements and Guidelines" +:title: ITU-T Recommendation T.81 "Information Technology --- Digital Compression and Coding of Continous-Tone Still Images --- Requirements and Guidelines" :author: International Telecommunication Union (http://www.itu.int) @@ -310,7 +310,7 @@ ISO 12232:2006 ============== -:title: Photography — Digital still cameras — Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index +:title: Photography --- Digital still cameras --- Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index :author: International Organization for Standardization (http://www.iso.org) diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst index 3d4138a4ba69..5b9b83feeceb 100644 --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst @@ -38,7 +38,7 @@ Conventions and Notations Used in This Document 6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i = [0..2]: i = 0, 1, 2. -7. Given an ``OUTPUT`` buffer A, then A’ represents a buffer on the ``CAPTURE`` +7. Given an ``OUTPUT`` buffer A, then A' represents a buffer on the ``CAPTURE`` queue containing data that resulted from processing buffer A. .. _decoder-glossary: @@ -288,7 +288,7 @@ Initialization Changing the ``OUTPUT`` format may change the currently set ``CAPTURE`` format. How the new ``CAPTURE`` format is determined is up to the decoder - and the client must ensure it matches its needs afterwards. + and the client must ensure it matches its needs afterwards. 2. Allocate source (bytestream) buffers via :c:func:`VIDIOC_REQBUFS` on ``OUTPUT``. @@ -874,7 +874,7 @@ it may be affected as per normal decoder operation. any of the following results on the ``CAPTURE`` queue is allowed: - {A’, B’, G’, H’}, {A’, G’, H’}, {G’, H’}. + {A', B', G', H'}, {A', G', H'}, {G', H'}. To determine the CAPTURE buffer containing the first decoded frame after the seek, the client may observe the timestamps to match the CAPTURE and OUTPUT 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 3fc04daa9ffb..72f5e85b4f34 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst @@ -1244,3 +1244,217 @@ FWHT Flags * - __u8 - ``padding[3]`` - Applications and drivers must set this to zero. + +.. _v4l2-codec-stateless-mpeg2: + +``V4L2_CID_STATELESS_MPEG2_SEQUENCE (struct)`` + Specifies the sequence parameters (as extracted from the bitstream) for the + associated MPEG-2 slice data. This includes fields matching the syntax + elements from the sequence header and sequence extension parts of the + bitstream as specified by :ref:`mpeg2part2`. + +.. c:type:: v4l2_ctrl_mpeg2_sequence + +.. raw:: latex + + \small + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.4cm}|p{6.5cm}|p{9.4cm}| + +.. flat-table:: struct v4l2_ctrl_mpeg2_sequence + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u16 + - ``horizontal_size`` + - The width of the displayable part of the frame's luminance component. + * - __u16 + - ``vertical_size`` + - The height of the displayable part of the frame's luminance component. + * - __u32 + - ``vbv_buffer_size`` + - Used to calculate the required size of the video buffering verifier, + defined (in bits) as: 16 * 1024 * vbv_buffer_size. + * - __u16 + - ``profile_and_level_indication`` + - The current profile and level indication as extracted from the + bitstream. + * - __u8 + - ``chroma_format`` + - The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4). + * - __u8 + - ``flags`` + - See :ref:`MPEG-2 Sequence Flags <mpeg2_sequence_flags>`. + +.. _mpeg2_sequence_flags: + +``MPEG-2 Sequence Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_MPEG2_SEQ_FLAG_PROGRESSIVE`` + - 0x01 + - Indication that all the frames for the sequence are progressive instead + of interlaced. + +.. raw:: latex + + \normalsize + +``V4L2_CID_STATELESS_MPEG2_PICTURE (struct)`` + Specifies the picture parameters (as extracted from the bitstream) for the + associated MPEG-2 slice data. This includes fields matching the syntax + elements from the picture header and picture coding extension parts of the + bitstream as specified by :ref:`mpeg2part2`. + +.. c:type:: v4l2_ctrl_mpeg2_picture + +.. raw:: latex + + \small + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.0cm}|p{5.6cm}|p{10.7cm}| + +.. flat-table:: struct v4l2_ctrl_mpeg2_picture + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u64 + - ``backward_ref_ts`` + - Timestamp of the V4L2 capture buffer to use as backward reference, used + with B-coded and P-coded frames. The timestamp refers to the + ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the + :c:func:`v4l2_timeval_to_ns()` function to convert the struct + :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. + * - __u64 + - ``forward_ref_ts`` + - Timestamp for the V4L2 capture buffer to use as forward reference, used + with B-coded frames. The timestamp refers to the ``timestamp`` field in + struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()` + function to convert the struct :c:type:`timeval` in struct + :c:type:`v4l2_buffer` to a __u64. + * - __u32 + - ``flags`` + - See :ref:`MPEG-2 Picture Flags <mpeg2_picture_flags>`. + * - __u8 + - ``f_code[2][2]`` + - Motion vector codes. + * - __u8 + - ``picture_coding_type`` + - Picture coding type for the frame covered by the current slice + (V4L2_MPEG2_PIC_CODING_TYPE_I, V4L2_MPEG2_PIC_CODING_TYPE_P or + V4L2_MPEG2_PIC_CODING_TYPE_B). + * - __u8 + - ``picture_structure`` + - Picture structure (1: interlaced top field, 2: interlaced bottom field, + 3: progressive frame). + * - __u8 + - ``intra_dc_precision`` + - Precision of Discrete Cosine transform (0: 8 bits precision, + 1: 9 bits precision, 2: 10 bits precision, 3: 11 bits precision). + * - __u8 + - ``reserved[5]`` + - Applications and drivers must set this to zero. + +.. _mpeg2_picture_flags: + +``MPEG-2 Picture Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_MPEG2_PIC_FLAG_TOP_FIELD_FIRST`` + - 0x00000001 + - If set and it's an interlaced stream, top field is output first. + * - ``V4L2_MPEG2_PIC_FLAG_FRAME_PRED_DCT`` + - 0x00000002 + - If set only frame-DCT and frame prediction are used. + * - ``V4L2_MPEG2_PIC_FLAG_CONCEALMENT_MV`` + - 0x00000004 + - If set motion vectors are coded for intra macroblocks. + * - ``V4L2_MPEG2_PIC_FLAG_Q_SCALE_TYPE`` + - 0x00000008 + - This flag affects the inverse quantization process. + * - ``V4L2_MPEG2_PIC_FLAG_INTRA_VLC`` + - 0x00000010 + - This flag affects the decoding of transform coefficient data. + * - ``V4L2_MPEG2_PIC_FLAG_ALT_SCAN`` + - 0x00000020 + - This flag affects the decoding of transform coefficient data. + * - ``V4L2_MPEG2_PIC_FLAG_REPEAT_FIRST`` + - 0x00000040 + - This flag affects the decoding process of progressive frames. + * - ``V4L2_MPEG2_PIC_FLAG_PROGRESSIVE`` + - 0x00000080 + - Indicates whether the current frame is progressive. + +.. raw:: latex + + \normalsize + +``V4L2_CID_STATELESS_MPEG2_QUANTISATION (struct)`` + Specifies quantisation matrices, in zigzag scanning order, for the + associated MPEG-2 slice data. This control is initialized by the kernel + to the matrices default values. If a bitstream transmits a user-defined + quantisation matrices load, applications are expected to use this control. + Applications are also expected to set the control loading the default + values, if the quantisation matrices need to be reset, for instance on a + sequence header. This process is specified by section 6.3.7. + "Quant matrix extension" of the specification. + +.. c:type:: v4l2_ctrl_mpeg2_quantisation + +.. tabularcolumns:: |p{0.8cm}|p{8.0cm}|p{8.5cm}| + +.. cssclass:: longtable + +.. raw:: latex + + \small + +.. flat-table:: struct v4l2_ctrl_mpeg2_quantisation + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``intra_quantiser_matrix[64]`` + - The quantisation matrix coefficients for intra-coded frames, in zigzag + scanning order. It is relevant for both luma and chroma components, + although it can be superseded by the chroma-specific matrix for + non-4:2:0 YUV formats. + * - __u8 + - ``non_intra_quantiser_matrix[64]`` + - The quantisation matrix coefficients for non-intra-coded frames, in + zigzag scanning order. It is relevant for both luma and chroma + components, although it can be superseded by the chroma-specific matrix + for non-4:2:0 YUV formats. + * - __u8 + - ``chroma_intra_quantiser_matrix[64]`` + - The quantisation matrix coefficients for the chominance component of + intra-coded frames, in zigzag scanning order. Only relevant for + non-4:2:0 YUV formats. + * - __u8 + - ``chroma_non_intra_quantiser_matrix[64]`` + - The quantisation matrix coefficients for the chrominance component of + non-intra-coded frames, in zigzag scanning order. Only relevant for + non-4:2:0 YUV formats. + +.. raw:: latex + + \normalsize diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index b0de4e6e7ebd..8c6e2a11ed95 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1606,223 +1606,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - ``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L6_BR (integer)`` Indicates bit rate (bps) for hierarchical coding layer 6 for H264 encoder. -.. _v4l2-mpeg-mpeg2: - -``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (struct)`` - Specifies the slice parameters (as extracted from the bitstream) for the - associated MPEG-2 slice data. This includes the necessary parameters for - configuring a stateless hardware decoding pipeline for MPEG-2. - The bitstream parameters are defined according to :ref:`mpeg2part2`. - - .. note:: - - This compound control is not yet part of the public kernel API and - it is expected to change. - -.. c:type:: v4l2_ctrl_mpeg2_slice_params - -.. tabularcolumns:: |p{5.6cm}|p{4.6cm}|p{7.1cm}| - -.. cssclass:: longtable - -.. flat-table:: struct v4l2_ctrl_mpeg2_slice_params - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u32 - - ``bit_size`` - - Size (in bits) of the current slice data. - * - __u32 - - ``data_bit_offset`` - - Offset (in bits) to the video data in the current slice data. - * - struct :c:type:`v4l2_mpeg2_sequence` - - ``sequence`` - - Structure with MPEG-2 sequence metadata, merging relevant fields from - the sequence header and sequence extension parts of the bitstream. - * - struct :c:type:`v4l2_mpeg2_picture` - - ``picture`` - - Structure with MPEG-2 picture metadata, merging relevant fields from - the picture header and picture coding extension parts of the bitstream. - * - __u64 - - ``backward_ref_ts`` - - Timestamp of the V4L2 capture buffer to use as backward reference, used - with B-coded and P-coded frames. The timestamp refers to the - ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the - :c:func:`v4l2_timeval_to_ns()` function to convert the struct - :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. - * - __u64 - - ``forward_ref_ts`` - - Timestamp for the V4L2 capture buffer to use as forward reference, used - with B-coded frames. The timestamp refers to the ``timestamp`` field in - struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()` - function to convert the struct :c:type:`timeval` in struct - :c:type:`v4l2_buffer` to a __u64. - * - __u32 - - ``quantiser_scale_code`` - - Code used to determine the quantization scale to use for the IDCT. - -.. c:type:: v4l2_mpeg2_sequence - -.. cssclass:: longtable - -.. tabularcolumns:: |p{1.4cm}|p{6.5cm}|p{9.4cm}| - -.. flat-table:: struct v4l2_mpeg2_sequence - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u16 - - ``horizontal_size`` - - The width of the displayable part of the frame's luminance component. - * - __u16 - - ``vertical_size`` - - The height of the displayable part of the frame's luminance component. - * - __u32 - - ``vbv_buffer_size`` - - Used to calculate the required size of the video buffering verifier, - defined (in bits) as: 16 * 1024 * vbv_buffer_size. - * - __u16 - - ``profile_and_level_indication`` - - The current profile and level indication as extracted from the - bitstream. - * - __u8 - - ``progressive_sequence`` - - Indication that all the frames for the sequence are progressive instead - of interlaced. - * - __u8 - - ``chroma_format`` - - The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4). - -.. c:type:: v4l2_mpeg2_picture - -.. raw:: latex - - \small - -.. cssclass:: longtable - -.. tabularcolumns:: |p{1.0cm}|p{5.6cm}|p{10.7cm}| - -.. flat-table:: struct v4l2_mpeg2_picture - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u8 - - ``picture_coding_type`` - - Picture coding type for the frame covered by the current slice - (V4L2_MPEG2_PICTURE_CODING_TYPE_I, V4L2_MPEG2_PICTURE_CODING_TYPE_P or - V4L2_MPEG2_PICTURE_CODING_TYPE_B). - * - __u8 - - ``f_code[2][2]`` - - Motion vector codes. - * - __u8 - - ``intra_dc_precision`` - - Precision of Discrete Cosine transform (0: 8 bits precision, - 1: 9 bits precision, 2: 10 bits precision, 3: 11 bits precision). - * - __u8 - - ``picture_structure`` - - Picture structure (1: interlaced top field, 2: interlaced bottom field, - 3: progressive frame). - * - __u8 - - ``top_field_first`` - - If set to 1 and interlaced stream, top field is output first. - * - __u8 - - ``frame_pred_frame_dct`` - - If set to 1, only frame-DCT and frame prediction are used. - * - __u8 - - ``concealment_motion_vectors`` - - If set to 1, motion vectors are coded for intra macroblocks. - * - __u8 - - ``q_scale_type`` - - This flag affects the inverse quantization process. - * - __u8 - - ``intra_vlc_format`` - - This flag affects the decoding of transform coefficient data. - * - __u8 - - ``alternate_scan`` - - This flag affects the decoding of transform coefficient data. - * - __u8 - - ``repeat_first_field`` - - This flag affects the decoding process of progressive frames. - * - __u16 - - ``progressive_frame`` - - Indicates whether the current frame is progressive. - -.. raw:: latex - - \normalsize - -``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION (struct)`` - Specifies quantization matrices (as extracted from the bitstream) for the - associated MPEG-2 slice data. - - .. note:: - - This compound control is not yet part of the public kernel API and - it is expected to change. - -.. c:type:: v4l2_ctrl_mpeg2_quantization - -.. tabularcolumns:: |p{0.8cm}|p{8.0cm}|p{8.5cm}| - -.. cssclass:: longtable - -.. raw:: latex - - \small - -.. flat-table:: struct v4l2_ctrl_mpeg2_quantization - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u8 - - ``load_intra_quantiser_matrix`` - - One bit to indicate whether to load the ``intra_quantiser_matrix`` data. - * - __u8 - - ``load_non_intra_quantiser_matrix`` - - One bit to indicate whether to load the ``non_intra_quantiser_matrix`` - data. - * - __u8 - - ``load_chroma_intra_quantiser_matrix`` - - One bit to indicate whether to load the - ``chroma_intra_quantiser_matrix`` data, only relevant for non-4:2:0 YUV - formats. - * - __u8 - - ``load_chroma_non_intra_quantiser_matrix`` - - One bit to indicate whether to load the - ``chroma_non_intra_quantiser_matrix`` data, only relevant for non-4:2:0 - YUV formats. - * - __u8 - - ``intra_quantiser_matrix[64]`` - - The quantization matrix coefficients for intra-coded frames, in zigzag - scanning order. It is relevant for both luma and chroma components, - although it can be superseded by the chroma-specific matrix for - non-4:2:0 YUV formats. - * - __u8 - - ``non_intra_quantiser_matrix[64]`` - - The quantization matrix coefficients for non-intra-coded frames, in - zigzag scanning order. It is relevant for both luma and chroma - components, although it can be superseded by the chroma-specific matrix - for non-4:2:0 YUV formats. - * - __u8 - - ``chroma_intra_quantiser_matrix[64]`` - - The quantization matrix coefficients for the chominance component of - intra-coded frames, in zigzag scanning order. Only relevant for - non-4:2:0 YUV formats. - * - __u8 - - ``chroma_non_intra_quantiser_matrix[64]`` - - The quantization matrix coefficients for the chrominance component of - non-intra-coded frames, in zigzag scanning order. Only relevant for - non-4:2:0 YUV formats. - -.. raw:: latex - - \normalsize - ``V4L2_CID_FWHT_I_FRAME_QP (integer)`` Quantization parameter for an I frame for FWHT. Valid range: from 1 to 31. @@ -2924,6 +2707,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - __u8 - ``chroma_format_idc`` - + * - __u8 + - ``sps_max_sub_layers_minus1`` + - * - __u64 - ``flags`` - See :ref:`Sequence Parameter Set Flags <hevc_sps_flags>` @@ -3000,6 +2786,12 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - __u8 - ``num_extra_slice_header_bits`` - + * - __u8 + - ``num_ref_idx_l0_default_active_minus1`` + - Specifies the inferred value of num_ref_idx_l0_active_minus1 + * - __u8 + - ``num_ref_idx_l1_default_active_minus1`` + - Specifies the inferred value of num_ref_idx_l1_active_minus1 * - __s8 - ``init_qp_minus26`` - @@ -3053,7 +2845,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - :stub-columns: 0 :widths: 1 1 2 - * - ``V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT`` + * - ``V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT_ENABLED`` - 0x00000001 - * - ``V4L2_HEVC_PPS_FLAG_OUTPUT_FLAG_PRESENT`` @@ -3110,6 +2902,14 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - ``V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT`` - 0x00040000 - + * - ``V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT`` + - 0x00080000 + - Specifies the presence of deblocking filter control syntax elements in + the PPS + * - ``V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING`` + - 0x00100000 + - Specifies that tile column boundaries and likewise tile row boundaries + are distributed uniformly across the picture .. raw:: latex @@ -3201,31 +3001,14 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - - ``pic_struct`` - * - __u8 - - ``num_active_dpb_entries`` - - The number of entries in ``dpb``. - * - __u8 - ``ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - The list of L0 reference elements as indices in the DPB. * - __u8 - ``ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - The list of L1 reference elements as indices in the DPB. * - __u8 - - ``num_rps_poc_st_curr_before`` - - The number of reference pictures in the short-term set that come before - the current frame. - * - __u8 - - ``num_rps_poc_st_curr_after`` - - The number of reference pictures in the short-term set that come after - the current frame. - * - __u8 - - ``num_rps_poc_lt_curr`` - - The number of reference pictures in the long-term set. - * - __u8 - - ``padding[7]`` + - ``padding`` - Applications and drivers must set this to zero. - * - struct :c:type:`v4l2_hevc_dpb_entry` - - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - The decoded picture buffer, for meta-data about reference frames. * - struct :c:type:`v4l2_hevc_pred_weight_table` - ``pred_weight_table`` - The prediction weight coefficients for inter-picture prediction. @@ -3277,6 +3060,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_LOOP_FILTER_ACROSS_SLICES_ENABLED`` - 0x00000100 - + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT`` + - 0x00000200 + - .. raw:: latex @@ -3478,3 +3264,78 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - encoding the next frame queued after setting this control. This provides a bitmask which consists of bits [0, LTR_COUNT-1]. This is applicable to the H264 and HEVC encoders. + +``V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS (struct)`` + Specifies various decode parameters, especially the references picture order + count (POC) for all the lists (short, long, before, current, after) and the + number of entries for each of them. + These parameters are defined according to :ref:`hevc`. + They are described in section 8.3 "Slice decoding process" of the + specification. + +.. c:type:: v4l2_ctrl_hevc_decode_params + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_hevc_decode_params + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __s32 + - ``pic_order_cnt_val`` + - PicOrderCntVal as described in section 8.3.1 "Decoding process + for picture order count" of the specification. + * - __u8 + - ``num_active_dpb_entries`` + - The number of entries in ``dpb``. + * - struct :c:type:`v4l2_hevc_dpb_entry` + - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - The decoded picture buffer, for meta-data about reference frames. + * - __u8 + - ``num_poc_st_curr_before`` + - The number of reference pictures in the short-term set that come before + the current frame. + * - __u8 + - ``num_poc_st_curr_after`` + - The number of reference pictures in the short-term set that come after + the current frame. + * - __u8 + - ``num_poc_lt_curr`` + - The number of reference pictures in the long-term set. + * - __u8 + - ``poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - PocStCurrBefore as described in section 8.3.2 "Decoding process for reference + picture set. + * - __u8 + - ``poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - PocStCurrAfter as described in section 8.3.2 "Decoding process for reference + picture set. + * - __u8 + - ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - PocLtCurr as described in section 8.3.2 "Decoding process for reference + picture set. + * - __u64 + - ``flags`` + - See :ref:`Decode Parameters Flags <hevc_decode_params_flags>` + +.. _hevc_decode_params_flags: + +``Decode Parameters Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC`` + - 0x00000001 + - + * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC`` + - 0x00000002 + - + * - ``V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR`` + - 0x00000004 + - diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst index 6dba70da822b..0ede39907ee2 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst @@ -112,12 +112,13 @@ Compressed Formats - 'MG2S' - MPEG-2 parsed slice data, as extracted from the MPEG-2 bitstream. This format is adapted for stateless video decoders that implement a - MPEG-2 pipeline (using the :ref:`mem2mem` and :ref:`media-request-api`). + MPEG-2 pipeline with the :ref:`stateless_decoder`. Metadata associated with the frame to decode is required to be passed - through the ``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS`` control and - quantization matrices can optionally be specified through the - ``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION`` control. - See the :ref:`associated Codec Control IDs <v4l2-mpeg-mpeg2>`. + through the ``V4L2_CID_STATELESS_MPEG2_SEQUENCE`` and + ``V4L2_CID_STATELESS_MPEG2_PICTURE`` controls. + Quantisation matrices can optionally be specified through the + ``V4L2_CID_STATELESS_MPEG2_QUANTISATION`` control. + See the :ref:`associated Codec Control IDs <v4l2-codec-stateless-mpeg2>`. Exactly one output and one capture buffer must be provided for use with this pixel format. The output buffer must contain the appropriate number of macroblocks to decode a full corresponding frame to the matching diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst b/Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst index 5f33d35532ef..84d81dd7a7b5 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst @@ -78,4 +78,4 @@ hardware and algorithm details. Intel IPU3 ImgU uAPI data types =============================== -.. kernel-doc:: drivers/staging/media/ipu3/include/intel-ipu3.h +.. kernel-doc:: drivers/staging/media/ipu3/include/uapi/intel-ipu3.h diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst index 3ba22983d21f..2d6bc8d94380 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -221,6 +221,18 @@ still cause this situation. - ``p_vp8_frame`` - A pointer to a struct :c:type:`v4l2_ctrl_vp8_frame`. Valid if this control is of type ``V4L2_CTRL_TYPE_VP8_FRAME``. + * - struct :c:type:`v4l2_ctrl_mpeg2_sequence` * + - ``p_mpeg2_sequence`` + - A pointer to a struct :c:type:`v4l2_ctrl_mpeg2_sequence`. Valid if this control is + of type ``V4L2_CTRL_TYPE_MPEG2_SEQUENCE``. + * - struct :c:type:`v4l2_ctrl_mpeg2_picture` * + - ``p_mpeg2_picture`` + - A pointer to a struct :c:type:`v4l2_ctrl_mpeg2_picture`. Valid if this control is + of type ``V4L2_CTRL_TYPE_MPEG2_PICTURE``. + * - struct :c:type:`v4l2_ctrl_mpeg2_quantisation` * + - ``p_mpeg2_quantisation`` + - A pointer to a struct :c:type:`v4l2_ctrl_mpeg2_quantisation`. Valid if this control is + of type ``V4L2_CTRL_TYPE_MPEG2_QUANTISATION``. * - struct :c:type:`v4l2_ctrl_hdr10_cll_info` * - ``p_hdr10_cll`` - A pointer to a struct :c:type:`v4l2_ctrl_hdr10_cll_info`. Valid if this control is diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index 8a285daedc6a..f9ecf6276129 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -417,18 +417,24 @@ See also the examples in :ref:`control`. - any - An unsigned 32-bit valued control ranging from minimum to maximum inclusive. The step value indicates the increment between values. - * - ``V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS`` + * - ``V4L2_CTRL_TYPE_MPEG2_QUANTISATION`` - n/a - n/a - n/a - - A struct :c:type:`v4l2_ctrl_mpeg2_slice_params`, containing MPEG-2 - slice parameters for stateless video decoders. - * - ``V4L2_CTRL_TYPE_MPEG2_QUANTIZATION`` + - A struct :c:type:`v4l2_ctrl_mpeg2_quantisation`, containing MPEG-2 + quantisation matrices for stateless video decoders. + * - ``V4L2_CTRL_TYPE_MPEG2_SEQUENCE`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_mpeg2_sequence`, containing MPEG-2 + sequence parameters for stateless video decoders. + * - ``V4L2_CTRL_TYPE_MPEG2_PICTURE`` - n/a - n/a - n/a - - A struct :c:type:`v4l2_ctrl_mpeg2_quantization`, containing MPEG-2 - quantization matrices for stateless video decoders. + - A struct :c:type:`v4l2_ctrl_mpeg2_picture`, containing MPEG-2 + picture parameters for stateless video decoders. * - ``V4L2_CTRL_TYPE_AREA`` - n/a - n/a @@ -495,6 +501,12 @@ See also the examples in :ref:`control`. - n/a - A struct :c:type:`v4l2_ctrl_vp8_frame`, containing VP8 frame parameters for stateless video decoders. + * - ``V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_hevc_decode_params`, containing HEVC + decoding parameters for stateless video decoders. .. raw:: latex diff --git a/Documentation/userspace-api/media/video.h.rst.exceptions b/Documentation/userspace-api/media/video.h.rst.exceptions deleted file mode 100644 index ea9de59ad8b7..000000000000 --- a/Documentation/userspace-api/media/video.h.rst.exceptions +++ /dev/null @@ -1,39 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 - -# Ignore header name -ignore define _UAPI_DVBVIDEO_H_ - -# This is a deprecated obscure API. Just ignore things we don't know -ignore define VIDEO_CMD_PLAY -ignore define VIDEO_CMD_STOP -ignore define VIDEO_CMD_FREEZE -ignore define VIDEO_CMD_CONTINUE -ignore define VIDEO_CMD_FREEZE_TO_BLACK -ignore define VIDEO_CMD_STOP_TO_BLACK -ignore define VIDEO_CMD_STOP_IMMEDIATELY -ignore define VIDEO_PLAY_FMT_NONE -ignore define VIDEO_PLAY_FMT_GOP -ignore define VIDEO_VSYNC_FIELD_UNKNOWN -ignore define VIDEO_VSYNC_FIELD_ODD -ignore define VIDEO_VSYNC_FIELD_EVEN -ignore define VIDEO_VSYNC_FIELD_PROGRESSIVE -ignore define VIDEO_EVENT_SIZE_CHANGED -ignore define VIDEO_EVENT_FRAME_RATE_CHANGED -ignore define VIDEO_EVENT_DECODER_STOPPED -ignore define VIDEO_EVENT_VSYNC -ignore define VIDEO_CAP_MPEG1 -ignore define VIDEO_CAP_MPEG2 -ignore define VIDEO_CAP_SYS -ignore define VIDEO_CAP_PROG -ignore define VIDEO_CAP_SPU -ignore define VIDEO_CAP_NAVI -ignore define VIDEO_CAP_CSS - -# some typedefs should point to struct/enums -replace typedef video_format_t :c:type:`video_format` -replace typedef video_system_t :c:type:`video_system` -replace typedef video_displayformat_t :c:type:`video_displayformat` -replace typedef video_size_t :c:type:`video_size` -replace typedef video_stream_source_t :c:type:`video_stream_source` -replace typedef video_play_state_t :c:type:`video_play_state` -replace typedef video_navi_pack_t :c:type:`video_navi_pack` diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index f59940352faa..2217b56c2686 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -134,8 +134,9 @@ replace symbol V4L2_CTRL_TYPE_STRING :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U16 :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type` -replace symbol V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS :c:type:`v4l2_ctrl_type` -replace symbol V4L2_CTRL_TYPE_MPEG2_QUANTIZATION :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_MPEG2_SEQUENCE :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_MPEG2_PICTURE :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_MPEG2_QUANTISATION :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_H264_SPS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_H264_PPS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_H264_SCALING_MATRIX :c:type:`v4l2_ctrl_type` diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst index bd9165241b6c..d61219889e49 100644 --- a/Documentation/userspace-api/seccomp_filter.rst +++ b/Documentation/userspace-api/seccomp_filter.rst @@ -250,14 +250,26 @@ Users can read via ``ioctl(SECCOMP_IOCTL_NOTIF_RECV)`` (or ``poll()``) on a seccomp notification fd to receive a ``struct seccomp_notif``, which contains five members: the input length of the structure, a unique-per-filter ``id``, the ``pid`` of the task which triggered this request (which may be 0 if the -task is in a pid ns not visible from the listener's pid namespace), a ``flags`` -member which for now only has ``SECCOMP_NOTIF_FLAG_SIGNALED``, representing -whether or not the notification is a result of a non-fatal signal, and the -``data`` passed to seccomp. Userspace can then make a decision based on this -information about what to do, and ``ioctl(SECCOMP_IOCTL_NOTIF_SEND)`` a -response, indicating what should be returned to userspace. The ``id`` member of -``struct seccomp_notif_resp`` should be the same ``id`` as in ``struct -seccomp_notif``. +task is in a pid ns not visible from the listener's pid namespace). The +notification also contains the ``data`` passed to seccomp, and a filters flag. +The structure should be zeroed out prior to calling the ioctl. + +Userspace can then make a decision based on this information about what to do, +and ``ioctl(SECCOMP_IOCTL_NOTIF_SEND)`` a response, indicating what should be +returned to userspace. The ``id`` member of ``struct seccomp_notif_resp`` should +be the same ``id`` as in ``struct seccomp_notif``. + +Userspace can also add file descriptors to the notifying process via +``ioctl(SECCOMP_IOCTL_NOTIF_ADDFD)``. The ``id`` member of +``struct seccomp_notif_addfd`` should be the same ``id`` as in +``struct seccomp_notif``. The ``newfd_flags`` flag may be used to set flags +like O_EXEC on the file descriptor in the notifying process. If the supervisor +wants to inject the file descriptor with a specific number, the +``SECCOMP_ADDFD_FLAG_SETFD`` flag can be used, and set the ``newfd`` member to +the specific number to use. If that file descriptor is already open in the +notifying process it will be replaced. The supervisor can also add an FD, and +respond atomically by using the ``SECCOMP_ADDFD_FLAG_SEND`` flag and the return +value will be the injected file descriptor number. It is worth noting that ``struct seccomp_data`` contains the values of register arguments to the syscall, but does not contain pointers to memory. The task's diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst b/Documentation/virt/kvm/amd-memory-encryption.rst index 5ec8a1902e15..5c081c8c7164 100644 --- a/Documentation/virt/kvm/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/amd-memory-encryption.rst @@ -22,7 +22,7 @@ to SEV:: [ecx]: Bits[31:0] Number of encrypted guests supported simultaneously -If support for SEV is present, MSR 0xc001_0010 (MSR_K8_SYSCFG) and MSR 0xc001_0015 +If support for SEV is present, MSR 0xc001_0010 (MSR_AMD64_SYSCFG) and MSR 0xc001_0015 (MSR_K7_HWCR) can be used to determine if it can be enabled:: 0xc001_0010: diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 22d077562149..c7b165ca70b6 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -688,9 +688,14 @@ MSRs that have been set successfully. Defines the vcpu responses to the cpuid instruction. Applications should use the KVM_SET_CPUID2 ioctl if available. -Note, when this IOCTL fails, KVM gives no guarantees that previous valid CPUID -configuration (if there is) is not corrupted. Userspace can get a copy of the -resulting CPUID configuration through KVM_GET_CPUID2 in case. +Caveat emptor: + - If this IOCTL fails, KVM gives no guarantees that previous valid CPUID + configuration (if there is) is not corrupted. Userspace can get a copy + of the resulting CPUID configuration through KVM_GET_CPUID2 in case. + - Using KVM_SET_CPUID{,2} after KVM_RUN, i.e. changing the guest vCPU model + after running the guest, may cause guest instability. + - Using heterogeneous CPUID configurations, modulo APIC IDs, topology, etc... + may cause guest instability. :: @@ -4803,7 +4808,7 @@ KVM_PV_VM_VERIFY 4.126 KVM_X86_SET_MSR_FILTER ---------------------------- -:Capability: KVM_X86_SET_MSR_FILTER +:Capability: KVM_CAP_X86_MSR_FILTER :Architectures: x86 :Type: vm ioctl :Parameters: struct kvm_msr_filter @@ -5034,6 +5039,260 @@ see KVM_XEN_VCPU_SET_ATTR above. The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used with the KVM_XEN_VCPU_GET_ATTR ioctl. +4.130 KVM_ARM_MTE_COPY_TAGS +--------------------------- + +:Capability: KVM_CAP_ARM_MTE +:Architectures: arm64 +:Type: vm ioctl +:Parameters: struct kvm_arm_copy_mte_tags +:Returns: number of bytes copied, < 0 on error (-EINVAL for incorrect + arguments, -EFAULT if memory cannot be accessed). + +:: + + struct kvm_arm_copy_mte_tags { + __u64 guest_ipa; + __u64 length; + void __user *addr; + __u64 flags; + __u64 reserved[2]; + }; + +Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The +``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr`` +field must point to a buffer which the tags will be copied to or from. + +``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or +``KVM_ARM_TAGS_FROM_GUEST``. + +The size of the buffer to store the tags is ``(length / 16)`` bytes +(granules in MTE are 16 bytes long). Each byte contains a single tag +value. This matches the format of ``PTRACE_PEEKMTETAGS`` and +``PTRACE_POKEMTETAGS``. + +If an error occurs before any data is copied then a negative error code is +returned. If some tags have been copied before an error occurs then the number +of bytes successfully copied is returned. If the call completes successfully +then ``length`` is returned. + +4.131 KVM_GET_SREGS2 +------------------ + +:Capability: KVM_CAP_SREGS2 +:Architectures: x86 +:Type: vcpu ioctl +:Parameters: struct kvm_sregs2 (out) +:Returns: 0 on success, -1 on error + +Reads special registers from the vcpu. +This ioctl (when supported) replaces the KVM_GET_SREGS. + +:: + +struct kvm_sregs2 { + /* out (KVM_GET_SREGS2) / in (KVM_SET_SREGS2) */ + struct kvm_segment cs, ds, es, fs, gs, ss; + struct kvm_segment tr, ldt; + struct kvm_dtable gdt, idt; + __u64 cr0, cr2, cr3, cr4, cr8; + __u64 efer; + __u64 apic_base; + __u64 flags; + __u64 pdptrs[4]; +}; + +flags values for ``kvm_sregs2``: + +``KVM_SREGS2_FLAGS_PDPTRS_VALID`` + + Indicates thats the struct contain valid PDPTR values. + + +4.132 KVM_SET_SREGS2 +------------------ + +:Capability: KVM_CAP_SREGS2 +:Architectures: x86 +:Type: vcpu ioctl +:Parameters: struct kvm_sregs2 (in) +:Returns: 0 on success, -1 on error + +Writes special registers into the vcpu. +See KVM_GET_SREGS2 for the data structures. +This ioctl (when supported) replaces the KVM_SET_SREGS. + +4.133 KVM_GET_STATS_FD +---------------------- + +:Capability: KVM_CAP_STATS_BINARY_FD +:Architectures: all +:Type: vm ioctl, vcpu ioctl +:Parameters: none +:Returns: statistics file descriptor on success, < 0 on error + +Errors: + + ====== ====================================================== + ENOMEM if the fd could not be created due to lack of memory + EMFILE if the number of opened files exceeds the limit + ====== ====================================================== + +The returned file descriptor can be used to read VM/vCPU statistics data in +binary format. The data in the file descriptor consists of four blocks +organized as follows: + ++-------------+ +| Header | ++-------------+ +| id string | ++-------------+ +| Descriptors | ++-------------+ +| Stats Data | ++-------------+ + +Apart from the header starting at offset 0, please be aware that it is +not guaranteed that the four blocks are adjacent or in the above order; +the offsets of the id, descriptors and data blocks are found in the +header. However, all four blocks are aligned to 64 bit offsets in the +file and they do not overlap. + +All blocks except the data block are immutable. Userspace can read them +only one time after retrieving the file descriptor, and then use ``pread`` or +``lseek`` to read the statistics repeatedly. + +All data is in system endianness. + +The format of the header is as follows:: + + struct kvm_stats_header { + __u32 flags; + __u32 name_size; + __u32 num_desc; + __u32 id_offset; + __u32 desc_offset; + __u32 data_offset; + }; + +The ``flags`` field is not used at the moment. It is always read as 0. + +The ``name_size`` field is the size (in byte) of the statistics name string +(including trailing '\0') which is contained in the "id string" block and +appended at the end of every descriptor. + +The ``num_desc`` field is the number of descriptors that are included in the +descriptor block. (The actual number of values in the data block may be +larger, since each descriptor may comprise more than one value). + +The ``id_offset`` field is the offset of the id string from the start of the +file indicated by the file descriptor. It is a multiple of 8. + +The ``desc_offset`` field is the offset of the Descriptors block from the start +of the file indicated by the file descriptor. It is a multiple of 8. + +The ``data_offset`` field is the offset of the Stats Data block from the start +of the file indicated by the file descriptor. It is a multiple of 8. + +The id string block contains a string which identifies the file descriptor on +which KVM_GET_STATS_FD was invoked. The size of the block, including the +trailing ``'\0'``, is indicated by the ``name_size`` field in the header. + +The descriptors block is only needed to be read once for the lifetime of the +file descriptor contains a sequence of ``struct kvm_stats_desc``, each followed +by a string of size ``name_size``. + + #define KVM_STATS_TYPE_SHIFT 0 + #define KVM_STATS_TYPE_MASK (0xF << KVM_STATS_TYPE_SHIFT) + #define KVM_STATS_TYPE_CUMULATIVE (0x0 << KVM_STATS_TYPE_SHIFT) + #define KVM_STATS_TYPE_INSTANT (0x1 << KVM_STATS_TYPE_SHIFT) + #define KVM_STATS_TYPE_PEAK (0x2 << KVM_STATS_TYPE_SHIFT) + + #define KVM_STATS_UNIT_SHIFT 4 + #define KVM_STATS_UNIT_MASK (0xF << KVM_STATS_UNIT_SHIFT) + #define KVM_STATS_UNIT_NONE (0x0 << KVM_STATS_UNIT_SHIFT) + #define KVM_STATS_UNIT_BYTES (0x1 << KVM_STATS_UNIT_SHIFT) + #define KVM_STATS_UNIT_SECONDS (0x2 << KVM_STATS_UNIT_SHIFT) + #define KVM_STATS_UNIT_CYCLES (0x3 << KVM_STATS_UNIT_SHIFT) + + #define KVM_STATS_BASE_SHIFT 8 + #define KVM_STATS_BASE_MASK (0xF << KVM_STATS_BASE_SHIFT) + #define KVM_STATS_BASE_POW10 (0x0 << KVM_STATS_BASE_SHIFT) + #define KVM_STATS_BASE_POW2 (0x1 << KVM_STATS_BASE_SHIFT) + + struct kvm_stats_desc { + __u32 flags; + __s16 exponent; + __u16 size; + __u32 offset; + __u32 unused; + char name[]; + }; + +The ``flags`` field contains the type and unit of the statistics data described +by this descriptor. Its endianness is CPU native. +The following flags are supported: + +Bits 0-3 of ``flags`` encode the type: + * ``KVM_STATS_TYPE_CUMULATIVE`` + The statistics data is cumulative. The value of data can only be increased. + Most of the counters used in KVM are of this type. + The corresponding ``size`` field for this type is always 1. + All cumulative statistics data are read/write. + * ``KVM_STATS_TYPE_INSTANT`` + The statistics data is instantaneous. Its value can be increased or + decreased. This type is usually used as a measurement of some resources, + like the number of dirty pages, the number of large pages, etc. + All instant statistics are read only. + The corresponding ``size`` field for this type is always 1. + * ``KVM_STATS_TYPE_PEAK`` + The statistics data is peak. The value of data can only be increased, and + represents a peak value for a measurement, for example the maximum number + of items in a hash table bucket, the longest time waited and so on. + The corresponding ``size`` field for this type is always 1. + +Bits 4-7 of ``flags`` encode the unit: + * ``KVM_STATS_UNIT_NONE`` + There is no unit for the value of statistics data. This usually means that + the value is a simple counter of an event. + * ``KVM_STATS_UNIT_BYTES`` + It indicates that the statistics data is used to measure memory size, in the + unit of Byte, KiByte, MiByte, GiByte, etc. The unit of the data is + determined by the ``exponent`` field in the descriptor. + * ``KVM_STATS_UNIT_SECONDS`` + It indicates that the statistics data is used to measure time or latency. + * ``KVM_STATS_UNIT_CYCLES`` + It indicates that the statistics data is used to measure CPU clock cycles. + +Bits 8-11 of ``flags``, together with ``exponent``, encode the scale of the +unit: + * ``KVM_STATS_BASE_POW10`` + The scale is based on power of 10. It is used for measurement of time and + CPU clock cycles. For example, an exponent of -9 can be used with + ``KVM_STATS_UNIT_SECONDS`` to express that the unit is nanoseconds. + * ``KVM_STATS_BASE_POW2`` + The scale is based on power of 2. It is used for measurement of memory size. + For example, an exponent of 20 can be used with ``KVM_STATS_UNIT_BYTES`` to + express that the unit is MiB. + +The ``size`` field is the number of values of this statistics data. Its +value is usually 1 for most of simple statistics. 1 means it contains an +unsigned 64bit data. + +The ``offset`` field is the offset from the start of Data Block to the start of +the corresponding statistics data. + +The ``unused`` field is reserved for future support for other types of +statistics data, like log/linear histogram. Its value is always 0 for the types +defined above. + +The ``name`` field is the name string of the statistics data. The name string +starts at the end of ``struct kvm_stats_desc``. The maximum length including +the trailing ``'\0'``, is indicated by ``name_size`` in the header. + +The Stats Data block contains an array of 64-bit values in the same order +as the descriptors in Descriptors block. + 5. The kvm_run structure ======================== @@ -6323,6 +6582,7 @@ KVM_RUN_BUS_LOCK flag is used to distinguish between them. This capability can be used to check / enable 2nd DAWR feature provided by POWER10 processor. + 7.24 KVM_CAP_VM_COPY_ENC_CONTEXT_FROM ------------------------------------- @@ -6360,7 +6620,67 @@ system fingerprint. To prevent userspace from circumventing such restrictions by running an enclave in a VM, KVM prevents access to privileged attributes by default. -See Documentation/x86/sgx/2.Kernel-internals.rst for more details. +See Documentation/x86/sgx.rst for more details. + +7.26 KVM_CAP_PPC_RPT_INVALIDATE +------------------------------- + +:Capability: KVM_CAP_PPC_RPT_INVALIDATE +:Architectures: ppc +:Type: vm + +This capability indicates that the kernel is capable of handling +H_RPT_INVALIDATE hcall. + +In order to enable the use of H_RPT_INVALIDATE in the guest, +user space might have to advertise it for the guest. For example, +IBM pSeries (sPAPR) guest starts using it if "hcall-rpt-invalidate" is +present in the "ibm,hypertas-functions" device-tree property. + +This capability is enabled for hypervisors on platforms like POWER9 +that support radix MMU. + +7.27 KVM_CAP_EXIT_ON_EMULATION_FAILURE +-------------------------------------- + +:Architectures: x86 +:Parameters: args[0] whether the feature should be enabled or not + +When this capability is enabled, an emulation failure will result in an exit +to userspace with KVM_INTERNAL_ERROR (except when the emulator was invoked +to handle a VMware backdoor instruction). Furthermore, KVM will now provide up +to 15 instruction bytes for any exit to userspace resulting from an emulation +failure. When these exits to userspace occur use the emulation_failure struct +instead of the internal struct. They both have the same layout, but the +emulation_failure struct matches the content better. It also explicitly +defines the 'flags' field which is used to describe the fields in the struct +that are valid (ie: if KVM_INTERNAL_ERROR_EMULATION_FLAG_INSTRUCTION_BYTES is +set in the 'flags' field then both 'insn_size' and 'insn_bytes' have valid data +in them.) + +7.28 KVM_CAP_ARM_MTE +-------------------- + +:Architectures: arm64 +:Parameters: none + +This capability indicates that KVM (and the hardware) supports exposing the +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the +VMM before creating any VCPUs to allow the guest access. Note that MTE is only +available to a guest running in AArch64 mode and enabling this capability will +cause attempts to create AArch32 VCPUs to fail. + +When enabled the guest is able to access tags associated with any memory given +to the guest. KVM will ensure that the tags are maintained during swap or +hibernation of the host; however the VMM needs to manually save/restore the +tags as appropriate if the VM is migrated. + +When this capability is enabled all memory in memslots must be mapped as +not-shareable (no MAP_SHARED), attempts to create a memslot with a +MAP_SHARED mmap will result in an -EINVAL return. + +When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to +perform a bulk copy of tags to/from the guest. 8. Other capabilities. ====================== @@ -6715,7 +7035,7 @@ accesses that would usually trigger a #GP by KVM into the guest will instead get bounced to user space through the KVM_EXIT_X86_RDMSR and KVM_EXIT_X86_WRMSR exit notifications. -8.27 KVM_X86_SET_MSR_FILTER +8.27 KVM_CAP_X86_MSR_FILTER --------------------------- :Architectures: x86 @@ -6891,3 +7211,33 @@ This capability is always enabled. This capability indicates that the KVM virtual PTP service is supported in the host. A VMM can check whether the service is available to the guest on migration. + +8.33 KVM_CAP_HYPERV_ENFORCE_CPUID +----------------------------- + +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 +Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001) +leaf. + +8.34 KVM_CAP_EXIT_HYPERCALL +--------------------------- + +:Capability: KVM_CAP_EXIT_HYPERCALL +:Architectures: x86 +:Type: vm + +This capability, if enabled, will cause KVM to exit to userspace +with KVM_EXIT_HYPERCALL exit reason to process some hypercalls. + +Calling KVM_CHECK_EXTENSION for this capability will return a bitmask +of hypercalls that can be configured to exit to userspace. +Right now, the only such hypercall is KVM_HC_MAP_GPA_RANGE. + +The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset +of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace +the hypercalls whose corresponding bit is in the argument, and return +ENOSYS for the others. diff --git a/Documentation/virt/kvm/cpuid.rst b/Documentation/virt/kvm/cpuid.rst index cf62162d4be2..bda3e3e737d7 100644 --- a/Documentation/virt/kvm/cpuid.rst +++ b/Documentation/virt/kvm/cpuid.rst @@ -96,6 +96,13 @@ KVM_FEATURE_MSI_EXT_DEST_ID 15 guest checks this feature bit before using extended destination ID bits in MSI address bits 11-5. +KVM_FEATURE_HC_MAP_GPA_RANGE 16 guest checks this feature bit before + using the map gpa range hypercall + to notify the page state change + +KVM_FEATURE_MIGRATION_CONTROL 17 guest checks this feature bit before + using MSR_KVM_MIGRATION_CONTROL + KVM_FEATURE_CLOCKSOURCE_STABLE_BIT 24 host will warn if no guest-side per-cpu warps are expected in kvmclock diff --git a/Documentation/virt/kvm/hypercalls.rst b/Documentation/virt/kvm/hypercalls.rst index ed4fddd364ea..e56fa8b9cfca 100644 --- a/Documentation/virt/kvm/hypercalls.rst +++ b/Documentation/virt/kvm/hypercalls.rst @@ -169,3 +169,24 @@ a0: destination APIC ID :Usage example: When sending a call-function IPI-many to vCPUs, yield if any of the IPI target vCPUs was preempted. + +8. KVM_HC_MAP_GPA_RANGE +------------------------- +:Architecture: x86 +:Status: active +:Purpose: Request KVM to map a GPA range with the specified attributes. + +a0: the guest physical address of the start page +a1: the number of (4kb) pages (must be contiguous in GPA space) +a2: attributes + + Where 'attributes' : + * bits 3:0 - preferred page size encoding 0 = 4kb, 1 = 2mb, 2 = 1gb, etc... + * bit 4 - plaintext = 0, encrypted = 1 + * bits 63:5 - reserved (must be zero) + +**Implementation note**: this hypercall is implemented in userspace via +the KVM_CAP_EXIT_HYPERCALL capability. Userspace must enable that capability +before advertising KVM_FEATURE_HC_MAP_GPA_RANGE in the guest CPUID. In +addition, if the guest supports KVM_FEATURE_MIGRATION_CONTROL, userspace +must also set up an MSR filter to process writes to MSR_KVM_MIGRATION_CONTROL. diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 1fc860c007a3..35eca377543d 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -16,6 +16,11 @@ The acquisition orders for mutexes are as follows: - kvm->slots_lock is taken outside kvm->irq_lock, though acquiring them together is quite rare. +- Unlike kvm->slots_lock, kvm->slots_arch_lock is released before + synchronize_srcu(&kvm->srcu). Therefore kvm->slots_arch_lock + can be taken inside a kvm->srcu read-side critical section, + while kvm->slots_lock cannot. + On x86: - vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock diff --git a/Documentation/virt/kvm/mmu.rst b/Documentation/virt/kvm/mmu.rst index 5bfe28b0728e..f60f5488e121 100644 --- a/Documentation/virt/kvm/mmu.rst +++ b/Documentation/virt/kvm/mmu.rst @@ -171,8 +171,8 @@ Shadow pages contain the following information: shadow pages) so role.quadrant takes values in the range 0..3. Each quadrant maps 1GB virtual address space. role.access: - Inherited guest access permissions in the form uwx. Note execute - permission is positive, not negative. + Inherited guest access permissions from the parent ptes in the form uwx. + Note execute permission is positive, not negative. role.invalid: The page is invalid and should not be used. It is a root page that is currently pinned (by a cpu hardware register pointing to it); once it is @@ -180,8 +180,8 @@ Shadow pages contain the following information: role.gpte_is_8_bytes: Reflects the size of the guest PTE for which the page is valid, i.e. '1' if 64-bit gptes are in use, '0' if 32-bit gptes are in use. - role.nxe: - Contains the value of efer.nxe for which the page is valid. + role.efer_nx: + Contains the value of efer.nx for which the page is valid. role.cr0_wp: Contains the value of cr0.wp for which the page is valid. role.smep_andnot_wp: @@ -192,9 +192,6 @@ Shadow pages contain the following information: Contains the value of cr4.smap && !cr0.wp for which the page is valid (pages for which this is true are different from other pages; see the treatment of cr0.wp=0 below). - role.ept_sp: - This is a virtual flag to denote a shadowed nested EPT page. ept_sp - is true if "cr0_wp && smap_andnot_wp", an otherwise invalid combination. role.smm: Is 1 if the page is valid in system management mode. This field determines which of the kvm_memslots array was used to build this diff --git a/Documentation/virt/kvm/msr.rst b/Documentation/virt/kvm/msr.rst index e37a14c323d2..9315fc385fb0 100644 --- a/Documentation/virt/kvm/msr.rst +++ b/Documentation/virt/kvm/msr.rst @@ -376,3 +376,16 @@ data: write '1' to bit 0 of the MSR, this causes the host to re-scan its queue and check if there are more notifications pending. The MSR is available if KVM_FEATURE_ASYNC_PF_INT is present in CPUID. + +MSR_KVM_MIGRATION_CONTROL: + 0x4b564d08 + +data: + This MSR is available if KVM_FEATURE_MIGRATION_CONTROL is present in + CPUID. Bit 0 represents whether live migration of the guest is allowed. + + When a guest is started, bit 0 will be 0 if the guest has encrypted + memory and 1 if the guest does not have encrypted memory. If the + guest is communicating page encryption status to the host using the + ``KVM_HC_MAP_GPA_RANGE`` hypercall, it can set bit 0 in this MSR to + allow live migration of the guest. diff --git a/Documentation/virt/kvm/s390-pv-boot.rst b/Documentation/virt/kvm/s390-pv-boot.rst index ad1f7866c001..73a6083cb5e7 100644 --- a/Documentation/virt/kvm/s390-pv-boot.rst +++ b/Documentation/virt/kvm/s390-pv-boot.rst @@ -10,7 +10,7 @@ The memory of Protected Virtual Machines (PVMs) is not accessible to I/O or the hypervisor. In those cases where the hypervisor needs to access the memory of a PVM, that memory must be made accessible. Memory made accessible to the hypervisor will be encrypted. See -:doc:`s390-pv` for details." +Documentation/virt/kvm/s390-pv.rst for details." On IPL (boot) a small plaintext bootloader is started, which provides information about the encrypted components and necessary metadata to diff --git a/Documentation/virt/kvm/vcpu-requests.rst b/Documentation/virt/kvm/vcpu-requests.rst index 5feb3706a7ae..ad2915ef7020 100644 --- a/Documentation/virt/kvm/vcpu-requests.rst +++ b/Documentation/virt/kvm/vcpu-requests.rst @@ -118,10 +118,12 @@ KVM_REQ_MMU_RELOAD necessary to inform each VCPU to completely refresh the tables. This request is used for that. -KVM_REQ_PENDING_TIMER +KVM_REQ_UNBLOCK - This request may be made from a timer handler run on the host on behalf - of a VCPU. It informs the VCPU thread to inject a timer interrupt. + This request informs the vCPU to exit kvm_vcpu_block. It is used for + example from timer handlers that run on the host on behalf of a vCPU, + or in order to update the interrupt routing and ensure that assigned + devices will wake up the vCPU. KVM_REQ_UNHALT @@ -302,6 +304,6 @@ VCPU returns from the call. References ========== -.. [atomic-ops] Documentation/core-api/atomic_ops.rst +.. [atomic-ops] Documentation/atomic_bitops.txt and Documentation/atomic_t.txt .. [memory-barriers] Documentation/memory-barriers.txt .. [lwn-mb] https://lwn.net/Articles/573436/ diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst index 09e28507f5b2..a14c2938e7af 100644 --- a/Documentation/vm/hmm.rst +++ b/Documentation/vm/hmm.rst @@ -332,7 +332,7 @@ between device driver specific code and shared common code: walks to fill in the ``args->src`` array with PFNs to be migrated. The ``invalidate_range_start()`` callback is passed a ``struct mmu_notifier_range`` with the ``event`` field set to - ``MMU_NOTIFY_MIGRATE`` and the ``migrate_pgmap_owner`` field set to + ``MMU_NOTIFY_MIGRATE`` and the ``owner`` field set to the ``args->pgmap_owner`` field passed to migrate_vma_setup(). This is allows the device driver to skip the invalidation callback and only invalidate device private MMU mappings that are actually migrating. @@ -405,6 +405,23 @@ between device driver specific code and shared common code: The lock can now be released. +Exclusive access memory +======================= + +Some devices have features such as atomic PTE bits that can be used to implement +atomic access to system memory. To support atomic operations to a shared virtual +memory page such a device needs access to that page which is exclusive of any +userspace access from the CPU. The ``make_device_exclusive_range()`` function +can be used to make a memory range inaccessible from userspace. + +This replaces all mappings for pages in the given range with special swap +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 +which point any CPU faults on the page may proceed as described. + Memory cgroup (memcg) and rss accounting ======================================== diff --git a/Documentation/vm/memory-model.rst b/Documentation/vm/memory-model.rst index ce398a7dc6cd..30e8fbed6914 100644 --- a/Documentation/vm/memory-model.rst +++ b/Documentation/vm/memory-model.rst @@ -14,15 +14,11 @@ for the CPU. Then there could be several contiguous ranges at completely distinct addresses. And, don't forget about NUMA, where different memory banks are attached to different CPUs. -Linux abstracts this diversity using one of the three memory models: -FLATMEM, DISCONTIGMEM and SPARSEMEM. Each architecture defines what +Linux abstracts this diversity using one of the two memory models: +FLATMEM and SPARSEMEM. Each architecture defines what memory models it supports, what the default memory model is and whether it is possible to manually override that default. -.. note:: - At time of this writing, DISCONTIGMEM is considered deprecated, - although it is still in use by several architectures. - All the memory models track the status of physical page frames using struct page arranged in one or more arrays. @@ -63,43 +59,6 @@ straightforward: `PFN - ARCH_PFN_OFFSET` is an index to the The `ARCH_PFN_OFFSET` defines the first page frame number for systems with physical memory starting at address different from 0. -DISCONTIGMEM -============ - -The DISCONTIGMEM model treats the physical memory as a collection of -`nodes` similarly to how Linux NUMA support does. For each node Linux -constructs an independent memory management subsystem represented by -`struct pglist_data` (or `pg_data_t` for short). Among other -things, `pg_data_t` holds the `node_mem_map` array that maps -physical pages belonging to that node. The `node_start_pfn` field of -`pg_data_t` is the number of the first page frame belonging to that -node. - -The architecture setup code should call :c:func:`free_area_init_node` for -each node in the system to initialize the `pg_data_t` object and its -`node_mem_map`. - -Every `node_mem_map` behaves exactly as FLATMEM's `mem_map` - -every physical page frame in a node has a `struct page` entry in the -`node_mem_map` array. When DISCONTIGMEM is enabled, a portion of the -`flags` field of the `struct page` encodes the node number of the -node hosting that page. - -The conversion between a PFN and the `struct page` in the -DISCONTIGMEM model became slightly more complex as it has to determine -which node hosts the physical page and which `pg_data_t` object -holds the `struct page`. - -Architectures that support DISCONTIGMEM provide :c:func:`pfn_to_nid` -to convert PFN to the node number. The opposite conversion helper -:c:func:`page_to_nid` is generic as it uses the node number encoded in -page->flags. - -Once the node number is known, the PFN can be used to index -appropriate `node_mem_map` array to access the `struct page` and -the offset of the `struct page` from the `node_mem_map` plus -`node_start_pfn` is the PFN of that page. - SPARSEMEM ========= diff --git a/Documentation/vm/slub.rst b/Documentation/vm/slub.rst index 03f294a638bd..d3028554b1e9 100644 --- a/Documentation/vm/slub.rst +++ b/Documentation/vm/slub.rst @@ -181,7 +181,7 @@ SLUB Debug output Here is a sample of slub debug output:: ==================================================================== - BUG kmalloc-8: Redzone overwritten + BUG kmalloc-8: Right Redzone overwritten -------------------------------------------------------------------- INFO: 0xc90f6d28-0xc90f6d2b. First byte 0x00 instead of 0xcc @@ -189,10 +189,10 @@ Here is a sample of slub debug output:: INFO: Object 0xc90f6d20 @offset=3360 fp=0xc90f6d58 INFO: Allocated in get_modalias+0x61/0xf5 age=53 cpu=1 pid=554 - Bytes b4 0xc90f6d10: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ - Object 0xc90f6d20: 31 30 31 39 2e 30 30 35 1019.005 - Redzone 0xc90f6d28: 00 cc cc cc . - Padding 0xc90f6d50: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ + Bytes b4 (0xc90f6d10): 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ + Object (0xc90f6d20): 31 30 31 39 2e 30 30 35 1019.005 + Redzone (0xc90f6d28): 00 cc cc cc . + Padding (0xc90f6d50): 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ [<c010523d>] dump_trace+0x63/0x1eb [<c01053df>] show_trace_log_lvl+0x1a/0x2f diff --git a/Documentation/vm/unevictable-lru.rst b/Documentation/vm/unevictable-lru.rst index 0e1490524f53..eae3af17f2d9 100644 --- a/Documentation/vm/unevictable-lru.rst +++ b/Documentation/vm/unevictable-lru.rst @@ -389,14 +389,14 @@ mlocked, munlock_vma_page() updates that zone statistics for the number of mlocked pages. Note, however, that at this point we haven't checked whether the page is mapped by other VM_LOCKED VMAs. -We can't call try_to_munlock(), the function that walks the reverse map to +We can't call page_mlock(), the function that walks the reverse map to check for other VM_LOCKED VMAs, without first isolating the page from the LRU. -try_to_munlock() is a variant of try_to_unmap() and thus requires that the page +page_mlock() is a variant of try_to_unmap() and thus requires that the page not be on an LRU list [more on these below]. However, the call to -isolate_lru_page() could fail, in which case we couldn't try_to_munlock(). So, +isolate_lru_page() could fail, in which case we can't call page_mlock(). So, we go ahead and clear PG_mlocked up front, as this might be the only chance we -have. If we can successfully isolate the page, we go ahead and -try_to_munlock(), which will restore the PG_mlocked flag and update the zone +have. If we can successfully isolate the page, we go ahead and call +page_mlock(), which will restore the PG_mlocked flag and update the zone page statistics if it finds another VMA holding the page mlocked. If we fail to isolate the page, we'll have left a potentially mlocked page on the LRU. This is fine, because we'll catch it later if and if vmscan tries to reclaim @@ -545,31 +545,24 @@ munlock or munmap system calls, mm teardown (munlock_vma_pages_all), reclaim, holepunching, and truncation of file pages and their anonymous COWed pages. -try_to_munlock() Reverse Map Scan +page_mlock() Reverse Map Scan --------------------------------- -.. warning:: - [!] TODO/FIXME: a better name might be page_mlocked() - analogous to the - page_referenced() reverse map walker. - When munlock_vma_page() [see section :ref:`munlock()/munlockall() System Call Handling <munlock_munlockall_handling>` above] tries to munlock a page, it needs to determine whether or not the page is mapped by any VM_LOCKED VMA without actually attempting to unmap all PTEs from the page. For this purpose, the unevictable/mlock infrastructure -introduced a variant of try_to_unmap() called try_to_munlock(). +introduced a variant of try_to_unmap() called page_mlock(). -try_to_munlock() calls the same functions as try_to_unmap() for anonymous and -mapped file and KSM pages with a flag argument specifying unlock versus unmap -processing. Again, these functions walk the respective reverse maps looking -for VM_LOCKED VMAs. When such a VMA is found, as in the try_to_unmap() case, -the functions mlock the page via mlock_vma_page() and return SWAP_MLOCK. This -undoes the pre-clearing of the page's PG_mlocked done by munlock_vma_page. +page_mlock() walks the respective reverse maps looking for VM_LOCKED VMAs. When +such a VMA is found the page is mlocked via mlock_vma_page(). This undoes the +pre-clearing of the page's PG_mlocked done by munlock_vma_page. -Note that try_to_munlock()'s reverse map walk must visit every VMA in a page's +Note that page_mlock()'s reverse map walk must visit every VMA in a page's reverse map to determine that a page is NOT mapped into any VM_LOCKED VMA. However, the scan can terminate when it encounters a VM_LOCKED VMA. -Although try_to_munlock() might be called a great many times when munlocking a +Although page_mlock() might be called a great many times when munlocking a large region or tearing down a large address space that has been mlocked via mlockall(), overall this is a fairly rare event. @@ -602,7 +595,7 @@ inactive lists to the appropriate node's unevictable list. shrink_inactive_list() should only see SHM_LOCK'd pages that became SHM_LOCK'd after shrink_active_list() had moved them to the inactive list, or pages mapped into VM_LOCKED VMAs that munlock_vma_page() couldn't isolate from the LRU to -recheck via try_to_munlock(). shrink_inactive_list() won't notice the latter, +recheck via page_mlock(). shrink_inactive_list() won't notice the latter, but will pass on to shrink_page_list(). shrink_page_list() again culls obviously unevictable pages that it could diff --git a/Documentation/vm/zswap.rst b/Documentation/vm/zswap.rst index d8d9fa4a1f0d..8edb8d578caf 100644 --- a/Documentation/vm/zswap.rst +++ b/Documentation/vm/zswap.rst @@ -10,7 +10,7 @@ Overview Zswap is a lightweight compressed cache for swap pages. It takes pages that are in the process of being swapped out and attempts to compress them into a dynamically allocated RAM-based memory pool. zswap basically trades CPU cycles -for potentially reduced swap I/O. This trade-off can also result in a +for potentially reduced swap I/O. This trade-off can also result in a significant performance improvement if reads from the compressed cache are faster than reads from a swap device. @@ -26,7 +26,7 @@ faster than reads from a swap device. performance impact of swapping. * Overcommitted guests that share a common I/O resource can dramatically reduce their swap I/O pressure, avoiding heavy handed I/O - throttling by the hypervisor. This allows more work to get done with less + throttling by the hypervisor. This allows more work to get done with less impact to the guest workload and guests sharing the I/O subsystem * Users with SSDs as swap devices can extend the life of the device by drastically reducing life-shortening writes. diff --git a/Documentation/x86/amd-memory-encryption.rst b/Documentation/x86/amd-memory-encryption.rst index c48d452d0718..a1940ebe7be5 100644 --- a/Documentation/x86/amd-memory-encryption.rst +++ b/Documentation/x86/amd-memory-encryption.rst @@ -53,7 +53,7 @@ CPUID function 0x8000001f reports information related to SME:: system physical addresses, not guest physical addresses) -If support for SME is present, MSR 0xc00100010 (MSR_K8_SYSCFG) can be used to +If support for SME is present, MSR 0xc00100010 (MSR_AMD64_SYSCFG) can be used to determine if SME is enabled and/or to enable memory encryption:: 0xc0010010: @@ -79,7 +79,7 @@ The state of SME in the Linux kernel can be documented as follows: The CPU supports SME (determined through CPUID instruction). - Enabled: - Supported and bit 23 of MSR_K8_SYSCFG is set. + Supported and bit 23 of MSR_AMD64_SYSCFG is set. - Active: Supported, Enabled and the Linux kernel is actively applying @@ -89,7 +89,7 @@ The state of SME in the Linux kernel can be documented as follows: SME can also be enabled and activated in the BIOS. If SME is enabled and activated in the BIOS, then all memory accesses will be encrypted and it will not be necessary to activate the Linux memory encryption support. If the BIOS -merely enables SME (sets bit 23 of the MSR_K8_SYSCFG), then Linux can activate +merely enables SME (sets bit 23 of the MSR_AMD64_SYSCFG), then Linux can activate memory encryption by default (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y) or by supplying mem_encrypt=on on the kernel command line. However, if BIOS does not enable SME, then Linux will not be able to activate memory encryption, even diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst index fc844913dece..894a19897005 100644 --- a/Documentation/x86/boot.rst +++ b/Documentation/x86/boot.rst @@ -1343,7 +1343,7 @@ follow:: In addition to read/modify/write the setup header of the struct boot_params as that of 16-bit boot protocol, the boot loader should also fill the additional fields of the struct boot_params as -described in chapter :doc:`zero-page`. +described in chapter Documentation/x86/zero-page.rst. After setting up the struct boot_params, the boot loader can load the 32/64-bit kernel in the same way as that of 16-bit boot protocol. @@ -1379,7 +1379,7 @@ can be calculated as follows:: In addition to read/modify/write the setup header of the struct boot_params as that of 16-bit boot protocol, the boot loader should also fill the additional fields of the struct boot_params as described -in chapter :doc:`zero-page`. +in chapter Documentation/x86/zero-page.rst. After setting up the struct boot_params, the boot loader can load 64-bit kernel in the same way as that of 16-bit boot protocol, but diff --git a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst new file mode 100644 index 000000000000..7c051e714943 --- /dev/null +++ b/Documentation/x86/buslock.rst @@ -0,0 +1,126 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: <isonum.txt> + +=============================== +Bus lock detection and handling +=============================== + +:Copyright: |copy| 2021 Intel Corporation +:Authors: - Fenghua Yu <fenghua.yu@intel.com> + - Tony Luck <tony.luck@intel.com> + +Problem +======= + +A split lock is any atomic operation whose operand crosses two cache lines. +Since the operand spans two cache lines and the operation must be atomic, +the system locks the bus while the CPU accesses the two cache lines. + +A bus lock is acquired through either split locked access to writeback (WB) +memory or any locked access to non-WB memory. This is typically thousands of +cycles slower than an atomic operation within a cache line. It also disrupts +performance on other cores and brings the whole system to its knees. + +Detection +========= + +Intel processors may support either or both of the following hardware +mechanisms to detect split locks and bus locks. + +#AC exception for split lock detection +-------------------------------------- + +Beginning with the Tremont Atom CPU split lock operations may raise an +Alignment Check (#AC) exception when a split lock operation is attemped. + +#DB exception for bus lock detection +------------------------------------ + +Some CPUs have the ability to notify the kernel by an #DB trap after a user +instruction acquires a bus lock and is executed. This allows the kernel to +terminate the application or to enforce throttling. + +Software handling +================= + +The kernel #AC and #DB handlers handle bus lock based on the kernel +parameter "split_lock_detect". Here is a summary of different options: + ++------------------+----------------------------+-----------------------+ +|split_lock_detect=|#AC for split lock |#DB for bus lock | ++------------------+----------------------------+-----------------------+ +|off |Do nothing |Do nothing | ++------------------+----------------------------+-----------------------+ +|warn |Kernel OOPs |Warn once per task and | +|(default) |Warn once per task and |and continues to run. | +| |disable future checking | | +| |When both features are | | +| |supported, warn in #AC | | ++------------------+----------------------------+-----------------------+ +|fatal |Kernel OOPs |Send SIGBUS to user. | +| |Send SIGBUS to user | | +| |When both features are | | +| |supported, fatal in #AC | | ++------------------+----------------------------+-----------------------+ +|ratelimit:N |Do nothing |Limit bus lock rate to | +|(0 < N <= 1000) | |N bus locks per second | +| | |system wide and warn on| +| | |bus locks. | ++------------------+----------------------------+-----------------------+ + +Usages +====== + +Detecting and handling bus lock may find usages in various areas: + +It is critical for real time system designers who build consolidated real +time systems. These systems run hard real time code on some cores and run +"untrusted" user processes on other cores. The hard real time cannot afford +to have any bus lock from the untrusted processes to hurt real time +performance. To date the designers have been unable to deploy these +solutions as they have no way to prevent the "untrusted" user code from +generating split lock and bus lock to block the hard real time code to +access memory during bus locking. + +It's also useful for general computing to prevent guests or user +applications from slowing down the overall system by executing instructions +with bus lock. + + +Guidance +======== +off +--- + +Disable checking for split lock and bus lock. This option can be useful if +there are legacy applications that trigger these events at a low rate so +that mitigation is not needed. + +warn +---- + +A warning is emitted when a bus lock is detected which allows to identify +the offending application. This is the default behavior. + +fatal +----- + +In this case, the bus lock is not tolerated and the process is killed. + +ratelimit +--------- + +A system wide bus lock rate limit N is specified where 0 < N <= 1000. This +allows a bus lock rate up to N bus locks per second. When the bus lock rate +is exceeded then any task which is caught via the buslock #DB exception is +throttled by enforced sleeps until the rate goes under the limit again. + +This is an effective mitigation in cases where a minimal impact can be +tolerated, but an eventual Denial of Service attack has to be prevented. It +allows to identify the offending processes and analyze whether they are +malicious or just badly written. + +Selecting a rate limit of 1000 allows the bus to be locked for up to about +seven million cycles each second (assuming 7000 cycles for each bus +lock). On a 2 GHz processor that would be about 0.35% system slowdown. diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 4693e192b447..0004f5d2283e 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -29,6 +29,7 @@ x86-specific Documentation microcode resctrl tsx_async_abort + buslock usb-legacy-support i386/index x86_64/index diff --git a/Documentation/x86/mtrr.rst b/Documentation/x86/mtrr.rst index c5b695d75349..9f0b1851771a 100644 --- a/Documentation/x86/mtrr.rst +++ b/Documentation/x86/mtrr.rst @@ -28,7 +28,7 @@ are aligned with platform MTRR setup. If MTRRs are only set up by the platform firmware code though and the OS does not make any specific MTRR mapping requests mtrr_type_lookup() should always return MTRR_TYPE_INVALID. -For details refer to :doc:`pat`. +For details refer to Documentation/x86/pat.rst. .. tip:: On Intel P6 family processors (Pentium Pro, Pentium II and later) diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/x86/x86_64/boot-options.rst index 324cefff92e7..5f62b3b86357 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/x86/x86_64/boot-options.rst @@ -247,16 +247,11 @@ Multiple x86-64 PCI-DMA mapping implementations exist, for example: Kernel boot message: "PCI-DMA: Using software bounce buffering for IO (SWIOTLB)" - 4. <arch/x86_64/pci-calgary.c> : IBM Calgary hardware IOMMU. Used in IBM - pSeries and xSeries servers. This hardware IOMMU supports DMA address - mapping with memory protection, etc. - Kernel boot message: "PCI-DMA: Using Calgary IOMMU" - :: iommu=[<size>][,noagp][,off][,force][,noforce] [,memaper[=<order>]][,merge][,fullflush][,nomerge] - [,noaperture][,calgary] + [,noaperture] General iommu options: @@ -295,8 +290,6 @@ iommu options only relevant to the AMD GART hardware IOMMU: Don't initialize the AGP driver and use full aperture. panic Always panic when IOMMU overflows. - calgary - Use the Calgary IOMMU if it is available iommu options only relevant to the software bounce buffering (SWIOTLB) IOMMU implementation: @@ -307,28 +300,6 @@ implementation: force Force all IO through the software TLB. -Settings for the IBM Calgary hardware IOMMU currently found in IBM -pSeries and xSeries machines - - calgary=[64k,128k,256k,512k,1M,2M,4M,8M] - Set the size of each PCI slot's translation table when using the - Calgary IOMMU. This is the size of the translation table itself - in main memory. The smallest table, 64k, covers an IO space of - 32MB; the largest, 8MB table, can cover an IO space of 4GB. - Normally the kernel will make the right choice by itself. - calgary=[translate_empty_slots] - Enable translation even on slots that have no devices attached to - them, in case a device will be hotplugged in the future. - calgary=[disable=<PCI bus number>] - Disable translation on a given PHB. For - example, the built-in graphics adapter resides on the first bridge - (PCI bus number 0); if translation (isolation) is enabled on this - bridge, X servers that access the hardware directly from user - space might stop working. Use this option if you have devices that - are accessed from userspace directly on some PCI host bridge. - panic - Always panic when IOMMU overflows - Miscellaneous ============= |