diff options
Diffstat (limited to 'Documentation')
137 files changed, 3756 insertions, 1523 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 7c2b846521f3..8494ef27e8d2 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -7,6 +7,7 @@ Description: all descendant memdevs for unbind. Writing '1' to this attribute flushes that work. + What: /sys/bus/cxl/devices/memX/firmware_version Date: December, 2020 KernelVersion: v5.12 @@ -16,6 +17,7 @@ Description: Memory Device Output Payload in the CXL-2.0 specification. + What: /sys/bus/cxl/devices/memX/ram/size Date: December, 2020 KernelVersion: v5.12 @@ -25,6 +27,7 @@ Description: identically named field in the Identify Memory Device Output Payload in the CXL-2.0 specification. + What: /sys/bus/cxl/devices/memX/pmem/size Date: December, 2020 KernelVersion: v5.12 @@ -34,6 +37,7 @@ Description: identically named field in the Identify Memory Device Output Payload in the CXL-2.0 specification. + What: /sys/bus/cxl/devices/memX/serial Date: January, 2022 KernelVersion: v5.18 @@ -43,6 +47,7 @@ Description: capability. Mandatory for CXL devices, see CXL 2.0 8.1.12.2 Memory Device PCIe Capabilities and Extended Capabilities. + What: /sys/bus/cxl/devices/memX/numa_node Date: January, 2022 KernelVersion: v5.18 @@ -52,114 +57,334 @@ Description: host PCI device for this memory device, emit the CPU node affinity for this device. + 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. + (RO) 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/*/modalias Date: December, 2021 KernelVersion: v5.18 Contact: linux-cxl@vger.kernel.org Description: - CXL device objects export the modalias attribute which mirrors - the same value communicated in the MODALIAS environment variable - for uevents for devices on the "cxl" bus. + (RO) CXL device objects export the modalias attribute which + mirrors the same value communicated in the MODALIAS 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 + (RO) 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. + (RO) 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 + (RO) 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. + (RO) 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. + (RO) 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. + (RO) 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 + (RO) 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 + (RO) 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. + + +What: /sys/bus/cxl/devices/endpointX/CDAT +Date: July, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) If this sysfs entry is not present no DOE mailbox was + found to support CDAT data. If it is present and the length of + the data is 0 reading the CDAT data failed. Otherwise the CDAT + data is reported. + + +What: /sys/bus/cxl/devices/decoderX.Y/mode +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it + translates from a host physical address range, to a device local + address range. Device-local address ranges are further split + into a 'ram' (volatile memory) range and 'pmem' (persistent + memory) range. The 'mode' attribute emits one of 'ram', 'pmem', + 'mixed', or 'none'. The 'mixed' indication is for error cases + when a decoder straddles the volatile/persistent partition + boundary, and 'none' indicates the decoder is not actively + decoding, or no DPA allocation policy has been set. + + 'mode' can be written, when the decoder is in the 'disabled' + state, with either 'ram' or 'pmem' to set the boundaries for the + next allocation. + + +What: /sys/bus/cxl/devices/decoderX.Y/dpa_resource +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) When a CXL decoder is of devtype "cxl_decoder_endpoint", + and its 'dpa_size' attribute is non-zero, this attribute + indicates the device physical address (DPA) base address of the + allocation. + + +What: /sys/bus/cxl/devices/decoderX.Y/dpa_size +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it + translates from a host physical address range, to a device local + address range. The range, base address plus length in bytes, of + DPA allocated to this decoder is conveyed in these 2 attributes. + Allocations can be mutated as long as the decoder is in the + disabled state. A write to 'dpa_size' releases the previous DPA + allocation and then attempts to allocate from the free capacity + in the device partition referred to by 'decoderX.Y/mode'. + Allocate and free requests can only be performed on the highest + instance number disabled decoder with non-zero size. I.e. + allocations are enforced to occur in increasing 'decoderX.Y/id' + order and frees are enforced to occur in decreasing + 'decoderX.Y/id' order. + + +What: /sys/bus/cxl/devices/decoderX.Y/interleave_ways +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) The number of targets across which this decoder's host + physical address (HPA) memory range is interleaved. The device + maps every Nth block of HPA (of size == + 'interleave_granularity') to consecutive DPA addresses. The + decoder's position in the interleave is determined by the + device's (endpoint or switch) switch ancestry. For root + decoders their interleave is specified by platform firmware and + they only specify a downstream target order for host bridges. + + +What: /sys/bus/cxl/devices/decoderX.Y/interleave_granularity +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) The number of consecutive bytes of host physical address + space this decoder claims at address N before the decode rotates + to the next target in the interleave at address N + + interleave_granularity (assuming N is aligned to + interleave_granularity). + + +What: /sys/bus/cxl/devices/decoderX.Y/create_pmem_region +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Write a string in the form 'regionZ' to start the process + of defining a new persistent memory region (interleave-set) + within the decode range bounded by root decoder 'decoderX.Y'. + The value written must match the current value returned from + reading this attribute. An atomic compare exchange operation is + done on write to assign the requested id to a region and + allocate the region-id for the next creation attempt. EBUSY is + returned if the region name written does not match the current + cached value. + + +What: /sys/bus/cxl/devices/decoderX.Y/delete_region +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (WO) Write a string in the form 'regionZ' to delete that region, + provided it is currently idle / not bound to a driver. + + +What: /sys/bus/cxl/devices/regionZ/uuid +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Write a unique identifier for the region. This field must + be set for persistent regions and it must not conflict with the + UUID of another region. + + +What: /sys/bus/cxl/devices/regionZ/interleave_granularity +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Set the number of consecutive bytes each device in the + interleave set will claim. The possible interleave granularity + values are determined by the CXL spec and the participating + devices. + + +What: /sys/bus/cxl/devices/regionZ/interleave_ways +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Configures the number of devices participating in the + region is set by writing this value. Each device will provide + 1/interleave_ways of storage for the region. + + +What: /sys/bus/cxl/devices/regionZ/size +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) System physical address space to be consumed by the region. + When written trigger the driver to allocate space out of the + parent root decoder's address space. When read the size of the + address space is reported and should match the span of the + region's resource attribute. Size shall be set after the + interleave configuration parameters. Once set it cannot be + changed, only freed by writing 0. The kernel makes no guarantees + that data is maintained over an address space freeing event, and + there is no guarantee that a free followed by an allocate + results in the same address being allocated. + + +What: /sys/bus/cxl/devices/regionZ/resource +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) A region is a contiguous partition of a CXL root decoder + address space. Region capacity is allocated by writing to the + size attribute, the resulting physical address space determined + by the driver is reflected here. It is therefore not useful to + read this before writing a value to the size attribute. + + +What: /sys/bus/cxl/devices/regionZ/target[0..N] +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Write an endpoint decoder object name to 'targetX' where X + is the intended position of the endpoint device in the region + interleave and N is the 'interleave_ways' setting for the + region. ENXIO is returned if the write results in an impossible + to map decode scenario, like the endpoint is unreachable at that + position relative to the root decoder interleave. EBUSY is + returned if the position in the region is already occupied, or + if the region is not in a state to accept interleave + configuration changes. EINVAL is returned if the object name is + not an endpoint decoder. Once all positions have been + successfully written a final validation for decode conflicts is + performed before activating the region. + + +What: /sys/bus/cxl/devices/regionZ/commit +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Write a boolean 'true' string value to this attribute to + trigger the region to transition from the software programmed + state to the actively decoding in hardware state. The commit + operation in addition to validating that the region is in proper + configured state, validates that the decoders are being + committed in spec mandated order (last committed decoder id + + 1), and checks that the hardware accepts the commit request. + Reading this value indicates whether the region is committed or + not. diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-caps b/Documentation/ABI/testing/sysfs-bus-event_source-devices-caps new file mode 100644 index 000000000000..8757dcf41c08 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-caps @@ -0,0 +1,18 @@ +What: /sys/bus/event_source/devices/<dev>/caps +Date: May 2022 +KernelVersion: 5.19 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: + Attribute group to describe the capabilities exposed + for a particular pmu. Each attribute of this group can + expose information specific to a PMU, say pmu_name, so that + userspace can understand some of the feature which the + platform specific PMU supports. + + One of the example available capability in supported platform + like Intel is pmu_name, which exposes underlying CPU name known + to the PMU driver. + + Example output in powerpc: + grep . /sys/bus/event_source/devices/cpu/caps/* + /sys/bus/event_source/devices/cpu/caps/pmu_name:POWER9 diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 9b583dd0298b..083ac2d63eef 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -580,3 +580,33 @@ Date: January 2022 Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> Description: Controls max # of node block writes to be used for roll forward recovery. This can limit the roll forward recovery time. + +What: /sys/fs/f2fs/<disk>/unusable_blocks_per_sec +Date: June 2022 +Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> +Description: Shows the number of unusable blocks in a section which was defined by + the zone capacity reported by underlying zoned device. + +What: /sys/fs/f2fs/<disk>/current_atomic_write +Date: July 2022 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: Show the total current atomic write block count, which is not committed yet. + This is a read-only entry. + +What: /sys/fs/f2fs/<disk>/peak_atomic_write +Date: July 2022 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: Show the peak value of total current atomic write block count after boot. + If you write "0" here, you can initialize to "0". + +What: /sys/fs/f2fs/<disk>/committed_atomic_block +Date: July 2022 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: Show the accumulated total committed atomic write block count after boot. + If you write "0" here, you can initialize to "0". + +What: /sys/fs/f2fs/<disk>/revoked_atomic_block +Date: July 2022 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: Show the accumulated total revoked atomic write block count after boot. + If you write "0" here, you can initialize to "0". diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index 9e9556826450..2ce2a38cdd55 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -422,6 +422,14 @@ The possible values in this file are: 'RSB filling' Protection of RSB on context switch enabled ============= =========================================== + - EIBRS Post-barrier Return Stack Buffer (PBRSB) protection status: + + =========================== ======================================================= + 'PBRSB-eIBRS: SW sequence' CPU is affected and protection of RSB on VMEXIT enabled + 'PBRSB-eIBRS: Vulnerable' CPU is vulnerable + 'PBRSB-eIBRS: Not affected' CPU is not affected by PBRSB + =========================== ======================================================= + Full mitigation might require a microcode update from the CPU vendor. When the necessary microcode is not available, the kernel will report vulnerability. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 9dc68a12a5bf..db5de5f0b9d3 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1158,8 +1158,12 @@ nopku [X86] Disable Memory Protection Keys CPU feature found in some Intel CPUs. - <module>.async_probe [KNL] - Enable asynchronous probe on this module. + <module>.async_probe[=<bool>] [KNL] + If no <bool> value is specified or if the value + specified is not a valid <bool>, enable asynchronous + probe on this module. Otherwise, enable/disable + asynchronous probe on this module as indicated by the + <bool> value. See also: module.async_probe early_ioremap_debug [KNL] Enable debug messages in early_ioremap support. This @@ -1673,6 +1677,19 @@ hlt [BUGS=ARM,SH] + hostname= [KNL] Set the hostname (aka UTS nodename). + Format: <string> + This allows setting the system's hostname during early + startup. This sets the name returned by gethostname. + Using this parameter to set the hostname makes it + possible to ensure the hostname is correctly set before + any userspace processes run, avoiding the possibility + that a process may call gethostname before the hostname + has been explicitly set, resulting in the calling + process getting an incorrect result. The string must + not exceed the maximum allowed hostname length (usually + 64 characters) and will be truncated otherwise. + hpet= [X86-32,HPET] option to control HPET usage Format: { enable (default) | disable | force | verbose } @@ -1718,12 +1735,13 @@ hugetlb_free_vmemmap= [KNL] Reguires CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP enabled. + Control if HugeTLB Vmemmap Optimization (HVO) is enabled. Allows heavy hugetlb users to free up some more memory (7 * PAGE_SIZE for each 2MB hugetlb page). - Format: { [oO][Nn]/Y/y/1 | [oO][Ff]/N/n/0 (default) } + Format: { on | off (default) } - [oO][Nn]/Y/y/1: enable the feature - [oO][Ff]/N/n/0: disable the feature + on: enable HVO + off: disable HVO Built with CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON=y, the default is on. @@ -3264,6 +3282,15 @@ For details see: Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst + module.async_probe=<bool> + [KNL] When set to true, modules will use async probing + by default. To enable/disable async probing for a + specific module, use the module specific control that + is documented under <module>.async_probe. When both + module.async_probe and <module>.async_probe are + specified, <module>.async_probe takes precedence for + the specific module. + module.sig_enforce [KNL] When CONFIG_MODULE_SIG is set, this means that modules without (valid) signatures will fail to load. @@ -3553,9 +3580,6 @@ noautogroup Disable scheduler automatic task group creation. - nobats [PPC] Do not use BATs for mapping kernel lowmem - on "Classic" PPC cores. - nocache [ARM] nodsp [SH] Disable hardware DSP at boot time. @@ -3725,9 +3749,6 @@ nolapic_timer [X86-32,APIC] Do not use the local APIC timer. - noltlbs [PPC] Do not use large page/tlb entries for kernel - lowmem mapping on PPC40x and PPC8xx - nomca [IA-64] Disable machine check abort handling nomce [X86-32] Disable Machine Check Exception diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index a90330d0a837..8e2727dc18d4 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -164,8 +164,8 @@ 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_OPTIMIZE_VMEMMAP is set, this enables optimizing - unused vmemmap pages associated with each HugeTLB page. + When CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is set, this enables HugeTLB + Vmemmap Optimization (HVO). 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 0f56ecd8ac05..a3c9e8ad8fa0 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -653,8 +653,8 @@ block might fail: - Concurrent activity that operates on the same physical memory area, such as allocating gigantic pages, can result in temporary offlining failures. -- Out of memory when dissolving huge pages, especially when freeing unused - vmemmap pages associated with each hugetlb page is enabled. +- Out of memory when dissolving huge pages, especially when HugeTLB Vmemmap + Optimization (HVO) is enabled. Offlining code may be able to migrate huge page contents, but may not be able to dissolve the source huge page because it fails allocating (unmovable) pages diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 8ab042beeb76..ee6572b1edad 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -592,6 +592,18 @@ to the guest kernel command line (see Documentation/admin-guide/kernel-parameters.rst). +nmi_wd_lpm_factor (PPC only) +============================ + +Factor to apply to the NMI watchdog timeout (only when ``nmi_watchdog`` is +set to 1). This factor represents the percentage added to +``watchdog_thresh`` when calculating the NMI watchdog timeout during an +LPM. The soft lockup timeout is not impacted. + +A value of 0 means no change. The default value is 200 meaning the NMI +watchdog is set to 30s (based on ``watchdog_thresh`` equal to 10). + + numa_balancing ============== diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index f74f722ad702..9b833e439f09 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -569,8 +569,7 @@ This knob is not available when the size of 'struct page' (a structure defined in include/linux/mm_types.h) is not power of two (an unusual system config could result in this). -Enable (set to 1) or disable (set to 0) the feature of optimizing vmemmap pages -associated with each HugeTLB page. +Enable (set to 1) or disable (set to 0) HugeTLB Vmemmap Optimization (HVO). Once enabled, the vmemmap pages of subsequent allocation of HugeTLB pages from buddy allocator will be optimized (7 pages per 2MB HugeTLB page and 4095 pages diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst index 437de2a7a5de..a210b8a4df00 100644 --- a/Documentation/bpf/bpf_design_QA.rst +++ b/Documentation/bpf/bpf_design_QA.rst @@ -214,6 +214,12 @@ A: NO. Tracepoints are tied to internal implementation details hence they are subject to change and can break with newer kernels. BPF programs need to change accordingly when this happens. +Q: Are places where kprobes can attach part of the stable ABI? +-------------------------------------------------------------- +A: NO. The places to which kprobes can attach are internal implementation +details, which means that they are subject to change and can break with +newer kernels. BPF programs need to change accordingly when this happens. + Q: How much stack space a BPF program uses? ------------------------------------------- A: Currently all program types are limited to 512 bytes of stack @@ -273,3 +279,22 @@ cc (congestion-control) implementations. If any of these kernel functions has changed, both the in-tree and out-of-tree kernel tcp cc implementations have to be changed. The same goes for the bpf programs and they have to be adjusted accordingly. + +Q: Attaching to arbitrary kernel functions is an ABI? +----------------------------------------------------- +Q: BPF programs can be attached to many kernel functions. Do these +kernel functions become part of the ABI? + +A: NO. + +The kernel function prototypes will change, and BPF programs attaching to +them will need to change. The BPF compile-once-run-everywhere (CO-RE) +should be used in order to make it easier to adapt your BPF programs to +different versions of the kernel. + +Q: Marking a function with BTF_ID makes that function an ABI? +------------------------------------------------------------- +A: NO. + +The BTF_ID macro does not cause a function to become part of the ABI +any more than does the EXPORT_SYMBOL_GPL macro. diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst index f5b2f92822c8..1ebcc6c3fafe 100644 --- a/Documentation/core-api/mm-api.rst +++ b/Documentation/core-api/mm-api.rst @@ -22,16 +22,16 @@ Memory Allocation Controls .. kernel-doc:: include/linux/gfp.h :internal: -.. kernel-doc:: include/linux/gfp.h +.. kernel-doc:: include/linux/gfp_types.h :doc: Page mobility and placement hints -.. kernel-doc:: include/linux/gfp.h +.. kernel-doc:: include/linux/gfp_types.h :doc: Watermark modifiers -.. kernel-doc:: include/linux/gfp.h +.. kernel-doc:: include/linux/gfp_types.h :doc: Reclaim modifiers -.. kernel-doc:: include/linux/gfp.h +.. kernel-doc:: include/linux/gfp_types.h :doc: Useful GFP flag combinations The Slab Cache diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index c9953f86b19d..1eaccf135b30 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -42,9 +42,7 @@ quiet_cmd_chk_bindings = CHKDT $@ quiet_cmd_mk_schema = SCHEMA $@ cmd_mk_schema = f=$$(mktemp) ; \ - $(if $(DT_MK_SCHEMA_FLAGS), \ - printf '%s\n' $(real-prereqs), \ - $(find_all_cmd)) > $$f ; \ + $(find_all_cmd) > $$f ; \ $(DT_MK_SCHEMA) -j $(DT_MK_SCHEMA_FLAGS) @$$f > $@ ; \ rm -f $$f diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index 16eef600d599..ab1b352344ae 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -25,21 +25,6 @@ System Timer (ST) required properties: Its subnodes can be: - watchdog: compatible should be "atmel,at91rm9200-wdt" -RSTC Reset Controller required properties: -- compatible: Should be "atmel,<chip>-rstc". - <chip> can be "at91sam9260", "at91sam9g45", "sama5d3" or "samx7" - it also can be "microchip,sam9x60-rstc" -- reg: Should contain registers location and length -- clocks: phandle to input clock. - -Example: - - rstc@fffffd00 { - compatible = "atmel,at91sam9260-rstc"; - reg = <0xfffffd00 0x10>; - clocks = <&clk32k>; - }; - RAMC SDRAM/DDR Controller required properties: - compatible: Should be "atmel,at91rm9200-sdramc", "syscon" "atmel,at91sam9260-sdramc", diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml index 2d98f7c4d3bc..50ebd8c57795 100644 --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml @@ -20,13 +20,24 @@ properties: compatible: const: google,cros-ec-typec - connector: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + '^connector@[0-9a-f]+$': $ref: /schemas/connector/usb-connector.yaml# + unevaluatedProperties: false + properties: + reg: + maxItems: 1 required: - compatible -additionalProperties: true #fixme +additionalProperties: false examples: - |+ diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml index 2f1b8b6852a0..24fa3d87a40b 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -25,6 +25,7 @@ properties: - description: v2 of CPUFREQ HW (EPSS) items: - enum: + - qcom,sm6375-cpufreq-epss - qcom,sm8250-cpufreq-epss - const: qcom,cpufreq-epss diff --git a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml index 10b3a7a4af36..a11e1b867379 100644 --- a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml +++ b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml @@ -22,6 +22,13 @@ select: compatible: contains: enum: + - qcom,apq8064 + - qcom,apq8096 + - qcom,ipq8064 + - qcom,msm8939 + - qcom,msm8960 + - qcom,msm8974 + - qcom,msm8996 - qcom,qcs404 required: - compatible diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml index 27ba4323d221..1f905d85dd9c 100644 --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml @@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Simple Framebuffer Device Tree Bindings maintainers: - - Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> - Hans de Goede <hdegoede@redhat.com> description: |+ diff --git a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml index 0f628b088cec..14486aee97b4 100644 --- a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml @@ -19,8 +19,14 @@ properties: oneOf: - enum: - x-powers,axp209-gpio + - x-powers,axp221-gpio - x-powers,axp813-gpio - items: + - enum: + - x-powers,axp223-gpio + - x-powers,axp809-gpio + - const: x-powers,axp221-gpio + - items: - const: x-powers,axp803-gpio - const: x-powers,axp813-gpio diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml index 154bee851139..d794deb08bb7 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml @@ -8,7 +8,6 @@ title: Analog Devices ADM1177 Hot Swap Controller and Digital Power Monitor maintainers: - Michael Hennerich <michael.hennerich@analog.com> - - Beniamin Bia <beniamin.bia@analog.com> description: | Analog Devices ADM1177 Hot Swap Controller and Digital Power Monitor diff --git a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml index 7c8f8bdc2333..9c7c66feeffc 100644 --- a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml +++ b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml @@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Freescale MMA7455 and MMA7456 three axis accelerometers maintainers: - - Joachim Eastwood <manabian@gmail.com> - Jonathan Cameron <jic23@kernel.org> description: diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml index 31ffa275f5fa..b97559f23b3a 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Analog Devices AD7091R5 4-Channel 12-Bit ADC maintainers: - - Beniamin Bia <beniamin.bia@analog.com> + - Michael Hennerich <michael.hennerich@analog.com> description: | Analog Devices AD7091R5 4-Channel 12-Bit ADC diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml index 73775174cf57..516fc24d3346 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml @@ -7,8 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Analog Devices AD7606 Simultaneous Sampling ADC maintainers: - - Beniamin Bia <beniamin.bia@analog.com> - - Stefan Popa <stefan.popa@analog.com> + - Michael Hennerich <michael.hennerich@analog.com> description: | Analog Devices AD7606 Simultaneous Sampling ADC diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml index 6404fb73f8ed..43abb300fa3d 100644 --- a/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: NXP LPC1850 ADC bindings maintainers: - - Joachim Eastwood <manabian@gmail.com> + - Jonathan Cameron <jic23@kernel.org> description: Supports the ADC found on the LPC1850 SoC. diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml index 54955f03df93..ae5ce60987fe 100644 --- a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments ADC108S102 and ADC128S102 maintainers: - - Bogdan Pricop <bogdan.pricop@emutex.com> + - Jonathan Cameron <jic23@kernel.org> description: | Family of 8 channel, 10/12 bit, SPI, single ended ADCs. diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml index 9f5e96439c01..2e6abc9d746a 100644 --- a/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments' ads124s08 and ads124s06 ADC chip maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml b/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml index a557761d8016..9fda56fa49c3 100644 --- a/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml +++ b/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml @@ -8,7 +8,6 @@ title: HMC425A 6-bit Digital Step Attenuator maintainers: - Michael Hennerich <michael.hennerich@analog.com> - - Beniamin Bia <beniamin.bia@analog.com> description: | Digital Step Attenuator IIO device with gpio interface. diff --git a/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml b/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml index 479e7065d4eb..0203b83b8587 100644 --- a/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml +++ b/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Freescale FXOS8700 Inertial Measurement Unit maintainers: - - Robert Jones <rjones@gateworks.com> + - Jonathan Cameron <jic23@kernel.org> description: | Accelerometer and magnetometer combo device with an i2c and SPI interface. diff --git a/Documentation/devicetree/bindings/input/adc-joystick.yaml b/Documentation/devicetree/bindings/input/adc-joystick.yaml index 2ee04e03bc22..64d961458ac7 100644 --- a/Documentation/devicetree/bindings/input/adc-joystick.yaml +++ b/Documentation/devicetree/bindings/input/adc-joystick.yaml @@ -45,6 +45,7 @@ additionalProperties: false patternProperties: "^axis@[0-9a-f]+$": type: object + $ref: input.yaml# description: > Represents a joystick axis bound to the given ADC channel. For each entry in the io-channels list, one axis subnode with a matching @@ -57,7 +58,6 @@ patternProperties: description: Index of an io-channels list entry bound to this axis. linux,code: - $ref: /schemas/types.yaml#/definitions/uint32 description: EV_ABS specific event code generated by the axis. abs-range: diff --git a/Documentation/devicetree/bindings/input/adc-keys.txt b/Documentation/devicetree/bindings/input/adc-keys.txt deleted file mode 100644 index 6c8be6a9ace2..000000000000 --- a/Documentation/devicetree/bindings/input/adc-keys.txt +++ /dev/null @@ -1,67 +0,0 @@ -ADC attached resistor ladder buttons ------------------------------------- - -Required properties: - - compatible: "adc-keys" - - io-channels: Phandle to an ADC channel - - io-channel-names = "buttons"; - - keyup-threshold-microvolt: Voltage above or equal to which all the keys are - considered up. - -Optional properties: - - poll-interval: Poll interval time in milliseconds - - autorepeat: Boolean, Enable auto repeat feature of Linux input - subsystem. - -Each button (key) is represented as a sub-node of "adc-keys": - -Required subnode-properties: - - label: Descriptive name of the key. - - linux,code: Keycode to emit. - - press-threshold-microvolt: voltage above or equal to which this key is - considered pressed. - -No two values of press-threshold-microvolt may be the same. -All values of press-threshold-microvolt must be less than -keyup-threshold-microvolt. - -Example: - -#include <dt-bindings/input/input.h> - - adc-keys { - compatible = "adc-keys"; - io-channels = <&lradc 0>; - io-channel-names = "buttons"; - keyup-threshold-microvolt = <2000000>; - - button-up { - label = "Volume Up"; - linux,code = <KEY_VOLUMEUP>; - press-threshold-microvolt = <1500000>; - }; - - button-down { - label = "Volume Down"; - linux,code = <KEY_VOLUMEDOWN>; - press-threshold-microvolt = <1000000>; - }; - - button-enter { - label = "Enter"; - linux,code = <KEY_ENTER>; - press-threshold-microvolt = <500000>; - }; - }; - -+--------------------------------+------------------------+ -| 2.000.000 <= value | no key pressed | -+--------------------------------+------------------------+ -| 1.500.000 <= value < 2.000.000 | KEY_VOLUMEUP pressed | -+--------------------------------+------------------------+ -| 1.000.000 <= value < 1.500.000 | KEY_VOLUMEDOWN pressed | -+--------------------------------+------------------------+ -| 500.000 <= value < 1.000.000 | KEY_ENTER pressed | -+--------------------------------+------------------------+ -| value < 500.000 | no key pressed | -+--------------------------------+------------------------+ diff --git a/Documentation/devicetree/bindings/input/adc-keys.yaml b/Documentation/devicetree/bindings/input/adc-keys.yaml new file mode 100644 index 000000000000..7aa078dead37 --- /dev/null +++ b/Documentation/devicetree/bindings/input/adc-keys.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/adc-keys.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADC attached resistor ladder buttons + +maintainers: + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +allOf: + - $ref: input.yaml# + +properties: + compatible: + const: adc-keys + + io-channels: + maxItems: 1 + + io-channel-names: + const: buttons + + keyup-threshold-microvolt: + description: + Voltage above or equal to which all the keys are considered up. + + poll-interval: true + autorepeat: true + +patternProperties: + '^button-': + type: object + $ref: input.yaml# + additionalProperties: false + description: + Each button (key) is represented as a sub-node. + + properties: + label: true + + linux,code: true + + press-threshold-microvolt: + description: + Voltage above or equal to which this key is considered pressed. No + two values of press-threshold-microvolt may be the same. All values + of press-threshold-microvolt must be less than + keyup-threshold-microvolt. + + required: + - linux,code + - press-threshold-microvolt + +required: + - compatible + - io-channels + - io-channel-names + - keyup-threshold-microvolt + +additionalProperties: false + +examples: + - | + #include <dt-bindings/input/input.h> + // +--------------------------------+------------------------+ + // | 2.000.000 <= value | no key pressed | + // +--------------------------------+------------------------+ + // | 1.500.000 <= value < 2.000.000 | KEY_VOLUMEUP pressed | + // +--------------------------------+------------------------+ + // | 1.000.000 <= value < 1.500.000 | KEY_VOLUMEDOWN pressed | + // +--------------------------------+------------------------+ + // | 500.000 <= value < 1.000.000 | KEY_ENTER pressed | + // +--------------------------------+------------------------+ + // | value < 500.000 | no key pressed | + // +--------------------------------+------------------------+ + + adc-keys { + compatible = "adc-keys"; + io-channels = <&lradc 0>; + io-channel-names = "buttons"; + keyup-threshold-microvolt = <2000000>; + + button-up { + label = "Volume Up"; + linux,code = <KEY_VOLUMEUP>; + press-threshold-microvolt = <1500000>; + }; + + button-down { + label = "Volume Down"; + linux,code = <KEY_VOLUMEDOWN>; + press-threshold-microvolt = <1000000>; + }; + + button-enter { + label = "Enter"; + linux,code = <KEY_ENTER>; + press-threshold-microvolt = <500000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml index 3399fc288afb..9700dc468b25 100644 --- a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml +++ b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml @@ -44,14 +44,13 @@ properties: patternProperties: "^button-[0-9]+$": type: object + $ref: input.yaml# properties: label: $ref: /schemas/types.yaml#/definitions/string description: Descriptive name of the key - linux,code: - $ref: /schemas/types.yaml#/definitions/uint32 - description: Keycode to emit + linux,code: true channel: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml index b4ad829d7383..442f623bb294 100644 --- a/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml +++ b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml @@ -17,6 +17,7 @@ description: | allOf: - $ref: input.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml index a3a1e5a65306..02e605fac408 100644 --- a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml +++ b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml @@ -37,10 +37,6 @@ properties: device is temporarily held in hardware reset prior to initialization if this property is present. - azoteq,rf-filt-enable: - type: boolean - description: Enables the device's internal RF filter. - azoteq,max-counts: $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1, 2, 3] @@ -421,6 +417,7 @@ patternProperties: patternProperties: "^event-(prox|touch)$": type: object + $ref: input.yaml# description: Represents a proximity or touch event reported by the channel. @@ -467,14 +464,9 @@ patternProperties: The IQS7222B does not feature channel-specific timeouts; the time- out specified for any one channel applies to all channels. - linux,code: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - Numeric key or switch code associated with the event. Specify - KEY_RESERVED (0) to opt out of event reporting. + linux,code: true linux,input-type: - $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 5] default: 1 description: @@ -537,9 +529,8 @@ patternProperties: azoteq,bottom-speed: $ref: /schemas/types.yaml#/definitions/uint32 - multipleOf: 4 minimum: 0 - maximum: 1020 + maximum: 255 description: Specifies the speed of movement after which coordinate filtering is linearly reduced. @@ -575,14 +566,13 @@ patternProperties: patternProperties: "^event-(press|tap|(swipe|flick)-(pos|neg))$": type: object + $ref: input.yaml# description: Represents a press or gesture (IQS7222A only) event reported by the slider. properties: - linux,code: - $ref: /schemas/types.yaml#/definitions/uint32 - description: Numeric key code associated with the event. + linux,code: true azoteq,gesture-max-ms: multipleOf: 4 @@ -616,16 +606,15 @@ patternProperties: azoteq,gpio-select: $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 - maxItems: 1 + maxItems: 3 items: minimum: 0 - maximum: 0 + maximum: 2 description: | - Specifies an individual GPIO mapped to a tap, swipe or flick - gesture as follows: + Specifies one or more GPIO mapped to the event as follows: 0: GPIO0 - 1: GPIO3 (reserved) - 2: GPIO4 (reserved) + 1: GPIO3 (IQS7222C only) + 2: GPIO4 (IQS7222C only) Note that although multiple events can be mapped to a single GPIO, they must all be of the same type (proximity, touch or @@ -710,6 +699,14 @@ allOf: multipleOf: 4 maximum: 1020 + patternProperties: + "^event-(press|tap|(swipe|flick)-(pos|neg))$": + properties: + azoteq,gpio-select: + maxItems: 1 + items: + maximum: 0 + else: patternProperties: "^channel-([0-9]|1[0-9])$": @@ -726,8 +723,6 @@ allOf: azoteq,gesture-dist: false - azoteq,gpio-select: false - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml b/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml index 878464f128dc..5139af287d3e 100644 --- a/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml +++ b/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml @@ -57,7 +57,7 @@ examples: #address-cells = <1>; #size-cells = <0>; - mpr121@5a { + touchkey@5a { compatible = "fsl,mpr121-touchkey"; reg = <0x5a>; interrupt-parent = <&gpio1>; @@ -77,7 +77,7 @@ examples: #address-cells = <1>; #size-cells = <0>; - mpr121@5a { + touchkey@5a { compatible = "fsl,mpr121-touchkey"; reg = <0x5a>; poll-interval = <20>; diff --git a/Documentation/devicetree/bindings/input/gpio-keys.yaml b/Documentation/devicetree/bindings/input/gpio-keys.yaml index 7fe1966ea28a..17ac9dff7972 100644 --- a/Documentation/devicetree/bindings/input/gpio-keys.yaml +++ b/Documentation/devicetree/bindings/input/gpio-keys.yaml @@ -15,107 +15,106 @@ properties: - gpio-keys - gpio-keys-polled + autorepeat: true + + label: + description: Name of entire device + + poll-interval: true + patternProperties: - ".*": - if: - type: object - then: - $ref: input.yaml# + "^(button|event|key|switch|(button|event|key|switch)-[a-z0-9-]+|[a-z0-9-]+-(button|event|key|switch))$": + $ref: input.yaml# - properties: - gpios: - maxItems: 1 + properties: + gpios: + maxItems: 1 + + interrupts: + maxItems: 1 - interrupts: - maxItems: 1 + label: + description: Descriptive name of the key. - label: - description: Descriptive name of the key. + linux,code: + description: Key / Axis code to emit. - linux,code: - description: Key / Axis code to emit. - $ref: /schemas/types.yaml#/definitions/uint32 + linux,input-type: + default: 1 # EV_KEY - linux,input-type: - description: - Specify event type this button/key generates. If not specified defaults to - <1> == EV_KEY. - $ref: /schemas/types.yaml#/definitions/uint32 + linux,input-value: + description: | + If linux,input-type is EV_ABS or EV_REL then this + value is sent for events this button generates when pressed. + EV_ABS/EV_REL axis will generate an event with a value of 0 + when all buttons with linux,input-type == type and + linux,code == axis are released. This value is interpreted + as a signed 32 bit value, e.g. to make a button generate a + value of -1 use: - default: 1 + linux,input-value = <0xffffffff>; /* -1 */ - linux,input-value: - description: | - If linux,input-type is EV_ABS or EV_REL then this - value is sent for events this button generates when pressed. - EV_ABS/EV_REL axis will generate an event with a value of 0 - when all buttons with linux,input-type == type and - linux,code == axis are released. This value is interpreted - as a signed 32 bit value, e.g. to make a button generate a - value of -1 use: + $ref: /schemas/types.yaml#/definitions/uint32 - linux,input-value = <0xffffffff>; /* -1 */ + debounce-interval: + description: + Debouncing interval time in milliseconds. If not specified defaults to 5. + $ref: /schemas/types.yaml#/definitions/uint32 - $ref: /schemas/types.yaml#/definitions/uint32 + default: 5 - debounce-interval: - description: - Debouncing interval time in milliseconds. If not specified defaults to 5. - $ref: /schemas/types.yaml#/definitions/uint32 + wakeup-source: + description: Button can wake-up the system. - default: 5 + wakeup-event-action: + description: | + Specifies whether the key should wake the system when asserted, when + deasserted, or both. This property is only valid for keys that wake up the + system (e.g., when the "wakeup-source" property is also provided). - wakeup-source: - description: Button can wake-up the system. + Supported values are defined in linux-event-codes.h: - wakeup-event-action: - description: | - Specifies whether the key should wake the system when asserted, when - deasserted, or both. This property is only valid for keys that wake up the - system (e.g., when the "wakeup-source" property is also provided). + EV_ACT_ANY - both asserted and deasserted + EV_ACT_ASSERTED - asserted + EV_ACT_DEASSERTED - deasserted + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] - Supported values are defined in linux-event-codes.h: + linux,can-disable: + description: + Indicates that button is connected to dedicated (not shared) interrupt + which can be disabled to suppress events from the button. + type: boolean - EV_ACT_ANY - both asserted and deasserted - EV_ACT_ASSERTED - asserted - EV_ACT_DEASSERTED - deasserted - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1, 2] + required: + - linux,code - linux,can-disable: - description: - Indicates that button is connected to dedicated (not shared) interrupt - which can be disabled to suppress events from the button. - type: boolean + anyOf: + - required: + - interrupts + - required: + - interrupts-extended + - required: + - gpios + dependencies: + wakeup-event-action: [ wakeup-source ] + linux,input-value: [ gpios ] + + unevaluatedProperties: false + +allOf: + - $ref: input.yaml# + - if: + properties: + compatible: + const: gpio-keys-polled + then: required: - - linux,code - - anyOf: - - required: - - interrupts - - required: - - gpios - - dependencies: - wakeup-event-action: [ wakeup-source ] - linux,input-value: [ gpios ] - - unevaluatedProperties: false - -if: - properties: - compatible: - const: gpio-keys-polled -then: - properties: - poll-interval: - description: - Poll interval time in milliseconds - $ref: /schemas/types.yaml#/definitions/uint32 - - required: - - poll-interval + - poll-interval + else: + properties: + poll-interval: false additionalProperties: false @@ -127,13 +126,13 @@ examples: compatible = "gpio-keys"; autorepeat; - up { + key-up { label = "GPIO Key UP"; linux,code = <103>; gpios = <&gpio1 0 1>; }; - down { + key-down { label = "GPIO Key DOWN"; linux,code = <108>; interrupts = <1 IRQ_TYPE_EDGE_FALLING>; diff --git a/Documentation/devicetree/bindings/input/input.yaml b/Documentation/devicetree/bindings/input/input.yaml index d41d8743aad4..17512f4347fd 100644 --- a/Documentation/devicetree/bindings/input/input.yaml +++ b/Documentation/devicetree/bindings/input/input.yaml @@ -21,7 +21,26 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32-array items: minimum: 0 - maximum: 0xff + maximum: 0x2ff + + linux,code: + description: + Specifies a single numeric keycode value to be used for reporting + button/switch events. Specify KEY_RESERVED (0) to opt out of event + reporting. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 0x2ff + + linux,input-type: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 1 # EV_KEY + - 2 # EV_REL + - 3 # EV_ABS + - 5 # EV_SW + description: + Specifies whether the event is to be interpreted as a key, relative, + absolute, or switch. poll-interval: description: Poll interval time in milliseconds. @@ -39,4 +58,7 @@ properties: reset automatically. Device with key pressed reset feature can specify this property. +dependencies: + linux,input-type: [ "linux,code" ] + additionalProperties: true diff --git a/Documentation/devicetree/bindings/input/iqs269a.yaml b/Documentation/devicetree/bindings/input/iqs269a.yaml index 9c154e5e1a91..3c430d38594f 100644 --- a/Documentation/devicetree/bindings/input/iqs269a.yaml +++ b/Documentation/devicetree/bindings/input/iqs269a.yaml @@ -370,6 +370,7 @@ patternProperties: patternProperties: "^event-prox(-alt)?$": type: object + $ref: input.yaml# description: Represents a proximity event reported by the channel in response to a decrease in counts. Node names suffixed with '-alt' instead corre- @@ -396,14 +397,13 @@ patternProperties: default: 10 description: Specifies the threshold for the event. - linux,code: - $ref: /schemas/types.yaml#/definitions/uint32 - description: Numeric key or switch code associated with the event. + linux,code: true additionalProperties: false "^event-touch(-alt)?$": type: object + $ref: input.yaml# description: Represents a touch event reported by the channel. properties: @@ -421,14 +421,13 @@ patternProperties: default: 4 description: Specifies the hysteresis for the event. - linux,code: - $ref: /schemas/types.yaml#/definitions/uint32 - description: Numeric key or switch code associated with the event. + linux,code: true additionalProperties: false "^event-deep(-alt)?$": type: object + $ref: input.yaml# description: Represents a deep-touch event reported by the channel. properties: @@ -446,9 +445,7 @@ patternProperties: default: 0 description: Specifies the hysteresis for the event. - linux,code: - $ref: /schemas/types.yaml#/definitions/uint32 - description: Numeric key or switch code associated with the event. + linux,code: true additionalProperties: false @@ -475,7 +472,7 @@ examples: #address-cells = <1>; #size-cells = <0>; - iqs269a@44 { + touch@44 { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/input/iqs626a.yaml b/Documentation/devicetree/bindings/input/iqs626a.yaml index 0cb736c541c9..7a27502095f3 100644 --- a/Documentation/devicetree/bindings/input/iqs626a.yaml +++ b/Documentation/devicetree/bindings/input/iqs626a.yaml @@ -449,6 +449,7 @@ patternProperties: patternProperties: "^event-(prox|touch|deep)(-alt)?$": type: object + $ref: input.yaml# description: Represents a proximity, touch or deep-touch event reported by the channel in response to a decrease in counts. Node names suffixed with @@ -487,21 +488,15 @@ patternProperties: Specifies the hysteresis for the event (touch and deep-touch events only). - linux,code: - $ref: /schemas/types.yaml#/definitions/uint32 - description: Numeric key or switch code associated with the event. + linux,code: true linux,input-type: - $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 5] description: Specifies whether the event is to be interpreted as a key (1) or a switch (5). By default, Hall-channel events are interpreted as switches and all others are interpreted as keys. - dependencies: - linux,input-type: ["linux,code"] - additionalProperties: false dependencies: @@ -511,6 +506,7 @@ patternProperties: "^trackpad-3x[2-3]$": type: object + $ref: input.yaml# description: Represents all channels associated with the trackpad. The channels are collectively active if the trackpad is defined and inactive otherwise. @@ -679,7 +675,6 @@ patternProperties: Specifies the raw count filter strength during low-power mode. linux,keycodes: - $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 6 description: | @@ -751,7 +746,7 @@ examples: #address-cells = <1>; #size-cells = <0>; - iqs626a@44 { + touch@44 { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/input/iqs62x-keys.yaml b/Documentation/devicetree/bindings/input/iqs62x-keys.yaml index 77fe3b545b35..0aa951f0ab92 100644 --- a/Documentation/devicetree/bindings/input/iqs62x-keys.yaml +++ b/Documentation/devicetree/bindings/input/iqs62x-keys.yaml @@ -9,6 +9,9 @@ title: Azoteq IQS620A/621/622/624/625 Keys and Switches maintainers: - Jeff LaBundy <jeff@labundy.com> +allOf: + - $ref: input.yaml# + description: | The Azoteq IQS620A, IQS621, IQS622, IQS624 and IQS625 multi-function sensors feature a variety of self-capacitive, mutual-inductive and Hall-effect sens- @@ -30,7 +33,6 @@ properties: - azoteq,iqs625-keys linux,keycodes: - $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 16 description: | @@ -89,15 +91,14 @@ properties: patternProperties: "^hall-switch-(north|south)$": type: object + $ref: input.yaml# description: Represents north/south-field Hall-effect sensor touch or proximity events. Note that north/south-field orientation is reversed on the IQS620AXzCSR device due to its flip-chip package. properties: - linux,code: - $ref: /schemas/types.yaml#/definitions/uint32 - description: Numeric switch code associated with the event. + linux,code: true azoteq,use-prox: $ref: /schemas/types.yaml#/definitions/flag diff --git a/Documentation/devicetree/bindings/input/max77650-onkey.yaml b/Documentation/devicetree/bindings/input/max77650-onkey.yaml index 3a2ad6ec64db..48edc0c8c1dd 100644 --- a/Documentation/devicetree/bindings/input/max77650-onkey.yaml +++ b/Documentation/devicetree/bindings/input/max77650-onkey.yaml @@ -16,15 +16,15 @@ description: | The onkey controller is represented as a sub-node of the PMIC node on the device tree. +allOf: + - $ref: input.yaml# + properties: compatible: const: maxim,max77650-onkey linux,code: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - The key-code to be reported when the key is pressed. Defaults - to KEY_POWER. + default: 116 # KEY_POWER maxim,onkey-slide: $ref: /schemas/types.yaml#/definitions/flag diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml index d5d6bced3148..96358b12f9b2 100644 --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml @@ -112,7 +112,7 @@ examples: #address-cells = <1>; #size-cells = <0>; - cap1188@28 { + touch@28 { compatible = "microchip,cap1188"; interrupt-parent = <&gpio1>; interrupts = <0 0>; diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml index 2e8da7470513..46bc8c028fe6 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml @@ -85,6 +85,14 @@ properties: minimum: 0 maximum: 80 + report-rate-hz: + description: | + Allows setting the scan rate in Hertz. + M06 supports range from 30 to 140 Hz. + M12 supports range from 1 to 255 Hz. + minimum: 1 + maximum: 255 + touchscreen-size-x: true touchscreen-size-y: true touchscreen-fuzz-x: true diff --git a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml index 9362b1ef9e88..14bebe1ad8f8 100644 --- a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml +++ b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml @@ -33,6 +33,8 @@ patternProperties: "^multi-led@[0-9a-b]$": type: object $ref: leds-class-multicolor.yaml# + unevaluatedProperties: false + description: This node represents one of the RGB LED devices on Turris Omnia. No subnodes need to be added for subchannels since this controller only diff --git a/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml b/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml new file mode 100644 index 000000000000..52252fb6bb32 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-bcm63138.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom's BCM63138 LEDs controller + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +description: | + This LEDs controller was first used on BCM63138 and later reused on BCM4908, + BCM6848, BCM6858, BCM63138, BCM63148, BCM63381 and BCM68360 SoCs. + + It supports up to 32 LEDs that can be connected parallelly or serially. It + also includes limited support for hardware blinking. + + Binding serially connected LEDs isn't documented yet. + +properties: + compatible: + oneOf: + - items: + - enum: + - brcm,bcm4908-leds + - brcm,bcm6848-leds + - brcm,bcm6858-leds + - brcm,bcm63148-leds + - brcm,bcm63381-leds + - brcm,bcm68360-leds + - const: brcm,bcm63138-leds + - const: brcm,bcm63138-leds + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^led@[a-f0-9]+$": + type: object + + $ref: common.yaml# + + properties: + reg: + maxItems: 1 + description: LED pin number + + active-low: + type: boolean + description: Makes LED active low + + required: + - reg + + unevaluatedProperties: false + +required: + - reg + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + + leds@ff800800 { + compatible = "brcm,bcm4908-leds", "brcm,bcm63138-leds"; + reg = <0xff800800 0xdc>; + + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0x0>; + function = LED_FUNCTION_POWER; + color = <LED_COLOR_ID_GREEN>; + default-state = "on"; + }; + + led@3 { + reg = <0x3>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_GREEN>; + active-low; + }; + }; diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml index f41d021ed677..31840e33dcf5 100644 --- a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml +++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Common properties for the multicolor LED class. maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | Bindings for multi color LEDs show how to describe current outputs of @@ -19,22 +19,22 @@ description: | LED class. Common LED nodes and properties are inherited from the common.yaml within this documentation directory. -patternProperties: - "^multi-led(@[0-9a-f])?$": - type: object - description: Represents the LEDs that are to be grouped. - properties: - color: - description: | - For multicolor LED support this property should be defined as either - LED_COLOR_ID_RGB or LED_COLOR_ID_MULTI which can be found in - include/linux/leds/common.h. - enum: [ 8, 9 ] - - $ref: "common.yaml#" - - required: - - color +properties: + $nodename: + pattern: "^multi-led(@[0-9a-f])?$" + + color: + description: | + For multicolor LED support this property should be defined as either + LED_COLOR_ID_RGB or LED_COLOR_ID_MULTI which can be found in + include/linux/leds/common.h. + enum: [ 8, 9 ] + +required: + - color + +allOf: + - $ref: "common.yaml#" additionalProperties: true diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml index d11898567313..63da380748bf 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: LED driver for LP50XX RGB LED from Texas Instruments. maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into @@ -56,6 +56,8 @@ patternProperties: '^multi-led@[0-9a-f]$': type: object $ref: leds-class-multicolor.yaml# + unevaluatedProperties: false + properties: reg: minItems: 1 @@ -65,8 +67,14 @@ patternProperties: for the child node. The LED modules can either be used stand alone or grouped into a module bank. + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + patternProperties: - "(^led-[0-9a-f]$|led)": + "^led@[0-9a-f]+$": type: object $ref: common.yaml# diff --git a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml index fdaf04e03a8d..bd6ec04a8727 100644 --- a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml +++ b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml @@ -19,6 +19,14 @@ properties: multi-led: type: object + $ref: leds-class-multicolor.yaml# + unevaluatedProperties: false + + properties: + max-brightness: + description: + Maximum brightness possible for the LED + $ref: /schemas/types.yaml#/definitions/uint32 patternProperties: "^led-[0-9a-z]+$": @@ -33,6 +41,10 @@ properties: pwm-names: true + active-low: + description: For PWMs where the LED is wired to supply rather than ground. + type: boolean + color: true required: @@ -42,9 +54,6 @@ properties: required: - compatible -allOf: - - $ref: leds-class-multicolor.yaml# - additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml index cd02811583ec..497db289169d 100644 --- a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml @@ -59,6 +59,8 @@ properties: multi-led: type: object $ref: leds-class-multicolor.yaml# + unevaluatedProperties: false + properties: "#address-cells": const: 1 diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml index bd49c201477d..d9a4f4a02d7c 100644 --- a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml +++ b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml @@ -57,6 +57,7 @@ properties: maxItems: 1 interrupts: + minItems: 2 items: - description: low-priority non-secure - description: high-priority non-secure diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index 7a86e7926dd2..191c1ce15009 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -72,14 +72,16 @@ properties: type : Channel type channel : Channel number - This MU support 4 type of unidirectional channels, each type - has 4 channels. A total of 16 channels. Following types are + This MU support 5 type of unidirectional channels, each type + has 4 channels except RST channel which only has 1 channel. + A total of 17 channels. Following types are supported: 0 - TX channel with 32bit transmit register and IRQ transmit acknowledgment support. 1 - RX channel with 32bit receive register and IRQ support 2 - TX doorbell channel. Without own register and no ACK support. 3 - RX doorbell channel. + 4 - RST channel const: 2 clocks: diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 3b5ba7ecc19d..f504652fc0ea 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -15,26 +15,30 @@ maintainers: properties: compatible: - enum: - - qcom,ipq6018-apcs-apps-global - - qcom,ipq8074-apcs-apps-global - - qcom,msm8916-apcs-kpss-global - - qcom,msm8939-apcs-kpss-global - - qcom,msm8953-apcs-kpss-global - - qcom,msm8976-apcs-kpss-global - - qcom,msm8994-apcs-kpss-global - - qcom,msm8996-apcs-hmss-global - - qcom,msm8998-apcs-hmss-global - - qcom,qcm2290-apcs-hmss-global - - qcom,qcs404-apcs-apps-global - - qcom,sc7180-apss-shared - - qcom,sc8180x-apss-shared - - qcom,sdm660-apcs-hmss-global - - qcom,sdm845-apss-shared - - qcom,sm6125-apcs-hmss-global - - qcom,sm6115-apcs-hmss-global - - qcom,sm8150-apss-shared - + oneOf: + - items: + - enum: + - qcom,ipq6018-apcs-apps-global + - qcom,ipq8074-apcs-apps-global + - qcom,msm8976-apcs-kpss-global + - qcom,msm8996-apcs-hmss-global + - qcom,msm8998-apcs-hmss-global + - qcom,qcm2290-apcs-hmss-global + - qcom,sc7180-apss-shared + - qcom,sc8180x-apss-shared + - qcom,sdm660-apcs-hmss-global + - qcom,sdm845-apss-shared + - qcom,sm6125-apcs-hmss-global + - qcom,sm6115-apcs-hmss-global + - qcom,sm8150-apss-shared + - items: + - enum: + - qcom,msm8916-apcs-kpss-global + - qcom,msm8939-apcs-kpss-global + - qcom,msm8953-apcs-kpss-global + - qcom,msm8994-apcs-kpss-global + - qcom,qcs404-apcs-apps-global + - const: syscon reg: maxItems: 1 @@ -121,7 +125,7 @@ examples: #define GCC_APSS_AHB_CLK_SRC 1 #define GCC_GPLL0_AO_OUT_MAIN 123 apcs: mailbox@b011000 { - compatible = "qcom,qcs404-apcs-apps-global"; + compatible = "qcom,qcs404-apcs-apps-global", "syscon"; reg = <0x0b011000 0x1000>; #mbox-cells = <1>; clocks = <&apcs_hfpll>, <&gcc GCC_GPLL0_AO_OUT_MAIN>; diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml index 1994be858940..baca4786ff94 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml @@ -25,6 +25,7 @@ properties: items: - enum: - qcom,sm6350-ipcc + - qcom,sm6375-ipcc - qcom,sm8250-ipcc - qcom,sm8350-ipcc - qcom,sm8450-ipcc diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml index 5a1e8d21f7a0..5e0fe3ebe1d2 100644 --- a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml +++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml @@ -19,7 +19,6 @@ description: | maintainers: - Tim Harvey <tharvey@gateworks.com> - - Robert Jones <rjones@gateworks.com> properties: $nodename: diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt deleted file mode 100644 index eb78e3ae7703..000000000000 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt +++ /dev/null @@ -1,94 +0,0 @@ - Qualcomm SPMI PMICs multi-function device bindings - -The Qualcomm SPMI series presently includes PM8941, PM8841 and PMA8084 -PMICs. These PMICs use a QPNP scheme through SPMI interface. -QPNP is effectively a partitioning scheme for dividing the SPMI extended -register space up into logical pieces, and set of fixed register -locations/definitions within these regions, with some of these regions -specifically used for interrupt handling. - -The QPNP PMICs are used with the Qualcomm Snapdragon series SoCs, and are -interfaced to the chip via the SPMI (System Power Management Interface) bus. -Support for multiple independent functions are implemented by splitting the -16-bit SPMI slave address space into 256 smaller fixed-size regions, 256 bytes -each. A function can consume one or more of these fixed-size register regions. - -Required properties: -- compatible: Should contain one of: - "qcom,pm660", - "qcom,pm660l", - "qcom,pm7325", - "qcom,pm8004", - "qcom,pm8005", - "qcom,pm8019", - "qcom,pm8028", - "qcom,pm8110", - "qcom,pm8150", - "qcom,pm8150b", - "qcom,pm8150c", - "qcom,pm8150l", - "qcom,pm8226", - "qcom,pm8350c", - "qcom,pm8841", - "qcom,pm8901", - "qcom,pm8909", - "qcom,pm8916", - "qcom,pm8941", - "qcom,pm8950", - "qcom,pm8953", - "qcom,pm8994", - "qcom,pm8998", - "qcom,pma8084", - "qcom,pmd9635", - "qcom,pmi8950", - "qcom,pmi8962", - "qcom,pmi8994", - "qcom,pmi8998", - "qcom,pmk8002", - "qcom,pmk8350", - "qcom,pmr735a", - "qcom,smb2351", - or generalized "qcom,spmi-pmic". -- reg: Specifies the SPMI USID slave address for this device. - For more information see: - Documentation/devicetree/bindings/spmi/spmi.yaml - -Required properties for peripheral child nodes: -- compatible: Should contain "qcom,xxx", where "xxx" is a peripheral name. - -Optional properties for peripheral child nodes: -- interrupts: Interrupts are specified as a 4-tuple. For more information - see: - Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml -- interrupt-names: Corresponding interrupt name to the interrupts property - -Each child node of SPMI slave id represents a function of the PMIC. In the -example below the rtc device node represents a peripheral of pm8941 -SID = 0. The regulator device node represents a peripheral of pm8941 SID = 1. - -Example: - - spmi { - compatible = "qcom,spmi-pmic-arb"; - - pm8941@0 { - compatible = "qcom,pm8941", "qcom,spmi-pmic"; - reg = <0x0 SPMI_USID>; - - rtc { - compatible = "qcom,rtc"; - interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>; - interrupt-names = "alarm"; - }; - }; - - pm8941@1 { - compatible = "qcom,pm8941", "qcom,spmi-pmic"; - reg = <0x1 SPMI_USID>; - - regulator { - compatible = "qcom,regulator"; - regulator-name = "8941_boost"; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml new file mode 100644 index 000000000000..65cbc6dee545 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml @@ -0,0 +1,190 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SPMI PMICs multi-function device + +description: | + Some Qualcomm PMICs used with the Snapdragon series SoCs are interfaced + to the chip via the SPMI (System Power Management Interface) bus. + Support for multiple independent functions are implemented by splitting the + 16-bit SPMI peripheral address space into 256 smaller fixed-size regions, 256 bytes + each. A function can consume one or more of these fixed-size register regions. + + The Qualcomm SPMI series includes the PM8941, PM8841, PMA8084, PM8998 and other + PMICs. These PMICs use a "QPNP" scheme through SPMI interface. + QPNP is effectively a partitioning scheme for dividing the SPMI extended + register space up into logical pieces, and set of fixed register + locations/definitions within these regions, with some of these regions + specifically used for interrupt handling. + +maintainers: + - Stephen Boyd <sboyd@kernel.org> + +properties: + $nodename: + oneOf: + - pattern: '^pmic@.*$' + - pattern: '^pm(a|s)?[0-9]*@.*$' + deprecated: true + + compatible: + items: + - enum: + - qcom,pm660 + - qcom,pm660l + - qcom,pm6150 + - qcom,pm6150l + - qcom,pm6350 + - qcom,pm7325 + - qcom,pm8004 + - qcom,pm8005 + - qcom,pm8009 + - qcom,pm8019 + - qcom,pm8110 + - qcom,pm8150 + - qcom,pm8150b + - qcom,pm8150l + - qcom,pm8226 + - qcom,pm8350 + - qcom,pm8350b + - qcom,pm8350c + - qcom,pm8841 + - qcom,pm8909 + - qcom,pm8916 + - qcom,pm8941 + - qcom,pm8950 + - qcom,pm8994 + - qcom,pm8998 + - qcom,pma8084 + - qcom,pmd9635 + - qcom,pmi8950 + - qcom,pmi8962 + - qcom,pmi8994 + - qcom,pmi8998 + - qcom,pmk8350 + - qcom,pmm8155au + - qcom,pmr735a + - qcom,pmr735b + - qcom,pms405 + - qcom,pmx55 + - qcom,pmx65 + - qcom,smb2351 + - const: qcom,spmi-pmic + + reg: + minItems: 1 + maxItems: 2 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + labibb: + type: object + $ref: /schemas/regulator/qcom-labibb-regulator.yaml# + + regulators: + type: object + $ref: /schemas/regulator/regulator.yaml# + +patternProperties: + "^adc@[0-9a-f]+$": + type: object + $ref: /schemas/iio/adc/qcom,spmi-vadc.yaml# + + "^adc-tm@[0-9a-f]+$": + type: object + $ref: /schemas/thermal/qcom-spmi-adc-tm5.yaml# + + "^audio-codec@[0-9a-f]+$": + type: object + additionalProperties: true # FIXME qcom,pm8916-wcd-analog-codec binding not converted yet + + "extcon@[0-9a-f]+$": + type: object + $ref: /schemas/extcon/qcom,pm8941-misc.yaml# + + "gpio(s)?@[0-9a-f]+$": + type: object + $ref: /schemas/pinctrl/qcom,pmic-gpio.yaml# + + "pon@[0-9a-f]+$": + type: object + $ref: /schemas/power/reset/qcom,pon.yaml# + + "pwm@[0-9a-f]+$": + type: object + $ref: /schemas/leds/leds-qcom-lpg.yaml# + + "^rtc@[0-9a-f]+$": + type: object + $ref: /schemas/rtc/qcom-pm8xxx-rtc.yaml# + + "^temp-alarm@[0-9a-f]+$": + type: object + $ref: /schemas/thermal/qcom,spmi-temp-alarm.yaml# + + "^vibrator@[0-9a-f]+$": + type: object + additionalProperties: true # FIXME qcom,pm8916-vib binding not converted yet + + "^mpps@[0-9a-f]+$": + type: object + $ref: /schemas/pinctrl/qcom,pmic-mpp.yaml# + + "(.*)?(wled|leds)@[0-9a-f]+$": + type: object + $ref: /schemas/leds/backlight/qcom-wled.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/spmi/spmi.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + spmi@c440000 { + compatible = "qcom,spmi-pmic-arb"; + reg = <0x0c440000 0x1100>, + <0x0c600000 0x2000000>, + <0x0e600000 0x100000>, + <0x0e700000 0xa0000>, + <0x0c40a000 0x26000>; + reg-names = "core", "chnls", "obsrvr", "intr", "cnfg"; + interrupt-names = "periph_irq"; + interrupts = <GIC_SPI 481 IRQ_TYPE_LEVEL_HIGH>; + qcom,ee = <0>; + qcom,channel = <0>; + #address-cells = <2>; + #size-cells = <0>; + interrupt-controller; + #interrupt-cells = <4>; + + pmi8998_lsid0: pmic@2 { + compatible = "qcom,pmi8998", "qcom,spmi-pmic"; + reg = <0x2 SPMI_USID>; + #address-cells = <1>; + #size-cells = <0>; + + pmi8998_gpio: gpios@c000 { + compatible = "qcom,pmi8998-gpio", "qcom,spmi-gpio"; + reg = <0xc000>; + gpio-controller; + gpio-ranges = <&pmi8998_gpio 0 0 14>; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml index b00578ae1dea..fc0e81c2066c 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml @@ -137,6 +137,8 @@ properties: max-frequency: true + operating-points-v2: true + patternProperties: '^opp-table(-[a-z0-9]+)?$': if: diff --git a/Documentation/devicetree/bindings/net/ti,dp83822.yaml b/Documentation/devicetree/bindings/net/ti,dp83822.yaml index 75e8712e903a..f2489a9c852f 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83822.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml @@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: TI DP83822 ethernet PHY maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The DP83822 is a low-power, single-port, 10/100 Mbps Ethernet PHY. It diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml index 76ff08a477ba..b8c0e4b5b494 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml @@ -11,7 +11,7 @@ allOf: - $ref: "ethernet-controller.yaml#" maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The DP83867 device is a robust, low power, fully featured Physical Layer diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml index 1b780dce61ab..b04ff0014a59 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml @@ -11,7 +11,7 @@ allOf: - $ref: "ethernet-phy.yaml#" maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The DP83869HM device is a robust, fully-featured Gigabit (PHY) transceiver diff --git a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml index 76c8acd981b3..66d0ec763f0b 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml @@ -50,6 +50,16 @@ patternProperties: property to uniquely identify the OPP nodes exists. Devices like power domains must have another (implementation dependent) property. + Entries for multiple clocks shall be provided in the same field, as + array of frequencies. The OPP binding doesn't provide any provisions + to relate the values to their clocks or the order in which the clocks + need to be configured and that is left for the implementation + specific binding. + minItems: 1 + maxItems: 16 + items: + maxItems: 1 + opp-microvolt: description: | Voltage for the OPP diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml index 30f7b596d609..59663e897dae 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml @@ -98,6 +98,8 @@ examples: capacity-dmips-mhz = <1024>; clocks = <&kryocc 0>; operating-points-v2 = <&cluster0_opp>; + power-domains = <&cpr>; + power-domain-names = "cpr"; #cooling-cells = <2>; next-level-cache = <&L2_0>; L2_0: l2-cache { @@ -115,6 +117,8 @@ examples: capacity-dmips-mhz = <1024>; clocks = <&kryocc 0>; operating-points-v2 = <&cluster0_opp>; + power-domains = <&cpr>; + power-domain-names = "cpr"; #cooling-cells = <2>; next-level-cache = <&L2_0>; }; @@ -128,6 +132,8 @@ examples: capacity-dmips-mhz = <1024>; clocks = <&kryocc 1>; operating-points-v2 = <&cluster1_opp>; + power-domains = <&cpr>; + power-domain-names = "cpr"; #cooling-cells = <2>; next-level-cache = <&L2_1>; L2_1: l2-cache { @@ -145,6 +151,8 @@ examples: capacity-dmips-mhz = <1024>; clocks = <&kryocc 1>; operating-points-v2 = <&cluster1_opp>; + power-domains = <&cpr>; + power-domain-names = "cpr"; #cooling-cells = <2>; next-level-cache = <&L2_1>; }; @@ -182,18 +190,21 @@ examples: opp-microvolt = <905000 905000 1140000>; opp-supported-hw = <0x7>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp1>; }; opp-1401600000 { opp-hz = /bits/ 64 <1401600000>; opp-microvolt = <1140000 905000 1140000>; opp-supported-hw = <0x5>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp2>; }; opp-1593600000 { opp-hz = /bits/ 64 <1593600000>; opp-microvolt = <1140000 905000 1140000>; opp-supported-hw = <0x1>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp3>; }; }; @@ -207,24 +218,28 @@ examples: opp-microvolt = <905000 905000 1140000>; opp-supported-hw = <0x7>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp1>; }; opp-1804800000 { opp-hz = /bits/ 64 <1804800000>; opp-microvolt = <1140000 905000 1140000>; opp-supported-hw = <0x6>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp4>; }; opp-1900800000 { opp-hz = /bits/ 64 <1900800000>; opp-microvolt = <1140000 905000 1140000>; opp-supported-hw = <0x4>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp5>; }; opp-2150400000 { opp-hz = /bits/ 64 <2150400000>; opp-microvolt = <1140000 905000 1140000>; opp-supported-hw = <0x1>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp6>; }; }; diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml index 0681b9a3965f..d19d65c870aa 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml @@ -46,6 +46,7 @@ properties: - allwinner,sun8i-v3s-pinctrl - allwinner,sun9i-a80-pinctrl - allwinner,sun9i-a80-r-pinctrl + - allwinner,sun20i-d1-pinctrl - allwinner,sun50i-a64-pinctrl - allwinner,sun50i-a64-r-pinctrl - allwinner,sun50i-a100-pinctrl @@ -80,9 +81,6 @@ properties: - const: hosc - const: losc - resets: - maxItems: 1 - gpio-controller: true interrupt-controller: true gpio-line-names: true @@ -185,6 +183,18 @@ allOf: properties: compatible: enum: + - allwinner,sun20i-d1-pinctrl + + then: + properties: + interrupts: + minItems: 6 + maxItems: 6 + + - if: + properties: + compatible: + enum: - allwinner,sun9i-a80-pinctrl then: diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml index 47a56b83a610..7a11beb8f222 100644 --- a/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml @@ -152,7 +152,7 @@ examples: pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uid>, <&pinmux_uid>; - uid { + button-uid { label = "UID"; linux,code = <102>; gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml index 8a2bb8608291..1eeb885ce0c6 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml @@ -28,6 +28,8 @@ properties: gpio-ranges: maxItems: 1 + gpio-line-names: true + reg: description: | Physical address base for gpio base registers. There are 8 different GPIO @@ -105,31 +107,8 @@ patternProperties: drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] - mediatek,drive-strength-adv: - description: | - Describe the specific driving setup property. - For I2C pins, the existing generic driving setup can only support - 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they - can support 0.125/0.25/0.5/1mA adjustment. If we enable specific - driving setup, the existing generic setup will be disabled. - The specific driving setup is controlled by E1E0EN. - When E1=0/E0=0, the strength is 0.125mA. - When E1=0/E0=1, the strength is 0.25mA. - When E1=1/E0=0, the strength is 0.5mA. - When E1=1/E0=1, the strength is 1mA. - EN is used to enable or disable the specific driving setup. - Valid arguments are described as below: - 0: (E1, E0, EN) = (0, 0, 0) - 1: (E1, E0, EN) = (0, 0, 1) - 2: (E1, E0, EN) = (0, 1, 0) - 3: (E1, E0, EN) = (0, 1, 1) - 4: (E1, E0, EN) = (1, 0, 0) - 5: (E1, E0, EN) = (1, 0, 1) - 6: (E1, E0, EN) = (1, 1, 0) - 7: (E1, E0, EN) = (1, 1, 1) - So the valid arguments are from 0 to 7. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1, 2, 3, 4, 5, 6, 7] + drive-strength-microamp: + enum: [125, 250, 500, 1000] bias-pull-down: oneOf: @@ -291,7 +270,7 @@ examples: pinmux = <PINMUX_GPIO127__FUNC_SCL0>, <PINMUX_GPIO128__FUNC_SDA0>; bias-pull-up = <MTK_PULL_SET_RSEL_001>; - mediatek,drive-strength-adv = <7>; + drive-strength-microamp = <1000>; }; }; }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml index c90a132fbc79..e0e943e5b874 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml @@ -80,46 +80,30 @@ patternProperties: dt-bindings/pinctrl/mt65xx.h. It can only support 2/4/6/8/10/12/14/16mA in mt8192. enum: [2, 4, 6, 8, 10, 12, 14, 16] - mediatek,drive-strength-adv: - description: | - Describe the specific driving setup property. - For I2C pins, the existing generic driving setup can only support - 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they - can support 0.125/0.25/0.5/1mA adjustment. If we enable specific - driving setup, the existing generic setup will be disabled. - The specific driving setup is controlled by E1E0EN. - When E1=0/E0=0, the strength is 0.125mA. - When E1=0/E0=1, the strength is 0.25mA. - When E1=1/E0=0, the strength is 0.5mA. - When E1=1/E0=1, the strength is 1mA. - EN is used to enable or disable the specific driving setup. - Valid arguments are described as below: - 0: (E1, E0, EN) = (0, 0, 0) - 1: (E1, E0, EN) = (0, 0, 1) - 2: (E1, E0, EN) = (0, 1, 0) - 3: (E1, E0, EN) = (0, 1, 1) - 4: (E1, E0, EN) = (1, 0, 0) - 5: (E1, E0, EN) = (1, 0, 1) - 6: (E1, E0, EN) = (1, 1, 0) - 7: (E1, E0, EN) = (1, 1, 1) - So the valid arguments are from 0 to 7. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1, 2, 3, 4, 5, 6, 7] - - mediatek,pull-up-adv: - description: | - Pull up settings for 2 pull resistors, R0 and R1. User can - configure those special pins. Valid arguments are described as below: - 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. - 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. - 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. - 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1, 2, 3] - - bias-pull-down: true - - bias-pull-up: true + drive-strength-microamp: + enum: [125, 250, 500, 1000] + + bias-pull-down: + oneOf: + - type: boolean + description: normal pull down. + - enum: [100, 101, 102, 103] + description: PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0_ + defines in dt-bindings/pinctrl/mt65xx.h. + - enum: [200, 201, 202, 203] + description: RSEL pull down type. See MTK_PULL_SET_RSEL_ + defines in dt-bindings/pinctrl/mt65xx.h. + + bias-pull-up: + oneOf: + - type: boolean + description: normal pull up. + - enum: [100, 101, 102, 103] + description: PUPD/R1/R0 pull up type. See MTK_PUPD_SET_R1R0_ + defines in dt-bindings/pinctrl/mt65xx.h. + - enum: [200, 201, 202, 203] + description: RSEL pull up type. See MTK_PULL_SET_RSEL_ + defines in dt-bindings/pinctrl/mt65xx.h. bias-disable: true diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml index c5b755514c46..66fe17e9e4d3 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml @@ -29,6 +29,8 @@ properties: description: gpio valid number range. maxItems: 1 + gpio-line-names: true + reg: description: | Physical address base for gpio base registers. There are 8 GPIO @@ -49,7 +51,7 @@ properties: description: The interrupt outputs to sysirq. maxItems: 1 - mediatek,rsel_resistance_in_si_unit: + mediatek,rsel-resistance-in-si-unit: type: boolean description: | Identifying i2c pins pull up/down type which is RSEL. It can support @@ -98,31 +100,8 @@ patternProperties: drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] - mediatek,drive-strength-adv: - description: | - Describe the specific driving setup property. - For I2C pins, the existing generic driving setup can only support - 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they - can support 0.125/0.25/0.5/1mA adjustment. If we enable specific - driving setup, the existing generic setup will be disabled. - The specific driving setup is controlled by E1E0EN. - When E1=0/E0=0, the strength is 0.125mA. - When E1=0/E0=1, the strength is 0.25mA. - When E1=1/E0=0, the strength is 0.5mA. - When E1=1/E0=1, the strength is 1mA. - EN is used to enable or disable the specific driving setup. - Valid arguments are described as below: - 0: (E1, E0, EN) = (0, 0, 0) - 1: (E1, E0, EN) = (0, 0, 1) - 2: (E1, E0, EN) = (0, 1, 0) - 3: (E1, E0, EN) = (0, 1, 1) - 4: (E1, E0, EN) = (1, 0, 0) - 5: (E1, E0, EN) = (1, 0, 1) - 6: (E1, E0, EN) = (1, 1, 0) - 7: (E1, E0, EN) = (1, 1, 1) - So the valid arguments are from 0 to 7. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1, 2, 3, 4, 5, 6, 7] + drive-strength-microamp: + enum: [125, 250, 500, 1000] bias-pull-down: oneOf: @@ -142,7 +121,7 @@ patternProperties: "MTK_PUPD_SET_R1R0_11" define in mt8195. For pull down type is RSEL, it can add RSEL define & resistance value(ohm) to set different resistance by identifying property - "mediatek,rsel_resistance_in_si_unit". + "mediatek,rsel-resistance-in-si-unit". It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101" @@ -161,7 +140,7 @@ patternProperties: }; An example of using si unit resistance value(ohm): &pio { - mediatek,rsel_resistance_in_si_unit; + mediatek,rsel-resistance-in-si-unit; } pincontroller { i2c0_pin { @@ -190,7 +169,7 @@ patternProperties: "MTK_PUPD_SET_R1R0_11" define in mt8195. For pull up type is RSEL, it can add RSEL define & resistance value(ohm) to set different resistance by identifying property - "mediatek,rsel_resistance_in_si_unit". + "mediatek,rsel-resistance-in-si-unit". It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101" @@ -209,7 +188,7 @@ patternProperties: }; An example of using si unit resistance value(ohm): &pio { - mediatek,rsel_resistance_in_si_unit; + mediatek,rsel-resistance-in-si-unit; } pincontroller { i2c0-pins { @@ -302,7 +281,7 @@ examples: pinmux = <PINMUX_GPIO8__FUNC_SDA0>, <PINMUX_GPIO9__FUNC_SCL0>; bias-disable; - mediatek,drive-strength-adv = <7>; + drive-strength-microamp = <1000>; }; }; }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml index b83c7f476e19..931e5c190ead 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml @@ -144,7 +144,7 @@ examples: #interrupt-cells = <2>; gpio-controller; #gpio-cells = <2>; - gpio-ranges = <&tlmm 0 80>; + gpio-ranges = <&tlmm 0 0 80>; serial3-pinmux { pins = "gpio44", "gpio45"; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml new file mode 100644 index 000000000000..e03530091478 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml @@ -0,0 +1,152 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,msm8909-tlmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. MSM8909 TLMM block + +maintainers: + - Stephan Gerhold <stephan@gerhold.net> + +description: | + This binding describes the Top Level Mode Multiplexer (TLMM) block found + in the MSM8909 platform. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,msm8909-tlmm + + reg: + maxItems: 1 + + 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 + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-msm8909-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-msm8909-tlmm-state" + +$defs: + qcom-msm8909-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]|10[0-9]|11[0-7])$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, + sdc2_data, qdsd_clk, qdsd_cmd, qdsd_data0, qdsd_data1, + qdsd_data2, qdsd_data3 ] + minItems: 1 + maxItems: 16 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + enum: [ adsp_ext, atest_bbrx0, atest_bbrx1, atest_char, atest_char0, + atest_char1, atest_char2, atest_char3, atest_combodac, + atest_gpsadc0, atest_gpsadc1, atest_wlan0, atest_wlan1, + bimc_dte0, bimc_dte1, blsp_i2c1, blsp_i2c2, blsp_i2c3, + blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_spi1, blsp_spi1_cs1, + blsp_spi1_cs2, blsp_spi1_cs3, blsp_spi2, blsp_spi2_cs1, + blsp_spi2_cs2, blsp_spi2_cs3, blsp_spi3, blsp_spi3_cs1, + blsp_spi3_cs2, blsp_spi3_cs3, blsp_spi4, blsp_spi5, blsp_spi6, + blsp_uart1, blsp_uart2, blsp_uim1, blsp_uim2, cam_mclk, + cci_async, cci_timer0, cci_timer1, cci_timer2, cdc_pdm0, + dbg_out, dmic0_clk, dmic0_data, ebi0_wrcdc, ebi2_a, ebi2_lcd, + ext_lpass, gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a, + gcc_gp2_clk_b, gcc_gp3_clk_a, gcc_gp3_clk_b, gcc_plltest, gpio, + gsm0_tx, ldo_en, ldo_update, m_voc, mdp_vsync, modem_tsync, + nav_pps, nav_tsync, pa_indicator, pbs0, pbs1, pbs2, + pri_mi2s_data0_a, pri_mi2s_data0_b, pri_mi2s_data1_a, + pri_mi2s_data1_b, pri_mi2s_mclk_a, pri_mi2s_mclk_b, + pri_mi2s_sck_a, pri_mi2s_sck_b, pri_mi2s_ws_a, pri_mi2s_ws_b, + prng_rosc, pwr_crypto_enabled_a, pwr_crypto_enabled_b, + pwr_modem_enabled_a, pwr_modem_enabled_b, pwr_nav_enabled_a, + pwr_nav_enabled_b, qdss_cti_trig_in_a0, qdss_cti_trig_in_a1, + qdss_cti_trig_in_b0, qdss_cti_trig_in_b1, qdss_cti_trig_out_a0, + qdss_cti_trig_out_a1, qdss_cti_trig_out_b0, + qdss_cti_trig_out_b1, qdss_traceclk_a, qdss_tracectl_a, + qdss_tracedata_a, qdss_tracedata_b, sd_write, sec_mi2s, + smb_int, ssbi0, ssbi1, uim1_clk, uim1_data, uim1_present, + uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset, + uim3_clk, uim3_data, uim3_present, uim3_reset, uim_batt, + wcss_bt, wcss_fm, wcss_wlan ] + + 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@1000000 { + compatible = "qcom,msm8909-tlmm"; + reg = <0x1000000 0x300000>; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&tlmm 0 0 117>; + interrupt-controller; + #interrupt-cells = <2>; + + gpio-wo-subnode-state { + pins = "gpio1"; + function = "gpio"; + }; + + uart-w-subnodes-state { + rx { + pins = "gpio4"; + function = "blsp_uart1"; + bias-pull-up; + }; + + tx { + pins = "gpio5"; + function = "blsp_uart1"; + bias-disable; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index 6f2efc3772cb..694898f382be 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -52,6 +52,7 @@ properties: - qcom,pmi8998-gpio - qcom,pmk8350-gpio - qcom,pmm8155au-gpio + - qcom,pmp8074-gpio - qcom,pmr735a-gpio - qcom,pmr735b-gpio - qcom,pms405-gpio @@ -158,6 +159,7 @@ allOf: compatible: contains: enum: + - qcom,pm8226-gpio - qcom,pm8350b-gpio - qcom,pm8950-gpio then: @@ -233,6 +235,7 @@ allOf: - qcom,pm8150b-gpio - qcom,pm8150l-gpio - qcom,pmc8180c-gpio + - qcom,pmp8074-gpio - qcom,pms405-gpio then: properties: @@ -415,6 +418,7 @@ $defs: - gpio1-gpio10 for pmi8994 - gpio1-gpio4 for pmk8350 - gpio1-gpio10 for pmm8155au + - gpio1-gpio12 for pmp8074 (holes on gpio1 and gpio12) - gpio1-gpio4 for pmr735a - gpio1-gpio4 for pmr735b - gpio1-gpio12 for pms405 (holes on gpio1, gpio9 diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml index d32ee32776e8..33d1d37fdf6d 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml @@ -19,6 +19,11 @@ properties: compatible: const: qcom,sc7280-lpass-lpi-pinctrl + qcom,adsp-bypass-mode: + description: + Tells ADSP is in bypass mode. + type: boolean + reg: minItems: 2 maxItems: 2 diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml new file mode 100644 index 000000000000..3908807a8339 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm6375-tlmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SM6375 TLMM block + +maintainers: + - Konrad Dybcio <konrad.dybcio@somainline.org> + +description: | + This binding describes the Top Level Mode Multiplexer (TLMM) block found + in the SM6375 platform. + +allOf: + - $ref: "pinctrl.yaml#" + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,sm6375-tlmm + + reg: + maxItems: 1 + + 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 + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sm6375-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sm6375-tlmm-state" + +$defs: + qcom-sm6375-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-4][0-9]|15[0-6])$" + - enum: [ ufs_reset, 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, audio_ref, btfm_slimbus, cam_mclk, + cci_async, cci_i2c, cci_timer0, cci_timer1, cci_timer2, + cci_timer3, cci_timer4, cri_trng, dbg_out, ddr_bist, + ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, dp_hot, edp_lcd, + gcc_gp1, gcc_gp2, gcc_gp3, gp_pdm0, gp_pdm1, gp_pdm2, gpio, + gps_tx, ibi_i3c, jitter_bist, ldo_en, ldo_update, lpass_ext, + m_voc, mclk, mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2, + mdp_vsync3, mi2s_0, mi2s_1, mi2s_2, mss_lte, nav_gpio, + nav_pps, pa_indicator, phase_flag0, phase_flag1, phase_flag10, + phase_flag11, phase_flag12, phase_flag13, phase_flag14, + phase_flag15, phase_flag16, phase_flag17, phase_flag18, + phase_flag19, phase_flag2, phase_flag20, phase_flag21, + phase_flag22, phase_flag23, phase_flag24, phase_flag25, + phase_flag26, phase_flag27, phase_flag28, phase_flag29, + phase_flag3, phase_flag30, phase_flag31, phase_flag4, + phase_flag5, phase_flag6, phase_flag7, phase_flag8, + phase_flag9, pll_bist, pll_bypassnl, pll_clk, pll_reset, + prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, qdss_cti, + qdss_gpio, qdss_gpio0, qdss_gpio1, qdss_gpio10, qdss_gpio11, + qdss_gpio12, qdss_gpio13, qdss_gpio14, qdss_gpio15, + qdss_gpio2, qdss_gpio3, qdss_gpio4, qdss_gpio5, qdss_gpio6, + qdss_gpio7, qdss_gpio8, qdss_gpio9, qlink0_enable, + qlink0_request, qlink0_wmss, qlink1_enable, qlink1_request, + qlink1_wmss, qup00, qup01, qup02, qup10, qup11_f1, qup11_f2, + qup12, qup13_f1, qup13_f2, qup14, sd_write, sdc1_tb, sdc2_tb, + sp_cmu, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm1, + tsense_pwm2, uim1_clk, uim1_data, uim1_present, uim1_reset, + uim2_clk, uim2_data, uim2_present, uim2_reset, usb2phy_ac, + usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1, + wlan2_adc0, wlan2_adc1 ] + + + 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,sm6375-tlmm"; + reg = <0x00500000 0x800000>; + interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-ranges = <&tlmm 0 0 157>; + + gpio-wo-subnode-state { + pins = "gpio1"; + function = "gpio"; + }; + + uart-w-subnodes-state { + rx { + pins = "gpio18"; + function = "qup13_f2"; + bias-pull-up; + }; + + tx { + pins = "gpio19"; + function = "qup13_f2"; + bias-disable; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml index 2a57df75d832..4fc758fea7e6 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml @@ -45,6 +45,7 @@ properties: - renesas,pfc-r8a77995 # R-Car D3 - renesas,pfc-r8a779a0 # R-Car V3U - renesas,pfc-r8a779f0 # R-Car S4-8 + - renesas,pfc-r8a779g0 # R-Car V4H - renesas,pfc-sh73a0 # SH-Mobile AG5 reg: diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml new file mode 100644 index 000000000000..eac6245db7dc --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml @@ -0,0 +1,170 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/renesas,rzv2m-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/V2M combined Pin and GPIO controller + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + - Phil Edworthy <phil.edworthy@renesas.com> + +description: + The Renesas RZ/V2M SoC features a combined Pin and GPIO controller. + Pin multiplexing and GPIO configuration is performed on a per-pin basis. + Each port features up to 16 pins, each of them configurable for GPIO function + (port mode) or in alternate function mode. + Up to 8 different alternate function modes exist for each single pin. + +properties: + compatible: + const: renesas,r9a09g011-pinctrl # RZ/V2M + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + description: + The first cell contains the global GPIO port index, constructed using the + RZV2M_GPIO() helper macro in <dt-bindings/pinctrl/rzv2m-pinctrl.h> and the + second cell represents consumer flag as mentioned in ../gpio/gpio.txt + E.g. "RZV2M_GPIO(8, 1)" for P8_1. + + gpio-ranges: + maxItems: 1 + + interrupts: + description: INEXINT[0..38] corresponding to individual pin inputs. + maxItems: 39 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +additionalProperties: + anyOf: + - type: object + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + description: + Pin controller client devices use pin configuration subnodes (children + and grandchildren) for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + phandle: true + pinmux: + description: + Values are constructed from GPIO port number, pin number, and + alternate function configuration number using the RZV2M_PORT_PINMUX() + helper macro in <dt-bindings/pinctrl/rzv2m-pinctrl.h>. + pins: true + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength-microamp: + # Superset of supported values + enum: [ 1600, 1800, 2000, 3200, 3800, 4000, 6400, 7800, 8000, + 9000, 9600, 11000, 12000, 13000, 18000 ] + slew-rate: + description: 0 is slow slew rate, 1 is fast slew rate + enum: [ 0, 1 ] + gpio-hog: true + gpios: true + output-high: true + output-low: true + line-name: true + + - type: object + properties: + phandle: true + + additionalProperties: + $ref: "#/additionalProperties/anyOf/0" + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + - interrupts + - clocks + - power-domains + - resets + +examples: + - | + #include <dt-bindings/pinctrl/rzv2m-pinctrl.h> + #include <dt-bindings/clock/r9a09g011-cpg.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + pinctrl: pinctrl@b6250000 { + compatible = "renesas,r9a09g011-pinctrl"; + reg = <0xb6250000 0x800>; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl 0 0 352>; + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD R9A09G011_PFC_PCLK>; + resets = <&cpg R9A09G011_PFC_PRESETN>; + power-domains = <&cpg>; + + i2c2_pins: i2c2 { + pinmux = <RZV2M_PORT_PINMUX(3, 8, 2)>, /* SDA */ + <RZV2M_PORT_PINMUX(3, 9, 2)>; /* SCL */ + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index 335ffc1353b5..d35dcc4f0242 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -59,6 +59,7 @@ properties: patternProperties: '^gpio@[0-9a-f]*$': type: object + additionalProperties: false properties: gpio-controller: true '#gpio-cells': @@ -68,8 +69,7 @@ patternProperties: maxItems: 1 clocks: maxItems: 1 - reset: - minItems: 1 + resets: maxItems: 1 gpio-ranges: minItems: 1 diff --git a/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml index d8e75b3e64f1..15092fdd4b5b 100644 --- a/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml @@ -288,11 +288,14 @@ required: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + examples: - | #include <dt-bindings/pinctrl/sppctl-sp7021.h> - pinctl@9c000100 { + pinctrl@9c000100 { compatible = "sunplus,sp7021-pctl"; reg = <0x9c000100 0x100>, <0x9c000300 0x100>, <0x9c0032e4 0x1c>, <0x9c000080 0x20>; diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml index 2722dc7bb03d..1e2b9b627b12 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml @@ -274,6 +274,10 @@ patternProperties: slew-rate: enum: [0, 1] + output-enable: + description: + This will internally disable the tri-state for MIO pins. + drive-strength: description: Selects the drive strength for MIO pins, in mA. diff --git a/Documentation/devicetree/bindings/power/reset/msm-poweroff.txt b/Documentation/devicetree/bindings/power/reset/msm-poweroff.txt deleted file mode 100644 index ce44ad357565..000000000000 --- a/Documentation/devicetree/bindings/power/reset/msm-poweroff.txt +++ /dev/null @@ -1,17 +0,0 @@ -MSM Restart Driver - -A power supply hold (ps-hold) bit is set to power the msm chipsets. -Clearing that bit allows us to restart/poweroff. The difference -between poweroff and restart is determined by unique power manager IC -settings. - -Required Properties: --compatible: "qcom,pshold" --reg: Specifies the physical address of the ps-hold register - -Example: - - restart@fc4ab000 { - compatible = "qcom,pshold"; - reg = <0xfc4ab000 0x4>; - }; diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pshold.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pshold.yaml new file mode 100644 index 000000000000..527962d54a8f --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/qcom,pshold.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/qcom,pshold.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SoC restart and power off + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + A power supply hold (ps-hold) bit is set to power the Qualcomm chipsets. + Clearing that bit allows us to restart/power off. The difference between + power off and restart is determined by unique power manager IC settings. + +properties: + compatible: + const: qcom,pshold + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + reset-controller@fc4ab000 { + compatible = "qcom,pshold"; + reg = <0xfc4ab000 0x4>; + }; diff --git a/Documentation/devicetree/bindings/power/supply/bq24190.yaml b/Documentation/devicetree/bindings/power/supply/bq24190.yaml index 21a9dadc1c6a..4884ec90e2b8 100644 --- a/Documentation/devicetree/bindings/power/supply/bq24190.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq24190.yaml @@ -28,7 +28,7 @@ properties: maxItems: 1 usb-otg-vbus: - type: object + $ref: /schemas/regulator/regulator.yaml# description: | Regulator that is used to control the VBUS voltage direction for either USB host mode or for charging on the OTG port diff --git a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml index 27db38577822..1a1b240034ef 100644 --- a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml @@ -8,8 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TI bq2515x 500-mA Linear charger family maintainers: - - Dan Murphy <dmurphy@ti.com> - - Ricardo Rivera-Matos <r-rivera-matos@ti.com> + - Andrew Davis <afd@ti.com> description: | The BQ2515x family is a highly integrated battery charge management IC that diff --git a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml index 91abe5733c41..82f382a7ffb3 100644 --- a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TI bq256xx Switch Mode Buck Charger maintainers: - - Ricardo Rivera-Matos <r-rivera-matos@ti.com> + - Andrew Davis <afd@ti.com> description: | The bq256xx devices are a family of highly-integrated battery charge diff --git a/Documentation/devicetree/bindings/power/supply/bq25980.yaml b/Documentation/devicetree/bindings/power/supply/bq25980.yaml index 4883527ab5c7..b687b8bcd705 100644 --- a/Documentation/devicetree/bindings/power/supply/bq25980.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq25980.yaml @@ -8,8 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TI BQ25980 Flash Charger maintainers: - - Dan Murphy <dmurphy@ti.com> - - Ricardo Rivera-Matos <r-rivera-matos@ti.com> + - Andrew Davis <afd@ti.com> description: | The BQ25980, BQ25975, and BQ25960 are a series of flash chargers intended diff --git a/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml b/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml index caeff68c66d5..cbac55d3cb92 100644 --- a/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml @@ -117,11 +117,18 @@ properties: be done externally to fully comply with the JEITA safety guidelines if this flag is set. + usb-charge-current-limit: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 100000 + maximum: 2500000 + description: | + Default USB charge current limit in uA. + usb-otg-in-supply: description: Reference to the regulator supplying power to the USB_OTG_IN pin. otg-vbus: - type: object + $ref: /schemas/regulator/regulator.yaml# description: | This node defines a regulator used to control the direction of VBUS voltage. Specifically whether to supply voltage to VBUS for host mode operation of the OTG port, diff --git a/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml b/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml index 0581497448ce..2d552becbfe6 100644 --- a/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml @@ -82,7 +82,7 @@ properties: - 1 # SMB3XX_SYSOK_INOK_ACTIVE_HIGH usb-vbus: - $ref: "../../regulator/regulator.yaml#" + $ref: /schemas/regulator/regulator.yaml# type: object properties: diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml index eec3b9c4c713..7e091eaffc18 100644 --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml @@ -18,6 +18,7 @@ properties: enum: - mediatek,mt8183-scp - mediatek,mt8186-scp + - mediatek,mt8188-scp - mediatek,mt8192-scp - mediatek,mt8195-scp @@ -80,6 +81,7 @@ allOf: enum: - mediatek,mt8183-scp - mediatek,mt8186-scp + - mediatek,mt8188-scp then: properties: reg: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index 947f94548d0e..3072af5f9d79 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -67,13 +67,28 @@ properties: minItems: 1 maxItems: 8 + interconnects: + maxItems: 1 + interrupts: minItems: 5 - maxItems: 6 + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + - description: Shutdown acknowledge interrupt interrupt-names: minItems: 5 - maxItems: 6 + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + - const: shutdown-ack resets: minItems: 1 @@ -116,7 +131,6 @@ properties: - description: Stop the modem qcom,smem-state-names: - $ref: /schemas/types.yaml#/definitions/string-array description: The names of the state bits used for SMP2P output items: - const: stop @@ -134,13 +148,13 @@ properties: three offsets within syscon for q6, modem and nc halt registers. smd-edge: - type: object + $ref: /schemas/remoteproc/qcom,smd-edge.yaml# description: Qualcomm Shared Memory subnode which represents communication edge, channels and devices related to the ADSP. glink-edge: - type: object + $ref: /schemas/remoteproc/qcom,glink-edge.yaml# description: Qualcomm G-Link subnode which represents communication edge, channels and devices related to the ADSP. @@ -315,19 +329,9 @@ allOf: then: properties: interrupts: - items: - - description: Watchdog interrupt - - description: Fatal interrupt - - description: Ready interrupt - - description: Handover interrupt - - description: Stop acknowledge interrupt + maxItems: 5 interrupt-names: - items: - - const: wdog - - const: fatal - - const: ready - - const: handover - - const: stop-ack + maxItems: 5 - if: properties: @@ -345,21 +349,9 @@ allOf: then: properties: interrupts: - items: - - description: Watchdog interrupt - - description: Fatal interrupt - - description: Ready interrupt - - description: Handover interrupt - - description: Stop acknowledge interrupt - - description: Shutdown acknowledge interrupt + minItems: 6 interrupt-names: - items: - - const: wdog - - const: fatal - - const: ready - - const: handover - - const: stop-ack - - const: shutdown-ack + minItems: 6 - if: properties: @@ -379,6 +371,8 @@ allOf: - qcom,msm8226-adsp-pil - qcom,msm8996-adsp-pil - qcom,msm8998-adsp-pas + - qcom,sm8150-adsp-pas + - qcom,sm8150-cdsp-pas then: properties: power-domains: @@ -447,19 +441,6 @@ allOf: compatible: contains: enum: - - qcom,sm8150-adsp-pas - - qcom,sm8150-cdsp-pas - then: - properties: - power-domains: - items: - - description: CX power domain - - - if: - properties: - compatible: - contains: - enum: - qcom,sc7280-mpss-pas - qcom,sdx55-mpss-pas - qcom,sm6350-mpss-pas @@ -594,11 +575,12 @@ allOf: examples: - | #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interrupt-controller/irq.h> adsp { compatible = "qcom,msm8974-adsp-pil"; - interrupts-extended = <&intc 0 162 IRQ_TYPE_EDGE_RISING>, + interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, @@ -620,7 +602,7 @@ examples: qcom,smem-state-names = "stop"; smd-edge { - interrupts = <0 156 IRQ_TYPE_EDGE_RISING>; + interrupts = <GIC_SPI 156 IRQ_TYPE_EDGE_RISING>; qcom,ipc = <&apcs 8 8>; qcom,smd-edge = <1>; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml new file mode 100644 index 000000000000..fa69f7b21eed --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,glink-edge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm G-Link Edge communication channel nodes + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + Qualcomm G-Link subnode represents communication edge, channels and devices + related to the remote processor. + +properties: + $nodename: + const: "glink-edge" + + apr: + $ref: /schemas/soc/qcom/qcom,apr.yaml# + description: + Qualcomm APR/GPR (Asynchronous/Generic Packet Router) + + fastrpc: + type: object + description: + See Documentation/devicetree/bindings/misc/qcom,fastrpc.txt + + interrupts: + maxItems: 1 + + label: + description: The names of the state bits used for SMP2P output + + mboxes: + maxItems: 1 + + qcom,remote-pid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + ID of the shared memory used by GLINK for communication with remote + processor. + +required: + - interrupts + - label + - mboxes + - qcom,remote-pid + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mailbox/qcom-ipcc.h> + + remoteproc@8a00000 { + reg = <0x08a00000 0x10000>; + // ... + + glink-edge { + interrupts-extended = <&ipcc IPCC_CLIENT_WPSS + IPCC_MPROC_SIGNAL_GLINK_QMP + IRQ_TYPE_EDGE_RISING>; + mboxes = <&ipcc IPCC_CLIENT_WPSS + IPCC_MPROC_SIGNAL_GLINK_QMP>; + + label = "wpss"; + qcom,remote-pid = <13>; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 658f96fbc4fe..d0ebd16ee0e1 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -14,8 +14,6 @@ on the Qualcomm Hexagon core. "qcom,msm8974-mss-pil" "qcom,msm8996-mss-pil" "qcom,msm8998-mss-pil" - "qcom,sc7180-mss-pil" - "qcom,sc7280-mss-pil" "qcom,sdm845-mss-pil" - reg: @@ -47,8 +45,6 @@ on the Qualcomm Hexagon core. must be "wdog", "fatal", "ready", "handover", "stop-ack" qcom,msm8996-mss-pil: qcom,msm8998-mss-pil: - qcom,sc7180-mss-pil: - qcom,sc7280-mss-pil: qcom,sdm845-mss-pil: must be "wdog", "fatal", "ready", "handover", "stop-ack", "shutdown-ack" @@ -86,11 +82,6 @@ on the Qualcomm Hexagon core. qcom,msm8998-mss-pil: must be "iface", "bus", "mem", "xo", "gpll0_mss", "snoc_axi", "mnoc_axi", "qdss" - qcom,sc7180-mss-pil: - must be "iface", "bus", "xo", "snoc_axi", "mnoc_axi", - "nav" - qcom,sc7280-mss-pil: - must be "iface", "xo", "snoc_axi", "offline", "pka" qcom,sdm845-mss-pil: must be "iface", "bus", "mem", "xo", "gpll0_mss", "snoc_axi", "mnoc_axi", "prng" @@ -102,7 +93,7 @@ on the Qualcomm Hexagon core. reference to the list of 3 reset-controllers for the wcss sub-system reference to the list of 2 reset-controllers for the modem - sub-system on SC7180, SC7280, SDM845 SoCs + sub-system on SDM845 SoCs - reset-names: Usage: required @@ -111,7 +102,7 @@ on the Qualcomm Hexagon core. must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset" for the wcss sub-system must be "mss_restart", "pdc_reset" for the modem - sub-system on SC7180, SC7280, SDM845 SoCs + sub-system on SDM845 SoCs For devices where the mba and mpss sub-nodes are not specified, mba/mpss region should be referenced as follows: @@ -176,10 +167,6 @@ For the compatible string below the following supplies are required: qcom,msm8996-mss-pil: qcom,msm8998-mss-pil: must be "cx", "mx" - qcom,sc7180-mss-pil: - must be "cx", "mx", "mss" - qcom,sc7280-mss-pil: - must be "cx", "mss" qcom,sdm845-mss-pil: must be "cx", "mx", "mss" @@ -205,36 +192,6 @@ For the compatible string below the following supplies are required: Definition: a phandle reference to a syscon representing TCSR followed by the three offsets within syscon for q6, modem and nc halt registers. - a phandle reference to a syscon representing TCSR followed - by the four offsets within syscon for q6, modem, nc and vq6 - halt registers on SC7280 SoCs. - -For the compatible strings below the following phandle references are required: - "qcom,sc7180-mss-pil" -- qcom,spare-regs: - Usage: required - Value type: <prop-encoded-array> - Definition: a phandle reference to a syscon representing TCSR followed - by the offset within syscon for conn_box_spare0 register - used by the modem sub-system running on SC7180 SoC. - -For the compatible strings below the following phandle references are required: - "qcom,sc7280-mss-pil" -- qcom,ext-regs: - Usage: required - Value type: <prop-encoded-array> - Definition: two phandle references to syscons representing TCSR_REG and - TCSR register space followed by the two offsets within the syscon - to force_clk_en/rscc_disable and axim1_clk_off/crypto_clk_off - registers respectively. - -- qcom,qaccept-regs: - Usage: required - Value type: <prop-encoded-array> - Definition: a phandle reference to a syscon representing TCSR followed - by the three offsets within syscon for mdm, cx and axi - qaccept registers used by the modem sub-system running on - SC7280 SoC. The Hexagon node must contain iommus property as described in ../iommu/iommu.txt on platforms which do not have TrustZone. @@ -257,29 +214,23 @@ related to the Hexagon. See ../soc/qcom/qcom,smd.yaml and The following example describes the resources needed to boot control the Hexagon, as it is found on MSM8974 boards. - modem-rproc@fc880000 { - compatible = "qcom,q6v5-pil"; - reg = <0xfc880000 0x100>, - <0xfc820000 0x020>; + remoteproc@fc880000 { + compatible = "qcom,msm8974-mss-pil"; + reg = <0xfc880000 0x100>, <0xfc820000 0x020>; reg-names = "qdsp6", "rmb"; - interrupts-extended = <&intc 0 24 1>, - <&modem_smp2p_in 0 0>, - <&modem_smp2p_in 1 0>, - <&modem_smp2p_in 2 0>, - <&modem_smp2p_in 3 0>; - interrupt-names = "wdog", - "fatal", - "ready", - "handover", - "stop-ack"; + interrupts-extended = <&intc GIC_SPI 24 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack"; clocks = <&gcc GCC_MSS_Q6_BIMC_AXI_CLK>, <&gcc GCC_MSS_CFG_AHB_CLK>, - <&gcc GCC_BOOT_ROM_AHB_CLK>; - clock-names = "iface", "bus", "mem"; - - qcom,halt-regs = <&tcsr_mutex_block 0x1180 0x1200 0x1280>; + <&gcc GCC_BOOT_ROM_AHB_CLK>, + <&xo_board>; + clock-names = "iface", "bus", "mem", "xo"; resets = <&gcc GCC_MSS_RESTART>; reset-names = "mss_restart"; @@ -289,6 +240,8 @@ Hexagon, as it is found on MSM8974 boards. mx-supply = <&pm8841_s1>; pll-supply = <&pm8941_l12>; + qcom,halt-regs = <&tcsr_mutex_block 0x1180 0x1200 0x1280>; + qcom,smem-states = <&modem_smp2p_out 0>; qcom,smem-state-names = "stop"; @@ -299,4 +252,13 @@ Hexagon, as it is found on MSM8974 boards. mpss { memory-region = <&mpss_region>; }; + + smd-edge { + interrupts = <GIC_SPI 25 IRQ_TYPE_EDGE_RISING>; + + qcom,ipc = <&apcs 8 12>; + qcom,smd-edge = <0>; + + label = "modem"; + }; }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml index 31413cfe10db..06f5f93f62a9 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml @@ -90,7 +90,6 @@ properties: - description: Stop the modem qcom,smem-state-names: - $ref: /schemas/types.yaml#/definitions/string description: The names of the state bits used for SMP2P output items: - const: stop diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml new file mode 100644 index 000000000000..e76c861165dd --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml @@ -0,0 +1,245 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,sc7180-mss-pil.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SC7180 MSS Peripheral Image Loader + +maintainers: + - Sibi Sankar <quic_sibis@quicinc.com> + +description: + This document describes the hardware for a component that loads and boots firmware + on the Qualcomm Technology Inc. SC7180 Modem Hexagon Core. + +properties: + compatible: + enum: + - qcom,sc7180-mss-pil + + reg: + items: + - description: MSS QDSP6 registers + - description: RMB registers + + reg-names: + items: + - const: qdsp6 + - const: rmb + + iommus: + items: + - description: MSA Stream 1 + - description: MSA Stream 2 + + interrupts: + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + - description: Shutdown acknowledge interrupt + + interrupt-names: + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + - const: shutdown-ack + + clocks: + items: + - description: GCC MSS IFACE clock + - description: GCC MSS BUS clock + - description: GCC MSS NAV clock + - description: GCC MSS SNOC_AXI clock + - description: GCC MSS MFAB_AXIS clock + - description: RPMH XO clock + + clock-names: + items: + - const: iface + - const: bus + - const: nav + - const: snoc_axi + - const: mnoc_axi + - const: xo + + power-domains: + items: + - description: CX power domain + - description: MX power domain + - description: MSS power domain + + power-domain-names: + items: + - const: cx + - const: mx + - const: mss + + resets: + items: + - description: AOSS restart + - description: PDC reset + + reset-names: + items: + - const: mss_restart + - const: pdc_reset + + memory-region: + items: + - description: MBA reserved region + - description: modem reserved region + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string-array + items: + - description: Name of MBA firmware + - description: Name of modem firmware + + qcom,halt-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Halt registers are used to halt transactions of various sub-components + within MSS. + items: + - items: + - description: phandle to TCSR_MUTEX registers + - description: offset to the Q6 halt register + - description: offset to the modem halt register + - description: offset to the nc halt register + + qcom,spare-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Spare registers are multipurpose registers used for errata + handling. + items: + - items: + - description: phandle to TCSR_MUTEX registers + - description: offset to the conn_box_spare0 register + + qcom,qmp: + $ref: /schemas/types.yaml#/definitions/phandle + description: Reference to the AOSS side-channel message RAM. + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: States used by the AP to signal the Hexagon core + items: + - description: Stop the modem + + qcom,smem-state-names: + description: The names of the state bits used for SMP2P output + const: stop + + glink-edge: + $ref: qcom,glink-edge.yaml# + description: + Qualcomm G-Link subnode which represents communication edge, channels + and devices related to the DSP. + + properties: + interrupts: + items: + - description: IRQ from MSS to GLINK + + mboxes: + items: + - description: Mailbox for communication between APPS and MSS + + label: + const: modem + + apr: false + fastrpc: false + +required: + - compatible + - reg + - reg-names + - iommus + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - power-domain-names + - resets + - reset-names + - qcom,halt-regs + - qcom,spare-regs + - memory-region + - qcom,qmp + - qcom,smem-states + - qcom,smem-state-names + - glink-edge + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sc7180.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/reset/qcom,sdm845-aoss.h> + #include <dt-bindings/reset/qcom,sdm845-pdc.h> + + remoteproc_mpss: remoteproc@4080000 { + compatible = "qcom,sc7180-mss-pil"; + reg = <0x04080000 0x10000>, <0x04180000 0x48>; + reg-names = "qdsp6", "rmb"; + + iommus = <&apps_smmu 0x461 0x0>, <&apps_smmu 0x444 0x3>; + + interrupts-extended = <&intc GIC_SPI 264 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; + + interrupt-names = "wdog", "fatal", "ready", "handover", + "stop-ack", "shutdown-ack"; + + clocks = <&gcc GCC_MSS_CFG_AHB_CLK>, + <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>, + <&gcc GCC_MSS_NAV_AXI_CLK>, + <&gcc GCC_MSS_SNOC_AXI_CLK>, + <&gcc GCC_MSS_MFAB_AXIS_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "bus", "nav", "snoc_axi", + "mnoc_axi", "xo"; + + power-domains = <&rpmhpd SC7180_CX>, + <&rpmhpd SC7180_MX>, + <&rpmhpd SC7180_MSS>; + power-domain-names = "cx", "mx", "mss"; + + memory-region = <&mba_mem>, <&mpss_mem>; + + qcom,qmp = <&aoss_qmp>; + + qcom,smem-states = <&modem_smp2p_out 0>; + qcom,smem-state-names = "stop"; + + resets = <&aoss_reset AOSS_CC_MSS_RESTART>, + <&pdc_reset PDC_MODEM_SYNC_RESET>; + reset-names = "mss_restart", "pdc_reset"; + + qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000 0x24000>; + qcom,spare-regs = <&tcsr_regs 0xb3e4>; + + glink-edge { + interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>; + mboxes = <&apss_shared 12>; + qcom,remote-pid = <1>; + label = "modem"; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml new file mode 100644 index 000000000000..da1a5de3d38b --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml @@ -0,0 +1,266 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,sc7280-mss-pil.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SC7280 MSS Peripheral Image Loader + +maintainers: + - Sibi Sankar <quic_sibis@quicinc.com> + +description: + This document describes the hardware for a component that loads and boots firmware + on the Qualcomm Technology Inc. SC7280 Modem Hexagon Core. + +properties: + compatible: + enum: + - qcom,sc7280-mss-pil + + reg: + items: + - description: MSS QDSP6 registers + - description: RMB registers + + reg-names: + items: + - const: qdsp6 + - const: rmb + + iommus: + items: + - description: MSA Stream 1 + - description: MSA Stream 2 + + interconnects: + items: + - description: Path leading to system memory + + interrupts: + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + - description: Shutdown acknowledge interrupt + + interrupt-names: + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + - const: shutdown-ack + + clocks: + items: + - description: GCC MSS IFACE clock + - description: GCC MSS OFFLINE clock + - description: GCC MSS SNOC_AXI clock + - description: RPMH PKA clock + - description: RPMH XO clock + + clock-names: + items: + - const: iface + - const: offline + - const: snoc_axi + - const: pka + - const: xo + + power-domains: + items: + - description: CX power domain + - description: MSS power domain + + power-domain-names: + items: + - const: cx + - const: mss + + resets: + items: + - description: AOSS restart + - description: PDC reset + + reset-names: + items: + - const: mss_restart + - const: pdc_reset + + memory-region: + items: + - description: MBA reserved region + - description: modem reserved region + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string-array + items: + - description: Name of MBA firmware + - description: Name of modem firmware + + qcom,halt-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Halt registers are used to halt transactions of various sub-components + within MSS. + items: + - items: + - description: phandle to TCSR_MUTEX registers + - description: offset to the Q6 halt register + - description: offset to the modem halt register + - description: offset to the nc halt register + - description: offset to the vq6 halt register + + qcom,ext-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: EXT registers are used for various power related functionality + items: + - items: + - description: phandle to TCSR_REG registers + - description: offset to the force_clk_en register + - description: offset to the rscc_disable register + - items: + - description: phandle to TCSR_MUTEX registers + - description: offset to the axim1_clk_off register + - description: offset to the crypto_clk_off register + + qcom,qaccept-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: QACCEPT registers are used to bring up/down Q-channels + items: + - items: + - description: phandle to TCSR_MUTEX registers + - description: offset to the mdm qaccept register + - description: offset to the cx qaccept register + - description: offset to the axi qaccept register + + qcom,qmp: + $ref: /schemas/types.yaml#/definitions/phandle + description: Reference to the AOSS side-channel message RAM. + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: States used by the AP to signal the Hexagon core + items: + - description: Stop the modem + + qcom,smem-state-names: + description: The names of the state bits used for SMP2P output + const: stop + + glink-edge: + $ref: qcom,glink-edge.yaml# + description: + Qualcomm G-Link subnode which represents communication edge, channels + and devices related to the DSP. + + properties: + interrupts: + items: + - description: IRQ from MSS to GLINK + + mboxes: + items: + - description: Mailbox for communication between APPS and MSS + + label: + const: modem + + apr: false + fastrpc: false + +required: + - compatible + - reg + - reg-names + - iommus + - interconnects + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - power-domain-names + - resets + - reset-names + - qcom,halt-regs + - qcom,ext-regs + - qcom,qaccept-regs + - memory-region + - qcom,qmp + - qcom,smem-states + - qcom,smem-state-names + - glink-edge + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sc7280.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/interconnect/qcom,sc7280.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mailbox/qcom-ipcc.h> + #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/reset/qcom,sdm845-aoss.h> + #include <dt-bindings/reset/qcom,sdm845-pdc.h> + + remoteproc_mpss: remoteproc@4080000 { + compatible = "qcom,sc7280-mss-pil"; + reg = <0x04080000 0x10000>, <0x04180000 0x48>; + reg-names = "qdsp6", "rmb"; + + iommus = <&apps_smmu 0x124 0x0>, <&apps_smmu 0x488 0x7>; + + interconnects = <&mc_virt MASTER_LLCC 0 &mc_virt SLAVE_EBI1 0>; + + interrupts-extended = <&intc GIC_SPI 264 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; + + interrupt-names = "wdog", "fatal", "ready", "handover", + "stop-ack", "shutdown-ack"; + + clocks = <&gcc GCC_MSS_CFG_AHB_CLK>, + <&gcc GCC_MSS_OFFLINE_AXI_CLK>, + <&gcc GCC_MSS_SNOC_AXI_CLK>, + <&rpmhcc RPMH_PKA_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "offline", "snoc_axi", "pka", "xo"; + + power-domains = <&rpmhpd SC7280_CX>, + <&rpmhpd SC7280_MSS>; + power-domain-names = "cx", "mss"; + + memory-region = <&mba_mem>, <&mpss_mem>; + + qcom,qmp = <&aoss_qmp>; + + qcom,smem-states = <&modem_smp2p_out 0>; + qcom,smem-state-names = "stop"; + + resets = <&aoss_reset AOSS_CC_MSS_RESTART>, + <&pdc_reset PDC_MODEM_SYNC_RESET>; + reset-names = "mss_restart", "pdc_reset"; + + qcom,halt-regs = <&tcsr_mutex 0x23000 0x25000 0x28000 0x33000>; + qcom,ext-regs = <&tcsr 0x10000 0x10004>, <&tcsr_mutex 0x26004 0x26008>; + qcom,qaccept-regs = <&tcsr_mutex 0x23030 0x23040 0x23020>; + + glink-edge { + interrupts-extended = <&ipcc IPCC_CLIENT_MPSS + IPCC_MPROC_SIGNAL_GLINK_QMP + IRQ_TYPE_EDGE_RISING>; + mboxes = <&ipcc IPCC_CLIENT_MPSS + IPCC_MPROC_SIGNAL_GLINK_QMP>; + label = "modem"; + qcom,remote-pid = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml index d99a729d2710..3f06d66cbe47 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml @@ -76,7 +76,7 @@ properties: - const: pdc_sync memory-region: - $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 description: Reference to the reserved-memory for the Hexagon core firmware-name: @@ -102,13 +102,12 @@ properties: - description: Stop the modem qcom,smem-state-names: - $ref: /schemas/types.yaml#/definitions/string description: The names of the state bits used for SMP2P output const: stop glink-edge: - type: object - description: | + $ref: qcom,glink-edge.yaml# + description: Qualcomm G-Link subnode which represents communication edge, channels and devices related to the ADSP. @@ -122,21 +121,11 @@ properties: - description: Mailbox for communication between APPS and WPSS label: - description: The names of the state bits used for SMP2P output items: - const: wpss - qcom,remote-pid: - $ref: /schemas/types.yaml#/definitions/uint32 - description: ID of the shared memory used by GLINK for communication with WPSS - - required: - - interrupts - - mboxes - - label - - qcom,remote-pid - - additionalProperties: false + apr: false + fastrpc: false required: - compatible diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml index 1535bbbe25da..20df83a96ef3 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml @@ -90,7 +90,6 @@ properties: - description: Stop the modem qcom,smem-state-names: - $ref: /schemas/types.yaml#/definitions/string description: The names of the state bits used for SMP2P output items: - const: stop diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml new file mode 100644 index 000000000000..06eebf791e32 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,smd-edge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SMD Edge communication channel nodes + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + Qualcomm SMD subnode represents a remote subsystem or a remote processor of + some sort - or in SMD language an "edge". The name of the edges are not + important. + See also Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml + +properties: + $nodename: + const: "smd-edge" + + interrupts: + maxItems: 1 + + label: + description: + Name of the edge, used for debugging and identification purposes. The + node name will be used if this is not present. + + mboxes: + maxItems: 1 + description: + Reference to the mailbox representing the outgoing doorbell in APCS for + this client. + + qcom,ipc: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to a syscon node representing the APCS registers + - description: u32 representing offset to the register within the syscon + - description: u32 representing the ipc bit within the register + description: + Three entries specifying the outgoing ipc bit used for signaling the + remote processor. + + qcom,smd-edge: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The identifier of the remote processor in the smd channel allocation + table. + + qcom,remote-pid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The identifier for the remote processor as known by the rest of the + system. + +required: + - interrupts + - qcom,smd-edge + +oneOf: + - required: + - mboxes + - required: + - qcom,ipc + +additionalProperties: true + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mailbox/qcom-ipcc.h> + + remoteproc { + // ... + + smd-edge { + interrupts = <GIC_SPI 156 IRQ_TYPE_EDGE_RISING>; + + qcom,ipc = <&apcs 8 8>; + qcom,smd-edge = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml index d7c3a78e37e6..cd55d80137f7 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml @@ -36,17 +36,18 @@ properties: enum: - ti,am3356-pru # for AM335x SoC family (AM3356+ SoCs only) - ti,am4376-pru # for AM437x SoC family (AM4376+ SoCs only) + - ti,am5728-pru # for AM57xx SoC family + - ti,am625-pru # for PRUs in K3 AM62x SoC family - ti,am642-pru # for PRUs in K3 AM64x SoC family - ti,am642-rtu # for RTUs in K3 AM64x SoC family - ti,am642-tx-pru # for Tx_PRUs in K3 AM64x SoC family - - ti,am5728-pru # for AM57xx SoC family - - ti,k2g-pru # for 66AK2G SoC family - ti,am654-pru # for PRUs in K3 AM65x SoC family - ti,am654-rtu # for RTUs in K3 AM65x SoC family - ti,am654-tx-pru # for Tx_PRUs in K3 AM65x SR2.0 SoCs - ti,j721e-pru # for PRUs in K3 J721E SoC family - ti,j721e-rtu # for RTUs in K3 J721E SoC family - ti,j721e-tx-pru # for Tx_PRUs in K3 J721E SoC family + - ti,k2g-pru # for 66AK2G SoC family reg: items: diff --git a/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml b/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml new file mode 100644 index 000000000000..98465d26949e --- /dev/null +++ b/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/atmel,at91sam9260-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel/Microchip System Reset Controller + +maintainers: + - Claudiu Beznea <claudiu.beznea@microchip.com> + +description: | + The system reset controller can be used to reset the CPU. In case of + SAMA7G5 it can also reset some devices (e.g. USB PHYs). + +properties: + compatible: + oneOf: + - items: + - enum: + - atmel,at91sam9260-rstc + - atmel,at91sam9g45-rstc + - atmel,sama5d3-rstc + - microchip,sam9x60-rstc + - microchip,sama7g5-rstc + - items: + - const: atmel,sama5d3-rstc + - const: atmel,at91sam9g45-rstc + + reg: + minItems: 1 + items: + - description: base registers for system reset control + - description: registers for device specific reset control + + clocks: + maxItems: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - clocks + +allOf: + - if: + properties: + compatible: + contains: + enum: + - microchip,sama7g5-rstc + then: + required: + - "#reset-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/at91.h> + + reset-controller@fffffd00 { + compatible = "atmel,at91sam9260-rstc"; + reg = <0xfffffd00 0x10>; + clocks = <&pmc PMC_TYPE_CORE PMC_SLOW>; + }; diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml index 9593840a4a2b..60f9027e8299 100644 --- a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml +++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml @@ -32,6 +32,7 @@ properties: - 11000 trickle-voltage-millivolt: + $ref: /schemas/types.yaml#/definitions/uint32 enum: - 1750 - 3000 diff --git a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml new file mode 100644 index 000000000000..7a1857f5caa8 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/nuvoton,nct3018y.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NUVOTON NCT3018Y Real Time Clock + +allOf: + - $ref: "rtc.yaml#" + +maintainers: + - Medad CChien <ctcchien@nuvoton.com> + - Mia Lin <mimi05633@gmail.com> + +properties: + compatible: + const: nuvoton,nct3018y + + reg: + maxItems: 1 + + start-year: true + + reset-source: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc@6f { + compatible = "nuvoton,nct3018y"; + reg = <0x6f>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt deleted file mode 100644 index 217b7cd06c11..000000000000 --- a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt +++ /dev/null @@ -1,32 +0,0 @@ -* NXP PCF85063 Real Time Clock - -Required properties: -- compatible: Should one of contain: - "nxp,pca85073a", - "nxp,pcf85063", - "nxp,pcf85063a", - "nxp,pcf85063tp", - "microcrystal,rv8263" -- reg: I2C address for chip. - -Optional property: -- quartz-load-femtofarads: The capacitive load of the quartz(x-tal), - expressed in femto Farad (fF). Valid values are 7000 and 12500. - Default value (if no value is specified) is 7000fF. - -Optional child node: -- clock: Provide this if the square wave pin is used as boot-enabled fixed clock. - -Example: - -pcf85063: rtc@51 { - compatible = "nxp,pcf85063"; - reg = <0x51>; - quartz-load-femtofarads = <12500>; - - clock { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <32768>; - }; -}; diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.yaml new file mode 100644 index 000000000000..2f892f8640d1 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/nxp,pcf85063.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP PCF85063 Real Time Clock + +maintainers: + - Alexander Stein <alexander.stein@ew.tq-group.com> + +properties: + compatible: + enum: + - microcrystal,rv8263 + - nxp,pcf85063 + - nxp,pcf85063a + - nxp,pcf85063tp + - nxp,pca85073a + + reg: + maxItems: 1 + + "#clock-cells": + const: 0 + + clock-output-names: + maxItems: 1 + + interrupts: + maxItems: 1 + + quartz-load-femtofarads: + description: + The capacitive load of the quartz(x-tal). + enum: [7000, 12500] + default: 7000 + + clock: + $ref: /schemas/clock/fixed-clock.yaml + description: + Provide this if the square wave pin is used as boot-enabled + fixed clock. + + wakeup-source: true + +allOf: + - $ref: rtc.yaml# + - if: + properties: + compatible: + contains: + enum: + - microcrystal,rv8263 + then: + properties: + quartz-load-femtofarads: false + - if: + properties: + compatible: + contains: + enum: + - nxp,pcf85063 + then: + properties: + quartz-load-femtofarads: + const: 7000 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc@51 { + compatible = "nxp,pcf85063a"; + reg = <0x51>; + quartz-load-femtofarads = <12500>; + + clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml index 6fa7d9fc2dc7..23ab5bb4f395 100644 --- a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm PM8xxx PMIC RTC device maintainers: - - Satya Priya <skakit@codeaurora.org> + - Satya Priya <quic_c_skakit@quicinc.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt index 55a0c8874c03..7212076a8f1b 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt +++ b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt @@ -14,6 +14,8 @@ For MediaTek PMIC wrapper bus bindings, see: Required properties: - compatible: Should be one of follows "mediatek,mt6323-rtc": for MT6323 PMIC + "mediatek,mt6358-rtc": for MT6358 PMIC + "mediatek,mt6366-rtc", "mediatek,mt6358-rtc": for MT6366 PMIC "mediatek,mt6397-rtc": for MT6397 PMIC Example: diff --git a/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml b/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml new file mode 100644 index 000000000000..d995ef04a6eb --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/ti,k3-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments K3 Real Time Clock + +maintainers: + - Nishanth Menon <nm@ti.com> + +description: | + This RTC appears in the AM62x family of SoCs. + +allOf: + - $ref: "rtc.yaml#" + +properties: + compatible: + enum: + - ti,am62-rtc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: VBUS Interface clock + - description: 32k Clock source (external or internal). + + clock-names: + items: + - const: vbus + - const: osc32k + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + rtc@2b1f0000 { + compatible = "ti,am62-rtc"; + reg = <0x2b1f0000 0x100>; + interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&bar 0>; + clocks = <&foo 0>, <&foo 1>; + clock-names = "vbus", "osc32k"; + wakeup-source; + }; diff --git a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml index bdb72d3ddf2a..7ed0230f6c67 100644 --- a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml @@ -23,8 +23,15 @@ properties: reg: maxItems: 1 + clocks: + maxItems: 1 + + clock-names: + items: + - const: rtc + interrupts: - minItems: 2 + maxItems: 2 interrupt-names: items: @@ -39,6 +46,7 @@ properties: minimum: 0x1 maximum: 0x1FFFFF default: 0x198233 + deprecated: true required: - compatible @@ -61,5 +69,7 @@ examples: interrupts = <0 26 4>, <0 27 4>; interrupt-names = "alarm", "sec"; calibration = <0x198233>; + clock-names = "rtc"; + clocks = <&rtc_clk>; }; }; diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml index 5f6b113d378f..6258f5f59b19 100644 --- a/Documentation/devicetree/bindings/serial/8250.yaml +++ b/Documentation/devicetree/bindings/serial/8250.yaml @@ -62,6 +62,7 @@ properties: - const: mrvl,pxa-uart - const: nuvoton,wpcm450-uart - const: nuvoton,npcm750-uart + - const: nuvoton,npcm845-uart - const: nvidia,tegra20-uart - const: nxp,lpc3220-uart - items: diff --git a/Documentation/devicetree/bindings/serial/mediatek,uart.yaml b/Documentation/devicetree/bindings/serial/mediatek,uart.yaml new file mode 100644 index 000000000000..4ff27d6d4d5b --- /dev/null +++ b/Documentation/devicetree/bindings/serial/mediatek,uart.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/mediatek,uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Universal Asynchronous Receiver/Transmitter (UART) + +maintainers: + - Matthias Brugger <matthias.bgg@gmail.com> + +allOf: + - $ref: serial.yaml# + +description: | + The MediaTek UART is based on the basic 8250 UART and compatible + with 16550A, with enhancements for high speed baud rates and + support for DMA. + +properties: + compatible: + oneOf: + - const: mediatek,mt6577-uart + - items: + - enum: + - mediatek,mt2701-uart + - mediatek,mt2712-uart + - mediatek,mt6580-uart + - mediatek,mt6582-uart + - mediatek,mt6589-uart + - mediatek,mt6755-uart + - mediatek,mt6765-uart + - mediatek,mt6779-uart + - mediatek,mt6795-uart + - mediatek,mt6797-uart + - mediatek,mt7622-uart + - mediatek,mt7623-uart + - mediatek,mt7629-uart + - mediatek,mt7986-uart + - mediatek,mt8127-uart + - mediatek,mt8135-uart + - mediatek,mt8173-uart + - mediatek,mt8183-uart + - mediatek,mt8186-uart + - mediatek,mt8192-uart + - mediatek,mt8195-uart + - mediatek,mt8516-uart + - const: mediatek,mt6577-uart + + reg: + description: The base address of the UART register bank + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: The clock the baudrate is derived from + - description: The bus clock for register accesses + + clock-names: + minItems: 1 + items: + - const: baud + - const: bus + + dmas: + items: + - description: phandle to TX DMA + - description: phandle to RX DMA + + dma-names: + items: + - const: tx + - const: rx + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + description: + The UART interrupt and optionally the RX in-band wakeup interrupt. + minItems: 1 + items: + - const: uart + - const: wakeup + + pinctrl-0: true + pinctrl-1: true + + pinctrl-names: + minItems: 1 + items: + - const: default + - const: sleep + +required: + - compatible + - reg + - clocks + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + serial@11006000 { + compatible = "mediatek,mt6589-uart", "mediatek,mt6577-uart"; + reg = <0x11006000 0x400>; + interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 52 IRQ_TYPE_EDGE_FALLING>; + interrupt-names = "uart", "wakeup"; + clocks = <&uart_clk>, <&bus_clk>; + clock-names = "baud", "bus"; + pinctrl-0 = <&uart_pin>; + pinctrl-1 = <&uart_pin_sleep>; + pinctrl-names = "default", "sleep"; + }; diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt deleted file mode 100644 index 113b5d6a2245..000000000000 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ /dev/null @@ -1,59 +0,0 @@ -* MediaTek Universal Asynchronous Receiver/Transmitter (UART) - -Required properties: -- compatible should contain: - * "mediatek,mt2701-uart" for MT2701 compatible UARTS - * "mediatek,mt2712-uart" for MT2712 compatible UARTS - * "mediatek,mt6580-uart" for MT6580 compatible UARTS - * "mediatek,mt6582-uart" for MT6582 compatible UARTS - * "mediatek,mt6589-uart" for MT6589 compatible UARTS - * "mediatek,mt6755-uart" for MT6755 compatible UARTS - * "mediatek,mt6765-uart" for MT6765 compatible UARTS - * "mediatek,mt6779-uart" for MT6779 compatible UARTS - * "mediatek,mt6795-uart" for MT6795 compatible UARTS - * "mediatek,mt6797-uart" for MT6797 compatible UARTS - * "mediatek,mt7622-uart" for MT7622 compatible UARTS - * "mediatek,mt7623-uart" for MT7623 compatible UARTS - * "mediatek,mt7629-uart" for MT7629 compatible UARTS - * "mediatek,mt7986-uart", "mediatek,mt6577-uart" for MT7986 compatible UARTS - * "mediatek,mt8127-uart" for MT8127 compatible UARTS - * "mediatek,mt8135-uart" for MT8135 compatible UARTS - * "mediatek,mt8173-uart" for MT8173 compatible UARTS - * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS - * "mediatek,mt8186-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS - * "mediatek,mt8192-uart", "mediatek,mt6577-uart" for MT8192 compatible UARTS - * "mediatek,mt8195-uart", "mediatek,mt6577-uart" for MT8195 compatible UARTS - * "mediatek,mt8516-uart" for MT8516 compatible UARTS - * "mediatek,mt6577-uart" for MT6577 and all of the above - -- reg: The base address of the UART register bank. - -- interrupts: - index 0: an interrupt specifier for the UART controller itself - index 1: optional, an interrupt specifier with edge sensitivity on Rx pin to - support Rx in-band wake up. If one would like to use this feature, - one must create an addtional pinctrl to reconfigure Rx pin to normal - GPIO before suspend. - -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: - - "baud": The clock the baudrate is derived from - - "bus": The bus clock for register accesses (optional) - -For compatibility with older device trees an unnamed clock is used for the -baud clock if the baudclk does not exist. Do not use this for new designs. - -Example: - - uart0: serial@11006000 { - compatible = "mediatek,mt6589-uart", "mediatek,mt6577-uart"; - reg = <0x11006000 0x400>; - interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 52 IRQ_TYPE_EDGE_FALLING>; - clocks = <&uart_clk>, <&bus_clk>; - clock-names = "baud", "bus"; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&uart_pin>; - pinctrl-1 = <&uart_pin_sleep>; - }; diff --git a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml index 87180d95cd4c..1957b9d782e8 100644 --- a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml @@ -57,6 +57,7 @@ properties: - items: - enum: - renesas,hscif-r8a779a0 # R-Car V3U + - renesas,hscif-r8a779f0 # R-Car S4-8 - renesas,hscif-r8a779g0 # R-Car V4H - const: renesas,rcar-gen4-hscif # R-Car Gen4 - const: renesas,hscif # generic HSCIF compatible UART diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml index f2c9c9fe6aa7..90a1bab40f05 100644 --- a/Documentation/devicetree/bindings/serial/rs485.yaml +++ b/Documentation/devicetree/bindings/serial/rs485.yaml @@ -22,12 +22,12 @@ properties: - description: Delay between rts signal and beginning of data sent in milliseconds. It corresponds to the delay before sending data. default: 0 - maximum: 1000 + maximum: 100 - description: Delay between end of data sent and rts signal in milliseconds. It corresponds to the delay after sending data and actual release of the line. default: 0 - maximum: 1000 + maximum: 100 rs485-rts-active-low: description: drive RTS low when sending (default is high). diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index 12137fe80acf..dc74643ae72e 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -33,7 +33,9 @@ properties: - rockchip,rk3368-uart - rockchip,rk3399-uart - rockchip,rk3568-uart + - rockchip,rk3588-uart - rockchip,rv1108-uart + - rockchip,rv1126-uart - const: snps,dw-apb-uart - items: - enum: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index 50f834563e19..09d5bfa920f2 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -92,12 +92,33 @@ examples: qcom,ipc = <&apcs 8 0>; qcom,smd-edge = <15>; - rpm-requests { - compatible = "qcom,rpm-msm8974"; - qcom,smd-channels = "rpm_requests"; + rpm-requests { + compatible = "qcom,rpm-msm8916"; + qcom,smd-channels = "rpm_requests"; + + clock-controller { + compatible = "qcom,rpmcc-msm8916", "qcom,rpmcc"; + #clock-cells = <1>; + clocks = <&xo_board>; + clock-names = "xo"; + }; - /* Regulator nodes to follow */ + power-controller { + compatible = "qcom,msm8916-rpmpd"; + #power-domain-cells = <1>; + operating-points-v2 = <&rpmpd_opp_table>; + + rpmpd_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-1 { + opp-level = <1>; + }; + opp-2 { + opp-level = <2>; + }; + }; }; }; - }; -... + }; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml index bca07bb13ebf..9b3efe97f47c 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml @@ -21,51 +21,13 @@ properties: patternProperties: "^.*-edge|rpm$": - type: object + $ref: /schemas/remoteproc/qcom,smd-edge.yaml# description: Each subnode of the SMD node represents a remote subsystem or a remote processor of some sort - or in SMD language an "edge". The name of the edges are not important. properties: - interrupts: - maxItems: 1 - - label: - $ref: /schemas/types.yaml#/definitions/string - description: - Name of the edge, used for debugging and identification purposes. The - node name will be used if this is not present. - - mboxes: - maxItems: 1 - description: - Reference to the mailbox representing the outgoing doorbell in APCS for - this client. - - qcom,ipc: - $ref: /schemas/types.yaml#/definitions/phandle-array - items: - - items: - - description: phandle to a syscon node representing the APCS registers - - description: u32 representing offset to the register within the syscon - - description: u32 representing the ipc bit within the register - description: - Three entries specifying the outgoing ipc bit used for signaling the - remote processor. - - qcom,smd-edge: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - The identifier of the remote processor in the smd channel allocation - table. - - qcom,remote-pid: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - The identifier for the remote processor as known by the rest of the - system. - rpm-requests: type: object description: @@ -89,17 +51,7 @@ patternProperties: additionalProperties: true - required: - - interrupts - - qcom,smd-edge - - oneOf: - - required: - - mboxes - - required: - - qcom,ipc - - additionalProperties: false + unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/sound/tas2562.yaml b/Documentation/devicetree/bindings/sound/tas2562.yaml index 5f7dd5d6cbca..30f6b029ac08 100644 --- a/Documentation/devicetree/bindings/sound/tas2562.yaml +++ b/Documentation/devicetree/bindings/sound/tas2562.yaml @@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: Texas Instruments TAS2562 Smart PA maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The TAS2562 is a mono, digital input Class-D audio amplifier optimized for diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index bc2fb1a80ed7..ee698614862e 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments TLV320ADCX140 Quad Channel Analog-to-Digital Converter maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The TLV320ADCX140 are multichannel (4-ch analog recording or 8-ch digital diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml b/Documentation/devicetree/bindings/virtio/mmio.yaml index 10c22b5bd16a..0aa8433f0a5e 100644 --- a/Documentation/devicetree/bindings/virtio/mmio.yaml +++ b/Documentation/devicetree/bindings/virtio/mmio.yaml @@ -33,6 +33,10 @@ properties: description: Required for devices making accesses thru an IOMMU. maxItems: 1 + wakeup-source: + type: boolean + description: Required for setting irq of a virtio_mmio device as wakeup source. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml index 2bd6b4a52637..d8ac0be36e6c 100644 --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml @@ -24,6 +24,7 @@ properties: - qcom,apss-wdt-sc8280xp - qcom,apss-wdt-sdm845 - qcom,apss-wdt-sdx55 + - qcom,apss-wdt-sdx65 - qcom,apss-wdt-sm6350 - qcom,apss-wdt-sm8150 - qcom,apss-wdt-sm8250 diff --git a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml index 11b220a5e0f6..099245fe7b10 100644 --- a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml @@ -29,6 +29,7 @@ properties: - realtek,rtl8380-wdt - realtek,rtl8390-wdt - realtek,rtl9300-wdt + - realtek,rtl9310-wdt reg: maxItems: 1 diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index db476bb170b6..5149ecdc53c7 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -362,6 +362,14 @@ CXL Core .. kernel-doc:: drivers/cxl/core/mbox.c :doc: cxl mbox +CXL Regions +----------- +.. kernel-doc:: drivers/cxl/core/region.c + :doc: cxl core region + +.. kernel-doc:: drivers/cxl/core/region.c + :identifiers: + External Interfaces =================== diff --git a/Documentation/driver-api/serial/driver.rst b/Documentation/driver-api/serial/driver.rst index 7ef83fd3917b..23c6b956cd90 100644 --- a/Documentation/driver-api/serial/driver.rst +++ b/Documentation/driver-api/serial/driver.rst @@ -25,10 +25,10 @@ Console Support --------------- The serial core provides a few helper functions. This includes identifing -the correct port structure (via uart_get_console) and decoding command line -arguments (uart_parse_options). +the correct port structure (via uart_get_console()) and decoding command line +arguments (uart_parse_options()). -There is also a helper function (uart_console_write) which performs a +There is also a helper function (uart_console_write()) which performs a character by character write, translating newlines to CRLF sequences. Driver writers are recommended to use this function rather than implementing their own version. @@ -39,7 +39,7 @@ Locking It is the responsibility of the low level hardware driver to perform the necessary locking using port->lock. There are some exceptions (which -are described in the uart_ops listing below.) +are described in the struct uart_ops listing below.) There are two locks. A per-port spinlock, and an overall semaphore. @@ -63,442 +63,20 @@ commonly referred to as the port mutex. uart_ops -------- -The uart_ops structure is the main interface between serial_core and the -hardware specific driver. It contains all the methods to control the -hardware. - - tx_empty(port) - This function tests whether the transmitter fifo and shifter - for the port described by 'port' is empty. If it is empty, - this function should return TIOCSER_TEMT, otherwise return 0. - If the port does not support this operation, then it should - return TIOCSER_TEMT. - - Locking: none. - - Interrupts: caller dependent. - - This call must not sleep - - set_mctrl(port, mctrl) - This function sets the modem control lines for port described - by 'port' to the state described by mctrl. The relevant bits - of mctrl are: - - - TIOCM_RTS RTS signal. - - TIOCM_DTR DTR signal. - - TIOCM_OUT1 OUT1 signal. - - TIOCM_OUT2 OUT2 signal. - - TIOCM_LOOP Set the port into loopback mode. - - If the appropriate bit is set, the signal should be driven - active. If the bit is clear, the signal should be driven - inactive. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - get_mctrl(port) - Returns the current state of modem control inputs. The state - of the outputs should not be returned, since the core keeps - track of their state. The state information should include: - - - TIOCM_CAR state of DCD signal - - TIOCM_CTS state of CTS signal - - TIOCM_DSR state of DSR signal - - TIOCM_RI state of RI signal - - The bit is set if the signal is currently driven active. If - the port does not support CTS, DCD or DSR, the driver should - indicate that the signal is permanently active. If RI is - not available, the signal should not be indicated as active. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - stop_tx(port) - Stop transmitting characters. This might be due to the CTS - line becoming inactive or the tty layer indicating we want - to stop transmission due to an XOFF character. - - The driver should stop transmitting characters as soon as - possible. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - start_tx(port) - Start transmitting characters. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - throttle(port) - Notify the serial driver that input buffers for the line discipline are - close to full, and it should somehow signal that no more characters - should be sent to the serial port. - This will be called only if hardware assisted flow control is enabled. - - Locking: serialized with .unthrottle() and termios modification by the - tty layer. - - unthrottle(port) - Notify the serial driver that characters can now be sent to the serial - port without fear of overrunning the input buffers of the line - disciplines. - - This will be called only if hardware assisted flow control is enabled. - - Locking: serialized with .throttle() and termios modification by the - tty layer. - - send_xchar(port,ch) - Transmit a high priority character, even if the port is stopped. - This is used to implement XON/XOFF flow control and tcflow(). If - the serial driver does not implement this function, the tty core - will append the character to the circular buffer and then call - start_tx() / stop_tx() to flush the data out. - - Do not transmit if ch == '\0' (__DISABLED_CHAR). - - Locking: none. - - Interrupts: caller dependent. - - stop_rx(port) - Stop receiving characters; the port is in the process of - being closed. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - enable_ms(port) - Enable the modem status interrupts. - - This method may be called multiple times. Modem status - interrupts should be disabled when the shutdown method is - called. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - break_ctl(port,ctl) - Control the transmission of a break signal. If ctl is - nonzero, the break signal should be transmitted. The signal - should be terminated when another call is made with a zero - ctl. - - Locking: caller holds tty_port->mutex - - startup(port) - Grab any interrupt resources and initialise any low level driver - state. Enable the port for reception. It should not activate - RTS nor DTR; this will be done via a separate call to set_mctrl. - - This method will only be called when the port is initially opened. - - Locking: port_sem taken. - - Interrupts: globally disabled. - - shutdown(port) - Disable the port, disable any break condition that may be in - effect, and free any interrupt resources. It should not disable - RTS nor DTR; this will have already been done via a separate - call to set_mctrl. - - Drivers must not access port->state once this call has completed. - - This method will only be called when there are no more users of - this port. - - Locking: port_sem taken. - - Interrupts: caller dependent. - - flush_buffer(port) - Flush any write buffers, reset any DMA state and stop any - ongoing DMA transfers. - - This will be called whenever the port->state->xmit circular - buffer is cleared. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - set_termios(port,termios,oldtermios) - Change the port parameters, including word length, parity, stop - bits. Update read_status_mask and ignore_status_mask to indicate - the types of events we are interested in receiving. Relevant - termios->c_cflag bits are: - - CSIZE - - word size - CSTOPB - - 2 stop bits - PARENB - - parity enable - PARODD - - odd parity (when PARENB is in force) - CREAD - - enable reception of characters (if not set, - still receive characters from the port, but - throw them away. - CRTSCTS - - if set, enable CTS status change reporting - CLOCAL - - if not set, enable modem status change - reporting. - - Relevant termios->c_iflag bits are: - - INPCK - - enable frame and parity error events to be - passed to the TTY layer. - BRKINT / PARMRK - - both of these enable break events to be - passed to the TTY layer. - - IGNPAR - - ignore parity and framing errors - IGNBRK - - ignore break errors, If IGNPAR is also - set, ignore overrun errors as well. - - The interaction of the iflag bits is as follows (parity error - given as an example): - - =============== ======= ====== ============================= - Parity error INPCK IGNPAR - =============== ======= ====== ============================= - n/a 0 n/a character received, marked as - TTY_NORMAL - None 1 n/a character received, marked as - TTY_NORMAL - Yes 1 0 character received, marked as - TTY_PARITY - Yes 1 1 character discarded - =============== ======= ====== ============================= - - Other flags may be used (eg, xon/xoff characters) if your - hardware supports hardware "soft" flow control. - - Locking: caller holds tty_port->mutex - - Interrupts: caller dependent. - - This call must not sleep - - set_ldisc(port,termios) - Notifier for discipline change. See ../tty/tty_ldisc.rst. - - Locking: caller holds tty_port->mutex - - pm(port,state,oldstate) - Perform any power management related activities on the specified - port. State indicates the new state (defined by - enum uart_pm_state), oldstate indicates the previous state. - - This function should not be used to grab any resources. - - This will be called when the port is initially opened and finally - closed, except when the port is also the system console. This - will occur even if CONFIG_PM is not set. - - Locking: none. - - Interrupts: caller dependent. - - type(port) - Return a pointer to a string constant describing the specified - port, or return NULL, in which case the string 'unknown' is - substituted. - - Locking: none. - - Interrupts: caller dependent. - - release_port(port) - Release any memory and IO region resources currently in use by - the port. - - Locking: none. - - Interrupts: caller dependent. - - request_port(port) - Request any memory and IO region resources required by the port. - If any fail, no resources should be registered when this function - returns, and it should return -EBUSY on failure. - - Locking: none. - - Interrupts: caller dependent. - - config_port(port,type) - Perform any autoconfiguration steps required for the port. `type` - contains a bit mask of the required configuration. UART_CONFIG_TYPE - indicates that the port requires detection and identification. - port->type should be set to the type found, or PORT_UNKNOWN if - no port was detected. - - UART_CONFIG_IRQ indicates autoconfiguration of the interrupt signal, - which should be probed using standard kernel autoprobing techniques. - This is not necessary on platforms where ports have interrupts - internally hard wired (eg, system on a chip implementations). - - Locking: none. - - Interrupts: caller dependent. - - verify_port(port,serinfo) - Verify the new serial port information contained within serinfo is - suitable for this port type. - - Locking: none. - - Interrupts: caller dependent. - - ioctl(port,cmd,arg) - Perform any port specific IOCTLs. IOCTL commands must be defined - using the standard numbering system found in <asm/ioctl.h> - - Locking: none. - - Interrupts: caller dependent. - - poll_init(port) - Called by kgdb to perform the minimal hardware initialization needed - to support poll_put_char() and poll_get_char(). Unlike ->startup() - this should not request interrupts. - - Locking: tty_mutex and tty_port->mutex taken. - - Interrupts: n/a. - - poll_put_char(port,ch) - Called by kgdb to write a single character directly to the serial - port. It can and should block until there is space in the TX FIFO. - - Locking: none. - - Interrupts: caller dependent. - - This call must not sleep - - poll_get_char(port) - Called by kgdb to read a single character directly from the serial - port. If data is available, it should be returned; otherwise - the function should return NO_POLL_CHAR immediately. - - Locking: none. - - Interrupts: caller dependent. - - This call must not sleep +.. kernel-doc:: include/linux/serial_core.h + :identifiers: uart_ops Other functions --------------- -uart_update_timeout(port,cflag,baud) - Update the FIFO drain timeout, port->timeout, according to the - number of bits, parity, stop bits and baud rate. - - Locking: caller is expected to take port->lock - - Interrupts: n/a - -uart_get_baud_rate(port,termios,old,min,max) - Return the numeric baud rate for the specified termios, taking - account of the special 38400 baud "kludge". The B0 baud rate - is mapped to 9600 baud. - - If the baud rate is not within min..max, then if old is non-NULL, - the original baud rate will be tried. If that exceeds the - min..max constraint, 9600 baud will be returned. termios will - be updated to the baud rate in use. - - Note: min..max must always allow 9600 baud to be selected. - - Locking: caller dependent. - - Interrupts: n/a - -uart_get_divisor(port,baud) - Return the divisor (baud_base / baud) for the specified baud - rate, appropriately rounded. - - If 38400 baud and custom divisor is selected, return the - custom divisor instead. - - Locking: caller dependent. - - Interrupts: n/a - -uart_match_port(port1,port2) - This utility function can be used to determine whether two - uart_port structures describe the same port. - - Locking: n/a - - Interrupts: n/a - -uart_write_wakeup(port) - A driver is expected to call this function when the number of - characters in the transmit buffer have dropped below a threshold. - - Locking: port->lock should be held. - - Interrupts: n/a - -uart_register_driver(drv) - Register a uart driver with the core driver. We in turn register - with the tty layer, and initialise the core driver per-port state. - - drv->port should be NULL, and the per-port structures should be - registered using uart_add_one_port after this call has succeeded. - - Locking: none - - Interrupts: enabled - -uart_unregister_driver() - Remove all references to a driver from the core driver. The low - level driver must have removed all its ports via the - uart_remove_one_port() if it registered them with uart_add_one_port(). - - Locking: none - - Interrupts: enabled - -**uart_suspend_port()** - -**uart_resume_port()** - -**uart_add_one_port()** - -**uart_remove_one_port()** +.. kernel-doc:: drivers/tty/serial/serial_core.c + :identifiers: uart_update_timeout uart_get_baud_rate uart_get_divisor + uart_match_port uart_write_wakeup uart_register_driver + uart_unregister_driver uart_suspend_port uart_resume_port + uart_add_one_port uart_remove_one_port uart_console_write + uart_parse_earlycon uart_parse_options uart_set_options + uart_get_lsr_info uart_handle_dcd_change uart_handle_cts_change + uart_try_toggle_sysrq uart_get_console Other notes ----------- @@ -519,31 +97,7 @@ Modem control lines via GPIO Some helpers are provided in order to set/get modem control lines via GPIO. -mctrl_gpio_init(port, idx): - This will get the {cts,rts,...}-gpios from device tree if they are - present and request them, set direction etc, and return an - allocated structure. `devm_*` functions are used, so there's no need - to call mctrl_gpio_free(). - As this sets up the irq handling make sure to not handle changes to the - gpio input lines in your driver, too. - -mctrl_gpio_free(dev, gpios): - This will free the requested gpios in mctrl_gpio_init(). - As `devm_*` functions are used, there's generally no need to call - this function. - -mctrl_gpio_to_gpiod(gpios, gidx) - This returns the gpio_desc structure associated to the modem line - index. - -mctrl_gpio_set(gpios, mctrl): - This will sets the gpios according to the mctrl state. - -mctrl_gpio_get(gpios, mctrl): - This will update mctrl with the gpios values. - -mctrl_gpio_enable_ms(gpios): - Enables irqs and handling of changes to the ms lines. - -mctrl_gpio_disable_ms(gpios): - Disables irqs and handling of changes to the ms lines. +.. kernel-doc:: drivers/tty/serial/serial_mctrl_gpio.c + :identifiers: mctrl_gpio_init mctrl_gpio_free mctrl_gpio_to_gpiod + mctrl_gpio_set mctrl_gpio_get mctrl_gpio_enable_ms + mctrl_gpio_disable_ms diff --git a/Documentation/driver-api/serial/serial-rs485.rst b/Documentation/driver-api/serial/serial-rs485.rst index 6bc824f948f9..6ebad75c74ed 100644 --- a/Documentation/driver-api/serial/serial-rs485.rst +++ b/Documentation/driver-api/serial/serial-rs485.rst @@ -38,10 +38,14 @@ RS485 Serial Communications the values given by the device tree. Any driver for devices capable of working both as RS232 and RS485 should - implement the rs485_config callback in the uart_port structure. The - serial_core calls rs485_config to do the device specific part in response - to TIOCSRS485 and TIOCGRS485 ioctls (see below). The rs485_config callback - receives a pointer to struct serial_rs485. + implement the rs485_config callback and provide rs485_supported in the + uart_port structure. The serial core calls rs485_config to do the device + specific part in response to TIOCSRS485 ioctl (see below). The rs485_config + callback receives a pointer to a sanitizated serial_rs485 structure. The + serial_rs485 userspace provides is sanitized before calling rs485_config + using rs485_supported that indicates what RS485 features the driver supports + for the uart_port. TIOCGRS485 ioctl can be used to read back the + serial_rs485 structure matching to the current configuration. 4. Usage from user-level ======================== @@ -95,7 +99,31 @@ RS485 Serial Communications /* Error handling. See errno. */ } -5. References +5. Multipoint Addressing +======================== + + The Linux kernel provides addressing mode for multipoint RS-485 serial + communications line. The addressing mode is enabled with SER_RS485_ADDRB + flag in serial_rs485. Struct serial_rs485 has two additional flags and + fields for enabling receive and destination addresses. + + Address mode flags: + - SER_RS485_ADDRB: Enabled addressing mode (sets also ADDRB in termios). + - SER_RS485_ADDR_RECV: Receive (filter) address enabled. + - SER_RS485_ADDR_DEST: Set destination address. + + Address fields (enabled with corresponding SER_RS485_ADDR_* flag): + - addr_recv: Receive address. + - addr_dest: Destination address. + + Once a receive address is set, the communication can occur only with the + particular device and other peers are filtered out. It is left up to the + receiver side to enforce the filtering. Receive address will be cleared + if SER_RS485_ADDR_RECV is not set. + + Note: not all devices supporting RS485 support multipoint addressing. + +6. References ============= [1] include/uapi/linux/serial.h diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst index eb9c2d9a4f5f..17779a2772e5 100644 --- a/Documentation/fault-injection/fault-injection.rst +++ b/Documentation/fault-injection/fault-injection.rst @@ -169,6 +169,13 @@ configuration of fault-injection capabilities. default is 'N', setting it to 'Y' will disable disconnect injection on the RPC server. +- /sys/kernel/debug/fail_sunrpc/ignore-cache-wait: + + Format: { 'Y' | 'N' } + + default is 'N', setting it to 'Y' will disable cache wait + injection on the RPC server. + - /sys/kernel/debug/fail_function/inject: Format: { 'function-name' | '!function-name' | '' } diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index 98dc24f5c6f0..d0c09663dae8 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -336,6 +336,11 @@ discard_unit=%s Control discard unit, the argument can be "block", "segment" default, it is helpful for large sized SMR or ZNS devices to reduce memory cost by getting rid of fs metadata supports small discard. +memory=%s Control memory mode. This supports "normal" and "low" modes. + "low" mode is introduced to support low memory devices. + Because of the nature of low memory devices, in this mode, f2fs + will try to save memory sometimes by sacrificing performance. + "normal" mode is the default mode and same as before. ======================== ============================================================ Debugfs Entries diff --git a/Documentation/filesystems/fuse.rst b/Documentation/filesystems/fuse.rst index 8120c3c0cb4e..1e31e87aee68 100644 --- a/Documentation/filesystems/fuse.rst +++ b/Documentation/filesystems/fuse.rst @@ -279,7 +279,7 @@ How are requirements fulfilled? the filesystem or not. Note that the *ptrace* check is not strictly necessary to - prevent B/2/i, it is enough to check if mount owner has enough + prevent C/2/i, it is enough to check if mount owner has enough privilege to send signal to the process accessing the filesystem, since *SIGSTOP* can be used to get a similar effect. @@ -288,10 +288,29 @@ I think these limitations are unacceptable? If a sysadmin trusts the users enough, or can ensure through other measures, that system processes will never enter non-privileged -mounts, it can relax the last limitation with a 'user_allow_other' -config option. If this config option is set, the mounting user can -add the 'allow_other' mount option which disables the check for other -users' processes. +mounts, it can relax the last limitation in several ways: + + - With the 'user_allow_other' config option. If this config option is + set, the mounting user can add the 'allow_other' mount option which + disables the check for other users' processes. + + User namespaces have an unintuitive interaction with 'allow_other': + an unprivileged user - normally restricted from mounting with + 'allow_other' - could do so in a user namespace where they're + privileged. If any process could access such an 'allow_other' mount + this would give the mounting user the ability to manipulate + processes in user namespaces where they're unprivileged. For this + reason 'allow_other' restricts access to users in the same userns + or a descendant. + + - With the 'allow_sys_admin_access' module option. If this option is + set, super user's processes have unrestricted access to mounts + irrespective of allow_other setting or user namespace of the + mounting user. + +Note that both of these relaxations expose the system to potential +information leak or *DoS* as described in points B and C/2/i-ii in the +preceding section. Kernel - userspace interface ============================ diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index a7173843a294..7fb398649f51 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -672,7 +672,7 @@ Future kconfig work Work on kconfig is welcomed on both areas of clarifying semantics and on evaluating the use of a full SAT solver for it. A full SAT solver can be desirable to enable more complex dependency mappings and / or queries, -for instance on possible use case for a SAT solver could be that of handling +for instance one possible use case for a SAT solver could be that of handling the current known recursive dependency issues. It is not known if this would address such issues but such evaluation is desirable. If support for a full SAT solver proves too complex or that it cannot address recursive dependency issues diff --git a/Documentation/loongarch/introduction.rst b/Documentation/loongarch/introduction.rst index 216b3f390e80..6c9160c4e9be 100644 --- a/Documentation/loongarch/introduction.rst +++ b/Documentation/loongarch/introduction.rst @@ -221,7 +221,7 @@ I26 Opcode + I26L + I26H =========== ========================== Rd is the destination register operand, while Rj, Rk and Ra ("a" stands for -"additional") are the source register operands. I8/I12/I16/I21/I26 are +"additional") are the source register operands. I8/I12/I14/I16/I21/I26 are immediate operands of respective width. The longer I21 and I26 are stored in separate higher and lower parts in the instruction word, denoted by the "L" and "H" suffixes. diff --git a/Documentation/m68k/kernel-options.rst b/Documentation/m68k/kernel-options.rst index cabd9419740d..2008a20b4329 100644 --- a/Documentation/m68k/kernel-options.rst +++ b/Documentation/m68k/kernel-options.rst @@ -367,8 +367,8 @@ activated by a "external:" sub-option. 4.1.2) inverse -------------- -Invert the display. This affects both, text (consoles) and graphics -(X) display. Usually, the background is chosen to be black. With this +Invert the display. This affects only text consoles. +Usually, the background is chosen to be black. With this option, you can make the background white. 4.1.3) font diff --git a/Documentation/mm/highmem.rst b/Documentation/mm/highmem.rst index c9887f241c6c..0f731d9196b0 100644 --- a/Documentation/mm/highmem.rst +++ b/Documentation/mm/highmem.rst @@ -60,17 +60,40 @@ list shows them in order of preference of use. This function should be preferred, where feasible, over all the others. These mappings are thread-local and CPU-local, meaning that the mapping - can only be accessed from within this thread and the thread is bound the - CPU while the mapping is active. Even if the thread is preempted (since - preemption is never disabled by the function) the CPU can not be - unplugged from the system via CPU-hotplug until the mapping is disposed. + can only be accessed from within this thread and the thread is bound to the + CPU while the mapping is active. Although preemption is never disabled by + this function, the CPU can not be unplugged from the system via + CPU-hotplug until the mapping is disposed. It's valid to take pagefaults in a local kmap region, unless the context in which the local mapping is acquired does not allow it for other reasons. + As said, pagefaults and preemption are never disabled. There is no need to + disable preemption because, when context switches to a different task, the + maps of the outgoing task are saved and those of the incoming one are + restored. + kmap_local_page() always returns a valid virtual address and it is assumed that kunmap_local() will never fail. + On CONFIG_HIGHMEM=n kernels and for low memory pages this returns the + virtual address of the direct mapping. Only real highmem pages are + temporarily mapped. Therefore, users may call a plain page_address() + for pages which are known to not come from ZONE_HIGHMEM. However, it is + always safe to use kmap_local_page() / kunmap_local(). + + While it is significantly faster than kmap(), for the higmem case it + comes with restrictions about the pointers validity. Contrary to kmap() + mappings, the local mappings are only valid in the context of the caller + and cannot be handed to other contexts. This implies that users must + be absolutely sure to keep the use of the return address local to the + thread which mapped it. + + Most code can be designed to use thread local mappings. User should + therefore try to design their code to avoid the use of kmap() by mapping + pages in the same thread the address will be used and prefer + kmap_local_page(). + Nesting kmap_local_page() and kmap_atomic() mappings is allowed to a certain extent (up to KMAP_TYPE_NR) but their invocations have to be strictly ordered because the map implementation is stack based. See kmap_local_page() kdocs diff --git a/Documentation/mm/vmemmap_dedup.rst b/Documentation/mm/vmemmap_dedup.rst index c9c495f62d12..a4b12ff906c4 100644 --- a/Documentation/mm/vmemmap_dedup.rst +++ b/Documentation/mm/vmemmap_dedup.rst @@ -7,23 +7,25 @@ A vmemmap diet for HugeTLB and Device DAX HugeTLB ======= -The struct page structures (page structs) are used to describe a physical -page frame. By default, there is a one-to-one mapping from a page frame to -it's corresponding page struct. +This section is to explain how HugeTLB Vmemmap Optimization (HVO) works. + +The ``struct page`` structures are used to describe a physical page frame. By +default, there is a one-to-one mapping from a page frame to it's corresponding +``struct page``. HugeTLB pages consist of multiple base page size pages and is supported by many architectures. See Documentation/admin-guide/mm/hugetlbpage.rst for more details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB are currently supported. Since the base page size on x86 is 4KB, a 2MB HugeTLB page consists of 512 base pages and a 1GB HugeTLB page consists of 4096 base pages. -For each base page, there is a corresponding page struct. +For each base page, there is a corresponding ``struct page``. -Within the HugeTLB subsystem, only the first 4 page structs are used to -contain unique information about a HugeTLB page. __NR_USED_SUBPAGE provides -this upper limit. The only 'useful' information in the remaining page structs +Within the HugeTLB subsystem, only the first 4 ``struct page`` are used to +contain unique information about a HugeTLB page. ``__NR_USED_SUBPAGE`` provides +this upper limit. The only 'useful' information in the remaining ``struct page`` is the compound_head field, and this field is the same for all tail pages. -By removing redundant page structs for HugeTLB pages, memory can be returned +By removing redundant ``struct page`` for HugeTLB pages, memory can be returned to the buddy allocator for other uses. Different architectures support different HugeTLB pages. For example, the @@ -44,7 +46,7 @@ page. | | 64KB | 2MB | 512MB | 16GB | | +--------------+-----------+-----------+-----------+-----------+-----------+ -When the system boot up, every HugeTLB page has more than one struct page +When the system boot up, every HugeTLB page has more than one ``struct page`` structs which size is (unit: pages):: struct_size = HugeTLB_Size / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE @@ -74,10 +76,10 @@ Where n is how many pte entries which one page can contains. So the value of n is (PAGE_SIZE / sizeof(pte_t)). This optimization only supports 64-bit system, so the value of sizeof(pte_t) -is 8. And this optimization also applicable only when the size of struct page -is a power of two. In most cases, the size of struct page is 64 bytes (e.g. +is 8. And this optimization also applicable only when the size of ``struct page`` +is a power of two. In most cases, the size of ``struct page`` is 64 bytes (e.g. x86-64 and arm64). So if we use pmd level mapping for a HugeTLB page, the -size of struct page structs of it is 8 page frames which size depends on the +size of ``struct page`` structs of it is 8 page frames which size depends on the size of the base page. For the HugeTLB page of the pud level mapping, then:: @@ -86,7 +88,7 @@ For the HugeTLB page of the pud level mapping, then:: = PAGE_SIZE / 8 * 8 (pages) = PAGE_SIZE (pages) -Where the struct_size(pmd) is the size of the struct page structs of a +Where the struct_size(pmd) is the size of the ``struct page`` structs of a HugeTLB page of the pmd level mapping. E.g.: A 2MB HugeTLB page on x86_64 consists in 8 page frames while 1GB @@ -94,7 +96,7 @@ HugeTLB page consists in 4096. Next, we take the pmd level mapping of the HugeTLB page as an example to show the internal implementation of this optimization. There are 8 pages -struct page structs associated with a HugeTLB page which is pmd mapped. +``struct page`` structs associated with a HugeTLB page which is pmd mapped. Here is how things look before optimization:: @@ -122,10 +124,10 @@ Here is how things look before optimization:: +-----------+ The value of page->compound_head is the same for all tail pages. The first -page of page structs (page 0) associated with the HugeTLB page contains the 4 -page structs necessary to describe the HugeTLB. The only use of the remaining -pages of page structs (page 1 to page 7) is to point to page->compound_head. -Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of page structs +page of ``struct page`` (page 0) associated with the HugeTLB page contains the 4 +``struct page`` necessary to describe the HugeTLB. The only use of the remaining +pages of ``struct page`` (page 1 to page 7) is to point to page->compound_head. +Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of ``struct page`` will be used for each HugeTLB page. This will allow us to free the remaining 7 pages to the buddy allocator. @@ -167,13 +169,37 @@ entries that can be cached in a single TLB entry. The contiguous bit is used to increase the mapping size at the pmd and pte (last) level. So this type of HugeTLB page can be optimized only when its -size of the struct page structs is greater than 1 page. +size of the ``struct page`` structs is greater than **1** page. Notice: The head vmemmap page is not freed to the buddy allocator and all tail vmemmap pages are mapped to the head vmemmap page frame. So we can see -more than one struct page struct with PG_head (e.g. 8 per 2 MB HugeTLB page) -associated with each HugeTLB page. The compound_head() can handle this -correctly (more details refer to the comment above compound_head()). +more than one ``struct page`` struct with ``PG_head`` (e.g. 8 per 2 MB HugeTLB +page) associated with each HugeTLB page. The ``compound_head()`` can handle +this correctly. There is only **one** head ``struct page``, the tail +``struct page`` with ``PG_head`` are fake head ``struct page``. We need an +approach to distinguish between those two different types of ``struct page`` so +that ``compound_head()`` can return the real head ``struct page`` when the +parameter is the tail ``struct page`` but with ``PG_head``. The following code +snippet describes how to distinguish between real and fake head ``struct page``. + +.. code-block:: c + + if (test_bit(PG_head, &page->flags)) { + unsigned long head = READ_ONCE(page[1].compound_head); + + if (head & 1) { + if (head == (unsigned long)page + 1) + /* head struct page */ + else + /* tail struct page */ + } else { + /* head struct page */ + } + } + +We can safely access the field of the **page[1]** with ``PG_head`` because the +page is a compound page composed with at least two contiguous pages. +The implementation refers to ``page_fixed_fake_head()``. Device DAX ========== @@ -187,7 +213,7 @@ PMD_SIZE (2M on x86_64) and PUD_SIZE (1G on x86_64). The differences with HugeTLB are relatively minor. -It only use 3 page structs for storing all information as opposed +It only use 3 ``struct page`` for storing all information as opposed to 4 on HugeTLB pages. There's no remapping of vmemmap given that device-dax memory is not part of diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst index 53a18ff7cf23..7823a069a903 100644 --- a/Documentation/networking/bonding.rst +++ b/Documentation/networking/bonding.rst @@ -1982,15 +1982,6 @@ uses the response as an indication that the link is operating. This gives some assurance that traffic is actually flowing to and from one or more peers on the local network. -The ARP monitor relies on the device driver itself to verify -that traffic is flowing. In particular, the driver must keep up to -date the last receive time, dev->last_rx. Drivers that use NETIF_F_LLTX -flag must also update netdev_queue->trans_start. If they do not, then the -ARP monitor will immediately fail any slaves using that driver, and -those slaves will stay down. If networking monitoring (tcpdump, etc) -shows the ARP requests and replies on the network, then it may be that -your device driver is not updating last_rx and trans_start. - 7.2 Configuring Multiple ARP Targets ------------------------------------ diff --git a/Documentation/powerpc/elf_hwcaps.rst b/Documentation/powerpc/elf_hwcaps.rst new file mode 100644 index 000000000000..3366e5b18e67 --- /dev/null +++ b/Documentation/powerpc/elf_hwcaps.rst @@ -0,0 +1,231 @@ +.. _elf_hwcaps_powerpc: + +================== +POWERPC ELF HWCAPs +================== + +This document describes the usage and semantics of the powerpc ELF HWCAPs. + + +1. Introduction +--------------- + +Some hardware or software features are only available on some CPU +implementations, and/or with certain kernel configurations, but have no other +discovery mechanism available to userspace code. The kernel exposes the +presence of these features to userspace through a set of flags called HWCAPs, +exposed in the auxiliary vector. + +Userspace software can test for features by acquiring the AT_HWCAP or +AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant +flags are set, e.g.:: + + bool floating_point_is_present(void) + { + unsigned long HWCAPs = getauxval(AT_HWCAP); + if (HWCAPs & PPC_FEATURE_HAS_FPU) + return true; + + return false; + } + +Where software relies on a feature described by a HWCAP, it should check the +relevant HWCAP flag to verify that the feature is present before attempting to +make use of the feature. + +HWCAP is the preferred method to test for the presence of a feature rather +than probing through other means, which may not be reliable or may cause +unpredictable behaviour. + +Software that targets a particular platform does not necessarily have to +test for required or implied features. For example if the program requires +FPU, VMX, VSX, it is not necessary to test those HWCAPs, and it may be +impossible to do so if the compiler generates code requiring those features. + +2. Facilities +------------- + +The Power ISA uses the term "facility" to describe a class of instructions, +registers, interrupts, etc. The presence or absence of a facility indicates +whether this class is available to be used, but the specifics depend on the +ISA version. For example, if the VSX facility is available, the VSX +instructions that can be used differ between the v3.0B and v3.1B ISA +versions. + +3. Categories +------------- + +The Power ISA before v3.0 uses the term "category" to describe certain +classes of instructions and operating modes which may be optional or +mutually exclusive, the exact meaning of the HWCAP flag may depend on +context, e.g., the presence of the BOOKE feature implies that the server +category is not implemented. + +4. HWCAP allocation +------------------- + +HWCAPs are allocated as described in Power Architecture 64-Bit ELF V2 ABI +Specification (which will be reflected in the kernel's uapi headers). + +5. The HWCAPs exposed in AT_HWCAP +--------------------------------- + +PPC_FEATURE_32 + 32-bit CPU + +PPC_FEATURE_64 + 64-bit CPU (userspace may be running in 32-bit mode). + +PPC_FEATURE_601_INSTR + The processor is PowerPC 601. + Unused in the kernel since f0ed73f3fa2c ("powerpc: Remove PowerPC 601") + +PPC_FEATURE_HAS_ALTIVEC + Vector (aka Altivec, VMX) facility is available. + +PPC_FEATURE_HAS_FPU + Floating point facility is available. + +PPC_FEATURE_HAS_MMU + Memory management unit is present and enabled. + +PPC_FEATURE_HAS_4xxMAC + The processor is 40x or 44x family. + +PPC_FEATURE_UNIFIED_CACHE + The processor has a unified L1 cache for instructions and data, as + found in NXP e200. + Unused in the kernel since 39c8bf2b3cc1 ("powerpc: Retire e200 core (mpc555x processor)") + +PPC_FEATURE_HAS_SPE + Signal Processing Engine facility is available. + +PPC_FEATURE_HAS_EFP_SINGLE + Embedded Floating Point single precision operations are available. + +PPC_FEATURE_HAS_EFP_DOUBLE + Embedded Floating Point double precision operations are available. + +PPC_FEATURE_NO_TB + The timebase facility (mftb instruction) is not available. + This is a 601 specific HWCAP, so if it is known that the processor + running is not a 601, via other HWCAPs or other means, it is not + required to test this bit before using the timebase. + Unused in the kernel since f0ed73f3fa2c ("powerpc: Remove PowerPC 601") + +PPC_FEATURE_POWER4 + The processor is POWER4 or PPC970/FX/MP. + POWER4 support dropped from the kernel since 471d7ff8b51b ("powerpc/64s: Remove POWER4 support") + +PPC_FEATURE_POWER5 + The processor is POWER5. + +PPC_FEATURE_POWER5_PLUS + The processor is POWER5+. + +PPC_FEATURE_CELL + The processor is Cell. + +PPC_FEATURE_BOOKE + The processor implements the embedded category ("BookE") architecture. + +PPC_FEATURE_SMT + The processor implements SMT. + +PPC_FEATURE_ICACHE_SNOOP + The processor icache is coherent with the dcache, and instruction storage + can be made consistent with data storage for the purpose of executing + instructions with the sequence (as described in, e.g., POWER9 Processor + User's Manual, 4.6.2.2 Instruction Cache Block Invalidate (icbi)):: + + sync + icbi (to any address) + isync + +PPC_FEATURE_ARCH_2_05 + The processor supports the v2.05 userlevel architecture. Processors + supporting later architectures DO NOT set this feature. + +PPC_FEATURE_PA6T + The processor is PA6T. + +PPC_FEATURE_HAS_DFP + DFP facility is available. + +PPC_FEATURE_POWER6_EXT + The processor is POWER6. + +PPC_FEATURE_ARCH_2_06 + The processor supports the v2.06 userlevel architecture. Processors + supporting later architectures also set this feature. + +PPC_FEATURE_HAS_VSX + VSX facility is available. + +PPC_FEATURE_PSERIES_PERFMON_COMPAT + The processor supports architected PMU events in the range 0xE0-0xFF. + +PPC_FEATURE_TRUE_LE + The processor supports true little-endian mode. + +PPC_FEATURE_PPC_LE + The processor supports "PowerPC Little-Endian", that uses address + munging to make storage access appear to be little-endian, but the + data is stored in a different format that is unsuitable to be + accessed by other agents not running in this mode. + +6. The HWCAPs exposed in AT_HWCAP2 +---------------------------------- + +PPC_FEATURE2_ARCH_2_07 + The processor supports the v2.07 userlevel architecture. Processors + supporting later architectures also set this feature. + +PPC_FEATURE2_HTM + Transactional Memory feature is available. + +PPC_FEATURE2_DSCR + DSCR facility is available. + +PPC_FEATURE2_EBB + EBB facility is available. + +PPC_FEATURE2_ISEL + isel instruction is available. This is superseded by ARCH_2_07 and + later. + +PPC_FEATURE2_TAR + TAR facility is available. + +PPC_FEATURE2_VEC_CRYPTO + v2.07 crypto instructions are available. + +PPC_FEATURE2_HTM_NOSC + System calls fail if called in a transactional state, see + Documentation/powerpc/syscall64-abi.rst + +PPC_FEATURE2_ARCH_3_00 + The processor supports the v3.0B / v3.0C userlevel architecture. Processors + supporting later architectures also set this feature. + +PPC_FEATURE2_HAS_IEEE128 + IEEE 128-bit binary floating point is supported with VSX + quad-precision instructions and data types. + +PPC_FEATURE2_DARN + darn instruction is available. + +PPC_FEATURE2_SCV + The scv 0 instruction may be used for system calls, see + Documentation/powerpc/syscall64-abi.rst. + +PPC_FEATURE2_HTM_NO_SUSPEND + A limited Transactional Memory facility that does not support suspend is + available, see Documentation/powerpc/transactional_memory.rst. + +PPC_FEATURE2_ARCH_3_1 + The processor supports the v3.1 userlevel architecture. Processors + supporting later architectures also set this feature. + +PPC_FEATURE2_MMA + MMA facility is available. diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst index 0f7d3c495693..85e80e30160b 100644 --- a/Documentation/powerpc/index.rst +++ b/Documentation/powerpc/index.rst @@ -17,6 +17,7 @@ powerpc dawr-power9 dscr eeh-pci-error-recovery + elf_hwcaps elfnote firmware-assisted-dump hvcs diff --git a/Documentation/s390/index.rst b/Documentation/s390/index.rst index b10ca9192557..73c79bf586fd 100644 --- a/Documentation/s390/index.rst +++ b/Documentation/s390/index.rst @@ -12,6 +12,7 @@ s390 Architecture qeth s390dbf vfio-ap + vfio-ap-locking vfio-ccw zfcpdump common_io diff --git a/Documentation/s390/vfio-ap-locking.rst b/Documentation/s390/vfio-ap-locking.rst new file mode 100644 index 000000000000..0dfcdb562e21 --- /dev/null +++ b/Documentation/s390/vfio-ap-locking.rst @@ -0,0 +1,115 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================== +VFIO AP Locks Overview +====================== +This document describes the locks that are pertinent to the secure operation +of the vfio_ap device driver. Throughout this document, the following variables +will be used to denote instances of the structures herein described: + +.. code-block:: c + + struct ap_matrix_dev *matrix_dev; + struct ap_matrix_mdev *matrix_mdev; + struct kvm *kvm; + +The Matrix Devices Lock (drivers/s390/crypto/vfio_ap_private.h) +--------------------------------------------------------------- + +.. code-block:: c + + struct ap_matrix_dev { + ... + struct list_head mdev_list; + struct mutex mdevs_lock; + ... + } + +The Matrix Devices Lock (matrix_dev->mdevs_lock) is implemented as a global +mutex contained within the single object of struct ap_matrix_dev. This lock +controls access to all fields contained within each matrix_mdev +(matrix_dev->mdev_list). This lock must be held while reading from, writing to +or using the data from a field contained within a matrix_mdev instance +representing one of the vfio_ap device driver's mediated devices. + +The KVM Lock (include/linux/kvm_host.h) +--------------------------------------- + +.. code-block:: c + + struct kvm { + ... + struct mutex lock; + ... + } + +The KVM Lock (kvm->lock) controls access to the state data for a KVM guest. This +lock must be held by the vfio_ap device driver while one or more AP adapters, +domains or control domains are being plugged into or unplugged from the guest. + +The KVM pointer is stored in the in the matrix_mdev instance +(matrix_mdev->kvm = kvm) containing the state of the mediated device that has +been attached to the KVM guest. + +The Guests Lock (drivers/s390/crypto/vfio_ap_private.h) +----------------------------------------------------------- + +.. code-block:: c + + struct ap_matrix_dev { + ... + struct list_head mdev_list; + struct mutex guests_lock; + ... + } + +The Guests Lock (matrix_dev->guests_lock) controls access to the +matrix_mdev instances (matrix_dev->mdev_list) that represent mediated devices +that hold the state for the mediated devices that have been attached to a +KVM guest. This lock must be held: + +1. To control access to the KVM pointer (matrix_mdev->kvm) while the vfio_ap + device driver is using it to plug/unplug AP devices passed through to the KVM + guest. + +2. To add matrix_mdev instances to or remove them from matrix_dev->mdev_list. + This is necessary to ensure the proper locking order when the list is perused + to find an ap_matrix_mdev instance for the purpose of plugging/unplugging + AP devices passed through to a KVM guest. + + For example, when a queue device is removed from the vfio_ap device driver, + if the adapter is passed through to a KVM guest, it will have to be + unplugged. In order to figure out whether the adapter is passed through, + the matrix_mdev object to which the queue is assigned will have to be + found. The KVM pointer (matrix_mdev->kvm) can then be used to determine if + the mediated device is passed through (matrix_mdev->kvm != NULL) and if so, + to unplug the adapter. + +It is not necessary to take the Guests Lock to access the KVM pointer if the +pointer is not used to plug/unplug devices passed through to the KVM guest; +however, in this case, the Matrix Devices Lock (matrix_dev->mdevs_lock) must be +held in order to access the KVM pointer since it is set and cleared under the +protection of the Matrix Devices Lock. A case in point is the function that +handles interception of the PQAP(AQIC) instruction sub-function. This handler +needs to access the KVM pointer only for the purposes of setting or clearing IRQ +resources, so only the matrix_dev->mdevs_lock needs to be held. + +The PQAP Hook Lock (arch/s390/include/asm/kvm_host.h) +----------------------------------------------------- + +.. code-block:: c + + typedef int (*crypto_hook)(struct kvm_vcpu *vcpu); + + struct kvm_s390_crypto { + ... + struct rw_semaphore pqap_hook_rwsem; + crypto_hook *pqap_hook; + ... + }; + +The PQAP Hook Lock is a r/w semaphore that controls access to the function +pointer of the handler ``(*kvm->arch.crypto.pqap_hook)`` to invoke when the +PQAP(AQIC) instruction sub-function is intercepted by the host. The lock must be +held in write mode when pqap_hook value is set, and in read mode when the +pqap_hook function is called. diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst index f57ae621f33e..61a0a3c6c7b4 100644 --- a/Documentation/s390/vfio-ap.rst +++ b/Documentation/s390/vfio-ap.rst @@ -123,27 +123,24 @@ Let's now take a look at how AP instructions executed on a guest are interpreted by the hardware. A satellite control block called the Crypto Control Block (CRYCB) is attached to -our main hardware virtualization control block. The CRYCB contains three fields -to identify the adapters, usage domains and control domains assigned to the KVM -guest: +our main hardware virtualization control block. The CRYCB contains an AP Control +Block (APCB) that has three fields to identify the adapters, usage domains and +control domains assigned to the KVM guest: * The AP Mask (APM) field is a bit mask that identifies the AP adapters assigned - to the KVM guest. Each bit in the mask, from left to right (i.e. from most - significant to least significant bit in big endian order), corresponds to + to the KVM guest. Each bit in the mask, from left to right, corresponds to an APID from 0-255. If a bit is set, the corresponding adapter is valid for use by the KVM guest. * The AP Queue Mask (AQM) field is a bit mask identifying the AP usage domains - assigned to the KVM guest. Each bit in the mask, from left to right (i.e. from - most significant to least significant bit in big endian order), corresponds to - an AP queue index (APQI) from 0-255. If a bit is set, the corresponding queue - is valid for use by the KVM guest. + assigned to the KVM guest. Each bit in the mask, from left to right, + corresponds to an AP queue index (APQI) from 0-255. If a bit is set, the + corresponding queue is valid for use by the KVM guest. * The AP Domain Mask field is a bit mask that identifies the AP control domains assigned to the KVM guest. The ADM bit mask controls which domains can be changed by an AP command-request message sent to a usage domain from the - guest. Each bit in the mask, from left to right (i.e. from most significant to - least significant bit in big endian order), corresponds to a domain from + guest. Each bit in the mask, from left to right, corresponds to a domain from 0-255. If a bit is set, the corresponding domain can be modified by an AP command-request message sent to a usage domain. @@ -151,10 +148,10 @@ If you recall from the description of an AP Queue, AP instructions include an APQN to identify the AP queue to which an AP command-request message is to be sent (NQAP and PQAP instructions), or from which a command-reply message is to be received (DQAP instruction). The validity of an APQN is defined by the matrix -calculated from the APM and AQM; it is the cross product of all assigned adapter -numbers (APM) with all assigned queue indexes (AQM). For example, if adapters 1 -and 2 and usage domains 5 and 6 are assigned to a guest, the APQNs (1,5), (1,6), -(2,5) and (2,6) will be valid for the guest. +calculated from the APM and AQM; it is the Cartesian product of all assigned +adapter numbers (APM) with all assigned queue indexes (AQM). For example, if +adapters 1 and 2 and usage domains 5 and 6 are assigned to a guest, the APQNs +(1,5), (1,6), (2,5) and (2,6) will be valid for the guest. The APQNs can provide secure key functionality - i.e., a private key is stored on the adapter card for each of its domains - so each APQN must be assigned to @@ -192,7 +189,7 @@ The design introduces three new objects: 1. AP matrix device 2. VFIO AP device driver (vfio_ap.ko) -3. VFIO AP mediated matrix pass-through device +3. VFIO AP mediated pass-through device The VFIO AP device driver ------------------------- @@ -200,12 +197,13 @@ The VFIO AP (vfio_ap) device driver serves the following purposes: 1. Provides the interfaces to secure APQNs for exclusive use of KVM guests. -2. Sets up the VFIO mediated device interfaces to manage a mediated matrix +2. Sets up the VFIO mediated device interfaces to manage a vfio_ap mediated device and creates the sysfs interfaces for assigning adapters, usage domains, and control domains comprising the matrix for a KVM guest. -3. Configures the APM, AQM and ADM in the CRYCB referenced by a KVM guest's - SIE state description to grant the guest access to a matrix of AP devices +3. Configures the APM, AQM and ADM in the APCB contained in the CRYCB referenced + by a KVM guest's SIE state description to grant the guest access to a matrix + of AP devices Reserve APQNs for exclusive use of KVM guests --------------------------------------------- @@ -235,10 +233,10 @@ reserved:: | | 8 probe | | +--------^---------+ +--^--^------------+ 6 edit | | | - apmask | +-----------------------------+ | 9 mdev create + apmask | +-----------------------------+ | 11 mdev create aqmask | | 1 modprobe | +--------+-----+---+ +----------------+-+ +----------------+ - | | | |8 create | mediated | + | | | |10 create| mediated | | admin | | VFIO device core |---------> matrix | | + | | | device | +------+-+---------+ +--------^---------+ +--------^-------+ @@ -246,14 +244,14 @@ reserved:: | | 9 create vfio_ap-passthrough | | | +------------------------------+ | +-------------------------------------------------------------+ - 10 assign adapter/domain/control domain + 12 assign adapter/domain/control domain The process for reserving an AP queue for use by a KVM guest is: 1. The administrator loads the vfio_ap device driver 2. The vfio-ap driver during its initialization will register a single 'matrix' device with the device core. This will serve as the parent device for - all mediated matrix devices used to configure an AP matrix for a guest. + all vfio_ap mediated devices used to configure an AP matrix for a guest. 3. The /sys/devices/vfio_ap/matrix device is created by the device core 4. The vfio_ap device driver will register with the AP bus for AP queue devices of type 10 and higher (CEX4 and newer). The driver will provide the vfio_ap @@ -269,24 +267,24 @@ The process for reserving an AP queue for use by a KVM guest is: default zcrypt cex4queue driver. 8. The AP bus probes the vfio_ap device driver to bind the queues reserved for it. -9. The administrator creates a passthrough type mediated matrix device to be +9. The administrator creates a passthrough type vfio_ap mediated device to be used by a guest 10. The administrator assigns the adapters, usage domains and control domains to be exclusively used by a guest. Set up the VFIO mediated device interfaces ------------------------------------------ -The VFIO AP device driver utilizes the common interface of the VFIO mediated +The VFIO AP device driver utilizes the common interfaces of the VFIO mediated device core driver to: -* Register an AP mediated bus driver to add a mediated matrix device to and +* Register an AP mediated bus driver to add a vfio_ap mediated device to and remove it from a VFIO group. -* Create and destroy a mediated matrix device -* Add a mediated matrix device to and remove it from the AP mediated bus driver -* Add a mediated matrix device to and remove it from an IOMMU group +* Create and destroy a vfio_ap mediated device +* Add a vfio_ap mediated device to and remove it from the AP mediated bus driver +* Add a vfio_ap mediated device to and remove it from an IOMMU group The following high-level block diagram shows the main components and interfaces -of the VFIO AP mediated matrix device driver:: +of the VFIO AP mediated device driver:: +-------------+ | | @@ -343,7 +341,7 @@ matrix device. * device_api: the mediated device type's API * available_instances: - the number of mediated matrix passthrough devices + the number of vfio_ap mediated passthrough devices that can be created * device_api: specifies the VFIO API @@ -351,29 +349,37 @@ matrix device. This attribute group identifies the user-defined sysfs attributes of the mediated device. When a device is registered with the VFIO mediated device framework, the sysfs attribute files identified in the 'mdev_attr_groups' - structure will be created in the mediated matrix device's directory. The - sysfs attributes for a mediated matrix device are: + structure will be created in the vfio_ap mediated device's directory. The + sysfs attributes for a vfio_ap mediated device are: assign_adapter / unassign_adapter: Write-only attributes for assigning/unassigning an AP adapter to/from the - mediated matrix device. To assign/unassign an adapter, the APID of the - adapter is echoed to the respective attribute file. + vfio_ap mediated device. To assign/unassign an adapter, the APID of the + adapter is echoed into the respective attribute file. assign_domain / unassign_domain: Write-only attributes for assigning/unassigning an AP usage domain to/from - the mediated matrix device. To assign/unassign a domain, the domain - number of the usage domain is echoed to the respective attribute + the vfio_ap mediated device. To assign/unassign a domain, the domain + number of the usage domain is echoed into the respective attribute file. matrix: - A read-only file for displaying the APQNs derived from the cross product - of the adapter and domain numbers assigned to the mediated matrix device. + A read-only file for displaying the APQNs derived from the Cartesian + product of the adapter and domain numbers assigned to the vfio_ap mediated + device. + guest_matrix: + A read-only file for displaying the APQNs derived from the Cartesian + product of the adapter and domain numbers assigned to the APM and AQM + fields respectively of the KVM guest's CRYCB. This may differ from the + the APQNs assigned to the vfio_ap mediated device if any APQN does not + reference a queue device bound to the vfio_ap device driver (i.e., the + queue is not in the host's AP configuration). assign_control_domain / unassign_control_domain: Write-only attributes for assigning/unassigning an AP control domain - to/from the mediated matrix device. To assign/unassign a control domain, - the ID of the domain to be assigned/unassigned is echoed to the respective - attribute file. + to/from the vfio_ap mediated device. To assign/unassign a control domain, + the ID of the domain to be assigned/unassigned is echoed into the + respective attribute file. control_domains: A read-only file for displaying the control domain numbers assigned to the - mediated matrix device. + vfio_ap mediated device. * functions: @@ -383,45 +389,75 @@ matrix device. * Store the reference to the KVM structure for the guest using the mdev * Store the AP matrix configuration for the adapters, domains, and control domains assigned via the corresponding sysfs attributes files + * Store the AP matrix configuration for the adapters, domains and control + domains available to a guest. A guest may not be provided access to APQNs + referencing queue devices that do not exist, or are not bound to the + vfio_ap device driver. remove: - deallocates the mediated matrix device's ap_matrix_mdev structure. This will - be allowed only if a running guest is not using the mdev. + deallocates the vfio_ap mediated device's ap_matrix_mdev structure. + This will be allowed only if a running guest is not using the mdev. * callback interfaces - open: + open_device: The vfio_ap driver uses this callback to register a - VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the mdev matrix - device. The open is invoked when QEMU connects the VFIO iommu group - for the mdev matrix device to the MDEV bus. Access to the KVM structure used - to configure the KVM guest is provided via this callback. The KVM structure, - is used to configure the guest's access to the AP matrix defined via the - mediated matrix device's sysfs attribute files. - release: + VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the matrix mdev + devices. The open_device callback is invoked by userspace to connect the + VFIO iommu group for the matrix mdev device to the MDEV bus. Access to the + KVM structure used to configure the KVM guest is provided via this callback. + The KVM structure, is used to configure the guest's access to the AP matrix + defined via the vfio_ap mediated device's sysfs attribute files. + + close_device: unregisters the VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the - mdev matrix device and deconfigures the guest's AP matrix. + matrix mdev device and deconfigures the guest's AP matrix. -Configure the APM, AQM and ADM in the CRYCB -------------------------------------------- -Configuring the AP matrix for a KVM guest will be performed when the + ioctl: + this callback handles the VFIO_DEVICE_GET_INFO and VFIO_DEVICE_RESET ioctls + defined by the vfio framework. + +Configure the guest's AP resources +---------------------------------- +Configuring the AP resources for a KVM guest will be performed when the VFIO_GROUP_NOTIFY_SET_KVM notifier callback is invoked. The notifier -function is called when QEMU connects to KVM. The guest's AP matrix is -configured via it's CRYCB by: +function is called when userspace connects to KVM. The guest's AP resources are +configured via it's APCB by: * Setting the bits in the APM corresponding to the APIDs assigned to the - mediated matrix device via its 'assign_adapter' interface. + vfio_ap mediated device via its 'assign_adapter' interface. * Setting the bits in the AQM corresponding to the domains assigned to the - mediated matrix device via its 'assign_domain' interface. + vfio_ap mediated device via its 'assign_domain' interface. * Setting the bits in the ADM corresponding to the domain dIDs assigned to the - mediated matrix device via its 'assign_control_domains' interface. + vfio_ap mediated device via its 'assign_control_domains' interface. + +The linux device model precludes passing a device through to a KVM guest that +is not bound to the device driver facilitating its pass-through. Consequently, +an APQN that does not reference a queue device bound to the vfio_ap device +driver will not be assigned to a KVM guest's matrix. The AP architecture, +however, does not provide a means to filter individual APQNs from the guest's +matrix, so the adapters, domains and control domains assigned to vfio_ap +mediated device via its sysfs 'assign_adapter', 'assign_domain' and +'assign_control_domain' interfaces will be filtered before providing the AP +configuration to a guest: + +* The APIDs of the adapters, the APQIs of the domains and the domain numbers of + the control domains assigned to the matrix mdev that are not also assigned to + the host's AP configuration will be filtered. + +* Each APQN derived from the Cartesian product of the APIDs and APQIs assigned + to the vfio_ap mdev is examined and if any one of them does not reference a + queue device bound to the vfio_ap device driver, the adapter will not be + plugged into the guest (i.e., the bit corresponding to its APID will not be + set in the APM of the guest's APCB). The CPU model features for AP ----------------------------- -The AP stack relies on the presence of the AP instructions as well as two -facilities: The AP Facilities Test (APFT) facility; and the AP Query -Configuration Information (QCI) facility. These features/facilities are made -available to a KVM guest via the following CPU model features: +The AP stack relies on the presence of the AP instructions as well as three +facilities: The AP Facilities Test (APFT) facility; the AP Query +Configuration Information (QCI) facility; and the AP Queue Interruption Control +facility. These features/facilities are made available to a KVM guest via the +following CPU model features: 1. ap: Indicates whether the AP instructions are installed on the guest. This feature will be enabled by KVM only if the AP instructions are installed @@ -435,24 +471,28 @@ available to a KVM guest via the following CPU model features: can be made available to the guest only if it is available on the host (i.e., facility bit 12 is set). +4. apqi: Indicates AP Queue Interruption Control faclity is available on the + guest. This facility can be made available to the guest only if it is + available on the host (i.e., facility bit 65 is set). + Note: If the user chooses to specify a CPU model different than the 'host' model to QEMU, the CPU model features and facilities need to be turned on explicitly; for example:: - /usr/bin/qemu-system-s390x ... -cpu z13,ap=on,apqci=on,apft=on + /usr/bin/qemu-system-s390x ... -cpu z13,ap=on,apqci=on,apft=on,apqi=on A guest can be precluded from using AP features/facilities by turning them off explicitly; for example:: - /usr/bin/qemu-system-s390x ... -cpu host,ap=off,apqci=off,apft=off + /usr/bin/qemu-system-s390x ... -cpu host,ap=off,apqci=off,apft=off,apqi=off Note: If the APFT facility is turned off (apft=off) for the guest, the guest -will not see any AP devices. The zcrypt device drivers that register for type 10 -and newer AP devices - i.e., the cex4card and cex4queue device drivers - need -the APFT facility to ascertain the facilities installed on a given AP device. If -the APFT facility is not installed on the guest, then the probe of device -drivers will fail since only type 10 and newer devices can be configured for -guest use. +will not see any AP devices. The zcrypt device drivers on the guest that +register for type 10 and newer AP devices - i.e., the cex4card and cex4queue +device drivers - need the APFT facility to ascertain the facilities installed on +a given AP device. If the APFT facility is not installed on the guest, then no +adapter or domain devices will get created by the AP bus running on the +guest because only type 10 and newer devices can be configured for guest use. Example ======= @@ -471,7 +511,7 @@ CARD.DOMAIN TYPE MODE 05.00ab CEX5C CCA-Coproc 06 CEX5A Accelerator 06.0004 CEX5A Accelerator -06.00ab CEX5C CCA-Coproc +06.00ab CEX5A Accelerator =========== ===== ============ Guest2 @@ -479,9 +519,9 @@ Guest2 =========== ===== ============ CARD.DOMAIN TYPE MODE =========== ===== ============ -05 CEX5A Accelerator -05.0047 CEX5A Accelerator -05.00ff CEX5A Accelerator +05 CEX5C CCA-Coproc +05.0047 CEX5C CCA-Coproc +05.00ff CEX5C CCA-Coproc =========== ===== ============ Guest3 @@ -529,40 +569,56 @@ These are the steps: 2. Secure the AP queues to be used by the three guests so that the host can not access them. To secure them, there are two sysfs files that specify - bitmasks marking a subset of the APQN range as 'usable by the default AP - queue device drivers' or 'not usable by the default device drivers' and thus - available for use by the vfio_ap device driver'. The location of the sysfs - files containing the masks are:: + bitmasks marking a subset of the APQN range as usable only by the default AP + queue device drivers. All remaining APQNs are available for use by + any other device driver. The vfio_ap device driver is currently the only + non-default device driver. The location of the sysfs files containing the + masks are:: /sys/bus/ap/apmask /sys/bus/ap/aqmask The 'apmask' is a 256-bit mask that identifies a set of AP adapter IDs - (APID). Each bit in the mask, from left to right (i.e., from most significant - to least significant bit in big endian order), corresponds to an APID from - 0-255. If a bit is set, the APID is marked as usable only by the default AP - queue device drivers; otherwise, the APID is usable by the vfio_ap - device driver. + (APID). Each bit in the mask, from left to right, corresponds to an APID from + 0-255. If a bit is set, the APID belongs to the subset of APQNs marked as + available only to the default AP queue device drivers. The 'aqmask' is a 256-bit mask that identifies a set of AP queue indexes - (APQI). Each bit in the mask, from left to right (i.e., from most significant - to least significant bit in big endian order), corresponds to an APQI from - 0-255. If a bit is set, the APQI is marked as usable only by the default AP - queue device drivers; otherwise, the APQI is usable by the vfio_ap device - driver. + (APQI). Each bit in the mask, from left to right, corresponds to an APQI from + 0-255. If a bit is set, the APQI belongs to the subset of APQNs marked as + available only to the default AP queue device drivers. + + The Cartesian product of the APIDs corresponding to the bits set in the + apmask and the APQIs corresponding to the bits set in the aqmask comprise + the subset of APQNs that can be used only by the host default device drivers. + All other APQNs are available to the non-default device drivers such as the + vfio_ap driver. + + Take, for example, the following masks:: + + apmask: + 0x7d00000000000000000000000000000000000000000000000000000000000000 - Take, for example, the following mask:: + aqmask: + 0x8000000000000000000000000000000000000000000000000000000000000000 - 0x7dffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff + The masks indicate: - It indicates: + * Adapters 1, 2, 3, 4, 5, and 7 are available for use by the host default + device drivers. - 1, 2, 3, 4, 5, and 7-255 belong to the default drivers' pool, and 0 and 6 - belong to the vfio_ap device driver's pool. + * Domain 0 is available for use by the host default device drivers + + * The subset of APQNs available for use only by the default host device + drivers are: + + (1,0), (2,0), (3,0), (4.0), (5,0) and (7,0) + + * All other APQNs are available for use by the non-default device drivers. The APQN of each AP queue device assigned to the linux host is checked by the - AP bus against the set of APQNs derived from the cross product of APIDs - and APQIs marked as usable only by the default AP queue device drivers. If a + AP bus against the set of APQNs derived from the Cartesian product of APIDs + and APQIs marked as available to the default AP queue device drivers. If a match is detected, only the default AP queue device drivers will be probed; otherwise, the vfio_ap device driver will be probed. @@ -579,8 +635,7 @@ These are the steps: 0x4100000000000000000000000000000000000000000000000000000000000000 - Keep in mind that the mask reads from left to right (i.e., most - significant to least significant bit in big endian order), so the mask + Keep in mind that the mask reads from left to right, so the mask above identifies device numbers 1 and 7 (01000001). If the string is longer than the mask, the operation is terminated with @@ -626,11 +681,22 @@ These are the steps: default drivers pool: adapter 0-15, domain 1 alternate drivers pool: adapter 16-255, domains 0, 2-255 + **Note:** + Changing a mask such that one or more APQNs will be taken from a vfio_ap + mediated device (see below) will fail with an error (EBUSY). A message + is logged to the kernel ring buffer which can be viewed with the 'dmesg' + command. The output identifies each APQN flagged as 'in use' and identifies + the vfio_ap mediated device to which it is assigned; for example: + + Userspace may not re-assign queue 05.0054 already assigned to 62177883-f1bb-47f0-914d-32a22e3a8804 + Userspace may not re-assign queue 04.0054 already assigned to cef03c3c-903d-4ecc-9a83-40694cb8aee4 + Securing the APQNs for our example ---------------------------------- To secure the AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004, 06.0047, 06.00ab, and 06.00ff for use by the vfio_ap device driver, the corresponding - APQNs can either be removed from the default masks:: + APQNs can be removed from the default masks using either of the following + commands:: echo -5,-6 > /sys/bus/ap/apmask @@ -683,7 +749,7 @@ Securing the APQNs for our example /sys/devices/vfio_ap/matrix/ --- [mdev_supported_types] - ------ [vfio_ap-passthrough] (passthrough mediated matrix device type) + ------ [vfio_ap-passthrough] (passthrough vfio_ap mediated device type) --------- create --------- [devices] @@ -734,6 +800,9 @@ Securing the APQNs for our example ----------------unassign_control_domain ----------------unassign_domain + Note *****: The vfio_ap mdevs do not persist across reboots unless the + mdevctl tool is used to create and persist them. + 4. The administrator now needs to configure the matrixes for the mediated devices $uuid1 (for Guest1), $uuid2 (for Guest2) and $uuid3 (for Guest3). @@ -755,6 +824,10 @@ Securing the APQNs for our example cat matrix + To display the matrix that is or will be assigned to Guest1:: + + cat guest_matrix + This is how the matrix is configured for Guest2:: echo 5 > assign_adapter @@ -774,17 +847,24 @@ Securing the APQNs for our example higher than the maximum is specified, the operation will terminate with an error (ENODEV). - * All APQNs that can be derived from the adapter ID and the IDs of - the previously assigned domains must be bound to the vfio_ap device - driver. If no domains have yet been assigned, then there must be at least - one APQN with the specified APID bound to the vfio_ap driver. If no such - APQNs are bound to the driver, the operation will terminate with an - error (EADDRNOTAVAIL). + Note: The maximum adapter number can be obtained via the sysfs + /sys/bus/ap/ap_max_adapter_id attribute file. + + * Each APQN derived from the Cartesian product of the APID of the adapter + being assigned and the APQIs of the domains previously assigned: + + - Must only be available to the vfio_ap device driver as specified in the + sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even + one APQN is reserved for use by the host device driver, the operation + will terminate with an error (EADDRNOTAVAIL). + + - Must NOT be assigned to another vfio_ap mediated device. If even one APQN + is assigned to another vfio_ap mediated device, the operation will + terminate with an error (EBUSY). - No APQN that can be derived from the adapter ID and the IDs of the - previously assigned domains can be assigned to another mediated matrix - device. If an APQN is assigned to another mediated matrix device, the - operation will terminate with an error (EADDRINUSE). + - Must NOT be assigned while the sysfs /sys/bus/ap/apmask and + sys/bus/ap/aqmask attribute files are being edited or the operation may + terminate with an error (EBUSY). In order to successfully assign a domain: @@ -793,41 +873,50 @@ Securing the APQNs for our example higher than the maximum is specified, the operation will terminate with an error (ENODEV). - * All APQNs that can be derived from the domain ID and the IDs of - the previously assigned adapters must be bound to the vfio_ap device - driver. If no domains have yet been assigned, then there must be at least - one APQN with the specified APQI bound to the vfio_ap driver. If no such - APQNs are bound to the driver, the operation will terminate with an - error (EADDRNOTAVAIL). + Note: The maximum domain number can be obtained via the sysfs + /sys/bus/ap/ap_max_domain_id attribute file. + + * Each APQN derived from the Cartesian product of the APQI of the domain + being assigned and the APIDs of the adapters previously assigned: + + - Must only be available to the vfio_ap device driver as specified in the + sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even + one APQN is reserved for use by the host device driver, the operation + will terminate with an error (EADDRNOTAVAIL). + + - Must NOT be assigned to another vfio_ap mediated device. If even one APQN + is assigned to another vfio_ap mediated device, the operation will + terminate with an error (EBUSY). - No APQN that can be derived from the domain ID and the IDs of the - previously assigned adapters can be assigned to another mediated matrix - device. If an APQN is assigned to another mediated matrix device, the - operation will terminate with an error (EADDRINUSE). + - Must NOT be assigned while the sysfs /sys/bus/ap/apmask and + sys/bus/ap/aqmask attribute files are being edited or the operation may + terminate with an error (EBUSY). - In order to successfully assign a control domain, the domain number - specified must represent a value from 0 up to the maximum domain number - configured for the system. If a control domain number higher than the maximum - is specified, the operation will terminate with an error (ENODEV). + In order to successfully assign a control domain: + + * The domain number specified must represent a value from 0 up to the maximum + domain number configured for the system. If a control domain number higher + than the maximum is specified, the operation will terminate with an + error (ENODEV). 5. Start Guest1:: - /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on \ + /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \ -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid1 ... 7. Start Guest2:: - /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on \ + /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \ -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid2 ... 7. Start Guest3:: - /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on \ + /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \ -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid3 ... -When the guest is shut down, the mediated matrix devices may be removed. +When the guest is shut down, the vfio_ap mediated devices may be removed. -Using our example again, to remove the mediated matrix device $uuid1:: +Using our example again, to remove the vfio_ap mediated device $uuid1:: /sys/devices/vfio_ap/matrix/ --- [mdev_supported_types] @@ -840,26 +929,143 @@ Using our example again, to remove the mediated matrix device $uuid1:: echo 1 > remove -This will remove all of the mdev matrix device's sysfs structures including -the mdev device itself. To recreate and reconfigure the mdev matrix device, +This will remove all of the matrix mdev device's sysfs structures including +the mdev device itself. To recreate and reconfigure the matrix mdev device, all of the steps starting with step 3 will have to be performed again. Note -that the remove will fail if a guest using the mdev is still running. +that the remove will fail if a guest using the vfio_ap mdev is still running. -It is not necessary to remove an mdev matrix device, but one may want to +It is not necessary to remove a vfio_ap mdev, but one may want to remove it if no guest will use it during the remaining lifetime of the linux -host. If the mdev matrix device is removed, one may want to also reconfigure +host. If the vfio_ap mdev is removed, one may want to also reconfigure the pool of adapters and queues reserved for use by the default drivers. +Hot plug/unplug support: +======================== +An adapter, domain or control domain may be hot plugged into a running KVM +guest by assigning it to the vfio_ap mediated device being used by the guest if +the following conditions are met: + +* The adapter, domain or control domain must also be assigned to the host's + AP configuration. + +* Each APQN derived from the Cartesian product comprised of the APID of the + adapter being assigned and the APQIs of the domains assigned must reference a + queue device bound to the vfio_ap device driver. + +* To hot plug a domain, each APQN derived from the Cartesian product + comprised of the APQI of the domain being assigned and the APIDs of the + adapters assigned must reference a queue device bound to the vfio_ap device + driver. + +An adapter, domain or control domain may be hot unplugged from a running KVM +guest by unassigning it from the vfio_ap mediated device being used by the +guest. + +Over-provisioning of AP queues for a KVM guest: +=============================================== +Over-provisioning is defined herein as the assignment of adapters or domains to +a vfio_ap mediated device that do not reference AP devices in the host's AP +configuration. The idea here is that when the adapter or domain becomes +available, it will be automatically hot-plugged into the KVM guest using +the vfio_ap mediated device to which it is assigned as long as each new APQN +resulting from plugging it in references a queue device bound to the vfio_ap +device driver. + Limitations =========== -* The KVM/kernel interfaces do not provide a way to prevent restoring an APQN - to the default drivers pool of a queue that is still assigned to a mediated - device in use by a guest. It is incumbent upon the administrator to - ensure there is no mediated device in use by a guest to which the APQN is - assigned lest the host be given access to the private data of the AP queue - device such as a private key configured specifically for the guest. +Live guest migration is not supported for guests using AP devices without +intervention by a system administrator. Before a KVM guest can be migrated, +the vfio_ap mediated device must be removed. Unfortunately, it can not be +removed manually (i.e., echo 1 > /sys/devices/vfio_ap/matrix/$UUID/remove) while +the mdev is in use by a KVM guest. If the guest is being emulated by QEMU, +its mdev can be hot unplugged from the guest in one of two ways: + +1. If the KVM guest was started with libvirt, you can hot unplug the mdev via + the following commands: + + virsh detach-device <guestname> <path-to-device-xml> + + For example, to hot unplug mdev 62177883-f1bb-47f0-914d-32a22e3a8804 from + the guest named 'my-guest': + + virsh detach-device my-guest ~/config/my-guest-hostdev.xml + + The contents of my-guest-hostdev.xml: + +.. code-block:: xml + + <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ap'> + <source> + <address uuid='62177883-f1bb-47f0-914d-32a22e3a8804'/> + </source> + </hostdev> + + + virsh qemu-monitor-command <guest-name> --hmp "device-del <device-id>" + + For example, to hot unplug the vfio_ap mediated device identified on the + qemu command line with 'id=hostdev0' from the guest named 'my-guest': + +.. code-block:: sh + + virsh qemu-monitor-command my-guest --hmp "device_del hostdev0" + +2. A vfio_ap mediated device can be hot unplugged by attaching the qemu monitor + to the guest and using the following qemu monitor command: + + (QEMU) device-del id=<device-id> + + For example, to hot unplug the vfio_ap mediated device that was specified + on the qemu command line with 'id=hostdev0' when the guest was started: + + (QEMU) device-del id=hostdev0 + +After live migration of the KVM guest completes, an AP configuration can be +restored to the KVM guest by hot plugging a vfio_ap mediated device on the target +system into the guest in one of two ways: + +1. If the KVM guest was started with libvirt, you can hot plug a matrix mediated + device into the guest via the following virsh commands: + + virsh attach-device <guestname> <path-to-device-xml> + + For example, to hot plug mdev 62177883-f1bb-47f0-914d-32a22e3a8804 into + the guest named 'my-guest': + + virsh attach-device my-guest ~/config/my-guest-hostdev.xml + + The contents of my-guest-hostdev.xml: + +.. code-block:: xml + + <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ap'> + <source> + <address uuid='62177883-f1bb-47f0-914d-32a22e3a8804'/> + </source> + </hostdev> + + + virsh qemu-monitor-command <guest-name> --hmp \ + "device_add vfio-ap,sysfsdev=<path-to-mdev>,id=<device-id>" + + For example, to hot plug the vfio_ap mediated device + 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest named 'my-guest' with + device-id hostdev0: + + virsh qemu-monitor-command my-guest --hmp \ + "device_add vfio-ap,\ + sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\ + id=hostdev0" + +2. A vfio_ap mediated device can be hot plugged by attaching the qemu monitor + to the guest and using the following qemu monitor command: + + (qemu) device_add "vfio-ap,sysfsdev=<path-to-mdev>,id=<device-id>" -* Dynamically modifying the AP matrix for a running guest (which would amount to - hot(un)plug of AP devices for the guest) is currently not supported + For example, to plug the vfio_ap mediated device + 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest with the device-id + hostdev0: -* Live guest migration is not supported for guests using AP devices. + (QEMU) device-add "vfio-ap,\ + sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\ + id=hostdev0" diff --git a/Documentation/translations/zh_CN/loongarch/introduction.rst b/Documentation/translations/zh_CN/loongarch/introduction.rst index 11686ee0caeb..128878f5bb70 100644 --- a/Documentation/translations/zh_CN/loongarch/introduction.rst +++ b/Documentation/translations/zh_CN/loongarch/introduction.rst @@ -190,8 +190,8 @@ I26 Opcode + I26L + I26H =========== ========================== Opcode是指令操作码，Rj和Rk是源操作数（寄存器），Rd是目标操作数（寄存器），Ra是 -4R-type格式特有的附加操作数（寄存器）。I8/I12/I16/I21/I26分别是8位/12位/16位/ -21位/26位的立即数。其中较长的21位和26位立即数在指令字中被分割为高位部分与低位 +4R-type格式特有的附加操作数（寄存器）。I8/I12/I14/I16/I21/I26分别是8位/12位/14位/ +16位/21位/26位的立即数。其中较长的21位和26位立即数在指令字中被分割为高位部分与低位 部分，所以你们在这里的格式描述中能够看到I21L/I21H和I26L/I26H这样带后缀的表述。 指令列表 diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 9788b19f9ff7..abd7c32126ce 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -8262,15 +8262,15 @@ dump related UV data. Also the vcpu ioctl `KVM_S390_PV_CPU_COMMAND` is available and supports the `KVM_PV_DUMP_CPU` subcommand. 8.38 KVM_CAP_VM_DISABLE_NX_HUGE_PAGES ---------------------------- +------------------------------------- -:Capability KVM_CAP_VM_DISABLE_NX_HUGE_PAGES +:Capability: KVM_CAP_VM_DISABLE_NX_HUGE_PAGES :Architectures: x86 :Type: vm :Parameters: arg[0] must be 0. -:Returns 0 on success, -EPERM if the userspace process does not - have CAP_SYS_BOOT, -EINVAL if args[0] is not 0 or any vCPUs have been - created. +:Returns: 0 on success, -EPERM if the userspace process does not + have CAP_SYS_BOOT, -EINVAL if args[0] is not 0 or any vCPUs have been + created. This capability disables the NX huge pages mitigation for iTLB MULTIHIT. diff --git a/Documentation/watchdog/watchdog-parameters.rst b/Documentation/watchdog/watchdog-parameters.rst index 223c99361a30..29153eed6689 100644 --- a/Documentation/watchdog/watchdog-parameters.rst +++ b/Documentation/watchdog/watchdog-parameters.rst @@ -425,6 +425,18 @@ pnx833x_wdt: ------------------------------------------------- +pseries-wdt: + action: + Action taken when watchdog expires: 0 (power off), 1 (restart), + 2 (dump and restart). (default=1) + timeout: + Initial watchdog timeout in seconds. (default=60) + nowayout: + Watchdog cannot be stopped once started. + (default=kernel config parameter) + +------------------------------------------------- + rc32434_wdt: timeout: Watchdog timeout value, in seconds (default=20) |