github-mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-09-28 12:02:03 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity Graph

Merge branch 'arena_direct_access' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next into for-7.2

Browse Source
This commit is contained in:
Tejun Heo 2026-05-25 09:34:24 -10:00
commit 639609b83f
6230 changed files with 290540 additions and 221708 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
.mailmap
View File

@ -19,6 +19,7 @@ Abhinav Kumar <quic_abhinavk@quicinc.com> <abhinavk@codeaurora.org>
Ahmad Masri <quic_amasri@quicinc.com> <amasri@codeaurora.org>
Adam Oldham <oldhamca@gmail.com>
Adam Radford <aradford@gmail.com>
Aditya Garg <gargaditya08@proton.me> <gargaditya08@live.com>
Adriana Reus <adi.reus@gmail.com> <adriana.reus@intel.com>
Adrian Bunk <bunk@stusta.de>
Ajay Kaher <ajay.kaher@broadcom.com> <akaher@vmware.com>
@ -207,7 +208,9 @@ Claudiu Beznea <claudiu.beznea@tuxon.dev> <claudiu.beznea@microchip.com>
Colin Ian King <colin.i.king@gmail.com> <colin.king@canonical.com>
Corey Minyard <minyard@acm.org>
Damian Hobson-Garcia <dhobsong@igel.co.jp>
Dan Carpenter <error27@gmail.com> <dan.carpenter@linaro.org>
Dan Carpenter <error27@gmail.com> <dan.carpenter@oracle.com>
Dan Williams <djbw@kernel.org> <dan.j.williams@intel.com>
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com>
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> <daniel.borkmann@tik.ee.ethz.ch>
@ -309,7 +312,10 @@ Gokul Sriram Palanisamy <quic_gokulsri@quicinc.com> <gokulsri@codeaurora.org>
Govindaraj Saminathan <quic_gsamin@quicinc.com> <gsamin@codeaurora.org>
Guo Ren <guoren@kernel.org> <guoren@linux.alibaba.com>
Guo Ren <guoren@kernel.org> <ren_guo@c-sky.com>
Guru Das Srinagesh <quic_gurus@quicinc.com> <gurus@codeaurora.org>
Guru Das Srinagesh <linux@gurudas.dev>
Guru Das Srinagesh <linux@gurudas.dev> <quic_gurus@quicinc.com>
Guru Das Srinagesh <linux@gurudas.dev> <gurus@codeaurora.org>
Guru Das Srinagesh <linux@gurudas.dev> <gurooodas@gmail.com>
Gustavo Padovan <gustavo@las.ic.unicamp.br>
Gustavo Padovan <padovan@profusion.mobi>
Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> <hamza.mahfooz@amd.com>
@ -334,6 +340,7 @@ Herbert Xu <herbert@gondor.apana.org.au>
Huacai Chen <chenhuacai@kernel.org> <chenhc@lemote.com>
Huacai Chen <chenhuacai@kernel.org> <chenhuacai@loongson.cn>
Ignat Korchagin <ignat@linux.win> <ignat@cloudflare.com>
Igor Korotin <igor.korotin@linux.dev> <igor.korotin.linux@gmail.com>
Ike Panhc <ikepanhc@gmail.com> <ike.pan@canonical.com>
J. Bruce Fields <bfields@fieldses.org> <bfields@redhat.com>
J. Bruce Fields <bfields@fieldses.org> <bfields@citi.umich.edu>
@ -424,6 +431,7 @@ John Stultz <johnstul@us.ibm.com>
<jon.toppins+linux@gmail.com> <jtoppins@cumulusnetworks.com>
<jon.toppins+linux@gmail.com> <jtoppins@redhat.com>
Jonas Gorski <jonas.gorski@gmail.com> <jogo@openwrt.org>
Jonathan Cameron <jic23@kernel.org> <jonathan.cameron@huawei.com>
Jordan Crouse <jordan@cosmicpenguin.net> <jcrouse@codeaurora.org>
<josh@joshtriplett.org> <josh@freedesktop.org>
<josh@joshtriplett.org> <josh@kernel.org>
@ -489,6 +497,7 @@ Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
Leon Romanovsky <leon@kernel.org> <leonro@nvidia.com>
Leo Yan <leo.yan@linux.dev> <leo.yan@linaro.org>
Liam R. Howlett <liam@infradead.org> <Liam.Howlett@oracle.com>
Liam Mark <quic_lmark@quicinc.com> <lmark@codeaurora.org>
Linas Vepstas <linas@austin.ibm.com>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
@ -499,6 +508,8 @@ Linus Walleij <linusw@kernel.org> <linus.walleij@stericsson.com>
Linus Walleij <linusw@kernel.org> <linus.walleij@linaro.org>
Linus Walleij <linusw@kernel.org> <triad@df.lth.se>
<linux-hardening@vger.kernel.org> <kernel-hardening@lists.openwall.com>
Li Wang <li.wang@linux.dev> <liwang@redhat.com>
Li Wang <li.wang@linux.dev> <wangli.ahau@gmail.com>
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
Lior David <quic_liord@quicinc.com> <liord@codeaurora.org>
@ -581,6 +592,7 @@ Michel Lespinasse <michel@lespinasse.org> <walken@google.com>
Michel Lespinasse <michel@lespinasse.org> <walken@zoy.org>
Mickaël Salaün <mic@digikod.net> <mic@linux.microsoft.com>
Miguel Ojeda <ojeda@kernel.org> <miguel.ojeda.sandonis@gmail.com>
Mike Leach <mike.leach@arm.com> <mike.leach@linaro.org>
Mike Rapoport <rppt@kernel.org> <mike@compulab.co.il>
Mike Rapoport <rppt@kernel.org> <mike.rapoport@gmail.com>
Mike Rapoport <rppt@kernel.org> <rppt@linux.ibm.com>
@ -670,6 +682,7 @@ Peter A Jonsson <pj@ludd.ltu.se>
Peter Hilber <peter.hilber@oss.qualcomm.com> <quic_philber@quicinc.com>
Peter Oruba <peter.oruba@amd.com>
Peter Oruba <peter@oruba.de>
Peter Rosin <peda@lysator.liu.se> <peda@axentia.se>
Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> <pierre-louis.bossart@linux.intel.com>
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
Pratyush Yadav <pratyush@kernel.org> <ptyadav@amazon.de>
@ -680,6 +693,7 @@ Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com>
Puranjay Mohan <puranjay@kernel.org> <puranjay12@gmail.com>
Qais Yousef <qyousef@layalina.io> <qais.yousef@imgtec.com>
Qais Yousef <qyousef@layalina.io> <qais.yousef@arm.com>
Qi Zheng <qi.zheng@linux.dev> <zhengqi.arch@bytedance.com>
Quentin Monnet <qmo@kernel.org> <quentin.monnet@netronome.com>
Quentin Monnet <qmo@kernel.org> <quentin@isovalent.com>
Quentin Perret <qperret@qperret.net> <quentin.perret@arm.com>
@ -738,11 +752,13 @@ Sarangdhar Joshi <spjoshi@codeaurora.org>
Saravana Kannan <saravanak@kernel.org> <skannan@codeaurora.org>
Saravana Kannan <saravanak@kernel.org> <saravanak@google.com>
Sascha Hauer <s.hauer@pengutronix.de>
Sasha Finkelstein <k@chaosmail.tech> <fnkl.kernel@gmail.com>
Sahitya Tummala <quic_stummala@quicinc.com> <stummala@codeaurora.org>
Sathishkumar Muruganandam <quic_murugana@quicinc.com> <murugana@codeaurora.org>
Satya Priya <quic_skakitap@quicinc.com> <quic_c_skakit@quicinc.com> <skakit@codeaurora.org>
S.Çağlar Onur <caglar@pardus.org.tr>
Sayali Lokhande <quic_sayalil@quicinc.com> <sayalil@codeaurora.org>
Sean Anderson <sean.anderson@linux.dev> <sean.anderson@seco.com>
Sean Christopherson <seanjc@google.com> <sean.j.christopherson@intel.com>
Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
Sean Tranchetti <quic_stranche@quicinc.com> <stranche@codeaurora.org>
@ -841,6 +857,7 @@ Tobias Klauser <tklauser@distanz.ch> <klto@zhaw.ch>
Tobias Klauser <tklauser@distanz.ch> <tklauser@nuerscht.ch>
Tobias Klauser <tklauser@distanz.ch> <tklauser@xenon.tklauser.home>
Todor Tomov <todor.too@gmail.com> <todor.tomov@linaro.org>
Tomasz Jeznach <tomasz.jeznach@linux.dev> <tjeznach@rivosinc.com>
Tony Luck <tony.luck@intel.com>
Trilok Soni <quic_tsoni@quicinc.com> <tsoni@codeaurora.org>
TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>

29
CREDITS
View File

@ -71,11 +71,6 @@ D: dosfs, LILO, some fd features, ATM, various other hacks here and there
S: Buenos Aires
S: Argentina
NTFS FILESYSTEM
N: Anton Altaparmakov
E: anton@tuxera.com
D: NTFS filesystem
N: Tim Alpaerts
E: tim_alpaerts@toyota-motor-europe.com
D: 802.2 class II logical link control layer,
@ -85,8 +80,8 @@ S: B-2610 Wilrijk-Antwerpen
S: Belgium
N: Anton Altaparmakov
E: aia21@cantab.net
W: http://www-stu.christs.cam.ac.uk/~aia21/
E: anton@tuxera.com
W: http://www.tuxera.com/
D: Author of new NTFS driver, various other kernel hacks.
S: Christ's College
S: Cambridge CB2 3BU
@ -1456,6 +1451,14 @@ N: Andy Gospodarek
E: andy@greyhouse.net
D: Maintenance and contributions to the network interface bonding driver.
N: Vivek Goyal
E: vgoyal@redhat.com
D: KDUMP, KEXEC, and VIRTIO FILE SYSTEM
N: Alexander Graf
E: graf@amazon.com
D: Kexec Handover (KHO)
N: Wolfgang Grandegger
E: wg@grandegger.com
D: Controller Area Network (device drivers)
@ -3649,6 +3652,11 @@ S: Dag Hammerskjolds v. 3E
S: S-226 64 LUND
S: Sweden
N: Tilman Schmidt
E: tilman@imap.cc
D: Siemens Gigaset ISDN driver author and maintainer
D: ISDN CAPI subsystem contributions
N: Henning P. Schmiedehausen
E: hps@tanstaafl.de
D: added PCI support to the serial driver
@ -4570,8 +4578,5 @@ D: MD driver
D: EISA/sysfs subsystem
S: France
# Don't add your name here, unless you really _are_ after Marc
# alphabetically. Leonard used to be very proud of being the
# last entry, and he'll get positively pissed if he can't even
# be second-to-last. (and this file really _is_ supposed to be
# in alphabetic order)
# Don't add your name here unless you really are last alphabetically.
# (This file is supposed to be kept in alphabetical order by last name.)

6
Documentation/.renames.txt
View File

@ -783,11 +783,9 @@ namespaces/compatibility-list admin-guide/namespaces/compatibility-list
namespaces/index admin-guide/namespaces/index
namespaces/resource-control admin-guide/namespaces/resource-control
networking/altera_tse networking/device_drivers/ethernet/altera/altera_tse
networking/baycom networking/device_drivers/hamradio/baycom
networking/bpf_flow_dissector bpf/prog_flow_dissector
networking/cxacru networking/device_drivers/atm/cxacru
networking/defza networking/device_drivers/fddi/defza
networking/device_drivers/3com/3c509 networking/device_drivers/ethernet/3com/3c509
networking/device_drivers/3com/vortex networking/device_drivers/ethernet/3com/vortex
networking/device_drivers/amazon/ena networking/device_drivers/ethernet/amazon/ena
networking/device_drivers/aquantia/atlantic networking/device_drivers/ethernet/aquantia/atlantic
@ -822,7 +820,6 @@ networking/device_drivers/microsoft/netvsc networking/device_drivers/ethernet/mi
networking/device_drivers/netronome/nfp networking/device_drivers/ethernet/netronome/nfp
networking/device_drivers/pensando/ionic networking/device_drivers/ethernet/pensando/ionic
networking/device_drivers/qualcomm/rmnet networking/device_drivers/cellular/qualcomm/rmnet
networking/device_drivers/smsc/smc9 networking/device_drivers/ethernet/smsc/smc9
networking/device_drivers/stmicro/stmmac networking/device_drivers/ethernet/stmicro/stmmac
networking/device_drivers/ti/cpsw networking/device_drivers/ethernet/ti/cpsw
networking/device_drivers/ti/cpsw_switchdev networking/device_drivers/ethernet/ti/cpsw_switchdev
@ -836,19 +833,16 @@ networking/e100 networking/device_drivers/ethernet/intel/e100
networking/e1000 networking/device_drivers/ethernet/intel/e1000
networking/e1000e networking/device_drivers/ethernet/intel/e1000e
networking/fm10k networking/device_drivers/ethernet/intel/fm10k
networking/fore200e networking/device_drivers/atm/fore200e
networking/hinic networking/device_drivers/ethernet/huawei/hinic
networking/i40e networking/device_drivers/ethernet/intel/i40e
networking/iavf networking/device_drivers/ethernet/intel/iavf
networking/ice networking/device_drivers/ethernet/intel/ice
networking/igb networking/device_drivers/ethernet/intel/igb
networking/igbvf networking/device_drivers/ethernet/intel/igbvf
networking/iphase networking/device_drivers/atm/iphase
networking/ixgbe networking/device_drivers/ethernet/intel/ixgbe
networking/ixgbevf networking/device_drivers/ethernet/intel/ixgbevf
networking/netdev-FAQ process/maintainer-netdev
networking/skfp networking/device_drivers/fddi/skfp
networking/z8530drv networking/device_drivers/hamradio/z8530drv
nfc/index driver-api/nfc/index
nfc/nfc-hci driver-api/nfc/nfc-hci
nfc/nfc-pn544 driver-api/nfc/nfc-pn544

0
Documentation/ABI/obsolete/sysfs-selinux-user → Documentation/ABI/removed/sysfs-selinux-user
View File

4
Documentation/ABI/stable/sysfs-driver-speakup
View File

@ -16,8 +16,8 @@ What: /sys/accessibility/speakup/bleeps
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: This controls whether one hears beeps through the PC speaker
when using speakup's review commands.
TODO: what values does it accept?
when using speakup's review commands. Range: 0-3. 0 = off, 1 = beeps
only, 2 = announcements only, 3 = beeps and announcements (default).
What: /sys/accessibility/speakup/bleep_time
KernelVersion: 2.6

1
Documentation/ABI/testing/evm
View File

@ -26,6 +26,7 @@ Description:
2 Permit modification of EVM-protected metadata at
runtime. Not supported if HMAC validation and
creation is enabled (deprecated).
3 Require asymmetric signatures to be version 3
31 Disable further runtime modification of EVM policy
=== ==================================================

10
Documentation/ABI/testing/ima_policy
View File

@ -53,10 +53,7 @@ Description:
where 'imasig' is the original or the signature
format v2.
where 'modsig' is an appended signature,
where 'sigv3' is the signature format v3. (Currently
limited to fsverity digest based signatures
stored in security.ima xattr. Requires
specifying "digest_type=verity" first.)
where 'sigv3' is the signature format v3.
appraise_flag:= [check_blacklist] (deprecated)
Setting the check_blacklist flag is no longer necessary.
@ -186,6 +183,11 @@ Description:
appraise func=BPRM_CHECK digest_type=verity \
appraise_type=sigv3
Example of a regular IMA file hash 'appraise' rule requiring
signature version 3 format stored in security.ima xattr.
appraise func=BPRM_CHECK appraise_type=sigv3
All of these policy rules could, for example, be constrained
either based on a filesystem's UUID (fsuuid) or based on LSM
labels.

10
Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
View File

@ -278,3 +278,13 @@ Date: Aug 2025
KernelVersion 6.18
Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
Description: (Read) Show hardware context information of device.
What: /sys/bus/coresight/devices/<tpdm-name>/traceid
Date: March 2026
KernelVersion: 7.1
Contact: Jie Gan <jie.gan@oss.qualcomm.com>
Description:
(R) Show the trace ID that will appear in the trace stream
coming from this TPDM. The trace ID is inherited from the
connected TPDA device and is fixed for the lifetime of the
device. Returns -EINVAL if the device has not been enabled yet.

13
Documentation/ABI/testing/sysfs-bus-cxl
View File

@ -508,6 +508,19 @@ Description:
(RO) The size of extended linear cache, if there is an extended
linear cache. Otherwise the attribute will not be visible.
What: /sys/bus/cxl/devices/regionZ/locked
Date: Mar, 2026
KernelVersion: v7.1
Contact: linux-cxl@vger.kernel.org
Description:
(RO) The CXL driver has the capability to lock a region based on
a BIOS or platform dependent configuration. Regions created as
locked are never permitted to be destroyed. Resets to participating
decoders will not result in a region destroy and will not free the
decoder resources.
What: /sys/bus/cxl/devices/regionZ/mode
Date: January, 2023
KernelVersion: v6.3

20
Documentation/ABI/testing/sysfs-bus-i3c
View File

@ -172,3 +172,23 @@ Description:
the automatic retries. Exist only when I3C constroller supports
this retry on nack feature.
What: /sys/bus/i3c/devices/i3c-<bus-id>/do_daa
KernelVersion: 7.0
Contact: linux-i3c@vger.kernel.org
Description:
Write-only attribute that triggers a Dynamic Address Assignment
(DAA) procedure which discovers new I3C devices on the bus.
Writing a boolean true value (1, y, yes, true, on) to this
attribute causes the master controller to perform DAA, which
includes broadcasting an ENTDAA (Enter Dynamic Address Assignment)
Common Command Code (CCC) on the bus. Writing a false value
returns -EINVAL.
This is useful for discovering I3C devices that were not present
during initial bus initialization and are unable to issue
Hot-Join. Only devices without a currently assigned dynamic address
will respond to the ENTDAA broadcast and be assigned addresses.
Note that this mechanism is distinct from Hot-Join, since this is
controller-initiated discovery, while Hot-Join is device-initiated
method to provoke controller discovery procedure.

2
Documentation/ABI/testing/sysfs-bus-iio
View File

@ -1428,7 +1428,7 @@ KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
The name of the trigger source being used, as per string given
in /sys/class/iio/triggerY/name.
in /sys/bus/iio/devices/triggerY/name.
What: /sys/bus/iio/devices/iio:deviceX/bufferY/length
KernelVersion: 5.11

3
Documentation/ABI/testing/sysfs-class-power
View File

@ -675,7 +675,8 @@ Description:
Valid values:
"Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
"PD_DRP", "PD_PPS", "BrickID"
"PD_DRP", "PD_PPS", "BrickID", "PD_SPR_AVS",
"PD_PPS_SPR_AVS"
**Device Specific Properties**

36
Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes Normal file
View File

@ -0,0 +1,36 @@
What: /sys/class/reboot-mode/<driver>/reboot_modes
Date: March 2026(TBD)
KernelVersion: TBD
Contact: linux-pm@vger.kernel.org
Description:
This interface exposes the reboot-mode arguments
registered with the reboot-mode framework. It is
a read-only interface and provides a space
separated list of reboot-mode arguments supported
on the current platform.
Example:
recovery fastboot bootloader
The exact sysfs path may vary depending on the
name of the driver that registers the arguments.
Example:
/sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes
/sys/class/reboot-mode/syscon-reboot-mode/reboot_modes
/sys/class/reboot-mode/qcom-pon/reboot_modes
The supported arguments can be used by userspace to
invoke device reset using the standard reboot() system
call interface, with the "argument" as string to "*arg"
parameter along with LINUX_REBOOT_CMD_RESTART2.
A driver can expose the supported arguments by
registering them with the reboot-mode framework
using the property names that follow the
mode-<argument> format.
Example:
mode-bootloader, mode-recovery.
This attribute is useful for scripts or initramfs
logic that need to programmatically determine
which reboot-mode arguments are valid before
triggering a reboot.

724
Documentation/ABI/testing/sysfs-driver-hid-lenovo-go Normal file
View File

@ -0,0 +1,724 @@
What: /sys/class/leds/go:rgb:joystick_rings/effect
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the display effect of the RGB interface.
Values are monocolor, breathe, chroma, or rainbow.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/class/leds/go:rgb:joystick_rings/effect_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the effect attribute.
Values are monocolor, breathe, chroma, or rainbow.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/class/leds/go:rgb:joystick_rings/enabled
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling or disabling the RGB interface.
Values are true or false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/class/leds/go:rgb:joystick_rings/enabled_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the enabled attribute.
Values are true or false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/class/leds/go:rgb:joystick_rings/mode
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the operating mode of the RGB interface.
Values are dynamic or custom. Custom allows setting the RGB effect and color.
Dynamic is a Windows mode for syncing Lenovo RGB interfaces not currently
supported under Linux.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/class/leds/go:rgb:joystick_rings/mode_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the mode attribute.
Values are dynamic or custom.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/class/leds/go:rgb:joystick_rings/profile
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls selecting the configured RGB profile.
Values are 1-3.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/class/leds/go:rgb:joystick_rings/profile_range
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the profile attribute.
Values are 1-3.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/class/leds/go:rgb:joystick_rings/speed
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the change rate for the breathe, chroma, and rainbow effects.
Values are 0-100.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/class/leds/go:rgb:joystick_rings/speed_range
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the speed attribute.
Values are 0-100.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/firmware_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the firmware version of the internal MCU.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/fps_mode_dpi
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the DPI of the right handle when the FPS mode switch is on.
Values are 500, 800, 1200, and 1800.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/fps_mode_dpi_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the fps_mode_dpi attribute.
Values are 500, 800, 1200, and 1800.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/hardware_generation
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the hardware generation of the internal MCU.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/hardware_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the hardware version of the internal MCU.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/auto_sleep_time
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the sleep timer due to inactivity for the left removable controller.
Values are 0-255.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/auto_sleep_time_range
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the left_handle/auto_sleep_time attribute.
Values are 0-255.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_gyro
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This initiates or halts calibration of the left removable controller's IMU.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_gyro_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the left_handle/calibrate_gyro attribute.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_gyro_status
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the result of the last attempted calibration of the left removable controller's IMU.
Values are unknown, success, failure.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_joystick
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This initiates or halts calibration of the left removable controller's joystick.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_joystick_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the left_handle/calibrate_jotstick attribute.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_joystick_status
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the result of the last attempted calibration of the left removable controller's joystick.
Values are unknown, success, failure.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_tirgger
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This initiates or halts calibration of the left removable controller's trigger.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_gyro_trigger
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the left_handle/calibrate_trigger attribute.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_trigger_status
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the result of the last attempted calibration of the left removable controller's trigger.
Values are unknown, success, failure.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/firmware_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the left removable controller's firmware version.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/hardware_generation
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the hardware generation of the left removable controller.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/hardware_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the hardware version of the left removable controller.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/imu_bypass_enabled
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling or disabling the IMU bypass function of the left removable controller.
Values are true or false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/imu_bypass_enabled_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the left_handle/imu_bypass_enabled attribute.
Values are true or false.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/imu_enabled
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling or disabling the IMU of the left removable controller.
Values are true or false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/imu_enabled_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the left_handle/imu_enabled attribute.
Values are true or false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/product_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the product version of the left removable controller.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/protocol_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the protocol version of the left removable controller.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/reset
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: Resets the left removable controller to factory defaults.
Writing 1 to this path initiates.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/rumble_mode
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls setting the response behavior for rumble events for the left removable controller.
Values are fps, racing, standarg, spg, rpg.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/rumble_mode_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the left_handle/rumble_mode attribute.
Values are fps, racing, standarg, spg, rpg.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/rumble_notification
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling haptic rumble events for the left removable controller.
Values are true, false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/rumble_notification_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the left_handle/rumble_notification attribute.
Values are true, false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/mode
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the operating mode of the built-in controller.
Values are xinput or dinput.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/mode_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the mode attribute.
Values are xinput or dinput.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the behavior of built in chord combinations.
Values are windows or linux.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the os_mode attribute.
Values are windows or linux.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/product_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the product version of the internal MCU.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/protocol_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the protocol version of the internal MCU.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/reset_mcu
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: Resets the internal MCU to factory defaults.
Writing 1 to this path initiates.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/auto_sleep_time
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the sleep timer due to inactivity for the right removable controller.
Values are 0-255.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/auto_sleep_time_range
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the right_handle/auto_sleep_time attribute.
Values are 0-255.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_gyro
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This initiates or halts calibration of the right removable controller's IMU.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_gyro_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the right_handle/calibrate_gyro attribute.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_gyro_status
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the result of the last attempted calibration of the right removable controller's IMU.
Values are unknown, success, failure.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_joystick
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This initiates or halts calibration of the right removable controller's joystick.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_joystick_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the right_handle/calibrate_jotstick attribute.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_joystick_status
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the result of the last attempted calibration of the right removable controller's joystick.
Values are unknown, success, failure.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_tirgger
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This initiates or halts calibration of the right removable controller's trigger.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_gyro_trigger
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the right_handle/calibrate_trigger attribute.
Values are start, stop.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_trigger_status
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the result of the last attempted calibration of the right removable controller's trigger.
Values are unknown, success, failure.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/firmware_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the right removable controller's firmware version.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/hardware_generation
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the hardware generation of the right removable controller.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/hardware_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the hardware version of the right removable controller.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/imu_bypass_enabled
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling or disabling the IMU bypass function of the right removable controller.
Values are true or false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/imu_bypass_enabled_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the right_handle/imu_bypass_enabled attribute.
Values are true or false.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/imu_enabled
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling or disabling the IMU of the right removable controller.
Values are true or false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/imu_enabled_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the right_handle/imu_enabled attribute.
Values are true or false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/product_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the product version of the right removable controller.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/protocol_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the protocol version of the right removable controller.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/reset
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: Resets the right removable controller to factory defaults.
Writing 1 to this path initiates.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/rumble_mode
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls setting the response behavior for rumble events for the right removable controller.
Values are fps, racing, standarg, spg, rpg.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/rumble_mode_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the right_handle/rumble_mode attribute.
Values are fps, racing, standarg, spg, rpg.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/rumble_notification
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling haptic rumble events for the right removable controller.
Values are true, false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/rumble_notification_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the right_handle/rumble_notification attribute.
Values are true, false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/rumble_intensity
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls setting the rumble intensity for both removable controllers.
Values are off, low, medium, high.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/rumble_intensity_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the rumble_intensity attribute.
Values are off, low, medium, high.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling or disabling the touchpad.
Values are true, false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the touchpad/enabled attribute.
Values are true, false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/vibration_enabled
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling haptic rumble events for the touchpad.
Values are true, false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/vibration_enabled_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the touchpad/vibration_enabled attribute.
Values are true, false.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/vibration_intensity
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls setting the intensity of the touchpad haptics.
Values are off, low, medium, high.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/vibration_intensity_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the touchpad/vibration_intensity attribute.
Values are off, low, medium, high.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/tx_dongle/firmware_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the firmware version of the internal wireless transmission dongle.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/tx_dongle/hardware_generation
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the hardware generation of the internal wireless transmission dongle.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/tx_dongle/hardware_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the hardware version of the internal wireless transmission dongle.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/tx_dongle/product_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the product version of the internal wireless transmission dongle.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/tx_dongle/protocol_version
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the protocol version of the internal wireless transmission dongle.
Applies to Lenovo Legion Go and Go 2 line of handheld devices.

304
Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s Normal file
View File

@ -0,0 +1,304 @@
What: /sys/class/leds/go_s:rgb:joystick_rings/effect
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the display effect of the RGB interface.
Values are monocolor, breathe, chroma, or rainbow.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/class/leds/go_s:rgb:joystick_rings/effect_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the effect attribute.
Values are monocolor, breathe, chroma, or rainbow.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/class/leds/go_s:rgb:joystick_rings/enabled
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling or disabling the RGB interface.
Values are true or false.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/class/leds/go_s:rgb:joystick_rings/enabled_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the enabled attribute.
Values are true or false.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/class/leds/go_s:rgb:joystick_rings/mode
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the operating mode of the RGB interface.
Values are dynamic or custom. Custom allows setting the RGB effect and color.
Dynamic is a Windows mode for syncing Lenovo RGB interfaces not currently
supported under Linux.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/class/leds/go_s:rgb:joystick_rings/mode_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the mode attribute.
Values are dynamic or custom.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/class/leds/go_s:rgb:joystick_rings/profile
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls selecting the configured RGB profile.
Values are 1-3.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/class/leds/go_s:rgb:joystick_rings/profile_range
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the profile attribute.
Values are 1-3.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/class/leds/go_s:rgb:joystick_rings/speed
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the change rate for the breathe, chroma, and rainbow effects.
Values are 0-100.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/class/leds/go_s:rgb:joystick_rings/speed_range
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the speed attribute.
Values are 0-100.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/auto_sleep_time
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the sleep timer due to inactivity for the built-in controller.
Values are 0-255.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/auto_sleep_time_range
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the gamepad/auto_sleep_time attribute.
Values are 0-255.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/dpad_mode
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the operating mode of the built-in controllers D-pad.
Values are 4-way or 8-way.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/dpad_mode_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the gamepad/dpad_mode attribute.
Values are 4-way or 8-way.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/mode
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the operating mode of the built-in controller.
Values are xinput or dinput.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/mode_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the gamepad/mode attribute.
Values are xinput or dinput.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/poll_rate
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls the poll rate in Hz of the built-in controller.
Values are 125, 250, 500, or 1000.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/poll_rate_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the gamepad/poll_rate attribute.
Values are 125, 250, 500, or 1000.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/imu/bypass_enabled
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling or disabling the IMU bypass function. When enabled the IMU data is directly reported to the OS through
an HIDRAW interface.
Values are true or false.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/imu/bypass_enabled_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the imu/bypass_enabled attribute.
Values are true or false.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/imu/manufacturer
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the manufacturer of the intertial measurment unit.
Values are Bosch or ST.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/imu/sensor_enabled
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling or disabling the IMU.
Values are true, false, or wake-2s.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/imu/sensor_enabled_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the imu/sensor_enabled attribute.
Values are true, false, or wake-2s.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/mcu_id
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the MCU Identification Number
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/mouse/step
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls which value is used for the mouse sensitivity.
Values are 1-127.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/mouse/step_range
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the mouse/step attribute.
Values are 1-127.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls which value is used for the touchpads operating mode.
Values are windows or linux.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the os_mode attribute.
Values are windows or linux.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls enabling or disabling the built-in touchpad.
Values are true or false.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the touchpad/enabled attribute.
Values are true or false.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/linux_mode
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls behavior of the touchpad events when os_mode is set to linux.
Values are absolute or relative.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/linux_mode_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the touchpad/linux_mode attribute.
Values are absolute or relative.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/windows_mode
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This controls behavior of the touchpad events when os_mode is set to windows.
Values are absolute or relative.
Applies to Lenovo Legion Go S line of handheld devices.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/windows_mode_index
Date: April 2026
Contact: linux-input@vger.kernel.org
Description: This displays the available options for the touchpad/windows_mode attribute.
Values are absolute or relative.
Applies to Lenovo Legion Go S line of handheld devices.

23
Documentation/ABI/testing/sysfs-driver-ufs
View File

@ -1768,3 +1768,26 @@ Description:
==================== ===========================
The attribute is read only.
What: /sys/bus/platform/drivers/ufshcd/*/dme_qos_notification
What: /sys/bus/platform/devices/*.ufs/dme_qos_notification
Date: March 2026
Contact: Can Guo <can.guo@oss.qualcomm.com>
Description:
This attribute reports and clears pending DME (Device Management
Entity) Quality of Service (QoS) notifications. This attribute
is a bitfield with the following bit assignments:
Bit Description
=== ======================================
0 DME QoS Monitor has been reset by host
1 QoS from TX is detected
2 QoS from RX is detected
3 QoS from PA_INIT is detected
Reading this attribute returns the pending DME QoS notification
bits. Writing '0' to this attribute clears pending DME QoS
notification bits. Writing any non-zero value is invalid and
will be rejected.
The attribute is read/write.

27
Documentation/ABI/testing/sysfs-driver-uniwill-laptop
View File

@ -51,3 +51,30 @@ Description:
Reading this file returns the current status of the breathing animation
functionality.
What: /sys/bus/platform/devices/INOU0000:XX/ctgp_offset
Date: January 2026
KernelVersion: 7.0
Contact: Werner Sembach <wse@tuxedocomputers.com>
Description:
Allows userspace applications to set the configurable TGP offset on top of the base
TGP. Base TGP and max TGP and therefore the max cTGP offset are device specific.
Note that setting the maximum cTGP leaves no window open for Dynamic Boost as
Dynamic Boost also can not go over max TGP. Setting the cTGP to maximum is
effectively disabling Dynamic Boost and telling the device to always prioritize the
GPU over the CPU.
Reading this file returns the current configurable TGP offset.
What: /sys/bus/platform/devices/INOU0000:XX/usb_c_power_priority
Date: February 2026
KernelVersion: 7.1
Contact: Werner Sembach <wse@tuxedocomputers.com>
Description:
Allows userspace applications to choose the USB-C power distribution profile between
one that offers a bigger share of the power to the battery and one that offers more
of it to the CPU. Writing "charging"/"performance" into this file selects the
respective profile.
Reading this file returns the profile names with the currently active one in
brackets.

6
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@ -407,6 +407,12 @@ Contact: "Hridya Valsaraju" <hridya@google.com>
Description: Average number of valid blocks.
Available when CONFIG_F2FS_STAT_FS=y.
What: /sys/fs/f2fs/<disk>/defrag_blocks
Date: February 2026
Contact: "Jinbao Liu" <liujinbao1@xiaomi.com>
Description: Number of blocks moved by defragment.
Available when CONFIG_F2FS_STAT_FS=y.
What: /sys/fs/f2fs/<disk>/mounted_time_sec
Date: February 2020
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>

6
Documentation/admin-guide/cgroup-v1/memcg_test.rst
View File

@ -47,21 +47,19 @@ Please note that implementation details can be changed.
Called when swp_entry's refcnt goes down to 0. A charge against swap
disappears.
3. charge-commit-cancel
3. charge-commit
=======================
Memcg pages are charged in two steps:
- mem_cgroup_try_charge()
- mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
- commit_charge()
At try_charge(), there are no flags to say "this page is charged".
at this point, usage += PAGE_SIZE.
At commit(), the page is associated with the memcg.
At cancel(), simply usage -= PAGE_SIZE.
Under below explanation, we assume CONFIG_SWAP=y.
4. Anonymous

2
Documentation/admin-guide/cgroup-v2.rst
View File

@ -220,7 +220,7 @@ cgroup v2 currently supports the following mount options.
memory_hugetlb_accounting
Count HugeTLB memory usage towards the cgroup's overall
memory usage for the memory controller (for the purpose of
statistics reporting and memory protetion). This is a new
statistics reporting and memory protection). This is a new
behavior that could regress existing setups, so it must be
explicitly opted in with this mount option.

39
Documentation/admin-guide/kernel-parameters.txt
View File

@ -6,7 +6,6 @@
APPARMOR AppArmor support is enabled.
ARM ARM architecture is enabled.
ARM64 ARM64 architecture is enabled.
AX25 Appropriate AX.25 support is enabled.
CLK Common clock infrastructure is enabled.
CMA Contiguous Memory Area support is enabled.
DRM Direct Rendering Management support is enabled.
@ -633,23 +632,6 @@ Kernel parameters
1 - Enable the BAU.
unset - Disable the BAU.
baycom_epp= [HW,AX25]
Format: <io>,<mode>
baycom_par= [HW,AX25] BayCom Parallel Port AX.25 Modem
Format: <io>,<mode>
See header of drivers/net/hamradio/baycom_par.c.
baycom_ser_fdx= [HW,AX25]
BayCom Serial Port AX.25 Modem (Full Duplex Mode)
Format: <io>,<irq>,<mode>[,<baud>]
See header of drivers/net/hamradio/baycom_ser_fdx.c.
baycom_ser_hdx= [HW,AX25]
BayCom Serial Port AX.25 Modem (Half Duplex Mode)
Format: <io>,<irq>,<mode>
See header of drivers/net/hamradio/baycom_ser_hdx.c.
bdev_allow_write_mounted=
Format: <bool>
Control the ability to open a mounted block device
@ -2410,23 +2392,6 @@ Kernel parameters
[IMA] Define a custom template format.
Format: { "field1|...|fieldN" }
ima.ahash_minsize= [IMA] Minimum file size for asynchronous hash usage
Format: <min_file_size>
Set the minimal file size for using asynchronous hash.
If left unspecified, ahash usage is disabled.
ahash performance varies for different data sizes on
different crypto accelerators. This option can be used
to achieve the best performance for a particular HW.
ima.ahash_bufsize= [IMA] Asynchronous hash buffer size
Format: <bufsize>
Set hashing buffer size. Default: 4k.
ahash performance varies for different chunk sizes on
different crypto accelerators. This option can be used
to achieve best performance for particular HW.
ima= [IMA] Enable or disable IMA
Format: { "off" | "on" }
Default: "on"
@ -3264,8 +3229,8 @@ Kernel parameters
for the host. To force nVHE on VHE hardware, add
"arm64_sw.hvhe=0 id_aa64mmfr1.vh=0" to the
command-line.
"nested" is experimental and should be used with
extreme caution.
"nested" and "protected" are experimental and should be
used with extreme caution.
kvm-arm.vgic_v3_group0_trap=
[KVM,ARM,EARLY] Trap guest accesses to GICv3 group-0

21
Documentation/admin-guide/laptops/thinkpad-acpi.rst
View File

@ -1522,6 +1522,27 @@ Currently 2 antenna types are supported as mentioned below:
The property is read-only. If the platform doesn't have support the sysfs
class is not created.
doubletap_enable
----------------
sysfs: doubletap_enable
Controls whether TrackPoint doubletap events are filtered out. Doubletap is a
feature where quickly tapping the TrackPoint twice triggers a special function key event.
The available commands are::
cat /sys/devices/platform/thinkpad_acpi/doubletap_enable
echo 1 | sudo tee /sys/devices/platform/thinkpad_acpi/doubletap_enable
echo 0 | sudo tee /sys/devices/platform/thinkpad_acpi/doubletap_enable
Values:
* 1 - doubletap events are processed (default)
* 0 - doubletap events are filtered out (ignored)
This setting can also be toggled via the Fn+doubletap hotkey.
Auxmac
------

12
Documentation/admin-guide/laptops/uniwill-laptop.rst
View File

@ -50,6 +50,10 @@ between 1 and 100 percent are supported.
Additionally the driver signals the presence of battery charging issues through the standard
``health`` power supply sysfs attribute.
It also lets you set whether a USB-C power source should prioritise charging the battery or
delivering immediate power to the cpu. See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for
details.
Lightbar
--------
@ -58,3 +62,11 @@ LED class device. The default name of this LED class device is ``uniwill:multico
See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details on how to control the various
animation modes of the lightbar.
Configurable TGP
----------------
The ``uniwill-laptop`` driver allows to set the configurable TGP for devices with NVIDIA GPUs that
allow it.
See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details.

142
Documentation/admin-guide/lockup-watchdogs.rst
View File

@ -16,7 +16,7 @@ details), and a compile option, "BOOTPARAM_SOFTLOCKUP_PANIC", are
provided for this.
A 'hardlockup' is defined as a bug that causes the CPU to loop in
kernel mode for more than 10 seconds (see "Implementation" below for
kernel mode for several seconds (see "Implementation" below for
details), without letting other interrupts have a chance to run.
Similarly to the softlockup case, the current stack trace is displayed
upon detection and the system will stay locked up unless the default
@ -30,39 +30,135 @@ timeout is set through the confusingly named "kernel.panic" sysctl),
to cause the system to reboot automatically after a specified amount
of time.
Configuration
=============
A kernel knob is provided that allows administrators to configure
this period. The "watchdog_thresh" parameter (default 10 seconds)
controls the threshold. The right value for a particular environment
is a trade-off between fast response to lockups and detection overhead.
Implementation
==============
The soft and hard lockup detectors are built on top of the hrtimer and
perf subsystems, respectively. A direct consequence of this is that,
in principle, they should work in any architecture where these
subsystems are present.
The soft and hard lockup detectors are built around an hrtimer.
In addition, the softlockup detector regularly schedules a job, and
the hard lockup detector might use Perf/NMI events on architectures
that support it.
A periodic hrtimer runs to generate interrupts and kick the watchdog
job. An NMI perf event is generated every "watchdog_thresh"
(compile-time initialized to 10 and configurable through sysctl of the
same name) seconds to check for hardlockups. If any CPU in the system
does not receive any hrtimer interrupt during that time the
'hardlockup detector' (the handler for the NMI perf event) will
generate a kernel warning or call panic, depending on the
configuration.
Frequency and Heartbeats
------------------------
The watchdog job runs in a stop scheduling thread that updates a
timestamp every time it is scheduled. If that timestamp is not updated
for 2*watchdog_thresh seconds (the softlockup threshold) the
The core of the detectors is an hrtimer. It serves multiple purposes:
- schedules watchdog job for the softlockup detector
- bumps the interrupt counter for hardlockup detectors (heartbeat)
- detects softlockups
- detects hardlockups in Buddy mode
The period of this hrtimer is 2*watchdog_thresh/5, which is 4 seconds
by default. The hrtimer has two or three chances to generate an interrupt
(heartbeat) before the hardlockup detector kicks in.
Softlockup Detector
-------------------
The watchdog job is scheduled by the hrtimer and runs in a stop scheduling
thread. It updates a timestamp every time it is scheduled. If that timestamp
is not updated for 2*watchdog_thresh seconds (the softlockup threshold) the
'softlockup detector' (coded inside the hrtimer callback function)
will dump useful debug information to the system log, after which it
will call panic if it was instructed to do so or resume execution of
other kernel code.
The period of the hrtimer is 2*watchdog_thresh/5, which means it has
two or three chances to generate an interrupt before the hardlockup
detector kicks in.
Hardlockup Detector (NMI/Perf)
------------------------------
As explained above, a kernel knob is provided that allows
administrators to configure the period of the hrtimer and the perf
event. The right value for a particular environment is a trade-off
between fast response to lockups and detection overhead.
On architectures that support NMI (Non-Maskable Interrupt) perf events,
a periodic NMI is generated every "watchdog_thresh" seconds.
If any CPU in the system does not receive any hrtimer interrupt
(heartbeat) during the "watchdog_thresh" window, the 'hardlockup
detector' (the handler for the NMI perf event) will generate a kernel
warning or call panic.
**Detection Overhead (NMI):**
The time to detect a lockup can vary depending on when the lockup
occurs relative to the NMI check window. Examples below assume a watchdog_thresh of 10.
* **Best Case:** The lockup occurs just before the first heartbeat is
due. The detector will notice the missing hrtimer interrupt almost
immediately during the next check.
::
Time 100.0: cpu 1 heartbeat
Time 100.1: hardlockup_check, cpu1 stores its state
Time 103.9: Hard Lockup on cpu1
Time 104.0: cpu 1 heartbeat never comes
Time 110.1: hardlockup_check, cpu1 checks the state again, should be the same, declares lockup
Time to detection: ~6 seconds
* **Worst Case:** The lockup occurs shortly after a valid interrupt
(heartbeat) which itself happened just after the NMI check. The next
NMI check sees that the interrupt count has changed (due to that one
heartbeat), assumes the CPU is healthy, and resets the baseline. The
lockup is only detected at the subsequent check.
::
Time 100.0: hardlockup_check, cpu1 stores its state
Time 100.1: cpu 1 heartbeat
Time 100.2: Hard Lockup on cpu1
Time 110.0: hardlockup_check, cpu1 stores its state (misses lockup as state changed)
Time 120.0: hardlockup_check, cpu1 checks the state again, should be the same, declares lockup
Time to detection: ~20 seconds
Hardlockup Detector (Buddy)
---------------------------
On architectures or configurations where NMI perf events are not
available (or disabled), the kernel may use the "buddy" hardlockup
detector. This mechanism requires SMP (Symmetric Multi-Processing).
In this mode, each CPU is assigned a "buddy" CPU to monitor. The
monitoring CPU runs its own hrtimer (the same one used for softlockup
detection) and checks if the buddy CPU's hrtimer interrupt count has
increased.
To ensure timeliness and avoid false positives, the buddy system performs
checks at every hrtimer interval (2*watchdog_thresh/5, which is 4 seconds
by default). It uses a missed-interrupt threshold of 3. If the buddy's
interrupt count has not changed for 3 consecutive checks, it is assumed
that the buddy CPU is hardlocked (interrupts disabled). The monitoring
CPU will then trigger the hardlockup response (warning or panic).
**Detection Overhead (Buddy):**
With a default check interval of 4 seconds (watchdog_thresh = 10):
* **Best case:** Lockup occurs just before a check.
Detected in ~8s (0s till 1st check + 4s till 2nd + 4s till 3rd).
* **Worst case:** Lockup occurs just after a check.
Detected in ~12s (4s till 1st check + 4s till 2nd + 4s till 3rd).
**Limitations of the Buddy Detector:**
1. **All-CPU Lockup:** If all CPUs lock up simultaneously, the buddy
detector cannot detect the condition because the monitoring CPUs
are also frozen.
2. **Stack Traces:** Unlike the NMI detector, the buddy detector
cannot directly interrupt the locked CPU to grab a stack trace.
It relies on architecture-specific mechanisms (like NMI backtrace
support) to try and retrieve the status of the locked CPU. If
such support is missing, the log may only show that a lockup
occurred without providing the locked CPU's stack.
Watchdog Core Exclusion
=======================
By default, the watchdog runs on all online cores. However, on a
kernel configured with NO_HZ_FULL, by default the watchdog runs only

4
Documentation/admin-guide/mm/damon/lru_sort.rst
View File

@ -79,6 +79,10 @@ of parametrs except ``enabled`` again. Once the re-reading is done, this
parameter is set as ``N``. If invalid parameters are found while the
re-reading, DAMON_LRU_SORT will be disabled.
Once ``Y`` is written to this parameter, the user must not write to any
parameters until reading ``commit_inputs`` again returns ``N``. If users
violate this rule, the kernel may exhibit undefined behavior.
active_mem_bp
-------------

4
Documentation/admin-guide/mm/damon/reclaim.rst
View File

@ -71,6 +71,10 @@ of parametrs except ``enabled`` again. Once the re-reading is done, this
parameter is set as ``N``. If invalid parameters are found while the
re-reading, DAMON_RECLAIM will be disabled.
Once ``Y`` is written to this parameter, the user must not write to any
parameters until reading ``commit_inputs`` again returns ``N``. If users
violate this rule, the kernel may exhibit undefined behavior.
min_age
-------

41
Documentation/admin-guide/mm/kho.rst
View File

@ -42,6 +42,45 @@ 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.
Kexec Metadata
==============
KHO automatically tracks metadata about the kexec chain, passing information
about the previous kernel to the next kernel. This feature helps diagnose
bugs that only reproduce when kexecing from specific kernel versions.
On each KHO kexec, the kernel logs the previous kernel's version and the
number of kexec reboots since the last cold boot::
[ 0.000000] KHO: exec from: 6.19.0-rc4-next-20260107 (count 1)
The metadata includes:
``previous_release``
The kernel version string (from ``uname -r``) of the kernel that
initiated the kexec.
``kexec_count``
The number of kexec boots since the last cold boot. On cold boot,
this counter starts at 0 and increments with each kexec. This helps
identify issues that only manifest after multiple consecutive kexec
reboots.
Use Cases
---------
This metadata is particularly useful for debugging kexec transition bugs,
where a buggy kernel kexecs into a new kernel and the bug manifests only
in the second kernel. Examples of such bugs include:
- Memory corruption from the previous kernel affecting the new kernel
- Incorrect hardware state left by the previous kernel
- Firmware/ACPI state issues that only appear in kexec scenarios
At scale, correlating crashes to the previous kernel version enables
faster root cause analysis when issues only occur in specific kernel
transition scenarios.
debugfs Interfaces
==================
@ -80,5 +119,5 @@ stabilized.
it finished to interpret their metadata.
``/sys/kernel/debug/kho/in/sub_fdts/``
Similar to ``kho/out/sub_fdts/``, but contains sub FDT blobs
Similar to ``kho/out/sub_fdts/``, but contains sub blobs
of KHO producers passed from the old kernel.

30
Documentation/admin-guide/nfs/pnfs-block-server.rst
View File

@ -40,3 +40,33 @@ how to translate the device into a serial number from SCSI EVPD 0x80::
echo "fencing client ${CLIENT} serial ${EVPD}" >> /var/log/pnfsd-fence.log
EOF
If the nfsd server needs to fence a non-responding client and the
fencing operation fails, the server logs a warning message in the
system log with the following format:
FENCE failed client[IP_address] clid[#n] device[dev_name]
where:
- IP_address: refers to the IP address of the affected client.
- #n: indicates the unique client identifier.
- dev_name: specifies the name of the block device related
to the fencing attempt.
The server will repeatedly retry the operation indefinitely. During
this time, access to the affected file is restricted for all other
clients. This is to prevent potential data corruption if multiple
clients access the same file simultaneously.
To restore access to the affected file for other clients, the admin
needs to take the following actions:
- shutdown or power off the client being fenced.
- manually expire the client to release all its state on the server::
echo 'expire' > /proc/fs/nfsd/clients/clid/ctl
where:
- clid: is the unique client identifier displayed in the system log.

31
Documentation/admin-guide/nfs/pnfs-scsi-server.rst
View File

@ -22,3 +22,34 @@ option and the underlying SCSI device support persistent reservations.
On the client make sure the kernel has the CONFIG_PNFS_BLOCK option
enabled, and the file system is mounted using the NFSv4.1 protocol
version (mount -o vers=4.1).
If the nfsd server needs to fence a non-responding client and the
fencing operation fails, the server logs a warning message in the
system log with the following format:
FENCE failed client[IP_address] clid[#n] device[dev_name]
where:
- IP_address: refers to the IP address of the affected client.
- #n: indicates the unique client identifier.
- dev_name: specifies the name of the block device related
to the fencing attempt.
The server will repeatedly retry the operation indefinitely. During
this time, access to the affected file is restricted for all other
clients. This is to prevent potential data corruption if multiple
clients access the same file simultaneously.
To restore access to the affected file for other clients, the admin
needs to take the following actions:
- shutdown or power off the client being fenced.
- manually expire the client to release all its state on the server::
echo 'expire' > /proc/fs/nfsd/clients/clid/ctl
where:
- clid: is the unique client identifier displayed in the system log.

3
Documentation/admin-guide/sysctl/kernel.rst
View File

@ -418,7 +418,8 @@ hung_task_detect_count
======================
Indicates the total number of tasks that have been detected as hung since
the system boot.
the system boot or since the counter was reset. The counter is zeroed when
a value of 0 is written.
This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled.

2
Documentation/arch/arm64/silicon-errata.rst
View File

@ -202,6 +202,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V3AE | #3312417 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | C1-Pro | #4193714 | ARM64_ERRATUM_4193714 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-500 | #841119,826419 | ARM_SMMU_MMU_500_CPRE_ERRATA|
| | | #562869,1047329 | |
+----------------+-----------------+-----------------+-----------------------------+

8
Documentation/arch/riscv/cmodx.rst
View File

@ -21,13 +21,13 @@ call at each patchable function entry, and patches it dynamically at runtime to
enable or disable the redirection. In the case of RISC-V, 2 instructions,
AUIPC + JALR, are required to compose a function call. However, it is impossible
to patch 2 instructions and expect that a concurrent read-side executes them
without a race condition. This series makes atmoic code patching possible in
without a race condition. This series makes atomic code patching possible in
RISC-V ftrace. Kernel preemption makes things even worse as it allows the old
state to persist across the patching process with stop_machine().
In order to get rid of stop_machine() and run dynamic ftrace with full kernel
preemption, we partially initialize each patchable function entry at boot-time,
setting the first instruction to AUIPC, and the second to NOP. Now, atmoic
setting the first instruction to AUIPC, and the second to NOP. Now, atomic
patching is possible because the kernel only has to update one instruction.
According to Ziccif, as long as an instruction is naturally aligned, the ISA
guarantee an atomic update.
@ -36,8 +36,8 @@ By fixing down the first instruction, AUIPC, the range of the ftrace trampoline
is limited to +-2K from the predetermined target, ftrace_caller, due to the lack
of immediate encoding space in RISC-V. To address the issue, we introduce
CALL_OPS, where an 8B naturally align metadata is added in front of each
pacthable function. The metadata is resolved at the first trampoline, then the
execution can be derect to another custom trampoline.
patchable function. The metadata is resolved at the first trampoline, then the
execution can be directed to another custom trampoline.
CMODX in the User Space
-----------------------

2
Documentation/arch/riscv/zicfilp.rst
View File

@ -78,7 +78,7 @@ the program.
Per-task indirect branch tracking state can be monitored and
controlled via the :c:macro:`PR_GET_CFI` and :c:macro:`PR_SET_CFI`
``prctl()` arguments (respectively), by supplying
``prctl()`` arguments (respectively), by supplying
:c:macro:`PR_CFI_BRANCH_LANDING_PADS` as the second argument. These
are architecture-agnostic, and will return -EINVAL if the underlying
functionality is not supported.

151
Documentation/arch/s390/pci.rst
View File

@ -6,6 +6,7 @@ S/390 PCI
Authors:
- Pierre Morel
- Niklas Schnelle
Copyright, IBM Corp. 2020
@ -27,14 +28,16 @@ Command line parameters
debugfs entries
---------------
The S/390 debug feature (s390dbf) generates views to hold various debug results in sysfs directories of the form:
The S/390 debug feature (s390dbf) generates views to hold various debug results
in sysfs directories of the form:
* /sys/kernel/debug/s390dbf/pci_*/
For example:
- /sys/kernel/debug/s390dbf/pci_msg/sprintf
Holds messages from the processing of PCI events, like machine check handling
holds messages from the processing of PCI events, like machine check handling
and setting of global functionality, like UID checking.
Change the level of logging to be more or less verbose by piping
@ -47,87 +50,141 @@ Sysfs entries
Entries specific to zPCI functions and entries that hold zPCI information.
* /sys/bus/pci/slots/XXXXXXXX
* /sys/bus/pci/slots/XXXXXXXX:
The slot entries are set up using the function identifier (FID) of the
PCI function. The format depicted as XXXXXXXX above is 8 hexadecimal digits
with 0 padding and lower case hexadecimal digits.
The slot entries are set up using the function identifier (FID) of the PCI
function as slot name. The format depicted as XXXXXXXX above is 8 hexadecimal
digits with 0 padding and lower case hexadecimal digits.
- /sys/bus/pci/slots/XXXXXXXX/power
In addition to using the FID as the name of the slot, the slot directory
also contains the following s390-specific slot attributes.
- uid:
The User-defined identifier (UID) of the function which may be configured
by this slot. See also the corresponding attribute of the device.
A physical function that currently supports a virtual function cannot be
powered off until all virtual functions are removed with:
echo 0 > /sys/bus/pci/devices/XXXX:XX:XX.X/sriov_numvf
echo 0 > /sys/bus/pci/devices/DDDD:BB:dd.f/sriov_numvf
* /sys/bus/pci/devices/XXXX:XX:XX.X/
* /sys/bus/pci/devices/DDDD:BB:dd.f/:
- function_id
A zPCI function identifier that uniquely identifies the function in the Z server.
- function_id:
The zPCI function identifier (FID) is a 32-bit hexadecimal value that
uniquely identifies the PCI function. Unless the hypervisor provides
a virtual FID e.g. on KVM this identifier is unique across the machine even
between different partitions.
- function_handle
Low-level identifier used for a configured PCI function.
It might be useful for debugging.
- function_handle:
This 32-bit hexadecimal value is a low-level identifier used for a PCI
function. Note that the function handle may be changed and become invalid
on PCI events and when enabling/disabling the PCI function.
- pchid
Model-dependent location of the I/O adapter.
- pchid:
This 16-bit hexadecimal value encodes a model-dependent location for
the PCI function.
- pfgid
PCI function group ID, functions that share identical functionality
- pfgid:
PCI function group ID; functions that share identical functionality
use a common identifier.
A PCI group defines interrupts, IOMMU, IOTLB, and DMA specifics.
- vfn
- vfn:
The virtual function number, from 1 to N for virtual functions,
0 for physical functions.
- pft
The PCI function type
- pft:
The PCI function type is an s390-specific type attribute. It indicates
a more general, usage oriented, type than PCI Specification
class/vendor/device identifiers. That is PCI functions with the same pft
value may be backed by different hardware implementations. At the same time
apart from unclassified functions (pft is 0x00) the same pft value
generally implies a similar usage model. At the same time the same
PCI hardware device may appear with different pft values when in a
different usage model. For example NETD and NETH VFs may be implemented
by the same PCI hardware device but in NETD the parent Physical Function
is user managed while with NETH it is platform managed.
- port
The port corresponds to the physical port the function is attached to.
It also gives an indication of the physical function a virtual function
is attached to.
Currently the following PFT values are defined:
- uid
The user identifier (UID) may be defined as part of the machine
configuration or the z/VM or KVM guest configuration. If the accompanying
uid_is_unique attribute is 1 the platform guarantees that the UID is unique
within that instance and no devices with the same UID can be attached
during the lifetime of the system.
- 0x00 (UNC): Unclassified
- 0x02 (ROCE): RoCE Express
- 0x05 (ISM): Internal Shared Memory
- 0x0a (ROC2): RoCE Express 2
- 0x0b (NVMe): NVMe
- 0x0c (NETH): Network Express hybrid
- 0x0d (CNW): Cloud Network Adapter
- 0x0f (NETD): Network Express direct
- uid_is_unique
Indicates whether the user identifier (UID) is guaranteed to be and remain
unique within this Linux instance.
- port:
The port is a decimal value corresponding to the physical port the function
is attached to. Virtual Functions (VFs) share the port with their parent
Physical Function (PF). A value of 0 indicates that the port attribute is
not applicable for that PCI function type.
- pfip/segmentX
- uid:
The user-defined identifier (UID) for a PCI function is a 32-bit
hexadecimal value. It is defined on a per instance basis as part of the
partition, KVM guest, or z/VM guest configuration. If UID Checking is
enabled the platform ensures that the UID is unique within that instance
and no two PCI functions with the same UID will be visible to the instance.
Independent of this guarantee and unlike the function ID (FID) the UID may
be the same in different partitions within the same machine. This allows to
create PCI configurations in multiple partitions to be identical in the
UID-namespace.
- uid_is_unique:
A 0 or 1 flag indicating whether the user-defined identifier (UID) is
guaranteed to be and remain unique within this Linux instance. This
platform feature is called UID Checking.
- pfip/segmentX:
The segments determine the isolation of a function.
They correspond to the physical path to the function.
The more the segments are different, the more the functions are isolated.
- fidparm:
Contains an 8-bit-per-PCI function parameter field in hexadecimal provided
by the platform. The meaning of this field is PCI function type specific.
For NETH VFs a value of 0x01 indicates that the function supports
promiscuous mode.
* /sys/firmware/clp/uid_checking:
In addition to the per-device uid_is_unique attribute this presents a
global indication of whether UID Checking is enabled. This allows users
to check for UID Checking even when no PCI functions are configured.
Enumeration and hotplug
=======================
The PCI address consists of four parts: domain, bus, device and function,
and is of this form: DDDD:BB:dd.f
and is of this form: DDDD:BB:dd.f.
* When not using multi-functions (norid is set, or the firmware does not
support multi-functions):
* For a PCI function for which the platform does not expose the RID, the
pci=norid kernel parameter is used, or a so-called isolated Virtual Function
which does have RID information but is used without its parent Physical
Function being part of the same PCI configuration:
- There is only one function per domain.
- The domain is set from the zPCI function's UID as defined during the
LPAR creation.
- The domain is set from the zPCI function's UID if UID Checking is on;
otherwise the domain ID is generated dynamically and is not stable
across reboots or hot plug.
* When using multi-functions (norid parameter is not set),
zPCI functions are addressed differently:
* For a PCI function for which the platform exposes the RID and which
is not an Isolated Virtual Function:
- There is still only one bus per domain.
- There can be up to 256 functions per bus.
- There can be up to 256 PCI functions per bus.
- The domain part of the address of all functions for
a multi-Function device is set from the zPCI function's UID as defined
in the LPAR creation for the function zero.
- The domain part of the address of all functions within the same topology is
that of the configured PCI function with the lowest devfn within that
topology.
- New functions will only be ready for use after the function zero
(the function with devfn 0) has been enumerated.
- Virtual Functions generated by an SR-IOV capable Physical Function only
become visible once SR-IOV is enabled.

36
Documentation/arch/x86/tdx.rst
View File

@ -60,44 +60,18 @@ Besides initializing the TDX module, a per-cpu initialization SEAMCALL
must be done on one cpu before any other SEAMCALLs can be made on that
cpu.
The kernel provides two functions, tdx_enable() and tdx_cpu_enable() to
allow the user of TDX to enable the TDX module and enable TDX on local
cpu respectively.
Making SEAMCALL requires VMXON has been done on that CPU. Currently only
KVM implements VMXON. For now both tdx_enable() and tdx_cpu_enable()
don't do VMXON internally (not trivial), but depends on the caller to
guarantee that.
To enable TDX, the caller of TDX should: 1) temporarily disable CPU
hotplug; 2) do VMXON and tdx_enable_cpu() on all online cpus; 3) call
tdx_enable(). For example::
cpus_read_lock();
on_each_cpu(vmxon_and_tdx_cpu_enable());
ret = tdx_enable();
cpus_read_unlock();
if (ret)
goto no_tdx;
// TDX is ready to use
And the caller of TDX must guarantee the tdx_cpu_enable() has been
successfully done on any cpu before it wants to run any other SEAMCALL.
A typical usage is do both VMXON and tdx_cpu_enable() in CPU hotplug
online callback, and refuse to online if tdx_cpu_enable() fails.
User can consult dmesg to see whether the TDX module has been initialized.
If the TDX module is initialized successfully, dmesg shows something
like below::
[..] virt/tdx: 262668 KBs allocated for PAMT
[..] virt/tdx: module initialized
[..] virt/tdx: TDX-Module initialized
If the TDX module failed to initialize, dmesg also shows it failed to
initialize::
[..] virt/tdx: module initialization failed ...
[..] virt/tdx: TDX-Module initialization failed ...
TDX Interaction to Other Kernel Components
------------------------------------------
@ -129,9 +103,9 @@ CPU Hotplug
~~~~~~~~~~~
TDX module requires the per-cpu initialization SEAMCALL must be done on
one cpu before any other SEAMCALLs can be made on that cpu. The kernel
provides tdx_cpu_enable() to let the user of TDX to do it when the user
wants to use a new cpu for TDX task.
one cpu before any other SEAMCALLs can be made on that cpu. The kernel,
via the CPU hotplug framework, performs the necessary initialization when
a CPU is first brought online.
TDX doesn't support physical (ACPI) CPU hotplug. During machine boot,
TDX verifies all boot-time present logical CPUs are TDX compatible before

14
Documentation/bpf/kfuncs.rst
View File

@ -462,6 +462,20 @@ In order to accommodate such requirements, the verifier will enforce strict
PTR_TO_BTF_ID type matching if two types have the exact same name, with one
being suffixed with ``___init``.
2.8 Accessing arena memory through kfunc arguments
--------------------------------------------------
A read or write at any address inside an arena does not oops the kernel.
Unallocated arena pages are lazily backed by a scratch page and the
access is reported through the program's BPF stream as an error. Only
the BPF program's correctness is affected; the kernel itself remains
intact.
The arena is followed by a ``GUARD_SZ / 2`` (32 KiB) guard region that
is also covered by this recovery. A kfunc handed an arena pointer may
therefore access up to ``GUARD_SZ / 2`` past it without bounds-checking
against the arena. Larger accesses must verify the range explicitly.
.. _BPF_kfunc_lifecycle_expectations:
3. kfunc lifecycle expectations

2
Documentation/crypto/index.rst
View File

@ -13,6 +13,7 @@ for cryptographic use cases, as well as programming examples.
:caption: Table of contents
:maxdepth: 2
libcrypto
intro
api-intro
architecture
@ -27,4 +28,3 @@ for cryptographic use cases, as well as programming examples.
descore-readme
device_drivers/index
krb5
sha3

19
Documentation/crypto/libcrypto-blockcipher.rst Normal file
View File

@ -0,0 +1,19 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
Block ciphers
=============
AES
---
Support for the AES block cipher.
.. kernel-doc:: include/crypto/aes.h
DES
---
Support for the DES block cipher. This algorithm is obsolete and is supported
only for backwards compatibility.
.. kernel-doc:: include/crypto/des.h

86
Documentation/crypto/libcrypto-hash.rst Normal file
View File

@ -0,0 +1,86 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
Hash functions, MACs, and XOFs
==============================
AES-CMAC and AES-XCBC-MAC
-------------------------
Support for the AES-CMAC and AES-XCBC-MAC message authentication codes.
.. kernel-doc:: include/crypto/aes-cbc-macs.h
BLAKE2b
-------
Support for the BLAKE2b cryptographic hash function.
.. kernel-doc:: include/crypto/blake2b.h
BLAKE2s
-------
Support for the BLAKE2s cryptographic hash function.
.. kernel-doc:: include/crypto/blake2s.h
GHASH and POLYVAL
-----------------
Support for the GHASH and POLYVAL universal hash functions. These algorithms
are used only as internal components of other algorithms.
.. kernel-doc:: include/crypto/gf128hash.h
MD5
---
Support for the MD5 cryptographic hash function and HMAC-MD5. This algorithm is
obsolete and is supported only for backwards compatibility.
.. kernel-doc:: include/crypto/md5.h
NH
--
Support for the NH universal hash function. This algorithm is used only as an
internal component of other algorithms.
.. kernel-doc:: include/crypto/nh.h
Poly1305
--------
Support for the Poly1305 universal hash function. This algorithm is used only
as an internal component of other algorithms.
.. kernel-doc:: include/crypto/poly1305.h
SHA-1
-----
Support for the SHA-1 cryptographic hash function and HMAC-SHA1. This algorithm
is obsolete and is supported only for backwards compatibility.
.. kernel-doc:: include/crypto/sha1.h
SHA-2
-----
Support for the SHA-2 family of cryptographic hash functions, including SHA-224,
SHA-256, SHA-384, and SHA-512. This also includes their corresponding HMACs:
HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512.
.. kernel-doc:: include/crypto/sha2.h
SHA-3
-----
The SHA-3 functions are documented in :ref:`sha3`.
SM3
---
Support for the SM3 cryptographic hash function.
.. kernel-doc:: include/crypto/sm3.h

11
Documentation/crypto/libcrypto-signature.rst Normal file
View File

@ -0,0 +1,11 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
Digital signature algorithms
============================
ML-DSA
------
Support for the ML-DSA digital signature algorithm.
.. kernel-doc:: include/crypto/mldsa.h

6
Documentation/crypto/libcrypto-utils.rst Normal file
View File

@ -0,0 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
Utility functions
=================
.. kernel-doc:: include/crypto/utils.h

165
Documentation/crypto/libcrypto.rst Normal file
View File

@ -0,0 +1,165 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
==============
Crypto library
==============
``lib/crypto/`` provides faster and easier access to cryptographic algorithms
than the traditional crypto API.
Each cryptographic algorithm is supported via a set of dedicated functions.
"Crypto agility", where needed, is left to calling code.
The crypto library functions are intended to be boring and straightforward, and
to follow familiar conventions. Their primary documentation is their (fairly
extensive) kernel-doc. This page just provides some extra high-level context.
Note that the crypto library isn't entirely new. ``lib/`` has contained some
crypto functions since 2005. Rather, it's just an approach that's been expanded
over time as it's been found to work well. It also largely just matches how the
kernel already does things elsewhere.
Scope and intended audience
===========================
The crypto library documentation is primarily meant for kernel developers who
need to use a particular cryptographic algorithm(s) in kernel code. For
example, "I just need to compute a SHA-256 hash." A secondary audience is
developers working on the crypto algorithm implementations themselves.
If you're looking for more general information about cryptography, like the
differences between the different crypto algorithms or how to select an
appropriate algorithm, you should refer to external sources which cover that
type of information much more comprehensively. If you need help selecting
algorithms for a new kernel feature that doesn't already have its algorithms
predefined, please reach out to ``linux-crypto@vger.kernel.org`` for advice.
Code organization
=================
- ``lib/crypto/*.c``: the crypto algorithm implementations
- ``lib/crypto/$(SRCARCH)/``: architecture-specific code for crypto algorithms.
It is here rather than somewhere in ``arch/`` partly because this allows
generic and architecture-optimized code to be easily built into a single
loadable module (when the algorithm is set to 'm' in the kconfig).
- ``lib/crypto/tests/``: KUnit tests for the crypto algorithms
- ``include/crypto/``: crypto headers, for both the crypto library and the
traditional crypto API
Generally, there is one kernel module per algorithm. Sometimes related
algorithms are grouped into one module. There is intentionally no common
framework, though there are some utility functions that multiple algorithms use.
Each algorithm module is controlled by a tristate kconfig symbol
``CRYPTO_LIB_$(ALGORITHM)``. As is the norm for library functions in the
kernel, these are hidden symbols which don't show up in the kconfig menu.
Instead, they are just selected by all the kconfig symbols that need them.
Many of the algorithms have multiple implementations: a generic implementation
and architecture-optimized implementation(s). Each module initialization
function, or initcall in the built-in case, automatically enables the best
implementation based on the available CPU features.
Note that the crypto library doesn't use the ``crypto/``,
``arch/$(SRCARCH)/crypto/``, or ``drivers/crypto/`` directories. These
directories are used by the traditional crypto API. When possible, algorithms
in the traditional crypto API are implemented by calls into the library.
Advantages
==========
Some of the advantages of the library over the traditional crypto API are:
- The library functions tend to be much easier to use. For example, a hash
value can be computed using only a single function call. Most of the library
functions always succeed and return void, eliminating the need to write
error-handling code. Most also accept standard virtual addresses, rather than
scatterlists which are difficult and less efficient to work with.
- The library functions are usually faster, especially for short inputs. They
call the crypto algorithms directly without inefficient indirect calls, memory
allocations, string parsing, lookups in an algorithm registry, and other
unnecessary API overhead. Architecture-optimized code is enabled by default.
- The library functions use standard link-time dependencies instead of
error-prone dynamic loading by name. There's no need for workarounds such as
forcing algorithms to be built-in or adding module soft dependencies.
- The library focuses on the approach that works the best on the vast majority
of systems: CPU-based implementations of the crypto algorithms, utilizing
on-CPU acceleration (such as AES instructions) when available.
- The library uses standard KUnit tests, rather than custom ad-hoc tests.
- The library tends to have higher assurance implementations of the crypto
algorithms. This is both due to its simpler design and because more of its
code is being regularly tested.
- The library supports features that don't fit into the rigid framework of the
traditional crypto API, for example interleaved hashing and XOFs.
When to use it
==============
In-kernel users should use the library (rather than the traditional crypto API)
whenever possible. Many subsystems have already been converted. It usually
simplifies their code significantly and improves performance.
Some kernel features allow userspace to provide an arbitrary string that selects
an arbitrary algorithm from the traditional crypto API by name. These features
generally will have to keep using the traditional crypto API for backwards
compatibility.
Note: new kernel features shouldn't support every algorithm, but rather make a
deliberate choice about what algorithm(s) to support. History has shown that
making a deliberate, thoughtful choice greatly simplifies code maintenance,
reduces the chance for mistakes (such as using an obsolete, insecure, or
inappropriate algorithm), and makes your feature easier to use.
Testing
=======
The crypto library uses standard KUnit tests. Like many of the kernel's other
KUnit tests, they are included in the set of tests that is run by
``tools/testing/kunit/kunit.py run --alltests``.
A ``.kunitconfig`` file is also provided to run just the crypto library tests.
For example, here's how to run them in user-mode Linux:
.. code-block:: sh
tools/testing/kunit/kunit.py run --kunitconfig=lib/crypto/
Many of the crypto algorithms have architecture-optimized implementations.
Testing those requires building an appropriate kernel and running the tests
either in QEMU or on appropriate hardware. Here's one example with QEMU:
.. code-block:: sh
tools/testing/kunit/kunit.py run --kunitconfig=lib/crypto/ --arch=arm64 --make_options LLVM=1
Depending on the code being tested, flags may need to be passed to QEMU to
emulate the correct type of hardware for the code to be reached.
Since correctness is essential in cryptographic code, new architecture-optimized
code is accepted only if it can be tested in QEMU.
Note: the crypto library also includes FIPS 140 self-tests. These are
lightweight, are designed specifically to meet FIPS 140 requirements, and exist
*only* to meet those requirements. Normal testing done by kernel developers and
integrators should use the much more comprehensive KUnit tests instead.
API documentation
=================
.. toctree::
:maxdepth: 2
libcrypto-blockcipher
libcrypto-hash
libcrypto-signature
libcrypto-utils
sha3

2
Documentation/crypto/sha3.rst
View File

@ -1,5 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
.. _sha3:
==========================
SHA-3 Algorithm Collection
==========================

7
Documentation/devicetree/bindings/arm/altera.yaml
View File

@ -84,6 +84,12 @@ properties:
- altr,socfpga-stratix10-swvp
- const: altr,socfpga-stratix10
- description: Stratix 10 SoCDK eMMC variant
items:
- const: altr,socfpga-stratix10-socdk-emmc
- const: altr,socfpga-stratix10-socdk
- const: altr,socfpga-stratix10
- description: AgileX boards
items:
- enum:
@ -105,6 +111,7 @@ properties:
- enum:
- intel,socfpga-agilex5-socdk
- intel,socfpga-agilex5-socdk-013b
- intel,socfpga-agilex5-socdk-modular
- intel,socfpga-agilex5-socdk-nand
- const: intel,socfpga-agilex5

3
Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
View File

@ -128,6 +128,9 @@ properties:
"#address-cells":
const: 1
access-controllers:
maxItems: 1
patternProperties:
'^trig-conns@([0-9]+)$':
type: object

3
Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
View File

@ -78,6 +78,9 @@ properties:
description: Output connection to CoreSight Trace bus
$ref: /schemas/graph.yaml#/properties/port
access-controllers:
maxItems: 1
required:
- compatible
- reg

3
Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml
View File

@ -118,6 +118,9 @@ properties:
description: Output connection from the ETM to CoreSight Trace bus.
$ref: /schemas/graph.yaml#/properties/port
access-controllers:
maxItems: 1
required:
- compatible
- clocks

3
Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml
View File

@ -73,6 +73,9 @@ properties:
description: Output connection to the CoreSight Trace bus.
$ref: /schemas/graph.yaml#/properties/port
access-controllers:
maxItems: 1
required:
- compatible
- reg

3
Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml
View File

@ -128,6 +128,9 @@ properties:
- const: tracedata
- const: metadata
access-controllers:
maxItems: 1
required:
- compatible
- reg

3
Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml
View File

@ -70,6 +70,9 @@ properties:
description: Input connection from the CoreSight Trace bus.
$ref: /schemas/graph.yaml#/properties/port
access-controllers:
maxItems: 1
required:
- compatible
- reg

15
Documentation/devicetree/bindings/arm/arm,corstone1000.yaml
View File

@ -15,11 +15,11 @@ description: |+
provides a flexible compute architecture that combines Cortex‑A and Cortex‑M
processors.
Support for Cortex‑A32, Cortex‑A35 and Cortex‑A53 processors. Two expansion
systems for M-Class (or other) processors for adding sensors, connectivity,
video, audio and machine learning at the edge System and security IPs to build
a secure SoC for a range of rich IoT applications, for example gateways, smart
cameras and embedded systems.
Support for Cortex‑A32, Cortex‑A35, Cortex‑A53 and Cortex-A320 processors.
Two expansion systems for M-Class (or other) processors for adding sensors,
connectivity, video, audio and machine learning at the edge System and
security IPs to build a secure SoC for a range of rich IoT applications, for
example gateways, smart cameras and embedded systems.
Integrated Secure Enclave providing hardware Root of Trust and supporting
seamless integration of the optional CryptoCell™-312 cryptographic
@ -39,6 +39,11 @@ properties:
implementation of this system. See ARM ecosystems FVP's.
items:
- const: arm,corstone1000-fvp
- description: Corstone1000-A320 FVP is the Fixed Virtual Platform
implementation of this system with Cortex-A320 cores and Ethos-U85
NPU. See ARM ecosystems FVP's.
items:
- const: arm,corstone1000-a320-fvp
additionalProperties: true

10
Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
View File

@ -119,6 +119,16 @@ properties:
items:
- const: arm,foundation-aarch64
- const: arm,vexpress
- description: Arm Zena Compute Subsystem Platforms
Arm Zena Compute Subsystem (CSS) is a compute platform targeting
the automotive sector. Arm Zena CSS is a high-performance Arm
Cortex-A720AE Application Processor system augmented with an Arm
Cortex-R82AE based Safety Island and real-time domain.
items:
- enum:
- arm,zena-css-fvp
- const: arm,zena-css
- const: arm,vexpress
arm,vexpress,position:
description: When daughterboards are stacked on one site, their position

53
Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml Normal file
View File

@ -0,0 +1,53 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,vexpress-scc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Express Serial Configuration Controller
maintainers:
- Liviu Dudau <liviu.dudau@arm.com>
- Sudeep Holla <sudeep.holla@arm.com>
description: |
Test chips for ARM Versatile Express platform implement SCC (Serial
Configuration Controller) interface, used to set initial conditions
for the test chip.
In some cases its registers are also mapped in normal address space
and can be used to obtain runtime information about the chip internals
(like silicon temperature sensors) and as interface to other subsystems
like platform configuration control and power management.
properties:
compatible:
items:
- enum:
- arm,vexpress-scc,v2p-ca15_a7
- const: arm,vexpress-scc
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- compatible
additionalProperties: false
examples:
- |
bus {
#address-cells = <2>;
#size-cells = <2>;
scc@7fff0000 {
compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
reg = <0 0x7fff0000 0 0x1000>;
interrupts = <0 95 4>;
};
};
...

2
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
View File

@ -35,6 +35,7 @@ properties:
- ampere,mtjade-bmc
- aspeed,ast2500-evb
- asrock,altrad8-bmc
- asrock,ast2500-paul-ipmi-card
- asrock,e3c246d4i-bmc
- asrock,e3c256d4i-bmc
- asrock,romed8hm3-bmc
@ -80,6 +81,7 @@ properties:
- ampere,mtmitchell-bmc
- aspeed,ast2600-evb
- aspeed,ast2600-evb-a1
- asus,ast2600-kommando-ipmi-card
- asus,x4tf-bmc
- facebook,anacapa-bmc
- facebook,bletchley-bmc

66
Documentation/devicetree/bindings/arm/atmel,at91rm9200-sdramc.yaml Normal file
View File

@ -0,0 +1,66 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/atmel,at91rm9200-sdramc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip (Atmel) SDRAM / DDR Controller (RAMC / DDRAMC / UDDRC)
maintainers:
- Nicolas Ferre <nicolas.ferre@microchip.com>
- Claudiu Beznea <claudiu.beznea@tuxon.dev>
description:
The SDRAM/DDR Controller (often called RAMC or DDRAMC) in various
Atmel/Microchip ARM9 and Cortex-A5/A7 SoCs manages external
SDRAM / DDR memory. It is typically exposed as a syscon node for
register access from other drivers (e.g. for initialization or mode
configuration). No interrupts or clocks are usually required in the
binding.
properties:
compatible:
oneOf:
- items:
- const: atmel,at91rm9200-sdramc
- const: syscon
- items:
- const: microchip,sama7d65-uddrc
- const: microchip,sama7g5-uddrc
- enum:
- atmel,at91sam9260-sdramc
- atmel,at91sam9g45-ddramc
- atmel,sama5d3-ddramc
- microchip,sam9x60-ddramc
- microchip,sam9x7-ddramc
- microchip,sama7g5-uddrc
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: ddrck
- const: mpddr
required:
- compatible
- reg
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/at91.h>
ramc@ffffe400 {
compatible = "atmel,at91sam9g45-ddramc";
reg = <0xffffe400 0x200>;
clocks = <&pmc PMC_TYPE_SYSTEM 2>;
clock-names = "ddrck";
};
...

69
Documentation/devicetree/bindings/arm/atmel,at91rm9200-st.yaml Normal file
View File

@ -0,0 +1,69 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/atmel,at91rm9200-st.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Atmel System Timer
maintainers:
- Nicolas Ferre <nicolas.ferre@microchip.com>
- Claudiu Beznea <claudiu.beznea@tuxon.dev>
description:
The System Timer (ST) module in AT91RM9200 provides periodic tick and
alarm capabilities. It is exposed as a simple multi-function device
(simple-mfd + syscon) because it shares its register space and interrupt
with other System Controller blocks.
properties:
compatible:
items:
- const: atmel,at91rm9200-st
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 1
patternProperties:
"^watchdog@[0-9a-f]+$":
$ref: /schemas/watchdog/atmel,at91rm9200-wdt.yaml#
required:
- compatible
- reg
- interrupts
- clocks
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
timer@fffffd00 {
compatible = "atmel,at91rm9200-st", "syscon", "simple-mfd";
reg = <0xfffffd00 0x100>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
clocks = <&slow_xtal>;
#address-cells = <1>;
#size-cells = <1>;
watchdog@fffffd40 {
compatible = "atmel,at91rm9200-wdt";
reg = <0xfffffd40 0x40>;
};
};
...

49
Documentation/devicetree/bindings/arm/atmel,at91sam9260-pit.yaml Normal file
View File

@ -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,at91sam9260-pit.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Atmel AT91SAM9260 Periodic Interval Timer (PIT)
maintainers:
- Nicolas Ferre <nicolas.ferre@microchip.com>
- Claudiu Beznea <claudiu.beznea@tuxon.dev>
description:
The Periodic Interval Timer (PIT) is part of the System Controller of
various Microchip 32-bit ARM-based SoCs (formerly Atmel AT91 series).
It is a simple down-counter timer used mainly as the kernel tick source.
The PIT is clocked from the slow clock and shares a single IRQ line with
other System Controller peripherals.
properties:
compatible:
const: atmel,at91sam9260-pit
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
required:
- compatible
- reg
- interrupts
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
timer@fffffd30 {
compatible = "atmel,at91sam9260-pit";
reg = <0xfffffd30 0x10>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk32k>;
};
...

6
Documentation/devicetree/bindings/arm/atmel-at91.yaml
View File

@ -243,6 +243,12 @@ properties:
- const: microchip,lan9668
- const: microchip,lan966
- description: Microchip LAN9696 EV23X71A Evaluation Board
items:
- const: microchip,ev23x71a
- const: microchip,lan9696
- const: microchip,lan9691
- description: Kontron KSwitch D10 MMT series
items:
- enum:

48
Documentation/devicetree/bindings/arm/atmel-sysregs.txt
View File

@ -1,48 +0,0 @@
Atmel system registers
Chipid required properties:
- compatible: Should be "atmel,sama5d2-chipid" or "microchip,sama7g5-chipid"
"microchip,sama7d65-chipid"
- reg : Should contain registers location and length
PIT Timer required properties:
- compatible: Should be "atmel,at91sam9260-pit"
- reg: Should contain registers location and length
- interrupts: Should contain interrupt for the PIT which is the IRQ line
shared across all System Controller members.
PIT64B Timer required properties:
- compatible: Should be "microchip,sam9x60-pit64b" or
"microchip,sam9x7-pit64b", "microchip,sam9x60-pit64b"
"microchip,sama7d65-pit64b", "microchip,sam9x60-pit64b"
- reg: Should contain registers location and length
- interrupts: Should contain interrupt for PIT64B timer
- clocks: Should contain the available clock sources for PIT64B timer.
System Timer (ST) required properties:
- compatible: Should be "atmel,at91rm9200-st", "syscon", "simple-mfd"
- reg: Should contain registers location and length
- interrupts: Should contain interrupt for the ST which is the IRQ line
shared across all System Controller members.
- clocks: phandle to input clock.
Its subnodes can be:
- watchdog: compatible should be "atmel,at91rm9200-wdt"
RAMC SDRAM/DDR Controller required properties:
- compatible: Should be "atmel,at91rm9200-sdramc", "syscon" or
"atmel,at91sam9260-sdramc" or
"atmel,at91sam9g45-ddramc" or
"atmel,sama5d3-ddramc" or
"microchip,sam9x60-ddramc" or
"microchip,sama7g5-uddrc" or
"microchip,sama7d65-uddrc", "microchip,sama7g5-uddrc" or
"microchip,sam9x7-ddramc", "atmel,sama5d3-ddramc".
- reg: Should contain registers location and length
Examples:
ramc0: ramc@ffffe800 {
compatible = "atmel,at91sam9g45-ddramc";
reg = <0xffffe800 0x200>;
};

6
Documentation/devicetree/bindings/arm/axis.yaml
View File

@ -31,6 +31,12 @@ properties:
- axis,artpec8-grizzly
- const: axis,artpec8
- description: Axis ARTPEC-9 SoC board
items:
- enum:
- axis,artpec9-alfred
- const: axis,artpec9
additionalProperties: true
...

299
Documentation/devicetree/bindings/arm/cpus.yaml
View File

@ -79,149 +79,162 @@ properties:
All other bits in the reg cells must be set to 0.
compatible:
enum:
- apm,potenza
- apm,strega
- apple,avalanche
- apple,blizzard
- apple,cyclone
- apple,firestorm
- apple,hurricane-zephyr
- apple,icestorm
- apple,mistral
- apple,monsoon
- apple,twister
- apple,typhoon
- arm,arm710t
- arm,arm720t
- arm,arm740t
- arm,arm7ej-s
- arm,arm7tdmi
- arm,arm7tdmi-s
- arm,arm9es
- arm,arm9ej-s
- arm,arm920t
- arm,arm922t
- arm,arm925
- arm,arm926e-s
- arm,arm926ej-s
- arm,arm940t
- arm,arm946e-s
- arm,arm966e-s
- arm,arm968e-s
- arm,arm9tdmi
- arm,arm1020e
- arm,arm1020t
- arm,arm1022e
- arm,arm1026ej-s
- arm,arm1136j-s
- arm,arm1136jf-s
- arm,arm1156t2-s
- arm,arm1156t2f-s
- arm,arm1176jzf
- arm,arm1176jz-s
- arm,arm1176jzf-s
- arm,arm11mpcore
- arm,armv8 # Only for s/w models
- arm,c1-nano
- arm,c1-premium
- arm,c1-pro
- arm,c1-ultra
- arm,cortex-a5
- arm,cortex-a7
- arm,cortex-a8
- arm,cortex-a9
- arm,cortex-a12
- arm,cortex-a15
- arm,cortex-a17
- arm,cortex-a32
- arm,cortex-a34
- arm,cortex-a35
- arm,cortex-a53
- arm,cortex-a55
- arm,cortex-a57
- arm,cortex-a65
- arm,cortex-a72
- arm,cortex-a73
- arm,cortex-a75
- arm,cortex-a76
- arm,cortex-a77
- arm,cortex-a78
- arm,cortex-a78ae
- arm,cortex-a78c
- arm,cortex-a320
- arm,cortex-a510
- arm,cortex-a520
- arm,cortex-a520ae
- arm,cortex-a710
- arm,cortex-a715
- arm,cortex-a720
- arm,cortex-a720ae
- arm,cortex-a725
- arm,cortex-m0
- arm,cortex-m0+
- arm,cortex-m1
- arm,cortex-m3
- arm,cortex-m4
- arm,cortex-r4
- arm,cortex-r5
- arm,cortex-r7
- arm,cortex-r52
- arm,cortex-x1
- arm,cortex-x1c
- arm,cortex-x2
- arm,cortex-x3
- arm,cortex-x4
- arm,cortex-x925
- arm,neoverse-e1
- arm,neoverse-n1
- arm,neoverse-n2
- arm,neoverse-n3
- arm,neoverse-v1
- arm,neoverse-v2
- arm,neoverse-v3
- arm,neoverse-v3ae
- arm,rainier
- brcm,brahma-b15
- brcm,brahma-b53
- brcm,vulcan
- cavium,thunder
- cavium,thunder2
- faraday,fa526
- intel,sa110
- intel,sa1100
- marvell,feroceon
- marvell,mohawk
- marvell,pj4a
- marvell,pj4b
- marvell,sheeva-v5
- marvell,sheeva-v7
- nvidia,tegra132-denver
- nvidia,tegra186-denver
- nvidia,tegra194-carmel
- qcom,krait
- qcom,kryo
- qcom,kryo240
- qcom,kryo250
- qcom,kryo260
- qcom,kryo280
- qcom,kryo360
- qcom,kryo385
- qcom,kryo465
- qcom,kryo468
- qcom,kryo470
- qcom,kryo485
- qcom,kryo560
- qcom,kryo570
- qcom,kryo660
- qcom,kryo670
- qcom,kryo685
- qcom,kryo780
- qcom,oryon
- qcom,scorpion
- samsung,mongoose-m2
- samsung,mongoose-m3
- samsung,mongoose-m5
oneOf:
- enum:
- apm,potenza
- apm,strega
- apple,avalanche
- apple,blizzard
- apple,cyclone
- apple,everest
- apple,firestorm
- apple,hurricane-zephyr
- apple,icestorm
- apple,mistral
- apple,monsoon
- apple,sawtooth
- apple,twister
- apple,typhoon
- arm,arm710t
- arm,arm720t
- arm,arm740t
- arm,arm7ej-s
- arm,arm7tdmi
- arm,arm7tdmi-s
- arm,arm9es
- arm,arm9ej-s
- arm,arm920t
- arm,arm922t
- arm,arm925
- arm,arm926e-s
- arm,arm926ej-s
- arm,arm940t
- arm,arm946e-s
- arm,arm966e-s
- arm,arm968e-s
- arm,arm9tdmi
- arm,arm1020e
- arm,arm1020t
- arm,arm1022e
- arm,arm1026ej-s
- arm,arm1136j-s
- arm,arm1136jf-s
- arm,arm1156t2-s
- arm,arm1156t2f-s
- arm,arm1176jzf
- arm,arm1176jz-s
- arm,arm1176jzf-s
- arm,arm11mpcore
- arm,armv8 # Only for s/w models
- arm,c1-nano
- arm,c1-premium
- arm,c1-pro
- arm,c1-ultra
- arm,cortex-a5
- arm,cortex-a7
- arm,cortex-a8
- arm,cortex-a9
- arm,cortex-a12
- arm,cortex-a15
- arm,cortex-a17
- arm,cortex-a32
- arm,cortex-a34
- arm,cortex-a35
- arm,cortex-a53
- arm,cortex-a55
- arm,cortex-a57
- arm,cortex-a65
- arm,cortex-a72
- arm,cortex-a73
- arm,cortex-a75
- arm,cortex-a76
- arm,cortex-a77
- arm,cortex-a78
- arm,cortex-a78ae
- arm,cortex-a78c
- arm,cortex-a320
- arm,cortex-a510
- arm,cortex-a520
- arm,cortex-a520ae
- arm,cortex-a710
- arm,cortex-a715
- arm,cortex-a720
- arm,cortex-a720ae
- arm,cortex-a725
- arm,cortex-m0
- arm,cortex-m0+
- arm,cortex-m1
- arm,cortex-m3
- arm,cortex-m4
- arm,cortex-r4
- arm,cortex-r5
- arm,cortex-r7
- arm,cortex-r52
- arm,cortex-x1
- arm,cortex-x1c
- arm,cortex-x2
- arm,cortex-x3
- arm,cortex-x4
- arm,cortex-x925
- arm,neoverse-e1
- arm,neoverse-n1
- arm,neoverse-n2
- arm,neoverse-n3
- arm,neoverse-v1
- arm,neoverse-v2
- arm,neoverse-v3
- arm,neoverse-v3ae
- arm,rainier
- brcm,brahma-b15
- brcm,brahma-b53
- brcm,vulcan
- cavium,thunder
- cavium,thunder2
- faraday,fa526
- intel,sa110
- intel,sa1100
- marvell,feroceon
- marvell,mohawk
- marvell,pj4a
- marvell,pj4b
- marvell,sheeva-v5
- marvell,sheeva-v7
- nvidia,tegra132-denver
- nvidia,tegra186-denver
- nvidia,tegra194-carmel
- qcom,krait
- qcom,kryo240
- qcom,kryo250
- qcom,kryo260
- qcom,kryo280
- qcom,kryo360
- qcom,kryo385
- qcom,kryo465
- qcom,kryo468
- qcom,kryo470
- qcom,kryo485
- qcom,kryo560
- qcom,kryo570
- qcom,kryo660
- qcom,kryo670
- qcom,kryo685
- qcom,kryo780
- qcom,oryon-1-1
- qcom,oryon-1-2
- qcom,oryon-1-3
- qcom,oryon-1-4
- qcom,oryon-2-1
- qcom,oryon-2-2
- qcom,oryon-2-3
- qcom,scorpion
- samsung,mongoose-m2
- samsung,mongoose-m3
- samsung,mongoose-m5
- enum:
- qcom,kryo
- qcom,oryon
# Too generic, do not use in new code
deprecated: true
enable-method:
$ref: /schemas/types.yaml#/definitions/string

1
Documentation/devicetree/bindings/arm/freescale/fsl,imx51-m4if.yaml
View File

@ -15,6 +15,7 @@ properties:
compatible:
oneOf:
- enum:
- fsl,imx25-aips
- fsl,imx51-m4if
- fsl,imx51-tigerp
- fsl,imx51-aipstz

5
Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml
View File

@ -28,6 +28,9 @@ properties:
reg:
maxItems: 1
'#clock-cells':
const: 1
clocks:
maxItems: 2
@ -39,6 +42,7 @@ properties:
required:
- compatible
- reg
- '#clock-cells'
additionalProperties: false
@ -47,4 +51,5 @@ examples:
smc1@40410000 {
compatible = "fsl,imx7ulp-smc1";
reg = <0x40410000 0x1000>;
#clock-cells = <1>;
};

86
Documentation/devicetree/bindings/arm/fsl.yaml
View File

@ -996,6 +996,14 @@ properties:
- const: engicam,icore-mx8mm # i.MX8MM Engicam i.Core MX8M Mini SoM
- const: fsl,imx8mm
- description: Ka-Ro Electronics TX8M-1610 based boards
items:
- enum:
- gocontroll,moduline-iv-306-d
- gocontroll,moduline-mini-111
- const: karo,tx8m-1610
- const: fsl,imx8mm
- description: Kontron BL i.MX8MM (N801X S) Board
items:
- const: kontron,imx8mm-bl
@ -1041,6 +1049,13 @@ properties:
- const: phytec,imx8mm-phycore-som # phyCORE-i.MX8MM SoM
- const: fsl,imx8mm
- description: SolidRun i.MX8MM SoM based boards
items:
- enum:
- solidrun,imx8mm-hummingboard-ripple # SolidRun i.MX8MM SoM on HummingBoard Ripple
- const: solidrun,imx8mm-sr-som
- const: fsl,imx8mm
- description: Variscite VAR-SOM-MX8MM based boards
items:
- const: variscite,var-som-mx8mm-symphony
@ -1069,6 +1084,7 @@ properties:
- fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board
- fsl,imx8mn-evk # i.MX8MN LPDDR4 EVK Board
- gw,imx8mn-gw7902 # i.MX8MM Gateworks Board
- solidrun,solidsense-n8-compact # SolidRun SolidSense N8 Compact
- const: fsl,imx8mn
- description: ifm i.MX8MN VHIP4 based boards
@ -1106,6 +1122,7 @@ properties:
- beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit
- dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC
- emcraft,imx8mp-navqp # i.MX8MP Emcraft Systems NavQ+ Kit
- fsl,imx8mp-ab2 # i.MX8MP Audio Board V2
- fsl,imx8mp-evk # i.MX8MP EVK Board
- fsl,imx8mp-evk-revb4 # i.MX8MP EVK Rev B4 Board
- fsl,imx8mp-frdm # i.MX8MP Freedom Board
@ -1225,6 +1242,7 @@ properties:
items:
- enum:
- solidrun,imx8mp-cubox-m # SolidRun i.MX8MP SoM on CuBox-M
- solidrun,imx8mp-hummingboard-iiot # SolidRun i.MX8MP SoM on HummingBoard IIoT
- solidrun,imx8mp-hummingboard-mate # SolidRun i.MX8MP SoM on HummingBoard Mate
- solidrun,imx8mp-hummingboard-pro # SolidRun i.MX8MP SoM on HummingBoard Pro
- solidrun,imx8mp-hummingboard-pulse # SolidRun i.MX8MP SoM on HummingBoard Pulse
@ -1420,6 +1438,16 @@ properties:
- const: tq,imx8dxp-tqma8xdps # TQ-Systems GmbH TQMa8XDPS SOM
- const: fsl,imx8dxp
- description:
TQMa8x is a series of SOM featuring NXP i.MX8 system-on-chip
variants. It is designed to be clicked on different carrier boards
MBa8x is the starterkit
items:
- enum:
- tq,imx8qm-tqma8qm-mba8x # TQ-Systems GmbH TQMa8QM SOM on MBa8x
- const: tq,imx8qm-tqma8qm # TQ-Systems GmbH TQMa8QM SOM
- const: fsl,imx8qm
- description: i.MX8ULP based Boards
items:
- enum:
@ -1432,6 +1460,7 @@ properties:
- enum:
- fsl,imx91-11x11-evk # i.MX91 11x11 EVK Board
- fsl,imx91-11x11-frdm # FRDM i.MX91 Development Board
- fsl,imx91-11x11-frdm-s # FRDM i.MX91S Development Board
- const: fsl,imx91
- description: i.MX93 based Boards
@ -1441,6 +1470,7 @@ properties:
- fsl,imx93-11x11-evk # i.MX93 11x11 EVK Board
- fsl,imx93-11x11-frdm # i.MX93 11x11 FRDM Board
- fsl,imx93-14x14-evk # i.MX93 14x14 EVK Board
- fsl,imx93-wireless-evk # i.MX93 and IW610G WLCSP (Wi-Fi + BLE + 802.15.4) SiP EVK Board
- const: fsl,imx93
- description: i.MX94 based Boards
@ -1477,6 +1507,36 @@ properties:
- const: toradex,smarc-imx95 # Toradex SMARC iMX95 Module
- const: fsl,imx95
- description: Toradex Boards with Verdin iMX95 Modules
items:
- enum:
- toradex,verdin-imx95-nonwifi-dahlia # Verdin iMX95 Module on Dahlia
- toradex,verdin-imx95-nonwifi-dev # Verdin iMX95 Module on Verdin Development Board
- toradex,verdin-imx95-nonwifi-ivy # Verdin iMX95 Module on Ivy
- toradex,verdin-imx95-nonwifi-mallow # Verdin iMX95 Module on Mallow
- toradex,verdin-imx95-nonwifi-yavia # Verdin iMX95 Module on Yavia
- const: toradex,verdin-imx95-nonwifi # Verdin iMX95 Module without Wi-Fi / BT
- const: toradex,verdin-imx95 # Verdin iMX95 Module
- const: fsl,imx95
- description: Toradex Boards with Verdin iMX95 Wi-Fi / BT Modules
items:
- enum:
- toradex,verdin-imx95-wifi-dahlia # Verdin iMX95 Wi-Fi / BT Module on Dahlia
- toradex,verdin-imx95-wifi-dev # Verdin iMX95 Wi-Fi / BT Module on Verdin Development B.
- toradex,verdin-imx95-wifi-ivy # Verdin iMX95 Wi-Fi / BT Module on Ivy
- toradex,verdin-imx95-wifi-mallow # Verdin iMX95 Wi-Fi / BT Module on Mallow
- toradex,verdin-imx95-wifi-yavia # Verdin iMX95 Wi-Fi / BT Module on Yavia
- const: toradex,verdin-imx95-wifi # Verdin iMX95 Wi-Fi / BT Module
- const: toradex,verdin-imx95 # Verdin iMX95 Module
- const: fsl,imx95
- description: Variscite DART-MX95 based Boards
items:
- const: variscite,var-dart-mx95-sonata # Variscite DART-MX95 SOM on Sonata Development Board
- const: variscite,var-dart-mx95 # Variscite DART-MX95 SOM
- const: fsl,imx95
- description: i.MXRT1050 based Boards
items:
- enum:
@ -1522,11 +1582,14 @@ properties:
soldered on an adapter board or for the connector variant
MBa93xxLA mainboard is a single board computer using the solderable
SOM variant
MBa93xxLA-MINI 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
- tq,imx93-tqma9352-mba93xxla-mini # TQ-Systems GmbH i.MX93 TQMa93xxLA SOM on MBa93xxLA-MINI SBC
- const: tq,imx93-tqma9352 # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM
- const: fsl,imx93
@ -1545,6 +1608,12 @@ properties:
- const: phytec,imx93-phycore-som # phyCORE-i.MX93 SoM
- const: fsl,imx93
- description: Variscite DART-MX91 based boards
items:
- const: variscite,var-dart-mx91-sonata # Variscite DART-MX91 on Sonata Development Board
- const: variscite,var-dart-mx91 # Variscite DART-MX91 SOM
- const: fsl,imx91
- description: Variscite VAR-SOM-MX93 based boards
items:
- const: variscite,var-som-mx93-symphony
@ -1557,6 +1626,17 @@ properties:
- const: kontron,imx93-osm-s # Kontron OSM-S i.MX93 SoM
- const: fsl,imx93
- description:
TQMa95xxLA is a series of SOM featuring NXP i.MX95 SoC variants,
designed to be soldered on different carrier boards.
MBa95xxCA is a carrier reference design / starter kit that allows
to use TQMa95xxLA via an adaper board.
items:
- enum:
- tq,imx95-tqma9596la-mba95xxca # TQ-Systems GmbH i.MX95 TQMa95xxLA SOM on MBa95xxCA
- const: tq,imx95-tqma9596la # TQ-Systems GmbH i.MX95 TQMa95xxLA SOM
- const: fsl,imx95
- 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
@ -1827,6 +1907,12 @@ properties:
- fsl,s32v234-evb # S32V234-EVB2 Customer Evaluation Board
- const: fsl,s32v234
- description: S32N79 based Boards
items:
- enum:
- nxp,s32n79-rdb
- const: nxp,s32n79
- description: Traverse LS1088A based Boards
items:
- enum:

11
Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
View File

@ -21,6 +21,17 @@ properties:
- const: marvell,armada-ap806-dual
- const: marvell,armada-ap806
- description:
Falcon (DB-98CX85x0) Development board COM Express Carrier plus
Armada 7020 SoC COM Express CPU module
items:
- const: marvell,armada7020-falcon-carrier
- const: marvell,db-falcon-carrier
- const: marvell,armada7020-cpu-module
- const: marvell,armada7020
- const: marvell,armada-ap806-dual
- const: marvell,armada-ap806
- description: Armada 7040 SoC
items:
- enum:

59
Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml
View File

@ -49,38 +49,37 @@ required:
- '#clock-cells'
allOf:
- if:
properties:
compatible:
contains:
enum:
- mediatek,mt2701-audsys
- mediatek,mt7622-audsys
then:
properties:
audio-controller:
$ref: /schemas/sound/mediatek,mt2701-audio.yaml#
- if:
properties:
compatible:
contains:
enum:
- mediatek,mt2701-audsys
- mediatek,mt7622-audsys
then:
properties:
audio-controller:
$ref: /schemas/sound/mediatek,mt2701-audio.yaml#
- if:
properties:
compatible:
contains:
const: mediatek,mt8183-audiosys
then:
properties:
audio-controller:
$ref: /schemas/sound/mediatek,mt8183-audio.yaml#
- if:
properties:
compatible:
contains:
const: mediatek,mt8192-audsys
then:
properties:
audio-controller:
$ref: /schemas/sound/mt8192-afe-pcm.yaml#
- if:
properties:
compatible:
contains:
const: mediatek,mt8183-audiosys
then:
properties:
audio-controller:
$ref: /schemas/sound/mediatek,mt8183-audio.yaml#
- if:
properties:
compatible:
contains:
const: mediatek,mt8192-audsys
then:
properties:
audio-controller:
$ref: /schemas/sound/mt8192-afe-pcm.yaml#
additionalProperties: false

68
Documentation/devicetree/bindings/arm/microchip,sam9x60-pit64b.yaml Normal file
View File

@ -0,0 +1,68 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/microchip,sam9x60-pit64b.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip PIT64B 64-bit Periodic Interval Timer
maintainers:
- Nicolas Ferre <nicolas.ferre@microchip.com>
- Claudiu Beznea <claudiu.beznea@tuxon.dev>
description:
The Microchip PIT64B is a 64-bit periodic interval timer used in
several modern Microchip ARM SoCs including SAM9X60, SAM9X7 and
SAMA7D65 families. It provides extended timing range, flexible
clock selection and supports both periodic and one-shot interrupt
generation modes.
properties:
compatible:
oneOf:
- const: microchip,sam9x60-pit64b
- items:
- enum:
- microchip,sam9x7-pit64b
- microchip,sama7d65-pit64b
- microchip,sama7g5-pit64b
- const: microchip,sam9x60-pit64b
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
maxItems: 2
items:
enum:
- pclk
- gclk
required:
- compatible
- reg
- interrupts
- clocks
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/at91.h>
timer@f0028000 {
compatible = "microchip,sama7g5-pit64b", "microchip,sam9x60-pit64b";
reg = <0xf0028000 0x100>;
interrupts = <37 IRQ_TYPE_LEVEL_HIGH 7>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 37>, <&pmc PMC_TYPE_GCK 37>;
clock-names = "pclk", "gclk";
};
...

41
Documentation/devicetree/bindings/arm/microchip,sama7g5-chipid.yaml Normal file
View File

@ -0,0 +1,41 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/microchip,sama7g5-chipid.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Atmel/Microchip RAMC SDRAM/DDR Controller
maintainers:
- Nicolas Ferre <nicolas.ferre@microchip.com>
- Claudiu Beznea <claudiu.beznea@tuxon.dev>
description:
This binding describes the Atmel/Microchip Chip ID register block used
for SoC identification and revision information. It requires compatible
strings matching specific SoC families and a reg property defining the
register address and size.
properties:
compatible:
enum:
- atmel,sama5d2-chipid
- microchip,sama7d65-chipid
- microchip,sama7g5-chipid
reg:
maxItems: 1
required:
- compatible
- reg
unevaluatedProperties: false
examples:
- |
chipid@fc069000 {
compatible = "atmel,sama5d2-chipid";
reg = <0xfc069000 0x8>;
};
...

22
Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml
View File

@ -22,5 +22,27 @@ properties:
- phytec,phy3250
- const: nxp,lpc3250
- items:
- enum:
- ea,lpc4357-developers-kit
- const: nxp,lpc4357
- const: nxp,lpc4350
- items:
- enum:
- ciaa,lpc4337
- const: nxp,lpc4337
- const: nxp,lpc4350
- items:
- enum:
- hitex,lpc4350-eval-board
- const: nxp,lpc4350
- items:
- enum:
- myir,myd-lpc4357
- const: nxp,lpc4357
additionalProperties: true
...

47
Documentation/devicetree/bindings/arm/qcom.yaml
View File

@ -61,6 +61,21 @@ properties:
- qcom,apq8084-sbc
- const: qcom,apq8084
- items:
- enum:
- qcom,eliza-mtp
- const: qcom,eliza
- items:
- enum:
- qcom,glymur-crd
- const: qcom,glymur
- items:
- enum:
- qcom,mahua-crd
- const: qcom,mahua
- items:
- enum:
- fairphone,fp6
@ -171,6 +186,7 @@ properties:
- qcom,msm8916-mtp
- samsung,a3u-eur
- samsung,a5u-eur
- samsung,coreprimeltevzw
- samsung,e5
- samsung,e7
- samsung,fortuna3g
@ -186,6 +202,7 @@ properties:
- samsung,serranove
- thwc,uf896
- thwc,ufi001c
- wiko,chuppito
- wingtech,wt86518
- wingtech,wt86528
- wingtech,wt88047
@ -195,6 +212,8 @@ properties:
- items:
- enum:
- xiaomi,riva
- xiaomi,rolex
- xiaomi,tiare
- const: qcom,msm8917
- items:
@ -243,6 +262,13 @@ properties:
- const: qcom,apq8096-sbc
- const: qcom,apq8096
- items:
- const: arrow,apq8096sg-db820c
- const: arrow,apq8096-db820c
- const: qcom,apq8096-sbc
- const: qcom,apq8096sg
- const: qcom,apq8096
- items:
- enum:
- oneplus,oneplus3
@ -297,6 +323,11 @@ properties:
- tplink,archer-ax55-v1
- const: qcom,ipq5018
- items:
- enum:
- qcom,ipq5210-rdp504
- const: qcom,ipq5210
- items:
- enum:
- qcom,ipq5332-ap-mi01.2
@ -326,8 +357,10 @@ properties:
- items:
- enum:
- qcom,ipq9574-ap-al02-c2
- qcom,ipq9574-ap-al02-c2-emmc
- qcom,ipq9574-ap-al02-c6
- qcom,ipq9574-ap-al02-c7
- qcom,ipq9574-ap-al02-c7-emmc
- qcom,ipq9574-ap-al02-c8
- qcom,ipq9574-ap-al02-c9
- const: qcom,ipq9574
@ -360,6 +393,7 @@ properties:
- qcom,qcs6490-rb3gen2
- radxa,dragon-q6a
- shift,otter
- thundercomm,minipc-g1iot
- thundercomm,rubikpi3
- const: qcom,qcm6490
@ -385,6 +419,7 @@ properties:
- items:
- enum:
- acer,aspire1
- ecs,liva-qc710
- qcom,sc7180-idp
- const: qcom,sc7180
@ -882,6 +917,7 @@ properties:
- items:
- enum:
- arduino,monza
- qcom,monaco-evk
- qcom,qcs8300-ride
- const: qcom,qcs8300
@ -889,6 +925,7 @@ properties:
- items:
- enum:
- qcom,qcs615-ride
- qcom,talos-evk
- const: qcom,qcs615
- const: qcom,sm6150
@ -972,6 +1009,7 @@ properties:
- sony,pdx201
- xiaomi,ginkgo
- xiaomi,laurel-sprout
- xiaomi,willow
- const: qcom,sm6125
- items:
@ -1063,6 +1101,7 @@ properties:
- items:
- enum:
- ayaneo,pocket-s2
- qcom,sm8650-hdk
- qcom,sm8650-mtp
- qcom,sm8650-qrd
@ -1110,6 +1149,7 @@ properties:
- dell,xps13-9345
- hp,elitebook-ultra-g1q
- hp,omnibook-x14
- lenovo,ideacentre-mini-01q8x10
- lenovo,yoga-slim7x
- microsoft,romulus13
- microsoft,romulus15
@ -1128,6 +1168,12 @@ properties:
- const: microsoft,denali
- const: qcom,x1e80100
- items:
- enum:
- qcom,purwa-iot-evk
- const: qcom,purwa-iot-som
- const: qcom,x1p42100
- items:
- enum:
- asus,zenbook-a14-ux3407qa-lcd
@ -1137,6 +1183,7 @@ properties:
- items:
- enum:
- asus,vivobook-s15-x1p4
- hp,omnibook-x14-fe1
- lenovo,thinkbook-16
- qcom,x1p42100-crd

20
Documentation/devicetree/bindings/arm/rockchip.yaml
View File

@ -754,6 +754,11 @@ properties:
- const: khadas,edge2
- const: rockchip,rk3588s
- description: Khadas Edge-2L series boards
items:
- const: khadas,edge-2l
- const: rockchip,rk3576
- description: Kobol Helios64
items:
- const: kobol,helios64
@ -808,11 +813,22 @@ properties:
- const: netxeon,r89
- const: rockchip,rk3288
- description: Onion Omega4 Evaluation board
items:
- const: onion,omega4-evb
- const: onion,omega4
- const: rockchip,rv1103b
- description: OPEN AI LAB EAIDK-610
items:
- const: openailab,eaidk-610
- const: rockchip,rk3399
- description: OneThing Edge Cube series
items:
- const: onething,edge-cube
- const: rockchip,rk3566
- description: Xunlong Orange Pi RK3399 board
items:
- const: xunlong,rk3399-orangepi
@ -1187,7 +1203,9 @@ properties:
- description: Rockchip RK3576 Evaluation board
items:
- const: rockchip,rk3576-evb1-v10
- enum:
- rockchip,rk3576-evb1-v10
- rockchip,rk3576-evb2-v10
- const: rockchip,rk3576
- description: Rockchip RK3588 Evaluation board

3
Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
View File

@ -117,6 +117,7 @@ properties:
- description: Exynos5250 based boards
items:
- enum:
- google,manta # Google Manta (Nexus 10)
- google,snow-rev5 # Google Snow Rev 5+
- google,spring # Google Spring
- insignal,arndale # Insignal Arndale
@ -216,7 +217,9 @@ properties:
items:
- enum:
- samsung,a2corelte # Samsung Galaxy A2 Core
- samsung,j5y17lte # Samsung Galaxy J5 (2017)
- samsung,j6lte # Samsung Galaxy J6
- samsung,j7xelte # Samsung Galaxy J7 (2016)
- samsung,on7xelte # Samsung Galaxy J7 Prime
- const: samsung,exynos7870

8
Documentation/devicetree/bindings/arm/stm32/stm32.yaml
View File

@ -183,10 +183,12 @@ properties:
- const: seeed,stm32mp157c-odyssey-som
- const: st,stm32mp157
- description: Phytec STM32MP1 SoM based Boards
- description: Phytec STM32MP157 SoM based Boards
items:
- const: phytec,phycore-stm32mp1-3
- const: phytec,phycore-stm32mp157c-som
- enum:
- phytec,phycore-stm32mp1-3 # phyBOARD-Sargas with phyCORE-STM32MP157C SoM
- enum:
- phytec,phycore-stm32mp157c-som # phyCORE-STM32MP157C SoM
- const: st,stm32mp157
- description: Ultratronik STM32MP1 SBC based Boards

5
Documentation/devicetree/bindings/arm/sunxi.yaml
View File

@ -901,6 +901,11 @@ properties:
- const: allwinner,sl631
- const: allwinner,sun8i-v3
- description: TaiqiCat A01
items:
- const: ultrapower,taiqicat-a01
- const: allwinner,sun50i-h6
- description: Tanix TX1
items:
- const: oranth,tanix-tx1

56
Documentation/devicetree/bindings/arm/tegra.yaml
View File

@ -131,6 +131,33 @@ properties:
- const: toradex,apalis-tk1-v1.2
- const: toradex,apalis-tk1
- const: nvidia,tegra124
- items:
- const: google,nyan-big-rev7
- const: google,nyan-big-rev6
- const: google,nyan-big-rev5
- const: google,nyan-big-rev4
- const: google,nyan-big-rev3
- const: google,nyan-big-rev2
- const: google,nyan-big-rev1
- const: google,nyan-big-rev0
- const: google,nyan-big
- const: google,nyan
- const: nvidia,tegra124
- items:
- const: google,nyan-blaze-rev10
- const: google,nyan-blaze-rev9
- const: google,nyan-blaze-rev8
- const: google,nyan-blaze-rev7
- const: google,nyan-blaze-rev6
- const: google,nyan-blaze-rev5
- const: google,nyan-blaze-rev4
- const: google,nyan-blaze-rev3
- const: google,nyan-blaze-rev2
- const: google,nyan-blaze-rev1
- const: google,nyan-blaze-rev0
- const: google,nyan-blaze
- const: google,nyan
- const: nvidia,tegra124
- items:
- enum:
- nvidia,norrin
@ -184,17 +211,35 @@ properties:
- const: nvidia,tegra124
- items:
- enum:
- nvidia,darcy
- nvidia,p2371-0000
- nvidia,p2371-2180
- nvidia,p2571
- nvidia,p2894-0050-a08
- nvidia,p3450-0000
- const: nvidia,tegra210
- items:
- const: nvidia,p3541-0000
- const: nvidia,p3450-0000
- const: nvidia,tegra210
- description: NVIDIA Jetson Nano
items:
- const: nvidia,p3450-0000
- const: nvidia,tegra210
- description: NVIDIA Shield TV
items:
- const: nvidia,p2894-0050-a08
- const: nvidia,darcy
- const: nvidia,tegra210
- description: Google Pixel C
items:
- const: google,smaug-rev8
- const: google,smaug-rev7
- const: google,smaug-rev6
- const: google,smaug-rev5
- const: google,smaug-rev4
- const: google,smaug-rev3
- const: google,smaug-rev2
- const: google,smaug-rev1
- const: google,smaug
- const: nvidia,tegra210
- description: Jetson TX2 Developer Kit
items:
- const: nvidia,p2771-0000
@ -268,5 +313,10 @@ properties:
- const: nvidia,p3971-0089+p3834-0008
- const: nvidia,p3834-0008
- const: nvidia,tegra264
- description: Jetson AGX Thor Developer Kit
items:
- const: nvidia,p4071-0000+p3834-0008
- const: nvidia,p3834-0008
- const: nvidia,tegra264
additionalProperties: true

4
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml
View File

@ -48,6 +48,10 @@ properties:
- nvidia,tegra234-dce-fabric
- nvidia,tegra234-rce-fabric
- nvidia,tegra234-sce-fabric
- nvidia,tegra238-ape-fabric
- nvidia,tegra238-aon-fabric
- nvidia,tegra238-bpmp-fabric
- nvidia,tegra238-cbb-fabric
reg:
maxItems: 1

5
Documentation/devicetree/bindings/arm/ti/k3.yaml
View File

@ -79,6 +79,7 @@ properties:
- toradex,verdin-am62-nonwifi-ivy # Verdin AM62 Module on Ivy
- toradex,verdin-am62-nonwifi-mallow # Verdin AM62 Module on Mallow
- toradex,verdin-am62-nonwifi-yavia # Verdin AM62 Module on Yavia
- toradex,verdin-am62-nonwifi-zinnia # Verdin AM62 Module on Zinnia
- const: toradex,verdin-am62-nonwifi # Verdin AM62 Module without Wi-Fi / BT
- const: toradex,verdin-am62 # Verdin AM62 Module
- const: ti,am625
@ -91,6 +92,7 @@ properties:
- toradex,verdin-am62-wifi-ivy # Verdin AM62 Wi-Fi / BT Module on Ivy
- toradex,verdin-am62-wifi-mallow # Verdin AM62 Wi-Fi / BT Module on Mallow
- toradex,verdin-am62-wifi-yavia # Verdin AM62 Wi-Fi / BT Module on Yavia
- toradex,verdin-am62-wifi-zinnia # Verdin AM62 Wi-Fi / BT Module on Zinnia
- const: toradex,verdin-am62-wifi # Verdin AM62 Wi-Fi / BT Module
- const: toradex,verdin-am62 # Verdin AM62 Module
- const: ti,am625
@ -103,6 +105,7 @@ properties:
- 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
- toradex,verdin-am62p-nonwifi-zinnia # Verdin AM62P Module on Zinnia
- const: toradex,verdin-am62p-nonwifi # Verdin AM62P Module without Wi-Fi / BT
- const: toradex,verdin-am62p # Verdin AM62P Module
- const: ti,am62p5
@ -115,6 +118,7 @@ properties:
- 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
- toradex,verdin-am62p-wifi-zinnia # Verdin AM62P Wi-Fi / BT Module on Zinnia
- const: toradex,verdin-am62p-wifi # Verdin AM62P Wi-Fi / BT Module
- const: toradex,verdin-am62p # Verdin AM62P Module
- const: ti,am62p5
@ -208,7 +212,6 @@ properties:
items:
- enum:
- beagle,am67a-beagley-ai
- kontron,sa67 # Kontron SMARC-sAM67 board
- ti,j722s-evm
- const: ti,j722s

2
Documentation/devicetree/bindings/arm/ti/omap.yaml
View File

@ -144,6 +144,8 @@ properties:
- motorola,droid-bionic # Motorola Droid Bionic XT875
- motorola,xyboard-mz609
- motorola,xyboard-mz617
- samsung,espresso7
- samsung,espresso10
- ti,omap4-panda
- ti,omap4-sdp
- const: ti,omap4430

33
Documentation/devicetree/bindings/arm/vexpress-scc.txt
View File

@ -1,33 +0,0 @@
ARM Versatile Express Serial Configuration Controller
-----------------------------------------------------
Test chips for ARM Versatile Express platform implement SCC (Serial
Configuration Controller) interface, used to set initial conditions
for the test chip.
In some cases its registers are also mapped in normal address space
and can be used to obtain runtime information about the chip internals
(like silicon temperature sensors) and as interface to other subsystems
like platform configuration control and power management.
Required properties:
- compatible value: "arm,vexpress-scc,<model>", "arm,vexpress-scc";
where <model> is the full tile model name (as used
in the tile's Technical Reference Manual),
eg. for Coretile Express A15x2 A7x3 (V2P-CA15_A7):
compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
Optional properties:
- reg: when the SCC is memory mapped, physical address and size of the
registers window
- interrupts: when the SCC can generate a system-level interrupt
Example:
scc@7fff0000 {
compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
reg = <0 0x7fff0000 0 0x1000>;
interrupts = <0 95 4>;
};

5
Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
View File

@ -10,6 +10,7 @@ maintainers:
- Robin van der Gracht <robin@protonic.nl>
allOf:
- $ref: /schemas/input/input.yaml#
- $ref: /schemas/input/matrix-keymap.yaml#
properties:
@ -33,9 +34,7 @@ properties:
interrupts:
maxItems: 1
debounce-delay-ms:
maxItems: 1
description: Debouncing interval time in milliseconds
debounce-delay-ms: true
linux,keymap: true

90
Documentation/devicetree/bindings/bus/baikal,bt1-apb.yaml
View File

@ -1,90 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/baikal,bt1-apb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Baikal-T1 APB-bus
maintainers:
- Serge Semin <fancer.lancer@gmail.com>
description: |
Baikal-T1 CPU or DMAC MMIO requests are handled by the AMBA 3 AXI Interconnect
which routes them to the AXI-APB bridge. This interface is a single master
multiple slaves bus in turn serializing IO accesses and routing them to the
addressed APB slave devices. In case of any APB protocol collisions, slave
device not responding on timeout an IRQ is raised with an erroneous address
reported to the APB terminator (APB Errors Handler Block).
allOf:
- $ref: /schemas/simple-bus.yaml#
properties:
compatible:
contains:
const: baikal,bt1-apb
reg:
items:
- description: APB EHB MMIO registers
- description: APB MMIO region with no any device mapped
reg-names:
items:
- const: ehb
- const: nodev
interrupts:
maxItems: 1
clocks:
items:
- description: APB reference clock
clock-names:
items:
- const: pclk
resets:
items:
- description: APB domain reset line
reset-names:
items:
- const: prst
unevaluatedProperties: false
required:
- compatible
- reg
- reg-names
- interrupts
- clocks
- clock-names
examples:
- |
#include <dt-bindings/interrupt-controller/mips-gic.h>
bus@1f059000 {
compatible = "baikal,bt1-apb", "simple-bus";
reg = <0x1f059000 0x1000>,
<0x1d000000 0x2040000>;
reg-names = "ehb", "nodev";
#address-cells = <1>;
#size-cells = <1>;
ranges;
interrupts = <GIC_SHARED 16 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu_sys 1>;
clock-names = "pclk";
resets = <&ccu_sys 1>;
reset-names = "prst";
};
...

107
Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml
View File

@ -1,107 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/baikal,bt1-axi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Baikal-T1 AXI-bus
maintainers:
- Serge Semin <fancer.lancer@gmail.com>
description: |
AXI3-bus is the main communication bus of Baikal-T1 SoC connecting all
high-speed peripheral IP-cores with RAM controller and with MIPS P5600
cores. Traffic arbitration is done by means of DW AXI Interconnect (so
called AXI Main Interconnect) routing IO requests from one block to
another: from CPU to SoC peripherals and between some SoC peripherals
(mostly between peripheral devices and RAM, but also between DMA and
some peripherals). In case of any protocol error, device not responding
an IRQ is raised and a faulty situation is reported to the AXI EHB
(Errors Handler Block) embedded on top of the DW AXI Interconnect and
accessible by means of the Baikal-T1 System Controller.
allOf:
- $ref: /schemas/simple-bus.yaml#
properties:
compatible:
contains:
const: baikal,bt1-axi
reg:
minItems: 1
items:
- description: Synopsys DesignWare AXI Interconnect QoS registers
- description: AXI EHB MMIO system controller registers
reg-names:
minItems: 1
items:
- const: qos
- const: ehb
'#interconnect-cells':
const: 1
syscon:
$ref: /schemas/types.yaml#/definitions/phandle
description: Phandle to the Baikal-T1 System Controller DT node
interrupts:
maxItems: 1
clocks:
items:
- description: Main Interconnect uplink reference clock
clock-names:
items:
- const: aclk
resets:
items:
- description: Main Interconnect reset line
reset-names:
items:
- const: arst
unevaluatedProperties: false
required:
- compatible
- reg
- reg-names
- syscon
- interrupts
- clocks
- clock-names
examples:
- |
#include <dt-bindings/interrupt-controller/mips-gic.h>
bus@1f05a000 {
compatible = "baikal,bt1-axi", "simple-bus";
reg = <0x1f05a000 0x1000>,
<0x1f04d110 0x8>;
reg-names = "qos", "ehb";
#address-cells = <1>;
#size-cells = <1>;
#interconnect-cells = <1>;
syscon = <&syscon>;
ranges;
interrupts = <GIC_SHARED 127 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu_axi 0>;
clock-names = "aclk";
resets = <&ccu_axi 0>;
reset-names = "arst";
};
...

76
Documentation/devicetree/bindings/bus/st,stm32mp131-dbg-bus.yaml Normal file
View File

@ -0,0 +1,76 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/st,stm32mp131-dbg-bus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STM32 Coresight bus
maintainers:
- Gatien Chevallier <gatien.chevallier@foss.st.com>
description:
The STM32 debug bus is in charge of checking the debug configuration
of the platform before probing the peripheral drivers that rely on the debug
domain.
properties:
compatible:
items:
- enum:
- st,stm32mp131-dbg-bus
- st,stm32mp151-dbg-bus
"#address-cells":
const: 1
"#size-cells":
const: 1
ranges:
minItems: 1
maxItems: 2
"#access-controller-cells":
const: 1
description:
Contains the debug profile necessary to access the peripheral.
patternProperties:
"@[0-9a-f]+$":
description: Debug related peripherals
type: object
additionalProperties: true
required:
- access-controllers
required:
- "#access-controller-cells"
- "#address-cells"
- "#size-cells"
- compatible
- ranges
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/stm32mp1-clks.h>
dbg_bus: bus@50080000 {
compatible = "st,stm32mp131-dbg-bus";
#address-cells = <1>;
#size-cells = <1>;
#access-controller-cells = <1>;
ranges = <0x50080000 0x50080000 0x3f80000>;
cti@50094000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0x50094000 0x1000>;
clocks = <&rcc CK_DBG>;
clock-names = "apb_pclk";
access-controllers = <&dbg_bus 0>;
};
};

63
Documentation/devicetree/bindings/cache/baikal,bt1-l2-ctl.yaml vendored
View File

@ -1,63 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
%YAML 1.2
---
$id: http://devicetree.org/schemas/cache/baikal,bt1-l2-ctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Baikal-T1 L2-cache Control Block
maintainers:
- Serge Semin <fancer.lancer@gmail.com>
description: |
By means of the System Controller Baikal-T1 SoC exposes a few settings to
tune the MIPS P5600 CM2 L2 cache performance up. In particular it's possible
to change the Tag, Data and Way-select RAM access latencies. Baikal-T1
L2-cache controller block is responsible for the tuning. Its DT node is
supposed to be a child of the system controller.
properties:
compatible:
const: baikal,bt1-l2-ctl
reg:
maxItems: 1
baikal,l2-ws-latency:
$ref: /schemas/types.yaml#/definitions/uint32
description: Cycles of latency for Way-select RAM accesses
default: 0
minimum: 0
maximum: 3
baikal,l2-tag-latency:
$ref: /schemas/types.yaml#/definitions/uint32
description: Cycles of latency for Tag RAM accesses
default: 0
minimum: 0
maximum: 3
baikal,l2-data-latency:
$ref: /schemas/types.yaml#/definitions/uint32
description: Cycles of latency for Data RAM accesses
default: 1
minimum: 0
maximum: 3
additionalProperties: false
required:
- compatible
examples:
- |
l2@1f04d028 {
compatible = "baikal,bt1-l2-ctl";
reg = <0x1f04d028 0x004>;
baikal,l2-ws-latency = <1>;
baikal,l2-tag-latency = <1>;
baikal,l2-data-latency = <2>;
};
...

2
Documentation/devicetree/bindings/cache/qcom,llcc.yaml vendored
View File

@ -33,6 +33,7 @@ properties:
- qcom,sc7280-llcc
- qcom,sc8180x-llcc
- qcom,sc8280xp-llcc
- qcom,sdm670-llcc
- qcom,sdm845-llcc
- qcom,sm6350-llcc
- qcom,sm7150-llcc
@ -204,6 +205,7 @@ allOf:
contains:
enum:
- qcom,sc7280-llcc
- qcom,sdm670-llcc
then:
properties:
reg:

19
Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
View File

@ -8,17 +8,28 @@ title: Google Chrome OS EC(Embedded Controller) Type C port driver.
maintainers:
- Benson Leung <bleung@chromium.org>
- Prashant Malani <pmalani@chromium.org>
- Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
- Andrei Kuchynski <akuchynski@chromium.org>
- Łukasz Bartosik <ukaszb@chromium.org>
- Jameson Thies <jthies@google.com>
description:
Chrome OS devices have an Embedded Controller(EC) which has access to
Type C port state. This node is intended to allow the host to read and
control the Type C ports. The node for this device should be under a
cros-ec node like google,cros-ec-spi.
control the Type C ports. This binding is compatible with both the
cros-ec-typec and cros-ec-ucsi drivers. The cros-ec-typec driver
supports the host command interface used by the Chrome OS EC with a
built-in Type-C port manager and external Type-C Port Controller
(TCPC). The cros-ec-ucsi driver supports the USB Type-C Connector
System Software (UCSI) interface used by the Chrome OS EC when the
platform has a separate power delivery controller (PDC). The node for
this device should be under a cros-ec node like google,cros-ec-spi.
properties:
compatible:
const: google,cros-ec-typec
enum:
- google,cros-ec-typec
- google,cros-ec-ucsi
'#address-cells':
const: 1

6
Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
View File

@ -32,6 +32,7 @@ properties:
- enum:
- airoha,en7523-scu
- airoha,en7581-scu
- econet,en751221-scu
reg:
items:
@ -67,7 +68,9 @@ allOf:
- if:
properties:
compatible:
const: airoha,en7581-scu
enum:
- airoha,en7581-scu
- econet,en751221-scu
then:
properties:
reg:
@ -98,3 +101,4 @@ examples:
#reset-cells = <1>;
};
};

232
Documentation/devicetree/bindings/clock/axis,artpec9-clock.yaml Normal file
View File

@ -0,0 +1,232 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/axis,artpec9-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Axis ARTPEC-9 SoC clock controller
maintainers:
- Jesper Nilsson <jesper.nilsson@axis.com>
description: |
ARTPEC-9 clock controller is comprised of several CMU (Clock Management Unit)
units, generating clocks for different domains. Those CMU units are modeled
as separate device tree nodes, and might depend on each other.
The root clock in that root tree is an external clock: OSCCLK (25 MHz).
This external clock must be defined as a fixed-rate clock in dts.
CMU_CMU is a top-level CMU, where all base clocks are prepared using PLLs and
dividers, all other clocks of function blocks (other CMUs) are usually
derived from CMU_CMU.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All clocks available for usage
in clock consumer nodes are defined as preprocessor macros in
'include/dt-bindings/clock/axis,artpec9-clk.h' header.
properties:
compatible:
enum:
- axis,artpec9-cmu-cmu
- axis,artpec9-cmu-bus
- axis,artpec9-cmu-core
- axis,artpec9-cmu-cpucl
- axis,artpec9-cmu-fsys0
- axis,artpec9-cmu-fsys1
- axis,artpec9-cmu-imem
- axis,artpec9-cmu-peri
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 5
clock-names:
minItems: 1
maxItems: 5
"#clock-cells":
const: 1
required:
- compatible
- reg
- clocks
- clock-names
- "#clock-cells"
allOf:
- if:
properties:
compatible:
const: axis,artpec9-cmu-cmu
then:
properties:
clocks:
items:
- description: External reference clock (25 MHz)
clock-names:
items:
- const: fin_pll
- if:
properties:
compatible:
const: axis,artpec9-cmu-bus
then:
properties:
clocks:
items:
- description: External reference clock (25 MHz)
- description: CMU_BUS bus clock (from CMU_CMU)
clock-names:
items:
- const: fin_pll
- const: bus
- if:
properties:
compatible:
const: axis,artpec9-cmu-core
then:
properties:
clocks:
items:
- description: External reference clock (25 MHz)
- description: CMU_CORE main clock (from CMU_CMU)
clock-names:
items:
- const: fin_pll
- const: main
- if:
properties:
compatible:
const: axis,artpec9-cmu-cpucl
then:
properties:
clocks:
items:
- description: External reference clock (25 MHz)
- description: CMU_CPUCL switch clock (from CMU_CMU)
clock-names:
items:
- const: fin_pll
- const: switch
- if:
properties:
compatible:
const: axis,artpec9-cmu-fsys0
then:
properties:
clocks:
items:
- description: External reference clock (25 MHz)
- description: CMU_FSYS0 bus clock (from CMU_CMU)
- description: CMU_FSYS0 IP clock (from CMU_CMU)
clock-names:
items:
- const: fin_pll
- const: bus
- const: ip
- if:
properties:
compatible:
const: axis,artpec9-cmu-fsys1
then:
properties:
clocks:
items:
- description: External reference clock (25 MHz)
- description: CMU_FSYS1 scan0 clock (from CMU_CMU)
- description: CMU_FSYS1 scan1 clock (from CMU_CMU)
- description: CMU_FSYS1 bus clock (from CMU_CMU)
clock-names:
items:
- const: fin_pll
- const: scan0
- const: scan1
- const: bus
- if:
properties:
compatible:
const: axis,artpec9-cmu-imem
then:
properties:
clocks:
items:
- description: External reference clock (25 MHz)
- description: CMU_IMEM ACLK clock (from CMU_CMU)
- description: CMU_IMEM CA5 clock (from CMU_CMU)
- description: CMU_IMEM JPEG clock (from CMU_CMU)
- description: CMU_IMEM SSS clock (from CMU_CMU)
clock-names:
items:
- const: fin_pll
- const: aclk
- const: ca5
- const: jpeg
- const: sss
- if:
properties:
compatible:
const: axis,artpec9-cmu-peri
then:
properties:
clocks:
items:
- description: External reference clock (25 MHz)
- description: CMU_PERI IP clock (from CMU_CMU)
- description: CMU_PERI DISP clock (from CMU_CMU)
clock-names:
items:
- const: fin_pll
- const: ip
- const: disp
additionalProperties: false
examples:
# Clock controller node for CMU_FSYS1
- |
#include <dt-bindings/clock/axis,artpec9-clk.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
cmu_fsys1: clock-controller@14c10000 {
compatible = "axis,artpec9-cmu-fsys1";
reg = <0x0 0x14c10000 0x0 0x4000>;
#clock-cells = <1>;
clocks = <&fin_pll>,
<&cmu_cmu CLK_DOUT_CMU_FSYS1_SCAN0>,
<&cmu_cmu CLK_DOUT_CMU_FSYS1_SCAN1>,
<&cmu_cmu CLK_DOUT_CMU_FSYS1_BUS>;
clock-names = "fin_pll", "scan0", "scan1", "bus";
};
};
...

196
Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml
View File

@ -1,196 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/baikal,bt1-ccu-div.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Baikal-T1 Clock Control Unit Dividers
maintainers:
- Serge Semin <fancer.lancer@gmail.com>
description: |
Clocks Control Unit is the core of Baikal-T1 SoC System Controller
responsible for the chip subsystems clocking and resetting. The CCU is
connected with an external fixed rate oscillator, which signal is transformed
into clocks of various frequencies and then propagated to either individual
IP-blocks or to groups of blocks (clock domains). The transformation is done
by means of an embedded into CCU PLLs and gateable/non-gateable dividers. The
later ones are described in this binding. Each clock domain can be also
individually reset by using the domain clocks divider configuration
registers. Baikal-T1 CCU is logically divided into the next components:
1) External oscillator (normally XTAL's 25 MHz crystal oscillator, but
in general can provide any frequency supported by the CCU PLLs).
2) PLLs clocks generators (PLLs).
3) AXI-bus clock dividers (AXI) - described in this binding file.
4) System devices reference clock dividers (SYS) - described in this binding
file.
which are connected with each other as shown on the next figure:
+---------------+
| Baikal-T1 CCU |
| +----+------|- MIPS P5600 cores
| +-|PLLs|------|- DDR controller
| | +----+ |
+----+ | | | | |
|XTAL|--|-+ | | +---+-|
+----+ | | | +-|AXI|-|- AXI-bus
| | | +---+-|
| | | |
| | +----+---+-|- APB-bus
| +-------|SYS|-|- Low-speed Devices
| +---+-|- High-speed Devices
+---------------+
Each sub-block is represented as a separate DT node and has an individual
driver to be bound with.
In order to create signals of wide range frequencies the external oscillator
output is primarily connected to a set of CCU PLLs. Some of PLLs CLKOUT are
then passed over CCU dividers to create signals required for the target clock
domain (like AXI-bus or System Device consumers). The dividers have the
following structure:
+--------------+
CLKIN --|->+----+ 1|\ |
SETCLK--|--|/DIV|->| | |
CLKDIV--|--| | | |-|->CLKLOUT
LOCK----|--+----+ | | |
| |/ |
| | |
EN------|-----------+ |
RST-----|--------------|->RSTOUT
+--------------+
where CLKIN is the reference clock coming either from CCU PLLs or from an
external clock oscillator, SETCLK - a command to update the output clock in
accordance with a set divider, CLKDIV - clocks divider, LOCK - a signal of
the output clock stabilization, EN - enable/disable the divider block,
RST/RSTOUT - reset clocks domain signal. Depending on the consumer IP-core
peculiarities the dividers may lack of some functionality depicted on the
figure above (like EN, CLKDIV/LOCK/SETCLK). In this case the corresponding
clock provider just doesn't expose either switching functions, or the rate
configuration, or both of them.
The clock dividers, which output clock is then consumed by the SoC individual
devices, are united into a single clocks provider called System Devices CCU.
Similarly the dividers with output clocks utilized as AXI-bus reference clocks
are called AXI-bus CCU. Both of them use the common clock bindings with no
custom properties. The list of exported clocks and reset signals can be found
in the files: 'include/dt-bindings/clock/bt1-ccu.h' and
'include/dt-bindings/reset/bt1-ccu.h'. Since System Devices and AXI-bus CCU
are a part of the Baikal-T1 SoC System Controller their DT nodes are supposed
to be a children of later one.
if:
properties:
compatible:
contains:
const: baikal,bt1-ccu-axi
then:
properties:
clocks:
items:
- description: CCU SATA PLL output clock
- description: CCU PCIe PLL output clock
- description: CCU Ethernet PLL output clock
clock-names:
items:
- const: sata_clk
- const: pcie_clk
- const: eth_clk
else:
properties:
clocks:
items:
- description: External reference clock
- description: CCU SATA PLL output clock
- description: CCU PCIe PLL output clock
- description: CCU Ethernet PLL output clock
clock-names:
items:
- const: ref_clk
- const: sata_clk
- const: pcie_clk
- const: eth_clk
properties:
compatible:
enum:
- baikal,bt1-ccu-axi
- baikal,bt1-ccu-sys
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
minItems: 3
maxItems: 4
clock-names:
minItems: 3
maxItems: 4
additionalProperties: false
required:
- compatible
- "#clock-cells"
- clocks
- clock-names
examples:
# AXI-bus Clock Control Unit node:
- |
#include <dt-bindings/clock/bt1-ccu.h>
clock-controller@1f04d030 {
compatible = "baikal,bt1-ccu-axi";
reg = <0x1f04d030 0x030>;
#clock-cells = <1>;
#reset-cells = <1>;
clocks = <&ccu_pll CCU_SATA_PLL>,
<&ccu_pll CCU_PCIE_PLL>,
<&ccu_pll CCU_ETH_PLL>;
clock-names = "sata_clk", "pcie_clk", "eth_clk";
};
# System Devices Clock Control Unit node:
- |
#include <dt-bindings/clock/bt1-ccu.h>
clock-controller@1f04d060 {
compatible = "baikal,bt1-ccu-sys";
reg = <0x1f04d060 0x0a0>;
#clock-cells = <1>;
#reset-cells = <1>;
clocks = <&clk25m>,
<&ccu_pll CCU_SATA_PLL>,
<&ccu_pll CCU_PCIE_PLL>,
<&ccu_pll CCU_ETH_PLL>;
clock-names = "ref_clk", "sata_clk", "pcie_clk",
"eth_clk";
};
# Required Clock Control Unit PLL node:
- |
ccu_pll: clock-controller@1f04d000 {
compatible = "baikal,bt1-ccu-pll";
reg = <0x1f04d000 0x028>;
#clock-cells = <1>;
clocks = <&clk25m>;
clock-names = "ref_clk";
};
...

131
Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
View File

@ -1,131 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/baikal,bt1-ccu-pll.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Baikal-T1 Clock Control Unit PLL
maintainers:
- Serge Semin <fancer.lancer@gmail.com>
description: |
Clocks Control Unit is the core of Baikal-T1 SoC System Controller
responsible for the chip subsystems clocking and resetting. The CCU is
connected with an external fixed rate oscillator, which signal is transformed
into clocks of various frequencies and then propagated to either individual
IP-blocks or to groups of blocks (clock domains). The transformation is done
by means of PLLs and gateable/non-gateable dividers embedded into the CCU.
It's logically divided into the next components:
1) External oscillator (normally XTAL's 25 MHz crystal oscillator, but
in general can provide any frequency supported by the CCU PLLs).
2) PLLs clocks generators (PLLs) - described in this binding file.
3) AXI-bus clock dividers (AXI).
4) System devices reference clock dividers (SYS).
which are connected with each other as shown on the next figure:
+---------------+
| Baikal-T1 CCU |
| +----+------|- MIPS P5600 cores
| +-|PLLs|------|- DDR controller
| | +----+ |
+----+ | | | | |
|XTAL|--|-+ | | +---+-|
+----+ | | | +-|AXI|-|- AXI-bus
| | | +---+-|
| | | |
| | +----+---+-|- APB-bus
| +-------|SYS|-|- Low-speed Devices
| +---+-|- High-speed Devices
+---------------+
Each CCU sub-block is represented as a separate dts-node and has an
individual driver to be bound with.
In order to create signals of wide range frequencies the external oscillator
output is primarily connected to a set of CCU PLLs. There are five PLLs
to create a clock for the MIPS P5600 cores, the embedded DDR controller,
SATA, Ethernet and PCIe domains. The last three domains though named by the
biggest system interfaces in fact include nearly all of the rest SoC
peripherals. Each of the PLLs is based on True Circuits TSMC CLN28HPM core
with an interface wrapper (so called safe PLL' clocks switcher) to simplify
the PLL configuration procedure. The PLLs work as depicted on the next
diagram:
+--------------------------+
| |
+-->+---+ +---+ +---+ | +---+ 0|\
CLKF--->|/NF|--->|PFD|...|VCO|-+->|/OD|--->| |
+---+ +->+---+ +---+ /->+---+ | |--->CLKOUT
CLKOD---------C----------------+ 1| |
+--------C--------------------------->|/
| | ^
Rclk-+->+---+ | |
CLKR--->|/NR|-+ |
+---+ |
BYPASS--------------------------------------+
BWADJ--->
where Rclk is the reference clock coming from XTAL, NR - reference clock
divider, NF - PLL clock multiplier, OD - VCO output clock divider, CLKOUT -
output clock, BWADJ is the PLL bandwidth adjustment parameter. At this moment
the binding supports the PLL dividers configuration in accordance with a
requested rate, while bypassing and bandwidth adjustment settings can be
added in future if it gets to be necessary.
The PLLs CLKOUT is then either directly connected with the corresponding
clocks consumer (like P5600 cores or DDR controller) or passed over a CCU
divider to create a signal required for the clock domain.
The CCU PLL dts-node uses the common clock bindings with no custom
parameters. The list of exported clocks can be found in
'include/dt-bindings/clock/bt1-ccu.h'. Since CCU PLL is a part of the
Baikal-T1 SoC System Controller its DT node is supposed to be a child of
later one.
properties:
compatible:
const: baikal,bt1-ccu-pll
reg:
maxItems: 1
"#clock-cells":
const: 1
clocks:
description: External reference clock
maxItems: 1
clock-names:
const: ref_clk
additionalProperties: false
required:
- compatible
- "#clock-cells"
- clocks
- clock-names
examples:
# Clock Control Unit PLL node:
- |
clock-controller@1f04d000 {
compatible = "baikal,bt1-ccu-pll";
reg = <0x1f04d000 0x028>;
#clock-cells = <1>;
clocks = <&clk25m>;
clock-names = "ref_clk";
};
# Required external oscillator:
- |
clk25m: clock-oscillator-25m {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <25000000>;
clock-output-names = "clk25m";
};
...

46
Documentation/devicetree/bindings/clock/eswin,eic7700-clock.yaml Normal file
View File

@ -0,0 +1,46 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/eswin,eic7700-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Eswin EIC7700 SoC clock controller
maintainers:
- Yifeng Huang <huangyifeng@eswincomputing.com>
- Xuyang Dong <dongxuyang@eswincomputing.com>
description:
The clock controller generates and supplies clock to all the modules
for eic7700 SoC.
properties:
compatible:
const: eswin,eic7700-clock
reg:
maxItems: 1
clocks:
items:
- description: External 24MHz oscillator clock
'#clock-cells':
const: 1
required:
- compatible
- reg
- clocks
- '#clock-cells'
additionalProperties: false
examples:
- |
clock-controller@51828000 {
compatible = "eswin,eic7700-clock";
reg = <0x51828000 0x300>;
clocks = <&xtal24m>;
#clock-cells = <1>;
};

43
Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml
View File

@ -10,10 +10,10 @@ maintainers:
- Michael Walle <michael@walle.cc>
description: |
It is possible to use the BCLK pin of a SAI module as a generic clock
output. Some SoC are very constrained in their pin multiplexer
configuration. Eg. pins can only be changed groups. For example, on the
LS1028A SoC you can only enable SAIs in pairs. If you use only one SAI,
It is possible to use the BCLK or MCLK pin of a SAI module as a generic
clock output. Some SoC are very constrained in their pin multiplexer
configuration. E.g. pins can only be changed in groups. For example, on
the LS1028A SoC you can only enable SAIs in pairs. If you use only one SAI,
the second pins are wasted. Using this binding it is possible to use the
clock of the second SAI as a MCLK clock for an audio codec, for example.
@ -21,16 +21,45 @@ description: |
properties:
compatible:
const: fsl,vf610-sai-clock
oneOf:
- items:
- enum:
- fsl,imx8mm-sai-clock
- fsl,imx8mn-sai-clock
- fsl,imx8mp-sai-clock
- const: fsl,imx8mq-sai-clock
- items:
- enum:
- fsl,imx8mq-sai-clock
- fsl,vf610-sai-clock
reg:
maxItems: 1
clocks:
maxItems: 1
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: bus
- const: mclk1
'#clock-cells':
const: 0
maximum: 1
allOf:
- if:
properties:
compatible:
contains:
const: fsl,vf610-sai-clock
then:
properties:
clocks:
maxItems: 1
clock-names: false
required:
- compatible

4
Documentation/devicetree/bindings/clock/imx6q-clock.yaml
View File

@ -29,20 +29,24 @@ properties:
const: 1
clocks:
minItems: 5
items:
- description: 24m osc
- description: 32k osc
- description: ckih1 clock input
- description: anaclk1 clock input
- description: anaclk2 clock input
- description: clock input from enet ref pad
clock-names:
minItems: 5
items:
- const: osc
- const: ckil
- const: ckih1
- const: anaclk1
- const: anaclk2
- const: enet_ref_pad
fsl,pmic-stby-poweroff:
$ref: /schemas/types.yaml#/definitions/flag

4
Documentation/devicetree/bindings/clock/imx6ul-clock.yaml
View File

@ -29,18 +29,22 @@ properties:
const: 1
clocks:
minItems: 4
items:
- description: 32k osc
- description: 24m osc
- description: ipp_di0 clock input
- description: ipp_di1 clock input
- description: clock input from enet1 ref pad
clock-names:
minItems: 4
items:
- const: ckil
- const: osc
- const: ipp_di0
- const: ipp_di1
- const: enet1_ref_pad
required:
- compatible

155
Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
View File

@ -1,155 +0,0 @@
NVIDIA Tegra124 DFLL FCPU clocksource
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
The DFLL IP block on Tegra is a root clocksource designed for clocking
the fast CPU cluster. It consists of a free-running voltage controlled
oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop
control module that will automatically adjust the VDD_CPU voltage by
communicating with an off-chip PMIC either via an I2C bus or via PWM signals.
Required properties:
- compatible : should be one of:
- "nvidia,tegra124-dfll": for Tegra124
- "nvidia,tegra210-dfll": for Tegra210
- reg : Defines the following set of registers, in the order listed:
- registers for the DFLL control logic.
- registers for the I2C output logic.
- registers for the integrated I2C master controller.
- look-up table RAM for voltage register values.
- interrupts: Should contain the DFLL block interrupt.
- clocks: Must contain an entry for each entry in clock-names.
See clock-bindings.txt for details.
- clock-names: Must include the following entries:
- soc: Clock source for the DFLL control logic.
- ref: The closed loop reference clock
- i2c: Clock source for the integrated I2C master.
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- dvco: Reset control for the DFLL DVCO.
- #clock-cells: Must be 0.
- clock-output-names: Name of the clock output.
- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL
hardware will start controlling. The regulator will be queried for
the I2C register, control values and supported voltages.
Required properties for the control loop parameters:
- nvidia,sample-rate: Sample rate of the DFLL control loop.
- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM.
- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM.
- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM.
- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM.
- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM.
Optional properties for the control loop parameters:
- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM.
Optional properties for mode selection:
- nvidia,pwm-to-pmic: Use PWM to control regulator rather then I2C.
Required properties for I2C mode:
- nvidia,i2c-fs-rate: I2C transfer rate, if using full speed mode.
Required properties for PWM mode:
- nvidia,pwm-period-nanoseconds: period of PWM square wave in nanoseconds.
- nvidia,pwm-tristate-microvolts: Regulator voltage in micro volts when PWM
control is disabled and the PWM output is tristated. Note that this voltage is
configured in hardware, typically via a resistor divider.
- nvidia,pwm-min-microvolts: Regulator voltage in micro volts when PWM control
is enabled and PWM output is low. Hence, this is the minimum output voltage
that the regulator supports when PWM control is enabled.
- nvidia,pwm-voltage-step-microvolts: Voltage increase in micro volts
corresponding to a 1/33th increase in duty cycle. Eg the voltage for 2/33th
duty cycle would be: nvidia,pwm-min-microvolts +
nvidia,pwm-voltage-step-microvolts * 2.
- pinctrl-0: I/O pad configuration when PWM control is enabled.
- pinctrl-1: I/O pad configuration when PWM control is disabled.
- pinctrl-names: must include the following entries:
- dvfs_pwm_enable: I/O pad configuration when PWM control is enabled.
- dvfs_pwm_disable: I/O pad configuration when PWM control is disabled.
Example for I2C:
clock@70110000 {
compatible = "nvidia,tegra124-dfll";
reg = <0 0x70110000 0 0x100>, /* DFLL control */
<0 0x70110000 0 0x100>, /* I2C output control */
<0 0x70110100 0 0x100>, /* Integrated I2C controller */
<0 0x70110200 0 0x100>; /* Look-up table RAM */
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>,
<&tegra_car TEGRA124_CLK_DFLL_REF>,
<&tegra_car TEGRA124_CLK_I2C5>;
clock-names = "soc", "ref", "i2c";
resets = <&tegra_car TEGRA124_RST_DFLL_DVCO>;
reset-names = "dvco";
#clock-cells = <0>;
clock-output-names = "dfllCPU_out";
vdd-cpu-supply = <&vdd_cpu>;
nvidia,sample-rate = <12500>;
nvidia,droop-ctrl = <0x00000f00>;
nvidia,force-mode = <1>;
nvidia,cf = <10>;
nvidia,ci = <0>;
nvidia,cg = <2>;
nvidia,i2c-fs-rate = <400000>;
};
Example for PWM:
clock@70110000 {
compatible = "nvidia,tegra124-dfll";
reg = <0 0x70110000 0 0x100>, /* DFLL control */
<0 0x70110000 0 0x100>, /* I2C output control */
<0 0x70110100 0 0x100>, /* Integrated I2C controller */
<0 0x70110200 0 0x100>; /* Look-up table RAM */
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA210_CLK_DFLL_SOC>,
<&tegra_car TEGRA210_CLK_DFLL_REF>,
<&tegra_car TEGRA124_CLK_I2C5>;;
clock-names = "soc", "ref", "i2c";
resets = <&tegra_car TEGRA124_RST_DFLL_DVCO>;
reset-names = "dvco";
#clock-cells = <0>;
clock-output-names = "dfllCPU_out";
nvidia,sample-rate = <25000>;
nvidia,droop-ctrl = <0x00000f00>;
nvidia,force-mode = <1>;
nvidia,cf = <6>;
nvidia,ci = <0>;
nvidia,cg = <2>;
nvidia,pwm-min-microvolts = <708000>; /* 708mV */
nvidia,pwm-period-nanoseconds = <2500>; /* 2.5us */
nvidia,pwm-to-pmic;
nvidia,pwm-tristate-microvolts = <1000000>;
nvidia,pwm-voltage-step-microvolts = <19200>; /* 19.2mV */
pinctrl-names = "dvfs_pwm_enable", "dvfs_pwm_disable";
pinctrl-0 = <&dvfs_pwm_active_state>;
pinctrl-1 = <&dvfs_pwm_inactive_state>;
};
/* pinmux nodes added for completeness. Binding doc can be found in:
* Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml
*/
pinmux: pinmux@700008d4 {
dvfs_pwm_active_state: dvfs_pwm_active {
dvfs_pwm_pbb1 {
nvidia,pins = "dvfs_pwm_pbb1";
nvidia,tristate = <TEGRA_PIN_DISABLE>;
};
};
dvfs_pwm_inactive_state: dvfs_pwm_inactive {
dvfs_pwm_pbb1 {
nvidia,pins = "dvfs_pwm_pbb1";
nvidia,tristate = <TEGRA_PIN_ENABLE>;
};
};
};

290
Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.yaml Normal file
View File

@ -0,0 +1,290 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/nvidia,tegra124-dfll.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra124 (and later) DFLL FCPU clocksource
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
description:
The DFLL IP block on Tegra is a root clocksource designed for clocking
the fast CPU cluster. It consists of a free-running voltage controlled
oscillator connected to the CPU voltage rail (VDD_CPU), and a closed
loop control module that will automatically adjust the VDD_CPU voltage
by communicating with an off-chip PMIC either via an I2C bus or via
PWM signals.
properties:
compatible:
enum:
- nvidia,tegra124-dfll
- nvidia,tegra210-dfll
reg:
items:
- description: DFLL control logic
- description: I2C output logic
- description: Integrated I2C controller
- description: Look-up table RAM for voltage register values
interrupts:
maxItems: 1
"#clock-cells":
const: 0
clocks:
items:
- description: Clock source for the DFLL control logic
- description: Closed loop reference clock
- description: Clock source for the integrated I2C controller
clock-names:
items:
- const: soc
- const: ref
- const: i2c
clock-output-names:
description: Name of the clock output
items:
- const: dfllCPU_out
resets:
minItems: 1
maxItems: 2
reset-names:
minItems: 1
items:
- const: dvco
- const: dfll
vdd-cpu-supply:
description: Regulator for the CPU voltage rail that the DFLL
hardware will start controlling. The regulator will be queried for
the I2C register, control values and supported voltages.
nvidia,sample-rate:
description: Sample rate of the DFLL control loop
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 12500
maximum: 25000
nvidia,droop-ctrl:
description: Droop control parameter (CL_DVFS_DROOP_CTRL) in the TRM
$ref: /schemas/types.yaml#/definitions/uint32
nvidia,force-mode:
description: See the field DFLL_PARAMS_FORCE_MODE in the TRM
$ref: /schemas/types.yaml#/definitions/uint32
oneOf:
- description: disabled
const: 0
- description: fixed delay mode
const: 1
- description: auto mode
const: 2
nvidia,cf:
description: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 63
nvidia,ci:
description: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 7
nvidia,cg:
description: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
# optional properties
nvidia,cg-scale:
description: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM
$ref: /schemas/types.yaml#/definitions/flag
nvidia,pwm-to-pmic:
description: Use PWM to control regulator rather than I2C
$ref: /schemas/types.yaml#/definitions/flag
nvidia,i2c-fs-rate:
description: I2C transfer rate, if using full speed mode
$ref: /schemas/types.yaml#/definitions/uint32
enum: [100000, 400000]
# required properties for PWM mode
nvidia,pwm-period-nanoseconds:
description: Period of PWM square wave in nanoseconds
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1000
maximum: 1000000000
nvidia,pwm-tristate-microvolts:
description: Regulator voltage in microvolts when PWM control is disabled
and the PWM output is tristated. Note that this voltage is configured in
hardware, typically via a resistor divider.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3300000
nvidia,pwm-min-microvolts:
description: Regulator voltage in microvolts when PWM control is enabled
and PWM output is low. Hence, this is the minimum output voltage that
the regulator supports when PWM control is enabled.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3300000
nvidia,pwm-voltage-step-microvolts:
description: |
Voltage increase in micro volts corresponding to a 1/33th increase
in duty cycle. For example, the voltage for 2/33th duty cycle would be:
nvidia,pwm-min-microvolts + nvidia,pwm-voltage-step-microvolts * 2
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 100000
pinctrl-0:
description: I/O pad configuration when PWM control is enabled
pinctrl-1:
description: I/O pad configuration when PWM control is disabled
pinctrl-names:
items:
- const: dvfs_pwm_enable
- const: dvfs_pwm_disable
required:
- compatible
- reg
- interrupts
- "#clock-cells"
- clocks
- clock-names
- clock-output-names
- resets
- reset-names
- nvidia,sample-rate
- nvidia,droop-ctrl
- nvidia,force-mode
- nvidia,cf
- nvidia,ci
- nvidia,cg
additionalProperties: false
allOf:
- if:
properties:
compatible:
contains:
const: nvidia,tegra124-dfll
then:
properties:
resets:
maxItems: 1
reset-names:
maxItems: 1
else:
properties:
resets:
minItems: 2
reset-names:
minItems: 2
- if:
required:
- nvidia,pwm-to-pmic
then:
required:
- nvidia,pwm-min-microvolts
- nvidia,pwm-period-nanoseconds
- nvidia,pwm-tristate-microvolts
- nvidia,pwm-voltage-step-microvolts
else:
required:
- vdd-cpu-supply
examples:
- |
#include <dt-bindings/clock/tegra124-car.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/tegra124-car.h>
clock@70110000 {
compatible = "nvidia,tegra124-dfll";
reg = <0x70110000 0x100>, /* DFLL control */
<0x70110000 0x100>, /* I2C output control */
<0x70110100 0x100>, /* Integrated I2C controller */
<0x70110200 0x100>; /* Look-up table RAM */
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>,
<&tegra_car TEGRA124_CLK_DFLL_REF>,
<&tegra_car TEGRA124_CLK_I2C5>;
clock-names = "soc", "ref", "i2c";
resets = <&tegra_car TEGRA124_RST_DFLL_DVCO>;
reset-names = "dvco";
#clock-cells = <0>;
clock-output-names = "dfllCPU_out";
vdd-cpu-supply = <&vdd_cpu>;
nvidia,sample-rate = <12500>;
nvidia,droop-ctrl = <0x00000f00>;
nvidia,force-mode = <1>;
nvidia,cf = <10>;
nvidia,ci = <0>;
nvidia,cg = <2>;
nvidia,i2c-fs-rate = <400000>;
};
- |
#include <dt-bindings/clock/tegra210-car.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/tegra210-car.h>
clock@70110000 {
compatible = "nvidia,tegra210-dfll";
reg = <0x70110000 0x100>, /* DFLL control */
<0x70110000 0x100>, /* I2C output control */
<0x70110100 0x100>, /* Integrated I2C controller */
<0x70110200 0x100>; /* Look-up table RAM */
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA210_CLK_DFLL_SOC>,
<&tegra_car TEGRA210_CLK_DFLL_REF>,
<&tegra_car TEGRA210_CLK_I2C5>;
clock-names = "soc", "ref", "i2c";
resets = <&tegra_car TEGRA210_RST_DFLL_DVCO>,
<&tegra_car 155>;
reset-names = "dvco", "dfll";
#clock-cells = <0>;
clock-output-names = "dfllCPU_out";
vdd-cpu-supply = <&vdd_cpu>;
nvidia,sample-rate = <25000>;
nvidia,droop-ctrl = <0x00000f00>;
nvidia,force-mode = <1>;
nvidia,cf = <6>;
nvidia,ci = <0>;
nvidia,cg = <2>;
nvidia,pwm-min-microvolts = <708000>; /* 708mV */
nvidia,pwm-period-nanoseconds = <2500>; /* 2.5us */
nvidia,pwm-to-pmic;
nvidia,pwm-tristate-microvolts = <1000000>;
nvidia,pwm-voltage-step-microvolts = <19200>; /* 19.2mV */
};

96
Documentation/devicetree/bindings/clock/qcom,eliza-dispcc.yaml Normal file
View File

@ -0,0 +1,96 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,eliza-dispcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Display Clock & Reset Controller for Qualcomm Eliza SoC
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- Konrad Dybcio <konradybcio@kernel.org>
- Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
description: |
Display clock control module provides the clocks, resets and power
domains on Qualcomm Eliza SoC platform.
See also:
- include/dt-bindings/clock/qcom,eliza-dispcc.h
properties:
compatible:
enum:
- qcom,eliza-dispcc
clocks:
items:
- description: Board XO source
- description: Board Always On XO source
- description: Display's AHB clock
- description: sleep clock
- description: Byte clock from DSI PHY0
- description: Pixel clock from DSI PHY0
- description: Byte clock from DSI PHY1
- description: Pixel clock from DSI PHY1
- description: Link clock from DP PHY0
- description: VCO DIV clock from DP PHY0
- description: Link clock from DP PHY1
- description: VCO DIV clock from DP PHY1
- description: Link clock from DP PHY2
- description: VCO DIV clock from DP PHY2
- description: Link clock from DP PHY3
- description: VCO DIV clock from DP PHY3
- description: HDMI link clock from HDMI PHY
power-domains:
maxItems: 1
required-opps:
maxItems: 1
required:
- compatible
- clocks
- '#power-domain-cells'
allOf:
- $ref: qcom,gcc.yaml#
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,dsi-phy-28nm.h>
#include <dt-bindings/clock/qcom,eliza-gcc.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/power/qcom,rpmhpd.h>
clock-controller@af00000 {
compatible = "qcom,eliza-dispcc";
reg = <0x0af00000 0x20000>;
clocks = <&bi_tcxo_div2>,
<&bi_tcxo_ao_div2>,
<&gcc GCC_DISP_AHB_CLK>,
<&sleep_clk>,
<&dsi0_phy DSI_BYTE_PLL_CLK>,
<&dsi0_phy DSI_PIXEL_PLL_CLK>,
<&dsi1_phy DSI_BYTE_PLL_CLK>,
<&dsi1_phy DSI_PIXEL_PLL_CLK>,
<&dp0_phy 0>,
<&dp0_phy 1>,
<&dp1_phy 0>,
<&dp1_phy 1>,
<&dp2_phy 0>,
<&dp2_phy 1>,
<&dp3_phy 0>,
<&dp3_phy 1>,
<&hdmi_phy>;
#clock-cells = <1>;
#power-domain-cells = <1>;
#reset-cells = <1>;
power-domains = <&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
};
...

4
Documentation/devicetree/bindings/clock/qcom,glymur-dispcc.yaml
View File

@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/clock/qcom,glymur-dispcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display Clock & Reset Controller on GLYMUR
title: Qualcomm Display Clock & Reset Controller on Glymur SoC
maintainers:
- Taniya Das <taniya.das@oss.qualcomm.com>
description: |
Qualcomm display clock control module which supports the clocks, resets and
power domains for the MDSS instances on GLYMUR SoC.
power domains for the MDSS instances on Glymur SoC.
See also:
include/dt-bindings/clock/qcom,dispcc-glymur.h

62
Documentation/devicetree/bindings/clock/qcom,ipq5210-gcc.yaml Normal file
View File

@ -0,0 +1,62 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,ipq5210-gcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller on IPQ5210
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ5210
See also:
include/dt-bindings/clock/qcom,ipq5210-gcc.h
include/dt-bindings/reset/qcom,ipq5210-gcc.h
properties:
compatible:
const: qcom,ipq5210-gcc
clocks:
items:
- description: Board XO source
- description: Sleep clock source
- description: PCIE30 PHY0 pipe clock source
- description: PCIE30 PHY1 pipe clock source
- description: USB3 PHY pipe clock source
- description: NSS common clock source
'#power-domain-cells': false
'#interconnect-cells':
const: 1
required:
- compatible
- clocks
allOf:
- $ref: qcom,gcc.yaml#
unevaluatedProperties: false
examples:
- |
clock-controller@1800000 {
compatible = "qcom,ipq5210-gcc";
reg = <0x01800000 0x40000>;
clocks = <&xo_board_clk>,
<&sleep_clk>,
<&pcie30_phy0_pipe_clk>,
<&pcie30_phy1_pipe_clk>,
<&usb3phy_0_cc_pipe_clk>,
<&nss_cmn_clk>;
#clock-cells = <1>;
#reset-cells = <1>;
};
...

2
Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml
View File

@ -26,6 +26,8 @@ properties:
enum:
- qcom,ipq5018-cmn-pll
- qcom,ipq5424-cmn-pll
- qcom,ipq6018-cmn-pll
- qcom,ipq8074-cmn-pll
- qcom,ipq9574-cmn-pll
reg:

Some files were not shown because too many files have changed in this diff Show More