diff options
Diffstat (limited to 'Documentation')
241 files changed, 9455 insertions, 1588 deletions
diff --git a/Documentation/ABI/testing/debugfs-scmi-raw b/Documentation/ABI/testing/debugfs-scmi-raw index 97678cc9535c..5847b96b3896 100644 --- a/Documentation/ABI/testing/debugfs-scmi-raw +++ b/Documentation/ABI/testing/debugfs-scmi-raw @@ -31,6 +31,42 @@ Description: SCMI Raw asynchronous message injection/snooping facility; write (receiving an EOF at each message boundary). Users: Debugging, any userspace test suite +What: /sys/kernel/debug/scmi/<n>/raw/message_poll +Date: June 2025 +KernelVersion: 6.16 +Contact: cristian.marussi@arm.com +Description: SCMI Raw message injection/snooping facility using polling mode; + write a complete SCMI command message (header included) in + little-endian binary format to have it sent to the configured + backend SCMI server for instance <n>, using polling mode on + the reception path. (if transport is polling capable) + Any subsequently received response can be read from this same + entry if it arrived within the configured timeout. + Each write to the entry causes one command request to be built + and sent while the replies are read back one message at time + (receiving an EOF at each message boundary). +Users: Debugging, any userspace test suite + +What: /sys/kernel/debug/scmi/<n>/raw/message_poll_async +Date: June 2025 +KernelVersion: 6.16 +Contact: cristian.marussi@arm.com +Description: SCMI Raw asynchronous message injection/snooping facility using + polling-mode; write a complete SCMI asynchronous command message + (header included) in little-endian binary format to have it sent + to the configured backend SCMI server for instance <n>, using + polling-mode on the reception path of the immediate part of the + asynchronous command. (if transport is polling capable) + Any subsequently received response can be read from this same + entry if it arrived within the configured timeout. + Any additional delayed response received afterwards can be read + from this same entry too if it arrived within the configured + timeout. + Each write to the entry causes one command request to be built + and sent while the replies are read back one message at time + (receiving an EOF at each message boundary). +Users: Debugging, any userspace test suite + What: /sys/kernel/debug/scmi/<n>/raw/errors Date: March 2023 KernelVersion: 6.3 @@ -115,3 +151,58 @@ Description: SCMI Raw asynchronous message injection/snooping facility; write exist only if the transport is configured to have more than one default channel. Users: Debugging, any userspace test suite + + +What: /sys/kernel/debug/scmi/<n>/raw/channels/<m>/message_poll +Date: June 2025 +KernelVersion: 6.16 +Contact: cristian.marussi@arm.com +Description: SCMI Raw message injection/snooping facility using polling mode; + write a complete SCMI command message (header included) in + little-endian binary format to have it sent to the configured + backend SCMI server for instance <n> through the <m> transport + channel, using polling mode on the reception path. + (if transport is polling capable) + Any subsequently received response can be read from this same + entry if it arrived on channel <m> within the configured + timeout. + Each write to the entry causes one command request to be built + and sent while the replies are read back one message at time + (receiving an EOF at each message boundary). + Channel identifier <m> matches the SCMI protocol number which + has been associated with this transport channel in the DT + description, with base protocol number 0x10 being the default + channel for this instance. + Note that these per-channel entries rooted at <..>/channels + exist only if the transport is configured to have more than + one default channel. +Users: Debugging, any userspace test suite + +What: /sys/kernel/debug/scmi/<n>/raw/channels/<m>/message_poll_async +Date: June 2025 +KernelVersion: 6.16 +Contact: cristian.marussi@arm.com +Description: SCMI Raw asynchronous message injection/snooping facility using + polling-mode; write a complete SCMI asynchronous command message + (header included) in little-endian binary format to have it sent + to the configured backend SCMI server for instance <n> through + the <m> transport channel, using polling mode on the reception + path of the immediate part of the asynchronous command. + (if transport is polling capable) + Any subsequently received response can be read from this same + entry if it arrived on channel <m> within the configured + timeout. + Any additional delayed response received afterwards can be read + from this same entry too if it arrived within the configured + timeout. + Each write to the entry causes one command request to be built + and sent while the replies are read back one message at time + (receiving an EOF at each message boundary). + Channel identifier <m> matches the SCMI protocol number which + has been associated with this transport channel in the DT + description, with base protocol number 0x10 being the default + channel for this instance. + Note that these per-channel entries rooted at <..>/channels + exist only if the transport is configured to have more than + one default channel. +Users: Debugging, any userspace test suite diff --git a/Documentation/ABI/testing/debugfs-turris-mox-rwtm b/Documentation/ABI/testing/debugfs-turris-mox-rwtm deleted file mode 100644 index 813987d5de4e..000000000000 --- a/Documentation/ABI/testing/debugfs-turris-mox-rwtm +++ /dev/null @@ -1,14 +0,0 @@ -What: /sys/kernel/debug/turris-mox-rwtm/do_sign -Date: Jun 2020 -KernelVersion: 5.8 -Contact: Marek Behún <kabel@kernel.org> -Description: - - ======= =========================================================== - (Write) Message to sign with the ECDSA private key stored in - device's OTP. The message must be exactly 64 bytes - (since this is intended for SHA-512 hashes). - (Read) The resulting signature, 136 bytes. This contains the - R and S values of the ECDSA signature, both in - big-endian format. - ======= =========================================================== diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 99bb3faf7a0e..6b4e8c7a963d 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -242,7 +242,7 @@ Description: decoding a Host Physical Address range. Note that this number may be elevated without any regionX objects active or even enumerated, as this may be due to decoders established by - platform firwmare or a previous kernel (kexec). + platform firmware or a previous kernel (kexec). What: /sys/bus/cxl/devices/decoderX.Y @@ -572,7 +572,7 @@ Description: What: /sys/bus/cxl/devices/regionZ/accessY/read_bandwidth - /sys/bus/cxl/devices/regionZ/accessY/write_banwidth + /sys/bus/cxl/devices/regionZ/accessY/write_bandwidth Date: Jan, 2024 KernelVersion: v6.9 Contact: linux-cxl@vger.kernel.org diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index 2e24ac3bd7ef..0313b82644f2 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led @@ -72,6 +72,12 @@ Description: /sys/class/leds/<led> once a given trigger is selected. For their documentation see `sysfs-class-led-trigger-*`. + Writing "none" removes the trigger for this LED. + + Writing "default" sets the trigger to the LED's default trigger + (which would often be configured in the device tree for the + hardware). + What: /sys/class/leds/<led>/inverted Date: January 2011 KernelVersion: 2.6.38 diff --git a/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm index ea5e5b489bc7..26741cb84504 100644 --- a/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm +++ b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm @@ -12,15 +12,6 @@ Contact: Marek Behún <kabel@kernel.org> Description: (Read) MAC addresses burned into eFuses of this Turris Mox board. Format: %pM -What: /sys/firmware/turris-mox-rwtm/pubkey -Date: August 2019 -KernelVersion: 5.4 -Contact: Marek Behún <kabel@kernel.org> -Description: (Read) ECDSA public key (in pubkey hex compressed form) computed - as pair to the ECDSA private key burned into eFuses of this - Turris Mox Board. - Format: string - What: /sys/firmware/turris-mox-rwtm/ram_size Date: August 2019 KernelVersion: 5.4 diff --git a/Documentation/ABI/testing/sysfs-kernel-hardlockup_count b/Documentation/ABI/testing/sysfs-kernel-hardlockup_count new file mode 100644 index 000000000000..dfdd4078b077 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-hardlockup_count @@ -0,0 +1,7 @@ +What: /sys/kernel/hardlockup_count +Date: May 2025 +KernelVersion: 6.16 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: + Shows how many times the system has detected a hard lockup since last boot. + Available only if CONFIG_HARDLOCKUP_DETECTOR is enabled. diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon index 293197f180ad..5697ab154c1f 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-damon +++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon @@ -283,6 +283,12 @@ Contact: SeongJae Park <sj@kernel.org> Description: Writing to and reading from this file sets and gets the current value of the goal metric. +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/nid +Date: Apr 2025 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the nid + parameter of the goal. + What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/weights/sz_permil Date: Mar 2022 Contact: SeongJae Park <sj@kernel.org> diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave b/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave index 0b7972de04e9..649c0e9b895c 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave +++ b/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave @@ -20,6 +20,35 @@ Description: Weight configuration interface for nodeN Minimum weight: 1 Maximum weight: 255 - Writing an empty string or `0` will reset the weight to the - system default. The system default may be set by the kernel - or drivers at boot or during hotplug events. + Writing invalid values (i.e. any values not in [1,255], + empty string, ...) will return -EINVAL. + + Changing the weight to a valid value will automatically + switch the system to manual mode as well. + +What: /sys/kernel/mm/mempolicy/weighted_interleave/auto +Date: May 2025 +Contact: Linux memory management mailing list <linux-mm@kvack.org> +Description: Auto-weighting configuration interface + + Configuration mode for weighted interleave. 'true' indicates + that the system is in auto mode, and a 'false' indicates that + the system is in manual mode. + + In auto mode, all node weights are re-calculated and overwritten + (visible via the nodeN interfaces) whenever new bandwidth data + is made available during either boot or hotplug events. + + In manual mode, node weights can only be updated by the user. + Note that nodes that are onlined with previously set weights + will reuse those weights. If they were not previously set or + are onlined with missing bandwidth data, the weights will use + a default weight of 1. + + Writing any true value string (e.g. Y or 1) will enable auto + mode, while writing any false value string (e.g. N or 0) will + enable manual mode. All other strings are ignored and will + return -EINVAL. + + Writing a new weight to a node directly via the nodeN interface + will also automatically switch the system to manual mode. diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-numa b/Documentation/ABI/testing/sysfs-kernel-mm-numa index 77e559d4ed80..90e375ff54cb 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-numa +++ b/Documentation/ABI/testing/sysfs-kernel-mm-numa @@ -16,9 +16,13 @@ Description: Enable/disable demoting pages during reclaim Allowing page migration during reclaim enables these systems to migrate pages from fast tiers to slow tiers when the fast tier is under pressure. This migration - is performed before swap. It may move data to a NUMA - node that does not fall into the cpuset of the - allocating process which might be construed to violate - the guarantees of cpusets. This should not be enabled - on systems which need strict cpuset location - guarantees. + is performed before swap if an eligible numa node is + present in cpuset.mems for the cgroup (or if cpuset v1 + is being used). If cpusets.mems changes at runtime, it + may move data to a NUMA node that does not fall into the + cpuset of the new cpusets.mems, which might be construed + to violate the guarantees of cpusets. Shared memory, + such as libraries, owned by another cgroup may still be + demoted and result in memory use on a node not present + in cpusets.mem. This should not be enabled on systems + which need strict cpuset location guarantees. diff --git a/Documentation/ABI/testing/sysfs-kernel-rcu_stall_count b/Documentation/ABI/testing/sysfs-kernel-rcu_stall_count new file mode 100644 index 000000000000..a4a97a7f4a4d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-rcu_stall_count @@ -0,0 +1,6 @@ +What: /sys/kernel/rcu_stall_count +Date: May 2025 +KernelVersion: 6.16 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: + Shows how many times the system has detected an RCU stall since last boot. diff --git a/Documentation/ABI/testing/sysfs-kernel-slab b/Documentation/ABI/testing/sysfs-kernel-slab index cd5fb8fa3ddf..658999be5164 100644 --- a/Documentation/ABI/testing/sysfs-kernel-slab +++ b/Documentation/ABI/testing/sysfs-kernel-slab @@ -2,7 +2,7 @@ What: /sys/kernel/slab Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The /sys/kernel/slab directory contains a snapshot of the internal state of the SLUB allocator for each cache. Certain @@ -14,7 +14,7 @@ What: /sys/kernel/slab/<cache>/aliases Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The aliases file is read-only and specifies how many caches have merged into this cache. @@ -23,7 +23,7 @@ What: /sys/kernel/slab/<cache>/align Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The align file is read-only and specifies the cache's object alignment in bytes. @@ -32,7 +32,7 @@ What: /sys/kernel/slab/<cache>/alloc_calls Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The alloc_calls file is read-only and lists the kernel code locations from which allocations for this cache were performed. @@ -43,7 +43,7 @@ What: /sys/kernel/slab/<cache>/alloc_fastpath Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The alloc_fastpath file shows how many objects have been allocated using the fast path. It can be written to clear the @@ -54,7 +54,7 @@ What: /sys/kernel/slab/<cache>/alloc_from_partial Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The alloc_from_partial file shows how many times a cpu slab has been full and it has been refilled by using a slab from the list @@ -66,7 +66,7 @@ What: /sys/kernel/slab/<cache>/alloc_refill Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The alloc_refill file shows how many times the per-cpu freelist was empty but there were objects available as the result of @@ -77,7 +77,7 @@ What: /sys/kernel/slab/<cache>/alloc_slab Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The alloc_slab file is shows how many times a new slab had to be allocated from the page allocator. It can be written to @@ -88,7 +88,7 @@ What: /sys/kernel/slab/<cache>/alloc_slowpath Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The alloc_slowpath file shows how many objects have been allocated using the slow path because of a refill or @@ -100,7 +100,7 @@ What: /sys/kernel/slab/<cache>/cache_dma Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The cache_dma file is read-only and specifies whether objects are from ZONE_DMA. @@ -110,7 +110,7 @@ What: /sys/kernel/slab/<cache>/cpu_slabs Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The cpu_slabs file is read-only and displays how many cpu slabs are active and their NUMA locality. @@ -119,7 +119,7 @@ What: /sys/kernel/slab/<cache>/cpuslab_flush Date: April 2009 KernelVersion: 2.6.31 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The file cpuslab_flush shows how many times a cache's cpu slabs have been flushed as the result of destroying or shrinking a @@ -132,7 +132,7 @@ What: /sys/kernel/slab/<cache>/ctor Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The ctor file is read-only and specifies the cache's object constructor function, which is invoked for each object when a @@ -142,7 +142,7 @@ What: /sys/kernel/slab/<cache>/deactivate_empty Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The deactivate_empty file shows how many times an empty cpu slab was deactivated. It can be written to clear the current count. @@ -152,7 +152,7 @@ What: /sys/kernel/slab/<cache>/deactivate_full Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The deactivate_full file shows how many times a full cpu slab was deactivated. It can be written to clear the current count. @@ -162,7 +162,7 @@ What: /sys/kernel/slab/<cache>/deactivate_remote_frees Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The deactivate_remote_frees file shows how many times a cpu slab has been deactivated and contained free objects that were freed @@ -173,7 +173,7 @@ What: /sys/kernel/slab/<cache>/deactivate_to_head Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The deactivate_to_head file shows how many times a partial cpu slab was deactivated and added to the head of its node's partial @@ -184,7 +184,7 @@ What: /sys/kernel/slab/<cache>/deactivate_to_tail Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The deactivate_to_tail file shows how many times a partial cpu slab was deactivated and added to the tail of its node's partial @@ -195,7 +195,7 @@ What: /sys/kernel/slab/<cache>/destroy_by_rcu Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The destroy_by_rcu file is read-only and specifies whether slabs (not objects) are freed by rcu. @@ -204,7 +204,7 @@ What: /sys/kernel/slab/<cache>/free_add_partial Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The free_add_partial file shows how many times an object has been freed in a full slab so that it had to added to its node's @@ -215,7 +215,7 @@ What: /sys/kernel/slab/<cache>/free_calls Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The free_calls file is read-only and lists the locations of object frees if slab debugging is enabled (see @@ -225,7 +225,7 @@ What: /sys/kernel/slab/<cache>/free_fastpath Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The free_fastpath file shows how many objects have been freed using the fast path because it was an object from the cpu slab. @@ -236,7 +236,7 @@ What: /sys/kernel/slab/<cache>/free_frozen Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The free_frozen file shows how many objects have been freed to a frozen slab (i.e. a remote cpu slab). It can be written to @@ -247,7 +247,7 @@ What: /sys/kernel/slab/<cache>/free_remove_partial Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The free_remove_partial file shows how many times an object has been freed to a now-empty slab so that it had to be removed from @@ -259,7 +259,7 @@ What: /sys/kernel/slab/<cache>/free_slab Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The free_slab file shows how many times an empty slab has been freed back to the page allocator. It can be written to clear @@ -270,7 +270,7 @@ What: /sys/kernel/slab/<cache>/free_slowpath Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The free_slowpath file shows how many objects have been freed using the slow path (i.e. to a full or partial slab). It can @@ -281,7 +281,7 @@ What: /sys/kernel/slab/<cache>/hwcache_align Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The hwcache_align file is read-only and specifies whether objects are aligned on cachelines. @@ -301,7 +301,7 @@ What: /sys/kernel/slab/<cache>/object_size Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The object_size file is read-only and specifies the cache's object size. @@ -310,7 +310,7 @@ What: /sys/kernel/slab/<cache>/objects Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The objects file is read-only and displays how many objects are active and from which nodes they are from. @@ -319,7 +319,7 @@ What: /sys/kernel/slab/<cache>/objects_partial Date: April 2008 KernelVersion: 2.6.26 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The objects_partial file is read-only and displays how many objects are on partial slabs and from which nodes they are @@ -329,7 +329,7 @@ What: /sys/kernel/slab/<cache>/objs_per_slab Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The file objs_per_slab is read-only and specifies how many objects may be allocated from a single slab of the order @@ -339,7 +339,7 @@ What: /sys/kernel/slab/<cache>/order Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The order file specifies the page order at which new slabs are allocated. It is writable and can be changed to increase the @@ -356,7 +356,7 @@ What: /sys/kernel/slab/<cache>/order_fallback Date: April 2008 KernelVersion: 2.6.26 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The order_fallback file shows how many times an allocation of a new slab has not been possible at the cache's order and instead @@ -369,7 +369,7 @@ What: /sys/kernel/slab/<cache>/partial Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The partial file is read-only and displays how long many partial slabs there are and how long each node's list is. @@ -378,7 +378,7 @@ What: /sys/kernel/slab/<cache>/poison Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The poison file specifies whether objects should be poisoned when a new slab is allocated. @@ -387,7 +387,7 @@ What: /sys/kernel/slab/<cache>/reclaim_account Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The reclaim_account file specifies whether the cache's objects are reclaimable (and grouped by their mobility). @@ -396,7 +396,7 @@ What: /sys/kernel/slab/<cache>/red_zone Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The red_zone file specifies whether the cache's objects are red zoned. @@ -405,7 +405,7 @@ What: /sys/kernel/slab/<cache>/remote_node_defrag_ratio Date: January 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The file remote_node_defrag_ratio specifies the percentage of times SLUB will attempt to refill the cpu slab with a partial @@ -419,7 +419,7 @@ What: /sys/kernel/slab/<cache>/sanity_checks Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The sanity_checks file specifies whether expensive checks should be performed on free and, at minimum, enables double free @@ -430,7 +430,7 @@ What: /sys/kernel/slab/<cache>/shrink Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The shrink file is used to reclaim unused slab cache memory from a cache. Empty per-cpu or partial slabs @@ -446,7 +446,7 @@ What: /sys/kernel/slab/<cache>/slab_size Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The slab_size file is read-only and specifies the object size with metadata (debugging information and alignment) in bytes. @@ -455,7 +455,7 @@ What: /sys/kernel/slab/<cache>/slabs Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The slabs file is read-only and displays how long many slabs there are (both cpu and partial) and from which nodes they are @@ -465,7 +465,7 @@ What: /sys/kernel/slab/<cache>/store_user Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The store_user file specifies whether the location of allocation or free should be tracked for a cache. @@ -474,7 +474,7 @@ What: /sys/kernel/slab/<cache>/total_objects Date: April 2008 KernelVersion: 2.6.26 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The total_objects file is read-only and displays how many total objects a cache has and from which nodes they are from. @@ -483,7 +483,7 @@ What: /sys/kernel/slab/<cache>/trace Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: The trace file specifies whether object allocations and frees should be traced. @@ -492,7 +492,7 @@ What: /sys/kernel/slab/<cache>/validate Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, - Christoph Lameter <cl@linux-foundation.org> + Christoph Lameter <cl@gentwo.org> Description: Writing to the validate file causes SLUB to traverse all of its cache's objects and check the validity of metadata. @@ -506,14 +506,14 @@ Description: What: /sys/kernel/slab/<cache>/slabs_cpu_partial Date: Aug 2011 -Contact: Christoph Lameter <cl@linux.com> +Contact: Christoph Lameter <cl@gentwo.org> Description: This read-only file shows the number of partialli allocated frozen slabs. What: /sys/kernel/slab/<cache>/cpu_partial Date: Aug 2011 -Contact: Christoph Lameter <cl@linux.com> +Contact: Christoph Lameter <cl@gentwo.org> Description: This read-only file shows the number of per cpu partial pages to keep around. diff --git a/Documentation/ABI/testing/sysfs-kernel-softlockup_count b/Documentation/ABI/testing/sysfs-kernel-softlockup_count new file mode 100644 index 000000000000..337ff5531b5f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-softlockup_count @@ -0,0 +1,7 @@ +What: /sys/kernel/softlockup_count +Date: May 2025 +KernelVersion: 6.16 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: + Shows how many times the system has detected a soft lockup since last boot. + Available only if CONFIG_SOFTLOCKUP_DETECTOR is enabled. diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst index 70b02f30013a..05301f03b717 100644 --- a/Documentation/admin-guide/README.rst +++ b/Documentation/admin-guide/README.rst @@ -259,7 +259,7 @@ Configuring the kernel Compiling the kernel -------------------- - - Make sure you have at least gcc 5.1 available. + - Make sure you have at least gcc 8.1 available. For more information, refer to :ref:`Documentation/process/changes.rst <changes>`. - Do a ``make`` to create a compressed kernel image. It is also possible to do diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst index 9bdb30901a93..3e273c1bb749 100644 --- a/Documentation/admin-guide/blockdev/zram.rst +++ b/Documentation/admin-guide/blockdev/zram.rst @@ -317,6 +317,26 @@ a single line of text and contains the following stats separated by whitespace: Optional Feature ================ +IDLE pages tracking +------------------- + +zram has built-in support for idle pages tracking (that is, allocated but +not used pages). This feature is useful for e.g. zram writeback and +recompression. In order to mark pages as idle, execute the following command:: + + echo all > /sys/block/zramX/idle + +This will mark all allocated zram pages as idle. The idle mark will be +removed only when the page (block) is accessed (e.g. overwritten or freed). +Additionally, when CONFIG_ZRAM_TRACK_ENTRY_ACTIME is enabled, pages can be +marked as idle based on how many seconds have passed since the last access to +a particular zram page:: + + echo 86400 > /sys/block/zramX/idle + +In this example, all pages which haven't been accessed in more than 86400 +seconds (one day) will be marked idle. + writeback --------- @@ -331,24 +351,7 @@ If admin wants to use incompressible page writeback, they could do it via:: echo huge > /sys/block/zramX/writeback -To use idle page writeback, first, user need to declare zram pages -as idle:: - - echo all > /sys/block/zramX/idle - -From now on, any pages on zram are idle pages. The idle mark -will be removed until someone requests access of the block. -IOW, unless there is access request, those pages are still idle pages. -Additionally, when CONFIG_ZRAM_TRACK_ENTRY_ACTIME is enabled pages can be -marked as idle based on how long (in seconds) it's been since they were -last accessed:: - - echo 86400 > /sys/block/zramX/idle - -In this example all pages which haven't been accessed in more than 86400 -seconds (one day) will be marked idle. - -Admin can request writeback of those idle pages at right timing via:: +Admin can request writeback of idle pages at right timing via:: echo idle > /sys/block/zramX/writeback @@ -369,6 +372,23 @@ they could write a page index into the interface:: echo "page_index=1251" > /sys/block/zramX/writeback +In Linux 6.16 this interface underwent some rework. First, the interface +now supports `key=value` format for all of its parameters (`type=huge_idle`, +etc.) Second, the support for `page_indexes` was introduced, which specify +`LOW-HIGH` range (or ranges) of pages to be written-back. This reduces the +number of syscalls, but more importantly this enables optimal post-processing +target selection strategy. Usage example:: + + echo "type=idle" > /sys/block/zramX/writeback + echo "page_indexes=1-100 page_indexes=200-300" > \ + /sys/block/zramX/writeback + +We also now permit multiple page_index params per call and a mix of +single pages and page ranges:: + + echo page_index=42 page_index=99 page_indexes=100-200 \ + page_indexes=500-700 > /sys/block/zramX/writeback + If there are lots of write IO with flash device, potentially, it has flash wearout problem so that admin needs to design write limitation to guarantee storage health for entire product life. @@ -482,8 +502,6 @@ attempt to recompress::: echo "type=huge_idle max_pages=42" > /sys/block/zramX/recompress -Recompression of idle pages requires memory tracking. - During re-compression for every page, that matches re-compression criteria, ZRAM iterates the list of registered alternative compression algorithms in order of their priorities. ZRAM stops either when re-compression was diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst index a3e2edb3d274..463f98453323 100644 --- a/Documentation/admin-guide/cgroup-v1/cgroups.rst +++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst @@ -13,7 +13,7 @@ Portions Copyright (c) 2004-2006 Silicon Graphics, Inc. Modified by Paul Jackson <pj@sgi.com> -Modified by Christoph Lameter <cl@linux.com> +Modified by Christoph Lameter <cl@gentwo.org> .. CONTENTS: diff --git a/Documentation/admin-guide/cgroup-v1/cpusets.rst b/Documentation/admin-guide/cgroup-v1/cpusets.rst index f401af5e2f09..c7909e5ac136 100644 --- a/Documentation/admin-guide/cgroup-v1/cpusets.rst +++ b/Documentation/admin-guide/cgroup-v1/cpusets.rst @@ -10,7 +10,7 @@ Written by Simon.Derr@bull.net - Portions Copyright (c) 2004-2006 Silicon Graphics, Inc. - Modified by Paul Jackson <pj@sgi.com> -- Modified by Christoph Lameter <cl@linux.com> +- Modified by Christoph Lameter <cl@gentwo.org> - Modified by Paul Menage <menage@google.com> - Modified by Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 1edc26622594..0cc35a14afbe 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1334,6 +1334,18 @@ PAGE_SIZE multiple when read back. monitors the limited cgroup to alleviate heavy reclaim pressure. + If memory.high is opened with O_NONBLOCK then the synchronous + reclaim is bypassed. This is useful for admin processes that + need to dynamically adjust the job's memory limits without + expending their own CPU resources on memory reclamation. The + job will trigger the reclaim and/or get throttled on its + next charge request. + + Please note that with O_NONBLOCK, there is a chance that the + target memory cgroup may take indefinite amount of time to + reduce usage below the limit due to delayed charge request or + busy-hitting its memory to slow down reclaim. + memory.max A read-write single value file which exists on non-root cgroups. The default is "max". @@ -1351,6 +1363,18 @@ PAGE_SIZE multiple when read back. Caller could retry them differently, return into userspace as -ENOMEM or silently ignore in cases like disk readahead. + If memory.max is opened with O_NONBLOCK, then the synchronous + reclaim and oom-kill are bypassed. This is useful for admin + processes that need to dynamically adjust the job's memory limits + without expending their own CPU resources on memory reclamation. + The job will trigger the reclaim and/or oom-kill on its next + charge request. + + Please note that with O_NONBLOCK, there is a chance that the + target memory cgroup may take indefinite amount of time to + reduce usage below the limit due to delayed charge request or + busy-hitting its memory to slow down reclaim. + memory.reclaim A write-only nested-keyed file which exists for all cgroups. @@ -1383,6 +1407,9 @@ The following nested keys are defined. same semantics as vm.swappiness applied to memcg reclaim with all the existing limitations and potential future extensions. + The valid range for swappiness is [0-200, max], setting + swappiness=max exclusively reclaims anonymous memory. + memory.peak A read-write single value file which exists on non-root cgroups. @@ -1705,6 +1732,12 @@ The following nested keys are defined. numa_hint_faults (npn) Number of NUMA hinting faults. + numa_task_migrated (npn) + Number of task migration by NUMA balancing. + + numa_task_swapped (npn) + Number of task swap by NUMA balancing. + pgdemote_kswapd Number of pages demoted by kswapd. diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst index 1f7f14c6e184..20fabdf6567e 100644 --- a/Documentation/admin-guide/kdump/kdump.rst +++ b/Documentation/admin-guide/kdump/kdump.rst @@ -547,6 +547,38 @@ from within add_taint() whenever the value set in this bitmask matches with the bit flag being set by add_taint(). This will cause a kdump to occur at the add_taint()->panic() call. +Write the dump file to encrypted disk volume +============================================ + +CONFIG_CRASH_DM_CRYPT can be enabled to support saving the dump file to an +encrypted disk volume (only x86_64 supported for now). User space can interact +with /sys/kernel/config/crash_dm_crypt_keys for setup, + +1. Tell the first kernel what logon keys are needed to unlock the disk volumes, + # Add key #1 + mkdir /sys/kernel/config/crash_dm_crypt_keys/7d26b7b4-e342-4d2d-b660-7426b0996720 + # Add key #1's description + echo cryptsetup:7d26b7b4-e342-4d2d-b660-7426b0996720 > /sys/kernel/config/crash_dm_crypt_keys/description + + # how many keys do we have now? + cat /sys/kernel/config/crash_dm_crypt_keys/count + 1 + + # Add key #2 in the same way + + # how many keys do we have now? + cat /sys/kernel/config/crash_dm_crypt_keys/count + 2 + + # To support CPU/memory hot-plugging, re-use keys already saved to reserved + # memory + echo true > /sys/kernel/config/crash_dm_crypt_key/reuse + +2. Load the dump-capture kernel + +3. After the dump-capture kerne get booted, restore the keys to user keyring + echo yes > /sys/kernel/crash_dm_crypt_keys/restore + Contact ======= diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index 0f714fc945ac..8cf4614385b7 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -331,8 +331,8 @@ PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision|PG_head_mask|P Page attributes. These flags are used to filter various unnecessary for dumping pages. -PAGE_BUDDY_MAPCOUNT_VALUE(~PG_buddy)|PAGE_OFFLINE_MAPCOUNT_VALUE(~PG_offline) ------------------------------------------------------------------------------ +PAGE_BUDDY_MAPCOUNT_VALUE(~PG_buddy)|PAGE_OFFLINE_MAPCOUNT_VALUE(~PG_offline)|PAGE_OFFLINE_MAPCOUNT_VALUE(~PG_unaccepted) +------------------------------------------------------------------------------------------------------------------------- More page attributes. These flags are used to filter various unnecessary for dumping pages. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index ea81784be981..a3ea40b22fb9 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2749,6 +2749,31 @@ kgdbwait [KGDB,EARLY] Stop kernel execution and enter the kernel debugger at the earliest opportunity. + kho= [KEXEC,EARLY] + Format: { "0" | "1" | "off" | "on" | "y" | "n" } + Enables or disables Kexec HandOver. + "0" | "off" | "n" - kexec handover is disabled + "1" | "on" | "y" - kexec handover is enabled + + kho_scratch= [KEXEC,EARLY] + Format: ll[KMG],mm[KMG],nn[KMG] | nn% + Defines the size of the KHO scratch region. The KHO + scratch regions are physically contiguous memory + ranges that can only be used for non-kernel + allocations. That way, even when memory is heavily + fragmented with handed over memory, the kexeced + kernel will always have enough contiguous ranges to + bootstrap itself. + + It is possible to specify the exact amount of + memory in the form of "ll[KMG],mm[KMG],nn[KMG]" + where the first parameter defines the size of a low + memory scratch area, the second parameter defines + the size of a global scratch area and the third + parameter defines the size of additional per-node + scratch areas. The form "nn%" defines scale factor + (in percents) of memory that was used during boot. + kmac= [MIPS] Korina ethernet MAC address. Configure the RouterBoard 532 series on-chip Ethernet adapter MAC address. diff --git a/Documentation/admin-guide/mm/damon/index.rst b/Documentation/admin-guide/mm/damon/index.rst index 33d37bb2fb4e..bc7e976120e0 100644 --- a/Documentation/admin-guide/mm/damon/index.rst +++ b/Documentation/admin-guide/mm/damon/index.rst @@ -1,12 +1,11 @@ .. SPDX-License-Identifier: GPL-2.0 -========================== -DAMON: Data Access MONitor -========================== +================================================================ +DAMON: Data Access MONitoring and Access-aware System Operations +================================================================ -:doc:`DAMON </mm/damon/index>` allows light-weight data access monitoring. -Using DAMON, users can analyze the memory access patterns of their systems and -optimize those. +:doc:`DAMON </mm/damon/index>` is a Linux kernel subsystem for efficient data +access monitoring and access-aware system operations. .. toctree:: :maxdepth: 2 diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index ced2013db3df..d960aba72b82 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -81,7 +81,7 @@ comma (","). │ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas>`/ms,bytes,reset_interval_ms,effective_bytes │ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil │ │ │ │ │ │ │ │ :ref:`goals <sysfs_schemes_quota_goals>`/nr_goals - │ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value + │ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid │ │ │ │ │ │ │ :ref:`watermarks <sysfs_watermarks>`/metric,interval_us,high,mid,low │ │ │ │ │ │ │ :ref:`{core_,ops_,}filters <sysfs_filters>`/nr_filters │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx,min,max @@ -390,11 +390,11 @@ number (``N``) to the file creates the number of child directories named ``0`` to ``N-1``. Each directory represents each goal and current achievement. Among the multiple feedback, the best one is used. -Each goal directory contains three files, namely ``target_metric``, -``target_value`` and ``current_value``. Users can set and get the three -parameters for the quota auto-tuning goals that specified on the :ref:`design -doc <damon_design_damos_quotas_auto_tuning>` by writing to and reading from each -of the files. Note that users should further write +Each goal directory contains four files, namely ``target_metric``, +``target_value``, ``current_value`` and ``nid``. Users can set and get the +four parameters for the quota auto-tuning goals that specified on the +:ref:`design doc <damon_design_damos_quotas_auto_tuning>` by writing to and +reading from each of the files. Note that users should further write ``commit_schemes_quota_goals`` to the ``state`` file of the :ref:`kdamond directory <sysfs_kdamond>` to pass the feedback to DAMON. diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst index 8b35795b664b..2d2f6c222308 100644 --- a/Documentation/admin-guide/mm/index.rst +++ b/Documentation/admin-guide/mm/index.rst @@ -42,3 +42,4 @@ the Linux memory management. transhuge userfaultfd zswap + kho diff --git a/Documentation/admin-guide/mm/kho.rst b/Documentation/admin-guide/mm/kho.rst new file mode 100644 index 000000000000..6dc18ed4b886 --- /dev/null +++ b/Documentation/admin-guide/mm/kho.rst @@ -0,0 +1,115 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +==================== +Kexec Handover Usage +==================== + +Kexec HandOver (KHO) is a mechanism that allows Linux to preserve memory +regions, which could contain serialized system states, across kexec. + +This document expects that you are familiar with the base KHO +:ref:`concepts <kho-concepts>`. If you have not read +them yet, please do so now. + +Prerequisites +============= + +KHO is available when the kernel is compiled with ``CONFIG_KEXEC_HANDOVER`` +set to y. Every KHO producer may have its own config option that you +need to enable if you would like to preserve their respective state across +kexec. + +To use KHO, please boot the kernel with the ``kho=on`` command line +parameter. You may use ``kho_scratch`` parameter to define size of the +scratch regions. For example ``kho_scratch=16M,512M,256M`` will reserve a +16 MiB low memory scratch area, a 512 MiB global scratch region, and 256 MiB +per NUMA node scratch regions on boot. + +Perform a KHO kexec +=================== + +First, before you perform a KHO kexec, you need to move the system into +the :ref:`KHO finalization phase <kho-finalization-phase>` :: + + $ echo 1 > /sys/kernel/debug/kho/out/finalize + +After this command, the KHO FDT is available in +``/sys/kernel/debug/kho/out/fdt``. Other subsystems may also register +their own preserved sub FDTs under +``/sys/kernel/debug/kho/out/sub_fdts/``. + +Next, load the target payload and kexec into it. It is important that you +use the ``-s`` parameter to use the in-kernel kexec file loader, as user +space kexec tooling currently has no support for KHO with the user space +based file loader :: + + # kexec -l /path/to/bzImage --initrd /path/to/initrd -s + # kexec -e + +The new kernel will boot up and contain some of the previous kernel's state. + +For example, if you used ``reserve_mem`` command line parameter to create +an early memory reservation, the new kernel will have that memory at the +same physical address as the old kernel. + +Abort a KHO exec +================ + +You can move the system out of KHO finalization phase again by calling :: + + $ echo 0 > /sys/kernel/debug/kho/out/active + +After this command, the KHO FDT is no longer available in +``/sys/kernel/debug/kho/out/fdt``. + +debugfs Interfaces +================== + +Currently KHO creates the following debugfs interfaces. Notice that these +interfaces may change in the future. They will be moved to sysfs once KHO is +stabilized. + +``/sys/kernel/debug/kho/out/finalize`` + Kexec HandOver (KHO) allows Linux to transition the state of + compatible drivers into the next kexec'ed kernel. To do so, + device drivers will instruct KHO to preserve memory regions, + which could contain serialized kernel state. + While the state is serialized, they are unable to perform + any modifications to state that was serialized, such as + handed over memory allocations. + + When this file contains "1", the system is in the transition + state. When contains "0", it is not. To switch between the + two states, echo the respective number into this file. + +``/sys/kernel/debug/kho/out/fdt`` + When KHO state tree is finalized, the kernel exposes the + flattened device tree blob that carries its current KHO + state in this file. Kexec user space tooling can use this + as input file for the KHO payload image. + +``/sys/kernel/debug/kho/out/scratch_len`` + Lengths of KHO scratch regions, which are physically contiguous + memory regions that will always stay available for future kexec + allocations. Kexec user space tools can use this file to determine + where it should place its payload images. + +``/sys/kernel/debug/kho/out/scratch_phys`` + Physical locations of KHO scratch regions. Kexec user space tools + can use this file in conjunction to scratch_phys to determine where + it should place its payload images. + +``/sys/kernel/debug/kho/out/sub_fdts/`` + In the KHO finalization phase, KHO producers register their own + FDT blob under this directory. + +``/sys/kernel/debug/kho/in/fdt`` + When the kernel was booted with Kexec HandOver (KHO), + the state tree that carries metadata about the previous + kernel's state is in this file in the format of flattened + device tree. This file may disappear when all consumers of + it finished to interpret their metadata. + +``/sys/kernel/debug/kho/in/sub_fdts/`` + Similar to ``kho/out/sub_fdts/``, but contains sub FDT blobs + of KHO producers passed from the old kernel. diff --git a/Documentation/admin-guide/mm/multigen_lru.rst b/Documentation/admin-guide/mm/multigen_lru.rst index 33e068830497..9cb54b4ff5d9 100644 --- a/Documentation/admin-guide/mm/multigen_lru.rst +++ b/Documentation/admin-guide/mm/multigen_lru.rst @@ -151,8 +151,9 @@ generations less than or equal to ``min_gen_nr``. ``min_gen_nr`` should be less than ``max_gen_nr-1``, since ``max_gen_nr`` and ``max_gen_nr-1`` are not fully aged (equivalent to the active list) and therefore cannot be evicted. ``swappiness`` -overrides the default value in ``/proc/sys/vm/swappiness``. -``nr_to_reclaim`` limits the number of pages to evict. +overrides the default value in ``/proc/sys/vm/swappiness`` and the valid +range is [0-200, max], with max being exclusively used for the reclamation +of anonymous memory. ``nr_to_reclaim`` limits the number of pages to evict. A typical use case is that a job scheduler runs this command before it tries to land a new job on a server. If it fails to materialize enough diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst index afce291649dd..e60e9211fd9b 100644 --- a/Documentation/admin-guide/mm/pagemap.rst +++ b/Documentation/admin-guide/mm/pagemap.rst @@ -250,6 +250,7 @@ Following flags about pages are currently supported: - ``PAGE_IS_PFNZERO`` - Page has zero PFN - ``PAGE_IS_HUGE`` - Page is PMD-mapped THP or Hugetlb backed - ``PAGE_IS_SOFT_DIRTY`` - Page is soft-dirty +- ``PAGE_IS_GUARD`` - Page is a part of a guard region The ``struct pm_scan_arg`` is used as the argument of the IOCTL. diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index d385985b305f..9bef46151d53 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -132,6 +132,12 @@ to latency spikes in unsuspecting applications. The kernel employs various heuristics to avoid wasting CPU cycles if it detects that proactive compaction is not being effective. +Setting the value above 80 will, in addition to lowering the acceptable level +of fragmentation, make the compaction code more sensitive to increases in +fragmentation, i.e. compaction will trigger more often, but reduce +fragmentation by a smaller amount. +This makes the fragmentation level more stable over time. + Be careful when setting it to extreme values like 100, as that may cause excessive background compaction activity. diff --git a/Documentation/arch/openrisc/openrisc_port.rst b/Documentation/arch/openrisc/openrisc_port.rst index a8f307a3b499..60b0a9e51d70 100644 --- a/Documentation/arch/openrisc/openrisc_port.rst +++ b/Documentation/arch/openrisc/openrisc_port.rst @@ -40,6 +40,12 @@ Build the Linux kernel as usual:: make ARCH=openrisc CROSS_COMPILE="or1k-linux-" defconfig make ARCH=openrisc CROSS_COMPILE="or1k-linux-" +If you want to embed initramfs in the kernel, also pass ``CONFIG_INITRAMFS_SOURCE``. For example:: + + make ARCH=openrisc CROSS_COMPILE="or1k-linux-" CONFIG_INITRAMFS_SOURCE="path/to/rootfs path/to/devnodes" + +For more information on this, please check Documentation/filesystems/ramfs-rootfs-initramfs.rst. + 3) Running on FPGA (optional) The OpenRISC community typically uses FuseSoC to manage building and programming diff --git a/Documentation/core-api/folio_queue.rst b/Documentation/core-api/folio_queue.rst index 1fe7a9bc4b8d..83cfbc157e49 100644 --- a/Documentation/core-api/folio_queue.rst +++ b/Documentation/core-api/folio_queue.rst @@ -151,19 +151,16 @@ The marks can be set by:: void folioq_mark(struct folio_queue *folioq, unsigned int slot); void folioq_mark2(struct folio_queue *folioq, unsigned int slot); - void folioq_mark3(struct folio_queue *folioq, unsigned int slot); Cleared by:: void folioq_unmark(struct folio_queue *folioq, unsigned int slot); void folioq_unmark2(struct folio_queue *folioq, unsigned int slot); - void folioq_unmark3(struct folio_queue *folioq, unsigned int slot); And the marks can be queried by:: bool folioq_is_marked(const struct folio_queue *folioq, unsigned int slot); bool folioq_is_marked2(const struct folio_queue *folioq, unsigned int slot); - bool folioq_is_marked3(const struct folio_queue *folioq, unsigned int slot); The marks can be used for any purpose and are not interpreted by this API. diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index e9789bd381d8..7a4ca18ca6e2 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -115,6 +115,7 @@ more memory-management documentation in Documentation/mm/index.rst. pin_user_pages boot-time-mm gfp_mask-from-fs-io + kho/index Interfaces for kernel debugging =============================== diff --git a/Documentation/core-api/kho/bindings/kho.yaml b/Documentation/core-api/kho/bindings/kho.yaml new file mode 100644 index 000000000000..11e8ab7b219d --- /dev/null +++ b/Documentation/core-api/kho/bindings/kho.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +title: Kexec HandOver (KHO) root tree + +maintainers: + - Mike Rapoport <rppt@kernel.org> + - Changyuan Lyu <changyuanl@google.com> + +description: | + System memory preserved by KHO across kexec. + +properties: + compatible: + enum: + - kho-v1 + + preserved-memory-map: + description: | + physical address (u64) of an in-memory structure describing all preserved + folios and memory ranges. + +patternProperties: + "$[0-9a-f_]+^": + $ref: sub-fdt.yaml# + description: physical address of a KHO user's own FDT. + +required: + - compatible + - preserved-memory-map + +additionalProperties: false + +examples: + - | + kho { + compatible = "kho-v1"; + preserved-memory-map = <0xf0be16 0x1000000>; + + memblock { + fdt = <0x80cc16 0x1000000>; + }; + }; diff --git a/Documentation/core-api/kho/bindings/memblock/memblock.yaml b/Documentation/core-api/kho/bindings/memblock/memblock.yaml new file mode 100644 index 000000000000..d388c28eb91d --- /dev/null +++ b/Documentation/core-api/kho/bindings/memblock/memblock.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +title: Memblock reserved memory + +maintainers: + - Mike Rapoport <rppt@kernel.org> + +description: | + Memblock can serialize its current memory reservations created with + reserve_mem command line option across kexec through KHO. + The post-KHO kernel can then consume these reservations and they are + guaranteed to have the same physical address. + +properties: + compatible: + enum: + - reserve-mem-v1 + +patternProperties: + "$[0-9a-f_]+^": + $ref: reserve-mem.yaml# + description: reserved memory regions + +required: + - compatible + +additionalProperties: false + +examples: + - | + memblock { + compatible = "memblock-v1"; + n1 { + compatible = "reserve-mem-v1"; + start = <0xc06b 0x4000000>; + size = <0x04 0x00>; + }; + }; diff --git a/Documentation/core-api/kho/bindings/memblock/reserve-mem.yaml b/Documentation/core-api/kho/bindings/memblock/reserve-mem.yaml new file mode 100644 index 000000000000..10282d3d1bcd --- /dev/null +++ b/Documentation/core-api/kho/bindings/memblock/reserve-mem.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +title: Memblock reserved memory regions + +maintainers: + - Mike Rapoport <rppt@kernel.org> + +description: | + Memblock can serialize its current memory reservations created with + reserve_mem command line option across kexec through KHO. + This object describes each such region. + +properties: + compatible: + enum: + - reserve-mem-v1 + + start: + description: | + physical address (u64) of the reserved memory region. + + size: + description: | + size (u64) of the reserved memory region. + +required: + - compatible + - start + - size + +additionalProperties: false + +examples: + - | + n1 { + compatible = "reserve-mem-v1"; + start = <0xc06b 0x4000000>; + size = <0x04 0x00>; + }; diff --git a/Documentation/core-api/kho/bindings/sub-fdt.yaml b/Documentation/core-api/kho/bindings/sub-fdt.yaml new file mode 100644 index 000000000000..b9a3d2d24850 --- /dev/null +++ b/Documentation/core-api/kho/bindings/sub-fdt.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +title: KHO users' FDT address + +maintainers: + - Mike Rapoport <rppt@kernel.org> + - Changyuan Lyu <changyuanl@google.com> + +description: | + Physical address of an FDT blob registered by a KHO user. + +properties: + fdt: + description: | + physical address (u64) of an FDT blob. + +required: + - fdt + +additionalProperties: false + +examples: + - | + memblock { + fdt = <0x80cc16 0x1000000>; + }; diff --git a/Documentation/core-api/kho/concepts.rst b/Documentation/core-api/kho/concepts.rst new file mode 100644 index 000000000000..36d5c05cfb30 --- /dev/null +++ b/Documentation/core-api/kho/concepts.rst @@ -0,0 +1,74 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later +.. _kho-concepts: + +======================= +Kexec Handover Concepts +======================= + +Kexec HandOver (KHO) is a mechanism that allows Linux to preserve memory +regions, which could contain serialized system states, across kexec. + +It introduces multiple concepts: + +KHO FDT +======= + +Every KHO kexec carries a KHO specific flattened device tree (FDT) blob +that describes preserved memory regions. These regions contain either +serialized subsystem states, or in-memory data that shall not be touched +across kexec. After KHO, subsystems can retrieve and restore preserved +memory regions from KHO FDT. + +KHO only uses the FDT container format and libfdt library, but does not +adhere to the same property semantics that normal device trees do: Properties +are passed in native endianness and standardized properties like ``regs`` and +``ranges`` do not exist, hence there are no ``#...-cells`` properties. + +KHO is still under development. The FDT schema is unstable and would change +in the future. + +Scratch Regions +=============== + +To boot into kexec, we need to have a physically contiguous memory range that +contains no handed over memory. Kexec then places the target kernel and initrd +into that region. The new kernel exclusively uses this region for memory +allocations before during boot up to the initialization of the page allocator. + +We guarantee that we always have such regions through the scratch regions: On +first boot KHO allocates several physically contiguous memory regions. Since +after kexec these regions will be used by early memory allocations, there is a +scratch region per NUMA node plus a scratch region to satisfy allocations +requests that do not require particular NUMA node assignment. +By default, size of the scratch region is calculated based on amount of memory +allocated during boot. The ``kho_scratch`` kernel command line option may be +used to explicitly define size of the scratch regions. +The scratch regions are declared as CMA when page allocator is initialized so +that their memory can be used during system lifetime. CMA gives us the +guarantee that no handover pages land in that region, because handover pages +must be at a static physical memory location and CMA enforces that only +movable pages can be located inside. + +After KHO kexec, we ignore the ``kho_scratch`` kernel command line option and +instead reuse the exact same region that was originally allocated. This allows +us to recursively execute any amount of KHO kexecs. Because we used this region +for boot memory allocations and as target memory for kexec blobs, some parts +of that memory region may be reserved. These reservations are irrelevant for +the next KHO, because kexec can overwrite even the original kernel. + +.. _kho-finalization-phase: + +KHO finalization phase +====================== + +To enable user space based kexec file loader, the kernel needs to be able to +provide the FDT that describes the current kernel's state before +performing the actual kexec. The process of generating that FDT is +called serialization. When the FDT is generated, some properties +of the system may become immutable because they are already written down +in the FDT. That state is called the KHO finalization phase. + +Public API +========== +.. kernel-doc:: kernel/kexec_handover.c + :export: diff --git a/Documentation/core-api/kho/fdt.rst b/Documentation/core-api/kho/fdt.rst new file mode 100644 index 000000000000..62505285d60d --- /dev/null +++ b/Documentation/core-api/kho/fdt.rst @@ -0,0 +1,80 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +======= +KHO FDT +======= + +KHO uses the flattened device tree (FDT) container format and libfdt +library to create and parse the data that is passed between the +kernels. The properties in KHO FDT are stored in native format. +It includes the physical address of an in-memory structure describing +all preserved memory regions, as well as physical addresses of KHO users' +own FDTs. Interpreting those sub FDTs is the responsibility of KHO users. + +KHO nodes and properties +======================== + +Property ``preserved-memory-map`` +--------------------------------- + +KHO saves a special property named ``preserved-memory-map`` under the root node. +This node contains the physical address of an in-memory structure for KHO to +preserve memory regions across kexec. + +Property ``compatible`` +----------------------- + +The ``compatible`` property determines compatibility between the kernel +that created the KHO FDT and the kernel that attempts to load it. +If the kernel that loads the KHO FDT is not compatible with it, the entire +KHO process will be bypassed. + +Property ``fdt`` +---------------- + +Generally, a KHO user serialize its state into its own FDT and instructs +KHO to preserve the underlying memory, such that after kexec, the new kernel +can recover its state from the preserved FDT. + +A KHO user thus can create a node in KHO root tree and save the physical address +of its own FDT in that node's property ``fdt`` . + +Examples +======== + +The following example demonstrates KHO FDT that preserves two memory +regions created with ``reserve_mem`` kernel command line parameter:: + + /dts-v1/; + + / { + compatible = "kho-v1"; + + preserved-memory-map = <0x40be16 0x1000000>; + + memblock { + fdt = <0x1517 0x1000000>; + }; + }; + +where the ``memblock`` node contains an FDT that is requested by the +subsystem memblock for preservation. The FDT contains the following +serialized data:: + + /dts-v1/; + + / { + compatible = "memblock-v1"; + + n1 { + compatible = "reserve-mem-v1"; + start = <0xc06b 0x4000000>; + size = <0x04 0x00>; + }; + + n2 { + compatible = "reserve-mem-v1"; + start = <0xc067 0x4000000>; + size = <0x04 0x00>; + }; + }; diff --git a/Documentation/core-api/kho/index.rst b/Documentation/core-api/kho/index.rst new file mode 100644 index 000000000000..0c63b0c5c143 --- /dev/null +++ b/Documentation/core-api/kho/index.rst @@ -0,0 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +======================== +Kexec Handover Subsystem +======================== + +.. toctree:: + :maxdepth: 1 + + concepts + fdt + +.. only:: subproject and html diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml index 8c7575455422..30c44a0e6407 100644 --- a/Documentation/devicetree/bindings/arm/altera.yaml +++ b/Documentation/devicetree/bindings/arm/altera.yaml @@ -47,6 +47,7 @@ properties: - novtech,chameleon96 - samtec,vining - terasic,de0-atlas + - terasic,de10-nano - terasic,socfpga-cyclone5-sockit - const: altr,socfpga-cyclone5 - const: altr,socfpga diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml index 572381306681..a758f4bb2bb3 100644 --- a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml @@ -9,20 +9,120 @@ title: Altera SOCFPGA Clock Manager maintainers: - Dinh Nguyen <dinguyen@kernel.org> -description: test +description: + This binding describes the Altera SOCFGPA Clock Manager and its associated + tree of clocks, pll's, and clock gates for the Cyclone5, Arria5 and Arria10 + chip families. properties: compatible: items: - const: altr,clk-mgr + reg: maxItems: 1 + clocks: + type: object + additionalProperties: false + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^osc[0-9]$": + type: object + + "^[a-z0-9,_]+(clk|pll|clk_gate|clk_divided)(@[a-f0-9]+)?$": + type: object + $ref: '#/$defs/clock-props' + unevaluatedProperties: false + + properties: + compatible: + enum: + - altr,socfpga-pll-clock + - altr,socfpga-perip-clk + - altr,socfpga-gate-clk + - altr,socfpga-a10-pll-clock + - altr,socfpga-a10-perip-clk + - altr,socfpga-a10-gate-clk + - fixed-clock + + clocks: + description: one or more phandles to input clock + minItems: 1 + maxItems: 5 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^[a-z0-9,_]+(clk|pll)(@[a-f0-9]+)?$": + type: object + $ref: '#/$defs/clock-props' + unevaluatedProperties: false + + properties: + compatible: + enum: + - altr,socfpga-perip-clk + - altr,socfpga-gate-clk + - altr,socfpga-a10-perip-clk + - altr,socfpga-a10-gate-clk + + clocks: + description: one or more phandles to input clock + minItems: 1 + maxItems: 4 + + required: + - compatible + - clocks + - "#clock-cells" + + required: + - compatible + - "#clock-cells" + required: - compatible + - reg additionalProperties: false +$defs: + clock-props: + properties: + reg: + maxItems: 1 + + "#clock-cells": + const: 0 + + clk-gate: + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: gating register offset + - description: bit index + + div-reg: + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: divider register offset + - description: bit shift + - description: bit width + + fixed-divider: + $ref: /schemas/types.yaml#/definitions/uint32 + examples: - | clkmgr@ffd04000 { diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 0647851ae1f5..05edf22e6c30 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -27,6 +27,7 @@ properties: items: - enum: - minix,neo-x8 + - tcu,fernsehfee3 - const: amlogic,meson8 - description: Boards with the Amlogic Meson8m2 SoC @@ -73,6 +74,13 @@ properties: - const: amlogic,s805x - const: amlogic,meson-gxl + - description: Boards with the Amlogic Meson GXL S805Y SoC + items: + - enum: + - xiaomi,aquaman + - const: amlogic,s805y + - const: amlogic,meson-gxl + - description: Boards with the Amlogic Meson GXL S905W SoC items: - enum: @@ -237,6 +245,24 @@ properties: - amlogic,aq222 - const: amlogic,s4 + - description: Boards with the Amlogic S6 S905X5 SoC + items: + - enum: + - amlogic,bl209 + - const: amlogic,s6 + + - description: Boards with the Amlogic S7 S805X3 SoC + items: + - enum: + - amlogic,bp201 + - const: amlogic,s7 + + - description: Boards with the Amlogic S7D S905X5M SoC + items: + - enum: + - amlogic,bm202 + - const: amlogic,s7d + - description: Boards with the Amlogic T7 A311D2 SoC items: - enum: diff --git a/Documentation/devicetree/bindings/arm/atmel,sama5d2-secumod.yaml b/Documentation/devicetree/bindings/arm/atmel,sama5d2-secumod.yaml new file mode 100644 index 000000000000..ad4a98a4ee67 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/atmel,sama5d2-secumod.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/atmel,sama5d2-secumod.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip AT91 Security Module (SECUMOD) + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + +description: + The Security Module also offers the PIOBU pins which can be used as GPIO pins. + Note that they maintain their voltage during Backup/Self-refresh. + +properties: + compatible: + oneOf: + - items: + - const: atmel,sama5d2-secumod + - const: syscon + - items: + - enum: + - microchip,sama7d65-secumod + - microchip,sama7g5-secumod + - const: atmel,sama5d2-secumod + - const: syscon + reg: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + const: 2 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + security-module@fc040000 { + compatible = "atmel,sama5d2-secumod", "syscon"; + reg = <0xfc040000 0x100>; + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index d3821f651e72..5ce54f9befe6 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -46,28 +46,3 @@ Examples: reg = <0xffffe800 0x200>; }; -Security Module (SECUMOD) - -The Security Module macrocell provides all necessary secure functions to avoid -voltage, temperature, frequency and mechanical attacks on the chip. It also -embeds secure memories that can be scrambled. - -The Security Module also offers the PIOBU pins which can be used as GPIO pins. -Note that they maintain their voltage during Backup/Self-refresh. - -required properties: -- compatible: Should be "atmel,<chip>-secumod", "syscon". - <chip> can be "sama5d2". -- reg: Should contain registers location and length -- gpio-controller: Marks the port as GPIO controller. -- #gpio-cells: There are 2. The pin number is the - first, the second represents additional - parameters such as GPIO_ACTIVE_HIGH/LOW. - - - secumod@fc040000 { - compatible = "atmel,sama5d2-secumod", "syscon"; - reg = <0xfc040000 0x100>; - gpio-controller; - #gpio-cells = <2>; - }; diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml index e4ff71f006b8..2729a542c4f3 100644 --- a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml @@ -52,6 +52,7 @@ properties: - description: BCM2837 based Boards items: - enum: + - raspberrypi,2-model-b-rev2 - raspberrypi,3-model-a-plus - raspberrypi,3-model-b - raspberrypi,3-model-b-plus diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 1b90870958a2..d3b5e6923e41 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -1120,6 +1120,12 @@ properties: - const: avnet,sm2s-imx8mp # SM2S-IMX8PLUS SoM - const: fsl,imx8mp + - description: Boundary Devices Nitrogen8M Plus ENC Carrier Board + items: + - const: boundary,imx8mp-nitrogen-enc-carrier-board + - const: boundary,imx8mp-nitrogen-som + - const: fsl,imx8mp + - description: Boundary Device Nitrogen8MP Universal SMARC Carrier Board items: - const: boundary,imx8mp-nitrogen-smarc-universal-board @@ -1156,6 +1162,13 @@ properties: - const: kontron,imx8mp-osm-s # Kontron i.MX8MP OSM-S SoM - const: fsl,imx8mp + - description: PHYTEC phyCORE-i.MX8MP FPSC based boards + items: + - enum: + - phytec,imx8mp-libra-rdk-fpsc # i.MX 8M Plus Libra RDK + - const: phytec,imx8mp-phycore-fpsc # phyCORE-i.MX 8M Plus FPSC + - const: fsl,imx8mp + - description: PHYTEC phyCORE-i.MX8MP SoM based boards items: - const: phytec,imx8mp-phyboard-pollux-rdk # phyBOARD-Pollux RDK @@ -1176,6 +1189,12 @@ properties: - const: polyhex,imx8mp-debix-som-a # Polyhex Debix SOM A - const: fsl,imx8mp + - description: Toradex Boards with SMARC iMX8M Plus Modules + items: + - const: toradex,smarc-imx8mp-dev # Toradex SMARC iMX8M Plus on Toradex SMARC Development Board + - const: toradex,smarc-imx8mp # Toradex SMARC iMX8M Plus Module + - const: fsl,imx8mp + - description: Toradex Boards with Verdin iMX8M Plus Modules items: - enum: @@ -1333,6 +1352,22 @@ properties: - const: tq,imx8qxp-tqma8xqp # TQ-Systems GmbH TQMa8XQP SOM (with i.MX8QXP) - const: fsl,imx8qxp + - description: + TQMa8XxS is a series of SOM featuring NXP i.MX8X system-on-chip + variants. It has the SMARC-2.0 form factor and is designed to be placed on + different carrier boards. MB-SMARC-2 is a carrier reference design. + oneOf: + - items: + - enum: + - tq,imx8qxp-tqma8xqps-mb-smarc-2 # TQ-Systems GmbH TQMa8QXPS SOM on MB-SMARC-2 + - const: tq,imx8qxp-tqma8xqps # TQ-Systems GmbH TQMa8QXPS SOM + - const: fsl,imx8qxp + - items: + - enum: + - tq,imx8dxp-tqma8xdps-mb-smarc-2 # TQ-Systems GmbH TQMa8XDPS SOM on MB-SMARC-2 + - const: tq,imx8dxp-tqma8xdps # TQ-Systems GmbH TQMa8XDPS SOM + - const: fsl,imx8dxp + - description: i.MX8ULP based Boards items: - enum: @@ -1347,6 +1382,12 @@ properties: - fsl,imx93-14x14-evk # i.MX93 14x14 EVK Board - const: fsl,imx93 + - description: i.MX94 based Boards + items: + - enum: + - fsl,imx943-evk # i.MX943 EVK Board + - const: fsl,imx94 + - description: i.MX95 based Boards items: - enum: @@ -1374,12 +1415,16 @@ properties: All SOM and CPU variants use the same device tree hence only one compatible is needed. Bootloader disables all features not present in the assembled SOC. + MBa91xxCA mainboard can be used as starterkit for the SOM + soldered on an adapter board or for the connector variant + to evaluate RGB display support. MBa93xxCA mainboard can be used as starterkit for the SOM soldered on an adapter board or for the connector variant MBa93xxLA mainboard is a single board computer using the solderable SOM variant items: - enum: + - tq,imx93-tqma9352-mba91xxca # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM on MBa91xxCA - tq,imx93-tqma9352-mba93xxca # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM on MBa93xxCA - tq,imx93-tqma9352-mba93xxla # TQ-Systems GmbH i.MX93 TQMa93xxLA SOM on MBa93xxLA SBC - const: tq,imx93-tqma9352 # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM @@ -1387,8 +1432,10 @@ properties: - description: PHYTEC phyCORE-i.MX93 SoM based boards items: - - const: phytec,imx93-phyboard-segin # phyBOARD-Segin with i.MX93 - - const: phytec,imx93-phycore-som # phyCORE-i.MX93 SoM + - enum: + - phytec,imx93-phyboard-nash # phyBOARD-Nash-i.MX93 + - phytec,imx93-phyboard-segin # phyBOARD-Segin with i.MX93 + - const: phytec,imx93-phycore-som # phyCORE-i.MX93 SoM - const: fsl,imx93 - description: Variscite VAR-SOM-MX93 based boards @@ -1404,6 +1451,16 @@ properties: - const: fsl,imx93 - description: + TQMa95xxSA is a series of SOM featuring NXP i.MX95 SoC variants. + It has the SMARC form factor and is designed to be placed on + different carrier boards. MB-SMARC-2 is a carrier reference design. + items: + - enum: + - tq,imx95-tqma9596sa-mb-smarc-2 # TQ-Systems GmbH i.MX95 TQMa95xxSA SOM on MB-SMARC-2 + - const: tq,imx95-tqma9596sa # TQ-Systems GmbH i.MX95 TQMa95xxSA SOM + - const: fsl,imx95 + + - description: Freescale Vybrid Platform Device Tree Bindings For the Vybrid SoC family all variants with DDR controller are supported, diff --git a/Documentation/devicetree/bindings/arm/intel,socfpga.yaml b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml index 2ee0c740eb56..c75cd7d29f1a 100644 --- a/Documentation/devicetree/bindings/arm/intel,socfpga.yaml +++ b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml @@ -25,6 +25,7 @@ properties: items: - enum: - intel,socfpga-agilex5-socdk + - intel,socfpga-agilex5-socdk-nand - const: intel,socfpga-agilex5 additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 108ae5e0185d..a7e0a72f6e4c 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -105,6 +105,10 @@ properties: - bananapi,bpi-r4 - const: mediatek,mt7988a - items: + - const: bananapi,bpi-r4-2g5 + - const: bananapi,bpi-r4 + - const: mediatek,mt7988a + - items: - enum: - mediatek,mt8127-moose - const: mediatek,mt8127 @@ -285,6 +289,13 @@ properties: - const: google,steelix-sku393218 - const: google,steelix - const: mediatek,mt8186 + - description: Google Ponyta + items: + - enum: + - google,ponyta-sku0 + - google,ponyta-sku1 + - const: google,ponyta + - const: mediatek,mt8186 - description: Google Rusty (Lenovo 100e Chromebook Gen 4) items: - const: google,steelix-sku196609 diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 618a87693ac1..56f78f0f3803 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -90,6 +90,7 @@ description: | sm6350 sm6375 sm7125 + sm7150 sm7225 sm7325 sm8150 @@ -1020,6 +1021,7 @@ properties: - items: - enum: - sony,pdx201 + - xiaomi,ginkgo - xiaomi,laurel-sprout - const: qcom,sm6125 @@ -1041,6 +1043,11 @@ properties: - items: - enum: + - google,sunfish + - const: qcom,sm7150 + + - items: + - enum: - fairphone,fp4 - const: qcom,sm7225 @@ -1123,14 +1130,18 @@ properties: - items: - enum: - - lenovo,thinkpad-t14s + - lenovo,thinkpad-t14s-lcd + - lenovo,thinkpad-t14s-oled + - const: lenovo,thinkpad-t14s - const: qcom,x1e78100 - const: qcom,x1e80100 - items: - enum: - asus,vivobook-s15 + - asus,zenbook-a14-ux3407ra - dell,xps13-9345 + - hp,elitebook-ultra-g1q - hp,omnibook-x14 - lenovo,yoga-slim7x - microsoft,romulus13 @@ -1141,6 +1152,7 @@ properties: - items: - enum: + - asus,zenbook-a14-ux3407qa - qcom,x1p42100-crd - const: qcom,x1p42100 diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 650fb833d96e..5772d905f390 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -946,6 +946,11 @@ properties: - const: radxa,rock-5b - const: rockchip,rk3588 + - description: Radxa ROCK 5B+ + items: + - const: radxa,rock-5b-plus + - const: rockchip,rk3588 + - description: Radxa ROCK 5C items: - const: radxa,rock-5c @@ -1047,6 +1052,11 @@ properties: - const: rockchip,rk3399-evb - const: rockchip,rk3399 + - description: Rockchip RK3399 Industry Evaluation board + items: + - const: rockchip,rk3399-evb-ind + - const: rockchip,rk3399 + - description: Rockchip RK3399 Sapphire standalone items: - const: rockchip,rk3399-sapphire @@ -1057,6 +1067,11 @@ properties: - const: rockchip,rk3399-sapphire-excavator - const: rockchip,rk3399 + - description: Rockchip RK3562 Evaluation board 2 + items: + - const: rockchip,rk3562-evb2-v10 + - const: rockchip,rk3562 + - description: Rockchip RK3566 BOX Evaluation Demo board items: - const: rockchip,rk3566-box-demo @@ -1074,7 +1089,9 @@ properties: - description: Rockchip RK3588 Evaluation board items: - - const: rockchip,rk3588-evb1-v10 + - enum: + - rockchip,rk3588-evb1-v10 + - rockchip,rk3588-evb2-v10 - const: rockchip,rk3588 - description: Rockchip RK3588S Evaluation board @@ -1109,6 +1126,24 @@ properties: - rockchip,rv1126 - rockchip,rv1109 + - description: Theobroma Systems PX30-Cobra + items: + - enum: + - tsd,px30-cobra-ltk050h3146w + - tsd,px30-cobra-ltk050h3146w-a2 + - tsd,px30-cobra-ltk050h3148w + - tsd,px30-cobra-ltk500hd1829 + - const: tsd,px30-cobra + - const: rockchip,px30 + + - description: Theobroma Systems PX30-PP1516 + items: + - enum: + - tsd,px30-pp1516-ltk050h3146w-a2 + - tsd,px30-pp1516-ltk050h3148w + - const: tsd,px30-pp1516 + - const: rockchip,px30 + - description: Theobroma Systems PX30-uQ7 with Haikou baseboard items: - const: tsd,px30-ringneck-haikou diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml index 52016a141227..46c1af851be7 100644 --- a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml @@ -25,6 +25,7 @@ select: - rockchip,rk3288-pmu - rockchip,rk3368-pmu - rockchip,rk3399-pmu + - rockchip,rk3562-pmu - rockchip,rk3568-pmu - rockchip,rk3576-pmu - rockchip,rk3588-pmu @@ -43,6 +44,7 @@ properties: - rockchip,rk3288-pmu - rockchip,rk3368-pmu - rockchip,rk3399-pmu + - rockchip,rk3562-pmu - rockchip,rk3568-pmu - rockchip,rk3576-pmu - rockchip,rk3588-pmu diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml index fab29f95d8e6..b3be184c7e56 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml @@ -212,6 +212,14 @@ properties: - samsung,exynos7-espresso # Samsung Exynos7 Espresso - const: samsung,exynos7 + - description: Exynos7870 based boards + items: + - enum: + - samsung,a2corelte # Samsung Galaxy A2 Core + - samsung,j6lte # Samsung Galaxy J6 + - samsung,on7xelte # Samsung Galaxy J7 Prime + - const: samsung,exynos7870 + - description: Exynos7885 based boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 5fee2f38ff25..408532504a24 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -44,6 +44,10 @@ properties: - const: st,stm32h743 - items: - enum: + - st,stm32h747i-disco + - const: st,stm32h747 + - items: + - enum: - st,stm32h750i-art-pi - const: st,stm32h750 - items: @@ -184,6 +188,11 @@ properties: - const: phytec,phycore-stm32mp157c-som - const: st,stm32mp157 + - description: Ultratronik STM32MP1 SBC based Boards + items: + - const: ultratronik,stm32mp157c-ultra-fly-sbc + - const: st,stm32mp157 + - description: ST STM32MP257 based Boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index f536cdd2c1a6..7807ea613258 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -492,6 +492,11 @@ properties: - const: lamobo,lamobo-r1 - const: allwinner,sun7i-a20 + - description: Liontron H-A133L + items: + - const: liontron,h-a133l + - const: allwinner,sun50i-a100 + - description: HAOYU Electronics Marsboard A10 items: - const: haoyu,a10-marsboard @@ -845,6 +850,11 @@ properties: - const: allwinner,r7-tv-dongle - const: allwinner,sun5i-a10s + - description: Radxa Cubie A5E + items: + - const: radxa,cubie-a5e + - const: allwinner,sun55i-a527 + - description: Remix Mini PC items: - const: jide,remix-mini-pc @@ -966,6 +976,11 @@ properties: - const: hechuang,x96-mate - const: allwinner,sun50i-h616 + - description: X96Q Pro+ + items: + - const: amediatech,x96q-pro-plus + - const: allwinner,sun55i-h728 + - description: Xunlong OrangePi items: - const: xunlong,orangepi @@ -1081,4 +1096,14 @@ properties: - const: xunlong,orangepi-zero3 - const: allwinner,sun50i-h618 + - description: YuzukiHD Avaota A1 + items: + - const: yuzukihd,avaota-a1 + - const: allwinner,sun55i-t527 + + - description: YuzukiHD Chameleon + items: + - const: yuzukihd,chameleon + - const: allwinner,sun50i-h618 + additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index 65e0ff1fdf1e..9cae3268a827 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -52,17 +52,14 @@ properties: - nvidia,cardhu-a04 - const: nvidia,cardhu - const: nvidia,tegra30 - - items: - - const: asus,tf201 - - const: nvidia,tegra30 - - items: - - const: asus,tf300t - - const: nvidia,tegra30 - - items: - - const: asus,tf300tg - - const: nvidia,tegra30 - - items: - - const: asus,tf700t + - description: ASUS Transformers Device family + items: + - enum: + - asus,tf201 + - asus,tf300t + - asus,tf300tg + - asus,tf300tl + - asus,tf700t - const: nvidia,tegra30 - description: LG Optimus 4X P880 items: diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index 18f155cd06c8..bf6003d8fb76 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -46,6 +46,7 @@ properties: - description: K3 AM625 SoC items: - enum: + - beagle,am62-pocketbeagle2 - beagle,am625-beagleplay - ti,am625-sk - ti,am62-lp-sk @@ -75,6 +76,30 @@ properties: - const: toradex,verdin-am62 # Verdin AM62 Module - const: ti,am625 + - description: K3 AM62P5 SoC Toradex Verdin Modules and Carrier Boards + items: + - enum: + - toradex,verdin-am62p-nonwifi-dahlia # Verdin AM62P Module on Dahlia + - toradex,verdin-am62p-nonwifi-dev # Verdin AM62P Module on Verdin Development Board + - toradex,verdin-am62p-nonwifi-ivy # Verdin AM62P Module on Ivy + - toradex,verdin-am62p-nonwifi-mallow # Verdin AM62P Module on Mallow + - toradex,verdin-am62p-nonwifi-yavia # Verdin AM62P Module on Yavia + - const: toradex,verdin-am62p-nonwifi # Verdin AM62P Module without Wi-Fi / BT + - const: toradex,verdin-am62p # Verdin AM62P Module + - const: ti,am62p5 + + - description: K3 AM62P5 SoC Toradex Verdin Modules and Carrier Boards with Wi-Fi / BT + items: + - enum: + - toradex,verdin-am62p-wifi-dahlia # Verdin AM62P Wi-Fi / BT Module on Dahlia + - toradex,verdin-am62p-wifi-dev # Verdin AM62P Wi-Fi / BT M. on Verdin Development B. + - toradex,verdin-am62p-wifi-ivy # Verdin AM62P Wi-Fi / BT Module on Ivy + - toradex,verdin-am62p-wifi-mallow # Verdin AM62P Wi-Fi / BT Module on Mallow + - toradex,verdin-am62p-wifi-yavia # Verdin AM62P Wi-Fi / BT Module on Yavia + - const: toradex,verdin-am62p-wifi # Verdin AM62P Wi-Fi / BT Module + - const: toradex,verdin-am62p # Verdin AM62P Module + - const: ti,am62p5 + - description: K3 AM642 SoC items: - enum: @@ -139,6 +164,13 @@ properties: - ti,j721s2-evm - const: ti,j721s2 + - description: K3 J721s2 SoC Phytec SoM based boards + items: + - enum: + - phytec,am68-phyboard-izar + - const: phytec,am68-phycore-som + - const: ti,j721s2 + - description: K3 J722S SoC and Boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/vt8500.yaml b/Documentation/devicetree/bindings/arm/vt8500.yaml index 5d5ad5a60451..fa47b8989bbf 100644 --- a/Documentation/devicetree/bindings/arm/vt8500.yaml +++ b/Documentation/devicetree/bindings/arm/vt8500.yaml @@ -7,14 +7,13 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: VIA/Wondermedia VT8500 Platforms maintainers: - - Tony Prisk <linux@prisktech.co.nz> -description: test + - Alexey Charkov <alchark@gmail.com> properties: $nodename: const: '/' compatible: - items: + oneOf: - enum: - via,vt8500 - wm,wm8505 @@ -22,4 +21,9 @@ properties: - wm,wm8750 - wm,wm8850 + - description: VIA APC Rock and Paper boards + items: + - const: via,apc-rock + - const: wm,wm8950 + additionalProperties: true diff --git a/Documentation/devicetree/bindings/ata/ahci-dm816.txt b/Documentation/devicetree/bindings/ata/ahci-dm816.txt deleted file mode 100644 index f8c535f3541f..000000000000 --- a/Documentation/devicetree/bindings/ata/ahci-dm816.txt +++ /dev/null @@ -1,21 +0,0 @@ -Device tree binding for the TI DM816 AHCI SATA Controller ---------------------------------------------------------- - -Required properties: - - compatible: must be "ti,dm816-ahci" - - reg: physical base address and size of the register region used by - the controller (as defined by the AHCI 1.1 standard) - - interrupts: interrupt specifier (refer to the interrupt binding) - - clocks: list of phandle and clock specifier pairs (or only - phandles for clock providers with '0' defined for - #clock-cells); two clocks must be specified: the functional - clock and an external reference clock - -Example: - - sata: sata@4a140000 { - compatible = "ti,dm816-ahci"; - reg = <0x4a140000 0x10000>; - interrupts = <16>; - clocks = <&sysclk5_ck>, <&sata_refclk>; - }; diff --git a/Documentation/devicetree/bindings/ata/ahci-st.txt b/Documentation/devicetree/bindings/ata/ahci-st.txt deleted file mode 100644 index 909c9935360d..000000000000 --- a/Documentation/devicetree/bindings/ata/ahci-st.txt +++ /dev/null @@ -1,35 +0,0 @@ -STMicroelectronics STi SATA controller - -This binding describes a SATA device. - -Required properties: - - compatible : Must be "st,ahci" - - reg : Physical base addresses and length of register sets - - interrupts : Interrupt associated with the SATA device - - interrupt-names : Associated name must be; "hostc" - - clocks : The phandle for the clock - - clock-names : Associated name must be; "ahci_clk" - - phys : The phandle for the PHY port - - phy-names : Associated name must be; "ahci_phy" - -Optional properties: - - resets : The power-down, soft-reset and power-reset lines of SATA IP - - reset-names : Associated names must be; "pwr-dwn", "sw-rst" and "pwr-rst" - -Example: - - /* Example for stih407 family silicon */ - sata0: sata@9b20000 { - compatible = "st,ahci"; - reg = <0x9b20000 0x1000>; - interrupts = <GIC_SPI 159 IRQ_TYPE_NONE>; - interrupt-names = "hostc"; - phys = <&phy_port0 PHY_TYPE_SATA>; - phy-names = "ahci_phy"; - resets = <&powerdown STIH407_SATA0_POWERDOWN>, - <&softreset STIH407_SATA0_SOFTRESET>, - <&softreset STIH407_SATA0_PWR_SOFTRESET>; - reset-names = "pwr-dwn", "sw-rst", "pwr-rst"; - clocks = <&clk_s_c0_flexgen CLK_ICN_REG>; - clock-names = "ahci_clk"; - }; diff --git a/Documentation/devicetree/bindings/ata/apm,xgene-ahci.yaml b/Documentation/devicetree/bindings/ata/apm,xgene-ahci.yaml new file mode 100644 index 000000000000..7dc942808656 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/apm,xgene-ahci.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/apm,xgene-ahci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: APM X-Gene 6.0 Gb/s SATA host controller + +maintainers: + - Rob Herring <robh@kernel.org> + +allOf: + - $ref: ahci-common.yaml# + +properties: + compatible: + enum: + - apm,xgene-ahci + - apm,xgene-ahci-pcie + + reg: + minItems: 4 + items: + - description: AHCI memory resource + - description: Host controller core + - description: Host controller diagnostic + - description: Host controller AXI + - description: Host controller MUX + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - clocks + - phys + - phy-names + +unevaluatedProperties: false + +examples: + - | + sata@1a400000 { + compatible = "apm,xgene-ahci"; + reg = <0x1a400000 0x1000>, + <0x1f220000 0x1000>, + <0x1f22d000 0x1000>, + <0x1f22e000 0x1000>, + <0x1f227000 0x1000>; + clocks = <&sataclk 0>; + dma-coherent; + interrupts = <0x0 0x87 0x4>; + phys = <&phy2 0>; + phy-names = "sata-phy"; + }; diff --git a/Documentation/devicetree/bindings/ata/apm-xgene.txt b/Documentation/devicetree/bindings/ata/apm-xgene.txt deleted file mode 100644 index 02e690a675db..000000000000 --- a/Documentation/devicetree/bindings/ata/apm-xgene.txt +++ /dev/null @@ -1,77 +0,0 @@ -* APM X-Gene 6.0 Gb/s SATA host controller nodes - -SATA host controller nodes are defined to describe on-chip Serial ATA -controllers. Each SATA controller (pair of ports) have its own node. - -Required properties: -- compatible : Shall contain: - * "apm,xgene-ahci" -- reg : First memory resource shall be the AHCI memory - resource. - Second memory resource shall be the host controller - core memory resource. - Third memory resource shall be the host controller - diagnostic memory resource. - 4th memory resource shall be the host controller - AXI memory resource. - 5th optional memory resource shall be the host - controller MUX memory resource if required. -- interrupts : Interrupt-specifier for SATA host controller IRQ. -- clocks : Reference to the clock entry. -- phys : A list of phandles + phy-specifiers, one for each - entry in phy-names. -- phy-names : Should contain: - * "sata-phy" for the SATA 6.0Gbps PHY - -Optional properties: -- dma-coherent : Present if dma operations are coherent -- status : Shall be "ok" if enabled or "disabled" if disabled. - Default is "ok". - -Example: - sataclk: sataclk { - compatible = "fixed-clock"; - #clock-cells = <1>; - clock-frequency = <100000000>; - clock-output-names = "sataclk"; - }; - - phy2: phy@1f22a000 { - compatible = "apm,xgene-phy"; - reg = <0x0 0x1f22a000 0x0 0x100>; - #phy-cells = <1>; - }; - - phy3: phy@1f23a000 { - compatible = "apm,xgene-phy"; - reg = <0x0 0x1f23a000 0x0 0x100>; - #phy-cells = <1>; - }; - - sata2: sata@1a400000 { - compatible = "apm,xgene-ahci"; - reg = <0x0 0x1a400000 0x0 0x1000>, - <0x0 0x1f220000 0x0 0x1000>, - <0x0 0x1f22d000 0x0 0x1000>, - <0x0 0x1f22e000 0x0 0x1000>, - <0x0 0x1f227000 0x0 0x1000>; - interrupts = <0x0 0x87 0x4>; - dma-coherent; - clocks = <&sataclk 0>; - phys = <&phy2 0>; - phy-names = "sata-phy"; - }; - - sata3: sata@1a800000 { - compatible = "apm,xgene-ahci-pcie"; - reg = <0x0 0x1a800000 0x0 0x1000>, - <0x0 0x1f230000 0x0 0x1000>, - <0x0 0x1f23d000 0x0 0x1000>, - <0x0 0x1f23e000 0x0 0x1000>, - <0x0 0x1f237000 0x0 0x1000>; - interrupts = <0x0 0x88 0x4>; - dma-coherent; - clocks = <&sataclk 0>; - phys = <&phy3 0>; - phy-names = "sata-phy"; - }; diff --git a/Documentation/devicetree/bindings/ata/arasan,cf-spear1340.yaml b/Documentation/devicetree/bindings/ata/arasan,cf-spear1340.yaml new file mode 100644 index 000000000000..4d7017452dda --- /dev/null +++ b/Documentation/devicetree/bindings/ata/arasan,cf-spear1340.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/arasan,cf-spear1340.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arasan PATA Compact Flash Controller + +maintainers: + - Viresh Kumar <viresh.kumar@linaro.org> + +properties: + compatible: + const: arasan,cf-spear1340 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + arasan,broken-udma: + description: UDMA mode is unusable + type: boolean + + arasan,broken-mwdma: + description: MWDMA mode is unusable + type: boolean + + arasan,broken-pio: + description: PIO mode is unusable + type: boolean + + dmas: + maxItems: 1 + + dma-names: + items: + - const: data + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +allOf: + - if: + not: + required: + - arasan,broken-udma + - arasan,broken-mwdma + then: + required: + - dmas + - dma-names + +examples: + - | + cf@fc000000 { + compatible = "arasan,cf-spear1340"; + reg = <0xfc000000 0x1000>; + interrupts = <12>; + dmas = <&dma 23>; + dma-names = "data"; + }; diff --git a/Documentation/devicetree/bindings/ata/cavium,ebt3000-compact-flash.yaml b/Documentation/devicetree/bindings/ata/cavium,ebt3000-compact-flash.yaml new file mode 100644 index 000000000000..349f289b81e6 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/cavium,ebt3000-compact-flash.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/cavium,ebt3000-compact-flash.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cavium Compact Flash + +maintainers: + - Rob Herring <robh@kernel.org> + +description: + The Cavium Compact Flash device is connected to the Octeon Boot Bus, and is + thus a child of the Boot Bus device. It can read and write industry standard + compact flash devices. + +properties: + compatible: + const: cavium,ebt3000-compact-flash + + reg: + description: The base address of the CF chip select banks. + items: + - description: CF chip select bank 0 + - description: CF chip select bank 1 + + cavium,bus-width: + description: The width of the connection to the CF devices. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16] + + cavium,true-ide: + description: True IDE mode when present. + type: boolean + + cavium,dma-engine-handle: + description: A phandle for the DMA Engine connected to this device. + $ref: /schemas/types.yaml#/definitions/phandle + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <1>; + + compact-flash@5,0 { + compatible = "cavium,ebt3000-compact-flash"; + reg = <5 0 0x10000>, <6 0 0x10000>; + cavium,bus-width = <16>; + cavium,true-ide; + cavium,dma-engine-handle = <&dma0>; + }; + }; diff --git a/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt b/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt deleted file mode 100644 index 3bacc8e0931e..000000000000 --- a/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt +++ /dev/null @@ -1,30 +0,0 @@ -* Compact Flash - -The Cavium Compact Flash device is connected to the Octeon Boot Bus, -and is thus a child of the Boot Bus device. It can read and write -industry standard compact flash devices. - -Properties: -- compatible: "cavium,ebt3000-compact-flash"; - - Compatibility with many Cavium evaluation boards. - -- reg: The base address of the CF chip select banks. Depending on - the device configuration, there may be one or two banks. - -- cavium,bus-width: The width of the connection to the CF devices. Valid - values are 8 and 16. - -- cavium,true-ide: Optional, if present the CF connection is in True IDE mode. - -- cavium,dma-engine-handle: Optional, a phandle for the DMA Engine connected - to this device. - -Example: - compact-flash@5,0 { - compatible = "cavium,ebt3000-compact-flash"; - reg = <5 0 0x10000>, <6 0 0x10000>; - cavium,bus-width = <16>; - cavium,true-ide; - cavium,dma-engine-handle = <&dma0>; - }; diff --git a/Documentation/devicetree/bindings/ata/marvell,orion-sata.yaml b/Documentation/devicetree/bindings/ata/marvell,orion-sata.yaml new file mode 100644 index 000000000000..f656ea9223d6 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/marvell,orion-sata.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/marvell,orion-sata.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Orion SATA + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Gregory Clement <gregory.clement@bootlin.com> + +allOf: + - $ref: sata-common.yaml# + +properties: + compatible: + enum: + - marvell,orion-sata + - marvell,armada-370-sata + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 8 + + clock-names: + minItems: 1 + items: + - const: '0' + - const: '1' + - const: '2' + - const: '3' + - const: '4' + - const: '5' + - const: '6' + - const: '7' + + interrupts: + maxItems: 1 + + nr-ports: + description: + Number of SATA ports in use. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 8 + + phys: + minItems: 1 + maxItems: 8 + + phy-names: + minItems: 1 + items: + - const: port0 + - const: port1 + - const: port2 + - const: port3 + - const: port4 + - const: port5 + - const: port6 + - const: port7 + +required: + - compatible + - reg + - interrupts + - nr-ports + +unevaluatedProperties: false + +examples: + - | + sata@80000 { + compatible = "marvell,orion-sata"; + reg = <0x80000 0x5000>; + interrupts = <21>; + phys = <&sata_phy0>, <&sata_phy1>; + phy-names = "port0", "port1"; + nr-ports = <2>; + }; diff --git a/Documentation/devicetree/bindings/ata/marvell.txt b/Documentation/devicetree/bindings/ata/marvell.txt deleted file mode 100644 index b460edd12766..000000000000 --- a/Documentation/devicetree/bindings/ata/marvell.txt +++ /dev/null @@ -1,22 +0,0 @@ -* Marvell Orion SATA - -Required Properties: -- compatibility : "marvell,orion-sata" or "marvell,armada-370-sata" -- reg : Address range of controller -- interrupts : Interrupt controller is using -- nr-ports : Number of SATA ports in use. - -Optional Properties: -- phys : List of phandles to sata phys -- phy-names : Should be "0", "1", etc, one number per phandle - -Example: - - sata@80000 { - compatible = "marvell,orion-sata"; - reg = <0x80000 0x5000>; - interrupts = <21>; - phys = <&sata_phy0>, <&sata_phy1>; - phy-names = "0", "1"; - nr-ports = <2>; - } diff --git a/Documentation/devicetree/bindings/ata/pata-arasan.txt b/Documentation/devicetree/bindings/ata/pata-arasan.txt deleted file mode 100644 index 872edc105680..000000000000 --- a/Documentation/devicetree/bindings/ata/pata-arasan.txt +++ /dev/null @@ -1,37 +0,0 @@ -* ARASAN PATA COMPACT FLASH CONTROLLER - -Required properties: -- compatible: "arasan,cf-spear1340" -- reg: Address range of the CF registers -- interrupt: Should contain the CF interrupt number -- clock-frequency: Interface clock rate, in Hz, one of - 25000000 - 33000000 - 40000000 - 50000000 - 66000000 - 75000000 - 100000000 - 125000000 - 150000000 - 166000000 - 200000000 - -Optional properties: -- arasan,broken-udma: if present, UDMA mode is unusable -- arasan,broken-mwdma: if present, MWDMA mode is unusable -- arasan,broken-pio: if present, PIO mode is unusable -- dmas: one DMA channel, as described in bindings/dma/dma.txt - required unless both UDMA and MWDMA mode are broken -- dma-names: the corresponding channel name, must be "data" - -Example: - - cf@fc000000 { - compatible = "arasan,cf-spear1340"; - reg = <0xfc000000 0x1000>; - interrupt-parent = <&vic1>; - interrupts = <12>; - dmas = <&dma-controller 23>; - dma-names = "data"; - }; diff --git a/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml b/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml index 13eaa8d9a16e..b5ecaabfe2e2 100644 --- a/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml +++ b/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml @@ -20,6 +20,7 @@ select: contains: enum: - rockchip,rk3568-dwc-ahci + - rockchip,rk3576-dwc-ahci - rockchip,rk3588-dwc-ahci required: - compatible @@ -29,6 +30,7 @@ properties: items: - enum: - rockchip,rk3568-dwc-ahci + - rockchip,rk3576-dwc-ahci - rockchip,rk3588-dwc-ahci - const: snps,dwc-ahci @@ -83,6 +85,7 @@ allOf: contains: enum: - rockchip,rk3568-dwc-ahci + - rockchip,rk3576-dwc-ahci then: properties: clocks: diff --git a/Documentation/devicetree/bindings/ata/st,ahci.yaml b/Documentation/devicetree/bindings/ata/st,ahci.yaml new file mode 100644 index 000000000000..6e8e4b4f3d6c --- /dev/null +++ b/Documentation/devicetree/bindings/ata/st,ahci.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/st,ahci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STi SATA controller + +maintainers: + - Patrice Chotard <patrice.chotard@foss.st.com> + +allOf: + - $ref: ahci-common.yaml# + +properties: + compatible: + const: st,ahci + + interrupt-names: + items: + - const: hostc + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ahci_clk + + resets: + items: + - description: Power-down line + - description: Soft-reset line + - description: Power-reset line + + reset-names: + items: + - const: pwr-dwn + - const: sw-rst + - const: pwr-rst + +required: + - compatible + - interrupt-names + - phys + - phy-names + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/phy/phy.h> + #include <dt-bindings/reset/stih407-resets.h> + #include <dt-bindings/clock/stih407-clks.h> + + sata@9b20000 { + compatible = "st,ahci"; + reg = <0x9b20000 0x1000>; + interrupts = <GIC_SPI 159 IRQ_TYPE_NONE>; + interrupt-names = "hostc"; + phys = <&phy_port0 PHY_TYPE_SATA>; + phy-names = "sata-phy"; + resets = <&powerdown STIH407_SATA0_POWERDOWN>, + <&softreset STIH407_SATA0_SOFTRESET>, + <&softreset STIH407_SATA0_PWR_SOFTRESET>; + reset-names = "pwr-dwn", "sw-rst", "pwr-rst"; + clocks = <&clk_s_c0_flexgen CLK_ICN_REG>; + clock-names = "ahci_clk"; + }; diff --git a/Documentation/devicetree/bindings/ata/ti,dm816-ahci.yaml b/Documentation/devicetree/bindings/ata/ti,dm816-ahci.yaml new file mode 100644 index 000000000000..d0ff9e78afe6 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/ti,dm816-ahci.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/ti,dm816-ahci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI DM816 AHCI SATA Controller + +maintainers: + - Bartosz Golaszewski <brgl@bgdev.pl> + +allOf: + - $ref: ahci-common.yaml# + +properties: + compatible: + const: ti,dm816-ahci + + reg: + maxItems: 1 + + clocks: + items: + - description: functional clock + - description: external reference clock + + ti,hwmods: + const: sata + +required: + - compatible + - clocks + +unevaluatedProperties: false + +examples: + - | + sata@4a140000 { + compatible = "ti,dm816-ahci"; + reg = <0x4a140000 0x10000>; + interrupts = <16>; + clocks = <&sysclk5_ck>, <&sata_refclk>; + }; diff --git a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml index a8d40c766dcd..0bea4f5287ce 100644 --- a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml +++ b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml @@ -10,8 +10,8 @@ maintainers: - Saurabh Sengar <ssengar@linux.microsoft.com> description: - VMBus is a software bus that implement the protocols for communication - between the root or host OS and guest OSs (virtual machines). + VMBus is a software bus that implements the protocols for communication + between the root or host OS and guest OS'es (virtual machines). properties: compatible: @@ -25,9 +25,16 @@ properties: '#size-cells': const: 1 + dma-coherent: true + + interrupts: + maxItems: 1 + description: Interrupt is used to report a message from the host. + required: - compatible - ranges + - interrupts - '#address-cells' - '#size-cells' @@ -35,6 +42,8 @@ additionalProperties: false examples: - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> soc { #address-cells = <2>; #size-cells = <1>; @@ -49,6 +58,9 @@ examples: #address-cells = <2>; #size-cells = <1>; ranges = <0x0f 0xf0000000 0x0f 0xf0000000 0x10000000>; + dma-coherent; + interrupt-parent = <&gic>; + interrupts = <GIC_PPI 2 IRQ_TYPE_EDGE_RISING>; }; }; }; diff --git a/Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml b/Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml index d2cbe49f4e15..4de5bb2e5f24 100644 --- a/Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml +++ b/Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml @@ -28,6 +28,9 @@ select: properties: compatible: items: + - enum: + - andestech,qilai-ax45mp-cache + - renesas,r9a07g043f-ax45mp-cache - const: andestech,ax45mp-cache - const: cache @@ -65,12 +68,27 @@ required: - cache-size - cache-unified +allOf: + - if: + properties: + compatible: + contains: + const: andestech,qilai-ax45mp-cache + + then: + properties: + cache-sets: + const: 2048 + cache-size: + const: 2097152 + examples: - | #include <dt-bindings/interrupt-controller/irq.h> cache-controller@13400000 { - compatible = "andestech,ax45mp-cache", "cache"; + compatible = "renesas,r9a07g043f-ax45mp-cache", "andestech,ax45mp-cache", + "cache"; reg = <0x13400000 0x100000>; interrupts = <508 IRQ_TYPE_LEVEL_HIGH>; cache-line-size = <64>; diff --git a/Documentation/devicetree/bindings/cache/marvell,feroceon-cache.txt b/Documentation/devicetree/bindings/cache/marvell,feroceon-cache.txt deleted file mode 100644 index 0d244b999d10..000000000000 --- a/Documentation/devicetree/bindings/cache/marvell,feroceon-cache.txt +++ /dev/null @@ -1,16 +0,0 @@ -* Marvell Feroceon Cache - -Required properties: -- compatible : Should be either "marvell,feroceon-cache" or - "marvell,kirkwood-cache". - -Optional properties: -- reg : Address of the L2 cache control register. Mandatory for - "marvell,kirkwood-cache", not used by "marvell,feroceon-cache" - - -Example: - l2: l2-cache@20128 { - compatible = "marvell,kirkwood-cache"; - reg = <0x20128 0x4>; - }; diff --git a/Documentation/devicetree/bindings/cache/marvell,kirkwood-cache.yaml b/Documentation/devicetree/bindings/cache/marvell,kirkwood-cache.yaml new file mode 100644 index 000000000000..2bfa3c29f6a6 --- /dev/null +++ b/Documentation/devicetree/bindings/cache/marvell,kirkwood-cache.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cache/marvell,kirkwood-cache.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Feroceon/Kirkwood Cache + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Gregory Clement <gregory.clement@bootlin.com> + +properties: + compatible: + enum: + - marvell,feroceon-cache + - marvell,kirkwood-cache + + reg: + maxItems: 1 + +allOf: + - if: + properties: + compatible: + contains: + const: marvell,kirkwood-cache + then: + required: + - reg + else: + properties: + reg: false + +required: + - compatible + +additionalProperties: false + +examples: + - | + l2-cache@20128 { + compatible = "marvell,kirkwood-cache"; + reg = <0x20128 0x4>; + }; diff --git a/Documentation/devicetree/bindings/cache/marvell,tauros2-cache.txt b/Documentation/devicetree/bindings/cache/marvell,tauros2-cache.txt deleted file mode 100644 index 31af1cbb60bd..000000000000 --- a/Documentation/devicetree/bindings/cache/marvell,tauros2-cache.txt +++ /dev/null @@ -1,17 +0,0 @@ -* Marvell Tauros2 Cache - -Required properties: -- compatible : Should be "marvell,tauros2-cache". -- marvell,tauros2-cache-features : Specify the features supported for the - tauros2 cache. - The features including - CACHE_TAUROS2_PREFETCH_ON (1 << 0) - CACHE_TAUROS2_LINEFILL_BURST8 (1 << 1) - The definition can be found at - arch/arm/include/asm/hardware/cache-tauros2.h - -Example: - L2: l2-cache { - compatible = "marvell,tauros2-cache"; - marvell,tauros2-cache-features = <0x3>; - }; diff --git a/Documentation/devicetree/bindings/cache/marvell,tauros2-cache.yaml b/Documentation/devicetree/bindings/cache/marvell,tauros2-cache.yaml new file mode 100644 index 000000000000..9f7f0d031631 --- /dev/null +++ b/Documentation/devicetree/bindings/cache/marvell,tauros2-cache.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cache/marvell,tauros2-cache.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Tauros2 Cache + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Gregory Clement <gregory.clement@bootlin.com> + +properties: + compatible: + const: marvell,tauros2-cache + + marvell,tauros2-cache-features: + description: > + Specify the features supported for the tauros2 cache. The features include: + + - CACHE_TAUROS2_PREFETCH_ON (1 << 0) + - CACHE_TAUROS2_LINEFILL_BURST8 (1 << 1) + + The definition can be found at arch/arm/include/asm/hardware/cache-tauros2.h + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 0x3 + +required: + - compatible + - marvell,tauros2-cache-features + +additionalProperties: false + +examples: + - | + l2-cache { + compatible = "marvell,tauros2-cache"; + marvell,tauros2-cache-features = <0x3>; + }; diff --git a/Documentation/devicetree/bindings/cache/qcom,llcc.yaml b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml index e5effbb4a606..37e3ebd55487 100644 --- a/Documentation/devicetree/bindings/cache/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml @@ -40,6 +40,7 @@ properties: - qcom,sm8450-llcc - qcom,sm8550-llcc - qcom,sm8650-llcc + - qcom,sm8750-llcc - qcom,x1e80100-llcc reg: @@ -274,6 +275,7 @@ allOf: - qcom,sm8450-llcc - qcom,sm8550-llcc - qcom,sm8650-llcc + - qcom,sm8750-llcc then: properties: reg: diff --git a/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml b/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml index 7e8cebe21584..579bacb66f34 100644 --- a/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml +++ b/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml @@ -39,6 +39,7 @@ properties: - const: cache - items: - enum: + - eswin,eic7700-l3-cache - starfive,jh7100-ccache - starfive,jh7110-ccache - const: sifive,ccache0 @@ -55,10 +56,10 @@ properties: enum: [2, 3] cache-sets: - enum: [1024, 2048] + enum: [1024, 2048, 4096] cache-size: - const: 2097152 + enum: [2097152, 4194304] cache-unified: true @@ -89,6 +90,7 @@ allOf: compatible: contains: enum: + - eswin,eic7700-l3-cache - sifive,fu740-c000-ccache - starfive,jh7100-ccache - starfive,jh7110-ccache @@ -112,6 +114,22 @@ allOf: properties: compatible: contains: + const: eswin,eic7700-l3-cache + + then: + properties: + cache-size: + const: 4194304 + + else: + properties: + cache-size: + const: 2097152 + + - if: + properties: + compatible: + contains: enum: - sifive,fu740-c000-ccache - starfive,jh7100-ccache @@ -122,7 +140,15 @@ allOf: cache-sets: const: 2048 - else: + - if: + properties: + compatible: + contains: + enum: + - microchip,mpfs-ccache + - sifive,fu540-c000-ccache + + then: properties: cache-sets: const: 1024 @@ -131,6 +157,18 @@ allOf: properties: compatible: contains: + enum: + - eswin,eic7700-l3-cache + + then: + properties: + cache-sets: + const: 4096 + + - if: + properties: + compatible: + contains: const: sifive,ccache0 then: diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt deleted file mode 100644 index f72e80e0dade..000000000000 --- a/Documentation/devicetree/bindings/clock/altr_socfpga.txt +++ /dev/null @@ -1,30 +0,0 @@ -Device Tree Clock bindings for Altera's SoCFPGA platform - -This binding uses the common clock binding[1]. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt - -Required properties: -- compatible : shall be one of the following: - "altr,socfpga-pll-clock" - for a PLL clock - "altr,socfpga-perip-clock" - The peripheral clock divided from the - PLL clock. - "altr,socfpga-gate-clk" - Clocks that directly feed peripherals and - can get gated. - -- reg : shall be the control register offset from CLOCK_MANAGER's base for the clock. -- clocks : shall be the input parent clock phandle for the clock. This is - either an oscillator or a pll output. -- #clock-cells : from common clock binding, shall be set to 0. - -Optional properties: -- fixed-divider : If clocks have a fixed divider value, use this property. -- clk-gate : For "socfpga-gate-clk", clk-gate contains the gating register - and the bit index. -- div-reg : For "socfpga-gate-clk" and "socfpga-periph-clock", div-reg contains - the divider register, bit shift, and width. -- clk-phase : For the sdmmc_clk, contains the value of the clock phase that controls - the SDMMC CIU clock. The first value is the clk_sample(smpsel), and the second - value is the cclk_in_drv(drvsel). The clk-phase is used to enable the correct - hold/delay times that is needed for the SD/MMC CIU clock. The values of both - can be 0-315 degrees, in 45 degree increments. diff --git a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml index e879bc0be8e2..9f8e6689cd94 100644 --- a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml +++ b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml @@ -83,6 +83,8 @@ properties: by SNVS ONOFF, the driver can report the status of POWER key and wakeup system if pressed after system suspend. + $ref: /schemas/input/input.yaml + properties: compatible: const: fsl,sec-v4.0-pwrkey @@ -111,6 +113,9 @@ properties: maxItems: 1 default: 116 + power-off-time-sec: + enum: [0, 5, 10, 15] + required: - compatible - interrupts diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index 5d2089dc596e..daf90ebb39bf 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -27,6 +27,10 @@ properties: - mediatek,mt8195-mdp3-aal - items: - enum: + - mediatek,mt8188-mdp3-aal + - const: mediatek,mt8195-mdp3-aal + - items: + - enum: - mediatek,mt2712-disp-aal - mediatek,mt6795-disp-aal - const: mediatek,mt8173-disp-aal diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index 6160439ce4d7..5564f4063317 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -29,6 +29,10 @@ properties: - mediatek,mt8195-mdp3-color - items: - enum: + - mediatek,mt8188-mdp3-color + - const: mediatek,mt8195-mdp3-color + - items: + - enum: - mediatek,mt7623-disp-color - mediatek,mt2712-disp-color - const: mediatek,mt2701-disp-color diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index 0de9f64f3f84..3798a25402d3 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -26,6 +26,10 @@ properties: - mediatek,mt8195-disp-merge - mediatek,mt8195-mdp3-merge - items: + - enum: + - mediatek,mt8188-mdp3-merge + - const: mediatek,mt8195-mdp3-merge + - items: - const: mediatek,mt6795-disp-merge - const: mediatek,mt8173-disp-merge - items: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml index be07bbdc54e3..86787866ced0 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml @@ -20,9 +20,13 @@ description: properties: compatible: - enum: - - mediatek,mt8188-disp-padding - - mediatek,mt8195-mdp3-padding + oneOf: + - enum: + - mediatek,mt8188-disp-padding + - mediatek,mt8195-mdp3-padding + - items: + - const: mediatek,mt8188-mdp3-padding + - const: mediatek,mt8195-mdp3-padding reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml b/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml index bbaaa783d184..2219d3d4ac43 100644 --- a/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml +++ b/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: LG SW43408 1080x2160 DSI panel maintainers: - - Caleb Connolly <caleb.connolly@linaro.org> + - Casey Connolly <casey.connolly@linaro.org> description: This panel is used on the Pixel 3, it is a 60hz OLED panel which diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt deleted file mode 100644 index 447fb44e7abe..000000000000 --- a/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt +++ /dev/null @@ -1,44 +0,0 @@ -* NVIDIA Tegra APB DMA controller - -Required properties: -- compatible: Should be "nvidia,<chip>-apbdma" -- reg: Should contain DMA registers location and length. This should include - all of the per-channel registers. -- interrupts: Should contain all of the per-channel DMA interrupts. -- clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - dma -- #dma-cells : Must be <1>. This dictates the length of DMA specifiers in - client nodes' dmas properties. The specifier represents the DMA request - select value for the peripheral. For more details, consult the Tegra TRM's - documentation of the APB DMA channel control register REQ_SEL field. - -Examples: - -apbdma: dma@6000a000 { - compatible = "nvidia,tegra20-apbdma"; - reg = <0x6000a000 0x1200>; - interrupts = < 0 136 0x04 - 0 137 0x04 - 0 138 0x04 - 0 139 0x04 - 0 140 0x04 - 0 141 0x04 - 0 142 0x04 - 0 143 0x04 - 0 144 0x04 - 0 145 0x04 - 0 146 0x04 - 0 147 0x04 - 0 148 0x04 - 0 149 0x04 - 0 150 0x04 - 0 151 0x04 >; - clocks = <&tegra_car 34>; - resets = <&tegra_car 34>; - reset-names = "dma"; - #dma-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.yaml new file mode 100644 index 000000000000..a2ffd5209b3b --- /dev/null +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/nvidia,tegra20-apbdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra APB DMA Controller + +description: + The NVIDIA Tegra APB DMA controller is a hardware component that + enables direct memory access (DMA) on Tegra systems. It facilitates + data transfer between I/O devices and main memory without constant + CPU intervention. + +maintainers: + - Jonathan Hunter <jonathanh@nvidia.com> + +properties: + compatible: + oneOf: + - const: nvidia,tegra20-apbdma + - items: + - const: nvidia,tegra30-apbdma + - const: nvidia,tegra20-apbdma + + reg: + maxItems: 1 + + "#dma-cells": + const: 1 + + clocks: + maxItems: 1 + + interrupts: + description: + Should contain all of the per-channel DMA interrupts in + ascending order with respect to the DMA channel index. + minItems: 1 + maxItems: 32 + + resets: + maxItems: 1 + + reset-names: + const: dma + +required: + - compatible + - reg + - "#dma-cells" + - clocks + - interrupts + - resets + - reset-names + +allOf: + - $ref: dma-controller.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/reset/tegra186-reset.h> + dma-controller@6000a000 { + compatible = "nvidia,tegra30-apbdma", "nvidia,tegra20-apbdma"; + reg = <0x6000a000 0x1200>; + interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car 34>; + resets = <&tegra_car 34>; + reset-names = "dma"; + #dma-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml b/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml index 2cdad1bbae73..9785aac3b5f3 100644 --- a/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml +++ b/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml @@ -27,6 +27,15 @@ properties: mboxes: maxItems: 1 + pmic: + description: Child node describing the main PMIC. + type: object + additionalProperties: true + + properties: + compatible: + const: samsung,s2mpg10-pmic + shmem: description: List of phandle pointing to the shared memory (SHM) area. The memory @@ -43,8 +52,34 @@ additionalProperties: false examples: - | + #include <dt-bindings/interrupt-controller/irq.h> + power-management { compatible = "google,gs101-acpm-ipc"; mboxes = <&ap2apm_mailbox>; shmem = <&apm_sram>; + + pmic { + compatible = "samsung,s2mpg10-pmic"; + interrupts-extended = <&gpa0 6 IRQ_TYPE_LEVEL_LOW>; + + regulators { + LDO1 { + regulator-name = "vdd_ldo1"; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + }; + + // ... + + BUCK1 { + regulator-name = "vdd_mif"; + regulator-min-microvolt = <450000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + regulator-boot-on; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt deleted file mode 100644 index 6eff1afd8daf..000000000000 --- a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt +++ /dev/null @@ -1,57 +0,0 @@ -Intel Service Layer Driver for Stratix10 SoC -============================================ -Intel Stratix10 SoC is composed of a 64 bit quad-core ARM Cortex A53 hard -processor system (HPS) and Secure Device Manager (SDM). When the FPGA is -configured from HPS, there needs to be a way for HPS to notify SDM the -location and size of the configuration data. Then SDM will get the -configuration data from that location and perform the FPGA configuration. - -To meet the whole system security needs and support virtual machine requesting -communication with SDM, only the secure world of software (EL3, Exception -Layer 3) can interface with SDM. All software entities running on other -exception layers must channel through the EL3 software whenever it needs -service from SDM. - -Intel Stratix10 service layer driver, running at privileged exception level -(EL1, Exception Layer 1), interfaces with the service providers and provides -the services for FPGA configuration, QSPI, Crypto and warm reset. Service layer -driver also manages secure monitor call (SMC) to communicate with secure monitor -code running in EL3. - -Required properties: -------------------- -The svc node has the following mandatory properties, must be located under -the firmware node. - -- compatible: "intel,stratix10-svc" or "intel,agilex-svc" -- method: smc or hvc - smc - Secure Monitor Call - hvc - Hypervisor Call -- memory-region: - phandle to the reserved memory node. See - Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt - for details - -Example: -------- - - reserved-memory { - #address-cells = <2>; - #size-cells = <2>; - ranges; - - service_reserved: svcbuffer@0 { - compatible = "shared-dma-pool"; - reg = <0x0 0x0 0x0 0x1000000>; - alignment = <0x1000>; - no-map; - }; - }; - - firmware { - svc { - compatible = "intel,stratix10-svc"; - method = "smc"; - memory-region = <&service_reserved>; - }; - }; diff --git a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml new file mode 100644 index 000000000000..fac1e955852e --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/intel,stratix10-svc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel Service Layer Driver for Stratix10 SoC + +maintainers: + - Dinh Nguyen <dinguyen@kernel.org> + - Mahesh Rao <mahesh.rao@altera.com> + +description: > + Intel Stratix10 SoC is composed of a 64 bit quad-core ARM Cortex A53 hard + processor system (HPS) and Secure Device Manager (SDM). When the FPGA is + configured from HPS, there needs to be a way for HPS to notify SDM the + location and size of the configuration data. Then SDM will get the + configuration data from that location and perform the FPGA configuration. + + To meet the whole system security needs and support virtual machine requesting + communication with SDM, only the secure world of software (EL3, Exception + Layer 3) can interface with SDM. All software entities running on other + exception layers must channel through the EL3 software whenever it needs + service from SDM. + + Intel Stratix10 service layer driver, running at privileged exception level + (EL1, Exception Layer 1), interfaces with the service providers and provides + the services for FPGA configuration, QSPI, Crypto and warm reset. Service layer + driver also manages secure monitor call (SMC) to communicate with secure monitor + code running in EL3. + +properties: + compatible: + enum: + - intel,stratix10-svc + - intel,agilex-svc + + method: + description: | + Supervisory call method to be used to communicate with the + secure service layer. + Permitted values are: + - "smc" : SMC #0, following the SMCCC + - "hvc" : HVC #0, following the SMCCC + + $ref: /schemas/types.yaml#/definitions/string-array + enum: + - smc + - hvc + + memory-region: + maxItems: 1 + description: + reserved memory region for the service layer driver to + communicate with the secure device manager. + + fpga-mgr: + $ref: /schemas/fpga/intel,stratix10-soc-fpga-mgr.yaml + description: Optional child node for fpga manager to perform fabric configuration. + +required: + - compatible + - method + - memory-region + +additionalProperties: false + +examples: + - | + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + + service_reserved: svcbuffer@0 { + compatible = "shared-dma-pool"; + reg = <0x0 0x0 0x0 0x1000000>; + alignment = <0x1000>; + no-map; + }; + }; + + firmware { + svc { + compatible = "intel,stratix10-svc"; + method = "smc"; + memory-region = <&service_reserved>; + + fpga-mgr { + compatible = "intel,stratix10-soc-fpga-mgr"; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml b/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml index 1a95010a546b..2bda2e0e1369 100644 --- a/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml @@ -11,6 +11,18 @@ maintainers: - Peng Fan <peng.fan@nxp.com> properties: + protocol@80: + description: + SCMI LMM protocol which is for boot, shutdown, and reset of other logical + machines (LM). It is usually used to allow one LM to manage another used + as an offload or accelerator engine. + $ref: '/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node' + unevaluatedProperties: false + + properties: + reg: + const: 0x80 + protocol@81: $ref: '/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node' unevaluatedProperties: false @@ -19,6 +31,17 @@ properties: reg: const: 0x81 + protocol@82: + description: + SCMI CPU Protocol which allows an agent to start or stop a CPU. It is + used to manage auxiliary CPUs in a LM. + $ref: '/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node' + unevaluatedProperties: false + + properties: + reg: + const: 0x82 + protocol@84: $ref: '/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node' unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/fpga/intel,stratix10-soc-fpga-mgr.yaml b/Documentation/devicetree/bindings/fpga/intel,stratix10-soc-fpga-mgr.yaml new file mode 100644 index 000000000000..6e536d6b28a9 --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/intel,stratix10-soc-fpga-mgr.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/intel,stratix10-soc-fpga-mgr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel Stratix10 SoC FPGA Manager + +maintainers: + - Mahesh Rao <mahesh.rao@altera.com> + - Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> + - Niravkumar L Rabara <nirav.rabara@altera.com> + +description: + The Intel Stratix10 SoC consists of a 64-bit quad-core ARM Cortex A53 hard + processor system (HPS) and a Secure Device Manager (SDM). The Stratix10 + SoC FPGA Manager driver is used to configure/reconfigure the FPGA fabric + on the die.The driver communicates with SDM/ATF via the stratix10-svc + platform driver for performing its operations. + +properties: + compatible: + enum: + - intel,stratix10-soc-fpga-mgr + - intel,agilex-soc-fpga-mgr + +required: + - compatible + +additionalProperties: false + +examples: + - | + fpga-mgr { + compatible = "intel,stratix10-soc-fpga-mgr"; + }; diff --git a/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt deleted file mode 100644 index 0f874137ca46..000000000000 --- a/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt +++ /dev/null @@ -1,18 +0,0 @@ -Intel Stratix10 SoC FPGA Manager - -Required properties: -The fpga_mgr node has the following mandatory property, must be located under -firmware/svc node. - -- compatible : should contain "intel,stratix10-soc-fpga-mgr" or - "intel,agilex-soc-fpga-mgr" - -Example: - - firmware { - svc { - fpga_mgr: fpga-mgr { - compatible = "intel,stratix10-soc-fpga-mgr"; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/hwinfo/via,vt8500-scc-id.yaml b/Documentation/devicetree/bindings/hwinfo/via,vt8500-scc-id.yaml new file mode 100644 index 000000000000..b0f425a4a882 --- /dev/null +++ b/Documentation/devicetree/bindings/hwinfo/via,vt8500-scc-id.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwinfo/via,vt8500-scc-id.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: VIA/WonderMedia SoC system configuration information + +maintainers: + - Alexey Charkov <alchark@gmail.com> + +description: + The system configuration controller on VIA/WonderMedia SoC's contains a chip + identifier and revision used to differentiate between different hardware + versions of on-chip IP blocks having their own peculiarities which may or + may not be captured by their respective DT compatible strings + +properties: + compatible: + items: + - const: via,vt8500-scc-id + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + chipid@d8120000 { + compatible = "via,vt8500-scc-id"; + reg = <0xd8120000 0x4>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml new file mode 100644 index 000000000000..bf028a8718f1 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/pmbus/adi,lt3074.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices LT3074 voltage regulator + +maintainers: + - Cedric Encarnacion <cedricjustine.encarnacion@analog.com> + +description: | + The LT3074 is a low voltage, ultra-low noise and ultra-fast transient + response linear regulator. It allows telemetry for input/output voltage, + output current and temperature through the PMBus serial interface. + + Datasheet: + https://www.analog.com/en/products/lt3074.html + +allOf: + - $ref: /schemas/regulator/regulator.yaml# + +properties: + compatible: + enum: + - adi,lt3074 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@6d { + compatible = "adi,lt3074"; + reg = <0x6d>; + regulator-name = "vout"; + regulator-max-microvolt = <1250000>; + regulator-min-microvolt = <1150000>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/mps,mpq8785.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/mps,mpq8785.yaml new file mode 100644 index 000000000000..90970a0433e9 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/pmbus/mps,mpq8785.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/pmbus/mps,mpq8785.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Monolithic Power Systems Multiphase Voltage Regulators with PMBus + +maintainers: + - Charles Hsu <ythsu0511@gmail.com> + +description: + Monolithic Power Systems digital multiphase voltage regulators with PMBus. + +properties: + compatible: + enum: + - mps,mpm3695 + - mps,mpm3695-25 + - mps,mpm82504 + - mps,mpq8785 + + reg: + maxItems: 1 + + mps,vout-fb-divider-ratio-permille: + description: + The feedback resistor divider ratio, expressed in permille + (Vfb / Vout * 1000). This value is written to the PMBUS_VOUT_SCALE_LOOP + register and is required for correct output voltage presentation. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 4095 + default: 706 + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + enum: + - mps,mpm3695 + - mps,mpm82504 + then: + properties: + mps,vout-fb-divider-ratio-permille: + maximum: 1023 + + - if: + properties: + compatible: + const: mps,mpq8785 + then: + properties: + mps,vout-fb-divider-ratio-permille: + maximum: 2047 + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@30 { + compatible = "mps,mpm82504"; + reg = <0x30>; + mps,vout-fb-divider-ratio-permille = <600>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml b/Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml index f0667ac41d75..b76805d39427 100644 --- a/Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml +++ b/Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml @@ -11,7 +11,11 @@ maintainers: properties: compatible: - const: sophgo,sg2042-hwmon-mcu + oneOf: + - items: + - const: sophgo,sg2044-hwmon-mcu + - const: sophgo,sg2042-hwmon-mcu + - const: sophgo,sg2042-hwmon-mcu reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml b/Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml index 5d33f1a23d03..9ca7356760a7 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml @@ -28,6 +28,17 @@ properties: i2c-mux: type: object + fan: + $ref: fan-common.yaml# + unevaluatedProperties: false + + "#pwm-cells": + const: 2 + description: | + Number of cells in a PWM specifier. + - cell 0: PWM period in nanoseconds + - cell 1: PWM polarity: 0 or PWM_POLARITY_INVERTED + required: - compatible - reg @@ -50,9 +61,14 @@ examples: #address-cells = <1>; #size-cells = <0>; - fan@18 { + fan_controller: fan@18 { compatible = "ti,amc6821"; reg = <0x18>; + #pwm-cells = <2>; + + fan { + pwms = <&fan_controller 40000 0>; + }; }; }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml index bc03781342c0..d1fb7b9abda0 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml @@ -19,6 +19,7 @@ description: | properties: compatible: enum: + - silergy,sq52206 - silergy,sy24655 - ti,ina209 - ti,ina219 @@ -58,6 +59,9 @@ properties: shunt voltage, and a value of 4 maps to ADCRANGE=0 such that a wider voltage range is used. + For SQ52206,the shunt-gain value 1 mapps to ADCRANGE=10/11, the value 2 + mapps to ADCRANGE=01, and the value 4 mapps to ADCRANGE=00. + The default value is device dependent, and is defined by the reset value of PGA/ADCRANGE in the respective configuration registers. $ref: /schemas/types.yaml#/definitions/uint32 @@ -97,6 +101,7 @@ allOf: compatible: contains: enum: + - silergy,sq52206 - silergy,sy24655 - ti,ina209 - ti,ina219 diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml index 7e5b62a0215d..4c89448eba0d 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml @@ -23,6 +23,9 @@ properties: "#thermal-sensor-cells": const: 1 + vcc-supply: + description: Power supply for tmp102 + required: - compatible - reg @@ -42,6 +45,7 @@ examples: reg = <0x48>; interrupt-parent = <&gpio7>; interrupts = <16 IRQ_TYPE_LEVEL_LOW>; + vcc-supply = <&supply>; #thermal-sensor-cells = <1>; }; }; diff --git a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml index 4fbdcdac0aee..853092f7522d 100644 --- a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml +++ b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml @@ -9,14 +9,17 @@ title: Silvaco I3C master maintainers: - Conor Culhane <conor.culhane@silvaco.com> -allOf: - - $ref: i3c.yaml# - properties: compatible: - enum: - - nuvoton,npcm845-i3c - - silvaco,i3c-master-v1 + oneOf: + - enum: + - nuvoton,npcm845-i3c + - silvaco,i3c-master-v1 + - items: + - enum: + - nxp,imx94-i3c + - nxp,imx95-i3c + - const: silvaco,i3c-master-v1 reg: maxItems: 1 @@ -25,12 +28,14 @@ properties: maxItems: 1 clocks: + minItems: 2 items: - description: system clock - description: bus clock - description: other (slower) events clock clock-names: + minItems: 2 items: - const: pclk - const: fast_clk @@ -46,6 +51,34 @@ required: - clock-names - clocks +allOf: + - $ref: i3c.yaml# + - if: + properties: + compatible: + enum: + - nuvoton,npcm845-i3c + - silvaco,i3c-master-v1 + then: + properties: + clocks: + minItems: 3 + clock-names: + minItems: 3 + - if: + properties: + compatible: + contains: + enum: + - nxp,imx94-i3c + - nxp,imx95-i3c + then: + properties: + clocks: + maxItems: 2 + clock-names: + maxItems: 2 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml index f39bc92c2b99..862e450da214 100644 --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm's SPMI PMIC Round Robin ADC maintainers: - - Caleb Connolly <caleb.connolly@linaro.org> + - Casey Connolly <casey.connolly@linaro.org> description: | The Qualcomm SPMI Round Robin ADC (RRADC) provides interface to clients to diff --git a/Documentation/devicetree/bindings/input/dlg,da7280.txt b/Documentation/devicetree/bindings/input/dlg,da7280.txt deleted file mode 100644 index 96ee5d50e111..000000000000 --- a/Documentation/devicetree/bindings/input/dlg,da7280.txt +++ /dev/null @@ -1,108 +0,0 @@ -Dialog Semiconductor DA7280 Haptics bindings - -Required properties: -- compatible: Should be "dlg,da7280". -- reg: Specifies the I2C slave address. - -- interrupt-parent : Specifies the phandle of the interrupt controller to - which the IRQs from DA7280 are delivered to. - -- dlg,actuator-type: Set Actuator type. it should be one of: - "LRA" - Linear Resonance Actuator type. - "ERM-bar" - Bar type Eccentric Rotating Mass. - "ERM-coin" - Coin type Eccentric Rotating Mass. - -- dlg,const-op-mode: Haptic operation mode for FF_CONSTANT. - Possible values: - 1 - Direct register override(DRO) mode triggered by i2c(default), - 2 - PWM data source mode controlled by PWM duty, -- dlg,periodic-op-mode: Haptic operation mode for FF_PERIODIC. - Possible values: - 1 - Register triggered waveform memory(RTWM) mode, the pattern - assigned to the PS_SEQ_ID played as much times as PS_SEQ_LOOP, - 2 - Edge triggered waveform memory(ETWM) mode, external GPI(N) - control are required to enable/disable and it needs to keep - device enabled by sending magnitude (X > 0), - the pattern is assigned to the GPI(N)_SEQUENCE_ID below. - The default value is 1 for both of the operation modes. - For more details, please see the datasheet. - -- dlg,nom-microvolt: Nominal actuator voltage rating. - Valid values: 0 - 6000000. -- dlg,abs-max-microvolt: Absolute actuator maximum voltage rating. - Valid values: 0 - 6000000. -- dlg,imax-microamp: Actuator max current rating. - Valid values: 0 - 252000. - Default: 130000. -- dlg,impd-micro-ohms: the impedance of the actuator in micro ohms. - Valid values: 0 - 1500000000. - -Optional properties: -- pwms : phandle to the physical PWM(Pulse Width Modulation) device. - PWM properties should be named "pwms". And number of cell is different - for each pwm device. - (See Documentation/devicetree/bindings/pwm/pwm.txt - for further information relating to pwm properties) - -- dlg,ps-seq-id: the PS_SEQ_ID(pattern ID in waveform memory inside chip) - to play back when RTWM-MODE is enabled. - Valid range: 0 - 15. -- dlg,ps-seq-loop: the PS_SEQ_LOOP, Number of times the pre-stored sequence - pointed to by PS_SEQ_ID or GPI(N)_SEQUENCE_ID is repeated. - Valid range: 0 - 15. -- dlg,gpiN-seq-id: the GPI(N)_SEQUENCE_ID, pattern to play - when gpi0 is triggered, 'N' must be 0 - 2. - Valid range: 0 - 15. -- dlg,gpiN-mode: the pattern mode which can select either - "Single-pattern" or "Multi-pattern", 'N' must be 0 - 2. -- dlg,gpiN-polarity: gpiN polarity which can be chosen among - "Rising-edge", "Falling-edge" and "Both-edge", - 'N' must be 0 - 2 - Haptic will work by this edge option in case of ETWM mode. - -- dlg,resonant-freq-hz: use in case of LRA. - the frequency range: 50 - 300. - Default: 205. - -- dlg,bemf-sens-enable: Enable for internal loop computations. -- dlg,freq-track-enable: Enable for resonant frequency tracking. -- dlg,acc-enable: Enable for active acceleration. -- dlg,rapid-stop-enable: Enable for rapid stop. -- dlg,amp-pid-enable: Enable for the amplitude PID. -- dlg,mem-array: Customized waveform memory(patterns) data downloaded to - the device during initialization. This is an array of 100 values(u8). - -For further information, see device datasheet. - -====== - -Example: - - haptics: da7280-haptics@4a { - compatible = "dlg,da7280"; - reg = <0x4a>; - interrupt-parent = <&gpio6>; - interrupts = <11 IRQ_TYPE_LEVEL_LOW>; - dlg,actuator-type = "LRA"; - dlg,dlg,const-op-mode = <1>; - dlg,dlg,periodic-op-mode = <1>; - dlg,nom-microvolt = <2000000>; - dlg,abs-max-microvolt = <2000000>; - dlg,imax-microamp = <170000>; - dlg,resonant-freq-hz = <180>; - dlg,impd-micro-ohms = <10500000>; - dlg,freq-track-enable; - dlg,rapid-stop-enable; - dlg,mem-array = < - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - >; - }; diff --git a/Documentation/devicetree/bindings/input/dlg,da7280.yaml b/Documentation/devicetree/bindings/input/dlg,da7280.yaml new file mode 100644 index 000000000000..0d06755aaaa8 --- /dev/null +++ b/Documentation/devicetree/bindings/input/dlg,da7280.yaml @@ -0,0 +1,248 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/dlg,da7280.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dialog Semiconductor DA7280 Low Power High-Definition Haptic Driver + +maintainers: + - Roy Im <roy.im.opensource@diasemi.com> + +properties: + compatible: + const: dlg,da7280 + + reg: + maxItems: 1 + description: I2C address of the device. + + interrupts: + maxItems: 1 + + dlg,actuator-type: + enum: + - LRA # Linear Resonance Actuator type + - ERM-bar # Bar type Eccentric Rotating Mass + - ERM-coin # Coin type Eccentric Rotating Mass + + dlg,const-op-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 1 # Direct register override (DRO) mode triggered by i2c (default) + - 2 # PWM data source mode controlled by PWM duty + description: + Haptic operation mode for FF_CONSTANT + + dlg,periodic-op-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 1 # Register triggered waveform memory(RTWM) mode, the pattern + # assigned to the PS_SEQ_ID played as much times as PS_SEQ_LOOP + - 2 # Edge triggered waveform memory(ETWM) mode, external GPI(N) + # control are required to enable/disable and it needs to keep + # device enabled by sending magnitude (X > 0), + # the pattern is assigned to the GPI(N)_SEQUENCE_ID below + default: 1 + description: + Haptic operation mode for FF_PERIODIC. + The default value is 1 for both of the operation modes. + For more details, please see the datasheet + + dlg,nom-microvolt: + minimum: 0 + maximum: 6000000 + description: + Nominal actuator voltage rating + + dlg,abs-max-microvolt: + minimum: 0 + maximum: 6000000 + description: + Absolute actuator maximum voltage rating + + dlg,imax-microamp: + minimum: 0 + maximum: 252000 + default: 130000 + description: + Actuator max current rating + + dlg,impd-micro-ohms: + minimum: 0 + maximum: 1500000000 + description: + Impedance of the actuator + + pwms: + maxItems: 1 + + dlg,ps-seq-id: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + The PS_SEQ_ID(pattern ID in waveform memory inside chip) + to play back when RTWM-MODE is enabled + + dlg,ps-seq-loop: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + The PS_SEQ_LOOP, Number of times the pre-stored sequence pointed to by + PS_SEQ_ID or GPI(N)_SEQUENCE_ID is repeated + + dlg,gpi0-seq-id: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + the GPI0_SEQUENCE_ID, pattern to play when gpi0 is triggered + + dlg,gpi1-seq-id: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + the GPI1_SEQUENCE_ID, pattern to play when gpi1 is triggered + + dlg,gpi2-seq-id: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + the GPI2_SEQUENCE_ID, pattern to play when gpi2 is triggered + + dlg,gpi0-mode: + enum: + - Single-pattern + - Multi-pattern + description: + Pattern mode for gpi0 + + dlg,gpi1-mode: + enum: + - Single-pattern + - Multi-pattern + description: + Pattern mode for gpi1 + + dlg,gpi2-mode: + enum: + - Single-pattern + - Multi-pattern + description: + Pattern mode for gpi2 + + dlg,gpi0-polarity: + enum: + - Rising-edge + - Falling-edge + - Both-edge + description: + gpi0 polarity, Haptic will work by this edge option in case of ETWM mode + + dlg,gpi1-polarity: + enum: + - Rising-edge + - Falling-edge + - Both-edge + description: + gpi1 polarity, Haptic will work by this edge option in case of ETWM mode + + dlg,gpi2-polarity: + enum: + - Rising-edge + - Falling-edge + - Both-edge + description: + gpi2 polarity, Haptic will work by this edge option in case of ETWM mode + + dlg,resonant-freq-hz: + minimum: 50 + maximum: 300 + default: 205 + + dlg,bemf-sens-enable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable for internal loop computations + + dlg,freq-track-enable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable for resonant frequency tracking + + dlg,acc-enable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable for active acceleration + + dlg,rapid-stop-enable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable for rapid stop + + dlg,amp-pid-enable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable for the amplitude PID + + dlg,mem-array: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 100 + description: + Customized waveform memory (patterns) data downloaded to the device during initialization. + Each entry value must be included between 0 and 255. + +required: + - compatible + - reg + - interrupts + - dlg,actuator-type + - dlg,const-op-mode + - dlg,periodic-op-mode + - dlg,nom-microvolt + - dlg,abs-max-microvolt + - dlg,imax-microamp + - dlg,impd-micro-ohms + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + haptics@4a { + compatible = "dlg,da7280"; + reg = <0x4a>; + interrupt-parent = <&gpio6>; + interrupts = <11 IRQ_TYPE_LEVEL_LOW>; + dlg,actuator-type = "LRA"; + dlg,const-op-mode = <1>; + dlg,periodic-op-mode = <1>; + dlg,nom-microvolt = <2000000>; + dlg,abs-max-microvolt = <2000000>; + dlg,imax-microamp = <170000>; + dlg,resonant-freq-hz = <180>; + dlg,impd-micro-ohms = <10500000>; + dlg,freq-track-enable; + dlg,rapid-stop-enable; + dlg,mem-array = <0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml index 70a922e213f2..ab821490284a 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml @@ -103,16 +103,9 @@ properties: minimum: 0 maximum: 255 - touchscreen-size-x: true - touchscreen-size-y: true - touchscreen-fuzz-x: true - touchscreen-fuzz-y: true - touchscreen-inverted-x: true - touchscreen-inverted-y: true - touchscreen-swapped-x-y: true interrupt-controller: true -additionalProperties: false +unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt deleted file mode 100644 index 2ff356640100..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt +++ /dev/null @@ -1,41 +0,0 @@ -NVIDIA Legacy Interrupt Controller - -All Tegra SoCs contain a legacy interrupt controller that routes -interrupts to the GIC, and also serves as a wakeup source. It is also -referred to as "ictlr", hence the name of the binding. - -The HW block exposes a number of interrupt controllers, each -implementing a set of 32 interrupts. - -Required properties: - -- compatible : should be: "nvidia,tegra<chip>-ictlr". The LIC on - subsequent SoCs remained backwards-compatible with Tegra30, so on - Tegra generations later than Tegra30 the compatible value should - include "nvidia,tegra30-ictlr". -- reg : Specifies base physical address and size of the registers. - Each controller must be described separately (Tegra20 has 4 of them, - whereas Tegra30 and later have 5). -- interrupt-controller : Identifies the node as an interrupt controller. -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. The value must be 3. - -Notes: - -- Because this HW ultimately routes interrupts to the GIC, the - interrupt specifier must be that of the GIC. -- Only SPIs can use the ictlr as an interrupt parent. SGIs and PPIs - are explicitly forbidden. - -Example: - - ictlr: interrupt-controller@60004000 { - compatible = "nvidia,tegra20-ictlr", "nvidia,tegra-ictlr"; - reg = <0x60004000 64>, - <0x60004100 64>, - <0x60004200 64>, - <0x60004300 64>; - interrupt-controller; - #interrupt-cells = <3>; - interrupt-parent = <&intc>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.yaml b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.yaml new file mode 100644 index 000000000000..074a873880e5 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/nvidia,tegra20-ictlr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20 Legacy Interrupt Controller + +maintainers: + - Thierry Reding <treding@nvidia.com> + - Jonathan Hunter <jonathanh@nvidia.com> + +description: > + All Tegra SoCs contain a legacy interrupt controller that routes interrupts to + the GIC, and also serves as a wakeup source. It is also referred to as + "ictlr", hence the name of the binding. + + The HW block exposes a number of interrupt controllers, each implementing a + set of 32 interrupts. + + Notes: + - Because this HW ultimately routes interrupts to the GIC, the + interrupt specifier must be that of the GIC. + - Only SPIs can use the ictlr as an interrupt parent. SGIs and PPIs + are explicitly forbidden. + +properties: + compatible: + oneOf: + - items: + - enum: + - nvidia,tegra114-ictlr + - nvidia,tegra124-ictlr + - const: nvidia,tegra30-ictlr + - enum: + - nvidia,tegra20-ictlr + - nvidia,tegra30-ictlr + + reg: + description: Each entry is a block of 32 interrupts + minItems: 4 + maxItems: 5 + + interrupt-controller: true + + '#interrupt-cells': + const: 3 + +required: + - compatible + - reg + - interrupt-controller + - '#interrupt-cells' + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: nvidia,tegra20-ictlr + then: + properties: + reg: + maxItems: 4 + else: + properties: + reg: + minItems: 5 + +examples: + - | + interrupt-controller@60004000 { + compatible = "nvidia,tegra20-ictlr"; + reg = <0x60004000 64>, + <0x60004100 64>, + <0x60004200 64>, + <0x60004300 64>; + interrupt-controller; + #interrupt-cells = <3>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.txt b/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.txt deleted file mode 100644 index 55c04faa3f3f..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.txt +++ /dev/null @@ -1,23 +0,0 @@ -OpenRISC 1000 Programmable Interrupt Controller - -Required properties: - -- compatible : should be "opencores,or1k-pic-level" for variants with - level triggered interrupt lines, "opencores,or1k-pic-edge" for variants with - edge triggered interrupt lines or "opencores,or1200-pic" for machines - with the non-spec compliant or1200 type implementation. - - "opencores,or1k-pic" is also provided as an alias to "opencores,or1200-pic", - but this is only for backwards compatibility. - -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. The value shall be 1. - -Example: - -intc: interrupt-controller { - compatible = "opencores,or1k-pic-level"; - interrupt-controller; - #interrupt-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.yaml b/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.yaml new file mode 100644 index 000000000000..995b68c3aed4 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/opencores,or1k-pic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OpenRISC 1000 Programmable Interrupt Controller + +maintainers: + - Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> + +properties: + compatible: + enum: + - opencores,or1k-pic-level + - opencores,or1k-pic-edge + - opencores,or1200-pic + - opencores,or1k-pic + + interrupt-controller: true + + '#interrupt-cells': + const: 1 + +required: + - compatible + - interrupt-controller + - '#interrupt-cells' + +additionalProperties: false + +examples: + - | + interrupt-controller { + compatible = "opencores,or1k-pic-level"; + interrupt-controller; + #interrupt-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt b/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt deleted file mode 100644 index caec07cc7149..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt +++ /dev/null @@ -1,22 +0,0 @@ -Open Multi-Processor Interrupt Controller - -Required properties: - -- compatible : This should be "openrisc,ompic" -- reg : Specifies base physical address and size of the register space. The - size is based on the number of cores the controller has been configured - to handle, this should be set to 8 bytes per cpu core. -- interrupt-controller : Identifies the node as an interrupt controller. -- #interrupt-cells : This should be set to 0 as this will not be an irq - parent. -- interrupts : Specifies the interrupt line to which the ompic is wired. - -Example: - -ompic: interrupt-controller@98000000 { - compatible = "openrisc,ompic"; - reg = <0x98000000 16>; - interrupt-controller; - #interrupt-cells = <0>; - interrupts = <1>; -}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.yaml b/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.yaml new file mode 100644 index 000000000000..4efbfba3aa6b --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/openrisc,ompic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Open Multi-Processor Interrupt Controller + +maintainers: + - Stafford Horne <shorne@gmail.com> + +properties: + compatible: + items: + - const: openrisc,ompic + + reg: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 0 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupt-controller + - '#interrupt-cells' + - interrupts + +additionalProperties: false + +examples: + - | + interrupt-controller@98000000 { + compatible = "openrisc,ompic"; + reg = <0x98000000 16>; + interrupt-controller; + #interrupt-cells = <0>; + interrupts = <1>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml index 3dfe425909d1..ffc4768bad06 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml @@ -70,6 +70,7 @@ properties: - sophgo,cv1812h-plic - sophgo,sg2002-plic - sophgo,sg2042-plic + - sophgo,sg2044-plic - thead,th1520-plic - const: thead,c900-plic - items: diff --git a/Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-mswi.yaml b/Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-mswi.yaml index 065f2544b63b..d6fb08a54167 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-mswi.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-mswi.yaml @@ -14,6 +14,7 @@ properties: items: - enum: - sophgo,sg2042-aclint-mswi + - sophgo,sg2044-aclint-mswi - const: thead,c900-aclint-mswi reg: diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index ea6b0f5f24de..75750c64157c 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -74,6 +74,7 @@ properties: - mediatek,mt2712-m4u # generation two - mediatek,mt6779-m4u # generation two - mediatek,mt6795-m4u # generation two + - mediatek,mt6893-iommu-mm # generation two - mediatek,mt8167-m4u # generation two - mediatek,mt8173-m4u # generation two - mediatek,mt8183-m4u # generation two @@ -131,6 +132,7 @@ properties: dt-binding/memory/mt2712-larb-port.h for mt2712, dt-binding/memory/mt6779-larb-port.h for mt6779, dt-binding/memory/mt6795-larb-port.h for mt6795, + dt-binding/memory/mediatek,mt6893-memory-port.h for mt6893, dt-binding/memory/mt8167-larb-port.h for mt8167, dt-binding/memory/mt8173-larb-port.h for mt8173, dt-binding/memory/mt8183-larb-port.h for mt8183, @@ -157,6 +159,7 @@ allOf: - mediatek,mt2701-m4u - mediatek,mt2712-m4u - mediatek,mt6795-m4u + - mediatek,mt6893-iommu-mm - mediatek,mt8173-m4u - mediatek,mt8186-iommu-mm - mediatek,mt8188-iommu-vdo @@ -173,6 +176,7 @@ allOf: properties: compatible: enum: + - mediatek,mt6893-iommu-mm - mediatek,mt8186-iommu-mm - mediatek,mt8188-iommu-vdo - mediatek,mt8188-iommu-vpp diff --git a/Documentation/devicetree/bindings/leds/ti,tps61310.yaml b/Documentation/devicetree/bindings/leds/ti,tps61310.yaml new file mode 100644 index 000000000000..118f9c8bfdf7 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/ti,tps61310.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/ti,tps61310.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TPS6131X flash LED driver + +maintainers: + - Matthias Fend <matthias.fend@emfend.at> + +description: | + The TPS61310/TPS61311 is a flash LED driver with I2C interface. + Its power stage is capable of supplying a maximum total current of roughly 1500mA. + The TPS6131x provides three constant-current sinks, capable of sinking + up to 2 x 400mA (LED1 and LED3) and 800mA (LED2) in flash mode. + In torch mode, each sink (LED1, LED2, LED3) supports currents up to 175mA. + Since the three current sinks share most of the control components such as + flash timer, control logic, safety timer and the operating mode, they cannot + be used completely independently of each other. Therefore, only one LED is + supported, but the current sinks can be combined accordingly. + + The data sheet can be found at: + https://www.ti.com/lit/ds/symlink/tps61310.pdf + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,tps61311 + - const: ti,tps61310 + - items: + - const: ti,tps61310 + + reg: + maxItems: 1 + + reset-gpios: + maxItems: 1 + description: GPIO connected to NRESET pin + + ti,valley-current-limit: + type: boolean + description: + Reduce the valley peak current limit from 1750mA to 1250mA (TPS61310) or + from 2480mA to 1800mA (TPS61311). + + led: + type: object + $ref: common.yaml# + unevaluatedProperties: false + + properties: + led-sources: + minItems: 1 + maxItems: 3 + items: + enum: [1, 2, 3] + + led-max-microamp: + oneOf: + - minimum: 50000 + maximum: 350000 + multipleOf: 50000 + - minimum: 25000 + maximum: 525000 + multipleOf: 25000 + + flash-max-microamp: + oneOf: + - minimum: 50000 + maximum: 800000 + multipleOf: 50000 + - minimum: 25000 + maximum: 1500000 + multipleOf: 25000 + + flash-max-timeout-us: + enum: [ 5300, 10700, 16000, 21300, 26600, 32000, 37300, 68200, 71500, + 102200, 136300, 170400, 204500, 340800, 579300, 852000 ] + + required: + - led-sources + - led-max-microamp + - flash-max-microamp + - flash-max-timeout-us + +required: + - compatible + - reg + - led + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@33 { + compatible = "ti,tps61311", "ti,tps61310"; + reg = <0x33>; + + reset-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; + + led { + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_WHITE>; + led-sources = <1>, <2>, <3>; + led-max-microamp = <525000>; + flash-max-microamp = <1500000>; + flash-max-timeout-us = <852000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index a58a018f3f7b..ac726136f7e5 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -49,6 +49,7 @@ properties: - qcom,qcs615-apss-shared - qcom,sc7180-apss-shared - qcom,sc8180x-apss-shared + - qcom,sm7150-apss-shared - qcom,sm8150-apss-shared - const: qcom,sdm845-apss-shared - items: @@ -72,6 +73,7 @@ properties: description: phandles to the parent clocks of the clock driver minItems: 2 maxItems: 3 + deprecated: true '#mbox-cells': const: 1 @@ -82,6 +84,23 @@ properties: clock-names: minItems: 2 maxItems: 3 + deprecated: true + + clock-controller: + type: object + additionalProperties: false + properties: + clocks: + description: phandles to the parent clocks of the clock driver + minItems: 2 + maxItems: 3 + + '#clock-cells': + enum: [0, 1] + + clock-names: + minItems: 2 + maxItems: 3 required: - compatible @@ -90,6 +109,76 @@ required: additionalProperties: false +# Clocks should be specified either on the parent node or on the child node +oneOf: + - required: + - clock-controller + properties: + clocks: false + clock-names: false + '#clock-cells': false + - properties: + clock-controller: false + +$defs: + msm8916-apcs-clock-controller: + properties: + clocks: + items: + - description: primary pll parent of the clock driver + - description: auxiliary parent + clock-names: + items: + - const: pll + - const: aux + '#clock-cells': + const: 0 + + msm8939-apcs-clock-controller: + properties: + clocks: + items: + - description: primary pll parent of the clock driver + - description: auxiliary parent + - description: reference clock + clock-names: + items: + - const: pll + - const: aux + - const: ref + '#clock-cells': + const: 0 + + sdx55-apcs-clock-controller: + properties: + clocks: + items: + - description: reference clock + - description: primary pll parent of the clock driver + - description: auxiliary parent + clock-names: + items: + - const: ref + - const: pll + - const: aux + '#clock-cells': + const: 0 + + ipq6018-apcs-clock-controller: + properties: + clocks: + items: + - description: primary pll parent of the clock driver + - description: XO clock + - description: GCC GPLL0 clock source + clock-names: + items: + - const: pll + - const: xo + - const: gpll0 + '#clock-cells': + const: 1 + allOf: - if: properties: @@ -98,15 +187,10 @@ allOf: enum: - qcom,msm8916-apcs-kpss-global then: + $ref: "#/$defs/msm8916-apcs-clock-controller" properties: - clocks: - items: - - description: primary pll parent of the clock driver - - description: auxiliary parent - clock-names: - items: - - const: pll - - const: aux + clock-controller: + $ref: "#/$defs/msm8916-apcs-clock-controller" - if: properties: @@ -115,17 +199,10 @@ allOf: enum: - qcom,msm8939-apcs-kpss-global then: + $ref: "#/$defs/msm8939-apcs-clock-controller" properties: - clocks: - items: - - description: primary pll parent of the clock driver - - description: auxiliary parent - - description: reference clock - clock-names: - items: - - const: pll - - const: aux - - const: ref + clock-controller: + $ref: "#/$defs/msm8939-apcs-clock-controller" - if: properties: @@ -134,17 +211,10 @@ allOf: enum: - qcom,sdx55-apcs-gcc then: + $ref: "#/$defs/sdx55-apcs-clock-controller" properties: - clocks: - items: - - description: reference clock - - description: primary pll parent of the clock driver - - description: auxiliary parent - clock-names: - items: - - const: ref - - const: pll - - const: aux + clock-controller: + $ref: "#/$defs/sdx55-apcs-clock-controller" - if: properties: @@ -153,17 +223,10 @@ allOf: enum: - qcom,ipq6018-apcs-apps-global then: + $ref: "#/$defs/ipq6018-apcs-clock-controller" properties: - clocks: - items: - - description: primary pll parent of the clock driver - - description: XO clock - - description: GCC GPLL0 clock source - clock-names: - items: - - const: pll - - const: xo - - const: gpll0 + clock-controller: + $ref: "#/$defs/ipq6018-apcs-clock-controller" - if: properties: @@ -179,19 +242,7 @@ allOf: properties: clocks: false clock-names: false - - - if: - properties: - compatible: - contains: - enum: - - qcom,ipq6018-apcs-apps-global - then: - properties: - '#clock-cells': - const: 1 - else: - properties: + clock-controller: false '#clock-cells': const: 0 @@ -219,6 +270,23 @@ examples: - | #define GCC_APSS_AHB_CLK_SRC 1 #define GCC_GPLL0_AO_OUT_MAIN 123 + mailbox@b011000 { + compatible = "qcom,qcs404-apcs-apps-global", + "qcom,msm8916-apcs-kpss-global", "syscon"; + reg = <0x0b011000 0x1000>; + #mbox-cells = <1>; + + apcs_clk: clock-controller { + clocks = <&apcs_hfpll>, <&gcc GCC_GPLL0_AO_OUT_MAIN>; + clock-names = "pll", "aux"; + #clock-cells = <0>; + }; + }; + + # Example apcs with qcs404 (deprecated: use clock-controller subnode) + - | + #define GCC_APSS_AHB_CLK_SRC 1 + #define GCC_GPLL0_AO_OUT_MAIN 123 apcs: mailbox@b011000 { compatible = "qcom,qcs404-apcs-apps-global", "qcom,msm8916-apcs-kpss-global", "syscon"; diff --git a/Documentation/devicetree/bindings/mailbox/sophgo,cv1800b-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/sophgo,cv1800b-mailbox.yaml new file mode 100644 index 000000000000..24e126bd3a20 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/sophgo,cv1800b-mailbox.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/sophgo,cv1800b-mailbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sophgo CV1800/SG2000 mailbox controller + +maintainers: + - Yuntao Dai <d1581209858@live.com> + - Junhui Liu <junhui.liu@pigmoral.tech> + +description: + Mailboxes integrated in Sophgo CV1800/SG2000 SoCs have 8 channels, each + shipping an 8-byte FIFO. Any processor can write to an arbitrary channel + and raise interrupts to receivers. Sending messages to itself is also + supported. + +properties: + compatible: + const: sophgo,cv1800b-mailbox + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#mbox-cells": + const: 2 + description: | + <&phandle channel target> + phandle : Label name of mailbox controller + channel : 0-7, Channel index + target : 0-3, Target processor ID + + Sophgo CV1800/SG2000 SoCs include the following processors, numbered as: + <0> Cortex-A53 (Only available on CV181X/SG200X) + <1> C906B + <2> C906L + <3> 8051 + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + mailbox@1900000 { + compatible = "sophgo,cv1800b-mailbox"; + reg = <0x01900000 0x1000>; + interrupts = <101 IRQ_TYPE_LEVEL_HIGH>; + #mbox-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml index 03f31b009085..40fda59fa8a8 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml @@ -16,8 +16,12 @@ description: properties: compatible: - enum: - - mediatek,mt8195-mdp3-fg + oneOf: + - enum: + - mediatek,mt8195-mdp3-fg + - items: + - const: mediatek,mt8188-mdp3-fg + - const: mediatek,mt8195-mdp3-fg reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml index d4609bba6578..d9f926c20220 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml @@ -16,8 +16,12 @@ description: properties: compatible: - enum: - - mediatek,mt8195-mdp3-hdr + oneOf: + - enum: + - mediatek,mt8195-mdp3-hdr + - items: + - const: mediatek,mt8188-mdp3-hdr + - const: mediatek,mt8195-mdp3-hdr reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml index f5676bec4326..8124c39d73e9 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml @@ -20,6 +20,7 @@ properties: - mediatek,mt8183-mdp3-rsz - items: - enum: + - mediatek,mt8188-mdp3-rsz - mediatek,mt8195-mdp3-rsz - const: mediatek,mt8183-mdp3-rsz diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml index d815bea29154..1d8e7e202c42 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml @@ -16,8 +16,12 @@ description: properties: compatible: - enum: - - mediatek,mt8195-mdp3-stitch + oneOf: + - enum: + - mediatek,mt8195-mdp3-stitch + - items: + - const: mediatek,mt8188-mdp3-stitch + - const: mediatek,mt8195-mdp3-stitch reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml index 14ea556d4f82..6cff7c073ce4 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml @@ -17,8 +17,12 @@ description: properties: compatible: - enum: - - mediatek,mt8195-mdp3-tcc + oneOf: + - enum: + - mediatek,mt8195-mdp3-tcc + - items: + - const: mediatek,mt8188-mdp3-tcc + - const: mediatek,mt8195-mdp3-tcc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml index 8ab7f2d8e148..cdfa27324738 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml @@ -16,8 +16,12 @@ description: properties: compatible: - enum: - - mediatek,mt8195-mdp3-tdshp + oneOf: + - enum: + - mediatek,mt8195-mdp3-tdshp + - items: + - const: mediatek,mt8188-mdp3-tdshp + - const: mediatek,mt8195-mdp3-tdshp reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml index 53a679338402..b6269f4f9fd6 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml @@ -20,6 +20,7 @@ properties: - mediatek,mt8183-mdp3-wrot - items: - enum: + - mediatek,mt8188-mdp3-wrot - mediatek,mt8195-mdp3-wrot - const: mediatek,mt8183-mdp3-wrot diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index 2f36ac23604c..0762e0ff66ef 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -33,6 +33,7 @@ properties: - mediatek,mt2712-smi-common - mediatek,mt6779-smi-common - mediatek,mt6795-smi-common + - mediatek,mt6893-smi-common - mediatek,mt8167-smi-common - mediatek,mt8173-smi-common - mediatek,mt8183-smi-common diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index 2381660b324c..2e7fac4b5094 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -21,6 +21,7 @@ properties: - mediatek,mt2712-smi-larb - mediatek,mt6779-smi-larb - mediatek,mt6795-smi-larb + - mediatek,mt6893-smi-larb - mediatek,mt8167-smi-larb - mediatek,mt8173-smi-larb - mediatek,mt8183-smi-larb diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32mp25-omm.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32mp25-omm.yaml new file mode 100644 index 000000000000..344878db8818 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32mp25-omm.yaml @@ -0,0 +1,226 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/st,stm32mp25-omm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STM32 Octo Memory Manager (OMM) + +maintainers: + - Patrice Chotard <patrice.chotard@foss.st.com> + +description: | + The STM32 Octo Memory Manager is a low-level interface that enables an + efficient OCTOSPI pin assignment with a full I/O matrix (before alternate + function map) and multiplex of single/dual/quad/octal SPI interfaces over + the same bus. It Supports up to: + - Two single/dual/quad/octal SPI interfaces + - Two ports for pin assignment + +properties: + compatible: + const: st,stm32mp25-omm + + "#address-cells": + const: 2 + + "#size-cells": + const: 1 + + ranges: + description: | + Reflects the memory layout per OSPI instance. + Format: + <chip-select> 0 <registers base address> <size> + minItems: 2 + maxItems: 2 + + reg: + items: + - description: OMM registers + - description: OMM memory map area + + reg-names: + items: + - const: regs + - const: memory_map + + memory-region: + description: + Memory region shared between the 2 OCTOSPI instance. + One or two phandle to a node describing a memory mapped region + depending of child number. + minItems: 1 + maxItems: 2 + + memory-region-names: + description: + Identify to which OSPI instance the memory region belongs to. + items: + enum: [ospi1, ospi2] + minItems: 1 + maxItems: 2 + + clocks: + maxItems: 3 + + clock-names: + items: + - const: omm + - const: ospi1 + - const: ospi2 + + resets: + maxItems: 3 + + reset-names: + items: + - const: omm + - const: ospi1 + - const: ospi2 + + access-controllers: + maxItems: 1 + + power-domains: + maxItems: 1 + + st,syscfg-amcr: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: | + The Address Mapping Control Register (AMCR) is used to split the 256MB + memory map area shared between the 2 OSPI instance. The Octo Memory + Manager sets the AMCR depending of the memory-region configuration. + The memory split bitmask description is: + - 000: OCTOSPI1 (256 Mbytes), OCTOSPI2 unmapped + - 001: OCTOSPI1 (192 Mbytes), OCTOSPI2 (64 Mbytes) + - 010: OCTOSPI1 (128 Mbytes), OCTOSPI2 (128 Mbytes) + - 011: OCTOSPI1 (64 Mbytes), OCTOSPI2 (192 Mbytes) + - 1xx: OCTOSPI1 unmapped, OCTOSPI2 (256 Mbytes) + items: + - items: + - description: phandle to syscfg + - description: register offset within syscfg + - description: register bitmask for memory split + + st,omm-req2ack-ns: + description: + In multiplexed mode (MUXEN = 1), this field defines the time in + nanoseconds between two transactions. + default: 0 + + st,omm-cssel-ovr: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Configure the chip select selector override for the 2 OCTOSPIs. + - 0: OCTOSPI1 chip select send to NCS1 OCTOSPI2 chip select send to NCS1 + - 1: OCTOSPI1 chip select send to NCS2 OCTOSPI2 chip select send to NCS1 + - 2: OCTOSPI1 chip select send to NCS1 OCTOSPI2 chip select send to NCS2 + - 3: OCTOSPI1 chip select send to NCS2 OCTOSPI2 chip select send to NCS2 + minimum: 0 + maximum: 3 + default: 0 + + st,omm-mux: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Configure the muxing between the 2 OCTOSPIs busses and the 2 output ports. + - 0: direct mode + - 1: mux OCTOSPI1 and OCTOSPI2 to port 1 + - 2: swapped mode + - 3: mux OCTOSPI1 and OCTOSPI2 to port 2 + minimum: 0 + maximum: 3 + default: 0 + +patternProperties: + ^spi@[0-9]: + type: object + $ref: /schemas/spi/st,stm32mp25-ospi.yaml# + description: Required spi child node + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - clocks + - clock-names + - resets + - reset-names + - st,syscfg-amcr + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/st,stm32mp25-rcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/reset/st,stm32mp25-rcc.h> + ommanager@40500000 { + compatible = "st,stm32mp25-omm"; + reg = <0x40500000 0x400>, <0x60000000 0x10000000>; + reg-names = "regs", "memory_map"; + ranges = <0 0 0x40430000 0x400>, + <1 0 0x40440000 0x400>; + memory-region = <&mm_ospi1>, <&mm_ospi2>; + memory-region-names = "ospi1", "ospi2"; + pinctrl-0 = <&ospi_port1_clk_pins_a + &ospi_port1_io03_pins_a + &ospi_port1_cs0_pins_a>; + pinctrl-1 = <&ospi_port1_clk_sleep_pins_a + &ospi_port1_io03_sleep_pins_a + &ospi_port1_cs0_sleep_pins_a>; + pinctrl-names = "default", "sleep"; + clocks = <&rcc CK_BUS_OSPIIOM>, + <&scmi_clk CK_SCMI_OSPI1>, + <&scmi_clk CK_SCMI_OSPI2>; + clock-names = "omm", "ospi1", "ospi2"; + resets = <&rcc OSPIIOM_R>, + <&scmi_reset RST_SCMI_OSPI1>, + <&scmi_reset RST_SCMI_OSPI2>; + reset-names = "omm", "ospi1", "ospi2"; + access-controllers = <&rifsc 111>; + power-domains = <&CLUSTER_PD>; + #address-cells = <2>; + #size-cells = <1>; + st,syscfg-amcr = <&syscfg 0x2c00 0x7>; + st,omm-req2ack-ns = <0>; + st,omm-mux = <0>; + st,omm-cssel-ovr = <0>; + + spi@0 { + compatible = "st,stm32mp25-ospi"; + reg = <0 0 0x400>; + memory-region = <&mm_ospi1>; + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&hpdma 2 0x62 0x00003121 0x0>, + <&hpdma 2 0x42 0x00003112 0x0>; + dma-names = "tx", "rx"; + clocks = <&scmi_clk CK_SCMI_OSPI1>; + resets = <&scmi_reset RST_SCMI_OSPI1>, <&scmi_reset RST_SCMI_OSPI1DLL>; + access-controllers = <&rifsc 74>; + power-domains = <&CLUSTER_PD>; + #address-cells = <1>; + #size-cells = <0>; + st,syscfg-dlyb = <&syscfg 0x1000>; + }; + + spi@1 { + compatible = "st,stm32mp25-ospi"; + reg = <1 0 0x400>; + memory-region = <&mm_ospi1>; + interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&hpdma 3 0x62 0x00003121 0x0>, + <&hpdma 3 0x42 0x00003112 0x0>; + dma-names = "tx", "rx"; + clocks = <&scmi_clk CK_KER_OSPI2>; + resets = <&scmi_reset RST_SCMI_OSPI2>, <&scmi_reset RST_SCMI_OSPI1DLL>; + access-controllers = <&rifsc 75>; + power-domains = <&CLUSTER_PD>; + #address-cells = <1>; + #size-cells = <0>; + st,syscfg-dlyb = <&syscfg 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml index f805545aa62a..f6f47999c6c1 100644 --- a/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml +++ b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml @@ -19,6 +19,7 @@ properties: - items: - enum: - atmel,at91sam9260-gpbr + - microchip,sama7d65-gpbr - const: syscon - items: - enum: diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm59056.txt b/Documentation/devicetree/bindings/mfd/brcm,bcm59056.txt deleted file mode 100644 index be51a15e05f9..000000000000 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm59056.txt +++ /dev/null @@ -1,39 +0,0 @@ -------------------------------- -BCM590xx Power Management Units -------------------------------- - -Required properties: -- compatible: "brcm,bcm59056" -- reg: I2C slave address -- interrupts: interrupt for the PMU. Generic interrupt client node bindings - are described in interrupt-controller/interrupts.txt - ------------------- -Voltage Regulators ------------------- - -Optional child nodes: -- regulators: container node for regulators following the generic - regulator binding in regulator/regulator.txt - - The valid regulator node names for BCM59056 are: - rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo, - mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo, - csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr, - gpldo1, gpldo2, gpldo3, gpldo4, gpldo5, gpldo6, - vbus - -Example: - pmu: bcm59056@8 { - compatible = "brcm,bcm59056"; - reg = <0x08>; - interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>; - regulators { - rfldo_reg: rfldo { - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3300000>; - }; - - ... - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml new file mode 100644 index 000000000000..b67d7a723fc2 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/brcm,bcm59056.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM590xx Power Management Units + +maintainers: + - Artur Weber <aweber.kernel@gmail.com> + +properties: + compatible: + enum: + - brcm,bcm59054 + - brcm,bcm59056 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + regulators: + type: object + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: brcm,bcm59054 + then: + properties: + regulators: + $ref: /schemas/regulator/brcm,bcm59054.yaml# + + - if: + properties: + compatible: + contains: + const: brcm,bcm59056 + then: + properties: + regulators: + $ref: /schemas/regulator/brcm,bcm59056.yaml# + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@8 { + compatible = "brcm,bcm59056"; + reg = <0x08>; + interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>; + + regulators { + rfldo { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/iqs62x.yaml b/Documentation/devicetree/bindings/mfd/iqs62x.yaml index e79ce447a800..f242dd0e18fd 100644 --- a/Documentation/devicetree/bindings/mfd/iqs62x.yaml +++ b/Documentation/devicetree/bindings/mfd/iqs62x.yaml @@ -60,43 +60,34 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> i2c { - #address-cells = <1>; - #size-cells = <0>; - - iqs620a@44 { - compatible = "azoteq,iqs620a"; - reg = <0x44>; - interrupt-parent = <&gpio>; - interrupts = <17 IRQ_TYPE_LEVEL_LOW>; - - keys { - compatible = "azoteq,iqs620a-keys"; - - linux,keycodes = <KEY_SELECT>, - <KEY_MENU>, - <KEY_OK>, - <KEY_MENU>; - - hall-switch-south { - linux,code = <SW_LID>; - azoteq,use-prox; - }; - }; - - iqs620a_pwm: pwm { - compatible = "azoteq,iqs620a-pwm"; - #pwm-cells = <2>; - }; + #address-cells = <1>; + #size-cells = <0>; + + iqs620a@44 { + compatible = "azoteq,iqs620a"; + reg = <0x44>; + interrupt-parent = <&gpio>; + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; + + keys { + compatible = "azoteq,iqs620a-keys"; + + linux,keycodes = <KEY_SELECT>, + <KEY_MENU>, + <KEY_OK>, + <KEY_MENU>; + + hall-switch-south { + linux,code = <SW_LID>; + azoteq,use-prox; + }; }; - }; - - pwmleds { - compatible = "pwm-leds"; - led-1 { - pwms = <&iqs620a_pwm 0 1000000>; - max-brightness = <255>; + iqs620a_pwm: pwm { + compatible = "azoteq,iqs620a-pwm"; + #pwm-cells = <2>; }; + }; }; - | @@ -105,37 +96,37 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> i2c { - #address-cells = <1>; - #size-cells = <0>; - - iqs620a@44 { - compatible = "azoteq,iqs620a"; - reg = <0x44>; - interrupt-parent = <&gpio>; - interrupts = <17 IRQ_TYPE_LEVEL_LOW>; - - firmware-name = "iqs620a_coil.bin"; - - keys { - compatible = "azoteq,iqs620a-keys"; - - linux,keycodes = <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <KEY_MUTE>; - - hall-switch-north { - linux,code = <SW_DOCK>; - }; - - hall-switch-south { - linux,code = <SW_TABLET_MODE>; - }; - }; + #address-cells = <1>; + #size-cells = <0>; + + iqs620a@44 { + compatible = "azoteq,iqs620a"; + reg = <0x44>; + interrupt-parent = <&gpio>; + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; + + firmware-name = "iqs620a_coil.bin"; + + keys { + compatible = "azoteq,iqs620a-keys"; + + linux,keycodes = <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <KEY_MUTE>; + + hall-switch-north { + linux,code = <SW_DOCK>; + }; + + hall-switch-south { + linux,code = <SW_TABLET_MODE>; + }; }; + }; }; - | @@ -144,36 +135,36 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> i2c { - #address-cells = <1>; - #size-cells = <0>; - - iqs624@44 { - compatible = "azoteq,iqs624"; - reg = <0x44>; - interrupt-parent = <&gpio>; - interrupts = <17 IRQ_TYPE_LEVEL_LOW>; - - keys { - compatible = "azoteq,iqs624-keys"; - - linux,keycodes = <BTN_0>, - <0>, - <BTN_1>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <KEY_VOLUMEUP>, - <KEY_VOLUMEDOWN>; - }; + #address-cells = <1>; + #size-cells = <0>; + + iqs624@44 { + compatible = "azoteq,iqs624"; + reg = <0x44>; + interrupt-parent = <&gpio>; + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; + + keys { + compatible = "azoteq,iqs624-keys"; + + linux,keycodes = <BTN_0>, + <0>, + <BTN_1>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <KEY_VOLUMEUP>, + <KEY_VOLUMEDOWN>; }; + }; }; ... diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml index 768390b92682..0e1d43c96fb9 100644 --- a/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml @@ -18,6 +18,7 @@ properties: compatible: items: - enum: + - mediatek,mt6893-scpsys - mediatek,mt8167-scpsys - mediatek,mt8173-scpsys - mediatek,mt8183-scpsys diff --git a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml index 8bd1abfc44d9..b613da83dca4 100644 --- a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml +++ b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml @@ -76,12 +76,6 @@ additionalProperties: false examples: - | - ocelot_clock: ocelot-clock { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <125000000>; - }; - spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml index 59a630025f52..37fbb953ea12 100644 --- a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml +++ b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml @@ -48,29 +48,18 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> i2c { - #address-cells = <1>; - #size-cells = <0>; - - ec: embedded-controller@43 { - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_ntxec>; - - compatible = "netronix,ntxec"; - reg = <0x43>; - system-power-controller; - interrupt-parent = <&gpio4>; - interrupts = <11 IRQ_TYPE_EDGE_FALLING>; - #pwm-cells = <2>; - }; - }; - - backlight { - compatible = "pwm-backlight"; - pwms = <&ec 0 50000>; - power-supply = <&backlight_regulator>; - }; - - backlight_regulator: regulator-dummy { - compatible = "regulator-fixed"; - regulator-name = "backlight"; + #address-cells = <1>; + #size-cells = <0>; + + ec: embedded-controller@43 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ntxec>; + + compatible = "netronix,ntxec"; + reg = <0x43>; + system-power-controller; + interrupt-parent = <&gpio4>; + interrupts = <11 IRQ_TYPE_EDGE_FALLING>; + #pwm-cells = <2>; + }; }; diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml index 7e7225aadae3..14ae3f00ef7e 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml @@ -41,6 +41,7 @@ properties: - qcom,sm8450-tcsr - qcom,tcsr-apq8064 - qcom,tcsr-apq8084 + - qcom,tcsr-ipq5018 - qcom,tcsr-ipq5332 - qcom,tcsr-ipq5424 - qcom,tcsr-ipq6018 diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml index 534cf03f36bb..47611c2a982c 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml @@ -99,29 +99,29 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> i2c { - #address-cells = <1>; - #size-cells = <0>; - - pmic: pmic@30 { - compatible = "rohm,bd9571mwv"; - reg = <0x30>; - interrupt-parent = <&gpio2>; - interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <2>; - gpio-controller; - #gpio-cells = <2>; - rohm,ddr-backup-power = <0xf>; - rohm,rstbmode-pulse; - - regulators { - dvfs: dvfs { - regulator-name = "dvfs"; - regulator-min-microvolt = <750000>; - regulator-max-microvolt = <1030000>; - regulator-boot-on; - regulator-always-on; - }; - }; - }; + #address-cells = <1>; + #size-cells = <0>; + + pmic: pmic@30 { + compatible = "rohm,bd9571mwv"; + reg = <0x30>; + interrupt-parent = <&gpio2>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-controller; + #gpio-cells = <2>; + rohm,ddr-backup-power = <0xf>; + rohm,rstbmode-pulse; + + regulators { + dvfs: dvfs { + regulator-name = "dvfs"; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <1030000>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml index efee3de0d9ad..0e06570483ae 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml @@ -4,19 +4,21 @@ $id: http://devicetree.org/schemas/mfd/rohm,bd96801-pmic.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: ROHM BD96801 Scalable Power Management Integrated Circuit +title: ROHM BD96801/BD96805 Scalable Power Management Integrated Circuit maintainers: - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> description: - BD96801 is an automotive grade single-chip power management IC. - It integrates 4 buck converters and 3 LDOs with safety features like + BD96801 and BD96805 are automotive grade, single-chip power management ICs. + They both integrate 4 buck converters and 3 LDOs with safety features like over-/under voltage and over current detection and a watchdog. properties: compatible: - const: rohm,bd96801 + enum: + - rohm,bd96801 + - rohm,bd96805 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml new file mode 100644 index 000000000000..6cbea796d12f --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/rohm,bd96802-pmic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BD96802 / BD96806 Scalable Power Management Integrated Circuit + +maintainers: + - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> + +description: | + BD96802Qxx-C and BD96806 are automotive grade configurable Power Management + Integrated Circuits supporting Functional Safety features for application + processors, SoCs and FPGAs + +properties: + compatible: + enum: + - rohm,bd96802 + - rohm,bd96806 + + reg: + maxItems: 1 + + interrupts: + description: + The PMIC provides intb and errb IRQ lines. The errb IRQ line is used + for fatal IRQs which will cause the PMIC to shut down power outputs. + In many systems this will shut down the SoC contolling the PMIC and + connecting/handling the errb can be omitted. However, there are cases + where the SoC is not powered by the PMIC or has a short time backup + energy to handle shutdown of critical hardware. In that case it may be + useful to connect the errb and handle errb events. + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + items: + - enum: [intb, errb] + - const: errb + + regulators: + $ref: ../regulator/rohm,bd96802-regulator.yaml + description: + List of child nodes that specify the regulators. + +required: + - compatible + - reg + - interrupts + - interrupt-names + - regulators + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/leds/common.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + pmic: pmic@62 { + reg = <0x62>; + compatible = "rohm,bd96802"; + interrupt-parent = <&gpio1>; + interrupts = <29 IRQ_TYPE_LEVEL_LOW>, <6 IRQ_TYPE_LEVEL_LOW>; + interrupt-names = "intb", "errb"; + + regulators { + buck1 { + regulator-name = "buck1"; + regulator-ramp-delay = <1250>; + /* 0.5V min INITIAL - 150 mV tune */ + regulator-min-microvolt = <350000>; + /* 3.3V + 150mV tune */ + regulator-max-microvolt = <3450000>; + + /* These can be set only when PMIC is in STBY */ + rohm,initial-voltage-microvolt = <500000>; + regulator-ov-error-microvolt = <230000>; + regulator-uv-error-microvolt = <230000>; + regulator-temp-protection-kelvin = <1>; + regulator-temp-warn-kelvin = <0>; + }; + buck2 { + regulator-name = "buck2"; + regulator-min-microvolt = <350000>; + regulator-max-microvolt = <3450000>; + + rohm,initial-voltage-microvolt = <3000000>; + regulator-ov-error-microvolt = <18000>; + regulator-uv-error-microvolt = <18000>; + regulator-temp-protection-kelvin = <1>; + regulator-temp-warn-kelvin = <1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml index ac5d0c149796..d6b9e2914796 100644 --- a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml +++ b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml @@ -20,6 +20,7 @@ description: | properties: compatible: enum: + - samsung,s2mpg10-pmic - samsung,s2mps11-pmic - samsung,s2mps13-pmic - samsung,s2mps14-pmic @@ -58,11 +59,12 @@ properties: reset (setting buck voltages to default values). type: boolean + system-power-controller: true + wakeup-source: true required: - compatible - - reg - regulators additionalProperties: false @@ -72,6 +74,28 @@ allOf: properties: compatible: contains: + const: samsung,s2mpg10-pmic + then: + properties: + reg: false + samsung,s2mps11-acokb-ground: false + samsung,s2mps11-wrstbi-ground: false + + oneOf: + - required: [interrupts] + - required: [interrupts-extended] + + else: + properties: + system-power-controller: false + + required: + - reg + + - if: + properties: + compatible: + contains: const: samsung,s2mps11-pmic then: properties: diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml index d41308856408..4eabafb8079d 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml @@ -21,7 +21,12 @@ maintainers: properties: compatible: - const: st,stm32-lptimer + oneOf: + - items: + - const: st,stm32mp25-lptimer + - const: st,stm32-lptimer + - items: + - const: st,stm32-lptimer reg: maxItems: 1 @@ -48,13 +53,21 @@ properties: minItems: 1 maxItems: 2 + power-domains: + maxItems: 1 + pwm: type: object additionalProperties: false properties: compatible: - const: st,stm32-pwm-lp + oneOf: + - items: + - const: st,stm32mp25-pwm-lp + - const: st,stm32-pwm-lp + - items: + - const: st,stm32-pwm-lp "#pwm-cells": const: 3 @@ -69,7 +82,12 @@ properties: properties: compatible: - const: st,stm32-lptimer-counter + oneOf: + - items: + - const: st,stm32mp25-lptimer-counter + - const: st,stm32-lptimer-counter + - items: + - const: st,stm32-lptimer-counter required: - compatible @@ -80,7 +98,12 @@ properties: properties: compatible: - const: st,stm32-lptimer-timer + oneOf: + - items: + - const: st,stm32mp25-lptimer-timer + - const: st,stm32-lptimer-timer + - items: + - const: st,stm32-lptimer-timer required: - compatible @@ -92,13 +115,18 @@ patternProperties: properties: compatible: - const: st,stm32-lptimer-trigger + oneOf: + - items: + - const: st,stm32mp25-lptimer-trigger + - const: st,stm32-lptimer-trigger + - items: + - const: st,stm32-lptimer-trigger reg: description: Identify trigger hardware block. items: minimum: 0 - maximum: 2 + maximum: 4 required: - compatible diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index c6bbb19c3e3e..27672adeb1fe 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -84,6 +84,7 @@ select: - mediatek,mt2701-pctl-a-syscfg - mediatek,mt2712-pctl-a-syscfg - mediatek,mt6397-pctl-pmic-syscfg + - mediatek,mt7988-topmisc - mediatek,mt8135-pctl-a-syscfg - mediatek,mt8135-pctl-b-syscfg - mediatek,mt8173-pctl-a-syscfg @@ -98,6 +99,8 @@ select: - mstar,msc313-pmsleep - nuvoton,ma35d1-sys - nuvoton,wpcm450-shm + - qcom,apq8064-mmss-sfpb + - qcom,apq8064-sps-sic - rockchip,px30-qos - rockchip,rk3036-qos - rockchip,rk3066-qos @@ -187,9 +190,11 @@ properties: - mediatek,mt2701-pctl-a-syscfg - mediatek,mt2712-pctl-a-syscfg - mediatek,mt6397-pctl-pmic-syscfg + - mediatek,mt7988-topmisc - mediatek,mt8135-pctl-a-syscfg - mediatek,mt8135-pctl-b-syscfg - mediatek,mt8173-pctl-a-syscfg + - mediatek,mt8365-infracfg-nao - mediatek,mt8365-syscfg - microchip,lan966x-cpu-syscon - microchip,mpfs-sysreg-scb @@ -201,6 +206,8 @@ properties: - mstar,msc313-pmsleep - nuvoton,ma35d1-sys - nuvoton,wpcm450-shm + - qcom,apq8064-mmss-sfpb + - qcom,apq8064-sps-sic - rockchip,px30-qos - rockchip,rk3036-qos - rockchip,rk3066-qos diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml index 3f7661bdd202..45f015d63df1 100644 --- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml +++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml @@ -316,106 +316,106 @@ additionalProperties: false examples: - | - i2c { - #address-cells = <1>; - #size-cells = <0>; - - pmic@30 { - compatible = "x-powers,axp152"; - reg = <0x30>; - interrupts = <0>; - interrupt-controller; - #interrupt-cells = <1>; - }; - }; + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@30 { + compatible = "x-powers,axp152"; + reg = <0x30>; + interrupts = <0>; + interrupt-controller; + #interrupt-cells = <1>; + }; + }; - | - #include <dt-bindings/interrupt-controller/irq.h> - - i2c { - #address-cells = <1>; - #size-cells = <0>; - - pmic@34 { - compatible = "x-powers,axp209"; - reg = <0x34>; - interrupt-parent = <&nmi_intc>; - interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <1>; - - ac_power_supply: ac-power { - compatible = "x-powers,axp202-ac-power-supply"; - }; - - axp_adc: adc { - compatible = "x-powers,axp209-adc"; - #io-channel-cells = <1>; - }; - - axp_gpio: gpio { - compatible = "x-powers,axp209-gpio"; - gpio-controller; - #gpio-cells = <2>; - - gpio0-adc-pin { - pins = "GPIO0"; - function = "adc"; - }; - }; - - battery_power_supply: battery-power { - compatible = "x-powers,axp209-battery-power-supply"; - }; - - regulators { - /* Default work frequency for buck regulators */ - x-powers,dcdc-freq = <1500>; - - reg_dcdc2: dcdc2 { - regulator-always-on; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1450000>; - regulator-name = "vdd-cpu"; - }; - - reg_dcdc3: dcdc3 { - regulator-always-on; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1400000>; - regulator-name = "vdd-int-dll"; - }; - - reg_ldo1: ldo1 { - /* LDO1 is a fixed output regulator */ - regulator-always-on; - regulator-min-microvolt = <1300000>; - regulator-max-microvolt = <1300000>; - regulator-name = "vdd-rtc"; - }; - - reg_ldo2: ldo2 { - regulator-always-on; - regulator-min-microvolt = <3000000>; - regulator-max-microvolt = <3000000>; - regulator-name = "avcc"; - }; - - reg_ldo3: ldo3 { - regulator-name = "ldo3"; - }; - - reg_ldo4: ldo4 { - regulator-name = "ldo4"; - }; - - reg_ldo5: ldo5 { - regulator-name = "ldo5"; - }; - }; - - usb_power_supply: usb-power { - compatible = "x-powers,axp202-usb-power-supply"; - }; - }; - }; + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@34 { + compatible = "x-powers,axp209"; + reg = <0x34>; + interrupt-parent = <&nmi_intc>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <1>; + + ac_power_supply: ac-power { + compatible = "x-powers,axp202-ac-power-supply"; + }; + + axp_adc: adc { + compatible = "x-powers,axp209-adc"; + #io-channel-cells = <1>; + }; + + axp_gpio: gpio { + compatible = "x-powers,axp209-gpio"; + gpio-controller; + #gpio-cells = <2>; + + gpio0-adc-pin { + pins = "GPIO0"; + function = "adc"; + }; + }; + + battery_power_supply: battery-power { + compatible = "x-powers,axp209-battery-power-supply"; + }; + + regulators { + /* Default work frequency for buck regulators */ + x-powers,dcdc-freq = <1500>; + + reg_dcdc2: dcdc2 { + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1450000>; + regulator-name = "vdd-cpu"; + }; + + reg_dcdc3: dcdc3 { + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1400000>; + regulator-name = "vdd-int-dll"; + }; + + reg_ldo1: ldo1 { + /* LDO1 is a fixed output regulator */ + regulator-always-on; + regulator-min-microvolt = <1300000>; + regulator-max-microvolt = <1300000>; + regulator-name = "vdd-rtc"; + }; + + reg_ldo2: ldo2 { + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "avcc"; + }; + + reg_ldo3: ldo3 { + regulator-name = "ldo3"; + }; + + reg_ldo4: ldo4 { + regulator-name = "ldo4"; + }; + + reg_ldo5: ldo5 { + regulator-name = "ldo5"; + }; + }; + + usb_power_supply: usb-power { + compatible = "x-powers,axp202-usb-power-supply"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/fsl,vf610-nfc.yaml b/Documentation/devicetree/bindings/mtd/fsl,vf610-nfc.yaml new file mode 100644 index 000000000000..480a5c87859d --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/fsl,vf610-nfc.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/fsl,vf610-nfc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale's NAND flash controller (NFC) + +description: + This variant of the Freescale NAND flash controller (NFC) can be found on + Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70. + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +properties: + compatible: + enum: + - fsl,vf610-nfc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: nfc + +patternProperties: + "^nand@[a-f0-9]$": + type: object + $ref: raw-nand-chip.yaml + + properties: + compatible: + const: fsl,vf610-nfc-nandcs + + reg: + const: 0 + + nand-ecc-strength: + enum: [24, 32] + + nand-ecc-step-size: + const: 2048 + + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + +allOf: + - $ref: nand-controller.yaml + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/vf610-clock.h> + + nand-controller@400e0000 { + compatible = "fsl,vf610-nfc"; + reg = <0x400e0000 0x4000>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks VF610_CLK_NFC>; + clock-names = "nfc"; + assigned-clocks = <&clks VF610_CLK_NFC>; + assigned-clock-rates = <33000000>; + + nand@0 { + compatible = "fsl,vf610-nfc-nandcs"; + reg = <0>; + nand-bus-width = <8>; + nand-ecc-mode = "hw"; + nand-ecc-strength = <32>; + nand-ecc-step-size = <2048>; + nand-on-flash-bbt; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/loongson,ls1b-nand-controller.yaml b/Documentation/devicetree/bindings/mtd/loongson,ls1b-nand-controller.yaml new file mode 100644 index 000000000000..a09e92e416c4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/loongson,ls1b-nand-controller.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/loongson,ls1b-nand-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson-1 NAND Controller + +maintainers: + - Keguang Zhang <keguang.zhang@gmail.com> + +description: + The Loongson-1 NAND controller abstracts all supported operations, + meaning it does not support low-level access to raw NAND flash chips. + Moreover, the controller is paired with the DMA engine to perform + READ and PROGRAM functions. + +allOf: + - $ref: nand-controller.yaml + +properties: + compatible: + oneOf: + - enum: + - loongson,ls1b-nand-controller + - loongson,ls1c-nand-controller + - items: + - enum: + - loongson,ls1a-nand-controller + - const: loongson,ls1b-nand-controller + + reg: + maxItems: 2 + + reg-names: + items: + - const: nand + - const: nand-dma + + dmas: + maxItems: 1 + + dma-names: + const: rxtx + +required: + - compatible + - reg + - reg-names + - dmas + - dma-names + +unevaluatedProperties: false + +examples: + - | + nand-controller@1fe78000 { + compatible = "loongson,ls1b-nand-controller"; + reg = <0x1fe78000 0x24>, <0x1fe78040 0x4>; + reg-names = "nand", "nand-dma"; + dmas = <&dma 0>; + dma-names = "rxtx"; + #address-cells = <1>; + #size-cells = <0>; + + nand@0 { + reg = <0>; + label = "ls1x-nand"; + nand-use-soft-ecc-engine; + nand-ecc-algo = "hamming"; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml index 35b4206ea918..5511389960f0 100644 --- a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml +++ b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml @@ -11,12 +11,18 @@ maintainers: properties: compatible: - enum: - - qcom,ipq806x-nand - - qcom,ipq4019-nand - - qcom,ipq6018-nand - - qcom,ipq8074-nand - - qcom,sdx55-nand + oneOf: + - items: + - enum: + - qcom,sdx75-nand + - const: qcom,sdx55-nand + - items: + - enum: + - qcom,ipq806x-nand + - qcom,ipq4019-nand + - qcom,ipq6018-nand + - qcom,ipq8074-nand + - qcom,sdx55-nand reg: maxItems: 1 @@ -100,6 +106,18 @@ allOf: compatible: contains: enum: + - qcom,sdx75-nand + + then: + properties: + iommus: + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: - qcom,ipq4019-nand - qcom,ipq6018-nand - qcom,ipq8074-nand diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt deleted file mode 100644 index 7db5e6e609df..000000000000 --- a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt +++ /dev/null @@ -1,59 +0,0 @@ -Freescale's NAND flash controller (NFC) - -This variant of the Freescale NAND flash controller (NFC) can be found on -Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70. - -Required properties: -- compatible: Should be set to "fsl,vf610-nfc". -- reg: address range of the NFC. -- interrupts: interrupt of the NFC. -- #address-cells: shall be set to 1. Encode the nand CS. -- #size-cells : shall be set to 0. -- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>; -- assigned-clock-rates: The NAND bus timing is derived from this clock - rate and should not exceed maximum timing for any NAND memory chip - in a board stuffing. Typical NAND memory timings derived from this - clock are found in the SoC hardware reference manual. Furthermore, - there might be restrictions on maximum rates when using hardware ECC. - -- #address-cells, #size-cells : Must be present if the device has sub-nodes - representing partitions. - -Required children nodes: -Children nodes represent the available nand chips. Currently the driver can -only handle one NAND chip. - -Required properties: -- compatible: Should be set to "fsl,vf610-nfc-cs". -- nand-bus-width: see nand-controller.yaml -- nand-ecc-mode: see nand-controller.yaml - -Required properties for hardware ECC: -- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand-controller.yaml) -- nand-ecc-step-size: step size equals page size, currently only 2k pages are - supported -- nand-on-flash-bbt: see nand-controller.yaml - -Example: - - nfc: nand@400e0000 { - compatible = "fsl,vf610-nfc"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x400e0000 0x4000>; - interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks VF610_CLK_NFC>; - clock-names = "nfc"; - assigned-clocks = <&clks VF610_CLK_NFC>; - assigned-clock-rates = <33000000>; - - nand@0 { - compatible = "fsl,vf610-nfc-nandcs"; - reg = <0>; - nand-bus-width = <8>; - nand-ecc-mode = "hw"; - nand-ecc-strength = <32>; - nand-ecc-step-size = <2048>; - nand-on-flash-bbt; - }; - }; diff --git a/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml b/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml index a0f9d49ff8fb..90c7dc7632c5 100644 --- a/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm PMI8998/PM660 Switch-Mode Battery Charger "2" maintainers: - - Caleb Connolly <caleb.connolly@linaro.org> + - Casey Connolly <casey.connolly@linaro.org> properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/brcm,bcm59054.yaml b/Documentation/devicetree/bindings/regulator/brcm,bcm59054.yaml new file mode 100644 index 000000000000..5b46d7fca05e --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/brcm,bcm59054.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/brcm,bcm59054.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM59054 Power Management Unit regulators + +description: | + This is a part of device tree bindings for the BCM59054 power + management unit. + + See Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml for + additional information and example. + +maintainers: + - Artur Weber <aweber.kernel@gmail.com> + +patternProperties: + "^(cam|sim|mmc)ldo[1-2]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(rf|sd|sdx|aud|mic|usb|vib|tcx)ldo$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(c|mm|v)sr$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(io|sd)sr[1-2]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^gpldo[1-3]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^lvldo[1-2]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + +properties: + vbus: + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/brcm,bcm59056.yaml b/Documentation/devicetree/bindings/regulator/brcm,bcm59056.yaml new file mode 100644 index 000000000000..7a5e36394d21 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/brcm,bcm59056.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/brcm,bcm59056.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM59056 Power Management Unit regulators + +description: | + This is a part of device tree bindings for the BCM59056 power + management unit. + + See Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml for + additional information and example. + +maintainers: + - Artur Weber <aweber.kernel@gmail.com> + +patternProperties: + "^(cam|sim|mmc)ldo[1-2]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(rf|sd|sdx|aud|mic|usb|vib)ldo$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(c|m|v)sr$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(io|sd)sr[1-2]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^gpldo[1-6]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + +properties: + vbus: + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd96802-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd96802-regulator.yaml new file mode 100644 index 000000000000..671eaf1096d3 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/rohm,bd96802-regulator.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/rohm,bd96802-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BD96802 Power Management Integrated Circuit regulators + +maintainers: + - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> + +description: + This module is part of the ROHM BD96802 MFD device. For more details + see Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml. + + The regulator controller is represented as a sub-node of the PMIC node + on the device tree. + + Regulator nodes should be named to buck1 and buck2. + +patternProperties: + "^buck[1-2]$": + type: object + description: + Properties for single BUCK regulator. + $ref: regulator.yaml# + + properties: + rohm,initial-voltage-microvolt: + description: + Initial voltage for regulator. Voltage can be tuned +/-150 mV from + this value. NOTE, This can be modified via I2C only when PMIC is in + STBY state. + minimum: 500000 + maximum: 3300000 + + rohm,keep-on-stby: + description: + Keep the regulator powered when PMIC transitions to STBY state. + type: boolean + + unevaluatedProperties: false + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml index 56ff6386534d..5dcc2a32c080 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml @@ -16,6 +16,9 @@ description: properties: compatible: enum: + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas + - qcom,sc8180x-slpi-pas - qcom,sm8150-adsp-pas - qcom,sm8150-cdsp-pas - qcom,sm8150-mpss-pas diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml index fd3423e6051b..6d09823153fc 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml @@ -15,16 +15,20 @@ description: properties: compatible: - enum: - - qcom,sar2130p-adsp-pas - - qcom,sm8350-adsp-pas - - qcom,sm8350-cdsp-pas - - qcom,sm8350-slpi-pas - - qcom,sm8350-mpss-pas - - qcom,sm8450-adsp-pas - - qcom,sm8450-cdsp-pas - - qcom,sm8450-mpss-pas - - qcom,sm8450-slpi-pas + oneOf: + - enum: + - qcom,sar2130p-adsp-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-cdsp-pas + - qcom,sm8350-slpi-pas + - qcom,sm8350-mpss-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-cdsp-pas + - qcom,sm8450-mpss-pas + - qcom,sm8450-slpi-pas + - items: + - const: qcom,sc8280xp-slpi-pas + - const: qcom,sm8350-slpi-pas reg: maxItems: 1 @@ -61,14 +65,15 @@ allOf: - if: properties: compatible: - enum: - - qcom,sar2130p-adsp-pas - - qcom,sm8350-adsp-pas - - qcom,sm8350-cdsp-pas - - qcom,sm8350-slpi-pas - - qcom,sm8450-adsp-pas - - qcom,sm8450-cdsp-pas - - qcom,sm8450-slpi-pas + contains: + enum: + - qcom,sar2130p-adsp-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-cdsp-pas + - qcom,sm8350-slpi-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-cdsp-pas + - qcom,sm8450-slpi-pas then: properties: interrupts: @@ -102,12 +107,13 @@ allOf: - if: properties: compatible: - enum: - - qcom,sar2130p-adsp-pas - - qcom,sm8350-adsp-pas - - qcom,sm8350-slpi-pas - - qcom,sm8450-adsp-pas - - qcom,sm8450-slpi-pas + contains: + enum: + - qcom,sar2130p-adsp-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-slpi-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-slpi-pas then: properties: power-domains: diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index 370af61d8f28..843679c557e7 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -139,6 +139,10 @@ properties: If defined, when remoteproc is probed, it loads the default firmware and starts the remote processor. + firmware-name: + maxItems: 1 + description: Default name of the remote processor firmware. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml index 695ef38a7bb3..150e95c0d9be 100644 --- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml +++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml @@ -12,14 +12,20 @@ maintainers: properties: compatible: - enum: - - amlogic,meson8b-reset # Reset Controller on Meson8b and compatible SoCs - - amlogic,meson-gxbb-reset # Reset Controller on GXBB and compatible SoCs - - amlogic,meson-axg-reset # Reset Controller on AXG and compatible SoCs - - amlogic,meson-a1-reset # Reset Controller on A1 and compatible SoCs - - amlogic,meson-s4-reset # Reset Controller on S4 and compatible SoCs - - amlogic,c3-reset # Reset Controller on C3 and compatible SoCs - - amlogic,t7-reset + oneOf: + - enum: + - amlogic,meson8b-reset # Reset Controller on Meson8b and compatible SoCs + - amlogic,meson-gxbb-reset # Reset Controller on GXBB and compatible SoCs + - amlogic,meson-axg-reset # Reset Controller on AXG and compatible SoCs + - amlogic,meson-a1-reset # Reset Controller on A1 and compatible SoCs + - amlogic,meson-s4-reset # Reset Controller on S4 and compatible SoCs + - amlogic,c3-reset # Reset Controller on C3 and compatible SoCs + - amlogic,t7-reset + - items: + - enum: + - amlogic,a4-reset + - amlogic,a5-reset + - const: amlogic,meson-s4-reset reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml b/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml new file mode 100644 index 000000000000..c79f61c2373b --- /dev/null +++ b/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/renesas,rzv2h-usb2phy-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/V2H(P) USB2PHY Port reset Control + +maintainers: + - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> + +description: + The RZ/V2H(P) USB2PHY Control mainly controls Port reset and power down of the + USB2.0 PHY. + +properties: + compatible: + const: renesas,r9a09g057-usb2phy-reset # RZ/V2H(P) + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + power-domains: + maxItems: 1 + + '#reset-cells': + const: 0 + +required: + - compatible + - reg + - clocks + - resets + - power-domains + - '#reset-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/renesas,r9a09g057-cpg.h> + + reset-controller@15830000 { + compatible = "renesas,r9a09g057-usb2phy-reset"; + reg = <0x15830000 0x10000>; + clocks = <&cpg CPG_MOD 0xb6>; + resets = <&cpg 0xaf>; + power-domains = <&cpg>; + #reset-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/reset/sophgo,sg2042-reset.yaml b/Documentation/devicetree/bindings/reset/sophgo,sg2042-reset.yaml index 76e1931f0908..1d1b84575960 100644 --- a/Documentation/devicetree/bindings/reset/sophgo,sg2042-reset.yaml +++ b/Documentation/devicetree/bindings/reset/sophgo,sg2042-reset.yaml @@ -11,7 +11,12 @@ maintainers: properties: compatible: - const: sophgo,sg2042-reset + oneOf: + - items: + - enum: + - sophgo,sg2044-reset + - const: sophgo,sg2042-reset + - const: sophgo,sg2042-reset reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml b/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml new file mode 100644 index 000000000000..f2e91d0add7a --- /dev/null +++ b/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/thead,th1520-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: T-HEAD TH1520 SoC Reset Controller + +description: + The T-HEAD TH1520 reset controller is a hardware block that asserts/deasserts + resets for SoC subsystems. + +maintainers: + - Michal Wilczynski <m.wilczynski@samsung.com> + +properties: + compatible: + enum: + - thead,th1520-reset + + reg: + maxItems: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - "#reset-cells" + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + rst: reset-controller@ffef528000 { + compatible = "thead,th1520-reset"; + reg = <0xff 0xef528000 0x0 0x1000>; + #reset-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/riscv/sophgo.yaml b/Documentation/devicetree/bindings/riscv/sophgo.yaml index a14cb10ff3f0..b4c4d7a7d7ad 100644 --- a/Documentation/devicetree/bindings/riscv/sophgo.yaml +++ b/Documentation/devicetree/bindings/riscv/sophgo.yaml @@ -35,6 +35,10 @@ properties: - enum: - milkv,pioneer - const: sophgo,sg2042 + - items: + - enum: + - sophgo,srd3-10 + - const: sophgo,sg2044 additionalProperties: true diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml index 77c281153010..39d4637c2d08 100644 --- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml @@ -22,6 +22,8 @@ properties: - amlogic,meson-axg-clk-measure - amlogic,meson-g12a-clk-measure - amlogic,meson-sm1-clk-measure + - amlogic,c3-clk-measure + - amlogic,s4-clk-measure reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml b/Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml new file mode 100644 index 000000000000..2be022ca6a7d --- /dev/null +++ b/Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/google/google,gs101-pmu-intr-gen.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Google Power Management Unit (PMU) Interrupt Generation + +description: | + PMU interrupt generator for handshaking between PMU through interrupts. + +maintainers: + - Peter Griffin <peter.griffin@linaro.org> + +properties: + compatible: + items: + - const: google,gs101-pmu-intr-gen + - const: syscon + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + pmu_intr_gen: syscon@17470000 { + compatible = "google,gs101-pmu-intr-gen", "syscon"; + reg = <0x17470000 0x10000>; + }; diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml index 1ad5b61b249f..4c96d4917967 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml @@ -23,6 +23,7 @@ properties: compatible: oneOf: - enum: + - mediatek,mt6893-dvfsrc - mediatek,mt8183-dvfsrc - mediatek,mt8195-dvfsrc - items: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml index b00be9e01206..3e8d99cb4dc3 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml @@ -36,6 +36,13 @@ properties: - const: err - const: wakeup + clocks: + maxItems: 1 + + clock-names: + items: + - const: ram + qcom,ipc: $ref: /schemas/types.yaml#/definitions/phandle-array items: @@ -46,6 +53,14 @@ properties: description: Three entries specifying the outgoing ipc bit used for signaling the RPM. + clock-controller: + type: object + additionalProperties: true + properties: + compatible: + contains: + const: qcom,rpmcc + patternProperties: "^regulators(-[01])?$": type: object diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml index af632d0e0355..036562eb5140 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml @@ -44,7 +44,13 @@ description: | properties: compatible: - const: qcom,rpmh-rsc + oneOf: + - items: + - enum: + - qcom,sc7180-rpmh-apps-rsc + - qcom,sdm845-rpmh-apps-rsc + - const: qcom,rpmh-rsc + - const: qcom,rpmh-rsc interrupts: minItems: 1 @@ -124,7 +130,21 @@ required: - qcom,tcs-offset - reg - reg-names - - power-domains + +allOf: + # Some platforms may lack a OSI-mode PSCI implementation, which implies the + # system power domain can't provide feedback about entering power collapse + - if: + not: + properties: + compatible: + contains: + enum: + - qcom,sc7180-rpmh-apps-rsc + - qcom,sdm845-rpmh-apps-rsc + then: + required: + - power-domains additionalProperties: false diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml index 0389355b9eca..5e6e6e6208dc 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml @@ -375,6 +375,13 @@ properties: - renesas,r8a779g3 # ES3.x - const: renesas,r8a779g0 + - description: R-Car V4H (R8A779G3) + items: + - enum: + - retronix,sparrow-hawk # Sparrow Hawk board + - const: renesas,r8a779g3 # ES3.x + - const: renesas,r8a779g0 + - description: R-Car V4M (R8A779H0) items: - enum: @@ -585,6 +592,16 @@ properties: - const: renesas,r9a09g057h48 - const: renesas,r9a09g057 + - description: RZ/T2H (R9A09G077) + items: + - enum: + - renesas,rzt2h-evk # RZ/T2H Evaluation Board + - enum: + - renesas,r9a09g077m04 # RZ/T2H with Single Cortex-A55 + Dual Cortex-R52 - no security + - renesas,r9a09g077m24 # RZ/T2H with Dual Cortex-A55 + Dual Cortex-R52 - no security + - renesas,r9a09g077m44 # RZ/T2H with Quad Cortex-A55 + Dual Cortex-R52 - no security + - const: renesas,r9a09g077 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 2f61c1b95fea..8cbf5b6772dd 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -18,6 +18,12 @@ properties: - rockchip,rk3528-ioc-grf - rockchip,rk3528-vo-grf - rockchip,rk3528-vpu-grf + - rockchip,rk3562-ioc-grf + - rockchip,rk3562-peri-grf + - rockchip,rk3562-pipephy-grf + - rockchip,rk3562-pmu-grf + - rockchip,rk3562-sys-grf + - rockchip,rk3562-usbphy-grf - rockchip,rk3566-pipe-grf - rockchip,rk3568-pcie3-phy-grf - rockchip,rk3568-pipe-grf @@ -82,6 +88,7 @@ properties: - rockchip,rk3368-pmugrf - rockchip,rk3399-grf - rockchip,rk3399-pmugrf + - rockchip,rk3562-pmu-grf - rockchip,rk3568-grf - rockchip,rk3568-pmugrf - rockchip,rk3576-ioc-grf diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml index 204da6fe458d..3109df43d502 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml @@ -129,6 +129,11 @@ properties: description: Node for reboot method + google,pmu-intr-gen-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU interrupt generation interface. + required: - compatible - reg @@ -189,6 +194,16 @@ allOf: properties: dp-phy: false + - if: + properties: + compatible: + contains: + enum: + - google,gs101-pmu + then: + required: + - google,pmu-intr-gen-syscon + examples: - | #include <dt-bindings/clock/exynos5250.h> diff --git a/Documentation/devicetree/bindings/soc/sophgo/sophgo,cv1800b-rtc.yaml b/Documentation/devicetree/bindings/soc/sophgo/sophgo,cv1800b-rtc.yaml new file mode 100644 index 000000000000..5cf186c396c9 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/sophgo/sophgo,cv1800b-rtc.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sophgo/sophgo,cv1800b-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Real Time Clock of the Sophgo CV1800 SoC + +description: + The RTC (Real Time Clock) is an independently powered module in the chip. It + contains a 32KHz oscillator and a Power-On-Reset (POR) sub-module, which can + be used for time display and scheduled alarm produce. In addition, the + hardware state machine provides triggering and timing control for chip + power-on, power-off and reset. + + Furthermore, the 8051 subsystem is located within RTCSYS and is independently + powered. System software can use the 8051 to manage wake conditions and wake + the system while the system is asleep, and communicate with external devices + through peripheral controllers. + + Technical Reference Manual available at + https://github.com/sophgo/sophgo-doc/tree/main/SG200X/TRM + +maintainers: + - sophgo@lists.linux.dev + +allOf: + - $ref: /schemas/rtc/rtc.yaml# + +properties: + compatible: + items: + - const: sophgo,cv1800b-rtc + - const: syscon + + reg: + maxItems: 1 + + interrupts: + items: + - description: RTC Alarm + - description: RTC Longpress + - description: VBAT DET + + interrupt-names: + items: + - const: alarm + - const: longpress + - const: vbat + + clocks: + items: + - description: RTC clock source + - description: DW8051 MCU clock source + + clock-names: + items: + - const: rtc + - const: mcu + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/sophgo,cv1800.h> + #include <dt-bindings/interrupt-controller/irq.h> + + rtc@5025000 { + compatible = "sophgo,cv1800b-rtc", "syscon"; + reg = <0x5025000 0x2000>; + interrupts = <17 IRQ_TYPE_LEVEL_HIGH>, + <18 IRQ_TYPE_LEVEL_HIGH>, + <19 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "alarm", "longpress", "vbat"; + clocks = <&clk CLK_RTC_25M>, + <&clk CLK_SRC_RTC_SYS_0>; + clock-names = "rtc", "mcu"; + }; diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml index 378e9cc5fac2..f3bd0be3b279 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml @@ -26,6 +26,7 @@ properties: compatible: items: - enum: + - ti,am654-system-controller - ti,j7200-system-controller - ti,j721e-system-controller - ti,j721s2-system-controller @@ -68,6 +69,23 @@ patternProperties: description: The node corresponding to SoC chip identification. + "^pcie-ctrl@[0-9a-f]+$": + type: object + description: + The node corresponding to PCIe control register. + + "^clock@[0-9a-f]+$": + type: object + $ref: /schemas/soc/ti/ti,am654-serdes-ctrl.yaml# + description: + This is the Serdes Control region. + + "^dss-oldi-io-ctrl@[0-9a-f]+$": + type: object + $ref: /schemas/mfd/syscon.yaml# + description: + This is the DSS OLDI CTRL region. + required: - compatible - reg @@ -110,5 +128,10 @@ examples: compatible = "ti,am654-chipid"; reg = <0x14 0x4>; }; + + pcie0_ctrl: pcie-ctrl@4070 { + compatible = "ti,j784s4-pcie-ctrl", "syscon"; + reg = <0x4070 0x4>; + }; }; ... diff --git a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml index a7236f7db4ec..e7f7cf72719e 100644 --- a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml +++ b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml @@ -50,6 +50,7 @@ properties: - enum: - allwinner,sun50i-a100-system-control - allwinner,sun50i-h6-system-control + - allwinner,sun55i-a523-system-control - const: allwinner,sun50i-a64-system-control reg: diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 6a49e8efc0f7..8dc81b1ca48e 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -295,8 +295,6 @@ properties: - mps,mp5990 # Monolithic Power Systems Inc. digital step-down converter mp9941 - mps,mp9941 - # Monolithic Power Systems Inc. synchronous step-down converter mpq8785 - - mps,mpq8785 # Temperature sensor with integrated fan control - national,lm63 # Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor diff --git a/Documentation/devicetree/bindings/usb/cypress,hx3.yaml b/Documentation/devicetree/bindings/usb/cypress,hx3.yaml index 1033b7a4b8f9..d6eac1213228 100644 --- a/Documentation/devicetree/bindings/usb/cypress,hx3.yaml +++ b/Documentation/devicetree/bindings/usb/cypress,hx3.yaml @@ -14,9 +14,22 @@ allOf: properties: compatible: - enum: - - usb4b4,6504 - - usb4b4,6506 + oneOf: + - enum: + - usb4b4,6504 + - usb4b4,6506 + - items: + - enum: + - usb4b4,6500 + - usb4b4,6508 + - const: usb4b4,6504 + - items: + - enum: + - usb4b4,6502 + - usb4b4,6503 + - usb4b4,6507 + - usb4b4,650a + - const: usb4b4,6506 reg: true diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 55b6139d5e04..c01adbaacbbb 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -868,6 +868,8 @@ patternProperties: description: Linux-specific binding "^linx,.*": description: Linx Technologies + "^liontron,.*": + description: Shenzhen Liontron Technology Co., Ltd "^liteon,.*": description: LITE-ON Technology Corp. "^litex,.*": @@ -1268,6 +1270,8 @@ patternProperties: description: Renesas Electronics Corporation "^rervision,.*": description: Shenzhen Rervision Technology Co., Ltd. + "^retronix,.*": + description: Retronix Technology Inc. "^revotics,.*": description: Revolution Robotics, Inc. (Revotics) "^rex,.*": @@ -1500,6 +1504,8 @@ patternProperties: description: Toby Churchill Ltd. "^tcs,.*": description: Shenzhen City Tang Cheng Technology Co., Ltd. + "^tcu,.*": + description: TC Unterhaltungselektronik AG "^tdo,.*": description: Shangai Top Display Optoelectronics Co., Ltd "^team-source-display,.*": @@ -1613,6 +1619,8 @@ patternProperties: description: Universal Scientific Industrial Co., Ltd. "^usr,.*": description: U.S. Robotics Corporation + "^ultratronik,.*": + description: Ultratronik GmbH "^utoo,.*": description: Aigo Digital Technology Co., Ltd. "^v3,.*": @@ -1755,6 +1763,8 @@ patternProperties: description: Y Soft Corporation a.s. "^yuridenki,.*": description: Yuridenki-Shokai Co. Ltd. + "^yuzukihd,.*": + description: YuzukiHD Open Source Hardware "^zarlink,.*": description: Zarlink Semiconductor "^zealz,.*": diff --git a/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml index 8b7aa922249b..1d9f15ec6657 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml @@ -20,6 +20,7 @@ properties: items: - enum: - fsl,imx8dxl-sc-wdt + - fsl,imx8qm-sc-wdt - fsl,imx8qxp-sc-wdt - const: fsl,imx-sc-wdt diff --git a/Documentation/devicetree/bindings/watchdog/nxp,s32g2-swt.yaml b/Documentation/devicetree/bindings/watchdog/nxp,s32g2-swt.yaml new file mode 100644 index 000000000000..8f168a05b50c --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/nxp,s32g2-swt.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/nxp,s32g2-swt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Software Watchdog Timer (SWT) + +maintainers: + - Daniel Lezcano <daniel.lezcano@kernel.org> + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + oneOf: + - const: nxp,s32g2-swt + - items: + - const: nxp,s32g3-swt + - const: nxp,s32g2-swt + + reg: + maxItems: 1 + + clocks: + items: + - description: Counter clock + - description: Module clock + - description: Register clock + + clock-names: + items: + - const: counter + - const: module + - const: register + +required: + - compatible + - reg + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + watchdog@40100000 { + compatible = "nxp,s32g2-swt"; + reg = <0x40100000 0x1000>; + clocks = <&clks 0x3a>, <&clks 0x3b>, <&clks 0x3c>; + clock-names = "counter", "module", "register"; + timeout-sec = <10>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml index 3e0a8747a357..78874b90c88c 100644 --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml @@ -76,7 +76,9 @@ properties: - const: renesas,rcar-gen4-wdt # R-Car Gen4 - items: - - const: renesas,r9a09g047-wdt # RZ/G3E + - enum: + - renesas,r9a09g047-wdt # RZ/G3E + - renesas,r9a09g056-wdt # RZ/V2N - const: renesas,r9a09g057-wdt # RZ/V2H(P) - const: renesas,r9a09g057-wdt # RZ/V2H(P) diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml index d175ae968336..53fc64f5b56d 100644 --- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml @@ -25,6 +25,7 @@ properties: - samsung,exynos5420-wdt # for Exynos5420 - samsung,exynos7-wdt # for Exynos7 - samsung,exynos850-wdt # for Exynos850 + - samsung,exynos990-wdt # for Exynos990 - samsung,exynosautov9-wdt # for Exynosautov9 - samsung,exynosautov920-wdt # for Exynosautov920 - items: @@ -49,14 +50,14 @@ properties: samsung,cluster-index: $ref: /schemas/types.yaml#/definitions/uint32 description: - Index of CPU cluster on which watchdog is running (in case of Exynos850 - or Google gs101). + Index of CPU cluster on which watchdog is running (in case of Exynos850, + Exynos990 or Google gs101). samsung,syscon-phandle: $ref: /schemas/types.yaml#/definitions/phandle description: Phandle to the PMU system controller node (in case of Exynos5250, - Exynos5420, Exynos7, Exynos850 and gs101). + Exynos5420, Exynos7, Exynos850, Exynos990 and gs101). required: - compatible @@ -77,6 +78,7 @@ allOf: - samsung,exynos5420-wdt - samsung,exynos7-wdt - samsung,exynos850-wdt + - samsung,exynos990-wdt - samsung,exynosautov9-wdt - samsung,exynosautov920-wdt then: @@ -89,6 +91,7 @@ allOf: enum: - google,gs101-wdt - samsung,exynos850-wdt + - samsung,exynos990-wdt - samsung,exynosautov9-wdt - samsung,exynosautov920-wdt then: @@ -102,7 +105,7 @@ allOf: - const: watchdog - const: watchdog_src samsung,cluster-index: - enum: [0, 1] + enum: [0, 1, 2] required: - samsung,cluster-index else: diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml index 1efefd741c06..ef088e0f6917 100644 --- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml @@ -28,6 +28,7 @@ properties: - rockchip,rk3328-wdt - rockchip,rk3368-wdt - rockchip,rk3399-wdt + - rockchip,rk3562-wdt - rockchip,rk3568-wdt - rockchip,rk3576-wdt - rockchip,rk3588-wdt diff --git a/Documentation/driver-api/cxl/access-coordinates.rst b/Documentation/driver-api/cxl/access-coordinates.rst deleted file mode 100644 index b07950ea30c9..000000000000 --- a/Documentation/driver-api/cxl/access-coordinates.rst +++ /dev/null @@ -1,91 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 -.. include:: <isonum.txt> - -================================== -CXL Access Coordinates Computation -================================== - -Shared Upstream Link Calculation -================================ -For certain CXL region construction with endpoints behind CXL switches (SW) or -Root Ports (RP), there is the possibility of the total bandwidth for all -the endpoints behind a switch being more than the switch upstream link. -A similar situation can occur within the host, upstream of the root ports. -The CXL driver performs an additional pass after all the targets have -arrived for a region in order to recalculate the bandwidths with possible -upstream link being a limiting factor in mind. - -The algorithm assumes the configuration is a symmetric topology as that -maximizes performance. When asymmetric topology is detected, the calculation -is aborted. An asymmetric topology is detected during topology walk where the -number of RPs detected as a grandparent is not equal to the number of devices -iterated in the same iteration loop. The assumption is made that subtle -asymmetry in properties does not happen and all paths to EPs are equal. - -There can be multiple switches under an RP. There can be multiple RPs under -a CXL Host Bridge (HB). There can be multiple HBs under a CXL Fixed Memory -Window Structure (CFMWS). - -An example hierarchy: - -> CFMWS 0 -> | -> _________|_________ -> | | -> ACPI0017-0 ACPI0017-1 -> GP0/HB0/ACPI0016-0 GP1/HB1/ACPI0016-1 -> | | | | -> RP0 RP1 RP2 RP3 -> | | | | -> SW 0 SW 1 SW 2 SW 3 -> | | | | | | | | -> EP0 EP1 EP2 EP3 EP4 EP5 EP6 EP7 - -Computation for the example hierarchy: - -Min (GP0 to CPU BW, - Min(SW 0 Upstream Link to RP0 BW, - Min(SW0SSLBIS for SW0DSP0 (EP0), EP0 DSLBIS, EP0 Upstream Link) + - Min(SW0SSLBIS for SW0DSP1 (EP1), EP1 DSLBIS, EP1 Upstream link)) + - Min(SW 1 Upstream Link to RP1 BW, - Min(SW1SSLBIS for SW1DSP0 (EP2), EP2 DSLBIS, EP2 Upstream Link) + - Min(SW1SSLBIS for SW1DSP1 (EP3), EP3 DSLBIS, EP3 Upstream link))) + -Min (GP1 to CPU BW, - Min(SW 2 Upstream Link to RP2 BW, - Min(SW2SSLBIS for SW2DSP0 (EP4), EP4 DSLBIS, EP4 Upstream Link) + - Min(SW2SSLBIS for SW2DSP1 (EP5), EP5 DSLBIS, EP5 Upstream link)) + - Min(SW 3 Upstream Link to RP3 BW, - Min(SW3SSLBIS for SW3DSP0 (EP6), EP6 DSLBIS, EP6 Upstream Link) + - Min(SW3SSLBIS for SW3DSP1 (EP7), EP7 DSLBIS, EP7 Upstream link)))) - -The calculation starts at cxl_region_shared_upstream_perf_update(). A xarray -is created to collect all the endpoint bandwidths via the -cxl_endpoint_gather_bandwidth() function. The min() of bandwidth from the -endpoint CDAT and the upstream link bandwidth is calculated. If the endpoint -has a CXL switch as a parent, then min() of calculated bandwidth and the -bandwidth from the SSLBIS for the switch downstream port that is associated -with the endpoint is calculated. The final bandwidth is stored in a -'struct cxl_perf_ctx' in the xarray indexed by a device pointer. If the -endpoint is direct attached to a root port (RP), the device pointer would be an -RP device. If the endpoint is behind a switch, the device pointer would be the -upstream device of the parent switch. - -At the next stage, the code walks through one or more switches if they exist -in the topology. For endpoints directly attached to RPs, this step is skipped. -If there is another switch upstream, the code takes the min() of the current -gathered bandwidth and the upstream link bandwidth. If there's a switch -upstream, then the SSLBIS of the upstream switch. - -Once the topology walk reaches the RP, whether it's direct attached endpoints -or walking through the switch(es), cxl_rp_gather_bandwidth() is called. At -this point all the bandwidths are aggregated per each host bridge, which is -also the index for the resulting xarray. - -The next step is to take the min() of the per host bridge bandwidth and the -bandwidth from the Generic Port (GP). The bandwidths for the GP is retrieved -via ACPI tables SRAT/HMAT. The min bandwidth are aggregated under the same -ACPI0017 device to form a new xarray. - -Finally, the cxl_region_update_bandwidth() is called and the aggregated -bandwidth from all the members of the last xarray is updated for the -access coordinates residing in the cxl region (cxlr) context. diff --git a/Documentation/driver-api/cxl/allocation/dax.rst b/Documentation/driver-api/cxl/allocation/dax.rst new file mode 100644 index 000000000000..c6f7a5da832f --- /dev/null +++ b/Documentation/driver-api/cxl/allocation/dax.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========== +DAX Devices +=========== +CXL capacity exposed as a DAX device can be accessed directly via mmap. +Users may wish to use this interface mechanism to write their own userland +CXL allocator, or to managed shared or persistent memory regions across multiple +hosts. + +If the capacity is shared across hosts or persistent, appropriate flushing +mechanisms must be employed unless the region supports Snoop Back-Invalidate. + +Note that mappings must be aligned (size and base) to the dax device's base +alignment, which is typically 2MB - but maybe be configured larger. + +:: + + #include <stdio.h> + #include <stdlib.h> + #include <stdint.h> + #include <sys/mman.h> + #include <fcntl.h> + #include <unistd.h> + + #define DEVICE_PATH "/dev/dax0.0" // Replace DAX device path + #define DEVICE_SIZE (4ULL * 1024 * 1024 * 1024) // 4GB + + int main() { + int fd; + void* mapped_addr; + + /* Open the DAX device */ + fd = open(DEVICE_PATH, O_RDWR); + if (fd < 0) { + perror("open"); + return -1; + } + + /* Map the device into memory */ + mapped_addr = mmap(NULL, DEVICE_SIZE, PROT_READ | PROT_WRITE, + MAP_SHARED, fd, 0); + if (mapped_addr == MAP_FAILED) { + perror("mmap"); + close(fd); + return -1; + } + + printf("Mapped address: %p\n", mapped_addr); + + /* You can now access the device through the mapped address */ + uint64_t* ptr = (uint64_t*)mapped_addr; + *ptr = 0x1234567890abcdef; // Write a value to the device + printf("Value at address %p: 0x%016llx\n", ptr, *ptr); + + /* Clean up */ + munmap(mapped_addr, DEVICE_SIZE); + close(fd); + return 0; + } diff --git a/Documentation/driver-api/cxl/allocation/hugepages.rst b/Documentation/driver-api/cxl/allocation/hugepages.rst new file mode 100644 index 000000000000..1023c6922829 --- /dev/null +++ b/Documentation/driver-api/cxl/allocation/hugepages.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========== +Huge Pages +========== + +Contiguous Memory Allocator +=========================== +CXL Memory onlined as SystemRAM during early boot is eligible for use by CMA, +as the NUMA node hosting that capacity will be `Online` at the time CMA +carves out contiguous capacity. + +CXL Memory deferred to the CXL Driver for configuration cannot have its +capacity allocated by CMA - as the NUMA node hosting the capacity is `Offline` +at :code:`__init` time - when CMA carves out contiguous capacity. + +HugeTLB +======= +Different huge page sizes allow different memory configurations. + +2MB Huge Pages +-------------- +All CXL capacity regardless of configuration time or memory zone is eligible +for use as 2MB huge pages. + +1GB Huge Pages +-------------- +CXL capacity onlined in :code:`ZONE_NORMAL` is eligible for 1GB Gigantic Page +allocation. + +CXL capacity onlined in :code:`ZONE_MOVABLE` is not eligible for 1GB Gigantic +Page allocation. diff --git a/Documentation/driver-api/cxl/allocation/page-allocator.rst b/Documentation/driver-api/cxl/allocation/page-allocator.rst new file mode 100644 index 000000000000..7b8fe1b8d5bb --- /dev/null +++ b/Documentation/driver-api/cxl/allocation/page-allocator.rst @@ -0,0 +1,85 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================== +The Page Allocator +================== + +The kernel page allocator services all general page allocation requests, such +as :code:`kmalloc`. CXL configuration steps affect the behavior of the page +allocator based on the selected `Memory Zone` and `NUMA node` the capacity is +placed in. + +This section mostly focuses on how these configurations affect the page +allocator (as of Linux v6.15) rather than the overall page allocator behavior. + +NUMA nodes and mempolicy +======================== +Unless a task explicitly registers a mempolicy, the default memory policy +of the linux kernel is to allocate memory from the `local NUMA node` first, +and fall back to other nodes only if the local node is pressured. + +Generally, we expect to see local DRAM and CXL memory on separate NUMA nodes, +with the CXL memory being non-local. Technically, however, it is possible +for a compute node to have no local DRAM, and for CXL memory to be the +`local` capacity for that compute node. + + +Memory Zones +============ +CXL capacity may be onlined in :code:`ZONE_NORMAL` or :code:`ZONE_MOVABLE`. + +As of v6.15, the page allocator attempts to allocate from the highest +available and compatible ZONE for an allocation from the local node first. + +An example of a `zone incompatibility` is attempting to service an allocation +marked :code:`GFP_KERNEL` from :code:`ZONE_MOVABLE`. Kernel allocations are +typically not migratable, and as a result can only be serviced from +:code:`ZONE_NORMAL` or lower. + +To simplify this, the page allocator will prefer :code:`ZONE_MOVABLE` over +:code:`ZONE_NORMAL` by default, but if :code:`ZONE_MOVABLE` is depleted, it +will fallback to allocate from :code:`ZONE_NORMAL`. + + +Zone and Node Quirks +==================== +Let's consider a configuration where the local DRAM capacity is largely onlined +into :code:`ZONE_NORMAL`, with no :code:`ZONE_MOVABLE` capacity present. The +CXL capacity has the opposite configuration - all onlined in +:code:`ZONE_MOVABLE`. + +Under the default allocation policy, the page allocator will completely skip +:code:`ZONE_MOVABLE` as a valid allocation target. This is because, as of +Linux v6.15, the page allocator does (approximately) the following: :: + + for (each zone in local_node): + + for (each node in fallback_order): + + attempt_allocation(gfp_flags); + +Because the local node does not have :code:`ZONE_MOVABLE`, the CXL node is +functionally unreachable for direct allocation. As a result, the only way +for CXL capacity to be used is via `demotion` in the reclaim path. + +This configuration also means that if the DRAM ndoe has :code:`ZONE_MOVABLE` +capacity - when that capacity is depleted, the page allocator will actually +prefer CXL :code:`ZONE_MOVABLE` pages over DRAM :code:`ZONE_NORMAL` pages. + +We may wish to invert this priority in future Linux versions. + +If `demotion` and `swap` are disabled, Linux will begin to cause OOM crashes +when the DRAM nodes are depleted. See the reclaim section for more details. + + +CGroups and CPUSets +=================== +Finally, assuming CXL memory is reachable via the page allocation (i.e. onlined +in :code:`ZONE_NORMAL`), the :code:`cpusets.mems_allowed` may be used by +containers to limit the accessibility of certain NUMA nodes for tasks in that +container. Users may wish to utilize this in multi-tenant systems where some +tasks prefer not to use slower memory. + +In the reclaim section we'll discuss some limitations of this interface to +prevent demotions of shared data to CXL memory (if demotions are enabled). + diff --git a/Documentation/driver-api/cxl/allocation/reclaim.rst b/Documentation/driver-api/cxl/allocation/reclaim.rst new file mode 100644 index 000000000000..f40f1cae391a --- /dev/null +++ b/Documentation/driver-api/cxl/allocation/reclaim.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======= +Reclaim +======= +Another way CXL memory can be utilized *indirectly* is via the reclaim system +in :code:`mm/vmscan.c`. Reclaim is engaged when memory capacity on the system +becomes pressured based on global and cgroup-local `watermark` settings. + +In this section we won't discuss the `watermark` configurations, just how CXL +memory can be consumed by various pieces of reclaim system. + +Demotion +======== +By default, the reclaim system will prefer swap (or zswap) when reclaiming +memory. Enabling :code:`kernel/mm/numa/demotion_enabled` will cause vmscan +to opportunistically prefer distant NUMA nodes to swap or zswap, if capacity +is available. + +Demotion engages the :code:`mm/memory_tier.c` component to determine the +next demotion node. The next demotion node is based on the :code:`HMAT` +or :code:`CDAT` performance data. + +cpusets.mems_allowed quirk +-------------------------- +In Linux v6.15 and below, demotion does not respect :code:`cpusets.mems_allowed` +when migrating pages. As a result, if demotion is enabled, vmscan cannot +guarantee isolation of a container's memory from nodes not set in mems_allowed. + +In Linux v6.XX and up, demotion does attempt to respect +:code:`cpusets.mems_allowed`; however, certain classes of shared memory +originally instantiated by another cgroup (such as common libraries - e.g. +libc) may still be demoted. As a result, the mems_allowed interface still +cannot provide perfect isolation from the remote nodes. + +ZSwap and Node Preference +========================= +In Linux v6.15 and below, ZSwap allocates memory from the local node of the +processor for the new pages being compressed. Since pages being compressed +are typically cold, the result is a cold page becomes promoted - only to +be later demoted as it ages off the LRU. + +In Linux v6.XX, ZSwap tries to prefer the node of the page being compressed +as the allocation target for the compression page. This helps prevent +thrashing. + +Demotion with ZSwap +=================== +When enabling both Demotion and ZSwap, you create a situation where ZSwap +will prefer the slowest form of CXL memory by default until that tier of +memory is exhausted. diff --git a/Documentation/driver-api/cxl/devices/device-types.rst b/Documentation/driver-api/cxl/devices/device-types.rst new file mode 100644 index 000000000000..f5e4330c1cfe --- /dev/null +++ b/Documentation/driver-api/cxl/devices/device-types.rst @@ -0,0 +1,165 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +Devices and Protocols +===================== + +The type of CXL device (Memory, Accelerator, etc) dictates many configuration steps. This section +covers some basic background on device types and on-device resources used by the platform and OS +which impact configuration. + +Protocols +========= + +There are three core protocols to CXL. For the purpose of this documentation, +we will only discuss very high level definitions as the specific hardware +details are largely abstracted away from Linux. See the CXL specification +for more details. + +CXL.io +------ +The basic interaction protocol, similar to PCIe configuration mechanisms. +Typically used for initialization, configuration, and I/O access for anything +other than memory (CXL.mem) or cache (CXL.cache) operations. + +The Linux CXL driver exposes access to .io functionalty via the various sysfs +interfaces and /dev/cxl/ devices (which exposes direct access to device +mailboxes). + +CXL.cache +--------- +The mechanism by which a device may coherently access and cache host memory. + +Largely transparent to Linux once configured. + +CXL.mem +--------- +The mechanism by which the CPU may coherently access and cache device memory. + +Largely transparent to Linux once configured. + + +Device Types +============ + +Type-1 +------ + +A Type-1 CXL device: + +* Supports cxl.io and cxl.cache protocols +* Implements a fully coherent cache +* Allows Device-to-Host coherence and Host-to-Device snoops. +* Does NOT have host-managed device memory (HDM) + +Typical examples of type-1 devices is a Smart NIC - which may want to +directly operate on host-memory (DMA) to store incoming packets. These +devices largely rely on CPU-attached memory. + +Type-2 +------ + +A Type-2 CXL Device: + +* Supports cxl.io, cxl.cache, and cxl.mem protocols +* Optionally implements coherent cache and Host-Managed Device Memory +* Is typically an accelerator device w/ high bandwidth memory. + +The primary difference between a type-1 and type-2 device is the presence +of host-managed device memory, which allows the device to operate on a +local memory bank - while the CPU sill has coherent DMA to the same memory. + +The allows things like GPUs to expose their memory via DAX devices or file +descriptors, allows drivers and programs direct access to device memory +rather than use block-transfer semantics. + +Type-3 +------ + +A Type-3 CXL Device + +* Supports cxl.io and cxl.mem +* Implements Host-Managed Device Memory +* May provide either Volatile or Persistent memory capacity (or both). + +A basic example of a type-3 device is a simple memory expander, whose +local memory capacity is exposed to the CPU for access directly via +basic coherent DMA. + +Switch +------ + +A CXL switch is a device capacity of routing any CXL (and by extension, PCIe) +protocol between an upstream, downstream, or peer devices. Many devices, such +as Multi-Logical Devices, imply the presence of switching in some manner. + +Logical Devices and Heads +------------------------- + +A CXL device may present one or more "Logical Devices" to one or more hosts +(via physical "Heads"). + +A Single-Logical Device (SLD) is a device which presents a single device to +one or more heads. + +A Multi-Logical Device (MLD) is a device which may present multiple devices +to one or more devices. + +A Single-Headed Device exposes only a single physical connection. + +A Multi-Headed Device exposes multiple physical connections. + +MHSLD +~~~~~ +A Multi-Headed Single-Logical Device (MHSLD) exposes a single logical +device to multiple heads which may be connected to one or more discrete +hosts. An example of this would be a simple memory-pool which may be +statically configured (prior to boot) to expose portions of its memory +to Linux via :doc:`CEDT <../platform/acpi/cedt>`. + +MHMLD +~~~~~ +A Multi-Headed Multi-Logical Device (MHMLD) exposes multiple logical +devices to multiple heads which may be connected to one or more discrete +hosts. An example of this would be a Dynamic Capacity Device or which +may be configured at runtime to expose portions of its memory to Linux. + +Example Devices +=============== + +Memory Expander +--------------- +The simplest form of Type-3 device is a memory expander. A memory expander +exposes Host-Managed Device Memory (HDM) to Linux. This memory may be +Volatile or Non-Volatile (Persistent). + +Memory Expanders will typically be considered a form of Single-Headed, +Single-Logical Device - as its form factor will typically be an add-in-card +(AIC) or some other similar form-factor. + +The Linux CXL driver provides support for static or dynamic configuration of +basic memory expanders. The platform may program decoders prior to OS init +(e.g. auto-decoders), or the user may program the fabric if the platform +defers these operations to the OS. + +Multiple Memory Expanders may be added to an external chassis and exposed to +a host via a head attached to a CXL switch. This is a "memory pool", and +would be considered an MHSLD or MHMLD depending on the management capabilities +provided by the switch platform. + +As of v6.14, Linux does not provide a formalized interface to manage non-DCD +MHSLD or MHMLD devices. + +Dynamic Capacity Device (DCD) +----------------------------- + +A Dynamic Capacity Device is a Type-3 device which provides dynamic management +of memory capacity. The basic premise of a DCD to provide an allocator-like +interface for physical memory capacity to a "Fabric Manager" (an external, +privileged host with privileges to change configurations for other hosts). + +A DCD manages "Memory Extents", which may be volatile or persistent. Extents +may also be exclusive to a single host or shared across multiple hosts. + +As of v6.14, Linux does not provide a formalized interface to manage DCD +devices, however there is active work on LKML targeting future release. diff --git a/Documentation/driver-api/cxl/index.rst b/Documentation/driver-api/cxl/index.rst index 965ba90e8fb7..9e1414ad3357 100644 --- a/Documentation/driver-api/cxl/index.rst +++ b/Documentation/driver-api/cxl/index.rst @@ -4,12 +4,50 @@ Compute Express Link ==================== -.. toctree:: - :maxdepth: 1 +CXL device configuration has a complex handoff between platform (Hardware, +BIOS, EFI), OS (early boot, core kernel, driver), and user policy decisions +that have impacts on each other. The docs here break up configurations steps. - memory-devices - access-coordinates +.. toctree:: + :maxdepth: 2 + :caption: Overview + theory-of-operation maturity-map +.. toctree:: + :maxdepth: 2 + :caption: Device Reference + + devices/device-types + +.. toctree:: + :maxdepth: 2 + :caption: Platform Configuration + + platform/bios-and-efi + platform/acpi + platform/cdat + platform/example-configs + +.. toctree:: + :maxdepth: 2 + :caption: Linux Kernel Configuration + + linux/overview + linux/early-boot + linux/cxl-driver + linux/dax-driver + linux/memory-hotplug + linux/access-coordinates + +.. toctree:: + :maxdepth: 2 + :caption: Memory Allocation + + allocation/dax + allocation/page-allocator + allocation/reclaim + allocation/hugepages.rst + .. only:: subproject and html diff --git a/Documentation/driver-api/cxl/linux/access-coordinates.rst b/Documentation/driver-api/cxl/linux/access-coordinates.rst new file mode 100644 index 000000000000..341a7c682043 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/access-coordinates.rst @@ -0,0 +1,178 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +================================== +CXL Access Coordinates Computation +================================== + +Latency and Bandwidth Calculation +================================= +A memory region performance coordinates (latency and bandwidth) are typically +provided via ACPI tables :doc:`SRAT <../platform/acpi/srat>` and +:doc:`HMAT <../platform/acpi/hmat>`. However, the platform firmware (BIOS) is +not able to annotate those for CXL devices that are hot-plugged since they do +not exist during platform firmware initialization. The CXL driver can compute +the performance coordinates by retrieving data from several components. + +The :doc:`SRAT <../platform/acpi/srat>` provides a Generic Port Affinity +subtable that ties a proximity domain to a device handle, which in this case +would be the CXL hostbridge. Using this association, the performance +coordinates for the Generic Port can be retrieved from the +:doc:`HMAT <../platform/acpi/hmat>` subtable. This piece represents the +performance coordinates between a CPU and a Generic Port (CXL hostbridge). + +The :doc:`CDAT <../platform/cdat>` provides the performance coordinates for +the CXL device itself. That is the bandwidth and latency to access that device's +memory region. The DSMAS subtable provides a DSMADHandle that is tied to a +Device Physical Address (DPA) range. The DSLBIS subtable provides the +performance coordinates that's tied to a DSMADhandle and this ties the two +table entries together to provide the performance coordinates for each DPA +region. For example, if a device exports a DRAM region and a PMEM region, +then there would be different performance characteristsics for each of those +regions. + +If there's a CXL switch in the topology, then the performance coordinates for the +switch is provided by SSLBIS subtable. This provides the bandwidth and latency +for traversing the switch between the switch upstream port and the switch +downstream port that points to the endpoint device. + +Simple topology example:: + + GP0/HB0/ACPI0016-0 + RP0 + | + | L0 + | + SW 0 / USP0 + SW 0 / DSP0 + | + | L1 + | + EP0 + +In this example, there is a CXL switch between an endpoint and a root port. +Latency in this example is calculated as such: +L(EP0) - Latency from EP0 CDAT DSMAS+DSLBIS +L(L1) - Link latency between EP0 and SW0DSP0 +L(SW0) - Latency for the switch from SW0 CDAT SSLBIS. +L(L0) - Link latency between SW0 and RP0 +L(RP0) - Latency from root port to CPU via SRAT and HMAT (Generic Port). +Total read and write latencies are the sum of all these parts. + +Bandwidth in this example is calculated as such: +B(EP0) - Bandwidth from EP0 CDAT DSMAS+DSLBIS +B(L1) - Link bandwidth between EP0 and SW0DSP0 +B(SW0) - Bandwidth for the switch from SW0 CDAT SSLBIS. +B(L0) - Link bandwidth between SW0 and RP0 +B(RP0) - Bandwidth from root port to CPU via SRAT and HMAT (Generic Port). +The total read and write bandwidth is the min() of all these parts. + +To calculate the link bandwidth: +LinkOperatingFrequency (GT/s) is the current negotiated link speed. +DataRatePerLink (MB/s) = LinkOperatingFrequency / 8 +Bandwidth (MB/s) = PCIeCurrentLinkWidth * DataRatePerLink +Where PCIeCurrentLinkWidth is the number of lanes in the link. + +To calculate the link latency: +LinkLatency (picoseconds) = FlitSize / LinkBandwidth (MB/s) + +See `CXL Memory Device SW Guide r1.0 <https://www.intel.com/content/www/us/en/content-details/643805/cxl-memory-device-software-guide.html>`_, +section 2.11.3 and 2.11.4 for details. + +In the end, the access coordinates for a constructed memory region is calculated from one +or more memory partitions from each of the CXL device(s). + +Shared Upstream Link Calculation +================================ +For certain CXL region construction with endpoints behind CXL switches (SW) or +Root Ports (RP), there is the possibility of the total bandwidth for all +the endpoints behind a switch being more than the switch upstream link. +A similar situation can occur within the host, upstream of the root ports. +The CXL driver performs an additional pass after all the targets have +arrived for a region in order to recalculate the bandwidths with possible +upstream link being a limiting factor in mind. + +The algorithm assumes the configuration is a symmetric topology as that +maximizes performance. When asymmetric topology is detected, the calculation +is aborted. An asymmetric topology is detected during topology walk where the +number of RPs detected as a grandparent is not equal to the number of devices +iterated in the same iteration loop. The assumption is made that subtle +asymmetry in properties does not happen and all paths to EPs are equal. + +There can be multiple switches under an RP. There can be multiple RPs under +a CXL Host Bridge (HB). There can be multiple HBs under a CXL Fixed Memory +Window Structure (CFMWS) in the :doc:`CEDT <../platform/acpi/cedt>`. + +An example hierarchy:: + + CFMWS 0 + | + _________|_________ + | | + ACPI0017-0 ACPI0017-1 + GP0/HB0/ACPI0016-0 GP1/HB1/ACPI0016-1 + | | | | + RP0 RP1 RP2 RP3 + | | | | + SW 0 SW 1 SW 2 SW 3 + | | | | | | | | + EP0 EP1 EP2 EP3 EP4 EP5 EP6 EP7 + +Computation for the example hierarchy: + +Min (GP0 to CPU BW, + Min(SW 0 Upstream Link to RP0 BW, + Min(SW0SSLBIS for SW0DSP0 (EP0), EP0 DSLBIS, EP0 Upstream Link) + + Min(SW0SSLBIS for SW0DSP1 (EP1), EP1 DSLBIS, EP1 Upstream link)) + + Min(SW 1 Upstream Link to RP1 BW, + Min(SW1SSLBIS for SW1DSP0 (EP2), EP2 DSLBIS, EP2 Upstream Link) + + Min(SW1SSLBIS for SW1DSP1 (EP3), EP3 DSLBIS, EP3 Upstream link))) + +Min (GP1 to CPU BW, + Min(SW 2 Upstream Link to RP2 BW, + Min(SW2SSLBIS for SW2DSP0 (EP4), EP4 DSLBIS, EP4 Upstream Link) + + Min(SW2SSLBIS for SW2DSP1 (EP5), EP5 DSLBIS, EP5 Upstream link)) + + Min(SW 3 Upstream Link to RP3 BW, + Min(SW3SSLBIS for SW3DSP0 (EP6), EP6 DSLBIS, EP6 Upstream Link) + + Min(SW3SSLBIS for SW3DSP1 (EP7), EP7 DSLBIS, EP7 Upstream link)))) + +The calculation starts at cxl_region_shared_upstream_perf_update(). A xarray +is created to collect all the endpoint bandwidths via the +cxl_endpoint_gather_bandwidth() function. The min() of bandwidth from the +endpoint CDAT and the upstream link bandwidth is calculated. If the endpoint +has a CXL switch as a parent, then min() of calculated bandwidth and the +bandwidth from the SSLBIS for the switch downstream port that is associated +with the endpoint is calculated. The final bandwidth is stored in a +'struct cxl_perf_ctx' in the xarray indexed by a device pointer. If the +endpoint is direct attached to a root port (RP), the device pointer would be an +RP device. If the endpoint is behind a switch, the device pointer would be the +upstream device of the parent switch. + +At the next stage, the code walks through one or more switches if they exist +in the topology. For endpoints directly attached to RPs, this step is skipped. +If there is another switch upstream, the code takes the min() of the current +gathered bandwidth and the upstream link bandwidth. If there's a switch +upstream, then the SSLBIS of the upstream switch. + +Once the topology walk reaches the RP, whether it's direct attached endpoints +or walking through the switch(es), cxl_rp_gather_bandwidth() is called. At +this point all the bandwidths are aggregated per each host bridge, which is +also the index for the resulting xarray. + +The next step is to take the min() of the per host bridge bandwidth and the +bandwidth from the Generic Port (GP). The bandwidths for the GP are retrieved +via ACPI tables (:doc:`SRAT <../platform/acpi/srat>` and +:doc:`HMAT <../platform/acpi/hmat>`). The minimum bandwidth are aggregated +under the same ACPI0017 device to form a new xarray. + +Finally, the cxl_region_update_bandwidth() is called and the aggregated +bandwidth from all the members of the last xarray is updated for the +access coordinates residing in the cxl region (cxlr) context. + +QTG ID +====== +Each :doc:`CEDT <../platform/acpi/cedt>` has a QTG ID field. This field provides +the ID that associates with a QoS Throttling Group (QTG) for the CFMWS window. +Once the access coordinates are calculated, an ACPI Device Specific Method can +be issued to the ACPI0016 device to retrieve the QTG ID depends on the access +coordinates provided. The QTG ID for the device can be used as guidance to match +to the CFMWS to setup the best Linux root decoder for the device performance. diff --git a/Documentation/driver-api/cxl/linux/cxl-driver.rst b/Documentation/driver-api/cxl/linux/cxl-driver.rst new file mode 100644 index 000000000000..9759e90c3cf1 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/cxl-driver.rst @@ -0,0 +1,630 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +CXL Driver Operation +==================== + +The devices described in this section are present in :: + + /sys/bus/cxl/devices/ + /dev/cxl/ + +The :code:`cxl-cli` library, maintained as part of the NDTCL project, may +be used to script interactions with these devices. + +Drivers +======= +The CXL driver is split into a number of drivers. + +* cxl_core - fundamental init interface and core object creation +* cxl_port - initializes root and provides port enumeration interface. +* cxl_acpi - initializes root decoders and interacts with ACPI data. +* cxl_p/mem - initializes memory devices +* cxl_pci - uses cxl_port to enumates the actual fabric hierarchy. + +Driver Devices +============== +Here is an example from a single-socket system with 4 host bridges. Two host +bridges have a single memory device attached, and the devices are interleaved +into a single memory region. The memory region has been converted to dax. :: + + # ls /sys/bus/cxl/devices/ + dax_region0 decoder3.0 decoder6.0 mem0 port3 + decoder0.0 decoder4.0 decoder6.1 mem1 port4 + decoder1.0 decoder5.0 endpoint5 port1 region0 + decoder2.0 decoder5.1 endpoint6 port2 root0 + + +.. kernel-render:: DOT + :alt: Digraph of CXL fabric describing host-bridge interleaving + :caption: Diagraph of CXL fabric with a host-bridge interleave memory region + + digraph foo { + "root0" -> "port1"; + "root0" -> "port3"; + "root0" -> "decoder0.0"; + "port1" -> "endpoint5"; + "port3" -> "endpoint6"; + "port1" -> "decoder1.0"; + "port3" -> "decoder3.0"; + "endpoint5" -> "decoder5.0"; + "endpoint6" -> "decoder6.0"; + "decoder0.0" -> "region0"; + "decoder0.0" -> "decoder1.0"; + "decoder0.0" -> "decoder3.0"; + "decoder1.0" -> "decoder5.0"; + "decoder3.0" -> "decoder6.0"; + "decoder5.0" -> "region0"; + "decoder6.0" -> "region0"; + "region0" -> "dax_region0"; + "dax_region0" -> "dax0.0"; + } + +For this section we'll explore the devices present in this configuration, but +we'll explore more configurations in-depth in example configurations below. + +Base Devices +------------ +Most devices in a CXL fabric are a `port` of some kind (because each +device mostly routes request from one device to the next, rather than +provide a direct service). + +Root +~~~~ +The `CXL Root` is logical object created by the `cxl_acpi` driver during +:code:`cxl_acpi_probe` - if the :code:`ACPI0017` `Compute Express Link +Root Object` Device Class is found. + +The Root contains links to: + +* `Host Bridge Ports` defined by CHBS in the :doc:`CEDT<../platform/acpi/cedt>` + +* `Downstream Ports` typically connected to `Host Bridge Ports`. + +* `Root Decoders` defined by CFMWS the :doc:`CEDT<../platform/acpi/cedt>` + +:: + + # ls /sys/bus/cxl/devices/root0 + decoder0.0 dport0 dport5 port2 subsystem + decoders_committed dport1 modalias port3 uevent + devtype dport4 port1 port4 uport + + # cat /sys/bus/cxl/devices/root0/devtype + cxl_port + + # cat port1/devtype + cxl_port + + # cat decoder0.0/devtype + cxl_decoder_root + +The root is first `logical port` in the CXL fabric, as presented by the Linux +CXL driver. The `CXL root` is a special type of `switch port`, in that it +only has downstream port connections. + +Port +~~~~ +A `port` object is better described as a `switch port`. It may represent a +host bridge to the root or an actual switch port on a switch. A `switch port` +contains one or more decoders used to route memory requests downstream ports, +which may be connected to another `switch port` or an `endpoint port`. + +:: + + # ls /sys/bus/cxl/devices/port1 + decoder1.0 dport0 driver parent_dport uport + decoders_committed dport113 endpoint5 subsystem + devtype dport2 modalias uevent + + # cat devtype + cxl_port + + # cat decoder1.0/devtype + cxl_decoder_switch + + # cat endpoint5/devtype + cxl_port + +CXL `Host Bridges` in the fabric are probed during :code:`cxl_acpi_probe` at +the time the `CXL Root` is probed. The allows for the immediate logical +connection to between the root and host bridge. + +* The root has a downstream port connection to a host bridge + +* The host bridge has an upstream port connection to the root. + +* The host bridge has one or more downstream port connections to switch + or endpoint ports. + +A `Host Bridge` is a special type of CXL `switch port`. It is explicitly +defined in the ACPI specification via `ACPI0016` ID. `Host Bridge` ports +will be probed at `acpi_probe` time, while similar ports on an actual switch +will be probed later. Otherwise, switch and host bridge ports look very +similar - the both contain switch decoders which route accesses between +upstream and downstream ports. + +Endpoint +~~~~~~~~ +An `endpoint` is a terminal port in the fabric. This is a `logical device`, +and may be one of many `logical devices` presented by a memory device. It +is still considered a type of `port` in the fabric. + +An `endpoint` contains `endpoint decoders` and the device's Coherent Device +Attribute Table (which describes the device's capabilities). :: + + # ls /sys/bus/cxl/devices/endpoint5 + CDAT decoders_committed modalias uevent + decoder5.0 devtype parent_dport uport + decoder5.1 driver subsystem + + # cat /sys/bus/cxl/devices/endpoint5/devtype + cxl_port + + # cat /sys/bus/cxl/devices/endpoint5/decoder5.0/devtype + cxl_decoder_endpoint + + +Memory Device (memdev) +~~~~~~~~~~~~~~~~~~~~~~ +A `memdev` is probed and added by the `cxl_pci` driver in :code:`cxl_pci_probe` +and is managed by the `cxl_mem` driver. It primarily provides the `IOCTL` +interface to a memory device, via :code:`/dev/cxl/memN`, and exposes various +device configuration data. :: + + # ls /sys/bus/cxl/devices/mem0 + dev firmware_version payload_max security uevent + driver label_storage_size pmem serial + firmware numa_node ram subsystem + +A Memory Device is a discrete base object that is not a port. While the +physical device it belongs to may also host an `endpoint`, the relationship +between an `endpoint` and a `memdev` is not captured in sysfs. + +Port Relationships +~~~~~~~~~~~~~~~~~~ +In our example described above, there are four host bridges attached to the +root, and two of the host bridges have one endpoint attached. + +.. kernel-render:: DOT + :alt: Digraph of CXL fabric describing host-bridge interleaving + :caption: Diagraph of CXL fabric with a host-bridge interleave memory region + + digraph foo { + "root0" -> "port1"; + "root0" -> "port2"; + "root0" -> "port3"; + "root0" -> "port4"; + "port1" -> "endpoint5"; + "port3" -> "endpoint6"; + } + +Decoders +-------- +A `Decoder` is short for a CXL Host-Managed Device Memory (HDM) Decoder. It is +a device that routes accesses through the CXL fabric to an endpoint, and at +the endpoint translates a `Host Physical` to `Device Physical` Addressing. + +The CXL 3.1 specification heavily implies that only endpoint decoders should +engage in translation of `Host Physical Address` to `Device Physical Address`. +:: + + 8.2.4.20 CXL HDM Decoder Capability Structure + + IMPLEMENTATION NOTE + CXL Host Bridge and Upstream Switch Port Decode Flow + + IMPLEMENTATION NOTE + Device Decode Logic + +These notes imply that there are two logical groups of decoders. + +* Routing Decoder - a decoder which routes accesses but does not translate + addresses from HPA to DPA. + +* Translating Decoder - a decoder which translates accesses from HPA to DPA + for an endpoint to service. + +The CXL drivers distinguish 3 decoder types: root, switch, and endpoint. Only +endpoint decoders are Translating Decoders, all others are Routing Decoders. + +.. note:: PLATFORM VENDORS BE AWARE + + Linux makes a strong assumption that endpoint decoders are the only decoder + in the fabric that actively translates HPA to DPA. Linux assumes routing + decoders pass the HPA unchanged to the next decoder in the fabric. + + It is therefore assumed that any given decoder in the fabric will have an + address range that is a subset of its upstream port decoder. Any deviation + from this scheme undefined per the specification. Linux prioritizes + spec-defined / architectural behavior. + +Decoders may have one or more `Downstream Targets` if configured to interleave +memory accesses. This will be presented in sysfs via the :code:`target_list` +parameter. + +Root Decoder +~~~~~~~~~~~~ +A `Root Decoder` is logical construct of the physical address and interleave +configurations present in the CFMWS field of the :doc:`CEDT +<../platform/acpi/cedt>`. +Linux presents this information as a decoder present in the `CXL Root`. We +consider this a `Root Decoder`, though technically it exists on the boundary +of the CXL specification and platform-specific CXL root implementations. + +Linux considers these logical decoders a type of `Routing Decoder`, and is the +first decoder in the CXL fabric to receive a memory access from the platform's +memory controllers. + +`Root Decoders` are created during :code:`cxl_acpi_probe`. One root decoder +is created per CFMWS entry in the :doc:`CEDT <../platform/acpi/cedt>`. + +The :code:`target_list` parameter is filled by the CFMWS target fields. Targets +of a root decoder are `Host Bridges`, which means interleave done at the root +decoder level is an `Inter-Host-Bridge Interleave`. + +Only root decoders are capable of `Inter-Host-Bridge Interleave`. + +Such interleaves must be configured by the platform and described in the ACPI +CEDT CFMWS, as the target CXL host bridge UIDs in the CFMWS must match the CXL +host bridge UIDs in the CHBS field of the :doc:`CEDT +<../platform/acpi/cedt>` and the UID field of CXL Host Bridges defined in +the :doc:`DSDT <../platform/acpi/dsdt>`. + +Interleave settings in a root decoder describe how to interleave accesses among +the *immediate downstream targets*, not the entire interleave set. + +The memory range described in the root decoder is used to + +1) Create a memory region (:code:`region0` in this example), and + +2) Associate the region with an IO Memory Resource (:code:`kernel/resource.c`) + +:: + + # ls /sys/bus/cxl/devices/decoder0.0/ + cap_pmem devtype region0 + cap_ram interleave_granularity size + cap_type2 interleave_ways start + cap_type3 locked subsystem + create_ram_region modalias target_list + delete_region qos_class uevent + + # cat /sys/bus/cxl/devices/decoder0.0/region0/resource + 0xc050000000 + +The IO Memory Resource is created during early boot when the CFMWS region is +identified in the EFI Memory Map or E820 table (on x86). + +Root decoders are defined as a separate devtype, but are also a type +of `Switch Decoder` due to having downstream targets. :: + + # cat /sys/bus/cxl/devices/decoder0.0/devtype + cxl_decoder_root + +Switch Decoder +~~~~~~~~~~~~~~ +Any non-root, translating decoder is considered a `Switch Decoder`, and will +present with the type :code:`cxl_decoder_switch`. Both `Host Bridge` and `CXL +Switch` (device) decoders are of type :code:`cxl_decoder_switch`. :: + + # ls /sys/bus/cxl/devices/decoder1.0/ + devtype locked size target_list + interleave_granularity modalias start target_type + interleave_ways region subsystem uevent + + # cat /sys/bus/cxl/devices/decoder1.0/devtype + cxl_decoder_switch + + # cat /sys/bus/cxl/devices/decoder1.0/region + region0 + +A `Switch Decoder` has associations between a region defined by a root +decoder and downstream target ports. Interleaving done within a switch decoder +is a multi-downstream-port interleave (or `Intra-Host-Bridge Interleave` for +host bridges). + +Interleave settings in a switch decoder describe how to interleave accesses +among the *immediate downstream targets*, not the entire interleave set. + +Switch decoders are created during :code:`cxl_switch_port_probe` in the +:code:`cxl_port` driver, and is created based on a PCI device's DVSEC +registers. + +Switch decoder programming is validated during probe if the platform programs +them during boot (See `Auto Decoders` below), or on commit if programmed at +runtime (See `Runtime Programming` below). + + +Endpoint Decoder +~~~~~~~~~~~~~~~~ +Any decoder attached to a *terminal* point in the CXL fabric (`An Endpoint`) is +considered an `Endpoint Decoder`. Endpoint decoders are of type +:code:`cxl_decoder_endpoint`. :: + + # ls /sys/bus/cxl/devices/decoder5.0 + devtype locked start + dpa_resource modalias subsystem + dpa_size mode target_type + interleave_granularity region uevent + interleave_ways size + + # cat /sys/bus/cxl/devices/decoder5.0/devtype + cxl_decoder_endpoint + + # cat /sys/bus/cxl/devices/decoder5.0/region + region0 + +An `Endpoint Decoder` has an association with a region defined by a root +decoder and describes the device-local resource associated with this region. + +Unlike root and switch decoders, endpoint decoders translate `Host Physical` to +`Device Physical` address ranges. The interleave settings on an endpoint +therefore describe the entire *interleave set*. + +`Device Physical Address` regions must be committed in-order. For example, the +DPA region starting at 0x80000000 cannot be committed before the DPA region +starting at 0x0. + +As of Linux v6.15, Linux does not support *imbalanced* interleave setups, all +endpoints in an interleave set are expected to have the same interleave +settings (granularity and ways must be the same). + +Endpoint decoders are created during :code:`cxl_endpoint_port_probe` in the +:code:`cxl_port` driver, and is created based on a PCI device's DVSEC registers. + +Decoder Relationships +~~~~~~~~~~~~~~~~~~~~~ +In our example described above, there is one root decoder which routes memory +accesses over two host bridges. Each host bridge has a decoder which routes +access to their singular endpoint targets. Each endpoint has a decoder which +translates HPA to DPA and services the memory request. + +The driver validates relationships between ports by decoder programming, so +we can think of decoders being related in a similarly hierarchical fashion to +ports. + +.. kernel-render:: DOT + :alt: Digraph of hierarchical relationship between root, switch, and endpoint decoders. + :caption: Diagraph of CXL root, switch, and endpoint decoders. + + digraph foo { + "root0" -> "decoder0.0"; + "decoder0.0" -> "decoder1.0"; + "decoder0.0" -> "decoder3.0"; + "decoder1.0" -> "decoder5.0"; + "decoder3.0" -> "decoder6.0"; + } + +Regions +------- + +Memory Region +~~~~~~~~~~~~~ +A `Memory Region` is a logical construct that connects a set of CXL ports in +the fabric to an IO Memory Resource. It is ultimately used to expose the memory +on these devices to the DAX subsystem via a `DAX Region`. + +An example RAM region: :: + + # ls /sys/bus/cxl/devices/region0/ + access0 devtype modalias subsystem uuid + access1 driver mode target0 + commit interleave_granularity resource target1 + dax_region0 interleave_ways size uevent + +A memory region can be constructed during endpoint probe, if decoders were +programmed by BIOS/EFI (see `Auto Decoders`), or by creating a region manually +via a `Root Decoder`'s :code:`create_ram_region` or :code:`create_pmem_region` +interfaces. + +The interleave settings in a `Memory Region` describe the configuration of the +`Interleave Set` - and are what can be expected to be seen in the endpoint +interleave settings. + +.. kernel-render:: DOT + :alt: Digraph of CXL memory region relationships between root and endpoint decoders. + :caption: Regions are created based on root decoder configurations. Endpoint decoders + must be programmed with the same interleave settings as the region. + + digraph foo { + "root0" -> "decoder0.0"; + "decoder0.0" -> "region0"; + "region0" -> "decoder5.0"; + "region0" -> "decoder6.0"; + } + +DAX Region +~~~~~~~~~~ +A `DAX Region` is used to convert a CXL `Memory Region` to a DAX device. A +DAX device may then be accessed directly via a file descriptor interface, or +converted to System RAM via the DAX kmem driver. See the DAX driver section +for more details. :: + + # ls /sys/bus/cxl/devices/dax_region0/ + dax0.0 devtype modalias uevent + dax_region driver subsystem + +Mailbox Interfaces +------------------ +A mailbox command interface for each device is exposed in :: + + /dev/cxl/mem0 + /dev/cxl/mem1 + +These mailboxes may receive any specification-defined command. Raw commands +(custom commands) can only be sent to these interfaces if the build config +:code:`CXL_MEM_RAW_COMMANDS` is set. This is considered a debug and/or +development interface, not an officially supported mechanism for creation +of vendor-specific commands (see the `fwctl` subsystem for that). + +Decoder Programming +=================== + +Runtime Programming +------------------- +During probe, the only decoders *required* to be programmed are `Root Decoders`. +In reality, `Root Decoders` are a logical construct to describe the memory +region and interleave configuration at the host bridge level - as described +in the ACPI CEDT CFMWS. + +All other `Switch` and `Endpoint` decoders may be programmed by the user +at runtime - if the platform supports such configurations. + +This interaction is what creates a `Software Defined Memory` environment. + +See the :code:`cxl-cli` documentation for more information about how to +configure CXL decoders at runtime. + +Auto Decoders +------------- +Auto Decoders are decoders programmed by BIOS/EFI at boot time, and are +almost always locked (cannot be changed). This is done by a platform +which may have a static configuration - or certain quirks which may prevent +dynamic runtime changes to the decoders (such as requiring additional +controller programming within the CPU complex outside the scope of CXL). + +Auto Decoders are probed automatically as long as the devices and memory +regions they are associated with probe without issue. When probing Auto +Decoders, the driver's primary responsibility is to ensure the fabric is +sane - as-if validating runtime programmed regions and decoders. + +If Linux cannot validate auto-decoder configuration, the memory will not +be surfaced as a DAX device - and therefore not be exposed to the page +allocator - effectively stranding it. + +Interleave +---------- + +The Linux CXL driver supports `Cross-Link First` interleave. This dictates +how interleave is programmed at each decoder step, as the driver validates +the relationships between a decoder and it's parent. + +For example, in a `Cross-Link First` interleave setup with 16 endpoints +attached to 4 host bridges, linux expects the following ways/granularity +across the root, host bridge, and endpoints respectively. + +.. flat-table:: 4x4 cross-link first interleave settings + + * - decoder + - ways + - granularity + + * - root + - 4 + - 256 + + * - host bridge + - 4 + - 1024 + + * - endpoint + - 16 + - 256 + +At the root, every a given access will be routed to the +:code:`((HPA / 256) % 4)th` target host bridge. Within a host bridge, every +:code:`((HPA / 1024) % 4)th` target endpoint. Each endpoint translates based +on the entire 16 device interleave set. + +Unbalanced interleave sets are not supported - decoders at a similar point +in the hierarchy (e.g. all host bridge decoders) must have the same ways and +granularity configuration. + +At Root +~~~~~~~ +Root decoder interleave is defined by CFMWS field of the :doc:`CEDT +<../platform/acpi/cedt>`. The CEDT may actually define multiple CFMWS +configurations to describe the same physical capacity, with the intent to allow +users to decide at runtime whether to online memory as interleaved or +non-interleaved. :: + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Window base address : 0000000100000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + First Target : 00000007 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Window base address : 0000000200000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + First Target : 00000006 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Window base address : 0000000300000000 + Window size : 0000000200000000 + Interleave Members (2^n) : 01 + Interleave Arithmetic : 00 + First Target : 00000007 + Next Target : 00000006 + +In this example, the CFMWS defines two discrete non-interleaved 4GB regions +for each host bridge, and one interleaved 8GB region that targets both. This +would result in 3 root decoders presenting in the root. :: + + # ls /sys/bus/cxl/devices/root0/decoder* + decoder0.0 decoder0.1 decoder0.2 + + # cat /sys/bus/cxl/devices/decoder0.0/target_list start size + 7 + 0x100000000 + 0x100000000 + + # cat /sys/bus/cxl/devices/decoder0.1/target_list start size + 6 + 0x200000000 + 0x100000000 + + # cat /sys/bus/cxl/devices/decoder0.2/target_list start size + 7,6 + 0x300000000 + 0x200000000 + +These decoders are not runtime programmable. They are used to generate a +`Memory Region` to bring this memory online with runtime programmed settings +at the `Switch` and `Endpoint` decoders. + +At Host Bridge or Switch +~~~~~~~~~~~~~~~~~~~~~~~~ +`Host Bridge` and `Switch` decoders are programmable via the following fields: + +- :code:`start` - the HPA region associated with the memory region +- :code:`size` - the size of the region +- :code:`target_list` - the list of downstream ports +- :code:`interleave_ways` - the number downstream ports to interleave across +- :code:`interleave_granularity` - the granularity to interleave at. + +Linux expects the :code:`interleave_granularity` of switch decoders to be +derived from their upstream port connections. In `Cross-Link First` interleave +configurations, the :code:`interleave_granularity` of a decoder is equal to +:code:`parent_interleave_granularity * parent_interleave_ways`. + +At Endpoint +~~~~~~~~~~~ +`Endpoint Decoders` are programmed similar to Host Bridge and Switch decoders, +with the exception that the ways and granularity are defined by the interleave +set (e.g. the interleave settings defined by the associated `Memory Region`). + +- :code:`start` - the HPA region associated with the memory region +- :code:`size` - the size of the region +- :code:`interleave_ways` - the number endpoints in the interleave set +- :code:`interleave_granularity` - the granularity to interleave at. + +These settings are used by endpoint decoders to *Translate* memory requests +from HPA to DPA. This is why they must be aware of the entire interleave set. + +Linux does not support unbalanced interleave configurations. As a result, all +endpoints in an interleave set must have the same ways and granularity. + +Example Configurations +====================== +.. toctree:: + :maxdepth: 1 + + example-configurations/single-device.rst + example-configurations/hb-interleave.rst + example-configurations/intra-hb-interleave.rst + example-configurations/multi-interleave.rst diff --git a/Documentation/driver-api/cxl/linux/dax-driver.rst b/Documentation/driver-api/cxl/linux/dax-driver.rst new file mode 100644 index 000000000000..10d953a2167b --- /dev/null +++ b/Documentation/driver-api/cxl/linux/dax-driver.rst @@ -0,0 +1,43 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +DAX Driver Operation +==================== +The `Direct Access Device` driver was originally designed to provide a +memory-like access mechanism to memory-like block-devices. It was +extended to support CXL Memory Devices, which provide user-configured +memory devices. + +The CXL subsystem depends on the DAX subsystem to either: + +- Generate a file-like interface to userland via :code:`/dev/daxN.Y`, or +- Engage the memory-hotplug interface to add CXL memory to page allocator. + +The DAX subsystem exposes this ability through the `cxl_dax_region` driver. +A `dax_region` provides the translation between a CXL `memory_region` and +a `DAX Device`. + +DAX Device +========== +A `DAX Device` is a file-like interface exposed in :code:`/dev/daxN.Y`. A +memory region exposed via dax device can be accessed via userland software +via the :code:`mmap()` system-call. The result is direct mappings to the +CXL capacity in the task's page tables. + +Users wishing to manually handle allocation of CXL memory should use this +interface. + +kmem conversion +=============== +The :code:`dax_kmem` driver converts a `DAX Device` into a series of `hotplug +memory blocks` managed by :code:`kernel/memory-hotplug.c`. This capacity +will be exposed to the kernel page allocator in the user-selected memory +zone. + +The :code:`memmap_on_memory` setting (both global and DAX device local) +dictates where the kernell will allocate the :code:`struct folio` descriptors +for this memory will come from. If :code:`memmap_on_memory` is set, memory +hotplug will set aside a portion of the memory block capacity to allocate +folios. If unset, the memory is allocated via a normal :code:`GFP_KERNEL` +allocation - and as a result will most likely land on the local NUM node of the +CPU executing the hotplug operation. diff --git a/Documentation/driver-api/cxl/linux/early-boot.rst b/Documentation/driver-api/cxl/linux/early-boot.rst new file mode 100644 index 000000000000..a7fc6fc85fbe --- /dev/null +++ b/Documentation/driver-api/cxl/linux/early-boot.rst @@ -0,0 +1,137 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================= +Linux Init (Early Boot) +======================= + +Linux configuration is split into two major steps: Early-Boot and everything else. + +During early boot, Linux sets up immutable resources (such as numa nodes), while +later operations include things like driver probe and memory hotplug. Linux may +read EFI and ACPI information throughout this process to configure logical +representations of the devices. + +During Linux Early Boot stage (functions in the kernel that have the __init +decorator), the system takes the resources created by EFI/BIOS +(:doc:`ACPI tables <../platform/acpi>`) and turns them into resources that the +kernel can consume. + + +BIOS, Build and Boot Options +============================ + +There are 4 pre-boot options that need to be considered during kernel build +which dictate how memory will be managed by Linux during early boot. + +* EFI_MEMORY_SP + + * BIOS/EFI Option that dictates whether memory is SystemRAM or + Specific Purpose. Specific Purpose memory will be deferred to + drivers to manage - and not immediately exposed as system RAM. + +* CONFIG_EFI_SOFT_RESERVE + + * Linux Build config option that dictates whether the kernel supports + Specific Purpose memory. + +* CONFIG_MHP_DEFAULT_ONLINE_TYPE + + * Linux Build config that dictates whether and how Specific Purpose memory + converted to a dax device should be managed (left as DAX or onlined as + SystemRAM in ZONE_NORMAL or ZONE_MOVABLE). + +* nosoftreserve + + * Linux kernel boot option that dictates whether Soft Reserve should be + supported. Similar to CONFIG_EFI_SOFT_RESERVE. + +Memory Map Creation +=================== + +While the kernel parses the EFI memory map, if :code:`Specific Purpose` memory +is supported and detected, it will set this region aside as +:code:`SOFT_RESERVED`. + +If :code:`EFI_MEMORY_SP=0`, :code:`CONFIG_EFI_SOFT_RESERVE=n`, or +:code:`nosoftreserve=y` - Linux will default a CXL device memory region to +SystemRAM. This will expose the memory to the kernel page allocator in +:code:`ZONE_NORMAL`, making it available for use for most allocations (including +:code:`struct page` and page tables). + +If `Specific Purpose` is set and supported, :code:`CONFIG_MHP_DEFAULT_ONLINE_TYPE_*` +dictates whether the memory is onlined by default (:code:`_OFFLINE` or +:code:`_ONLINE_*`), and if online which zone to online this memory to by default +(:code:`_NORMAL` or :code:`_MOVABLE`). + +If placed in :code:`ZONE_MOVABLE`, the memory will not be available for most +kernel allocations (such as :code:`struct page` or page tables). This may +significant impact performance depending on the memory capacity of the system. + + +NUMA Node Reservation +===================== + +Linux refers to the proximity domains (:code:`PXM`) defined in the :doc:`SRAT +<../platform/acpi/srat>` to create NUMA nodes in :code:`acpi_numa_init`. +Typically, there is a 1:1 relation between :code:`PXM` and NUMA node IDs. + +The SRAT is the only ACPI defined way of defining Proximity Domains. Linux +chooses to, at most, map those 1:1 with NUMA nodes. +:doc:`CEDT <../platform/acpi/cedt>` adds a description of SPA ranges which +Linux may map to one or more NUMA nodes. + +If there are CXL ranges in the CFMWS but not in SRAT, then a fake :code:`PXM` +is created (as of v6.15). In the future, Linux may reject CFMWS not described +by SRAT due to the ambiguity of proximity domain association. + +It is important to note that NUMA node creation cannot be done at runtime. All +possible NUMA nodes are identified at :code:`__init` time, more specifically +during :code:`mm_init`. The CEDT and SRAT must contain sufficient :code:`PXM` +data for Linux to identify NUMA nodes their associated memory regions. + +The relevant code exists in: :code:`linux/drivers/acpi/numa/srat.c`. + +See :doc:`Example Platform Configurations <../platform/example-configs>` +for more info. + +Memory Tiers Creation +===================== +Memory tiers are a collection of NUMA nodes grouped by performance characteristics. +During :code:`__init`, Linux initializes the system with a default memory tier that +contains all nodes marked :code:`N_MEMORY`. + +:code:`memory_tier_init` is called at boot for all nodes with memory online by +default. :code:`memory_tier_late_init` is called during late-init for nodes setup +during driver configuration. + +Nodes are only marked :code:`N_MEMORY` if they have *online* memory. + +Tier membership can be inspected in :: + + /sys/devices/virtual/memory_tiering/memory_tierN/nodelist + 0-1 + +If nodes are grouped which have clear difference in performance, check the +:doc:`HMAT <../platform/acpi/hmat>` and CDAT information for the CXL nodes. All +nodes default to the DRAM tier, unless HMAT/CDAT information is reported to the +memory_tier component via `access_coordinates`. + +For more, see :doc:`CXL access coordinates documentation +<../linux/access-coordinates>`. + +Contiguous Memory Allocation +============================ +The contiguous memory allocator (CMA) enables reservation of contiguous memory +regions on NUMA nodes during early boot. However, CMA cannot reserve memory +on NUMA nodes that are not online during early boot. :: + + void __init hugetlb_cma_reserve(int order) { + if (!node_online(nid)) + /* do not allow reservations */ + } + +This means if users intend to defer management of CXL memory to the driver, CMA +cannot be used to guarantee huge page allocations. If enabling CXL memory as +SystemRAM in `ZONE_NORMAL` during early boot, CMA reservations per-node can be +made with the :code:`cma_pernuma` or :code:`numa_cma` kernel command line +parameters. diff --git a/Documentation/driver-api/cxl/linux/example-configurations/hb-interleave.rst b/Documentation/driver-api/cxl/linux/example-configurations/hb-interleave.rst new file mode 100644 index 000000000000..f071490763a2 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/example-configurations/hb-interleave.rst @@ -0,0 +1,314 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Inter-Host-Bridge Interleave +============================ +This cxl-cli configuration dump shows the following host configuration: + +* A single socket system with one CXL root +* CXL Root has Four (4) CXL Host Bridges +* Two CXL Host Bridges have a single CXL Memory Expander Attached +* The CXL root is configured to interleave across the two host bridges. + +This output is generated by :code:`cxl list -v` and describes the relationships +between objects exposed in :code:`/sys/bus/cxl/devices/`. + +:: + + [ + { + "bus":"root0", + "provider":"ACPI.CXL", + "nr_dports":4, + "dports":[ + { + "dport":"pci0000:00", + "alias":"ACPI0016:01", + "id":0 + }, + { + "dport":"pci0000:a8", + "alias":"ACPI0016:02", + "id":4 + }, + { + "dport":"pci0000:2a", + "alias":"ACPI0016:03", + "id":1 + }, + { + "dport":"pci0000:d2", + "alias":"ACPI0016:00", + "id":5 + } + ], + +This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL +Host Bridges. The `Root` can be considered the singular upstream port attached +to the platform's memory controller - which routes memory requests to it. + +The `ports:root0` section lays out how each of these downstream ports are +configured. If a port is not configured (id's 0 and 1), they are omitted. + +:: + + "ports:root0":[ + { + "port":"port1", + "host":"pci0000:d2", + "depth":1, + "nr_dports":3, + "dports":[ + { + "dport":"0000:d2:01.1", + "alias":"device:02", + "id":0 + }, + { + "dport":"0000:d2:01.3", + "alias":"device:05", + "id":2 + }, + { + "dport":"0000:d2:07.1", + "alias":"device:0d", + "id":113 + } + ], + +This chunk shows the available downstream ports associated with the CXL Host +Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream +ports: :code:`dport1`, :code:`dport2`, and :code:`dport113`.. + +:: + + "endpoints:port1":[ + { + "endpoint":"endpoint5", + "host":"mem0", + "parent_dport":"0000:d2:01.1", + "depth":2, + "memdev":{ + "memdev":"mem0", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:d3:00.0" + }, + "decoders:endpoint5":[ + { + "decoder":"decoder5.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + +This chunk shows the endpoints attached to the host bridge :code:`port1`. + +:code:`endpoint5` contains a single configured decoder :code:`decoder5.0` +which has the same interleave configuration as :code:`region0` (shown later). + +Next we have the decodesr belonging to the host bridge: + +:: + + "decoders:port1":[ + { + "decoder":"decoder1.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":1, + "region":"region0", + "nr_targets":1, + "targets":[ + { + "target":"0000:d2:01.1", + "alias":"device:02", + "position":0, + "id":0 + } + ] + } + ] + }, + +Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`), whose only +target is :code:`dport1` - which is attached to :code:`endpoint5`. + +The following chunk shows a similar configuration for Host Bridge :code:`port3`, +the second host bridge with a memory device attached. + +:: + + { + "port":"port3", + "host":"pci0000:a8", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:a8:01.1", + "alias":"device:c3", + "id":0 + } + ], + "endpoints:port3":[ + { + "endpoint":"endpoint6", + "host":"mem1", + "parent_dport":"0000:a8:01.1", + "depth":2, + "memdev":{ + "memdev":"mem1", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:a9:00.0" + }, + "decoders:endpoint6":[ + { + "decoder":"decoder6.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + "decoders:port3":[ + { + "decoder":"decoder3.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":1, + "region":"region0", + "nr_targets":1, + "targets":[ + { + "target":"0000:a8:01.1", + "alias":"device:c3", + "position":0, + "id":0 + } + ] + } + ] + }, + + +The next chunk shows the two CXL host bridges without attached endpoints. + +:: + + { + "port":"port2", + "host":"pci0000:00", + "depth":1, + "nr_dports":2, + "dports":[ + { + "dport":"0000:00:01.3", + "alias":"device:55", + "id":2 + }, + { + "dport":"0000:00:07.1", + "alias":"device:5d", + "id":113 + } + ] + }, + { + "port":"port4", + "host":"pci0000:2a", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:2a:01.1", + "alias":"device:d0", + "id":0 + } + ] + } + ], + +Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder +applies the interleave across the downstream ports :code:`port1` and +:code:`port3` - with a granularity of 256 bytes. + +This information is generated by the CXL driver reading the ACPI CEDT CMFWS. + +:: + + "decoders:root0":[ + { + "decoder":"decoder0.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "max_available_extent":0, + "volatile_capable":true, + "nr_targets":2, + "targets":[ + { + "target":"pci0000:a8", + "alias":"ACPI0016:02", + "position":1, + "id":4 + }, + { + "target":"pci0000:d2", + "alias":"ACPI0016:00", + "position":0, + "id":5 + } + ], + +Finally we have the `Memory Region` associated with the `Root Decoder` +:code:`decoder0.0`. This region describes the overall interleave configuration +of the interleave set. + +:: + + "regions:decoder0.0":[ + { + "region":"region0", + "resource":825975898112, + "size":274877906944, + "type":"ram", + "interleave_ways":2, + "interleave_granularity":256, + "decode_state":"commit", + "mappings":[ + { + "position":1, + "memdev":"mem1", + "decoder":"decoder6.0" + }, + { + "position":0, + "memdev":"mem0", + "decoder":"decoder5.0" + } + ] + } + ] + } + ] + } + ] diff --git a/Documentation/driver-api/cxl/linux/example-configurations/intra-hb-interleave.rst b/Documentation/driver-api/cxl/linux/example-configurations/intra-hb-interleave.rst new file mode 100644 index 000000000000..077dfaf8458d --- /dev/null +++ b/Documentation/driver-api/cxl/linux/example-configurations/intra-hb-interleave.rst @@ -0,0 +1,291 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Intra-Host-Bridge Interleave +============================ +This cxl-cli configuration dump shows the following host configuration: + +* A single socket system with one CXL root +* CXL Root has Four (4) CXL Host Bridges +* One (1) CXL Host Bridges has two CXL Memory Expanders Attached +* The Host bridge decoder is programmed to interleave across the expanders. + +This output is generated by :code:`cxl list -v` and describes the relationships +between objects exposed in :code:`/sys/bus/cxl/devices/`. + +:: + + [ + { + "bus":"root0", + "provider":"ACPI.CXL", + "nr_dports":4, + "dports":[ + { + "dport":"pci0000:00", + "alias":"ACPI0016:01", + "id":0 + }, + { + "dport":"pci0000:a8", + "alias":"ACPI0016:02", + "id":4 + }, + { + "dport":"pci0000:2a", + "alias":"ACPI0016:03", + "id":1 + }, + { + "dport":"pci0000:d2", + "alias":"ACPI0016:00", + "id":5 + } + ], + +This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL +Host Bridges. The `Root` can be considered the singular upstream port attached +to the platform's memory controller - which routes memory requests to it. + +The `ports:root0` section lays out how each of these downstream ports are +configured. If a port is not configured (id's 0 and 1), they are omitted. + +:: + + "ports:root0":[ + { + "port":"port1", + "host":"pci0000:d2", + "depth":1, + "nr_dports":3, + "dports":[ + { + "dport":"0000:d2:01.1", + "alias":"device:02", + "id":0 + }, + { + "dport":"0000:d2:01.3", + "alias":"device:05", + "id":2 + }, + { + "dport":"0000:d2:07.1", + "alias":"device:0d", + "id":113 + } + ], + +This chunk shows the available downstream ports associated with the CXL Host +Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream +ports: :code:`dport1`, :code:`dport2`, and :code:`dport113`.. + +:: + + "endpoints:port1":[ + { + "endpoint":"endpoint5", + "host":"mem0", + "parent_dport":"0000:d2:01.1", + "depth":2, + "memdev":{ + "memdev":"mem0", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:d3:00.0" + }, + "decoders:endpoint5":[ + { + "decoder":"decoder5.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + }, + { + "endpoint":"endpoint6", + "host":"mem1", + "parent_dport":"0000:d2:01.3, + "depth":2, + "memdev":{ + "memdev":"mem1", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:a9:00.0" + }, + "decoders:endpoint6":[ + { + "decoder":"decoder6.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + +This chunk shows the endpoints attached to the host bridge :code:`port1`. + +:code:`endpoint5` contains a single configured decoder :code:`decoder5.0` +which has the same interleave configuration memory region they belong to +(show later). + +Next we have the decoders belonging to the host bridge: + +:: + + "decoders:port1":[ + { + "decoder":"decoder1.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "region":"region0", + "nr_targets":2, + "targets":[ + { + "target":"0000:d2:01.1", + "alias":"device:02", + "position":0, + "id":0 + }, + { + "target":"0000:d2:01.3", + "alias":"device:05", + "position":1, + "id":0 + } + ] + } + ] + }, + +Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`) with two +targets: :code:`dport1` and :code:`dport3` - which are attached to +:code:`endpoint5` and :code:`endpoint6` respectively. + +The host bridge decoder interleaves these devices at a 256 byte granularity. + +The next chunk shows the three CXL host bridges without attached endpoints. + +:: + + { + "port":"port2", + "host":"pci0000:00", + "depth":1, + "nr_dports":2, + "dports":[ + { + "dport":"0000:00:01.3", + "alias":"device:55", + "id":2 + }, + { + "dport":"0000:00:07.1", + "alias":"device:5d", + "id":113 + } + ] + }, + { + "port":"port3", + "host":"pci0000:a8", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:a8:01.1", + "alias":"device:c3", + "id":0 + } + ], + }, + { + "port":"port4", + "host":"pci0000:2a", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:2a:01.1", + "alias":"device:d0", + "id":0 + } + ] + } + ], + +Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder +applies the interleave across the downstream ports :code:`port1` and +:code:`port3` - with a granularity of 256 bytes. + +This information is generated by the CXL driver reading the ACPI CEDT CMFWS. + +:: + + "decoders:root0":[ + { + "decoder":"decoder0.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":1, + "max_available_extent":0, + "volatile_capable":true, + "nr_targets":2, + "targets":[ + { + "target":"pci0000:a8", + "alias":"ACPI0016:02", + "position":1, + "id":4 + }, + ], + +Finally we have the `Memory Region` associated with the `Root Decoder` +:code:`decoder0.0`. This region describes the overall interleave configuration +of the interleave set. + +:: + + "regions:decoder0.0":[ + { + "region":"region0", + "resource":825975898112, + "size":274877906944, + "type":"ram", + "interleave_ways":2, + "interleave_granularity":256, + "decode_state":"commit", + "mappings":[ + { + "position":1, + "memdev":"mem1", + "decoder":"decoder6.0" + }, + { + "position":0, + "memdev":"mem0", + "decoder":"decoder5.0" + } + ] + } + ] + } + ] + } + ] diff --git a/Documentation/driver-api/cxl/linux/example-configurations/multi-interleave.rst b/Documentation/driver-api/cxl/linux/example-configurations/multi-interleave.rst new file mode 100644 index 000000000000..008f9053c630 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/example-configurations/multi-interleave.rst @@ -0,0 +1,401 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================== +Multi-Level Interleave +====================== +This cxl-cli configuration dump shows the following host configuration: + +* A single socket system with one CXL root +* CXL Root has Four (4) CXL Host Bridges +* Two CXL Host Bridges have a two CXL Memory Expanders Attached each. +* The CXL root is configured to interleave across the two host bridges. +* Each host bridge with expanders interleaves across two endpoints. + +This output is generated by :code:`cxl list -v` and describes the relationships +between objects exposed in :code:`/sys/bus/cxl/devices/`. + +:: + + [ + { + "bus":"root0", + "provider":"ACPI.CXL", + "nr_dports":4, + "dports":[ + { + "dport":"pci0000:00", + "alias":"ACPI0016:01", + "id":0 + }, + { + "dport":"pci0000:a8", + "alias":"ACPI0016:02", + "id":4 + }, + { + "dport":"pci0000:2a", + "alias":"ACPI0016:03", + "id":1 + }, + { + "dport":"pci0000:d2", + "alias":"ACPI0016:00", + "id":5 + } + ], + +This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL +Host Bridges. The `Root` can be considered the singular upstream port attached +to the platform's memory controller - which routes memory requests to it. + +The `ports:root0` section lays out how each of these downstream ports are +configured. If a port is not configured (id's 0 and 1), they are omitted. + +:: + + "ports:root0":[ + { + "port":"port1", + "host":"pci0000:d2", + "depth":1, + "nr_dports":3, + "dports":[ + { + "dport":"0000:d2:01.1", + "alias":"device:02", + "id":0 + }, + { + "dport":"0000:d2:01.3", + "alias":"device:05", + "id":2 + }, + { + "dport":"0000:d2:07.1", + "alias":"device:0d", + "id":113 + } + ], + +This chunk shows the available downstream ports associated with the CXL Host +Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream +ports: :code:`dport0`, :code:`dport2`, and :code:`dport113`. + +:: + + "endpoints:port1":[ + { + "endpoint":"endpoint5", + "host":"mem0", + "parent_dport":"0000:d2:01.1", + "depth":2, + "memdev":{ + "memdev":"mem0", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:d3:00.0" + }, + "decoders:endpoint5":[ + { + "decoder":"decoder5.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":4, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + }, + { + "endpoint":"endpoint6", + "host":"mem1", + "parent_dport":"0000:d2:01.3", + "depth":2, + "memdev":{ + "memdev":"mem1", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:d3:00.0" + }, + "decoders:endpoint6":[ + { + "decoder":"decoder6.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":4, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + +This chunk shows the endpoints attached to the host bridge :code:`port1`. + +:code:`endpoint5` contains a single configured decoder :code:`decoder5.0` +which has the same interleave configuration as :code:`region0` (shown later). + +:code:`endpoint6` contains a single configured decoder :code:`decoder5.0` +which has the same interleave configuration as :code:`region0` (shown later). + +Next we have the decoders belonging to the host bridge: + +:: + + "decoders:port1":[ + { + "decoder":"decoder1.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":2, + "interleave_granularity":512, + "region":"region0", + "nr_targets":2, + "targets":[ + { + "target":"0000:d2:01.1", + "alias":"device:02", + "position":0, + "id":0 + }, + { + "target":"0000:d2:01.3", + "alias":"device:05", + "position":2, + "id":0 + } + ] + } + ] + }, + +Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`), whose +targets are :code:`dport0` and :code:`dport2` - which are attached to +:code:`endpoint5` and :code:`endpoint6` respectively. + +The following chunk shows a similar configuration for Host Bridge :code:`port3`, +the second host bridge with a memory device attached. + +:: + + { + "port":"port3", + "host":"pci0000:a8", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:a8:01.1", + "alias":"device:c3", + "id":0 + }, + { + "dport":"0000:a8:01.3", + "alias":"device:c5", + "id":0 + } + ], + "endpoints:port3":[ + { + "endpoint":"endpoint7", + "host":"mem2", + "parent_dport":"0000:a8:01.1", + "depth":2, + "memdev":{ + "memdev":"mem2", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:a9:00.0" + }, + "decoders:endpoint7":[ + { + "decoder":"decoder7.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":4, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + }, + { + "endpoint":"endpoint8", + "host":"mem3", + "parent_dport":"0000:a8:01.3", + "depth":2, + "memdev":{ + "memdev":"mem3", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:a9:00.0" + }, + "decoders:endpoint8":[ + { + "decoder":"decoder8.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":4, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + "decoders:port3":[ + { + "decoder":"decoder3.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":2, + "interleave_granularity":512, + "region":"region0", + "nr_targets":1, + "targets":[ + { + "target":"0000:a8:01.1", + "alias":"device:c3", + "position":1, + "id":0 + }, + { + "target":"0000:a8:01.3", + "alias":"device:c5", + "position":3, + "id":0 + } + ] + } + ] + }, + + +The next chunk shows the two CXL host bridges without attached endpoints. + +:: + + { + "port":"port2", + "host":"pci0000:00", + "depth":1, + "nr_dports":2, + "dports":[ + { + "dport":"0000:00:01.3", + "alias":"device:55", + "id":2 + }, + { + "dport":"0000:00:07.1", + "alias":"device:5d", + "id":113 + } + ] + }, + { + "port":"port4", + "host":"pci0000:2a", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:2a:01.1", + "alias":"device:d0", + "id":0 + } + ] + } + ], + +Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder +applies the interleave across the downstream ports :code:`port1` and +:code:`port3` - with a granularity of 256 bytes. + +This information is generated by the CXL driver reading the ACPI CEDT CMFWS. + +:: + + "decoders:root0":[ + { + "decoder":"decoder0.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":2, + "interleave_granularity":256, + "max_available_extent":0, + "volatile_capable":true, + "nr_targets":2, + "targets":[ + { + "target":"pci0000:a8", + "alias":"ACPI0016:02", + "position":1, + "id":4 + }, + { + "target":"pci0000:d2", + "alias":"ACPI0016:00", + "position":0, + "id":5 + } + ], + +Finally we have the `Memory Region` associated with the `Root Decoder` +:code:`decoder0.0`. This region describes the overall interleave configuration +of the interleave set. So we see there are a total of :code:`4` interleave +targets across 4 endpoint decoders. + +:: + + "regions:decoder0.0":[ + { + "region":"region0", + "resource":825975898112, + "size":549755813888, + "type":"ram", + "interleave_ways":4, + "interleave_granularity":256, + "decode_state":"commit", + "mappings":[ + { + "position":3, + "memdev":"mem3", + "decoder":"decoder8.0" + }, + { + "position":2, + "memdev":"mem1", + "decoder":"decoder6.0" + } + { + "position":1, + "memdev":"mem2", + "decoder":"decoder7.0" + }, + { + "position":0, + "memdev":"mem0", + "decoder":"decoder5.0" + } + ] + } + ] + } + ] + } + ] diff --git a/Documentation/driver-api/cxl/linux/example-configurations/single-device.rst b/Documentation/driver-api/cxl/linux/example-configurations/single-device.rst new file mode 100644 index 000000000000..5fd38eb0aaf4 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/example-configurations/single-device.rst @@ -0,0 +1,246 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +Single Device +============= +This cxl-cli configuration dump shows the following host configuration: + +* A single socket system with one CXL root +* CXL Root has Four (4) CXL Host Bridges +* One CXL Host Bridges has a single CXL Memory Expander Attached +* No interleave is present. + +This output is generated by :code:`cxl list -v` and describes the relationships +between objects exposed in :code:`/sys/bus/cxl/devices/`. + +:: + + [ + { + "bus":"root0", + "provider":"ACPI.CXL", + "nr_dports":4, + "dports":[ + { + "dport":"pci0000:00", + "alias":"ACPI0016:01", + "id":0 + }, + { + "dport":"pci0000:a8", + "alias":"ACPI0016:02", + "id":4 + }, + { + "dport":"pci0000:2a", + "alias":"ACPI0016:03", + "id":1 + }, + { + "dport":"pci0000:d2", + "alias":"ACPI0016:00", + "id":5 + } + ], + +This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL +Host Bridges. The `Root` can be considered the singular upstream port attached +to the platform's memory controller - which routes memory requests to it. + +The `ports:root0` section lays out how each of these downstream ports are +configured. If a port is not configured (id's 0, 1, and 4), they are omitted. + +:: + + "ports:root0":[ + { + "port":"port1", + "host":"pci0000:d2", + "depth":1, + "nr_dports":3, + "dports":[ + { + "dport":"0000:d2:01.1", + "alias":"device:02", + "id":0 + }, + { + "dport":"0000:d2:01.3", + "alias":"device:05", + "id":2 + }, + { + "dport":"0000:d2:07.1", + "alias":"device:0d", + "id":113 + } + ], + +This chunk shows the available downstream ports associated with the CXL Host +Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream +ports: :code:`dport1`, :code:`dport2`, and :code:`dport113`.. + +:: + + "endpoints:port1":[ + { + "endpoint":"endpoint5", + "host":"mem0", + "parent_dport":"0000:d2:01.1", + "depth":2, + "memdev":{ + "memdev":"mem0", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:d3:00.0" + }, + "decoders:endpoint5":[ + { + "decoder":"decoder5.0", + "resource":825975898112, + "size":137438953472, + "interleave_ways":1, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + +This chunk shows the endpoints attached to the host bridge :code:`port1`. + +:code:`endpoint5` contains a single configured decoder :code:`decoder5.0` +which has the same interleave configuration as :code:`region0` (shown later). + +Next we have the decoders belonging to the host bridge: + +:: + + "decoders:port1":[ + { + "decoder":"decoder1.0", + "resource":825975898112, + "size":137438953472, + "interleave_ways":1, + "region":"region0", + "nr_targets":1, + "targets":[ + { + "target":"0000:d2:01.1", + "alias":"device:02", + "position":0, + "id":0 + } + ] + } + ] + }, + +Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`), whose only +target is :code:`dport1` - which is attached to :code:`endpoint5`. + +The next chunk shows the three CXL host bridges without attached endpoints. + +:: + + { + "port":"port2", + "host":"pci0000:00", + "depth":1, + "nr_dports":2, + "dports":[ + { + "dport":"0000:00:01.3", + "alias":"device:55", + "id":2 + }, + { + "dport":"0000:00:07.1", + "alias":"device:5d", + "id":113 + } + ] + }, + { + "port":"port3", + "host":"pci0000:a8", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:a8:01.1", + "alias":"device:c3", + "id":0 + } + ] + }, + { + "port":"port4", + "host":"pci0000:2a", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:2a:01.1", + "alias":"device:d0", + "id":0 + } + ] + } + ], + +Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder +is a pass-through decoder because :code:`interleave_ways` is set to :code:`1`. + +This information is generated by the CXL driver reading the ACPI CEDT CMFWS. + +:: + + "decoders:root0":[ + { + "decoder":"decoder0.0", + "resource":825975898112, + "size":137438953472, + "interleave_ways":1, + "max_available_extent":0, + "volatile_capable":true, + "nr_targets":1, + "targets":[ + { + "target":"pci0000:d2", + "alias":"ACPI0016:00", + "position":0, + "id":5 + } + ], + +Finally we have the `Memory Region` associated with the `Root Decoder` +:code:`decoder0.0`. This region describes the discrete region associated +with the lone device. + +:: + + "regions:decoder0.0":[ + { + "region":"region0", + "resource":825975898112, + "size":137438953472, + "type":"ram", + "interleave_ways":1, + "decode_state":"commit", + "mappings":[ + { + "position":0, + "memdev":"mem0", + "decoder":"decoder5.0" + } + ] + } + ] + } + ] + } + ] diff --git a/Documentation/driver-api/cxl/linux/memory-hotplug.rst b/Documentation/driver-api/cxl/linux/memory-hotplug.rst new file mode 100644 index 000000000000..af368c2bc9cf --- /dev/null +++ b/Documentation/driver-api/cxl/linux/memory-hotplug.rst @@ -0,0 +1,78 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +Memory Hotplug +============== +The final phase of surfacing CXL memory to the kernel page allocator is for +the `DAX` driver to surface a `Driver Managed` memory region via the +memory-hotplug component. + +There are four major configurations to consider: + +1) Default Online Behavior (on/off and zone) +2) Hotplug Memory Block size +3) Memory Map Resource location +4) Driver-Managed Memory Designation + +Default Online Behavior +======================= +The default-online behavior of hotplug memory is dictated by the following, +in order of precedence: + +- :code:`CONFIG_MHP_DEFAULT_ONLINE_TYPE` Build Configuration +- :code:`memhp_default_state` Boot parameter +- :code:`/sys/devices/system/memory/auto_online_blocks` value + +These dictate whether hotplugged memory blocks arrive in one of three states: + +1) Offline +2) Online in :code:`ZONE_NORMAL` +3) Online in :code:`ZONE_MOVABLE` + +:code:`ZONE_NORMAL` implies this capacity may be used for almost any allocation, +while :code:`ZONE_MOVABLE` implies this capacity should only be used for +migratable allocations. + +:code:`ZONE_MOVABLE` attempts to retain the hotplug-ability of a memory block +so that it the entire region may be hot-unplugged at a later time. Any capacity +onlined into :code:`ZONE_NORMAL` should be considered permanently attached to +the page allocator. + +Hotplug Memory Block Size +========================= +By default, on most architectures, the Hotplug Memory Block Size is either +128MB or 256MB. On x86, the block size increases up to 2GB as total memory +capacity exceeds 64GB. As of v6.15, Linux does not take into account the +size and alignment of the ACPI CEDT CFMWS regions (see Early Boot docs) when +deciding the Hotplug Memory Block Size. + +Memory Map +========== +The location of :code:`struct folio` allocations to represent the hotplugged +memory capacity are dictated by the following system settings: + +- :code:`/sys_module/memory_hotplug/parameters/memmap_on_memory` +- :code:`/sys/bus/dax/devices/daxN.Y/memmap_on_memory` + +If both of these parameters are set to true, :code:`struct folio` for this +capacity will be carved out of the memory block being onlined. This has +performance implications if the memory is particularly high-latency and +its :code:`struct folio` becomes hotly contended. + +If either parameter is set to false, :code:`struct folio` for this capacity +will be allocated from the local node of the processor running the hotplug +procedure. This capacity will be allocated from :code:`ZONE_NORMAL` on +that node, as it is a :code:`GFP_KERNEL` allocation. + +Systems with extremely large amounts of :code:`ZONE_MOVABLE` memory (e.g. +CXL memory pools) must ensure that there is sufficient local +:code:`ZONE_NORMAL` capacity to host the memory map for the hotplugged capacity. + +Driver Managed Memory +===================== +The DAX driver surfaces this memory to memory-hotplug as "Driver Managed". This +is not a configurable setting, but it's important to note that driver managed +memory is explicitly excluded from use during kexec. This is required to ensure +any reset or out-of-band operations that the CXL device may be subject to during +a functional system-reboot (such as a reset-on-probe) will not cause portions of +the kexec kernel to be overwritten. diff --git a/Documentation/driver-api/cxl/linux/overview.rst b/Documentation/driver-api/cxl/linux/overview.rst new file mode 100644 index 000000000000..648beb2c8c83 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/overview.rst @@ -0,0 +1,103 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======== +Overview +======== + +This section presents the configuration process of a CXL Type-3 memory device, +and how it is ultimately exposed to users as either a :code:`DAX` device or +normal memory pages via the kernel's page allocator. + +Portions marked with a bullet are points at which certain kernel objects +are generated. + +1) Early Boot + + a) BIOS, Build, and Boot Parameters + + i) EFI_MEMORY_SP + ii) CONFIG_EFI_SOFT_RESERVE + iii) CONFIG_MHP_DEFAULT_ONLINE_TYPE + iv) nosoftreserve + + b) Memory Map Creation + + i) EFI Memory Map / E820 Consulted for Soft-Reserved + + * CXL Memory is set aside to be handled by the CXL driver + + * Soft-Reserved IO Resource created for CFMWS entry + + c) NUMA Node Creation + + * Nodes created from ACPI CEDT CFMWS and SRAT Proximity domains (PXM) + + d) Memory Tier Creation + + * A default memory_tier is created with all nodes. + + e) Contiguous Memory Allocation + + * Any requested CMA is allocated from Online nodes + + f) Init Finishes, Drivers start probing + +2) ACPI and PCI Drivers + + a) Detects PCI device is CXL, marking it for probe by CXL driver + +3) CXL Driver Operation + + a) Base device creation + + * root, port, and memdev devices created + * CEDT CFMWS IO Resource creation + + b) Decoder creation + + * root, switch, and endpoint decoders created + + c) Logical device creation + + * memory_region and endpoint devices created + + d) Devices are associated with each other + + * If auto-decoder (BIOS-programmed decoders), driver validates + configurations, builds associations, and locks configs at probe time. + + * If user-configured, validation and associations are built at + decoder-commit time. + + e) Regions surfaced as DAX region + + * dax_region created + + * DAX device created via DAX driver + +4) DAX Driver Operation + + a) DAX driver surfaces DAX region as one of two dax device modes + + * kmem - dax device is converted to hotplug memory blocks + + * DAX kmem IO Resource creation + + * hmem - dax device is left as daxdev to be accessed as a file. + + * If hmem, journey ends here. + + b) DAX kmem surfaces memory region to Memory Hotplug to add to page + allocator as "driver managed memory" + +5) Memory Hotplug + + a) mhp component surfaces a dax device memory region as multiple memory + blocks to the page allocator + + * blocks appear in :code:`/sys/bus/memory/devices` and linked to a NUMA node + + b) blocks are onlined into the requested zone (NORMAL or MOVABLE) + + * Memory is marked "Driver Managed" to avoid kexec from using it as region + for kernel updates diff --git a/Documentation/driver-api/cxl/maturity-map.rst b/Documentation/driver-api/cxl/maturity-map.rst index a2288f9df658..1330f3f52129 100644 --- a/Documentation/driver-api/cxl/maturity-map.rst +++ b/Documentation/driver-api/cxl/maturity-map.rst @@ -51,9 +51,9 @@ in place, but there are several corner cases that are pending closure. * [2] CXL Window Enumeration - * [0] :ref:`Extended-linear memory-side cache <extended-linear>` + * [2] :ref:`Extended-linear memory-side cache <extended-linear>` * [0] Low Memory-hole - * [0] Hetero-interleave + * [X] Hetero-interleave * [2] Switch Enumeration @@ -173,7 +173,7 @@ Accelerator User Flow Support ----------------- -* [0] HPA->DPA Address translation (need xormaps export solution) +* [0] Inject & clear poison by HPA Details ======= diff --git a/Documentation/driver-api/cxl/platform/acpi.rst b/Documentation/driver-api/cxl/platform/acpi.rst new file mode 100644 index 000000000000..ee7e6bd4c43d --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi.rst @@ -0,0 +1,76 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========== +ACPI Tables +=========== + +ACPI is the "Advanced Configuration and Power Interface", which is a standard +that defines how platforms and OS manage power and configure computer hardware. +For the purpose of this theory of operation, when referring to "ACPI" we will +usually refer to "ACPI Tables" - which are the way a platform (BIOS/EFI) +communicates static configuration information to the operation system. + +The Following ACPI tables contain *static* configuration and performance data +about CXL devices. + +.. toctree:: + :maxdepth: 1 + + acpi/cedt.rst + acpi/srat.rst + acpi/hmat.rst + acpi/slit.rst + acpi/dsdt.rst + +The SRAT table may also contain generic port/initiator content that is intended +to describe the generic port, but not information about the rest of the path to +the endpoint. + +Linux uses these tables to configure kernel resources for statically configured +(by BIOS/EFI) CXL devices, such as: + +- NUMA nodes +- Memory Tiers +- NUMA Abstract Distances +- SystemRAM Memory Regions +- Weighted Interleave Node Weights + +ACPI Debugging +============== + +The :code:`acpidump -b` command dumps the ACPI tables into binary format. + +The :code:`iasl -d` command disassembles the files into human readable format. + +Example :code:`acpidump -b && iasl -d cedt.dat` :: + + [000h 0000 4] Signature : "CEDT" [CXL Early Discovery Table] + +Common Issues +------------- +Most failures described here result in a failure of the driver to surface +memory as a DAX device and/or kmem. + +* CEDT CFMWS targets list UIDs do not match CEDT CHBS UIDs. +* CEDT CFMWS targets list UIDs do not match DSDT CXL Host Bridge UIDs. +* CEDT CFMWS Restriction Bits are not correct. +* CEDT CFMWS Memory regions are poorly aligned. +* CEDT CFMWS Memory regions spans a platform memory hole. +* CEDT CHBS UIDs do not match DSDT CXL Host Bridge UIDs. +* CEDT CHBS Specification version is incorrect. +* SRAT is missing regions described in CEDT CFMWS. + + * Result: failure to create a NUMA node for the region, or + region is placed in wrong node. + +* HMAT is missing data for regions described in CEDT CFMWS. + + * Result: NUMA node being placed in the wrong memory tier. + +* SLIT has bad data. + + * Result: Lots of performance mechanisms in the kernel will be very unhappy. + +All of these issues will appear to users as if the driver is failing to +support CXL - when in reality they are all the failure of a platform to +configure the ACPI tables correctly. diff --git a/Documentation/driver-api/cxl/platform/acpi/cedt.rst b/Documentation/driver-api/cxl/platform/acpi/cedt.rst new file mode 100644 index 000000000000..1d9c9d3592dc --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi/cedt.rst @@ -0,0 +1,62 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================ +CEDT - CXL Early Discovery Table +================================ + +The CXL Early Discovery Table is generated by BIOS to describe the CXL memory +regions configured at boot by the BIOS. + +CHBS +==== +The CXL Host Bridge Structure describes CXL host bridges. Other than describing +device register information, it reports the specific host bridge UID for this +host bridge. These host bridge ID's will be referenced in other tables. + +Example :: + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000007 <- Host bridge _UID + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010370400000 + Register length : 0000000000010000 + +CFMWS +===== +The CXL Fixed Memory Window structure describes a memory region associated +with one or more CXL host bridges (as described by the CHBS). It additionally +describes any inter-host-bridge interleave configuration that may have been +programmed by BIOS. + +Example :: + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 000000C050000000 <- Memory Region + Window size : 0000003CA0000000 + Interleave Members (2^n) : 01 <- Interleave configuration + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 <- Host Bridge _UID + Next Target : 00000006 <- Host Bridge _UID + +The restriction field dictates what this SPA range may be used for (memory type, +voltile vs persistent, etc). One or more bits may be set. :: + + Bit[0]: CXL Type 2 Memory + Bit[1]: CXL Type 3 Memory + Bit[2]: Volatile Memory + Bit[3]: Persistent Memory + Bit[4]: Fixed Config (HPA cannot be re-used) + +INTRA-host-bridge interleave (multiple devices on one host bridge) is NOT +reported in this structure, and is solely defined via CXL device decoder +programming (host bridge and endpoint decoders). diff --git a/Documentation/driver-api/cxl/platform/acpi/dsdt.rst b/Documentation/driver-api/cxl/platform/acpi/dsdt.rst new file mode 100644 index 000000000000..b4583b01d67d --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi/dsdt.rst @@ -0,0 +1,28 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================== +DSDT - Differentiated system Description Table +============================================== + +This table describes what peripherals a machine has. + +This table's UIDs for CXL devices - specifically host bridges, must be +consistent with the contents of the CEDT, otherwise the CXL driver will +fail to probe correctly. + +Example Compute Express Link Host Bridge :: + + Scope (_SB) + { + Device (S0D0) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + Name (_CID, Package (0x02) // _CID: Compatible ID + { + EisaId ("PNP0A08") /* PCI Express Bus */, + EisaId ("PNP0A03") /* PCI Bus */ + }) + ... + Name (_UID, 0x05) // _UID: Unique ID + ... + } diff --git a/Documentation/driver-api/cxl/platform/acpi/hmat.rst b/Documentation/driver-api/cxl/platform/acpi/hmat.rst new file mode 100644 index 000000000000..095a26f02a37 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi/hmat.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================================== +HMAT - Heterogeneous Memory Attribute Table +=========================================== + +The Heterogeneous Memory Attributes Table contains information such as cache +attributes and bandwidth and latency details for memory proximity domains. +For the purpose of this document, we will only discuss the SSLIB entry. + +SLLBI +===== +The System Locality Latency and Bandwidth Information records latency and +bandwidth information for proximity domains. + +This table is used by Linux to configure interleave weights and memory tiers. + +Example (Heavily truncated for brevity) :: + + Structure Type : 0001 [SLLBI] + Data Type : 00 <- Latency + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Entry : 0080 <- DRAM LTC + Entry : 0100 <- CXL LTC + + Structure Type : 0001 [SLLBI] + Data Type : 03 <- Bandwidth + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Entry : 1200 <- DRAM BW + Entry : 0200 <- CXL BW diff --git a/Documentation/driver-api/cxl/platform/acpi/slit.rst b/Documentation/driver-api/cxl/platform/acpi/slit.rst new file mode 100644 index 000000000000..a56768e8fe41 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi/slit.rst @@ -0,0 +1,21 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================== +SLIT - System Locality Information Table +======================================== + +The system locality information table provides "abstract distances" between +accessor and memory nodes. Node without initiators (cpus) are infinitely (FF) +distance away from all other nodes. + +The abstract distance described in this table does not describe any real +latency of bandwidth information. + +Example :: + + Signature : "SLIT" [System Locality Information Table] + Localities : 0000000000000004 + Locality 0 : 10 20 20 30 + Locality 1 : 20 10 30 20 + Locality 2 : FF FF 0A FF + Locality 3 : FF FF FF 0A diff --git a/Documentation/driver-api/cxl/platform/acpi/srat.rst b/Documentation/driver-api/cxl/platform/acpi/srat.rst new file mode 100644 index 000000000000..cc98ca0e508e --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi/srat.rst @@ -0,0 +1,71 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================== +SRAT - Static Resource Affinity Table +===================================== + +The System/Static Resource Affinity Table describes resource (CPU, Memory) +affinity to "Proximity Domains". This table is technically optional, but for +performance information (see "HMAT") to be enumerated by linux it must be +present. + +There is a careful dance between the CEDT and SRAT tables and how NUMA nodes are +created. If things don't look quite the way you expect - check the SRAT Memory +Affinity entries and CEDT CFMWS to determine what your platform actually +supports in terms of flexible topologies. + +The SRAT may statically assign portions of a CFMWS SPA range to a specific +proximity domains. See linux numa creation for more information about how +this presents in the NUMA topology. + +Proximity Domain +================ +A proximity domain is ROUGHLY equivalent to "NUMA Node" - though a 1-to-1 +mapping is not guaranteed. There are scenarios where "Proximity Domain 4" may +map to "NUMA Node 3", for example. (See "NUMA Node Creation") + +Memory Affinity +=============== +Generally speaking, if a host does any amount of CXL fabric (decoder) +programming in BIOS - an SRAT entry for that memory needs to be present. + +Example :: + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000001 <- NUMA Node 1 + Reserved1 : 0000 + Base Address : 000000C050000000 <- Physical Memory Region + Address Length : 0000003CA0000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + +Generic Port Affinity +===================== +The Generic Port Affinity subtable provides an association between a proximity +domain and a device handle representing a Generic Port such as a CXL host +bridge. With the association, latency and bandwidth numbers can be retrieved +from the SRAT for the path between CPU(s) (initiator) and the Generic Port. +This is used to construct performance coordinates for hotplugged CXL DEVICES, +which cannot be enumerated at boot by platform firmware. + +Example :: + + Subtable Type : 06 [Generic Port Affinity] + Length : 20 <- 32d, length of table + Reserved : 00 + Device Handle Type : 00 <- 0 - ACPI, 1 - PCI + Proximity Domain : 00000001 + Device Handle : ACPI0016:01 + Flags : 00000001 <- Bit 0 (Enabled) + Reserved : 00000000 + +The Proximity Domain is matched up to the :doc:`HMAT <hmat>` SSLBI Target +Proximity Domain List for the related latency or bandwidth numbers. Those +performance numbers are tied to a CXL host bridge via the Device Handle. +The driver uses the association to retrieve the Generic Port performance +numbers for the whole CXL path access coordinates calculation. diff --git a/Documentation/driver-api/cxl/platform/bios-and-efi.rst b/Documentation/driver-api/cxl/platform/bios-and-efi.rst new file mode 100644 index 000000000000..645322632cc9 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/bios-and-efi.rst @@ -0,0 +1,262 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================== +BIOS/EFI Configuration +====================== + +BIOS and EFI are largely responsible for configuring static information about +devices (or potential future devices) such that Linux can build the appropriate +logical representations of these devices. + +At a high level, this is what occurs during this phase of configuration. + +* The bootloader starts the BIOS/EFI. + +* BIOS/EFI do early device probe to determine static configuration + +* BIOS/EFI creates ACPI Tables that describe static config for the OS + +* BIOS/EFI create the system memory map (EFI Memory Map, E820, etc) + +* BIOS/EFI calls :code:`start_kernel` and begins the Linux Early Boot process. + +Much of what this section is concerned with is ACPI Table production and +static memory map configuration. More detail on these tables can be found +at :doc:`ACPI Tables <acpi>`. + +.. note:: + Platform Vendors should read carefully, as this sections has recommendations + on physical memory region size and alignment, memory holes, HDM interleave, + and what linux expects of HDM decoders trying to work with these features. + +UEFI Settings +============= +If your platform supports it, the :code:`uefisettings` command can be used to +read/write EFI settings. Changes will be reflected on the next reboot. Kexec +is not a sufficient reboot. + +One notable configuration here is the EFI_MEMORY_SP (Specific Purpose) bit. +When this is enabled, this bit tells linux to defer management of a memory +region to a driver (in this case, the CXL driver). Otherwise, the memory is +treated as "normal memory", and is exposed to the page allocator during +:code:`__init`. + +uefisettings examples +--------------------- + +:code:`uefisettings identify` :: + + uefisettings identify + + bios_vendor: xxx + bios_version: xxx + bios_release: xxx + bios_date: xxx + product_name: xxx + product_family: xxx + product_version: xxx + +On some AMD platforms, the :code:`EFI_MEMORY_SP` bit is set via the :code:`CXL +Memory Attribute` field. This may be called something else on your platform. + +:code:`uefisettings get "CXL Memory Attribute"` :: + + selector: xxx + ... + question: Question { + name: "CXL Memory Attribute", + answer: "Enabled", + ... + } + +Physical Memory Map +=================== + +Physical Address Region Alignment +--------------------------------- + +As of Linux v6.14, the hotplug memory system requires memory regions to be +uniform in size and alignment. While the CXL specification allows for memory +regions as small as 256MB, the supported memory block size and alignment for +hotplugged memory is architecture-defined. + +A Linux memory blocks may be as small as 128MB and increase in powers of two. + +* On ARM, the default block size and alignment is either 128MB or 256MB. + +* On x86, the default block size is 256MB, and increases to 2GB as the + capacity of the system increases up to 64GB. + +For best support across versions, platform vendors should place CXL memory at +a 2GB aligned base address, and regions should be 2GB aligned. This also helps +prevent the creating thousands of memory devices (one per block). + +Memory Holes +------------ + +Holes in the memory map are tricky. Consider a 4GB device located at base +address 0x100000000, but with the following memory map :: + + --------------------- + | 0x100000000 | + | CXL | + | 0x1BFFFFFFF | + --------------------- + | 0x1C0000000 | + | MEMORY HOLE | + | 0x1FFFFFFFF | + --------------------- + | 0x200000000 | + | CXL CONT. | + | 0x23FFFFFFF | + --------------------- + +There are two issues to consider: + +* decoder programming, and +* memory block alignment. + +If your architecture requires 2GB uniform size and aligned memory blocks, the +only capacity Linux is capable of mapping (as of v6.14) would be the capacity +from `0x100000000-0x180000000`. The remaining capacity will be stranded, as +they are not of 2GB aligned length. + +Assuming your architecture and memory configuration allows 1GB memory blocks, +this memory map is supported and this should be presented as multiple CFMWS +in the CEDT that describe each side of the memory hole separately - along with +matching decoders. + +Multiple decoders can (and should) be used to manage such a memory hole (see +below), but each chunk of a memory hole should be aligned to a reasonable block +size (larger alignment is always better). If you intend to have memory holes +in the memory map, expect to use one decoder per contiguous chunk of host +physical memory. + +As of v6.14, Linux does provide support for memory hotplug of multiple +physical memory regions separated by a memory hole described by a single +HDM decoder. + + +Decoder Programming +=================== +If BIOS/EFI intends to program the decoders to be statically configured, +there are a few things to consider to avoid major pitfalls that will +prevent Linux compatibility. Some of these recommendations are not +required "per the specification", but Linux makes no guarantees of support +otherwise. + + +Translation Point +----------------- +Per the specification, the only decoders which **TRANSLATE** Host Physical +Address (HPA) to Device Physical Address (DPA) are the **Endpoint Decoders**. +All other decoders in the fabric are intended to route accesses without +translating the addresses. + +This is heavily implied by the specification, see: :: + + CXL Specification 3.1 + 8.2.4.20: CXL HDM Decoder Capability Structure + - Implementation Note: CXL Host Bridge and Upstream Switch Port Decoder Flow + - Implementation Note: Device Decoder Logic + +Given this, Linux makes a strong assumption that decoders between CPU and +endpoint will all be programmed with addresses ranges that are subsets of +their parent decoder. + +Due to some ambiguity in how Architecture, ACPI, PCI, and CXL specifications +"hand off" responsibility between domains, some early adopting platforms +attempted to do translation at the originating memory controller or host +bridge. This configuration requires a platform specific extension to the +driver and is not officially endorsed - despite being supported. + +It is *highly recommended* **NOT** to do this; otherwise, you are on your own +to implement driver support for your platform. + +Interleave and Configuration Flexibility +---------------------------------------- +If providing cross-host-bridge interleave, a CFMWS entry in the :doc:`CEDT +<acpi/cedt>` must be presented with target host-bridges for the interleaved +device sets (there may be multiple behind each host bridge). + +If providing intra-host-bridge interleaving, only 1 CFMWS entry in the CEDT is +required for that host bridge - if it covers the entire capacity of the devices +behind the host bridge. + +If intending to provide users flexibility in programming decoders beyond the +root, you may want to provide multiple CFMWS entries in the CEDT intended for +different purposes. For example, you may want to consider adding: + +1) A CFMWS entry to cover all interleavable host bridges. +2) A CFMWS entry to cover all devices on a single host bridge. +3) A CFMWS entry to cover each device. + +A platform may choose to add all of these, or change the mode based on a BIOS +setting. For each CFMWS entry, Linux expects descriptions of the described +memory regions in the :doc:`SRAT <acpi/srat>` to determine the number of +NUMA nodes it should reserve during early boot / init. + +As of v6.14, Linux will create a NUMA node for each CEDT CFMWS entry, even if +a matching SRAT entry does not exist; however, this is not guaranteed in the +future and such a configuration should be avoided. + +Memory Holes +------------ +If your platform includes memory holes intersparsed between your CXL memory, it +is recommended to utilize multiple decoders to cover these regions of memory, +rather than try to program the decoders to accept the entire range and expect +Linux to manage the overlap. + +For example, consider the Memory Hole described above :: + + --------------------- + | 0x100000000 | + | CXL | + | 0x1BFFFFFFF | + --------------------- + | 0x1C0000000 | + | MEMORY HOLE | + | 0x1FFFFFFFF | + --------------------- + | 0x200000000 | + | CXL CONT. | + | 0x23FFFFFFF | + --------------------- + +Assuming this is provided by a single device attached directly to a host bridge, +Linux would expect the following decoder programming :: + + ----------------------- ----------------------- + | root-decoder-0 | | root-decoder-1 | + | base: 0x100000000 | | base: 0x200000000 | + | size: 0xC0000000 | | size: 0x40000000 | + ----------------------- ----------------------- + | | + ----------------------- ----------------------- + | HB-decoder-0 | | HB-decoder-1 | + | base: 0x100000000 | | base: 0x200000000 | + | size: 0xC0000000 | | size: 0x40000000 | + ----------------------- ----------------------- + | | + ----------------------- ----------------------- + | ep-decoder-0 | | ep-decoder-1 | + | base: 0x100000000 | | base: 0x200000000 | + | size: 0xC0000000 | | size: 0x40000000 | + ----------------------- ----------------------- + +With a CEDT configuration with two CFMWS describing the above root decoders. + +Linux makes no guarantee of support for strange memory hole situations. + +Multi-Media Devices +------------------- +The CFMWS field of the CEDT has special restriction bits which describe whether +the described memory region allows volatile or persistent memory (or both). If +the platform intends to support either: + +1) A device with multiple medias, or +2) Using a persistent memory device as normal memory + +A platform may wish to create multiple CEDT CFMWS entries to describe the same +memory, with the intent of allowing the end user flexibility in how that memory +is configured. Linux does not presently have strong requirements in this area. diff --git a/Documentation/driver-api/cxl/platform/cdat.rst b/Documentation/driver-api/cxl/platform/cdat.rst new file mode 100644 index 000000000000..34bbe7264d71 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/cdat.rst @@ -0,0 +1,118 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +Coherent Device Attribute Table (CDAT) +====================================== + +The CDAT provides functional and performance attributes of devices such +as CXL accelerators, switches, or endpoints. The table formatting is +similar to ACPI tables. CDAT data may be parsed by BIOS at boot or may +be enumerated at runtime (after device hotplug, for example). + +Terminology: +DPA - Device Physical Address, used by the CXL device to denote the address +it supports for that device. + +DSMADHandle - A device unique handle that is associated with a DPA range +defined by the DSMAS table. + + +=============================================== +Device Scoped Memory Affinity Structure (DSMAS) +=============================================== + +The DSMAS contains information such as DSMADHandle, the DPA Base, and DPA +Length. + +This table is used by Linux in conjunction with the Device Scoped Latency and +Bandwidth Information Structure (DSLBIS) to determine the performance +attributes of the CXL device itself. + +Example :: + + Structure Type : 00 [DSMAS] + Reserved : 00 + Length : 0018 <- 24d, size of structure + DSMADHandle : 01 + Flags : 00 + Reserved : 0000 + DPA Base : 0000000040000000 <- 1GiB base + DPA Length : 0000000080000000 <- 2GiB size + + +================================================================== +Device Scoped Latency and Bandwidth Information Structure (DSLBIS) +================================================================== + +This table is used by Linux in conjunction with DSMAS to determine the +performance attributes of a CXL device. The DSLBIS contains latency +and bandwidth information based on DSMADHandle matching. + +Example :: + + Structure Type : 01 [DSLBIS] + Reserved : 00 + Length : 18 <- 24d, size of structure + Handle : 0001 <- DSMAS handle + Flags : 00 <- Matches flag field for HMAT SLLBIS + Data Type : 00 <- Latency + Entry Basee Unit : 0000000000001000 <- Entry Base Unit field in HMAT SSLBIS + Entry : 010000000000 <- First byte used here, CXL LTC + Reserved : 0000 + + Structure Type : 01 [DSLBIS] + Reserved : 00 + Length : 18 <- 24d, size of structure + Handle : 0001 <- DSMAS handle + Flags : 00 <- Matches flag field for HMAT SLLBIS + Data Type : 03 <- Bandwidth + Entry Basee Unit : 0000000000001000 <- Entry Base Unit field in HMAT SSLBIS + Entry : 020000000000 <- First byte used here, CXL BW + Reserved : 0000 + + +================================================================== +Switch Scoped Latency and Bandwidth Information Structure (SSLBIS) +================================================================== + +The SSLBIS contains information about the latency and bandwidth of a switch. + +The table is used by Linux to compute the performance coordinates of a CXL path +from the device to the root port where a switch is part of the path. + +Example :: + + Structure Type : 05 [SSLBIS] + Reserved : 00 + Length : 20 <- 32d, length of record, including SSLB entries + Data Type : 00 <- Latency + Reserved : 000000 + Entry Base Unit : 00000000000000001000 <- Matches Entry Base Unit in HMAT SSLBIS + + <- SSLB Entry 0 + Port X ID : 0100 <- First port, 0100h represents an upstream port + Port Y ID : 0000 <- Second port, downstream port 0 + Latency : 0100 <- Port latency + Reserved : 0000 + <- SSLB Entry 1 + Port X ID : 0100 + Port Y ID : 0001 + Latency : 0100 + Reserved : 0000 + + + Structure Type : 05 [SSLBIS] + Reserved : 00 + Length : 18 <- 24d, length of record, including SSLB entry + Data Type : 03 <- Bandwidth + Reserved : 000000 + Entry Base Unit : 00000000000000001000 <- Matches Entry Base Unit in HMAT SSLBIS + + <- SSLB Entry 0 + Port X ID : 0100 <- First port, 0100h represents an upstream port + Port Y ID : FFFF <- Second port, FFFFh indicates any port + Bandwidth : 1200 <- Port bandwidth + Reserved : 0000 + +The CXL driver uses a combination of CDAT, HMAT, SRAT, and other data to +generate "whole path performance" data for a CXL device. diff --git a/Documentation/driver-api/cxl/platform/example-configs.rst b/Documentation/driver-api/cxl/platform/example-configs.rst new file mode 100644 index 000000000000..90a10d7473c6 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/example-configs.rst @@ -0,0 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Example Platform Configurations +############################### + +.. toctree:: + :maxdepth: 1 + :caption: Contents + + example-configurations/one-dev-per-hb.rst + example-configurations/multi-dev-per-hb.rst + example-configurations/hb-interleave.rst + example-configurations/flexible.rst diff --git a/Documentation/driver-api/cxl/platform/example-configurations/flexible.rst b/Documentation/driver-api/cxl/platform/example-configurations/flexible.rst new file mode 100644 index 000000000000..dab704b6fcc2 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/example-configurations/flexible.rst @@ -0,0 +1,296 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +Flexible Presentation +===================== +This system has a single socket with two CXL host bridges. Each host bridge +has two CXL memory expanders with a 4GB of memory (32GB total). + +On this system, the platform designer wanted to provide the user flexibility +to configure the memory devices in various interleave or NUMA node +configurations. So they provided every combination. + +Things to note: + +* Cross-Bridge interleave is described in one CFMWS that covers all capacity. +* One CFMWS is also described per-host bridge. +* One CFMWS is also described per-device. +* This SRAT describes one node for each of the above CFMWS. +* The HMAT describes performance for each node in the SRAT. + +:doc:`CEDT <../acpi/cedt>`:: + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000007 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010370400000 + Register length : 0000000000010000 + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000006 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010380800000 + Register length : 0000000000010000 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000001000000000 + Window size : 0000000400000000 + Interleave Members (2^n) : 01 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + Second Target : 00000006 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000002000000000 + Window size : 0000000200000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000002200000000 + Window size : 0000000200000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000006 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000003000000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000003100000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000003200000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000006 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000003300000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000006 + +:doc:`SRAT <../acpi/srat>`:: + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000001 + Reserved1 : 0000 + Base Address : 0000001000000000 + Address Length : 0000000400000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000002 + Reserved1 : 0000 + Base Address : 0000002000000000 + Address Length : 0000000200000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000003 + Reserved1 : 0000 + Base Address : 0000002200000000 + Address Length : 0000000200000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000004 + Reserved1 : 0000 + Base Address : 0000003000000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000005 + Reserved1 : 0000 + Base Address : 0000003100000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000006 + Reserved1 : 0000 + Base Address : 0000003200000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000007 + Reserved1 : 0000 + Base Address : 0000003300000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + +:doc:`HMAT <../acpi/hmat>`:: + + Structure Type : 0001 [SLLBI] + Data Type : 00 [Latency] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Target Proximity Domain List : 00000003 + Target Proximity Domain List : 00000004 + Target Proximity Domain List : 00000005 + Target Proximity Domain List : 00000006 + Target Proximity Domain List : 00000007 + Entry : 0080 + Entry : 0100 + Entry : 0100 + Entry : 0100 + Entry : 0100 + Entry : 0100 + Entry : 0100 + Entry : 0100 + + Structure Type : 0001 [SLLBI] + Data Type : 03 [Bandwidth] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Target Proximity Domain List : 00000003 + Target Proximity Domain List : 00000004 + Target Proximity Domain List : 00000005 + Target Proximity Domain List : 00000006 + Target Proximity Domain List : 00000007 + Entry : 1200 + Entry : 0400 + Entry : 0200 + Entry : 0200 + Entry : 0100 + Entry : 0100 + Entry : 0100 + Entry : 0100 + +:doc:`SLIT <../acpi/slit>`:: + + Signature : "SLIT" [System Locality Information Table] + Localities : 0000000000000003 + Locality 0 : 10 20 20 20 20 20 20 20 + Locality 1 : FF 0A FF FF FF FF FF FF + Locality 2 : FF FF 0A FF FF FF FF FF + Locality 3 : FF FF FF 0A FF FF FF FF + Locality 4 : FF FF FF FF 0A FF FF FF + Locality 5 : FF FF FF FF FF 0A FF FF + Locality 6 : FF FF FF FF FF FF 0A FF + Locality 7 : FF FF FF FF FF FF FF 0A + +:doc:`DSDT <../acpi/dsdt>`:: + + Scope (_SB) + { + Device (S0D0) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x07) // _UID: Unique ID + } + ... + Device (S0D5) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x06) // _UID: Unique ID + } + } diff --git a/Documentation/driver-api/cxl/platform/example-configurations/hb-interleave.rst b/Documentation/driver-api/cxl/platform/example-configurations/hb-interleave.rst new file mode 100644 index 000000000000..c474dcf09fb0 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/example-configurations/hb-interleave.rst @@ -0,0 +1,107 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Cross-Host-Bridge Interleave +============================ +This system has a single socket with two CXL host bridges. Each host bridge +has a single CXL memory expander with a 4GB of memory. + +Things to note: + +* Cross-Bridge interleave is described. +* The expanders are described by a single CFMWS. +* This SRAT describes one node for both host bridges. +* The HMAT describes a single node's performance. + +:doc:`CEDT <../acpi/cedt>`:: + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000007 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010370400000 + Register length : 0000000000010000 + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000006 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010380800000 + Register length : 0000000000010000 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000001000000000 + Window size : 0000000200000000 + Interleave Members (2^n) : 01 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + Second Target : 00000006 + +:doc:`SRAT <../acpi/srat>`:: + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000001 + Reserved1 : 0000 + Base Address : 0000001000000000 + Address Length : 0000000200000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + +:doc:`HMAT <../acpi/hmat>`:: + + Structure Type : 0001 [SLLBI] + Data Type : 00 [Latency] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Entry : 0080 + Entry : 0100 + + Structure Type : 0001 [SLLBI] + Data Type : 03 [Bandwidth] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Entry : 1200 + Entry : 0400 + +:doc:`SLIT <../acpi/slit>`:: + + Signature : "SLIT" [System Locality Information Table] + Localities : 0000000000000003 + Locality 0 : 10 20 + Locality 1 : FF 0A + +:doc:`DSDT <../acpi/dsdt>`:: + + Scope (_SB) + { + Device (S0D0) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x07) // _UID: Unique ID + } + ... + Device (S0D5) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x06) // _UID: Unique ID + } + } diff --git a/Documentation/driver-api/cxl/platform/example-configurations/multi-dev-per-hb.rst b/Documentation/driver-api/cxl/platform/example-configurations/multi-dev-per-hb.rst new file mode 100644 index 000000000000..a7854a79dbbd --- /dev/null +++ b/Documentation/driver-api/cxl/platform/example-configurations/multi-dev-per-hb.rst @@ -0,0 +1,90 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================ +Multiple Devices per Host Bridge +================================ + +In this example system we will have a single socket and one CXL host bridge. +There are two CXL memory expanders with 4GB attached to the host bridge. + +Things to note: + +* Intra-Bridge interleave is not described here. +* The expanders are described by a single CEDT/CFMWS. +* This CEDT/SRAT describes one node for both devices. +* There is only one proximity domain the HMAT for both devices. + +:doc:`CEDT <../acpi/cedt>`:: + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000007 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010370400000 + Register length : 0000000000010000 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000001000000000 + Window size : 0000000200000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + +:doc:`SRAT <../acpi/srat>`:: + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000001 + Reserved1 : 0000 + Base Address : 0000001000000000 + Address Length : 0000000200000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + +:doc:`HMAT <../acpi/hmat>`:: + + Structure Type : 0001 [SLLBI] + Data Type : 00 [Latency] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Entry : 0080 + Entry : 0100 + + Structure Type : 0001 [SLLBI] + Data Type : 03 [Bandwidth] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Entry : 1200 + Entry : 0200 + +:doc:`SLIT <../acpi/slit>`:: + + Signature : "SLIT" [System Locality Information Table] + Localities : 0000000000000003 + Locality 0 : 10 20 + Locality 1 : FF 0A + +:doc:`DSDT <../acpi/dsdt>`:: + + Scope (_SB) + { + Device (S0D0) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x07) // _UID: Unique ID + } + ... + } diff --git a/Documentation/driver-api/cxl/platform/example-configurations/one-dev-per-hb.rst b/Documentation/driver-api/cxl/platform/example-configurations/one-dev-per-hb.rst new file mode 100644 index 000000000000..aebda0eb3e17 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/example-configurations/one-dev-per-hb.rst @@ -0,0 +1,136 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +One Device per Host Bridge +========================== + +This system has a single socket with two CXL host bridges. Each host bridge +has a single CXL memory expander with a 4GB of memory. + +Things to note: + +* Cross-Bridge interleave is not being used. +* The expanders are in two separate but adjascent memory regions. +* This CEDT/SRAT describes one node per device +* The expanders have the same performance and will be in the same memory tier. + +:doc:`CEDT <../acpi/cedt>`:: + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000007 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010370400000 + Register length : 0000000000010000 + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000006 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010380800000 + Register length : 0000000000010000 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000001000000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000001100000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000006 + +:doc:`SRAT <../acpi/srat>`:: + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000001 + Reserved1 : 0000 + Base Address : 0000001000000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000002 + Reserved1 : 0000 + Base Address : 0000001100000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + +:doc:`HMAT <../acpi/hmat>`:: + + Structure Type : 0001 [SLLBI] + Data Type : 00 [Latency] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Entry : 0080 + Entry : 0100 + Entry : 0100 + + Structure Type : 0001 [SLLBI] + Data Type : 03 [Bandwidth] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Entry : 1200 + Entry : 0200 + Entry : 0200 + +:doc:`SLIT <../acpi/slit>`:: + + Signature : "SLIT" [System Locality Information Table] + Localities : 0000000000000003 + Locality 0 : 10 20 20 + Locality 1 : FF 0A FF + Locality 2 : FF FF 0A + +:doc:`DSDT <../acpi/dsdt>`:: + + Scope (_SB) + { + Device (S0D0) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x07) // _UID: Unique ID + } + ... + Device (S0D5) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x06) // _UID: Unique ID + } + } diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/theory-of-operation.rst index d732c42526df..40793dad3630 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/theory-of-operation.rst @@ -1,9 +1,9 @@ .. SPDX-License-Identifier: GPL-2.0 .. include:: <isonum.txt> -=================================== -Compute Express Link Memory Devices -=================================== +=============================================== +Compute Express Link Driver Theory of Operation +=============================================== A Compute Express Link Memory Device is a CXL component that implements the CXL.mem protocol. It contains some amount of volatile memory, persistent memory, @@ -14,8 +14,8 @@ that optionally define a device's contribution to an interleaved address range across multiple devices underneath a host-bridge or interleaved across host-bridges. -CXL Bus: Theory of Operation -============================ +The CXL Bus +=========== Similar to how a RAID driver takes disk objects and assembles them into a new logical device, the CXL subsystem is tasked to take PCIe and ACPI objects and assemble them into a CXL.mem decode topology. The need for runtime configuration @@ -347,6 +347,9 @@ CXL Core .. kernel-doc:: drivers/cxl/cxl.h :internal: +.. kernel-doc:: drivers/cxl/acpi.c + :identifiers: add_cxl_resources + .. kernel-doc:: drivers/cxl/core/hdm.c :doc: cxl core hdm @@ -371,12 +374,26 @@ CXL Core .. kernel-doc:: drivers/cxl/core/pmem.c :doc: cxl pmem +.. kernel-doc:: drivers/cxl/core/pmem.c + :identifiers: + .. kernel-doc:: drivers/cxl/core/regs.c :doc: cxl registers +.. kernel-doc:: drivers/cxl/core/regs.c + :identifiers: + .. kernel-doc:: drivers/cxl/core/mbox.c :doc: cxl mbox +.. kernel-doc:: drivers/cxl/core/mbox.c + :identifiers: + +.. kernel-doc:: drivers/cxl/core/features.c + :doc: cxl features + +See :c:func:`devm_cxl_setup_features` for API details. + CXL Regions ----------- .. kernel-doc:: drivers/cxl/core/region.c diff --git a/Documentation/edac/memory_repair.rst b/Documentation/edac/memory_repair.rst index 52162a422864..5f8da7c9b186 100644 --- a/Documentation/edac/memory_repair.rst +++ b/Documentation/edac/memory_repair.rst @@ -119,3 +119,34 @@ sysfs Sysfs files are documented in `Documentation/ABI/testing/sysfs-edac-memory-repair`. + +Examples +-------- + +The memory repair usage takes the form shown in this example: + +1. CXL memory sparing + +Memory sparing is defined as a repair function that replaces a portion of +memory with a portion of functional memory at that same DPA. The subclass +for this operation, cacheline/row/bank/rank sparing, vary in terms of the +scope of the sparing being performed. + +Memory sparing maintenance operations may be supported by CXL devices that +implement CXL.mem protocol. A sparing maintenance operation requests the +CXL device to perform a repair operation on its media. For example, a CXL +device with DRAM components that support memory sparing features may +implement sparing maintenance operations. + +2. CXL memory Soft Post Package Repair (sPPR) + +Post Package Repair (PPR) maintenance operations may be supported by CXL +devices that implement CXL.mem protocol. A PPR maintenance operation +requests the CXL device to perform a repair operation on its media. +For example, a CXL device with DRAM components that support PPR features +may implement PPR Maintenance operations. Soft PPR (sPPR) is a temporary +row repair. Soft PPR may be faster, but the repair is lost with a power +cycle. + +Sysfs files for memory repair are documented in +`Documentation/ABI/testing/sysfs-edac-memory-repair` diff --git a/Documentation/edac/scrub.rst b/Documentation/edac/scrub.rst index daab929cdba1..2cfa74fa1ffd 100644 --- a/Documentation/edac/scrub.rst +++ b/Documentation/edac/scrub.rst @@ -264,3 +264,79 @@ Sysfs files are documented in `Documentation/ABI/testing/sysfs-edac-scrub` `Documentation/ABI/testing/sysfs-edac-ecs` + +Examples +-------- + +The usage takes the form shown in these examples: + +1. CXL memory Patrol Scrub + +The following are the use cases identified why we might increase the scrub rate. + +- Scrubbing is needed at device granularity because a device is showing + unexpectedly high errors. + +- Scrubbing may apply to memory that isn't online at all yet. Likely this + is a system wide default setting on boot. + +- Scrubbing at a higher rate because the monitor software has determined that + more reliability is necessary for a particular data set. This is called + Differentiated Reliability. + +1.1. Device based scrubbing + +CXL memory is exposed to memory management subsystem and ultimately userspace +via CXL devices. Device-based scrubbing is used for the first use case +described in "Section 1 CXL Memory Patrol Scrub". + +When combining control via the device interfaces and region interfaces, +"see Section 1.2 Region based scrubbing". + +Sysfs files for scrubbing are documented in +`Documentation/ABI/testing/sysfs-edac-scrub` + +1.2. Region based scrubbing + +CXL memory is exposed to memory management subsystem and ultimately userspace +via CXL regions. CXL Regions represent mapped memory capacity in system +physical address space. These can incorporate one or more parts of multiple CXL +memory devices with traffic interleaved across them. The user may want to control +the scrub rate via this more abstract region instead of having to figure out the +constituent devices and program them separately. The scrub rate for each device +covers the whole device. Thus if multiple regions use parts of that device then +requests for scrubbing of other regions may result in a higher scrub rate than +requested for this specific region. + +Region-based scrubbing is used for the third use case described in +"Section 1 CXL Memory Patrol Scrub". + +Userspace must follow below set of rules on how to set the scrub rates for any +mixture of requirements. + +1. Taking each region in turn from lowest desired scrub rate to highest and set + their scrub rates. Later regions may override the scrub rate on individual + devices (and hence potentially whole regions). + +2. Take each device for which enhanced scrubbing is required (higher rate) and + set those scrub rates. This will override the scrub rates of individual devices, + setting them to the maximum rate required for any of the regions they help back, + unless a specific rate is already defined. + +Sysfs files for scrubbing are documented in +`Documentation/ABI/testing/sysfs-edac-scrub` + +2. CXL memory Error Check Scrub (ECS) + +The Error Check Scrub (ECS) feature enables a memory device to perform error +checking and correction (ECC) and count single-bit errors. The associated +memory controller sets the ECS mode with a trigger sent to the memory +device. CXL ECS control allows the host, thus the userspace, to change the +attributes for error count mode, threshold number of errors per segment +(indicating how many segments have at least that number of errors) for +reporting errors, and reset the ECS counter. Thus the responsibility for +initiating Error Check Scrub on a memory device may lie with the memory +controller or platform when unexpectedly high error rates are detected. + +Sysfs files for scrubbing are documented in +`Documentation/ABI/testing/sysfs-edac-ecs` diff --git a/Documentation/fb/sstfb.rst b/Documentation/fb/sstfb.rst index 88d5a52b13d8..7386eb63bac8 100644 --- a/Documentation/fb/sstfb.rst +++ b/Documentation/fb/sstfb.rst @@ -192,7 +192,7 @@ Todo - Get rid of the previous paragraph. - Buy more coffee. - test/port to other arch. -- try to add panning using tweeks with front and back buffer . +- try to add panning using tweaks with front and back buffer. - try to implement accel on voodoo2, this board can actually do a lot in 2D even if it was sold as a 3D only board ... diff --git a/Documentation/filesystems/fuse-passthrough.rst b/Documentation/filesystems/fuse-passthrough.rst new file mode 100644 index 000000000000..2b0e7c2da54a --- /dev/null +++ b/Documentation/filesystems/fuse-passthrough.rst @@ -0,0 +1,133 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================ +FUSE Passthrough +================ + +Introduction +============ + +FUSE (Filesystem in Userspace) passthrough is a feature designed to improve the +performance of FUSE filesystems for I/O operations. Typically, FUSE operations +involve communication between the kernel and a userspace FUSE daemon, which can +incur overhead. Passthrough allows certain operations on a FUSE file to bypass +the userspace daemon and be executed directly by the kernel on an underlying +"backing file". + +This is achieved by the FUSE daemon registering a file descriptor (pointing to +the backing file on a lower filesystem) with the FUSE kernel module. The kernel +then receives an identifier (``backing_id``) for this registered backing file. +When a FUSE file is subsequently opened, the FUSE daemon can, in its response to +the ``OPEN`` request, include this ``backing_id`` and set the +``FOPEN_PASSTHROUGH`` flag. This establishes a direct link for specific +operations. + +Currently, passthrough is supported for operations like ``read(2)``/``write(2)`` +(via ``read_iter``/``write_iter``), ``splice(2)``, and ``mmap(2)``. + +Enabling Passthrough +==================== + +To use FUSE passthrough: + + 1. The FUSE filesystem must be compiled with ``CONFIG_FUSE_PASSTHROUGH`` + enabled. + 2. The FUSE daemon, during the ``FUSE_INIT`` handshake, must negotiate the + ``FUSE_PASSTHROUGH`` capability and specify its desired + ``max_stack_depth``. + 3. The (privileged) FUSE daemon uses the ``FUSE_DEV_IOC_BACKING_OPEN`` ioctl + on its connection file descriptor (e.g., ``/dev/fuse``) to register a + backing file descriptor and obtain a ``backing_id``. + 4. When handling an ``OPEN`` or ``CREATE`` request for a FUSE file, the daemon + replies with the ``FOPEN_PASSTHROUGH`` flag set in + ``fuse_open_out::open_flags`` and provides the corresponding ``backing_id`` + in ``fuse_open_out::backing_id``. + 5. The FUSE daemon should eventually call ``FUSE_DEV_IOC_BACKING_CLOSE`` with + the ``backing_id`` to release the kernel's reference to the backing file + when it's no longer needed for passthrough setups. + +Privilege Requirements +====================== + +Setting up passthrough functionality currently requires the FUSE daemon to +possess the ``CAP_SYS_ADMIN`` capability. This requirement stems from several +security and resource management considerations that are actively being +discussed and worked on. The primary reasons for this restriction are detailed +below. + +Resource Accounting and Visibility +---------------------------------- + +The core mechanism for passthrough involves the FUSE daemon opening a file +descriptor to a backing file and registering it with the FUSE kernel module via +the ``FUSE_DEV_IOC_BACKING_OPEN`` ioctl. This ioctl returns a ``backing_id`` +associated with a kernel-internal ``struct fuse_backing`` object, which holds a +reference to the backing ``struct file``. + +A significant concern arises because the FUSE daemon can close its own file +descriptor to the backing file after registration. The kernel, however, will +still hold a reference to the ``struct file`` via the ``struct fuse_backing`` +object as long as it's associated with a ``backing_id`` (or subsequently, with +an open FUSE file in passthrough mode). + +This behavior leads to two main issues for unprivileged FUSE daemons: + + 1. **Invisibility to lsof and other inspection tools**: Once the FUSE + daemon closes its file descriptor, the open backing file held by the kernel + becomes "hidden." Standard tools like ``lsof``, which typically inspect + process file descriptor tables, would not be able to identify that this + file is still open by the system on behalf of the FUSE filesystem. This + makes it difficult for system administrators to track resource usage or + debug issues related to open files (e.g., preventing unmounts). + + 2. **Bypassing RLIMIT_NOFILE**: The FUSE daemon process is subject to + resource limits, including the maximum number of open file descriptors + (``RLIMIT_NOFILE``). If an unprivileged daemon could register backing files + and then close its own FDs, it could potentially cause the kernel to hold + an unlimited number of open ``struct file`` references without these being + accounted against the daemon's ``RLIMIT_NOFILE``. This could lead to a + denial-of-service (DoS) by exhausting system-wide file resources. + +The ``CAP_SYS_ADMIN`` requirement acts as a safeguard against these issues, +restricting this powerful capability to trusted processes. + +**NOTE**: ``io_uring`` solves this similar issue by exposing its "fixed files", +which are visible via ``fdinfo`` and accounted under the registering user's +``RLIMIT_NOFILE``. + +Filesystem Stacking and Shutdown Loops +-------------------------------------- + +Another concern relates to the potential for creating complex and problematic +filesystem stacking scenarios if unprivileged users could set up passthrough. +A FUSE passthrough filesystem might use a backing file that resides: + + * On the *same* FUSE filesystem. + * On another filesystem (like OverlayFS) which itself might have an upper or + lower layer that is a FUSE filesystem. + +These configurations could create dependency loops, particularly during +filesystem shutdown or unmount sequences, leading to deadlocks or system +instability. This is conceptually similar to the risks associated with the +``LOOP_SET_FD`` ioctl, which also requires ``CAP_SYS_ADMIN``. + +To mitigate this, FUSE passthrough already incorporates checks based on +filesystem stacking depth (``sb->s_stack_depth`` and ``fc->max_stack_depth``). +For example, during the ``FUSE_INIT`` handshake, the FUSE daemon can negotiate +the ``max_stack_depth`` it supports. When a backing file is registered via +``FUSE_DEV_IOC_BACKING_OPEN``, the kernel checks if the backing file's +filesystem stack depth is within the allowed limit. + +The ``CAP_SYS_ADMIN`` requirement provides an additional layer of security, +ensuring that only privileged users can create these potentially complex +stacking arrangements. + +General Security Posture +------------------------ + +As a general principle for new kernel features that allow userspace to instruct +the kernel to perform direct operations on its behalf based on user-provided +file descriptors, starting with a higher privilege requirement (like +``CAP_SYS_ADMIN``) is a conservative and common security practice. This allows +the feature to be used and tested while further security implications are +evaluated and addressed. diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index 32618512a965..11a599387266 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -99,6 +99,7 @@ Documentation for filesystem implementations. fuse fuse-io fuse-io-uring + fuse-passthrough inotify isofs nilfs2 diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 939b4b624fad..ddd799df6ce3 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -712,11 +712,6 @@ handle falling back from one source type to another. The members are: at a boundary with the filesystem structure (e.g. at the end of a Ceph object). It tells netfslib not to retile subrequests across it. - * ``NETFS_SREQ_SEEK_DATA_READ`` - - This is a hint from netfslib to the cache that it might want to try - skipping ahead to the next data (ie. using SEEK_DATA). - * ``error`` This is for the filesystem to store result of the subrequest. It should be diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index 3111ef5592f3..3616d7161dab 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -1243,3 +1243,9 @@ arguments in the opposite order but is otherwise identical. Using try_lookup_noperm() will require linux/namei.h to be included. +--- + +**mandatory** + +Calling conventions for ->d_automount() have changed; we should *not* grab +an extra reference to new mount - it should be returned with refcount 1. diff --git a/Documentation/filesystems/relay.rst b/Documentation/filesystems/relay.rst index 46447dbc75ad..301ff4c6e6c6 100644 --- a/Documentation/filesystems/relay.rst +++ b/Documentation/filesystems/relay.rst @@ -301,16 +301,6 @@ user-defined data with a channel, and is immediately available (including in create_buf_file()) via chan->private_data or buf->chan->private_data. -Buffer-only channels --------------------- - -These channels have no files associated and can be created with -relay_open(NULL, NULL, ...). Such channels are useful in scenarios such -as when doing early tracing in the kernel, before the VFS is up. In these -cases, one may open a buffer-only channel and then call -relay_late_setup_files() when the kernel is ready to handle files, -to expose the buffered data to the userspace. - Channel 'modes' --------------- diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index bf051c7da6b8..fd32a9a17bfb 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -1390,9 +1390,7 @@ defined: If a vfsmount is returned, the caller will attempt to mount it on the mountpoint and will remove the vfsmount from its - expiration list in the case of failure. The vfsmount should be - returned with 2 refs on it to prevent automatic expiration - the - caller will clean up the additional ref. + expiration list in the case of failure. This function is only used if DCACHE_NEED_AUTOMOUNT is set on the dentry. This is set by __d_instantiate() if S_AUTOMOUNT is diff --git a/Documentation/hwmon/acpi_power_meter.rst b/Documentation/hwmon/acpi_power_meter.rst index 8628c1161015..a91403a2a26f 100644 --- a/Documentation/hwmon/acpi_power_meter.rst +++ b/Documentation/hwmon/acpi_power_meter.rst @@ -37,9 +37,16 @@ arbitrary strings that ACPI provides with the meter. The measures/ directory contains symlinks to the devices that this meter measures. Some computers have the ability to enforce a power cap in hardware. If this is -the case, the `power[1-*]_cap` and related sysfs files will appear. When the -average power consumption exceeds the cap, an ACPI event will be broadcast on -the netlink event socket and a poll notification will be sent to the +the case, the `power[1-*]_cap` and related sysfs files will appear. +For information on enabling the power cap feature, refer to the description +of the "force_on_cap" option in the "Module Parameters" chapter. +To use the power cap feature properly, you need to set appropriate value +(in microWatts) to the `power[1-*]_cap` sysfs files. +The value must be within the range between the minimum value at `power[1-]_cap_min` +and the maximum value at `power[1-]_cap_max (both in microWatts)`. + +When the average power consumption exceeds the cap, an ACPI event will be +broadcast on the netlink event socket and a poll notification will be sent to the appropriate `power[1-*]_alarm` file to indicate that capping has begun, and the hardware has taken action to reduce power consumption. Most likely this will result in reduced performance. @@ -52,3 +59,19 @@ follows: `power[1-*]_cap` will be notified if the firmware changes the power cap. `power[1-*]_interval` will be notified if the firmware changes the averaging interval. + +Module Parameters +----------------- + +* force_cap_on: bool + Forcefully enable the power capping feature to specify + the upper limit of the system's power consumption. + + By default, the driver's power capping feature is only + enabled on IBM products. + Therefore, on other systems that support power capping, + you will need to use the option to enable it. + + Note: power capping is potentially unsafe feature. + Please check the platform specifications to make sure + that capping is supported before using this option. diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst index d2be9db29614..816d1f9947ea 100644 --- a/Documentation/hwmon/asus_ec_sensors.rst +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -4,6 +4,7 @@ Kernel driver asus_ec_sensors ================================= Supported boards: + * MAXIMUS VI HERO * PRIME X470-PRO * PRIME X570-PRO * PRIME X670E-PRO WIFI @@ -20,6 +21,7 @@ Supported boards: * ROG CROSSHAIR X670E GENE * ROG MAXIMUS XI HERO * ROG MAXIMUS XI HERO (WI-FI) + * ROG MAXIMUS Z690 FORMULA * ROG STRIX B550-E GAMING * ROG STRIX B550-I GAMING * ROG STRIX X570-E GAMING diff --git a/Documentation/hwmon/ina238.rst b/Documentation/hwmon/ina238.rst index d9f479984420..d1b93cf8627f 100644 --- a/Documentation/hwmon/ina238.rst +++ b/Documentation/hwmon/ina238.rst @@ -14,6 +14,12 @@ Supported chips: Datasheet: https://www.ti.com/lit/gpn/ina238 + * Silergy SQ52206 + + Prefix: 'SQ52206' + + Addresses: I2C 0x40 - 0x4f + Author: Nathan Rossi <nathan.rossi@digi.com> Description @@ -54,3 +60,12 @@ temp1_input Die temperature measurement (mC) temp1_max Maximum die temperature threshold (mC) temp1_max_alarm Maximum die temperature alarm ======================= ======================================================= + +Additional sysfs entries for sq52206 +------------------------------------ + +======================= ======================================================= +energy1_input Energy measurement (mJ) + +power1_input_highest Peak Power (uW) +======================= ======================================================= diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index ffe1a756a4f9..b45bfb4ebf30 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -106,6 +106,8 @@ Hardware Monitoring Kernel Drivers jc42 k10temp k8temp + kbatt + kfan lan966x lineage-pem lm25066 @@ -125,6 +127,7 @@ Hardware Monitoring Kernel Drivers lm95234 lm95245 lochnagar + lt3074 lt7182s ltc2992 ltc2945 @@ -161,6 +164,7 @@ Hardware Monitoring Kernel Drivers max6639 max6650 max6697 + max77705 max8688 mc13783-adc mc34vr500 diff --git a/Documentation/hwmon/kbatt.rst b/Documentation/hwmon/kbatt.rst new file mode 100644 index 000000000000..b72718c5ede3 --- /dev/null +++ b/Documentation/hwmon/kbatt.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver kbatt +=================== + +Supported chips: + + * KEBA battery monitoring controller (IP core in FPGA) + + Prefix: 'kbatt' + +Authors: + + Gerhard Engleder <eg@keba.com> + Petar Bojanic <boja@keba.com> + +Description +----------- + +The KEBA battery monitoring controller is an IP core for FPGAs, which +monitors the health of a coin cell battery. The coin cell battery is +typically used to supply the RTC during power off to keep the current +time. E.g., the CP500 FPGA includes this IP core to monitor the coin cell +battery of PLCs and the corresponding cp500 driver creates an auxiliary +device for the kbatt driver. + +This driver provides information about the coin cell battery health to +user space. Actually the user space shall be informed that the coin cell +battery is nearly empty and needs to be replaced. + +The coin cell battery must be tested actively to get to know if its nearly +empty or not. Therefore, a load is put on the coin cell battery and the +resulting voltage is evaluated. This evaluation is done by some hard wired +analog logic, which compares the voltage to a defined limit. If the +voltage is above the limit, then the coin cell battery is assumed to be +ok. If the voltage is below the limit, then the coin cell battery is +nearly empty (or broken, removed, ...) and shall be replaced by a new one. +The KEBA battery monitoring controller allows to start the test of the +coin cell battery and to get the result if the voltage is above or below +the limit. The actual voltage is not available. Only the information if +the voltage is below a limit is available. + +The test load, which is put on the coin cell battery for the health check, +is similar to the load during power off. Therefore, the lifetime of the +coin cell battery is reduced directly by the duration of each test. To +limit the negative impact to the lifetime the test is limited to at most +once every 10 seconds. The test load is put on the coin cell battery for +100ms. Thus, in worst case the coin cell battery lifetime is reduced by +1% of the uptime or 3.65 days per year. As the coin cell battery lasts +multiple years, this lifetime reduction negligible. + +This driver only provides a single alarm attribute, which is raised when +the coin cell battery is nearly empty. + +====================== ==== =================================================== +Attribute R/W Contents +====================== ==== =================================================== +in0_min_alarm R voltage of coin cell battery under load is below + limit +====================== ==== =================================================== diff --git a/Documentation/hwmon/kfan.rst b/Documentation/hwmon/kfan.rst new file mode 100644 index 000000000000..ce02dddfb4b8 --- /dev/null +++ b/Documentation/hwmon/kfan.rst @@ -0,0 +1,39 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver kfan +================== + +Supported chips: + + * KEBA fan controller (IP core in FPGA) + + Prefix: 'kfan' + +Authors: + + Gerhard Engleder <eg@keba.com> + Petar Bojanic <boja@keba.com> + +Description +----------- + +The KEBA fan controller is an IP core for FPGAs, which monitors the health +and controls the speed of a fan. The fan is typically used to cool the CPU +and the whole device. E.g., the CP500 FPGA includes this IP core to monitor +and control the fan of PLCs and the corresponding cp500 driver creates an +auxiliary device for the kfan driver. + +This driver provides information about the fan health to user space. +The user space shall be informed if the fan is removed or blocked. +Additionally, the speed in RPM is reported for fans with tacho signal. + +For fan control PWM is supported. For PWM 255 equals 100%. None-regulable +fans can be turned on with PWM 255 and turned off with PWM 0. + +====================== ==== =================================================== +Attribute R/W Contents +====================== ==== =================================================== +fan1_fault R Fan fault +fan1_input R Fan tachometer input (in RPM) +pwm1 RW Fan target duty cycle (0..255) +====================== ==== =================================================== diff --git a/Documentation/hwmon/lt3074.rst b/Documentation/hwmon/lt3074.rst new file mode 100644 index 000000000000..234f369153cf --- /dev/null +++ b/Documentation/hwmon/lt3074.rst @@ -0,0 +1,72 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver lt3074 +==================== + +Supported chips: + + * Analog Devices LT3074 + + Prefix: 'lt3074' + + Addresses scanned: - + + Datasheet: https://www.analog.com/en/products/lt3074.html + +Authors: Cedric Encarnacion <cedricjustine.encarnacion@analog.com> + + +Description +----------- + +This driver supports hardware monitoring for Analog Devices LT3074 Linear +Regulator with PMBus interface. + +The LT3074 is a low voltage, ultra-low noise and ultra-fast transient +response linear regulator with PMBus serial interface. PMBus telemetry +feature provides information regarding the output voltage and current, +input voltage, bias voltage and die temperature. + +The driver is a client driver to the core PMBus driver. Please see +Documentation/hwmon/pmbus.rst for details on PMBus client drivers. + +Usage Notes +----------- + +This driver does not auto-detect devices. You will have to instantiate +the devices explicitly. Please see Documentation/i2c/instantiating-devices.rst +for details. + +Platform data support +--------------------- + +The driver supports standard PMBus driver platform data. + +Sysfs entries +------------- + +======================= ======================================================= +in1_label "vin" +in1_input Measured input voltage +in1_max Input overvoltage warning limit +in1_max_alarm Input overvoltage warning status +in1_min Input undervoltage warning limit +in1_min_alarm Input undervoltage warning status +in2_label "vmon" +in2_input Measured bias voltage +in2_max Bias overvoltage warning limit +in2_min Bias undervoltage warning limit +in3_label "vout1" +in3_input Measured output voltage +in3_max Output overvoltage warning limit +in3_max_alarm Output overvoltage warning status +in3_min Output undervoltage warning limit +in3_min_alarm Output undervoltage warning status +curr1_label "iout1" +curr1_input Measured output current. +curr1_crit Output overcurrent fault limit +curr1_crit_alarm Output overcurrent fault status +temp1_input Measured temperature +temp1_max Maximum temperature limit +temp1_max_alarm Overtemperature warning status +======================= ======================================================= diff --git a/Documentation/hwmon/max34440.rst b/Documentation/hwmon/max34440.rst index 162d289f0814..8591a7152ce5 100644 --- a/Documentation/hwmon/max34440.rst +++ b/Documentation/hwmon/max34440.rst @@ -3,6 +3,14 @@ Kernel driver max34440 Supported chips: + * ADI ADPM12160 + + Prefixes: 'adpm12160' + + Addresses scanned: - + + Datasheet: - + * Maxim MAX34440 Prefixes: 'max34440' @@ -67,13 +75,14 @@ Author: Guenter Roeck <linux@roeck-us.net> Description ----------- -This driver supports hardware monitoring for Maxim MAX34440 PMBus 6-Channel -Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply Manager -and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data Logger. -It also supports the MAX34451, MAX34460, and MAX34461 PMBus Voltage Monitor & -Sequencers. The MAX34451 supports monitoring voltage or current of 12 channels -based on GIN pins. The MAX34460 supports 12 voltage channels, and the MAX34461 -supports 16 voltage channels. +This driver supports multiple devices: hardware monitoring for Maxim MAX34440 +PMBus 6-Channel Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply +Manager and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data +Logger; PMBus Voltage Monitor and Sequencers for MAX34451, MAX34460, and +MAX34461; PMBus DC/DC Power Module ADPM12160. The MAX34451 supports monitoring +voltage or current of 12 channels based on GIN pins. The MAX34460 supports 12 +voltage channels, and the MAX34461 supports 16 voltage channels. The ADPM1260 +also monitors both input and output of voltage and current. The driver is a client driver to the core PMBus driver. Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers. @@ -128,7 +137,10 @@ in[1-6]_highest Historical maximum voltage. in[1-6]_reset_history Write any value to reset history. ======================= ======================================================= -.. note:: MAX34446 only supports in[1-4]. +.. note:: + + - MAX34446 only supports in[1-4]. + - ADPM12160 only supports in[1-2]. Label is "vin1" and "vout1" respectively. Curr ~~~~ @@ -150,6 +162,7 @@ curr[1-6]_reset_history Write any value to reset history. - in6 and curr6 attributes only exist for MAX34440. - MAX34446 only supports curr[1-4]. + - For ADPM12160, curr[1] is "iin1" and curr[2-6] are "iout[1-5]. Power ~~~~~ @@ -185,6 +198,7 @@ temp[1-8]_reset_history Write any value to reset history. .. note:: - temp7 and temp8 attributes only exist for MAX34440. - MAX34446 only supports temp[1-3]. + - ADPM12160 only supports temp[1]. .. note:: diff --git a/Documentation/hwmon/max77705.rst b/Documentation/hwmon/max77705.rst new file mode 100644 index 000000000000..4a7680a340e1 --- /dev/null +++ b/Documentation/hwmon/max77705.rst @@ -0,0 +1,39 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver max77705 +====================== + +Supported chips: + + * Maxim Integrated MAX77705 + + Prefix: 'max77705' + + Addresses scanned: none + + Datasheet: Not available + +Authors: + - Dzmitry Sankouski <dsankouski@gmail.com> + +Description +----------- + +The MAX77705 PMIC provides current and voltage measurements besides fuelgauge: +- chip input current +- system bus current and voltage +- VBYP voltage + +Sysfs Attributes +---------------- + +================= ======================================== +in1_label "vbyp" +in1_input Measured chip vbyp voltage +in2_label "vsys" +in2_input Measured chip system bus voltage +curr1_label "iin" +curr1_input Measured chip input current. +curr2_label "isys" +curr2_input Measured chip system bus current. +================= ======================================== diff --git a/Documentation/hwmon/mpq8785.rst b/Documentation/hwmon/mpq8785.rst index bf8176b87086..198d5dfd7c30 100644 --- a/Documentation/hwmon/mpq8785.rst +++ b/Documentation/hwmon/mpq8785.rst @@ -5,6 +5,8 @@ Kernel driver mpq8785 Supported chips: + * MPS MPM3695 family + * MPS MPM82504 * MPS MPQ8785 Prefix: 'mpq8785' @@ -14,6 +16,22 @@ Author: Charles Hsu <ythsu0511@gmail.com> Description ----------- +The MPM3695 family is a scalable, ultra-thin, fully integrated power module with +a PMBus interface. It offers a complete power solution that achieves up to +10A (-10 variant), 20A (-25 variant), 25A (-20 variant), 100A (-100 variant) +of output current with excellent load and line regulation across a wide input +voltage range. It operates at high efficiency over a wide load range, and can +be parallled to deliver higher current. Variants -10,-20 and -100 have different +voltage scale configuration register range (10 bits) than -25 version (11 bits). + +The MPM82504 is a quad 25A, scalable, fully integrated power module with a PMBus +interface. The device offers a complete power solution that achieves up to 25A +per output channel. The MPM82504 has four output channels that can be paralleled +to provide 50A, 75A, or 100A of output current for flexible configurations. +The device can also operate in parallel with the MPM3695-100 and additional +MPM82504 devices to provide a higher output current. The MPM82504 operates +at high efficiency across a wide load range. + The MPQ8785 is a fully integrated, PMBus-compatible, high-frequency, synchronous buck converter. The MPQ8785 offers a very compact solution that achieves up to 40A output current per phase, with excellent load and line regulation over a @@ -23,19 +41,16 @@ output current load range. The PMBus interface provides converter configurations and key parameters monitoring. -The MPQ8785 adopts MPS's proprietary multi-phase digital constant-on-time (MCOT) +The devices adopts MPS's proprietary multi-phase digital constant-on-time (MCOT) control, which provides fast transient response and eases loop stabilization. -The MCOT scheme also allows multiple MPQ8785 devices to be connected in parallel -with excellent current sharing and phase interleaving for high-current +The MCOT scheme also allows multiple devices or channels to be connected in +parallel with excellent current sharing and phase interleaving for high-current applications. Fully integrated protection features include over-current protection (OCP), over-voltage protection (OVP), under-voltage protection (UVP), and over-temperature protection (OTP). -The MPQ8785 requires a minimal number of readily available, standard external -components, and is available in a TLGA (5mmx6mm) package. - Device compliant with: - PMBus rev 1.3 interface. diff --git a/Documentation/input/devices/amijoy.rst b/Documentation/input/devices/amijoy.rst index 8df7b11cd98d..a81e9de481c7 100644 --- a/Documentation/input/devices/amijoy.rst +++ b/Documentation/input/devices/amijoy.rst @@ -1,14 +1,15 @@ -~~~~~~~~~~~~~~~~~~~~~~~~~ -Amiga joystick extensions -~~~~~~~~~~~~~~~~~~~~~~~~~ +=============== +Amiga joysticks +=============== +Pinouts +======= -Amiga 4-joystick parport extension -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Amiga 4-joystick parallel port extension +---------------------------------------- Parallel port pins: - ===== ======== ==== ========== Pin Meaning Pin Meaning ===== ======== ==== ========== @@ -17,11 +18,11 @@ Pin Meaning Pin Meaning 4 Left1 8 Left2 5 Right1 9 Right2 13 Fire1 11 Fire2 -18 Gnd1 18 Gnd2 +19 Gnd1 18 Gnd2 ===== ======== ==== ========== -Amiga digital joystick pinout -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Amiga digital joystick +---------------------- === ============ Pin Meaning @@ -37,8 +38,8 @@ Pin Meaning 9 Thumb button === ============ -Amiga mouse pinout -~~~~~~~~~~~~~~~~~~ +Amiga mouse +----------- === ============ Pin Meaning @@ -54,8 +55,8 @@ Pin Meaning 9 Right button === ============ -Amiga analog joystick pinout -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Amiga analog joystick +--------------------- === ============== Pin Meaning @@ -71,8 +72,8 @@ Pin Meaning 9 Analog Y === ============== -Amiga lightpen pinout -~~~~~~~~~~~~~~~~~~~~~ +Amiga lightpen +-------------- === ============= Pin Meaning @@ -88,19 +89,23 @@ Pin Meaning 9 Stylus button === ============= -------------------------------------------------------------------------------- +Register addresses +================== + +JOY0DAT/JOY1DAT +--------------- -======== === ==== ==== ====== ======================================== +======== === ==== ==== ====== =========================================== NAME rev ADDR type chip Description -======== === ==== ==== ====== ======================================== -JOY0DAT 00A R Denise Joystick-mouse 0 data (left vert, horiz) -JOY1DAT 00C R Denise Joystick-mouse 1 data (right vert,horiz) -======== === ==== ==== ====== ======================================== +======== === ==== ==== ====== =========================================== +JOY0DAT 00A R Denise Joystick-mouse 0 data (left vert., horiz.) +JOY1DAT 00C R Denise Joystick-mouse 1 data (right vert., horiz.) +======== === ==== ==== ====== =========================================== These addresses each read a 16 bit register. These in turn are loaded from the MDAT serial stream and are clocked in on the rising edge of SCLK. MLD output is used to parallel load - the external parallel-to-serial converter.This in turn is + the external parallel-to-serial converter. This in turn is loaded with the 4 quadrature inputs from each of two game controller ports (8 total) plus 8 miscellaneous control bits which are new for LISA and can be read in upper 8 bits of @@ -108,7 +113,7 @@ JOY1DAT 00C R Denise Joystick-mouse 1 data (right vert,horiz) Register bits are as follows: - - Mouse counter usage (pins 1,3 =Yclock, pins 2,4 =Xclock) + - Mouse counter usage (pins 1,3 =Yclock, pins 2,4 =Xclock) ======== === === === === === === === === ====== === === === === === === === BIT# 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 @@ -123,7 +128,7 @@ JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0 clocked by 2 of the signals input from the mouse serial stream. Starting with first bit received: - +-------------------+-----------------------------------------+ + +--------+----------+-----------------------------------------+ | Serial | Bit Name | Description | +========+==========+=========================================+ | 0 | M0H | JOY0DAT Horizontal Clock | @@ -160,7 +165,8 @@ JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0 | Right | 4 | X1 | +------------+------+---------------------------------+ -------------------------------------------------------------------------------- +JOYTEST +------- ======== === ==== ==== ====== ================================================= NAME rev ADDR type chip Description @@ -177,14 +183,15 @@ JOYTEST 036 W Denise Write to all 4 joystick-mouse counters at once. JOYxDAT Y7 Y6 Y5 Y4 Y3 Y2 xx xx X7 X6 X5 X4 X3 X2 xx xx ========= === === === === === === === === ====== === === === === === === === -------------------------------------------------------------------------------- +POT0DAT/POT1DAT +--------------- -======= === ==== ==== ====== ======================================== +======= === ==== ==== ====== =========================================== NAME rev ADDR type chip Description -======= === ==== ==== ====== ======================================== -POT0DAT h 012 R Paula Pot counter data left pair (vert, horiz) -POT1DAT h 014 R Paula Pot counter data right pair (vert,horiz) -======= === ==== ==== ====== ======================================== +======= === ==== ==== ====== =========================================== +POT0DAT h 012 R Paula Pot counter data left pair (vert., horiz.) +POT1DAT h 014 R Paula Pot counter data right pair (vert., horiz.) +======= === ==== ==== ====== =========================================== These addresses each read a pair of 8 bit pot counters. (4 counters total). The bit assignment for both @@ -213,12 +220,13 @@ POT1DAT h 014 R Paula Pot counter data right pair (vert,horiz) +-------+------+-----+-----+-------+ With normal (NTSC or PAL) horiz. line rate, the pots will - give a full scale (FF) reading with about 500kohms in one - frame time. With proportionally faster horiz line times, + give a full scale (FF) reading with about 500k ohm in one + frame time. With proportionally faster horiz. line times, the counters will count proportionally faster. This should be noted when doing variable beam displays. -------------------------------------------------------------------------------- +POTGO +----- ====== === ==== ==== ====== ================================================ NAME rev ADDR type chip Description @@ -227,7 +235,8 @@ POTGO 034 W Paula Pot port (4 bit) bi-direction and data, and pot counter start. ====== === ==== ==== ====== ================================================ -------------------------------------------------------------------------------- +POTINP +------ ====== === ==== ==== ====== ================================================ NAME rev ADDR type chip Description @@ -238,26 +247,26 @@ POTINP 016 R Paula Pot pin data read This register controls a 4 bit bi-direction I/O port that shares the same 4 pins as the 4 pot counters above. - +-------+----------+---------------------------------------------+ - | BIT# | FUNCTION | DESCRIPTION | - +=======+==========+=============================================+ - | 15 | OUTRY | Output enable for Paula pin 33 | - +-------+----------+---------------------------------------------+ - | 14 | DATRY | I/O data Paula pin 33 | - +-------+----------+---------------------------------------------+ - | 13 | OUTRX | Output enable for Paula pin 32 | - +-------+----------+---------------------------------------------+ - | 12 | DATRX | I/O data Paula pin 32 | - +-------+----------+---------------------------------------------+ - | 11 | OUTLY | Out put enable for Paula pin 36 | - +-------+----------+---------------------------------------------+ - | 10 | DATLY | I/O data Paula pin 36 | - +-------+----------+---------------------------------------------+ - | 09 | OUTLX | Output enable for Paula pin 35 | - +-------+----------+---------------------------------------------+ - | 08 | DATLX | I/O data Paula pin 35 | - +-------+----------+---------------------------------------------+ - | 07-01 | X | Not used | - +-------+----------+---------------------------------------------+ - | 00 | START | Start pots (dump capacitors,start counters) | - +-------+----------+---------------------------------------------+ + +-------+----------+----------------------------------------------+ + | BIT# | FUNCTION | DESCRIPTION | + +=======+==========+==============================================+ + | 15 | OUTRY | Output enable for Paula pin 33 | + +-------+----------+----------------------------------------------+ + | 14 | DATRY | I/O data Paula pin 33 | + +-------+----------+----------------------------------------------+ + | 13 | OUTRX | Output enable for Paula pin 32 | + +-------+----------+----------------------------------------------+ + | 12 | DATRX | I/O data Paula pin 32 | + +-------+----------+----------------------------------------------+ + | 11 | OUTLY | Out put enable for Paula pin 36 | + +-------+----------+----------------------------------------------+ + | 10 | DATLY | I/O data Paula pin 36 | + +-------+----------+----------------------------------------------+ + | 09 | OUTLX | Output enable for Paula pin 35 | + +-------+----------+----------------------------------------------+ + | 08 | DATLX | I/O data Paula pin 35 | + +-------+----------+----------------------------------------------+ + | 07-01 | X | Not used | + +-------+----------+----------------------------------------------+ + | 00 | START | Start pots (dump capacitors, start counters) | + +-------+----------+----------------------------------------------+ diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index 3b9a8bc671e2..38cc656fac20 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -625,10 +625,10 @@ gcc-min-version Example:: - cflags-$(call gcc-min-version, 70100) := -foo + cflags-$(call gcc-min-version, 110100) := -foo In this example, cflags-y will be assigned the value -foo if $(CC) is gcc and - $(CONFIG_GCC_VERSION) is >= 7.1. + $(CONFIG_GCC_VERSION) is >= 11.1. clang-min-version clang-min-version tests if the value of $(CONFIG_CLANG_VERSION) is greater diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst index 0ab0a2128a11..76fae171039c 100644 --- a/Documentation/leds/index.rst +++ b/Documentation/leds/index.rst @@ -28,5 +28,5 @@ LEDs leds-mlxcpld leds-mt6370-rgb leds-sc27xx - leds-st1202.rst + leds-st1202 leds-qcom-lpg diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst index f12d33749329..ddc50db3afa4 100644 --- a/Documentation/mm/damon/design.rst +++ b/Documentation/mm/damon/design.rst @@ -54,7 +54,7 @@ monitoring are address-space dependent. DAMON consolidates these implementations in a layer called DAMON Operations Set, and defines the interface between it and the upper layer. The upper layer is dedicated for DAMON's core logics including the mechanism for control of the -monitoring accruracy and the overhead. +monitoring accuracy and the overhead. Hence, DAMON can easily be extended for any address space and/or available hardware features by configuring the core logic to use the appropriate @@ -550,10 +550,10 @@ aggressiveness (the quota) of the corresponding scheme. For example, if DAMOS is under achieving the goal, DAMOS automatically increases the quota. If DAMOS is over achieving the goal, it decreases the quota. -The goal can be specified with three parameters, namely ``target_metric``, -``target_value``, and ``current_value``. The auto-tuning mechanism tries to -make ``current_value`` of ``target_metric`` be same to ``target_value``. -Currently, two ``target_metric`` are provided. +The goal can be specified with four parameters, namely ``target_metric``, +``target_value``, ``current_value`` and ``nid``. The auto-tuning mechanism +tries to make ``current_value`` of ``target_metric`` be same to +``target_value``. - ``user_input``: User-provided value. Users could use any metric that they has interest in for the value. Use space main workload's latency or @@ -565,6 +565,11 @@ Currently, two ``target_metric`` are provided. in microseconds that measured from last quota reset to next quota reset. DAMOS does the measurement on its own, so only ``target_value`` need to be set by users at the initial time. In other words, DAMOS does self-feedback. +- ``node_mem_used_bp``: Specific NUMA node's used memory ratio in bp (1/10,000). +- ``node_mem_free_bp``: Specific NUMA node's free memory ratio in bp (1/10,000). + +``nid`` is optionally required for only ``node_mem_used_bp`` and +``node_mem_free_bp`` to point the specific NUMA node. To know how user-space can set the tuning goal metric, the target value, and/or the current value via :ref:`DAMON sysfs interface <sysfs_interface>`, refer to diff --git a/Documentation/mm/damon/index.rst b/Documentation/mm/damon/index.rst index 5a3359704cce..31c1fa955b3d 100644 --- a/Documentation/mm/damon/index.rst +++ b/Documentation/mm/damon/index.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -========================== -DAMON: Data Access MONitor -========================== +================================================================ +DAMON: Data Access MONitoring and Access-aware System Operations +================================================================ DAMON is a Linux kernel subsystem that provides a framework for data access monitoring and the monitoring results based system operations. The core diff --git a/Documentation/networking/arcnet-hardware.rst b/Documentation/networking/arcnet-hardware.rst index 982215723582..3bf7f99cd7bb 100644 --- a/Documentation/networking/arcnet-hardware.rst +++ b/Documentation/networking/arcnet-hardware.rst @@ -3152,7 +3152,7 @@ Tiara (model unknown) --------------- - - from Christoph Lameter <christoph@lameter.com> + - from Christoph Lameter <cl@gentwo.org> Here is information about my card as far as I could figure it out:: diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index d564362773b5..b14bd5b7cbc9 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -29,13 +29,13 @@ you probably needn't concern yourself with pcmciautils. ====================== =============== ======================================== Program Minimal version Command to check the version ====================== =============== ======================================== -GNU C 5.1 gcc --version +GNU C 8.1 gcc --version Clang/LLVM (optional) 13.0.1 clang --version Rust (optional) 1.78.0 rustc --version bindgen (optional) 0.65.1 bindgen --version GNU make 4.0 make --version bash 4.2 bash --version -binutils 2.25 ld -v +binutils 2.30 ld -v flex 2.5.35 flex --version bison 2.0 bison --version pahole 1.16 pahole --version @@ -116,7 +116,7 @@ Bash 4.2 or newer is needed. Binutils -------- -Binutils 2.25 or newer is needed to build the kernel. +Binutils 2.30 or newer is needed to build the kernel. pkg-config ---------- diff --git a/Documentation/process/debugging/gdb-kernel-debugging.rst b/Documentation/process/debugging/gdb-kernel-debugging.rst index 895285c037c7..9475c759c722 100644 --- a/Documentation/process/debugging/gdb-kernel-debugging.rst +++ b/Documentation/process/debugging/gdb-kernel-debugging.rst @@ -127,35 +127,31 @@ Examples of using the Linux-provided gdb helpers - Make use of the per-cpu function for the current or a specified CPU:: - (gdb) p $lx_per_cpu("runqueues").nr_running + (gdb) p $lx_per_cpu(runqueues).nr_running $3 = 1 - (gdb) p $lx_per_cpu("runqueues", 2).nr_running + (gdb) p $lx_per_cpu(runqueues, 2).nr_running $4 = 0 - Dig into hrtimers using the container_of helper:: - (gdb) set $next = $lx_per_cpu("hrtimer_bases").clock_base[0].active.next - (gdb) p *$container_of($next, "struct hrtimer", "node") + (gdb) set $leftmost = $lx_per_cpu(hrtimer_bases).clock_base[0].active.rb_root.rb_leftmost + (gdb) p *$container_of($leftmost, "struct hrtimer", "node") $5 = { node = { node = { - __rb_parent_color = 18446612133355256072, - rb_right = 0x0 <irq_stack_union>, - rb_left = 0x0 <irq_stack_union> + __rb_parent_color = 18446612686384860673, + rb_right = 0xffff888231da8b00, + rb_left = 0x0 }, - expires = { - tv64 = 1835268000000 - } + expires = 1228461000000 }, - _softexpires = { - tv64 = 1835268000000 - }, - function = 0xffffffff81078232 <tick_sched_timer>, - base = 0xffff88003fd0d6f0, - state = 1, - start_pid = 0, - start_site = 0xffffffff81055c1f <hrtimer_start_range_ns+20>, - start_comm = "swapper/2\000\000\000\000\000\000" + _softexpires = 1228461000000, + function = 0xffffffff8137ab20 <tick_nohz_handler>, + base = 0xffff888231d9b4c0, + state = 1 '\001', + is_rel = 0 '\000', + is_soft = 0 '\000', + is_hard = 1 '\001' } diff --git a/Documentation/staging/rpmsg.rst b/Documentation/staging/rpmsg.rst index 3713adaa1608..40282cca86ca 100644 --- a/Documentation/staging/rpmsg.rst +++ b/Documentation/staging/rpmsg.rst @@ -112,31 +112,6 @@ Returns 0 on success and an appropriate error value on failure. :: - int rpmsg_send_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst, - void *data, int len); - - -sends a message across to the remote processor, using the src and dst -addresses provided by the user. - -The caller should specify the endpoint, the data it wants to send, -its length (in bytes), and explicit source and destination addresses. -The message will then be sent to the remote processor to which the -endpoint's channel belongs, but the endpoint's src and channel dst -addresses will be ignored (and the user-provided addresses will -be used instead). - -In case there are no TX buffers available, the function will block until -one becomes available (i.e. until the remote processor consumes -a tx buffer and puts it back on virtio's used descriptor ring), -or a timeout of 15 seconds elapses. When the latter happens, --ERESTARTSYS is returned. - -The function can only be called from a process context (for now). -Returns 0 on success and an appropriate error value on failure. - -:: - int rpmsg_trysend(struct rpmsg_endpoint *ept, void *data, int len); sends a message across to the remote processor from a given endpoint. @@ -175,27 +150,6 @@ Returns 0 on success and an appropriate error value on failure. :: - int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst, - void *data, int len); - - -sends a message across to the remote processor, using source and -destination addresses provided by the user. - -The user should specify the channel, the data it wants to send, -its length (in bytes), and explicit source and destination addresses. -The message will then be sent to the remote processor to which the -channel belongs, but the channel's src and dst addresses will be -ignored (and the user-provided addresses will be used instead). - -In case there are no TX buffers available, the function will immediately -return -ENOMEM without waiting until one becomes available. - -The function can only be called from a process context (for now). -Returns 0 on success and an appropriate error value on failure. - -:: - struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev, rpmsg_rx_cb_t cb, void *priv, struct rpmsg_channel_info chinfo); diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst index c7d05e2fff15..77db13c4022b 100644 --- a/Documentation/translations/it_IT/process/changes.rst +++ b/Documentation/translations/it_IT/process/changes.rst @@ -32,13 +32,13 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils. ====================== ================= ======================================== Programma Versione minima Comando per verificare la versione ====================== ================= ======================================== -GNU C 5.1 gcc --version +GNU C 8.1 gcc --version Clang/LLVM (optional) 13.0.0 clang --version Rust (opzionale) 1.78.0 rustc --version bindgen (opzionale) 0.65.1 bindgen --version GNU make 4.0 make --version bash 4.2 bash --version -binutils 2.25 ld -v +binutils 2.30 ld -v flex 2.5.35 flex --version bison 2.0 bison --version pahole 1.16 pahole --version @@ -118,7 +118,7 @@ Questo richiede bash 4.2 o successivo. Binutils -------- -Per generare il kernel è necessario avere Binutils 2.25 o superiore. +Per generare il kernel è necessario avere Binutils 2.30 o superiore. pkg-config ---------- diff --git a/Documentation/translations/zh_CN/admin-guide/README.rst b/Documentation/translations/zh_CN/admin-guide/README.rst index 1bdafdc4c8e2..82e628b77efd 100644 --- a/Documentation/translations/zh_CN/admin-guide/README.rst +++ b/Documentation/translations/zh_CN/admin-guide/README.rst @@ -224,7 +224,7 @@ Linux内核6.x版本 <http://kernel.org/> 编译内核 --------- - - 确保您至少有gcc 5.1可用。 + - 确保您至少有gcc 8.1可用。 有关更多信息，请参阅 :ref:`Documentation/process/changes.rst <changes>` 。 - 执行 ``make`` 来创建压缩内核映像。如果您安装了lilo以适配内核makefile， diff --git a/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst b/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst index 3c133a918f30..282aacd33442 100644 --- a/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst +++ b/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst @@ -120,35 +120,31 @@ Kgdb内核调试器、QEMU等虚拟机管理程序或基于JTAG的硬件接口 - 对当前或指定的CPU使用per-cpu函数:: - (gdb) p $lx_per_cpu("runqueues").nr_running + (gdb) p $lx_per_cpu(runqueues).nr_running $3 = 1 - (gdb) p $lx_per_cpu("runqueues", 2).nr_running + (gdb) p $lx_per_cpu(runqueues, 2).nr_running $4 = 0 - 使用container_of查看更多hrtimers信息:: - (gdb) set $next = $lx_per_cpu("hrtimer_bases").clock_base[0].active.next - (gdb) p *$container_of($next, "struct hrtimer", "node") + (gdb) set $leftmost = $lx_per_cpu(hrtimer_bases).clock_base[0].active.rb_root.rb_leftmost + (gdb) p *$container_of($leftmost, "struct hrtimer", "node") $5 = { node = { node = { - __rb_parent_color = 18446612133355256072, - rb_right = 0x0 <irq_stack_union>, - rb_left = 0x0 <irq_stack_union> + __rb_parent_color = 18446612686384860673, + rb_right = 0xffff888231da8b00, + rb_left = 0x0 }, - expires = { - tv64 = 1835268000000 - } + expires = 1228461000000 }, - _softexpires = { - tv64 = 1835268000000 - }, - function = 0xffffffff81078232 <tick_sched_timer>, - base = 0xffff88003fd0d6f0, - state = 1, - start_pid = 0, - start_site = 0xffffffff81055c1f <hrtimer_start_range_ns+20>, - start_comm = "swapper/2\000\000\000\000\000\000" + _softexpires = 1228461000000, + function = 0xffffffff8137ab20 <tick_nohz_handler>, + base = 0xffff888231d9b4c0, + state = 1 '\001', + is_rel = 0 '\000', + is_soft = 0 '\000', + is_hard = 1 '\001' } diff --git a/Documentation/translations/zh_TW/dev-tools/gdb-kernel-debugging.rst b/Documentation/translations/zh_TW/dev-tools/gdb-kernel-debugging.rst index c881e8872b19..b595af59ba78 100644 --- a/Documentation/translations/zh_TW/dev-tools/gdb-kernel-debugging.rst +++ b/Documentation/translations/zh_TW/dev-tools/gdb-kernel-debugging.rst @@ -116,35 +116,31 @@ Kgdb內核調試器、QEMU等虛擬機管理程序或基於JTAG的硬件接口 - 對當前或指定的CPU使用per-cpu函數:: - (gdb) p $lx_per_cpu("runqueues").nr_running + (gdb) p $lx_per_cpu(runqueues).nr_running $3 = 1 - (gdb) p $lx_per_cpu("runqueues", 2).nr_running + (gdb) p $lx_per_cpu(runqueues, 2).nr_running $4 = 0 - 使用container_of查看更多hrtimers信息:: - (gdb) set $next = $lx_per_cpu("hrtimer_bases").clock_base[0].active.next - (gdb) p *$container_of($next, "struct hrtimer", "node") + (gdb) set $leftmost = $lx_per_cpu(hrtimer_bases).clock_base[0].active.rb_root.rb_leftmost + (gdb) p *$container_of($leftmost, "struct hrtimer", "node") $5 = { node = { node = { - __rb_parent_color = 18446612133355256072, - rb_right = 0x0 <irq_stack_union>, - rb_left = 0x0 <irq_stack_union> + __rb_parent_color = 18446612686384860673, + rb_right = 0xffff888231da8b00, + rb_left = 0x0 }, - expires = { - tv64 = 1835268000000 - } + expires = 1228461000000 }, - _softexpires = { - tv64 = 1835268000000 - }, - function = 0xffffffff81078232 <tick_sched_timer>, - base = 0xffff88003fd0d6f0, - state = 1, - start_pid = 0, - start_site = 0xffffffff81055c1f <hrtimer_start_range_ns+20>, - start_comm = "swapper/2\000\000\000\000\000\000" + _softexpires = 1228461000000, + function = 0xffffffff8137ab20 <tick_nohz_handler>, + base = 0xffff888231d9b4c0, + state = 1 '\001', + is_rel = 0 '\000', + is_soft = 0 '\000', + is_hard = 1 '\001' } diff --git a/Documentation/virt/hyperv/vmbus.rst b/Documentation/virt/hyperv/vmbus.rst index 1dcef6a7fda3..654bb4849972 100644 --- a/Documentation/virt/hyperv/vmbus.rst +++ b/Documentation/virt/hyperv/vmbus.rst @@ -250,10 +250,18 @@ interrupts are not Linux IRQs, there are no entries in /proc/interrupts or /proc/irq corresponding to individual VMBus channel interrupts. An online CPU in a Linux guest may not be taken offline if it has -VMBus channel interrupts assigned to it. Any such channel -interrupts must first be manually reassigned to another CPU as -described above. When no channel interrupts are assigned to the -CPU, it can be taken offline. +VMBus channel interrupts assigned to it. Starting in kernel v6.15, +any such interrupts are automatically reassigned to some other CPU +at the time of offlining. The "other" CPU is chosen by the +implementation and is not load balanced or otherwise intelligently +determined. If the CPU is onlined again, channel interrupts previously +assigned to it are not moved back. As a result, after multiple CPUs +have been offlined, and perhaps onlined again, the interrupt-to-CPU +mapping may be scrambled and non-optimal. In such a case, optimal +assignments must be re-established manually. For kernels v6.14 and +earlier, any conflicting channel interrupts must first be manually +reassigned to another CPU as described above. Then when no channel +interrupts are assigned to the CPU, it can be taken offline. The VMBus channel interrupt handling code is designed to work correctly even if an interrupt is received on a CPU other than the @@ -324,3 +332,15 @@ rescinded, neither Hyper-V nor Linux retains any state about its previous existence. Such a device might be re-added later, in which case it is treated as an entirely new device. See vmbus_onoffer_rescind(). + +For some devices, such as the KVP device, Hyper-V automatically +sends a rescind message when the primary channel is closed, +likely as a result of unbinding the device from its driver. +The rescind causes Linux to remove the device. But then Hyper-V +immediately reoffers the device to the guest, causing a new +instance of the device to be created in Linux. For other +devices, such as the synthetic SCSI and NIC devices, closing the +primary channel does *not* result in Hyper-V sending a rescind +message. The device continues to exist in Linux on the VMBus, +but with no driver bound to it. The same driver or a new driver +can subsequently be bound to the existing instance of the device. diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 6fb1870f0999..1bd2d42e6424 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -8001,6 +8001,11 @@ apply some other policy-based mitigation. When exiting to userspace, KVM sets KVM_RUN_X86_BUS_LOCK in vcpu-run->flags, and conditionally sets the exit_reason to KVM_EXIT_X86_BUS_LOCK. +Due to differences in the underlying hardware implementation, the vCPU's RIP at +the time of exit diverges between Intel and AMD. On Intel hosts, RIP points at +the next instruction, i.e. the exit is trap-like. On AMD hosts, RIP points at +the offending instruction, i.e. the exit is fault-like. + Note! Detected bus locks may be coincident with other exits to userspace, i.e. KVM_RUN_X86_BUS_LOCK should be checked regardless of the primary exit reason if userspace wants to take action on all detected bus locks. |